Tube🌿Timegot a new mini-project: this is the AMTRADE "The Real HD-Drive" which is a PC floppy drive with this board on the back enabling an Amiga to read high density floppy disks (1.75MB).
to get the Amiga to work with high density disks, the Commodore engineers took a little short cut and just spin the drive at half the normal RPM (150 instead of 300). this keeps the data rate the same, allowing the custom chip to remain unchanged.
this means you can't just use a standard PC floppy drive and expect it to work, even with a little PAL on the back. this drive has been modified.
as is typical in the Amiga community, the mods have been done in such a way to make them hard to reverse engineer. in this case, the rework wire is hair-thin magnet wire covered in silicone. try to remove the silicone, and it shreds the wire.
my guess is that it taps into the BA6986FS spindle motor driver and allows the PAL to slow it down when a high density disk is detected.
the schematic is pretty simple. looks like it does the pin swizzle for the disk change signal, creates the READY signal the amiga needs, but then it does some clever stuff with the index pulse. additionally, it uses the two reserved pins and the unused drive select line presumably to plumb the rework wires.
so presumably the way this works is that the two bodge wires hook into the clock signal from the controller chip to the spindle motor controller (pin 7 on this example). the motor controller derives the RPM from this signal, so the external PAL sneaks in an additional divide by 2 in order to half the RPM. not too shabby!
updated schematic. now that i know what all the pins do, it'll be much easier to reverse engineer the PAL. i'll take a crack at that tomorrow.
ran the outputs of DuPAL through Espresso to get the logic equations. i'm making a few assumptions so this probably has errors.
yeah these are wrong. i'm trying to dump it as a combinational 16L8 but i need to spend some time with the manual pin manipulation tool. the product terms depend on themselves in a bunch of places, creating flip flops.
ok it's got this weird state machine which, as it turns out, is used to *clock out a drive type value* using the drive select line as a clock and the ready pin as a data output!
yeah so that state machine clocks out 1010... continuously which corresponds with the ID value of AAAA AAAA; the Amiga interprets that as a high density drive.
there may have been a bad connection in the socket, i tried it again (also as a 16L8) and these equations look a lot better. i've started adding better net names.
another thing that i like to do is take a bunch of extra time to *understand* each product term. that involves using boolean algebra and DeMorgan's theorem to manually rearrange the terms.
here's the 2-bit counter that generates the drive ID code. it's a little asynchronous state machine. i just write up little notes like this as i figure things out.
and i've simplified the equations and gotten rid of excess terms about as much as i can. i understand what all the outputs do now, including the ones used to store intermediate states and never used in the external circuit.
the next step is to put the equations into either WinCUPL or galette so we can try writing them to a real PAL.
gah! i forgot how utterly awful both WinCUPL and galette are!
first attempt at PAL equations in galette--umm--did not match the real thing at all. i'm swapping parts into the DuPAL to compare how they perform for the same inputs.
UNFORTUNATELY i've discovered that DuPAL cannot differentiate between a tri-stated output and a low output, even though the hardware is capable of doing that. 😩
RealGene ☣️@tubetime
What if you put weak pullups on the outputs? Anything tri-stated will read high instead.
What if you put weak pullups on the outputs? Anything tri-stated will read high instead.
@RealGene yep, trouble is that i can't differentiate it from a regular logic high. one trick is to pull it to some other voltage and use a window comparator to detect it.