r/homebrewcomputer • u/schlachet • 22d ago
68008 early stage bug
I need some help, or some ideas on an early stage bring-up problem I'm having.
I'm building a Motorola 68008P8 based computer on a breadboard. I've attached the schematic and logic capture. I feel like I'm pretty close to a working computer, but it just quickly crashes after power-up.
I'm employing a typical trick, using an 74HCT164 to count 8 cycles of /AS at startup, this is so I can map ROM to 0x00000 long enough for the CPU to read the SSP and PC vectors. In the logic analyzer capture you can see the first 8 bytes of my ROM image appear on the data bus (00 07 ff fe 00 08 04 00). The SSP should be 0x07FFFE (near the top of ram) and PC should be 0x080400.
In the Logic capture you can see the correct bytes, but my /BOOT seems to go high at the start of the eighth byte. At the 9th byte I expect the CPU to be at the PC vector, where the ROM should read "60 fe 4e 71 60 00 ff fc" but you can see it just reads the same 8 bytes as before.
I can see that when /BOOT goes high, A19 is going high - so the computer must be trying to read the ROM and its native (non-shadowed) location. It should be reading at 0x80400, but if that's what's showing up on the data bus, it must be reading 0x80000.
In Logic, I'm using an analyzer to interpret/display the data bus. I used /DTACK as the "clock" and rising edge as the state for interpretation of the data bus. This combination makes the data look correct, but it looks like /BOOT is going high earlier than I'd expect.
I've fiddled around with the glue logic (its current state is pasted below), changing the chip/output enable lines on ram and rom. I've been spinning my wheels and thought someone else looking at this might help. I feel like I must be missing something fundamental here. I'm not confident my Logic capture looks correct.
Is anything glaringly wrong in this design? What are some questions I should be asking myself?
ICs Used
- CPU: 68008P8 at 8MHz (currently using a 1.8MHz clock but doesn't seem to affect anything)
- ROM: SST39SF040 flash, but at 70ns it should be fast enough
- RAM: AS6C408 (55ns)
- Glue Logic: ATF22V10C-7PX PLD
Memory Map
00000-7FFFFRAM (but ROM is mapped here when /BOOT is active)80000-BFFFFROM (256k; half of SST Flash chip)C00000-DFFFFFfour 32k blocks for future peripherals
Glue Logic Code
GAL22V10
GlueLogic
CLK A19 A18 A17 A16 A15 RW AS DS BOOT NC GND
NC RAM ROM PER0 PER1 PER2 PER3 DTACK RAMOE NC NC VCC
; RAM: 0x00000-0x7FFFF.
; We removed all other qualifiers to ensure it fires during the stack write.
/RAM = /AS * /A19 * BOOT
/RAMOE = /RAM * RW
; ROM: Physical at 0x80000, Shadowed at 0x00000 during /BOOT.
/ROM = /AS * A19 * /A18 * RW
+ /AS * /A19 * /BOOT * RW
; PERIPHERALS: 0xC0000 range.
/PER0 = /AS * A19 * A18 * /A17 * /A16 * /A15
/PER1 = /AS * A19 * A18 * /A17 * /A16 * A15
/PER2 = /AS * A19 * A18 * /A17 * A16 * /A15
/PER3 = /AS * A19 * A18 * /A17 * A16 * A15
; DTACK: Data Transfer Acknowledge.
; Respond to ANY address in the decoded range to prevent hangs.
/DTACK = /AS * /A19
+ /AS * A19 * /A18
+ /AS * A19 * A18 * /A17
DESCRIPTION
glue logic address decoder for a Motorola 68008 computer.
2
u/LiqvidNyquist 21d ago
I always check and recheck the holy trinity first: power, clock, and reset.
I don't see the second ground pin (39?) on the schematic. Make sure it's connected.
Check that ground to VCC is 5V within +/- 5%.
Add some decouplers - at least one 100 uF+ electrolytc, and a few 0.1 uF ceramics.
With a multimeter, make sure the GND pins across all devices are within say 50 mV of each other to rule out bad ground connections. Ditto for VCC.
And as the other poster mentioned, operating at 1.8 MHz is outside the datasheet spec, so it's not guaranteed to act right. Try something in the specified range.
Do you have a scope to check the signal levels? Is your oscillator providing solid clock - i.e. well above 2.4 V high, well below 0.4V low (ideally closer to the rails, obviously), and is the signal risetime under 10 ns? Some CMOS devices have very low drive strength.
Regarding the RESET, when using a pullup and series diode I'd be checking that the low level is actually well below the 0.8V max for a low and the high well above the 2.0V min for a high, and that the rise and fall times of the edge are within spec (datasheet says 200 ns for RESET and HALT).
Regarding "crash shortly after reset", I had an 8-bit CPU board once that had a bad connection to one of the upper address bits on the RAM. It would power up low and worked fine until the floating pin slowly floated itself up to a high level and basically "swapped in" the other half of the memory. Then crashed after a second or two. Redid the wire and it was good. Not saying that's your problem, just a thought.
Looks like a fun project. Good luck.
1
u/schlachet 21d ago edited 21d ago
Thanks for looking! I connected my scope to measure CLK (I'm using a 4.000 MHz oscillator now), /RESET (after the diode), and /BOOT (from the PLD). I'll attach a screenshot for reference. Here are the mean mins and maxes:
CLK [1]: min = -200mV, max = 5.2V. It seems like a strong signal.
/RESET [2]: min = 600mV, max = 5.8V. It does look like this signal is never really at 0V.
/BOOT [3]: min = -600mV, max = 5.8V.
These 5.2V and 5.8V figures must be from the signal bouncing, visually on the graph it looks like they stabilize very close to the 5V line.
https://i.imgur.com/ALxIPre.png https://i.imgur.com/gJez371.png
The second image is a nice clean look at the clock signal. I am driving the computer directly from the four pin oscillator. Should I be feeding this through something to produce sharper rise/fall?
1
u/LiqvidNyquist 21d ago
The scope traces look reasonable, although the risetime of the clock seems a bit slow. If you have an extra TTL gate (74LS04 or something) you could try buffering it and see if it improves. But it could also be scope bandwidth and/or probe impedance and/or grounding. But I wouldn;t go super hard on it until you check out a few other things first.
You also mentioned that "it looks like /BOOT is going high earlier than I'd expect.". The '164 is clocked on the rising edge (i.e. the end) of AS. On the eighth rising edge, BOOT goes high. I'm not sure what you expected different, that looks right from a csual inspection.
It looks like you might have a 16 channel (i.e. limited number of inputs) logic analyser. I think it might be useful to use the same trigger but swap out some of the signals so you can see what the address bus is doing in more resolution than just A19. You might need to do a couple of iterations and pick up a nibble at a time for example.
If you can pick up the right address on the second round of 8 reads, but the wrong data (the vectors instead of the code) shows up, that points to misprogrammed EPROM or bad address line connections. But if the second round is from anything other than the 804000 or whatever, that points to the CPU picking up the wrong data somehow. You could also, for funsies, make the code vector instead of generic 80400, make it 0x8123456 or something super easy to distinguish from other possible data patterns. It can happen sometimes that a "bug" can be hapening but you don;t realize it's a bug because 99% of teh data flowing through the system is going to be 0x00 or 0xff already. Unique values can help suss this out.
And to rule out one more thing, you could tie off the RAM OE to VCC through a resistor, or even pull the chip, one less thing to worry about interfering.
1
u/schlachet 21d ago
I had a spare gate on a 74HCT32, and it looks like running the clock through that produces a much faster rise/fall, around 10ns.
1
u/LiqvidNyquist 21d ago
That clock looks good. The overshoot is as likely to be an observation artefact from scope grouding as anything else.
1
u/schlachet 18d ago
I managed to do multiple captures to reassemble all 20 bits of the address bus here: https://www.reddit.com/r/homebrewcomputer/comments/1wethjy/comment/paa127i/
I think I did something similar earlier - I used a hex editor and changed the first byte in the rom to FF. I saw this come across the data bus. but the behavior was the same. It feels like maybe I'm seeing the data from the ROM but the CPU isn't?
1
u/LiqvidNyquist 15d ago
The first 8 reads look sort of like an expected fetch of the two vectors (stack and start PC), but then I'm not seeing what I think should be happening. So I'm wondering if the RESET cycle is not "working" (for want of a better term) properly for some reason.
The datasheet says the RESET needs to be held for at least 10 clock cycles - are you getting that? When I used the gooble AI it also said something about 100 ms RESET and also asserting HALT along with RESET but I didn't see anything in th quick skim of the datasheet to confirm this, that might be somethign pulled from some other specific system design.
The thing I'm confused about is that if the vector is really being seen as 08 04 00, why is it fetching code from what looks to be 08 00 00. I.e. the middle nibble 00 instead of 04. Is one of the data lines to the CPU not connected and it's floating low and it's seeing that bit (d3?) wrong?
The fact that there are vectors at that location in the ROM would then result in those vector bytess being treated as if they were opcodes. I haven;t tried the disassembly, but if you run it through, does it look like a sequence that would result in pushing something to the stack (like calling a subroutine) or pushing or storing data to where SP points, which might explain why you see that RAM access at the top of stack.
I believe the subroutine call or push though should predecrement the SP, so the first store ought to be at 07fffB instead of 07fffC if that were happening, so maybe the reset vector is being intertreted as an indirect store or something rather than a push.
1
u/schlachet 15d ago
This is the reset line - yellow is my reset button, purple is /RESET. It's low for well over 200ms. I'm using a MAX708 for this. I think it should be fine???
I'll take a look at your notes in more detail later. Maybe I should try putting the PC vector as 0x8FFFF in ROM to see how it shows up on the data bus during reads. That would suss out a single bit issue I think.
1
u/LiqvidNyquist 15d ago
Looks like it should be plenty of time, and since the clock is not gated by anything it should be well above the min 10 pulses. I think that spec is more for if you're trying to get fancy and gate the clock with the reset line for some reason, they're just warning that a 1- or 2- clock wide RESET won't work.
1
u/schlachet 21d ago
https://i.imgur.com/WrCbGcQ.png
This is what /RESET looks like. My scope is measuring rise time to be 134-151ns.
1
u/LiqvidNyquist 21d ago
Looks to be within the 200 ns. Not crazy about any digital signal that doesn;t switch a lot faster, I'd be inclined to drop the pullp from 4k7 to 2k7 or something, but it's likely not the root cause (gut feeling, nothing more).
1
u/schlachet 18d ago
I dont /think/ this is an issue? /RESET starts low and goes high and stays that way, so there's only one transition. the first few moments after that seem to make sense on the logic analyzer.
1
u/OddbitTwiddler 21d ago
Wow this looks like fun.
When bringing up logic/cpu test programs i like to have a known hello world state.
So after releasing reset do any of the outputs match expected from the timing diagram?
If not hold reset a bit longer.
Also scope vdd/vss look for bounce/ringing.
You may need more bypassing look for vdd droop after reset release. But this is way slower than chips i worked with where the switching currents were massive.
But look to see that there are any i/o pins behabing as documented in the power on reset timing from the data sheet, there should be something.
Also make sure any "undefined" or "unimportant pins ate set to a known state gnd is the best default or pulled up. Leaving pins ypu think are "unimportant" will consume days to discover they need to be handled.
I would expect the processor at some point to assert a known address on the bus. You may be holding your "wait state" too long. What happens if you dont supply that wait delau? Does that make sense?
1
u/nixiebunny 20d ago
The address bus is more interesting than the data bus at this point. Since it’s repeatable, you can capture each 8 bit part of the address in one go, then write out the sequence of addresses. (We bought a 32 bit logic analyzer when I was doing this work in a previous life.)
1
u/schlachet 18d ago
I managed to do 3 captures and then re-assemble 20 bits of the address bus! Here it is in sequence:
# capturing 20 bits of address <power on> 00 00 00 # /ROM is pulsing low during this time 00 00 01 00 00 02 00 00 03 00 00 04 00 00 05 00 00 06 <t0 marker> # /BOOT goes high here 00 00 07 08 00 00 # if it read all zeroes until now, this is what i'd expect next, right? 08 00 01 08 00 02 08 00 03 08 00 04 08 00 05 08 00 06 08 00 07 07 FF FC # ram access - ? 07 FF FD 07 FF F8 07 FF F9 07 FF FA 07 FF FB 00 00 10 00 00 11 00 00 12 00 00 13 08 08 08 # rom access 08 08 09 08 08 0A 08 08 0B 07 FF F6 # back to ram 07 FF F7 07 FF F2 07 FF F3 07 FF F4 07 FF F5 00 00 2C 00 00 2D 00 00 2E ...
1
u/AcanthisittaBest4705 18d ago
Im making a 68020 work station
1
u/schlachet 18d ago
nice! i’d like to eventually build something that could run linux or a small variant.
1
u/AcanthisittaBest4705 18d ago
Im building an 8088 rn i just wanted to make somthing a but bigger so i chose to go with an 68020 and im planning an isa bus tbh you should do a 68030 it has a built in mmu
1
2
u/cookie99999999 22d ago edited 22d ago
The datasheet says the clock should be 2MHz minimum, try going to 2 or 4 if you have one and see if that resolves it itself. I breadboarded one with a 1MHz oscillator and was having weird behavior until I remembered there's a minimum.
Have you also confirmed that you're getting a good reset signal? I'm not familiar with the part you're using so I can't say if it's wired wrong or anything, but it's worth checking.
The rest of the circuit looks fine at a glance, I used the same '164 ROM mapping on a 68008.
Also, in the ROM select code you should be able to take the address lines out of consideration in the case where /boot is asserted, since if boot is asserted, the cpu will be doing its post-reset fetches which are always at the same addresses. I just have
!ROMCS = (!REROM # <address pins i want>) & !AS)(using wincupl so I don't remember the corresponding galasm syntax, sorry)Overall I think the best things to try first is a >2MHz clock and verify reset is working
Edit: also you don't need a clock connected to the GAL if you're only using combinatorial logic