Faulty RAM - interpreting diag cart.

[gmc]

I bought a faulty VIC20 (324003) off eBay that's had a hard life. Replaced the kernal and char rom's with 27c64's with a conversion board which brought it back to life. At least its now booting up and screen looks fine.

Amazingly the VIC and CPU are fine, it starts up and see's 3583 bytes.

When I run the Vic20 diag cart it fails on ram test 2 UC 0D BAD. The diag cart is somewhat cryptic and from what I can find online its one of the 2114 ram chips that are faulty.

None of them are getting hot and I've check continuity between them all and looked at the address/data lines with a scope and nothing stands out.

Any magic programs I can use to determine which chip is faulty. Otherwise its a case of desoldering them one by one and testing them

[Mike]

Amazingly the VIC and CPU are fine, it starts up and sees 3583 bytes.

That means the KERNAL RAM check reports $1000..$1FFF as most probably fine. Otherwise, you'd just see cyan border and white background but no start-up message. Even though the built-in RAM check is somewhat crude, this hints at the remaining $0000..$03FF RAM, which isn't tested. Of course, faulty RAM down there can lead to difficult to track errors while the computer is operating.

I could only find the schematic of the 324001 board, but the SRAM of the 324003 board should be arranged the same way, $0000..$03FF are stored in UD2 and UE2. I'd first try to replace these two and see if the diagnostic now reports fine.

[srowe]

I started writing a utility for just this purpose, but I've been busy with other things,

Here's the current version, it should be able to identify which RAM chip is faulty, there's no text yet so post a picture of the screen if/when it fails.

[gmc]

Awesome. Will give this a shot and let you know.

Thanks, Mike - very useful info.

[gmc]

Here's the current version, it should be able to identify which RAM chip is faulty, there's no text yet so post a picture of the screen if/when it fails.

Pic attached. Lots of red

Great utility. Its not open source by any chance? Would love to see how it works.

[srowe]

OK, I'm guessing you're running this with no expansion so BLK1,2,3 should be red as they're not present. The odd result is RAM1, you probably don't have a 3K expansion so this might be an artifact of the fault.

"RAMb" is the crucial result, the red block on the left means it's detected a data bus fault in bits 7-4 of $1400-1f77. For a 324001-3 board this should indicate that UE4 is to blame. It is possible that some other chip is faulty (like UC4) but if this is repeatable I'd suggest checking and/or replacing this chip first.

I'm happy to release the code, just hadn't got around to pushing it to the server yet.

[gmc]

I'm running this from a cartridge with no memory expansion. Results are repeatable to looks like UE4 is the issue then.

At least this narrows it down. I'll replace UE4 and see what happens.

Let m know if you publish to git or something.

Thanks again.

[MCes]

@Gmc
If you are using the Srowe's "dead-test" by plugging-in a rom into the diagnostic cart the RAM1 has a sense:
the standard diagnostic cartridge provide ram into RAM1.

[srowe]

Let m know if you publish to git or something.

Code is here, hopefully I'll get to finish it off sometime

https://eden.mose.org.uk/gitweb/?p=dead ... ;a=summary

[gmc]

Lovely. Thanks very much.

I've started tinkering around with Visual Studio Code and ACME + VICE. Boy have I forgotten a lot of asm in the last 30 years

Will let you know if I make any useful changes to the code.

[gmc]

Code is here, hopefully I'll get to finish it off sometime

https://eden.mose.org.uk/gitweb/?p=dead ... ;a=summary

After tinkering around for a few days and pulling my hair out, I finally wrapped my head around most of the code. Still some of it is over my head but I managed to cobble together some changes and published to git.
Added in pal/ntsc detection, changed the screen formatting, displaying chip references.

Could never get the main loop working with pulling in addresses and displaying the chip references so ended up pulling it all apart and just replicated the code. Not very efficient but seems to work. I'm sure I'll find a few bugs I introduced but have tried it out on 2 faulty Vics I had and looks promising.

https://github.com/StormTrooper/Vic20-dead-test/