This is brilliant, thanks! I love the very clear explanation of the raw data, I've never looked at it before but I've made 2 different floppy circuits, one was with a real WD1772 and a PIC implementing a mass storage device and the other was on a tiny little machxo FPGA implementing a WD1772 with an SPI interface to an ESP8266.
Hi George, You have done a great job and I really appreciate all you have done. I am trying to use your circuits . I am going to review all your videos , circuits and software. I will probably use a z80 first then a 6502 bread board. I am currently using a fd55-gfr floppy and have the 74hc273 driving outputs to the drive . I just wanted to thank you for the effort you have put in.
Great work! Just on the topic of Gal's,I ended up using a 22v10 one in my VGA circuit, using it to detect the vync, hsync, blanking and do the mixing. It removed half a dozen or more glue logic chips.
Interesting, I looked at that in the past but couldn't see how you could do all the comparisons in one GAL as there aren't enough input pins. I had a solution in the past that used one GAL for vertical and one for horizontal but never really used it in a practical circuit.
@@GeorgeFoot I'm a bit new to it myself. I based mine on Slu4s, so only needed fairly limited nimber of bits, and most of horizontal you only need to check the first couple of digits, so I think I only needed to check 11 inputs all up. I really enjoy your videos, I appreciate how clear they are and how focused they are on what you're trying to achieve and explain *why* you choose to go a particular method.
Thanks for the feedback, always appreciated! Maybe I'll take another look at gals for syncing, but I'm pretty happy with the EEPROM solution, it seems ideally suited for a giant lookup table. Some folks on 6502.org have actually used serial EEPROMs for this, which is an interesting approach too - no need for counters!
Nicely done. Although it's a bit like using a sledgehammer to hit a flea, you could use a Raspberry Pi Pico's PIO to do everything (yeah, that's been the subject of my channel recently). However, I understand wanting to use vintage electronics to make it work. The Apple 2 disk drive made use of a prom and some electronic glue to allow the 6502 to do all the disk read, write, and control. If you can get the schematic; it might prove interesting. I converted a standard floppy drive to an Apple 2 drive by cutting a trace and adding a gate (but I don't remember what gate). Keep having fun!
@@GeorgeFoot Instead of the Pico, can't you just measure pulse intervals with the interrupt of any Micro, for example the one in the MEGA itself? I think the Pico is more of a sledgehammer than this with 2x133MHz 32 bit processor cores. Besides the pico is a pain-in-the-arse to work with in the Arduino IDE. Or alternatively, interface a µPD765 from NEC with the MEGA and let that chip do everything.... That is the way this was done back in the day.
Yes, I've since looked in more detail at how more traditional circuits work - chips like the 8271 still required a helping hand or two here. I believe they require you to supply a 125kHz signal (as opposed to 250kHz that I'm using here) and they decide internally whether this is marking the clock or data bits. It is similar in a way though.
Great work George I was wondering if you would consider making a pcb layout I would be very interested in supplying the products and components to your channel if possible many thanks for sharing 👍
I'm probably going to make a PCB at least for the ARM2 computer with some sort of video interface on the main board. I might do one for 6502 as well but I'm not sure exactly what I want to do with that, regarding resolution choice and bus interface.
I'm so glad to see your video on this! Are you aware of tools which have been a round for about 5-10 years that read and capture these flux transition pulses on all disks (agnostic of MFM , FM or any other encoding format?)? The Kryoflux is the oldest, then the SuperCard Pro and most recently the Greaseweazle. I've created several videos on my channel showing how the HxC decoding tool can interpret the flux transition pulses into data for the disks that you show here. I'd love to know if you know about these. They do basically what you've done here, but I am *fully supportive* of your exercise here to "reinvent the wheel" so to speak, because I believe there is HIGH value in sharing this level of technical detail. I don't believe that the makers of any of the devices I mentioned above have created any videos on TH-cam with the level of granular technical detail that you share here. Please, keep up the great work! I love it!!!
Absolutely! I used the Greaseweazle in a later video to copy useful data onto floppy disks, so that I could then read it back using my 6502 computer, and I think I watched your videos as well, I think you talked especially about Amiga copy protection, which was interesting as the Amiga isn't somethting I'm familiar with. The hook-up to the homebrew 6502 computer is my goal here, rather than to a PC, hence why I'm building an interface that's more in line with the legacy floppy drive controller chips from the early 80s. But I also learn most when I try to figure these things out for myself, and sometimes end up building things that work a little differently to the mainstream, which is nice too.
@@GeorgeFoot Ah, thanks for that update, George! Actually, while I've made several videos about flux disk capture, the Amiga format is never discussed by me, so that could have been any number of really smart people in the Amiga/Commodore space... I mostly focus on disks for systems that are nearly extinct, like the Convergent Technologies AWS, and MiniFrame. The machines that nobody but me makes videos about...and thus, "Forgotten Machines". Anyway, I LOVE your goal for a hook-up to the homebrew 6502 computer. Can't wait to see more about that! Keep up the great work here, and I'll follow along!
Is there info on the protocol of the Greaseweazle so you can control it low level? I think the program that comes with it is horribly written from a UX pov.
You can use a double latch, I.e have a one more latch triggered by shift registers then arduino can have up to 16 bits time to read /* 8 +/- 8 */ If you think about universal variant both for big and small CPUs, you can consider to connect shift registers to i8255 program channel A/B for I/O mode-1 to latch the values automatically. For small/slow CPUs there is a hack of adding a DDff to be set by out command and reset by INT from i8255 to speedup reaad/write without interrupts and even test and conditional loops
Yes, for the 6502 I'm probably going to use two 8bit D flip-flops to latch both data and clock. But I've also considered having the cpu read just the clock bits, and read again 8us later to grab the data bits when they've shifted along one step. It's fewer parts but more complex software.
Hi George. Great video. In the context of a typical disk- controller-microcomputer setup, does the drive controller do all the heavy lifting and present only the raw user data to the computer on the address bus/DMA, or is it typical for the computer's BIOS/kernel to do the removal of the data overheads (address marks/CRC/clock bits). I ask because I assumed if the computer asked for a sector read of, say 256 bytes, then memory only received 256 bytes of the actual user data.
It depends a bit on the system. With the 8271 floppy disc controller, pretty much everything is taken care of by the controller. It is actually a fairly complex microprocessor in its own right. The host system sends commands like "read 5 sectors starting from sector 3" and it will spin the disc, read sector headers to find sector 3, notice if it's actually on the wrong track and try to correct for that, and then present data to the host bus, signalling via a "DMA request" line each time a byte is ready (a bit like what I'm doing here). There's no buffering, so the host must consume the byte before the next one is ready. It automatically finds the next sector header and continues to read, so the host doesn't need much knowledge of the disc. The 8271 also checks and strips the CRCs. Writes are similar but backwards. Formatting is the only time the host really needs to know what's going on on the disc - it specifies a list of sector numbers, sizes, and gap sizes. That's as low level as it gets though. Other systems worked differently of course - Commodore's was very high level, more like a serial interface to a separate computer that reads the disc. I hear Apple's was lower level though, more like what I'm doing here.
I don't have any 74LS688s but I do have some 16v8 and 22v10 GALs, hmm. 22v10 might be enough to also count up to 16 and signal when each byte is complete after the address marks.
You can use flash rom simple 27512 from pentium m/b, similar like Woz did for Apple drive :) gal is much harder to get nowadays and not everybody can flash it…
Hate to rain on the complex parade, but a plain old UART already does clock sync. Sure it's once per word instead of once per data bit, but that's more than enough. Send the read data via a pulse stretcher into the Ardiuno UNO serial input. Configure the UART for 6 bit data word. Done. Pulse stretching is only needed on read data. Write data can be straight from the UART output. I have been accessing floppies that way in the 80s, using the basic 8250 UART from NatSemi back then. 4MHz for the baud input, word length to 6 bits, one stop bit. Yes, that simple.
So if I read your comment correctly, a Leonardo can interface the drive and read the data stream over its UART port? I say Leo, not UNO because it has a second UART for USB, so it is easier to put the data through. Why was it using 6-bit words and not 8-bit ones?
@@lovemadeinjapanAnything with a UART that can have a proper clock set (250kHz x 16) and a 6-bit word length. Why 6 bits? Because that word width syncs with the data encoding on the floppy track. After all you are sampling raw track data. It then has to be decoded into baseband/demodulated data. What the UART captures is what a digital oscilloscope would. It still has to be decoded. A floppy controller does this decoding in hardware.
Interesting, I considered that too! I figured you'd get about 15kHz of 8-bit samples. One revolution of the disc is one fifth of a second, so you'd need to step to the next track five times per second. How did it sound?
Wouldn't it be easier to just use a data separator chip like WD9216 (for data & clock separated) .. and a controller chip like FD1793 ?! .. please make a video explaining a similar setup like that ;) .. Good work!
@@lovemadeinjapan .. I don't think there are any old similar ones like that.. but maybe you can google similar chips .. I know some newer FDC chips have built in data-separators instead ..
This is brilliant, thanks! I love the very clear explanation of the raw data, I've never looked at it before but I've made 2 different floppy circuits, one was with a real WD1772 and a PIC implementing a mass storage device and the other was on a tiny little machxo FPGA implementing a WD1772 with an SPI interface to an ESP8266.
Hi George, You have done a great job and I really appreciate all you have done. I am trying to use your circuits . I am going to review all your videos , circuits and software. I will probably use a z80 first then a 6502 bread board. I am currently using a fd55-gfr floppy and have the 74hc273 driving outputs to the drive . I just wanted to thank you for the effort you have put in.
Great work! Just on the topic of Gal's,I ended up using a 22v10 one in my VGA circuit, using it to detect the vync, hsync, blanking and do the mixing. It removed half a dozen or more glue logic chips.
Interesting, I looked at that in the past but couldn't see how you could do all the comparisons in one GAL as there aren't enough input pins. I had a solution in the past that used one GAL for vertical and one for horizontal but never really used it in a practical circuit.
@@GeorgeFoot I'm a bit new to it myself. I based mine on Slu4s, so only needed fairly limited nimber of bits, and most of horizontal you only need to check the first couple of digits, so I think I only needed to check 11 inputs all up.
I really enjoy your videos, I appreciate how clear they are and how focused they are on what you're trying to achieve and explain *why* you choose to go a particular method.
Thanks for the feedback, always appreciated!
Maybe I'll take another look at gals for syncing, but I'm pretty happy with the EEPROM solution, it seems ideally suited for a giant lookup table. Some folks on 6502.org have actually used serial EEPROMs for this, which is an interesting approach too - no need for counters!
@@GeorgeFoot I don't know anything about PALs and GALs but what about a CPLD? The Xilinx XC95 series are my favorite as they're 5V tolerant.
Nicely done. Although it's a bit like using a sledgehammer to hit a flea, you could use a Raspberry Pi Pico's PIO to do everything (yeah, that's been the subject of my channel recently). However, I understand wanting to use vintage electronics to make it work. The Apple 2 disk drive made use of a prom and some electronic glue to allow the 6502 to do all the disk read, write, and control. If you can get the schematic; it might prove interesting. I converted a standard floppy drive to an Apple 2 drive by cutting a trace and adding a gate (but I don't remember what gate). Keep having fun!
Yes, the pico (and you) certainly sprang to mind! And that's interesting about the Apple drives, I knew they were different but never looked into how.
@@GeorgeFoot Instead of the Pico, can't you just measure pulse intervals with the interrupt of any Micro, for example the one in the MEGA itself? I think the Pico is more of a sledgehammer than this with 2x133MHz 32 bit processor cores. Besides the pico is a pain-in-the-arse to work with in the Arduino IDE.
Or alternatively, interface a µPD765 from NEC with the MEGA and let that chip do everything.... That is the way this was done back in the day.
Excellent description and theory. Interesting method for clock separation.
Yes, I've since looked in more detail at how more traditional circuits work - chips like the 8271 still required a helping hand or two here. I believe they require you to supply a 125kHz signal (as opposed to 250kHz that I'm using here) and they decide internally whether this is marking the clock or data bits. It is similar in a way though.
Great stuff! Excited to see where this goes, and happy to see you back on TH-cam :-)
This is insanely impressive!
Such a simple circuit. Wow.
Great progress! Eager to see the next steps.
dude this was so fun!
Great work George I was wondering if you would consider making a pcb layout I would be very interested in supplying the products and components to your channel if possible many thanks for sharing 👍
I'm probably going to make a PCB at least for the ARM2 computer with some sort of video interface on the main board. I might do one for 6502 as well but I'm not sure exactly what I want to do with that, regarding resolution choice and bus interface.
I'm so glad to see your video on this! Are you aware of tools which have been a round for about 5-10 years that read and capture these flux transition pulses on all disks (agnostic of MFM , FM or any other encoding format?)? The Kryoflux is the oldest, then the SuperCard Pro and most recently the Greaseweazle. I've created several videos on my channel showing how the HxC decoding tool can interpret the flux transition pulses into data for the disks that you show here. I'd love to know if you know about these. They do basically what you've done here, but I am *fully supportive* of your exercise here to "reinvent the wheel" so to speak, because I believe there is HIGH value in sharing this level of technical detail. I don't believe that the makers of any of the devices I mentioned above have created any videos on TH-cam with the level of granular technical detail that you share here. Please, keep up the great work! I love it!!!
Absolutely! I used the Greaseweazle in a later video to copy useful data onto floppy disks, so that I could then read it back using my 6502 computer, and I think I watched your videos as well, I think you talked especially about Amiga copy protection, which was interesting as the Amiga isn't somethting I'm familiar with. The hook-up to the homebrew 6502 computer is my goal here, rather than to a PC, hence why I'm building an interface that's more in line with the legacy floppy drive controller chips from the early 80s. But I also learn most when I try to figure these things out for myself, and sometimes end up building things that work a little differently to the mainstream, which is nice too.
@@GeorgeFoot Ah, thanks for that update, George! Actually, while I've made several videos about flux disk capture, the Amiga format is never discussed by me, so that could have been any number of really smart people in the Amiga/Commodore space... I mostly focus on disks for systems that are nearly extinct, like the Convergent Technologies AWS, and MiniFrame. The machines that nobody but me makes videos about...and thus, "Forgotten Machines". Anyway, I LOVE your goal for a hook-up to the homebrew 6502 computer. Can't wait to see more about that! Keep up the great work here, and I'll follow along!
@@ForgottenMachines Ah, hence the channel name! I'll check it out, thanks!
Is there info on the protocol of the Greaseweazle so you can control it low level? I think the program that comes with it is horribly written from a UX pov.
You can use a double latch, I.e have a one more latch triggered by shift registers then arduino can have up to 16 bits time to read /* 8 +/- 8 */
If you think about universal variant both for big and small CPUs, you can consider to connect shift registers to i8255 program channel A/B for I/O mode-1 to latch the values automatically. For small/slow CPUs there is a hack of adding a DDff to be set by out command and reset by INT from i8255 to speedup reaad/write without interrupts and even test and conditional loops
Yes, for the 6502 I'm probably going to use two 8bit D flip-flops to latch both data and clock. But I've also considered having the cpu read just the clock bits, and read again 8us later to grab the data bits when they've shifted along one step. It's fewer parts but more complex software.
Hi George. Great video. In the context of a typical disk- controller-microcomputer setup, does the drive controller do all the heavy lifting and present only the raw user data to the computer on the address bus/DMA, or is it typical for the computer's BIOS/kernel to do the removal of the data overheads (address marks/CRC/clock bits). I ask because I assumed if the computer asked for a sector read of, say 256 bytes, then memory only received 256 bytes of the actual user data.
It depends a bit on the system. With the 8271 floppy disc controller, pretty much everything is taken care of by the controller. It is actually a fairly complex microprocessor in its own right. The host system sends commands like "read 5 sectors starting from sector 3" and it will spin the disc, read sector headers to find sector 3, notice if it's actually on the wrong track and try to correct for that, and then present data to the host bus, signalling via a "DMA request" line each time a byte is ready (a bit like what I'm doing here). There's no buffering, so the host must consume the byte before the next one is ready. It automatically finds the next sector header and continues to read, so the host doesn't need much knowledge of the disc. The 8271 also checks and strips the CRCs. Writes are similar but backwards. Formatting is the only time the host really needs to know what's going on on the disc - it specifies a list of sector numbers, sizes, and gap sizes. That's as low level as it gets though.
Other systems worked differently of course - Commodore's was very high level, more like a serial interface to a separate computer that reads the disc. I hear Apple's was lower level though, more like what I'm doing here.
A single 74LS688 will catch any given byte (0xC7 etc) or maybe a GAL16v8 to catch multiple "magic" bytes, fun to learn easy to program. :-)
I don't have any 74LS688s but I do have some 16v8 and 22v10 GALs, hmm. 22v10 might be enough to also count up to 16 and signal when each byte is complete after the address marks.
You can use flash rom simple 27512 from pentium m/b, similar like Woz did for Apple drive :) gal is much harder to get nowadays and not everybody can flash it…
@@alexloktionoff6833 Even easier: SST 39SF010, still made new.
Hate to rain on the complex parade, but a plain old UART already does clock sync. Sure it's once per word instead of once per data bit, but that's more than enough. Send the read data via a pulse stretcher into the Ardiuno UNO serial input. Configure the UART for 6 bit data word. Done. Pulse stretching is only needed on read data. Write data can be straight from the UART output. I have been accessing floppies that way in the 80s, using the basic 8250 UART from NatSemi back then. 4MHz for the baud input, word length to 6 bits, one stop bit. Yes, that simple.
So if I read your comment correctly, a Leonardo can interface the drive and read the data stream over its UART port? I say Leo, not UNO because it has a second UART for USB, so it is easier to put the data through.
Why was it using 6-bit words and not 8-bit ones?
@@lovemadeinjapanAnything with a UART that can have a proper clock set (250kHz x 16) and a 6-bit word length. Why 6 bits? Because that word width syncs with the data encoding on the floppy track. After all you are sampling raw track data. It then has to be decoded into baseband/demodulated data. What the UART captures is what a digital oscilloscope would. It still has to be decoded. A floppy controller does this decoding in hardware.
@@absurdengineering would be nice to see how you can use a µPD765 with and Arduino as hardware decoder. Did you ever try that?
Great channel, happy sub.
A while ago I had attached a 3.5-inch floppy to a speaker.
Interesting, I considered that too! I figured you'd get about 15kHz of 8-bit samples. One revolution of the disc is one fifth of a second, so you'd need to step to the next track five times per second. How did it sound?
@@GeorgeFoot It sounded similar to a data cassette just less activity.
If you wedre in 90's you build your own floppy disk driver
Wouldn't it be easier to just use a data separator chip like WD9216 (for data & clock separated) .. and a controller chip like FD1793 ?! .. please make a video explaining a similar setup like that ;) .. Good work!
Do you know a similar chip to the WD9216?
@@lovemadeinjapan .. I don't think there are any old similar ones like that.. but maybe you can google similar chips .. I know some newer FDC chips have built in data-separators instead ..
@@ngtester6215 Weird enough the all-in-ones are way more expensive than 765+9216.
Next upnstore txt file andnread from floppy
🤣@12:02 Hungry?