wierd_w wrote on 2025-06-05, 14:25:
Quite true of our modern world, which is why USB floppies are 99% of the time made that exact way. ...
However, as vintage gear from the era when fdc controller chips were in mass production ...
Don't get me wrong, I wasn't suggesting an MCU instead of an FDC, but more "in addition to" as a means of
communicating with it.
I've built hardware that attached to and was controlled directly by the PC parallel port, and there are two main problems:
(1) Signal/Control lines
------------------------
There are 8 data lines, if you are lucky they are bidirectional
(many PPort output signals are "open collector" which means they pull-down
and when written high can be pulled down externally and some can be read from
the PC side)
There are 6 "output" signals: -STROBE. -AutoFD, -Init, -SLCTON, -IRQ and DataIn
There are 5 "input" signals: -ERROR, SLCT, PE, -ACK and BUSY
This isn't enough to interface to a device with multiple data "registers",
address lines and various selects.
One common way to "get around" this is to provide multiple output latches and
input buffers, and some sort of "addressing scheme" to access them - you might
think this could be done by attaching theie selects some of the "output" lines,
but consider that there is no actual select line to indicate when you read (or
write) a register - you need multiple output lines:
1 for each "register"
1 strobe for write
1 strobe for read
1 strobe for "status"
And a transaction becomes something like:
Write data FF (to read)
:1
Assert status strobe
Read status
Deassert status strobe
If status != READY repeat >:1
Write data
Assert write strobe
deassert write strobe
Write data FF (to read)
Assert read strobe
Read data
deassert read strobe
Which can be more than a dozen I/O operations just to perform one transaction
with the device - and it can be more operations if you need some sort of address latch
to handle more than 3 "things" --- which brings us to the second problem:
(2) Parallel ports are SLOW
---------------------------
(designed for interfacing with slow equipment over not-well-shielded cables
-- usually they include "wait states" to insure signal accuracy.
-- And you want things like storage "drives" to be fast!
The PC came out around 1981, and I expect PP connected storage was a few years
after that - there were indeed microcontrollers available before then, eg:
Intel 8048 1976
Intel 8051 1980
and there were others.
- I was building all kinds of microprocessor controlled "stuff" by then,
It definitely would have been doable.
You could take advantage that the MCU was fast and the PP was slow.
- Write data, drop select, write next data, raise select, repeat ...
And you could provide addressing through a command to the microcontroller,
which often has a couple dozen I/O lines "to spare".
----------------------------------------------------------------------------
This is a little EEPROM programmer I built many years ago - just happened to
find it a few weeks ago ... it "cheats", knowing that it's going to be
addressing the EEPROM sequentially, it uses a set of counter ICs... and
has only two addressing control Signals - Reset and Step(increment)
It still has to:
Write data
Raise programming signals
Drop programming signals
Assert STEP
Deassert STEP
- for each byte it programs
And it's still noticeably slower than a dedicated programmer! On the other hand
I built an PP connected EPROM emulator which used a microcontroller to
do PC<>emulator comms ... and it was faster!
