Connecting a C64 disk drive to the MEGA65 - first success

I have spent the last couple of days working on getting the IEC serial bus working on the MEGA65.  This has been possible, because we now have the CPU able to run at instruction-level accurate timing, which is generally sufficient for serial disk access. There are two purposes behind this: (1) we just want it working, and (2) we need to make sure that the circuitry on the MEGA65 mother board is correct for the IEC serial port.

I started out with a simple VHDL program that would let me control the CLK and DATA lines via joystick, and show their status on the two LEDs on the mother board.  That is, without a CPU, and without a video controller. The purpose here is to keep the VHDL super-simple, and thus super-fast to synthesise, so that I could iterate quickly, and avoid the 2 - 10 hour synthesis runs that have become normal.

We already knew that we had forgotten to specify the inclusion of pull-up resisters on the IEC serial lines, and this was indeed confirmed.  So I built an an adapter cable that takes 5V from a joystick port, and uses that to pull-up the serial lines via 1K resisters.  Ideally, it should also have diodes to prevent back-flow of current from the bus powering parts of the computer when it is off, as well. This I have noted in the errata for the next revision of the board, but didn't need to implement on my adapter cable for testing.  I'll probably adapt the 5V take-off on the joystick port into a joystick pass-through cable, so that I don't lose a joystick in order to have the IEC bus working. (It isn't unfortunately just a case of not using the cable when I don't want to use an external drive, because without it, it looks to the C65 ROM like there is a drive on the bus from which to try to boot, so the computer just hangs on start without it).  Here is the little cable I made up:

A side-benefit of this little cable with exposed pull-up resistor, is that it gave me somewhere convenient to attach the oscilloscope probles, so that I could watch what was going on:

After that, it was a bit of trial and error with my poor old 1581, that doesn't seem to be able to read disks any more.

 Then finally, once I had everything properly connected, and the, and the device ID set correctly on the 1581, it was success!

And here is the video of it:

Because I am using the MEGA65 in headless mode like this, I also extended the monitor_load program that can load a bitstream, and load a program into memory and do other useful stuff, to also allow typing input into the computer, as though it were being typed on the real physical keyboard. This uses the keyboard virtualisation layer that already exists in the MEGA65 to allow use off C65/C64/USB and other keyboard types, without having to mess with things.  So all I had to do was tell monitor_load to put the correct keyboard matrix events into the queue, and then I could type like magic.  One of the very nice aspects of this, is that one can run otherwise interactive tests completely automatically.

Here is the command line that I used to type this little disk status check in and run it. Note that I call monitor_load twice, once to boot the machine with a specific bitstream, and then again to do all the typing:

monitor_load -b bin/mega65r1.bit -4 ; monitor_load -T '10open15,11,15~M20get#15,a$:?a$;".";:ifa$>chr$(13)goto20~Mrun'

Now the next step is to figure out why it gets stuck after reading the disk status message once, instead of reading it repeatedly.  After displaying the disk status message once, the CPU gets stuck looping around in the input byte from serial bus routine at $EE13.  Clock and data are high, suggesting that the 1581 is not trying to send anything. What I can't work out is whether this is just because my 1581 is on its death bed (LOAD"$" yields a 74,DRIVE NOT READY,00,00 message), or whether there is still some problem with the MEGA65 side of things.  Unfortunately I don't have another drive here to compare with, and won't be able to get another one for a few days. Hopefully some of the MEGA guys in Germany will be able to test this there, where they do have some drives on hand. If there are remaining problems, I suspect that they will be CPU or CIA implementation related, since the electrical side of things clearly works, if we can instruct a device to come to attention, and then send a number of bytes.

In any case, I have plenty more to get on with in the meantime, for example, testing the ethernet and cartridge ports, and trying to work out why I can't get any audio out of the left channel.