USB floppy disc controller

[Chuck(G)]

Here's my first try. This is a track from a 720K DOS floppy done Catweasel-type sampling. Very crude code so far; no interrupts, just plain old polling loops.

This is essentially a 3-chip solution; 1 AVR ATMega128 uC, a 74LS373 latch and a 62128 128K SRAM. Since the AVR will sink 40 ma loads, I didn't even need any output buffers or receivers (although my prototype has them).

I'd appreciate it if someone with some Catweasel-type MFM decoding code could check my work. Otherwise, I'll sit down and get busy coding my own MFM decoder.

This was done with a 16MHz clock, so each byte represents a time delay from the previous byte in 62.5 nsec. units. Unlike the Catweasel format, all 8 bits are used.

 

[philpem]

This is essentially a 3-chip solution; 1 AVR ATMega128 uC, a 74LS373 latch and a 62128 128K SRAM. Since the AVR will sink 40 ma loads, I didn't even need any output buffers or receivers (although my prototype has them).

Even so, I'd be tempted to use some form of bus buffer -- if nothing else, it adds another layer of protection. Screw up with the drive power and instead of cooking your MCU (and maybe the SRAM), you cook a couple of 20p bus buffers...

I'd appreciate it if someone with some Catweasel-type MFM decoding code could check my work. Otherwise, I'll sit down and get busy coding my own MFM decoder.

Have you tried cwfloppy or one of Tim Mann's decoders?

I'll try and load it into my MFM decoder later on -- but I've only just woke up and as I'm sure you can understand, digging out the laptop isn't high on my list of priorities!

This was done with a 16MHz clock, so each byte represents a time delay from the previous byte in 62.5 nsec. units. Unlike the Catweasel format, all 8 bits are used.

So there's no "index status" bit, then?
That's a shame. Might make reading some hard-sectored discs a bit harder.

 

[Chuck(G)]

Even so, I'd be tempted to use some form of bus buffer -- if nothing else, it adds another layer of protection. Screw up with the drive power and instead of cooking your MCU (and maybe the SRAM), you cook a couple of 20p bus buffers...

Have you tried cwfloppy or one of Tim Mann's decoders?

I'll try and load it into my MFM decoder later on -- but I've only just woke up and as I'm sure you can understand, digging out the laptop isn't high on my list of priorities!

So there's no "index status" bit, then?
That's a shame. Might make reading some hard-sectored discs a bit harder.

I've yet to see a modern motherboard that uses buffers separate from the southbridge chip--and for that matter, many old ISA hard-floppy controllers used the DP8473 FDC "naked". So I'm still not decided about the buffer question.

Easy enough to add; the status is available--just haven't bothered with it at this point. Right now, I'm trying to figure out if I'm on the right track. I'm not even certain that the Mega128 is a good chip to use--it's old technology and there are better choices available. I just happened to have a couple around.

I've considered adding the index status as a separate byte value, say, 00, rather than devote a whole bit to it out of every sample. Same for clock rates; this was run with a 1x rate; I also have x/2 and x/4 supported.

Similarly, I'll probably want to include de/encoders for FM and MFM as well as for a few other modulation techniques to keep the amount of data actually transferred to the host down.

There are other aspects that need addressing before a "final" design comes out. For example, is this something that will be prefabricated or is it to be a through-hole design offered as a kit? If the latter, the choice of uC is strongly influenced. Right now the design supports both USB 1.1 and RS-232 serial, but will anyone actually use the RS-232 (i.e. is it worth the effort putting in the TTL-to-RS-232C level translator)?

 

[hexsane]

There are other aspects that need addressing before a "final" design comes out. For example, is this something that will be prefabricated or is it to be a through-hole design offered as a kit? If the latter, the choice of uC is strongly influenced. Right now the design supports both USB 1.1 and RS-232 serial, but will anyone actually use the RS-232 (i.e. is it worth the effort putting in the TTL-to-RS-232C level translator)?

I do prefer through hole myself even if fully assembled - it offers the possibility of repair in case of disaster.

Having an RS-232 port would allow non-USB computers (even non-IBM) to use the device. I would really like that. What baud rate would you default to? Something low like 2400 with the ability to set the rate higher with a command would be ideal as using jumpers/dip switches may complicate things further.

