I think I broke mine by being an idiot #23
Comments
|
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? |
|
The oscillator should get comfortably warm, so if it gets any warmer than
that - then I'd try exchanging it.
A direct short when used with a powerful PSU can also vaporize tracks, so
might be a good idea to look for dark spots on the PCB.
ons. 21. jul. 2021, 14:55 skrev liamoc ***@***.***>:
… 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?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGEF6IP2P4G3EEBAMJLWBWDTY27U7ANCNFSM5AX4Z7RA>
.
|
|
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:
|
|
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? |
|
My best guess for the power LED going out is that something is shorting it
out the power supply, might be causing the regulator on Arduino to go into
thermal shutdown. I think I'd try pulling all of the chips, then
reintroducing them one by one until the problem returns.
Don't know what kind of EPROM burner you have, but at least the MiniPro
does have the ability to test most logic chips.
fre. 6. aug. 2021, 17:27 skrev liamoc ***@***.***>:
… 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. What on earth just happened?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGEF6IJ2F22ZOT3DES67KR3T3P5M7ANCNFSM5AX4Z7RA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
Thanks for your advice. I removed all the chips, ardunio powered on and led powered on fully bright 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. |
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 But if the RAM's 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 |
|
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 |
|
If that was actually a backslash ( 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! |
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. |
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?
The text was updated successfully, but these errors were encountered: