Has anyone written a 6502 driver for loading data from a standard 1.44 MB DOS formatted disk?

_________________
Cat; the other white meat.

As there is no standard diskette drive hardware that interfaces to the 6502 (sans the Commodore drives), you would need to define some hardware interface, like a Western Digital FDC chip. I built up a WD2797 board back in the 80's for a Vic-20 and wrote BIOS code that could select a drive, reset it, seek to a track, read/write sectors, etc. But the older WD chips only supported density and data rates that would equate to a 720KB DOS formatted diskette. Note that Commodore's 1581 drive used a WD177x chip and changed the physical format for an 800KB diskette, but the FDC was not designed to run at double the data rate required for a 1.44MB diskette (IBM eventually doubled it again and released a 2.88MB diskette drive and media on certain PS/2 systems). Note that all of this assumes 3.5-inch diskette drives/media.

Additional code would be required to use the old FAT filesystem beyond the ability to access data at a sector level from the diskette. The old DOS format used for diskettes was also based on a 512-byte data field per sector and a 12-bit FAT table entry. There are parameters in the Boot sector that define the media, i.e., heads (sides), tracks, sectors per track, etc.

I think there was an updated WD1772 version used by Atari that would allow the double data rate required for the 1.44MB format. The chip in Commodore's 1581 drive can (technically) support a 720KB format, but you would still need additional code to support the FAT filesystem.

_________________
Regards, KM
https://github.com/floobydust

floobydust hit Submit before I did, and now I need to edit my post.

I had the same question: are there any 6502 machines that have a suitable floppy interface? Usually a floppy interface is based on an FDC (Floppy Disk Controller) chip. The driver talks to the FDC which in turn connects to the actual drive, regarding which there may be a degree of flexibility. For example back in the day I used a WD2797A FDC which attached to a 5.25" 360K drive; then later I added a 3" 1.44M drive. (8" drives were also a possibility, but I didn't need to go there, thank goodness!) This was for a homebrew Z80 system.

Maybe the A suffix explains why my FDC (WD2797A) managed 1.44 but floobydust's (WD2797) didn't; I don't know. (What I do know is the datasheet wasn't at all helpful in regard to 1.44 drives; I had to figure out a lot of it for myself. )

I guess Woz bent the rules with the interface he designed using Group Code Modulation. AIUI the usual FDC was replaced by a circuit using discrete logic. But again the driver talks to the interface, not the floppy drive itself.

DOS formatting is something that you'd manage in a higher layer of the driver. At the bottom level you're just reading and writing individual sectors, based on their physical address (ie; the track, side and sector).

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I have built a WD2797 based floppy disk controller for the Apple IIplus. Interfaceing a WD2797 or a WD1772 to the 6502 is very simple. As far as I know the WD2797A has an improved data separator. All WD279x versions support 8" MFM drives, which have the same datarate as 1.44Mbyte 3 1/2" floppies (500kbps). The WD1772 only supports 250kbps data rate but newer versions can be overclocked to support 500kbps datarate. The WD1772 has the advantage of a built in fully digital data separator, nothing to adjust, nothing to calibrate.