-Matt

 

[Chuck(G)]

No jumpers or switches here. The uC has 4K of EEPROM, so it's got lots of space to store options.

 

[cgrape2]

As an example of this thing's end user,I'd like to vote for both the RS232 and a USB port.I count myself as barely competent in assembly,so anything that makes soldering easier would be a BIG help.
As I am following this discussion,I am getting a terrific technical overview of the goings on.Wow!
cgrape2

 

[Chuck(G)]

Second try, after writing a simple MFM decoder. This is the first track from a DSHD 3.5" disk fished out of my junk box--it supposedly contains a version of the Fedex shipping software. The "testout.bin" file is the raw binary sample file and the "testout.txt" file is the decoded dump of the sample file. So far, so good.

It looks as if the 128K sample memory is adequate for 1.44MB media; the largest sample file I obtained was about 93K. If necessary, I can increase the sample RAM to 512K, but I don't think that will be necessary. I'm pretty happy that a 16MHz sample rate appears to be adequate.

So I've got to start thinking about the real thing. Do I include a decoder for MFM and FM in the uC firmware?

Thoughtful input is solicited. I want to breadboard one more version--the one that I hope will be the final one, so if you have suggestions, get them in before I pick up the soldering iron.

Thanks, as always!

 

[Dwight Elvey]

Hi Chuck
It would be good to have a few of the more common
formats like FM and MFM. You might even add Apples
GCR. Still you should always be able to get the raw
timing data so that any different format could be read.
It is more important to get tracks than files. I'd
leave the files for post processing on a PC or such.
Do have some way to indicate index. It might be best
to have blocks of data with size counts and some form
of simple block ID. That way you could have different
block IDs for chunks when index was active and not.
It would then be simple to remove index information if needed
after getting it on a PC.
Dwight

 

[nathan]

I definitely see the utility of firmware that rips tracks for later decoding (more 'universal') but from the perspective of many end-users it would be nice to have file-level access. Much like the device I've seen that presents a Super Nintendo/Genesis cartridge as a FAT filesystem. Also, if you provide USB Mass Storage functionality, it will have automatic compatibility with Macs, PCs, Linux, et cetera.

Of course, the FAT stuff is a whole other layer of complexity, so maybe a firmware with host-based decode first, then the upgrade that is plug-and-play.

 

[Chuck(G)]

Hi Dwight,

Right now, I trigger on the leading edge of the index--the trailing edge position seems to vary wildly from drive to drive, so I'm guessing that most controllers and software do the same.

I can plug a 00 byte (an impossible sampling value)into the sampling stream at index pulses. I suppose two commands should be added to the repertoire--"sample for xxx milliseconds" and "sample for xxx index pulses".

Another command I was thinking about was "skip xxx samples, then begin reading/writing", to allow a part of the track to be transferred.

The nice thing about the AVR is that not only can it be programmed with a JTAG or ISP programmer in-circuit, but that it can program itself (i.e. "boot block" mode), so firmware updates can be pretty simple.

On the physical end, is support for 2 drives sufficient? Should the board include a 50 pin header for 8" drives as well as a 34-pin header?

Also, be aware that since the pullup specs for older drives are pretty severe (150 ohm), this thing will not be self-powered off USB. I'm guessing that a standard 4-pin Molex (i.e. hard drive connector) will be sufficient for most people to supply power to the board.

I don't know about disguising this thing as a USB mass storage device. The command set is pretty restricted and not suited to handling strange formats--one can layer that into a Windows/Linux driver if desired. Right now, I'm just using it as a communications device.

 

[Chuck(G)]

The attached shows that FM is no problem either (first track of a disk from a Potter and Brumfeld CP/M box). I've got an Apple II sample recorded, but I need to go back to my copy of "Understanding the Apple IIe" and refresh my memory--it's been over 24 years since I wrote any decoding for those formats (a prototype ISA card project that went nowhere) and I only vaguely recall the details.

I've also tried this with an 8" drive, both FM and MFM; no issues there either. I'll eventually move on to some of my GCR/100 tpi/hard sectored samples and see how that goes.

