Close

Now Reliably Running Code

A project log for rosco_m68k

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

ross-bamfordRoss Bamford 05/19/2019 at 12:474 Comments

As I mentioned in yesteday's log, I finally got the computer to run some code from ROM, but that is was unreliable and always seemed to wander off into oblivion after some time (a few tens-of-thousands of microseconds).


From doing a lot of poking and prodding, and running trace after trace with the analyzer, I thought this was related to timing. My ROMs should be fast enough (just) to run with DTACK grounded, but clearly something was off.

For testing, I jury-rigged a DTACK generator using a 74LS93 binary counter in 3-bit mode. It looks like this:

And here's a trace showing how it looks compared to AS (40n between dots):
(Good thing I read Matt Lacey's awesome log about DTACK before I designed this, or I'd probably have come up against the same problem he did first time around!)

This seemed to improve things, but the problem still remained. I figured I'd sleep on it.

Fast-forward to this morning, and while trying out some changes on the board I realised that having my hands near the CPU kind-of fixed the problem. Uh-oh, something's floating.

Some sanity checking and continuity testing later led me to discover that, because of a mistake in the control bus wiring, my new DTACK generator was in fact trying to drive the CPU's bus-grant line. DTACK was in fact floating, and it was purely random chance that it ran at all.

Having fixed that, I first verified that the DTACK generator works (it does), and then went back to DTACK grounded. It now works perfectly and has been happily sitting my bench for the last hour, running this code which gives me some visual output on the address decoder status LEDs.

I've also made a small change in the ROM wiring to ensure it's safe to have DTACK grounded. Where I was previously using the address decoder to drive the /CS lines, I've instead tied CS low and am driving the /OE line from the decoder. According to the Atmel ROM datasheet, that should about halve the time-to-output from 150ns to 70.

Discussions

K.C. Lee wrote 05/20/2019 at 04:32 point

Grounding the /CS pin is what everyone did in the old days for slow EPROM.

  Are you sure? yes | no

Ross Bamford wrote 05/21/2019 at 12:42 point

seems like I’m following a good precedent then :) 

  Are you sure? yes | no

Ken Yap wrote 05/20/2019 at 00:07 point

Nice detective work. Feels really good when you nail one of these bugs I'm sure.

  Are you sure? yes | no

Ross Bamford wrote 05/21/2019 at 12:43 point

I must admit it did feel pretty good when it was finally working :)

  Are you sure? yes | no