68K Free Run
Some small progress on the 68K single board computer: I have a 68008 working in “free run” mode on a breadboard. Free run isn’t really a processor mode, it’s just what happens when you connect all the CPU data lines to ground, hardwire the control signals to default states, and connect a clock oscillator. The 68K acts like there’s a device present that spans the entire address space and is filled entirely with zeroes, so it initializes the program counter to 0 and starts executing a long series of instruction 0x0000, which happens to be the 68K opcode for ORI.B #0,D0. As the PC advances through the address space, the CPU address bus counts up from zero. By connecting an LED or a logic probe to one of the higher address lines, you can see it blink as proof that the processor is alive.
OK, maybe it’s not very exciting, but it’s a fun little experiment you can do with just a naked 68K CPU and a clock oscillator. No RAM or ROM or other hardware is needed. I recently discovered a similar free run demo for Brian Benchoff’s 68K-based single-board computer for Hackaday, although that project appears to have stalled out afterwards. It seems that blinking an LED in free run mode is a rite of passage for 68K projects.
Along the way to this demo, I discovered that reset handling for the 68K is annoyingly complicated. You might think there’s just a /RESET input to the CPU, and you could force /RESET low to reset the processor, but that’s not how it works. The 68K has a /RESET and a /HALT, and to reset the processor you need to drive both of them low. But these pins are actually bidirectional I/Os, and sometimes the CPU itself will drive one of them low! For example /HALT will be driven low after a double bus fault. So the external reset circuitry can’t actively drive these signals high without causing damage, it can only actively drive them low or let them be passively pulled high by a pull-up resistor.
This makes it impossible to design a simple reset circuit where /RESET and /HALT are both driven low when a single button is pushed. The single “master reset” signal would have to be connected to both /RESET and /HALT, effectively tying those signals together. If the CPU later drove /HALT low due to a fault, that would cause it to see /RESET low too, and so the CPU would reset itself. What a mess. After thinking in circles for a while, I concluded the only solution is to use an open collector buffer like 74LS07, or discrete transistors, so each signal can be independently pulled low in response to a single master reset signal, then allowed to float high. I don’t have any of those parts handy, so my breadboard circuit has two separate push buttons, and both must be pushed at the same time to force a CPU reset.
Read 11 comments and join the conversation11 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
You could couple the two together with diodes.
Clever idea. If I understand what you mean, wouldn’t that pull /RESET and /HALT to a diode drop above ground, instead of all the way to ground? That’s pretty close to the 68000’s input low voltage threshold of 0.8 volts.
Yes, that’s why you would want to use a Schottky diode instead of a generic diode; you can easily find Schottky diodes with a forward voltage drop of around 0.3 V (or less) at the small currents involved here. But then if you don’t have discrete transistors or OC buffers handy, you probably don’t have more specialized diodes handy either.
Do you have any 74HCT125 or 74HCT244 chips left over from your Nibbler project? If you tie the inputs of the buffers to ground and use the output enable pin(s) as your input they will act like open collector buffers (or actually, open drain buffers, since these are CMOS based).
Still not too late to switch to the 65816 :-).
Erik Petrich, that’s a clever idea, thanks! Two buttons are working well enough for my current breadboard testing, but I’ll probably use your idea in the final version of this SBC.
After adding more hardware to make the 68008 actually do something real, I’ve discovered that forcing /RESET low by itself is enough to reset the CPU. This contradicts the datasheet, which says both /RESET and /HALT must be brought low, so I’m not sure what’s going on. Section 5.5 on page 5-29 of the 68000 datasheet covers reset operation, but it doesn’t really say what’s supposed to happen if /RESET is asserted by itself without /HALT.
Hmm, I think the datasheet requirement to drive both /RESET and /HALT low together may only be there to cover the edge case where the CPU is executing a reset instruction at the same time as /RESET is asserted by external circuitry. Outside of that one case, it may be sufficient to assert /RESET alone.
The 68000 reset instruction is strange. It makes the CPU drive /RESET low, which is supposed to reset external peripherals, but doesn’t actually affect the CPU internal state. It’s an instruction to reset peripherals, not an instruction to reset the CPU itself. So if the CPU is in the middle of a reset instruction and is already driving /RESET low, and external circuitry also drives /RESET low at the same time, there’s no way to tell. The CPU won’t get reset. Asserting /HALT externally at the same time solves this problem.
You could also use two normal gates as a buffer, then resistors from one buffer to halt, and the other buffer to reset. You could also use a 7405/74hc05, which is an open collector inverter.
While we are talking about wiring up a 68K:
http://en.wikipedia.org/wiki/DTACK_Grounded
All the issues are archived on the net.
Damn. I see know that I’m two days late :/
I do know how to spell ‘now’, honest!
I use a PIC MCU to provide 100 ms power-on reset pulse generation, pushbutton reset switch debouncing, open-drain drivers for /RESET and /HALT, pull-ups for /RESET and /HALT, and HALT LED buffering, all in a single 8-pin package.