I just wanted to thank you for one of the only ; if not the only ; video on how floppy drives work at the lowest level . Your set of 3 videos made my day and I’ll watch them again to be sure to understand all of it. I’ll also hook up a floppy on my oscilloscope just as you did . Subscribing !
Great! Hopefully I'll get to make one reading with a 6502 soon - I've planned the circuit which is a fairly simple extension, just need a little time to build it and video it
This is great! Real low-level stuff! I worked on hard and floppy disk controller designs in the 80's and so I have a good awareness of the various fields in the data stream from the drive, but even then there was a much higher level of integration than this. I am impressed that you have this working reliably with such a low parts count using standard logic parts.
Thanks for the comment, I appreciate it. I too thought it would be more complex than this, as I know things like the 8271 were pretty widespread at the time, and also quite expensive. It'll be interesting to add write support and get it hooked up to a more 80s style CPU.
@@GeorgeFoot Interesting? Certainly. Challenging? Probably. Writing adds a whole new dimension. Get the timing wrong and you not only can't read what you wrote, you may have trashed everything else on the same track as well.
@@GeorgeFoot you can add this circuit through a 8255 in mode-1 for automatic latching. There is also a hack to make it work without DMA, to have a D-FF output connected to CPU's WAIT, the FF is set by CPU by one IN command and 8255 reset the FF by INTA, so data read/write loop can be very tight just 3 commands IN,IN, PUSH. /*SP must point into input buffer */
@@alexloktionoff6833 That's an interesting approach. I'm probably going to do it either through a 6522 or custom latch circuits - probably the latter as it's more interesting to design. The CPU will poll or service NMI interrupts like on the BBC Micro, at first, possibly with DMA later on.
@@GeorgeFoot agree with custom discrete chips it's more interesting. But it may become bloated - fd controller pcb may become same size as video-card. Z80 @ 3.5 MHz had just enough speed to poll /*to include test and conditional commands in the loop*/ for DD fd. Without sector buffering in fd controller NMI is too slow i'm afraid. Let's see ;)
The floppy controllers for the Ohio Scientific computers (among the cheapest of their time) were three simple parts: a PIA (6820) to move the head around and look for the index hole, an ACIA (6850) to read the serial data from the floppy, and a "data separator" which removed the clock pulses from the data pulses. It didn't bother using sectors or cylinders. Every track on the floppy was like a fixed length of tape. You just wrote or read tracks.
That's interesting, I considered just writing data to the tracks in my own format to keep it simple. I guess any time you had to update any data you rewrote the whole track?
@@GeorgeFoot That's exactly what you did with OSI's bare bones OS65 and that's why you needed a system with at least 16K of RAM. I think we had 320K on a 5 1/4 inch floppy so you had to read the entire 8K track into memory. In fact I never even learned how sectors worked. People wrote better OSes for OSI computers so maybe someone figured out how to emulate sectors which I guess would be reading and then writing at precise times. I don't know if you can even do this in software.
You seem like an experienced man, and I was wondering if you would help me hot wire my microcontroller up to a usb on my breadboard. its a PIC16F628A microcontroller, but when i hook it up, my pc gets the 'device descriptor request failed'. is there a way to mayby 'create' a fake dds (device descriptor signal, that's what I call it at least) or mayby to get a software that will communicate with the chip? Keep in mind I have no equipment, just some breadboards, wires, old device circuits, and a usb to usb hotwires cable (and some rom chips, pal chips, shift registers, and some other chips) any out-of-the-book knowledge you might have? any help from anyone would be nice.
I did a search and just in case you missed it, this video seems to be exactly what you need. ruclips.net/video/HbQ6q3skZgw/видео.html In simple terms, you can probably do what you want using a USB library for your microcontroller, but you may be better off using a different microcontroller which has hardware USB support built in.
@@melkiorwiseman5234 ok thanks for the response, the video might help me (when i understand it better) but for now thanks. Using a different microcontroller is a great idea (yes i thought of it before) but I have (as of now) only cash and live nowhere near a chip store, so ill have to wait for that one.
Hi George, how it is going? Anyway don't stop making videos, and please if you can make a video from scratch to how to access to 164kbit with 16 bit address
Haven't seen a new video from you for quite a while. Curious as to whether you've done any more work on this or any other project? I would love to see the fruits of your diligent research on this. In any case I hope things are well with you and I look forward to more videos!
Thanks! I did a bunch of planning for the next video on this, which will be hooking up to a 6502. I debated whether to use a 6522 as well, or go direct (going direct won), and sketching the circuit diagrams - I'm pretty confident it will work and allow loading data from the disc. That was all in December - but then I moved house and I haven't been able to actually get on with it since then! I'm hoping to get back to it soon, as the hard work is already done!
Yes you could do that. If you did it in a way that didn't require pausing the CPU - e.g. making the DMA happen in between CPU cycles like we do for video - then it would be beneficial as the CPU could get on with other things.
@@GeorgeFoot as a last stage what about putting the data from the 595s and storing the data in a sn74hc273? This would give the cpu time to read in data while reading a new byte from the disk.
Somebody commented a while back that you can use a UART to decode MFM at least into an intermediate form that can be fully decoded in software, very interesting
Interesting. I wonder if there is some device that can sample signal for example at 4MHz, save them and process whole bitstream by a software. Actually I'm not sure if modern osciloscopes can do this, I haven't use any in 20 years. I'm not sure if raspberry pi has capability of sampling signal into DMA buffer neither. It's interesting how floppy drives are simple, I guess with faster electronics it would be possible to have constant data density rather than fixed data throughput and store more on the outer tracks (it would just break compatibility with 1970s design)
A lot of modern minimal floppy interfaces do just record the bitstream, or the times between bits, especially when using microcontrollers like Arduino. I'm not so interested in that though because these days yes RAM and CPU power are cheap. I'm more interested in the older technology and what was possible in that era. CLV=constant linear velocity was used on CDs at least, maybe hard discs but I'm not sure. The difficulty is the effort of changing the rotation speed. These old drives just needed to be really good at maintaining exactly 300RPM. It must be harder to make something consistently maintain a variable speed.
@@GeorgeFoot I understand, for me as a software developer with signal processing background, I would choose SW approach. Hard drives or CD-ROMs faster than 4x have constant rotation speed. Hard drives have tens of zones with varying sectors per track so more data can be stored on outer tracks and data transfer rate is higher there. All defrag utilities are moving data towards start of the disc besides defragmenting files. I'm not sure if zones existed on MFM hard drives used till early 90s.
This is what devices like Super Card Pro\Kryoflux\Greaseweazle do. Most microcontrollers (including the atmegas) have dedicated pins that hook up to timers that can measure pulse timings (often called input capture). Take a look at Rob Smith's work;- amiga.robsmithdev.co.uk/history#background ruclips.net/video/OAswAoNLJhs/видео.html. Then there is also this that you may find interesting;- ruclips.net/video/ZgH6ov33ieg/видео.html
![Megan Thee Stallion - Mamushi (Remix) [feat. TWICE] [Official Audio]](http://i.ytimg.com/vi/5c0_u9PsrsQ/mqdefault.jpg)
These are great videos. George is so cool at this stuff. Im building it along with him and want to see a series on writing to the floppy.
I just wanted to thank you for one of the only ; if not the only ; video on how floppy drives work at the lowest level .
Your set of 3 videos made my day and I’ll watch them again to be sure to understand all of it.
I’ll also hook up a floppy on my oscilloscope just as you did .
Subscribing !
Glad you liked it! I'm trying to get things sorted out so that I can continue the series
Thanks for adding these videos in your channel. I only recently discovered them and I've had a good time watching them.
Great! Hopefully I'll get to make one reading with a 6502 soon - I've planned the circuit which is a fairly simple extension, just need a little time to build it and video it
I've always liked the challenging "maybe" gate.
This is great! Real low-level stuff! I worked on hard and floppy disk controller designs in the 80's and so I have a good awareness of the various fields in the data stream from the drive, but even then there was a much higher level of integration than this. I am impressed that you have this working reliably with such a low parts count using standard logic parts.
Thanks for the comment, I appreciate it. I too thought it would be more complex than this, as I know things like the 8271 were pretty widespread at the time, and also quite expensive. It'll be interesting to add write support and get it hooked up to a more 80s style CPU.
@@GeorgeFoot Interesting? Certainly. Challenging? Probably. Writing adds a whole new dimension. Get the timing wrong and you not only can't read what you wrote, you may have trashed everything else on the same track as well.
@@GeorgeFoot you can add this circuit through a 8255 in mode-1 for automatic latching. There is also a hack to make it work without DMA, to have a D-FF output connected to CPU's WAIT, the FF is set by CPU by one IN command and 8255 reset the FF by INTA, so data read/write loop can be very tight just 3 commands IN,IN, PUSH. /*SP must point into input buffer */
@@alexloktionoff6833 That's an interesting approach. I'm probably going to do it either through a 6522 or custom latch circuits - probably the latter as it's more interesting to design. The CPU will poll or service NMI interrupts like on the BBC Micro, at first, possibly with DMA later on.
@@GeorgeFoot agree with custom discrete chips it's more interesting. But it may become bloated - fd controller pcb may become same size as video-card. Z80 @ 3.5 MHz had just enough speed to poll /*to include test and conditional commands in the loop*/ for DD fd. Without sector buffering in fd controller NMI is too slow i'm afraid. Let's see ;)
Great stuff! Keen to see you reading a program from disk and running it! 👌
I can't blame you for using an external counter. It's much easier to set up than the Atmega counter peripheral.
Yes, I also want this to work with other CPUs in the future
Well done! I thought you might need a faster microcontroller; but a few more chips made it work!
I'm actually surprised it didn't require more than this - but it's a good sign for hooking up to a 6502 later on!
The floppy controllers for the Ohio Scientific computers (among the cheapest of their time) were three simple parts: a PIA (6820) to move the head around and look for the index hole, an ACIA (6850) to read the serial data from the floppy, and a "data separator" which removed the clock pulses from the data pulses. It didn't bother using sectors or cylinders. Every track on the floppy was like a fixed length of tape. You just wrote or read tracks.
That's interesting, I considered just writing data to the tracks in my own format to keep it simple. I guess any time you had to update any data you rewrote the whole track?
@@GeorgeFoot That's exactly what you did with OSI's bare bones OS65 and that's why you needed a system with at least 16K of RAM. I think we had 320K on a 5 1/4 inch floppy so you had to read the entire 8K track into memory. In fact I never even learned how sectors worked. People wrote better OSes for OSI computers so maybe someone figured out how to emulate sectors which I guess would be reading and then writing at precise times. I don't know if you can even do this in software.
You seem like an experienced man, and I was wondering if you would help me hot wire my microcontroller up to a usb on my breadboard. its a PIC16F628A microcontroller, but when i hook it up, my pc gets the 'device descriptor request failed'. is there a way to mayby 'create' a fake dds (device descriptor signal, that's what I call it at least) or mayby to get a software that will communicate with the chip? Keep in mind I have no equipment, just some breadboards, wires, old device circuits, and a usb to usb hotwires cable (and some rom chips, pal chips, shift registers, and some other chips) any out-of-the-book knowledge you might have? any help from anyone would be nice.
I did a search and just in case you missed it, this video seems to be exactly what you need.
ruclips.net/video/HbQ6q3skZgw/видео.html
In simple terms, you can probably do what you want using a USB library for your microcontroller, but you may be better off using a different microcontroller which has hardware USB support built in.
@@melkiorwiseman5234 ok thanks for the response, the video might help me (when i understand it better) but for now thanks. Using a different microcontroller is a great idea (yes i thought of it before) but I have (as of now) only cash and live nowhere near a chip store, so ill have to wait for that one.
Hi George, how it is going? Anyway don't stop making videos, and please if you can make a video from scratch to how to access to 164kbit with 16 bit address
You could have used 2 free inverter gates to clean up the diode wired OR signal ;-)
Haven't seen a new video from you for quite a while. Curious as to whether you've done any more work on this or any other project? I would love to see the fruits of your diligent research on this. In any case I hope things are well with you and I look forward to more videos!
Thanks! I did a bunch of planning for the next video on this, which will be hooking up to a 6502. I debated whether to use a 6522 as well, or go direct (going direct won), and sketching the circuit diagrams - I'm pretty confident it will work and allow loading data from the disc. That was all in December - but then I moved house and I haven't been able to actually get on with it since then! I'm hoping to get back to it soon, as the hard work is already done!
Isn't this where DMA is used? A faster IO device can take over the busses and write or read from the fast device without making the cpu sweat.
Yes you could do that. If you did it in a way that didn't require pausing the CPU - e.g. making the DMA happen in between CPU cycles like we do for video - then it would be beneficial as the CPU could get on with other things.
@@GeorgeFoot as a last stage what about putting the data from the 595s and storing the data in a sn74hc273? This would give the cpu time to read in data while reading a new byte from the disk.
What would hapen if you use UART to store data, instead of FM or MFM? That way you can use a simple microcontroller to read and write.
Somebody commented a while back that you can use a UART to decode MFM at least into an intermediate form that can be fully decoded in software, very interesting
excellent
Great upload video! 👍 👍stay connected! 😍Like 👍👍👍
Interesting. I wonder if there is some device that can sample signal for example at 4MHz, save them and process whole bitstream by a software. Actually I'm not sure if modern osciloscopes can do this, I haven't use any in 20 years. I'm not sure if raspberry pi has capability of sampling signal into DMA buffer neither. It's interesting how floppy drives are simple, I guess with faster electronics it would be possible to have constant data density rather than fixed data throughput and store more on the outer tracks (it would just break compatibility with 1970s design)
A lot of modern minimal floppy interfaces do just record the bitstream, or the times between bits, especially when using microcontrollers like Arduino. I'm not so interested in that though because these days yes RAM and CPU power are cheap. I'm more interested in the older technology and what was possible in that era.
CLV=constant linear velocity was used on CDs at least, maybe hard discs but I'm not sure. The difficulty is the effort of changing the rotation speed. These old drives just needed to be really good at maintaining exactly 300RPM. It must be harder to make something consistently maintain a variable speed.
@@GeorgeFoot I understand, for me as a software developer with signal processing background, I would choose SW approach. Hard drives or CD-ROMs faster than 4x have constant rotation speed. Hard drives have tens of zones with varying sectors per track so more data can be stored on outer tracks and data transfer rate is higher there. All defrag utilities are moving data towards start of the disc besides defragmenting files. I'm not sure if zones existed on MFM hard drives used till early 90s.
This is what devices like Super Card Pro\Kryoflux\Greaseweazle do. Most microcontrollers (including the atmegas) have dedicated pins that hook up to timers that can measure pulse timings (often called input capture).
Take a look at Rob Smith's work;-
amiga.robsmithdev.co.uk/history#background
ruclips.net/video/OAswAoNLJhs/видео.html.
Then there is also this that you may find interesting;-
ruclips.net/video/ZgH6ov33ieg/видео.html