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. 😩
oh i should just tag the guy who wrote DuPAL. @hkz very useful tool, can i have this tiny feature added to DuPAL Peeper? basically when you do a read, toggle the SIPO_O_7-14 lines and see if PISO_I_1-8 change at all. if they do, then they are hi-z.
bam! that was amazingly fast. so it turns out the output pin here, O13, used to drive the READY pin, goes hi-z when the drive select line is high. this is as expected. interestingly, it's driven either high or low when the drive select is low and the PAL is clocking out the drive ID code (1010... meaning it is a high density drive).
I think it's time to probe this device in circuit. I've attached the Saleae to most of the pins of the PAL.
you can see the drive ID protocol here. first it pulses the motor enable (with a drive select) to reset the state machine. then you get a bunch of pulses to clock out the data on the ready output (D7)
and this is what happens when you put a double density disk in the drive. so the drive ID gets read every time there is a disk change, and the adapter changes the drive type depending on the disk!
ok wow a few minor tweaks to the galette PLD file and the crazy thing works! I still need to test it with the Teac drive but I've managed to replicate the PAL.
the PAL code is not very complicated. i was able to remove a bunch of terms that `espresso` added (spuriously). i also made some minor improvements.
now for the most difficult part: what should i call my clone of "The Real HD-Drive"?
the layout for the board is simple. i'm making minor changes so it fits better in the Sony drive.
Lauren Weinstein@tubetime Discoganger.
chaz@tubetime The Fake Real HD-Drive?
root42@tubetime
* The Ultra 4K Drive
* Disc-o-Vision
* TruFlop
* Flippy Floppy HD
I bet I can come up with some more.
* The Ultra 4K Drive
* Disc-o-Vision
* TruFlop
* Flippy Floppy HD
I bet I can come up with some more.
Fritz Adalis@tubetime
Doppeldrïve
Doppeldrïve
Shambolic Matter@tubetime I can't believe it's not HD-Drive
Pyksy
Alan Martello
hkz@tubetime took note of it and will look into it!
@hkz grazie
@tubetime I don't have the device with me right now, so I can't test this change on real hardware.
But I have pushed a branch named "hiz_out" that you can checkout and try (add the '-hiz' parameter to the command line).
The limitation is that, for now, it checks for tri-stated outputs only on pins that are output-only for the particular device (like pin 12/19 on a 16L8), not on I/O pins.
Let me know how it goes.
@hkz it works great! thank you.
@tubetime Updated the branch again, now it should detect Hi-Z on I/O pins also.
Slightly more complicated and slower given that I need to toggle one pin at a time there (given that they can be input, they can change the state of other pins and give me false readings on the Hi-Z of other pins I'm checking).
Slightly more complicated and slower given that I need to toggle one pin at a time there (given that they can be input, they can change the state of other pins and give me false readings on the Hi-Z of other pins I'm checking).
bitsavers.orgyou would think that by now someone would have written a CUPL clone, or ABEL etc.
@bitsavers iirc someone wrote a yosys p&r backend targeting GALs, but they thought it was too trivial and didn't bother to publish it. i can't remember who it was.
@bitsavers thinking about it more and CUPL just isn't a good language. it would be fantastic to be able to write it up in Verilog so I could use simulation tooling and all that. and then after running p&r, being able to do accurate timing simulations would be super helpful. maybe I'll look into how Yosys/nextpnr targets work
Rue MohrPiffle.
PARC engineers wrote PROM state machines in BCPL
@bitsavers @tubetime ah yes, just a second while I compile the FORTRAN source code for that...
(seriously, please tell more)
✧✦Catherine✦✧@tubetime @bitsavers nextpnr is a poor fit for non LUT arches
re WinCupl, have you seen prjbureau?
@tubetime @bitsavers cause i might want a collab :p
@whitequark @bitsavers looks like R. Ou is the person I was thinking of. they did the original GAL work and then moved on to CPLDs. I think they mentioned it to me in conversation at MTVRE a few years ago.
@tubetime @bitsavers oh yeah, they're around on fedi too... i forget the handle
plaes@tubetime @bitsavers There's something called JsonToCupl - https://github.com/michaelhunsberger/JsonToCupl
Simon Frankau@tubetime How can I make galette less awful? It's currently extremely galasm-like, but if there are things I can do to make it nicer to use, I'm all ears.
(The deficiencies are probably obvious, but I'm too used to galasm to notice.)
@sgf ah thanks, I really appreciate your openness! I guess there are a couple of things:
- better error messages. I had some underscores in term names and the error I got said "invalid character in line n" but didn't say what the invalid character actually was.
- better docs. it's always a pain to write this stuff but it's super helpful for folks.
- equation reduction is probably out of scope since palasm was meant to be a thin wrapper around the raw fuse map, but that would be cool. 😃
@tubetime I worked on some error messages last week, for unrelated reasons - PTAL at Github latest & I'll fix anything missing.
Docs: I love writing docs, but don't know what people need, so let me know.
Equation reduction is tempting. I was thinking of writing something like a cupl2pld stage so that the pld format remains WYSIWYG. It's lower priority than just making it more usable in its basic form, though.
Thanks for the feedback. If GitHub issues work better for you, that's also good.
@sgf sounds good, thank you.
@tubetime Its kinda funny that the project files IT creates dont work till you remove the content it put there.
@tubetime you know, there is a linux program called
galasm
@tubetime It would be interesting to see you reverse engineer one of my FSMs...
@tubetime you're incredibly good at this
I could probably do this, but nowhere near as quickly
Tommy Þ@whitequark @tubetime It sounds really fun though, unravelling a mystery
@whitequark thanks! i got a lot of practice with the Quadlink project which had ~10 GALs, some registered.
Brændꜵn Mollɔy 
@tubetime i like the handwriting. 😊
ShutterBugged@tubetime Doesn't this model of PAL (https://www.alldatasheet.com/datasheet-pdf/pdf/70181/LATTICE/GAL16V8.html) have latches on the outputs, some of which can feed back into the inputs of other latches' combinatorial logic?
