Well, I’ve switched servers at my webhost. I’ve updated WordPress and Gallery. No major changes, but both of these updates fix security vunerabilities. I’ve been wrapped around this for a approximately a week or so, but the transition went pretty much as planned.
I’ll be updating the status of the project over the weekend.
I’m just starting to try to get a microcontroller to read an IBM floppy, and ran across your Amiga project.
Did you go all the way down to receiving those individual pulses from the floppy, detecting the index, and sync, and reading sector, track, side, crc, and decoding FM or MFM or however the data is encoded? How hard was it? Is your code available to the general public?
Yes, I went all the way down to the hardware layer, signal layer, layer 1 if you will.
I don’t use the index, as it’s really not valuable to me. I receive a string of pulses(aka bits), one at a time, from directly from the disk. And yes, I’ve also written the MFM decoding routines. It’s not ENTIRELY from scratch, but I understand it down to the lowest layer, and I did create the code entirely myself. I learned the general ropes from Veneri’s Amiga Floppy Reader, from floppy.c in the Amiga Fellow emulator, and from some assembly code written for the amiga.
How hard was it? Well, it wasn’t easy. Look at my blog. I’m like two years into it, but this has been a nights/weekend project mostly, and I’ve taken a lot of time off it. I have spent a very large number of intensive hours on it.
There are a couple reasons though, and perhaps your experience will go much better :
1> Limited other people doing this, so collaboration is hard. I had some posters here though who *REALLY* helped me out.
2> I was learning microcontrollers and electronic stuff as I went, if I had previous experience it would have gone faster.
3> My firmware is completely from scratch, and has several different important subroutines that have to work together. I made the huge mistake of not FULLY testing my individual modules independently of each other.
4> Since I had lack of hardware skills, I was literally redesigning the hardware as I went. I’ve gone through at least a few different combinations of hardware before the hardware could support the concept. I first tried using the parallel port, tried without memory, tried using an amiga drive, and so on.
My source code is public, however, I’m not particularly proud of the form it’s in right now. It’s not optimized, it’s not pretty, but it works. I’m not a slob of a programmer, and I comment my code, etc, so it’s not entirely unreadable. I’ll be happy to share the work I’ve done, but I don’t think I’ll post it publically, not quite yet. There are some older versions on the blog already, but I wouldn’t look at them, they are so old and out dated. Also the java code isn’t easily runnable, libraries have to be the right place, you’ve got use a hard-coded serial port(virtual serial usb port) at this point, and so on. Just not ready for public consumption, not quite yet.
I’m going to put up another post describing in (painful?) detail of how my project works, so this should benefit you. Also, you can email me at
, and I’ll forward you whatever code you need.
Whose microcontroller are you using? AVR? Microchip? Parallax?
Thanks for the info.
I’m planning to use the Parallax propeller. What I’ve done so far is to make an adapter that connects the floppy 34-pin cable to a 25-pin D cable with bit directions matching the PC parallel port. I wrote a Delphi program in the PC that is able to start the floppy motor, step the head, and receive index, head-zero and data pulses. I used the PC because it’s quick and easy to get those basics working, but I don’t think the parallel port is fast enough to decode the data pulses.
So as soon as I had the confidence that I wired the connector properly, I wired a 25-pin D connector onto my homemade propeller breadboard so I can easily swap the floppy cable back and forth between the PC and the propeller. As of last night the propeller can run the floppy motor and make the head make noises, but it’s not reading the head-zero or the index inputs yet. But since the PC can get those to work it shouldn’t be too hard to figure out what the propeller is doing differently.
All those sync bytes, and sector headers, and CRC and data pulses look like a mess to me. I have no idea how decoding those will go. But that’s the challenge of it; to dig in and figure it out!
I’ve made a WAV audio player on the propeller breadboard that reads standard WAV files from an SD card FAT directory and plays them (the code for this is posted in the Parallax projects forum) , and I’ve gotten a rudimentary hard disk raw sector reader and writer working, so I think those experiences will help a lot to get this floppy interface running.
Sorry about the delay in posting, I like to be faster in replying.
If you’ve read far enough back in my blog, I too, started out with the parallel port. Basically, what I figured out, is that the parallel port (while having true speeds of at least 1mbps+) is not fast enough in any high-level language, at least in any new version of Windows. I’m sure that in pure assembly, or in dos, or any place(like win98) where there is limited to no hardware abstraction/protection, it’s definitely possible. Currently flavors of Windows require a ring-0(I think this what its called) patch in order to provide direct access to the parallel port.
I used WINIO library in C and that worked really nice. https://www.internals.com/
In the end, I just don’t think that using the parallel port would be fast enough. I wouldn’t be surprised if one could find a workable solution. My plan has mostly been to take the path of least resistance, and so USB was a natural next step. Plus, I’m running my USB at 2mbps (I’m confident you cant do that with most parallel ports), and at least the PC side is handled by UART inside the usb-serial converter that I’m using. So I only have to debug one UART code instead of two.
Once you jump into the meat of it, most of the SYNC bytes, sector headers, CRC and so on will make plenty of sense. I was sort of overwhelmed with it as well. The natural progression of my project has made a logical progression of learning it. So I learned it when I *needed* to know it.
One thing to note: The amiga uses different MFM encoding (Commodore engineers called it “funny AmigaMFM 0.1” or something) than PC’s do, but I think you’ll find that the PC is actually easier. The amiga’s odd and even bits were separated by half a sector, and so it had to recombine these broken-up 16-bit words.
Yeah, if you’ve worked with harddrives, you should be ok with floppies!
I do want to fully document my code to process the raw signalling, because although its a short code segment, it’s really doing alot.
I’m going to try to clean up my parallax code and get that either posted or emailed to you……..