Apart from work and family commitments over Easter I’ve been stuck in a rinse repeat cycle with this board.
I am still trying to iron the bugs out, and I’m having weird issues with the firmware. I started thinking about porting the TS2 “monitor” to this board, but was having weird issues trying to get the UART to output a string from ROM.
I’m doing something wrong …
I then set up a new project just to do a simple test of blinking the LED in a sequence stored in ROM. It was about this time I started to suspect there was something wrong with the CPU or the board. Reading a byte from RAM with post decrement addressing would work, but trying to do the same in ROM would crash the CPU. After much stuffing around I finally put out a cry on Twitter and @brouhaha mentioned that the CPU could be double faulting and asserting it’s HALT line. I hadn’t realized this CPU had bidirectional RESET and HALT lines!
Looking at the schematic I made, I did wonder why the RESET and HALT lines had resistors in them. It now makes sense given they can drive the lines as well as take input. So anyway, I stuck my multimeter into the HALT pin when a crash happened and yes the CPU was double faulting.
The 7 Stages of Grief …
At this point I doubted everything I spent a week or more trying to solve why this was happening. I questioned my understanding of m68k assembler, and kept breaking my testing program down till all I had was basically three instructions and the problem still existed. I questioned the assembler. I questioned the linker. I whinged on Twitter, I complained constantly to @trc_vm via Slack. I then questioned the new EEPROMs I had bought.
Which this last one may or may not be a real issue, but the previous EPROMs were 90nS speed rated, and the RAM is 100nS speed rated. These new AT28C256 EEPROMs are a fair bit slower at 150nS, so I desoldered the 12MHz crystal and under-clocked the CPU to 8MHz to see if that made any difference. In the end it did, in some small way in that at least now it would appear to fall into the exception handlers and not just double bus fault all the time. But I still had my problem with byte loading values from ROM.
I then started to question “can the m68k actually address bytes, I’m sure it can” so I scoured all possible resources to confirm it. Then I altered my program to use words instead of bytes and the damn thing started working!
Time to crack out the logic analyzer.
So now I’m to the point I’m questioning the board or the CPU. So I drag out the logic analyzer and since I can’t find more than 5 chip clip leads I’m forced to stuff around to get what I want. I set up my simple small test program to blink the LED in a sequence stored in the ROM. First blink the LED twice, pause, then blink the LED three times, pause, etc etc. Eventually up to 8 blinks.
Run this, I get my two blinks then a locked up LED. I wanted to see what the ROMs were doing on the 8 bit address read. So I clipped up the RAM/ROM chip select lines, the even and odd enable lines and the LED output.
You can easily see the ROM is doing an 8bit read on even, then an 8bit read on odd.
Damn it, this looks OK … :(
Suffice to say, I’m at a loss. I re-installed the original factory firmware to finally see if I wasn’t going bananas. It too failed and entered a double bus fault. So if the original firmware now fails I’ve somehow damaged the CPU or the board.
I’ve found on eBay a few replacement CPU’s for every little money, but they won’t be here in time for the end of the Retro Challenge. But it does mean I will get this board going again. I’ve learnt so much playing with it, and my understanding of GNU binutils etc is so much richer because of it. So perhaps I can’t get anything going this year for the challenge…
… or can I?
When I rescued this board from the dumpster I also recovered a few others with it. I picked this board for the Retro Challenge because it seemed the most approachable; generic MC68HC000; external UARTs and I/O. But it wasn’t the only board I recovered with a m68k processor on it.
Enter the AMX AXC-EM with an MC68340RP16 on board!
Why didn’t you use this one first?
To be honest I wasn’t sure what I wanted, and I was familiar with the MC68HC000. I also thought having the UARTs and I/O all on chip was cheating. This board is basically the same thing functionally-wise to the other. It’s just newer and with an ‘020 based CPU. Basically all the same hardware is on board. Two UARTs, an LED, 8 DIP switches, battery backup RAM, clock/calendar, etc etc. It’s still from 1992 so it fits the Challenge. :)
So yeah, now I start again basically. I have to figure out the memory map, the device layout and the differences with an ‘020 versus a vanilla 68000. Dear god I hope it can read bytes from ROM!
Comments