Home » RBC Forums » General Discussion » A Z80 project or a USB Floppy Disk Controller like the old Sony? (A retro project I'm considering.)
| A Z80 project or a USB Floppy Disk Controller like the old Sony? [message #10512] |
Tue, 21 November 2023 08:05  |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
I have two projects, one more than I have time for.
Project 1). A small Z80 project about something I suggested on alt.os.cpm long ago to compress a *modified* CP/M into a tiny-page bank at the top of the 64KB page. It used a simple TTL circuit to detect a fetch from the high N bytes of memory, where N is also the number of banked-pages. M would be the size of each bank-page. So M*N would be large enough to hold the *modified CP/M code MINUS the N bytes of trigger area on the top of each page.
EXAMPLE: If there were 16 bank-pages, the top of each page would contain this 16 byte piece of code:
The trigger is a fetch from address FFFxh, The next banked-page is loaded from address A0:A3.
;automatic banked-page changes by selecting a fetch from one of then address bytes
;load HL with the address within the next banked-page that executes next
FFF0: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 0h, 01d at address (HL)
FFF1: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 1h, 02d at address (HL)
FFF2: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 2h, 03d at address (HL)
FFF3: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 3h, 04d at address (HL)
FFF4: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 4h, 05d at address (HL)
FFF5: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 5h, 06d at address (HL)
FFF6: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 6h, 07d at address (HL)
FFF7: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 7h, 08d at address (HL)
FFF8: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 8h, 09d at address (HL)
FFF9: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page 9h, 10d at address (HL)
FFFA: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page Ah, 11d at address (HL)
FFFB: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page Bh, 12d at address (HL)
FFFC: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page Ch, 13d at address (HL)
FFFD: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page Dh, 14d at address (HL)
FFFE: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page Eh, 15d at address (HL)
FFFF: E9h jp (hl) ;1b1c4t ;fetch here to go to banked-page Fh, 16d at address (HL)
In the example above, either each page would have the same 16 bytes at the top of each page, or the CPLD could just map one page for that portion of memory, which would allow the other 15 pages to have 16 bytes of R/W rams space there. Those 15 pages could not put code in those 16 bytes because it would trigger an unintended banked-page change.
NOTE: The TPA can change or swap BIOS portions by uses a 'jp (hl)' that triggers the banked-page but the HL address returns to the TPA routine's next instruction. Examples would be initializing the banked-pages or swapping the BIOS to read/write another type of floppy disk.
Project 2). A modular floppy disk controller attached upstream via a USB serial cable. For my configuration that would likely be a Raspberry Pi upstream. Each needs to be able to support {8",5.25",3.5"} drives of many possible formats.
What they do with the drives depends on the Variants below:
Variant #1: I want to design my own USB-Serial Floppy Disk Drive conceptually like the SONY USB Floppy Disk Drive. However, my design needs download code to support the various {8",5.25",3.5"} floppy drives of many possible formats. It needs to read the drives to possibly identify the format, but that determination and table lookup should be handled by the upstream computer, which would likely result in the upstream computer downloading the code for that drive and format.
Variant #2: I need a multi-station floppy disk system to efficiently image my collection of floppy disks for archival. This Variant design is a USB serial Floppy Disk Controller board (not a FDC chip) that can control several drives concurrently and support a quick swap of connections. It needs to be able to multitask jobs-in-progress for several drives including the positioning to target-track phase and the track's flux timing phase of steaming the track's READDATA# signal. It needs to hold all necessary buffers awaiting upload to the upstream controlling computer.
[Updated on: Fri, 24 November 2023 09:15] Report message to a moderator |
|
|
|
|
|
|
|
| Re: A Z80 project or a USB Floppy Disk Controller like the old Sony? [message #10516 is a reply to message #10513] |
Sun, 26 November 2023 09:55  |
jayindallas
Messages: 110
Registered: June 2021
|
Senior Member |
|
|
Andrew Lynch wrote...:
"...been numerous runs at a USB to floppy drive interface. I think it is long overdue..."
The USB Floppy Disk Drive (FDD) aspect came up unexpectedly during my planning for the larger floppy image-archiving project. I have too many floppies to archive one-by-one; I need to be imaging several floppies at a time.
I need to program a RPi-computer to:
(1) orchestrate the multi-tasking I have to do to maintain flow,
(2) to download the correct software into the FDC-Module for the FDD and Disk type(s) its handling and
(3) manage the track images until they can be bundled and transferred by LAN to a PC for complete disk-image-formatting, storage and organization.
At the human-labor end of this system, I need to: (1) swap disks, (2) be able to quickly swap drives, sometimes to keep clean R/W heads in action and sometimes to switch drives types for a batch of compatible floppies.
A USB cable from the up-link computer to the floppy disk controller (FDC) module keeps the setup simple. I also need to add a FDD-Patch-Panel between the FDC-module and the FDD(s) to change ribbon cable and power hookups near the FDD end, leaving the FDC-Module untouched and undisturbed.
--(LAN)--| COMPUTER |--(USB)--| FDC-module |--(34-pin-Shugart)--| FDD-Patch-Panel |--(34&50-pin Shugart)--| FDD(s) |
DUH! That's almost a Sony USB Floppy Disk Drive but more flexible; something useful for hobbyists.
| COMPUTER |--(USB)--| FDC-module |--(34&50-pin Shugart)--| FDD(s) |
Andrew Lynch wrote...:
"...skip the actual CPU and FDC approach and reimplement the FDC function on an MCU..."
I agree. When a MCU's software is fast enough for realtime hardware emulation, it adds the advantage of software flexibility and virtual expanded FDC features, that a hardware solution cannot match. It might also allow me to emulate the hardware data-separator function so it can be more tolerant of FDD rotation speeds. You don't want to trash a disk simply because it was written on a FDD that was too far out of rotational specification to read.
Andrew Lynch wrote...:
"...My advice would be to go USB to the 34-pin Shugart Floppy interface and let the operator connect their own floppy drive..."
I agree completely. External drives add powerful flexibility, particularly when more than one FDD type and disk format is connected.
A lot of the floppy controller boards in the vintage age, that supported both 34-pin and 50-pin cables, used signals from the 34-pin Shugart interface and connected them to the equivalent pins on the 50-pin connector and not adding support for additional controls available in the 50-pin interface; even I did that. Examples: my Versa-Floppy-Winchester III, the standard Versa-Floppy II, Ciarcia's SB-180, the Japanese MSC LAT-1, Xerox 820 and others.
My prior work on this project included a survey of vintage systems' and boards' schematics that supported both 34 and 50-pin Shugart cables. Its in a spreadsheet somewhere on a PC I haven't powered up since my recent move.
Andrew Lynch wrote...:
"...seems to be special interest in 5.25" floppy drives..."
I was unaware of that. It makes sense because there are a lot of viable 5.25-inch floppies around.
I have a special 5.25" floppy disk rescue task from the 1980s. In 1983 I bought three surplus Xerox 820 motherboards for $50 each, they were manufactured in nearby Addison, Tx. I build a somewhat frankstein system around each, two using 5.25-inch and one system using 8-inch drives. I later figured out that by changing about 8-16 bytes in the Xerox 820's EProm, it could use 5.25" DSDD 80-Track drives, but it still had a single density FDC so I only got 4x capacity per disk. I still have those 4x-disks and can image them, but no system can read them.
In any case, first make an image-format file from all of them.
(1) Recreate my 1984 Eprom-hack and implement it on a Xerox 820 I acquired since and use them there, or
(2) Write software to convert the image-format into another standard or defineable computer format, then run it on another computer.
(3) Or both (1) and (2).
I'll probably do both. Option (1) is quicker and allows me to implement it on my Xerox 820. Option (2) would be vary useful and similar to some software I've done on IMD image-formats; thus something capable, but just taking more time. This exercise parallels some User Group IMD files I have that would be more useful if I converted them to a different image-format before transferring it to a new disk.
If I'm going to do these things above, working on the FDC-module project would be more productive than my Z80 project.
I've done programming work using the IMD format. Back in 2019, I wrote a program to sequence through my large collection of IMDs archives and had it identify images that likely supported CP/M on them, and even some IMDs that HAD CP/M loaded on the disk tracks. The last thing I did on that was scanning the IMDs that were previously classified CP/M versions, to tally the different {head/tracks/sectors/sector-size} formats. I ran those mutli-file tasks from a DOS batch file that handled traversing directories, finding IMD files and unzipping zipped IMD collections, then calling my IMD-extractor software with parameters, on each IMD file as available and appending the IMD-extractor's reports into an accumulating report text file.
So I have C++ code for creating and extracting IMD format already. It would be my choice for converting disk-images into formated disks. Maybe with output disk-format selection and format definition... best handled in the computer module instead of the FDC-module. All the FDC-module needs is one disk image-format downloaded through USB to write the disk.
scruss wrote...:
"...look at the work already done on the Adafruit Floppy project..."
Nah... I did this type of design work in the early 1980s, so I'm comfortable with all aspects of this project. I've even helped people out on doing projects in this technical area over the years. I'm primarily doing it for my own enjoyment and secondarily because I need the end result of his project and prefer the ability to add my own custom design choices. I've done a lot of ground work, analysis and design on this project years ago, but put it aside during a period of family's health matters. Now I just need to update it a little and have some fun! :)
I agree with you on the selection of the RP2040, but not the 5V tolerant aspect. I've been doing a RP2040 project too and I agree that its a good pick for hobbyist builds. The price and modularity, of a Raspberry Pi PICO/RP2040 are fairly unbeatable for budget-minded end-users.
scruss wrote...:
"...don't see that the core project is looking at 8" drives, but someone, somewhere will be trying it...."
I think I just made that official... :)
[Updated on: Tue, 28 November 2023 15:10] Report message to a moderator |
|
|
|
Current Time: Tue Jul 15 12:44:09 PDT 2025
Total time taken to generate the page: 0.00822 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
