Atom with missing C11

[MrSquiggles]

Hi all,

I'm having trouble getting my Atom to start up. Most of the time I just get a garbage text display, like the OS is not started.

Probing around the CPU when it is in this state I see good 1MHz clock in and out. /RST, /NMI and /IRQ are all high. And so are all the address lines, as if the CPU is not running! What might cause this?

I notice that C11, the capacitor that debounces / stretches the RST pulse at power-up / Break is missing. Could noisy Breaks somehow get the CPU into an unstable state? (Eg, some sort of "latch-up" condition perhaps??) It is a Rockwell R6502P.

It does seem as if physical handling of the pcb makes a difference. I was just getting going with the logic probe yesterday when the problem fixed itself, and the Atom ran well for the rest of the day. (Reassuring that it's not completely broken, but slightly frustrating when trying to debug the problem!)

According to the schematic C11 is 100nF. The parts list in the Tech Manual say 10uF electrolytic. (And my handwritten notes from BITD suggest mine was actually 22uF for some reason.) From the spacing of the holes on the PCB, I guess the manual is right, not the schematic. Correct?

Would it really matter which was fitted to replace the missing C11?

Pete

[oss003]

Hi Pete,

C11 delays the RESET pulse to be sure all chips are ready to be reset.
The value determines the delay time and if 10 uF isn't enough, you can try a bigger one.

Greetings
Kees

[MrSquiggles]

Thanks Kees.

I fitted a 68uF. (That was the nearest value I had on hand.) With a logic probe on IC9.13 I see a reset pulse of about 300ms when I press Break. It doesn't fix my problem.

A scope on the 6502 /RST pin shows a horrible amount of noise, sufficient amplittude for the logic probe to regard the line as flipping many times in the 300ms. I think most of the noise is too fast for the 2 clock cycles that it takes to reset the 6502.

I think I might actually be better with a much smaller cap, eg 10nF as in the schematic, so that the reset spends much less time in the noise zone. However I no longer really think that the reset is the problem. I actually think I have a pretty poorly Atom on my hands...

I put the probe on /RST, /NMI, /IRQ, SYN, RDY and A0, and watched what happens after pressing Break. About 1 in 10 attempts the CPU does start and runs for a few 100ms, and the screen is cleared to the 'Acorn ATOM' banner, but does not reach the '>' prompt. After that the CPU appears to just freeze: no SYN or A0 activitiy any more. What happens on screen is hard to describe: it's not stable, but the text stays, and there is none of the classic writing to screen RAM noise. (I guess the 6847 is resetting somehow, but I don't see a mechanism, it doesn't have a RST pin)

/NMI and /IRQ remain high throughout. So does RDY. Previous comments aside, /RST looks OK too.

Has anyone any ideas what might be going on? I don't think the 6502 has a Halt mechanism other than RDY, does it? Is there any instruction that could cause this behaviour?

Is there an ATOM fault finding guide anywhere, like there is for the Beeb? I don't remember seeing one.

Pete

[hoglet]

Has anyone any ideas what might be going on? I don't think the 6502 has a Halt mechanism other than RDY, does it? Is there any instruction that could cause this behaviour?

There are certain undocumented 6502 opcodes (called KIL) that will halt the processor:
https://www.oxyron.de/html/opcodes02.html

A RAM fault can cause a "jump into the weeds" resulting in one of these being executed.

Dave

[oss003]

Hi Pete,

can you check with your scope the signals on pin 13,12,3 and 4 of IC 9 to see if there is any noise present when pressing BREAK?
Maybe IC9 is bad.

For testing, you can remove IC1 (6522) or IC25 (8255) to see if one of these IC's create noise on the line.
Only the 8255, 6502 and 6522 are connected to the Reset signal or do you have some external boards connected?

Greetings
Kees

[MrSquiggles]

Hi guys,

Thanks for your comments.

@Kees: I took traces around IC9 at the weekend, from power-up and from pressing Break. I'm attaching screenshots (various zooms). I have already taken the VIA out. I think the traces were taken before that tho.

A couple of things I should add:

1. When I was working on it the Atom was only about the 20cm from my LCD monitor. The logic probe was between them, even closer. I think I shoud repeat the exercise with a bit more distance.
2. I'm using a Saleae Logic Probe. It has ground lines for each input. I may not have been ground lines to the appropriate places. Some of them may have been floating. I don't know how much this matters.

I will try removing the PIA next time. I don't have any extra boards. This Atom is almost "stock" minumum configuration, just FPROM + 1k of extra RAM fitted at #2800.

@Dave: Ahhh, I knew about there being some undocumented opcodes. I should have thought to check those myself, before I posted! Lots of KIL opcodes in that page you linked, all with bit 2 (0x02) set... and which set all data lines high. That feels like a bit of a smoking gun.

I will investigate this next time I get to work on it. I'll get the logic probe on those lines. I notice D2 has a 4k7 pull down at R40: am I right thinking any fault would need to actively drive D2 high to produce a KIL opcode?

As this is happening so early after reset, I'm thinking the fault is more likely in the main ROM than in RAM. I really hope it isn't - that is the one part I don't have a spare for: the ROM in my other Atom is already dead.

I have some 5V Arduinos. I'm thinking I may need to write a ROM reader/tester program to check the ROM (or other ICs) in isolation. That should be pretty safe, right? The ROM is fully static, isn't it? There aren't any problems running it slowly, even single-stepping addresses, are there??

Pete

[1024MAK]

Mask ROM chips are normally more reliable than the type of SRAM used in the Atom.

ROM chips are okay when used static or at low access frequencies. As are the SRAM chips.

All 0V/GND/ground leads used on test gear should be connected to a suitable 0V/GND point on the board or equipment under test. If there is more than one 0V/GND/ground lead, they should normally be connected to the same point.

The reset “pulse” to the processor should be a nice low to high “step” with no oscillations. However, in practice because of the chip that Acorn used, there may be a small number of oscillations as the voltage across the capacitor C11 changes slowly. But this should not cause the problems you are having.

R40 is not going to make any difference if another chip (ROM, RAM or other device) is driving the data bus. Typically when a memory chip (ROM, EPROM, RAM) fails, one or more outputs will produce either an invalid logic level, incorrect output but valid logic level (which could be “always low” or “always high”) or the pin will partly act as a short circuit affecting all devices on the same bus/line. With an Atom, it is possible to swap the SRAM chips around. Do label them and keep notes so you know what you have done.

Mark

[hoglet]

I will investigate this next time I get to work on it. I'll get the logic probe on those lines. I notice D2 has a 4k7 pull down at R40: am I right thinking any fault would need to actively drive D2 high to produce a KIL opcode?

Yes, but it would have to drive D1 high, not D2 (that also has a 4K7 pulldown - R39)

Does your Atom still have 2114 memory chips? Have you tried swapping them around?

Dave

[MrSquiggles]

Hi all,

@Mark: Thanks for your comments. Helpful info.

@Dave: Yes, still 2114s in both my Atoms. I've got lots of those to try!!

I was puzzled as to how the RAM could be a factor in this startup problem, but as you more experienced guys all seem to think so, I will certainly investigate further. (Plus, I think I figured out the "how" now, too!)

I did a bit more on this last night. I moved the Atom and logic probe well away. No difference. My monitor is not the source of the noise (nor anything else on my desk).

Following Kees' suggestion, I removed the VIA and PIA. I also removed the CPU, and just scoped the pins of IC9. No noise! I put the CPU back. The noise came back. Conclusion? The 6502 - or something closely related - is the source of the noise.

I'm not sure what to make of that. Coupled with the halting problem, I am inclined to think I have a failing 6502 here. Is that a fair conclusion?

So my next step will probably be to try the 6502 from my other Atom. I'm a little nervous of doing that in case there could be something wrong with this board that could damage it. (This is my "tidy" Atom I am working on here, btw. My "tatty" Atom is worse! I don't mind borrowing bits from it, but I don't want to just rob it. It's not that tatty!)

