Always Blame The Software (Part Two)...

A project log for rosco_m68k

A full-featured Motorola 68k retro computer, starring a 68010 running at 10MHz

Ross BamfordRoss Bamford 06/08/2019 at 20:242 Comments

So I talked in the previous log about how I had some issues while integrating the MC68901 MFP that I initially assumed were hardware-related, but that turned out to be software. Once I got past that, I hoped it would be plain sailing. Boy, was I wrong.

This morning, I took delivery of a 1.8432MHz crystal, which is perfect for generating the standard Baud rates we're all used to. I was quite excited to hook this up and then write a bit of code to just send something, anything, via the UART and a cp2102 UART-to-USB board I had lying around.

I hooked up the crystal, and quickly put together a bit of code to set up the timers and enable the transmit side of the UART. Needless to say, it didn't work first time. No problem, I didn't really expect it to. I still had the BIN files of the previous ROMs kicking around so I burned them back to the chips so I could watch the lights blink while I fixed the code. It was at this point that hilarity ensued.

The board was dead. The ROMs can't have burned correctly, so I burned them again. Still nothing.

I assumed that the jury-rigged EEPROM burner I built from a NodeMCU and some flip-flops must have stopped working. I don't have another one, so I built a quick circuit that would let me manually flip the address lines and see the output on LEDs. The first and last few bytes in the ROM matched with the bytes in the BIN I'd burned.

At this point, I ordered a real EEPROM burner, just to be on the safe side. Also because I was tired of using my home-built one which still required me to recompile the NodeMCU firmware to change the data that got burned to the ROM.

I spent a few hours checking and rechecking all the connections around the ROMs in case I've dislodged something while pulling them for programming.

I'm now thinking I've killed the ROMs with ESD or something when I pulled them from the board to burn them. I order more ROMs, just to be on the safe side.

Again I'm deep down a rabbit hole with only a multimeter and cheap logic analyzer for company. The readings I'm getting are all kinds of weird (at one point I'm assuming the 68010 is broken, because I'm not seeing the first word read of the initial SSP - turns out the logic analyzer just needed to be unplugged and plugged back in again).

Finally, just as I'm about to give up until the new ROMs arrive, I decide to try one last ditch thing (which really ought to have been my first-ditch thing, but oh well) and delete all the old BIN files and build them from source.

Bingo. All working fine again.

The "previous ROM" BIN file turns out to actually be an incorrectly-named version of a much earlier memory test program I wrote, which spools through the entire address space. This includes the expansion space, which now doesn't have any DTACK generation (since the changes I made to support the MFP) and helpfully no longer has a working indicator LED (because I've kind-of abandoned the idea of expansion space in the current revision due to the output line from the decoder being not-really fit for purpose, more on that in another log).

So all the while I thought the board was dead, it was really waiting patiently for a DTACK that would never come, in an address-range that I don't have an indicator for. I did think it was weird that the run LED never went out, but just didn't connect the dots.

Oh well, you live and learn...


Ross Bamford wrote 06/09/2019 at 15:40 point

Yep, it would definitely have saved me some time. I have a watchdog planned but unfortunately haven’t actually built it yet 🙄

  Are you sure? yes | no

lennart.lindell wrote 06/08/2019 at 23:23 point

It is exactly in this situation the bus-error timeout should be used.

  Are you sure? yes | no