Thoughts on the interface: I don't know that USB is worth the trouble if I keep RS-232C around. What with getting a USB VID and whatnot, it might be simpler to just use an inexpensive RS-232-to-USB converter. The USB power supply isn't useful at any rate. It's not a matter of hardware or even code (the VUSB code for an AVR is pretty simple and small), but more a matter of being worth the trouble.

Input welcome, as always!

 

[NobodyIsHere]

Hi Chuck! Thanks! A simple USB to serial adapter may actually be cheaper and more flexible than adding USB directly to the device. Here are some adapters for less than $10 at NewEgg

http://www.newegg.com/Product/Produ...r&bop=And&ActiveSearchResult=True&Order=PRICE

Also, the software using regular serial would be more simple too. Just use HyperTerm or other terminal program at first and then migrate to an integrated front-end program.

Please let me know when you want to start prototyping the PCB. This is a good time since the N8VEM VDU board is now known working and some other projects have plateaued for a bit.

Thanks and have a nice day!

Andrew Lynch

PS, are you thinking of using a regular ATX style power supply? That would power the drives and the PCB easily.

 

[Chuck(G)]

PS, are you thinking of using a regular ATX style power supply? That would power the drives and the PCB easily.

I suppose that we can leave some traces and holes for a USB connector and eventually supply one (along with software) if folks get too strident. At least it wouldn't be a PCB redesign.

Right now, I'm using a small bench supply that puts out about 1.5A both at 12v and 5v for testing. That's enough to power a floppy drive and the board. My concern about using a full-blown ATX supply is that the load isn't heavy enough to keep it from shutting down. Perhaps a 12V "wall wart" type supply with a 5v regulator on it might do the trick.

I want to do some writing experiments this week, as the reading end seems to be working pretty well. After that, I'll sketch out a schematic with parts specification and turn you loose on a PCB.

Thanks!
Chuck

P.S. I've ordered a couple of USB-to-serial cables off of eBay. With shipping, less than $4.

 

[NobodyIsHere]

Hi Chuck! OK! That sounds good to me. We can use a 12V wall wart and 7805 SCRs to for the 5V sections. No problem!

Thanks and have a nice day!

Andrew Lynch

 

[Chuck(G)]

Hi Andrew,

The 7805 was a pretty good linear regulator for 1973, but the problem is that the 7V drop across it will go up in heat. If the drive and the board draw 500 ma (I don't think that's unrealistic, given the size of the pullup resistors), that's 3.5W in heat.

How about moving into the 21st century with something like an LM2575-5 switcher? Not much more than the 7805 and hugely better efficiency. If 1A isn't enough, an MC4576-5.0BT should work without component changes to supply 3A.

Just a suggestion...

Thanks,
Chuck

 

[NobodyIsHere]

Hi Chuck! Yes, I meant the 7805 SCR as a general idea. There are far more efficient SCRs these days that can handle a lot more output current - some are directly pin compatible. We can work out those details during the schematic and PCB layout. It's no problem!

Thanks and have a nice day!

Andrew Lynch

 

[Chuck(G)]

Hi Chuck! Yes, I meant the 7805 SCR as a general idea. There are far more efficient SCRs these days that can handle a lot more output current - some are directly pin compatible. We can work out those details during the schematic and PCB layout. It's no problem!

Hi Andrew,

I'm not familiar with the term "SCR" for a linear pass regulator, just the usual "Silicon Controlled Rectifier", which, of course, the 7805 is not. What does "SCR" stand for in this context?

Thanks for educating me,
Chuck

 

[NobodyIsHere]

Hi! I am thinking regulator not rectifier. Thanks for the clarification.

Andrew Lynch

 

[NobodyIsHere]

Hi Chuck! What's the latest on this project?

Thanks and have a nice day!

Andrew Lynch

 

[Chuck(G)]

Hi Chuck! What's the latest on this project?

Thanks and have a nice day!

Andrew Lynch

Hi Andrew!

I've decided to get serious, so the patched-together firmware that I've been working with has been getting a rewrite. I should have some design decisions by early next week. I'm still waiting on my USB-serial adapters as well and expect them no later than next week.

I'd like to say that the design will fit in a DIP-packaged uC, but as the design matures, it looks less likely. Just too many I/Os.

--Chuck