I think I broke mine by being an idiot
liamoc opened this issue · 22 comments
I accidentally left my SBC resting on a conductive surface and turned it on via the 5V power from the backplane. It immediately shorted and seemed to turn off. Upon correcting this issue and plugging it in again, i can't seem to get anything to work anymore. It doesn't seem to be booting correctly. The Arduino itself seems to be fine (it shows a ! when I connect to the serial interface), so I suspect that the EEPROM has been corrupted. I don't think a 5v short would really damage any of the other chips, although I suppose it's possible. Anything else I should try before I start replacing chips?
Oh, I just realised the oscillator I have in here seems to be getting very hot! Is that normal? Or is that perhaps the broken culprit?
Thanks for the tips! The oscillator is hot enough that it is slightly painful to touch, but it's not so bad as to actually burn me. I think that's too hot. I will get out my desoldering braid and replace it soon.
I tried replacing the oscillator and the new one doesn't run so hot but the machine still doesn't work. I reprogrammed the EEPROM, still didn't work. Then I just decided to solder up a whole new board seeing as I have the parts anyway, so I did that and moved the chips over. Still didn't work -- exactly the same problem. So I know it's not the eeprom, the oscillator, or any of the traces on the board. Now I've ordered a new ne555 in case it's just not powering on properly (the reset button doesn't seem to produce any change, so perhaps this is the culprit). I also ordered MCP23S17 in case that's the problem, and a new 6821 because I found one for cheap. When they arrive i'll try replacing those chips. It may be that I will be able to make two working SBCs from my leftover chips 🤣
The easiest way to debug this is to start 'scoping out the various lines (usually starting with clock, then address) if you have an oscilloscope available. If not, you're stuck with a logic probe or even just a voltmeter in which case removing chips for individual testing may be an easier way to go about things.
A few things you could try:
- You can (unreliably) reset the CPU by simply briefly shorting the reset pin to ground for a short period of time, so you might try that if you suspect your reset circuit.
- If you pull the 6502 and wire it up on a breadboard with pull-ups and pull-downs to put a NOP ($EA) on the data bus, you can look at the high address pins to see if they're toggling on and off at a constant rate (the A14 rate should be double the A15 rate, A13 double A14, and so on). The slower a clock you use, the more lines you can check by eye with just a logic probe or LED.
- You can pull the ROM and wire it up on a breadboard with various high/low inputs on the address pins and asserted select lines, and then check the data outputs to see that you're getting the values you expect.
- You can do the same with the RAM to write and read it, if you're careful.
Thanks for the advice! I have a scope arriving tomorrow so I will be able to do some poking around then.
I tried scoping out the clock pins on the CPU and they just seem to be high (but it was <5v, perhaps 3.3?). But then, while I was scoping it out, suddenly the power LED faded off and then I couldn't power the board anymore at all. The Arduino powers on just fine when not plugged into the board, but now absolutely nothing happens when I plug it in while attached to the board (even the arduino doesn't power on). What on earth just happened?
Thanks for your advice. I removed all the chips, ardunio powered on and led powered on fully bright
added reset chip - same
added oscillator - same
added arduino io expander - same
added PIA - LED is half as bright, arduino power light goes on but doesn't seem to be actually starting.
removed PIA, added CPU - LED is extremely dim, arduino doesn't power on.
added PIA and CPU - LED is off, arduino doesn't power on.
I am not sure what's wrong here. Should I try a different PIA chip? I'm worried that I'm frying whatever chips I put in it.
For a start you should be using a voltmeter to check your power rails! This is the first thing you should always do (ideally, check the voltage and ground pins on each chip) and you should also do this whenever you take out or replace a chip. I probably should have mentioned this first thing in my earlier reply.
If adding a chip like the PIA or CPU causes a voltage drop of more than a tenth of a volt or so, pull all the other chips (including the Arduino) and try it again. If you still get the drop it's a bad chip; if you don't you may simply not be supplying enough power to the board. (Powering the entire board via USB should be ok, since the board usually wants a total of around 250 mA and most powered USB ports should supply at least 500 mA, but there are some circumstances in which they will supply less.)
You need the Arduino to see I/O on your computer, of course, but you can actually work from the other direction with a 'scope by looking to see which lines are toggling (and which are not) on the address bus, and then go on to I/O lines. Start with the clock circuitry and make sure power is ok and you're getting a proper 1 MHz clock. Then add the ROM, again checking power, and then the CPU, checking power, clock and then the address lines. If that's all ok the CPU will be running in a loop in WozMon ($FF00-$FFFF) and reading the keyboard input at $D011, you should see A15 and A14 always high, A13 toggling, A12 always high, A11-A8 toggling, and so on. If that all seems ok you can add the PIA and you should be able to capture signals on the video output port when you reset the system and it prints a prompt.
Obviously this stuff is a bit complex to figure out, but it will not only help you fix your board but at the same time really deepen your understanding of how the whole thing works at the very lowest level.
I checked the voltage when on USB power via the arduino (vcc to gnd on the 6502 pins) and it's negligible (<1V). I think the arduino is just not powering it at all (I did have USB power jumpered). In case powering via USB was the problem, I connected it to a solid 5v power from the backplane. Now the board powers up fine, but still the system isn't booting. I scoped out the clock lines and now it seems like we're getting a solid 1MHz clock, which is good.
I used the jumpers to disable the PIA, ROM and RAM. The CPU was showing activity. Then I enabled the ROM, and the address lines were as you described, with toggling. If I enable the RAM though, all address lines seem to be stuck high. The RAM chip doesn't seem to be faulty though (I tried replacing it with a fresh one, and no change).
As for the PIA, I don't really know how to scope that one out yet. I'll do more research.
If the system worked with the RAM removed, but failed with it in, that would point to a bad RAM chip. But that it works when the RAM is merely disabled, and the bus goes wonky when the RAM enable line is connected again points to possible issues with the address enable signals. Those are generated mainly by the 74LS138. Something like the RAM enable being stuck active (low), so that every read from the ROM or PIA ends up having the RAM respond as well, would seem to be consistent with the symptoms seen so far.
If it's always low, you've found a problem. If not, it may still be going low at certain times when it ought not be and you can (with a bit of ingenuity) 'scope that out. I suggest reading carefully the schematic to understand the decoding logic and the monitor source code from $FF00 through $FF2D so you understand what it's doing from reset to waiting for the first character input. Make a list of all addresses you see accessed (both for code and data loads/stores). If no RAM is being accessed (which I think is the case), you should never see the RAM enable line go low and you can verify this by triggering your 'scope on that (and seeing that it doesn't trigger) or maybe triggering the 'scope on reset lifting and watching however many clock cycles that code takes to get to its wait-for-input loop. (Even with a two channel scope you should be able to watch the clock and that select, and use an external trigger from a third signal.) Or you could 'scope out several of the select lines to see, e.g., ROM and PIA being selected as expected for the input loop but never RAM (assuming you get to the input loop). You get the idea; poke around, looking at both working and non-working configurations, refining both your understanding of how the system is supposed to work and what it's actually doing.
I just tested the 74LS138 (and all the other logic chips) in my minipro and it reported all good, but I will scope it out as you suggest.
The schematics seem to suggest that the 74LS138 chip isn't involved with the RAM at all? In any event, looking at the three control pins for the RAM (_OE _WE and _CS), I am getting a solid 1mhz clock on _WE whereas _OE and _CS are stuck high. But that doesn't seem wrong, seeing as they are (via the jumper) directly connected to A15 which also seems to be stuck high. So I guess this means that the CPU isn't reading RAM anyway. Seeing as MSB of the addresses would be ROM anyway, it seems like the RAM chip is doing what it's supposed to, right?
Oh, weirdly, if I move the jumpers that select the bank of ROM to use to the left (i'm using a 256 eeprom so I had them set to the right hand pair) the address toggling behaviour is visible even when ram is enabled. But even when such toggling behaviour is visible, there is no I/O coming through to the arduino.
Looking at the rom pins, _OE and _CS is always low, and _WE is always high, which also makes sense because we never write to rom, and the CPU is asking for a high address. So it doesn't seem like it's a ROM/RAM conflict at all.
The schematics seem to suggest that the 74LS138 chip isn't involved with the RAM at all?
Good catch! Yes, you're right (as well as showing that you're developing good debugging skills :-)). The RAM is mapped to all of the low 32 KB of address space, so one can just use A15 as the select.
But if the RAM's O̅E̅ and C̅S̅ are always high it will never be enabled and so should never cause a problem. You'll note the RAM_EN jumper just connects those two directly to +5V or CS_RAM aka A15, so if things are ok when the jumper disables the RAM, and break when it connects the chip to CS_RAM, the problem must be in CS_RAM/A15. So I'd go over and re-debug that whole section again and see if changing the jumper really does change things. Perhaps the jumper wasn't properly connected when you thought you were jumpering CS_RAM to the chip; if the O̅E̅ and/or C̅S̅ pins were left floating that would very likely cause problems (the chip might randomly spew on to the bus).
WRT the ROM bank jumpers, again those are ones that will cause problems if they're left floating, so make sure that the ROM's A13 and A14 pins are properly connected to Vcc or GND. (You can use a continuity tester on the unplugged board to verify this.) Assuming that's working properly, you'll of course get different behaviour at startup if you select a ROM bank with different code in it. I've been assuming you're using a ROM bank with WozMon in it (it starts D8 58 A0 7F 8C 12 D0...; this is in the listing in the Apple 1 manual). But you can of course play around with other code, and even burn your own test code into the EEPROM if you like. If you don't have a way to read the ROM, you can just plug the chip into a breadboard, wire up an address on the address pins, enable the chip by grounding O̅E̅ and C̅S̅, and see what voltages come out the data pins. This is a nice little exercise even if you're not having problems, though obviously you're probably not going to want to read more than a dozen or two bytes this way.
I discovered that perhaps one or more of my chips simply wasn't seated well. I noticed that even with ROM jumpers on the right and the RAM jumpers enabled, i could get the "toggling" address behaviour sometimes on resetting but it would quickly go all-high when I touched it with my probe. Giving the chips a good push seems to have solved the "stuck high" problem. Connecting to the PIA via the arduino printed about 20 /, which I think was it attempting to print the prompt, and then it did echo my input! but as soon as i tried to print out a random memory address in wozmon it just spammed space characters (or tab?) into the stream. Ever since then, resetting hasn't produced any results at all (just as before..) but the cpu and ram and rom do seem to be working somewhat. I am beginning to strongly suspect the PIA.
If that was actually a backslash (\), that's the Wozmon prompt, yes. You should also be able to get that by typing an ESC (which clears the current input line), IIRC.
When things go wrong with (emulated) keyboard/screen input and output, remember you also can reset the Arduino. (Or at least I can with mine: my Nano has a reset button.) I've sometimes found on my system that it's the Arduino that's gotten messed up, not the SBC, and resetting just the Arduino brings me back to where I was with the microcomputer.
Sorry, yes, it was a backslash. I have managed to get it to reliably print a backslash on reset. But it still doesn't accept any input. Also, scoping the address lines while i do this, it will print the backslash and almost immediately afterward all the address lines go high again. I'm not sure what's causing this. I get about 1 second of working computer and then it crashes in this way. I'll try reseating all the chips again.
Edit: Pressing in on the CPU makes the address lines toggle again, but now it no longer prints a backslash..
OK, I moved the CPU, ROM, arduino (+ io expander), reset and logic chips over to my second board that i soldered more recently, including the new PIA that just arrived. This combination of hardware now works perfectly. So that leads me to conclude that it must be either the old PIA or the old board itself that is problematic. I will do more testing on the suspicious PIA, but I can close this issue now because I have a working machine again.
Thanks so much for all of your help!
I will do more testing on the suspicious PIA...
It also might be worth beeping out the old board to see if anything's been broken or shorted on it, though from what caused the damage I would suspect a damaged chip myself.