Close

Prepping for the MC68901 and nailing reliability

A project log for rosco_m68k

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

ross-bamfordRoss Bamford 05/26/2019 at 10:260 Comments

Now that the board is reliably running code (more on that below) I'm into the next stage of planning, which will involve hooking up the MC68901 MFP (Multi-function Peripheral). This will give me some interrupt timers (meaning I'll have a tick for the kernel to use) and a USART which I'm going to use for the initial IO to an external terminal (via a USB converter).

Most of the work here will be simply connecting it to the bus, but it will mean DTACK-grounded isn't going to cut it any more, at least when /IOSEL is asserted. With that in mind, I designed a small circuit that will look after DTACK for me:

This is super-simple, and is effectively the same as having DTACK grounded when RAM or ROM is selected (ignoring a bit of propagation delay of course). When IO is selected, however, it allows DTACK to be controlled by an external active-low signal, just like the one the MC68901 provides.

Gating the whole thing with AS is probably not necessary (and may even be undesirable - I won't really know until I build the thing and look at it with the analyzer) but felt cleaner.

Of course this is still the minimum-viable solution, but it will work for now. As the system grows DTACK generation may well become an issue again, and if it gets much more complicated I have a vague plan to move to an arrangement where DTACK can be generated by any one of a number of open-collectors which I'll wire-OR together.

A (hopefully) final update on reliability

Following my last couple of logs, I thought I'd nailed reliability. However, I noticed that it would still go wrong very occasionally. Everything would run fine for anything up to an hour or two, and then it would go wrong and end up asserting HALT.

This was really annoying, and I was thinking of all kinds of strange and exotic things - interference, weird timing-related things, a faulty chip? Then, while looking at something else with the multimeter I noticed that the voltages on the board were all over the place. The daisy-chained power connections between the breadboards were the problem, and putting in a couple of jumpers directly between the two ends of the whole system cured it (longer-term I plan to redo the power connections so there's no daisy-chaining).

Just goes to show that in homebrew computers, as in almost everything else, debugging should start from the basics. I'm happy to report that the board has been running now for a solid 24 hours without a glitch.

Discussions