Note that when you poll the FDC (i.e. don't use DMA to transfer data between the FDC and Memory) a 500kbps datarate for 1.44Mbyte floppies requires a 6502 clocked with 2MHz at least.

Here some info regarding GCR (Group Code Recording) used in the Apple. Actually Woz did not bent any rules, he just use more brain than hardware for his design.

The GCR format of the Disk-II actually is just another way to write the data track to the floppy drive. Electrically there is no difference in the read/write logic of a MFM and an GCR diskette drive. It's just that the floppy drives for the PC and the Apple use a different interface. The major difference is that the PC drives use a DIR, STEP to position the read/write head on the appropriate track where as the Apple II directly controls the phases of the stepper motor that is used to position the read/write head. Also the number of supported tracks is different, on a PC the standard was 40 tracks and for the Apple it was 35 tracks. But you have to know that when DISK-II was released 35 tracks was the standard for 5 1/4" drives and 77 tracks for 8". It was only later that 40/80 tracks became standard. But floppies are much older than this. The RD and WR signals are not different. Woz actually was using "naked" floppy drives from Shugart and what he did was designing his own minimal read/write electronic, actually the analogue part was more or less the same used in Shugart drives. He completely omitted the logic for stepping and only added the drivers for the stepper motor. He also omitted the Track 0 detection to safe the costs for the photoelectronic detector. Everything related to this was handled in software. The genius of Woz was all put into the controller. This is actually a very clever statemachine that is controlled by a small PROM (256bytes) and the signals from the CPU and the floppy drive. A very good and detailed documentation is available in Chapter 9 of Jim Slathers book Understanding the Apple IIe. GCR is actually the far more advanced way to write data on a magnetic media than FM or MFM. FM and MFM requires a very sophisticated data/clock separator which at the beginning was built using analogue circuits and required expensive tools to calibrate. GCR uses none of them. It just works. Only later with the enhancements of chip design and support for higher clock rates it was possible to create fully digital data/clock separators for MFM.

One thing I'm curious, why do you want to use floppies?

Thanks everyone for the detailed information!



I adore vintage hardware. All of it. Some might argue that 1.44 MB floppies aren't all that vintage but floppies in general are.

I'm just doing some background research at the moment. I'm building a very basic 65C02 SBC that will have lots of room for expansion. I have a long list of hardware projects I want to accomplish. One of those is to interface my SBC to a floppy drive. Even old drives like the 1541 and DISK-II, etc.

I even want to interface to cassette tape. If I had access to a punch card machine, I would do that too.

_________________
Cat; the other white meat.

Yes, the WD2797 would support 500Kb data rates. I still have my old controller board (just found it), It was setup for 4 drives on the standard 34-pin cable config. I added logic to select single or double density and the clock rates as well. As noted it had an integrated data separator and required a few external parts to function. The 1.44MB format was 18 sectors per track of 512 bytes each, doubled-sided with 80 tracks. The sector interleave defaulted to 1, i.e., sector IDs were sequential from the index pulse as 1,2,3,4,5,6---,17,18. As my controller was built to connect to the Vic-20, I used the SO pin (set overflow input on the 6502) for data transfers so the 1.0227MHz CPU could keep up. This required some small modifications on the expansion connector. I also had a an additional expansion card that contained a 6551 async port, 8KB of RAM or ROM at the cartridge address, 1KB of SRAM at one of the empty I/O ranges, a battery backed RTC and I/O decode. The floppy controller plugged into one of the two expansion slots on this board. I used the 1KB of SRAM for sector buffers.

The FM/MFM encoding was created by IBM earlier for the 3740 format (FM) on an 8-inch floppy and MFM later with the 34 format also on 8-inch drives. I later had an IBM 72MD (magazine drive from a System/38). This held two 10-diskette magazines and 3-single diskettes. It also spun the diskettes at double speed, 720 RPM vs 360 RPM. Unfortunately. I never got around to hooking it up... it was a massive assembly and extremely robust, albeit the "picker assembly" did give us problems from time to time.

Commodore also used a bare mechanics drive and GCR encoding with the 1541 drive. They also opted to nix the track 0 sensor. This was a dumb idea... as a drive reset would start with 40 seeks to track zero... resulting in hammering the stepper motor most of the time. It would eventually fail as the magnetic rotor was pressed onto a steel shaft that was knurled. The magnet donut was a cheaper and softer material and would give out over time from the constant hammering. I wound up doing repairs on dozens of these drives where I would remove the cover on the stepper, zip a groove into the magnet donut and epoxy the donut to the shaft. Once realigned, they didn't fail again.

While the GCR and custom electronics worked for Commodore and Apple, even Commodore eventually went with a more industry standard approach with the 1581. This was a superior drive to the 1541. Much higher capacity, better reliability and even faster transfer rates over the serial bus with older machines like the Vic-20 and C64. I still have a couple 1541 drives and a couple 1581 drives. I'm still tempted to interface them to my little 65C02 board setup.... just need the time

Why use a floppy these days?? Well, retro data storage for a retro processor based machine perhaps. Personally I have over a thousand 3.5-inch floppies, and probably a few hundred 5.25-inch floppies. I might even be able to find some old 8-inch ones as well. It's a well sorted and reliable technology that is simple to interface. Having 1.44MB of 6502 code/data that slips inside your pocket is still kinda cool

_________________
Regards, KM
https://github.com/floobydust

If you ever want to sell any of those, let me know.



Bingo



If you ever want to part with some of those, I would also be interested.

_________________
Cat; the other white meat.

Haha... I still have my original Vic-20, C64, 1541 and 1581, all bought new. These are keepers... I picked up some backups over the years however. Both the Vic-20 and C64 have been fully socketed for every chip, so keeping them running shouldn't be too difficult, unless one of the proprietary MOS chips decides to go out. I recently re-capped the Vic/C64 with all new electrolytic caps... as they can be a problem over time.

Also, you can still get the WD1772-02-PH chip... pretty sure this one handles the 500Kb rate. I would recommend building with one of these for a controller with fewer parts. You can find the 1581 schematic for a guide but I would build it differently than Commodore did.

_________________
Regards, KM
https://github.com/floobydust

Not to toot my own horn, but I'm an avid collector and have nearly 70 vintage computers. Including some VIC-20's, C64's, etc.

But for me, they're all keepers! LOL

I saw that Mouser actually has some floppy controllers. That's pretty cool. I was wondering if I should use a micro-controller between the 65C02 and the floppy drive but it appears there's still chips available.

_________________
Cat; the other white meat.

Cool... I still have a lot of systems about... PS/2s... a model 95 server, some biscuit PCs, a couple Timex/Sinclair 1000's, a Syntertek Sym-1 with full docs plus a lot of other gear. I dumped at least a hundred pounds of boards, controllers, cables, drives, power supplies, etc. 10 years ago, but could do the same a couple more times if needed.

I saw the floppy controllers on Mouser. There's only one that makes sense and is a derivative of the Nec 765 chip that was used in the IBM PC line. These are a bit more involved for programming (vs the WD FDC line) IIRC, as I wrote a fair amount of code for doing special formats and analyzing media back in the 80's. It's also the only one that is compatible at 5V and supports the final 2.88MB format with the 1Mb data rate. For anyone looking to interface a floppy with currently available chips, I would likely opt for this one:

http://www.mouser.com/ProductDetail/Mic ... C37C78-HT/

_________________
Regards, KM
https://github.com/floobydust

I see it is only for nostalgic purposes. In this case I would start with a WD1772. This can be connected directly to the 6502 bus and you can directly connect the floppy drive. No further glue required for a single drive system. You only need a clock of 8 or 16 MHz for 250 or 500kbps datarate. The latter requires a 2MHz 6502 or you need some glue to use the trick with the SO connected to DRQ as floobydust did.

I went a little further with the repairs. At the time, I had access to the tool room at the company where I worked. So I made a small jig that fit on the table of a vertical milling machine. I would mount the stepper motor and sleeve assembly into the jig and find center. Next, I drilled a small hole through the sleeve and shaft, using a carbide drill and manually applied coolant (the shaft was around Rockwell 50C, too hard to be drilled with a HSS drill). That was followed by a carbide reamer to get the hole to exact size (0.125 inches, if I correctly recall). The final step was to press in a split spring pin. The pin positively locked the sleeve to the shaft, yet allowed future disassembly if needed.

Commodore's SFD-1001 was also noted for using the hammer technique of establishing track zero during disk formatting. However, that unit used a Panasonic DSQD drive mechanism, which was originally intended for use in minis and ruggedly built. Until I switched to the Lt. Kernal hard drive subsystem in mid-1987, my 8 bit C= machines were attached to two SFD-1001 drives, using several different types of IEEE-488 adapters. The SFD units were fast by Commodore standards, although not quite as fast as the 1581 when running with a C-128 in 2 MHz mode.

Somewhere in the Internet abyss, a copy program I wrote that does an exact disk-to-disk copy between two SFD units still exists—the program was called "SFD to SFD 128". It was written entirely in assembly language, except for the BASIC SYS instruction that started it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hi BDD,

Funny how we stumbled across similar problems. I was living in a tiny apartment with a wife and infant at the time. My workshop was the closet shared by the hot water heater and I had a dremel tool and my (IBM) service toolbag plus some of my older test gear and soldering equipment from my audio days. Funny definition of "a little further" no doubt.

The other funny thing is the copy program. Back in the mid-80's we announced ESDI drives for the PS/2 line. These were early drives that had onboard defect mapping and logical block addressing (pre-SCSI). The end result was 100% good media showing against the drive parameters. Over an afternoon, I wrote a hard drive copy program (Packcopy) which allowed cloning of hard drives regardless of the operating system (also in assembler for the PC). The interesting side effect was copying to a larger drive also worked due to LBA, as the sectors and heads mapped across. All that was required was to stretch the partition out to fill the rest of the drive. The code was limited to ~8GB due to the BIOS interface but was used for many years to clone drives for development, preloads for manufacturing, internal classroom training, site equipment, billable services to customers and BofA's bank branch rollouts across the US. An old coding buddy of mine wrapped a NetBIOS interface around it and using a bootable diskette, we had Packcopy that could clone drives across a network. We stopped supporting it long long ago but it was a staple internally for a long time and predated every other (hard) disk cloning software.

_________________
Regards, KM
https://github.com/floobydust

Pre-SCSI only in the sense that the ANSI X3.131 SCSI standard had yet to be ratified. However, X3.131 was little more than a formalization of SASI (Shugart Associates system interface), which had been developed in 1979. In 1981, NCR was the first major builder of minicomputer systems to utilize SASI to connect up mass storage, which feature gave them an edge on their competitors when it came to I/O-bound performance. NCR also instigated the formalization of SASI as an ANSI standard, which came about in 1986.

Maxtor shipped the first ESDI (enhanced small disk interface) disks in 1984 as an alternative to the ST-412/506 units IBM was integrating into the PC-XT and PC-AT. ESDI could use the same cabling used with the ST-412/506 disks: a 20 pin data cable (one per drive) and a 34 pin common control cable. SCSI, of course, has always used only one cable: 50 pins with the "narrow" bus and 68 pins with the "wide" and LVD buses. The use of LBA (logical block addressing) to talk to ESDI disks was "borrowed" from SASI, which had LBA since inception.

So you can see that SASI/SCSI predates ESDI by several years. IBM was the only manufacturer to make significant shipments of ESDI drives, which was part of their failed attempt to regain control of the PC industry after Compaq, Packard-Bell and others started grabbing the lion's share of sales. By the latter 1980s IDE (or ATA) had taken over in clone PCs, as it was more economical to implement and used only one cable. IBM eventually saw the light and abandoned ESDI entirely.
It has been over 25 years since I last saw an ESDI drive. I last touched an ST-412/506 disk in 1994.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Good historical info... I was merely posting from an IBM historical view. The clone machines were certainly cheaper but they were also much more cheaply made. Junky keyboards, flimsy chassis, etc. but again in retrospect, the technology started to leapfrog at a rapid pace and making machines to be reliable and robust seemed pointless. In the end, IBM sold off an industry it created. I say created, because, like it or not, IBM's entry into the PC market legitimized it. This along with the massive influx in capital (to Intel and Microsoft mostly) allowed both companies to mature their technology and the PC industry boom took off. 'nuff said.

Back to the thread at hand.... I would agree with CBSCPE that the WD1772 would be a good choice to add a diskette to a 6502 system. I've done some research and it turns out that WD made an improved version of the chip, namely the WD1772-PH 02-02. This is the FDC that Atari used in their later machines and could be clocked with a 16MHz oscillator and reliably run at 500Kbps transfer and hence support the 2MB (unformatted) 3.5-inch floppy standard. It also had an improved data separator. I would also recommend obtaining the older Teac FD235-HF diskette drive as these are very reliable and have good specs and tolerance.

You still need to add some external logic to interface the WD1772 to the diskette drive and also handle some additional lines, like head select and media change as the FDC doesn't handle them. Overall, I still like the approach of the Commodore drive(s) where the intelligence is in the drive. Looking at the WD177X datasheet, it would appear that you're going to be limited to a 4MHz CPU clock unless you use more hardware to insert some wait time when accessing the FDC. I still like the idea of building a 1581-style drive but with increased capacity, handling additional formats and a much faster data transfer rate. I don't think it needs to compatible but the basic functions with an on-board filesystem would be nice and saves more memory for the system accessing the drive.

_________________
Regards, KM
https://github.com/floobydust