I didn't have a chance to investigate the halting any further yet. If the 6502 is flaky I am not sure if that is worth doing any more.

Pete

[hoglet]

I was puzzled as to how the RAM could be a factor in this startup problem, but as you more experienced guys all seem to think so, I will certainly investigate further. (Plus, I think I figured out the "how" now, too!)

If the RAM in IC51/52 is unreliable, then the 6502 stack will be affected, and RTS may return to the wrong address, eventually resulting in a KIL opcode being hit.

Dave

[oss003]

I never tried it but a Dutch Acorn Usergroup member did create a solution for this in the past by creating a flip-flop.
R38 and C11 must be in the Atom.

Greetings
Kees

[hoglet]

John Kortink also has a nice solution to the reset problem using a DS1818:

(twitter)

[oss003]

This looks like a supereasy solution ....... great find Dave.

Greetings
Kees

[MrSquiggles]

Hi guys,

Thanks for the suggestions. I like the DS1818 idea, so easy and neat. And, Dave, thanks for the reminder about the stack.

I've spent several more hours this weekend trying to get this working again. No progress.

I swapped ICs 51 + 52 (ZP RAM) with ICs 32 + 33 (video RAM). I regard the video RAMs as "known working", at least fairly recently. I thought putting the under-suspicion RAMs in the video would be an easy way to spot any stuck bits. I think all the RAMs are working OK.

I still have the PIA (IC25) removed. I have tied pin 35 of the 6847 VDG (IC31) to gnd to keep it in text mode. With that my monitor gets a good picture. I can see that the video RAM is not getting cleared.

I tried a different 6502 from my other Atom. The behaviour looked the same as the original CPU. (Sadly I didn't think to scope the /RST line for noise). I think the spare CPU is OK, at least it was when I last worked on the other Atom.

I spent a while trying to work out how to make the logic probe detect, and "trigger" on, a memory read with bit 0x02 set. That wasn't very successful, but in the process I have scoped out much of the address decode logic, especially IC23, and not spotted any obvious problems.

I can start trying components from this board in my other board. (I think the main problem with the other board is a failed ROM.) I haven't tried that yet. And I could start trying to build things to read and test ROMs and RAM ICs.

Apart from that, I am running out of ideas for what to try next. Any suggestions welcome!

Pete