Diagnostic Tools for the Vic-20

[MCes]

Why the old PAL & NTSC distinct Diagnostic tool version and not my pal/ntsc cable free hacked version of Diagnostic Tool? and why not my new DeadTest version with additional Keyboard and Video/Audio tests too?

It's just a misunderstanding: "OLD" as "improved mbla000 CLASSIC", "OLD" as "not unreleased"

I corrected my previous post to be clearer

[orion70]

3) an hardware LOGIC STATES ANALYZER on board useful for a VIC20 that does not boot up(not even with DEAD TEST).

Could it be of interest to anyone other than me?

Yep, count me down for one! Dead VIC-20s diagnosed via a LED display - it would be VERY useful.

[beamrider]

I'd be interested depending on cost.

[chysn]

Could it be of interest to anyone other than me?

Given that (1) I seem to be accumulating VIC-20s, (2) I'm gaining greater interest in hardware repair, and (3) I know you make good stuff, then yes, I'd be interested in such a project.

[USA_Joe]

I'm having a strange issue with a VIC-20 CR. The issue is that it fails the diagnostics test for the datasette port. The odd thing is that the datasette can read and write to and from different cassettes without any issues. I tested the diagnostics components on a different VIC-20 CR I have, and everything passes.

What exactly does the diagnostics datasette test check for when it is running? It has been recommended that I use a oscilloscope to compare what's happening on the two VIC-20's when the diagnostics is running. Before I do that, I'd like to know how the diagnostics checks the datasette port.

Thank you!

Joe

[Marsupial]

I am trying to understand what can make the diagnostic report a bad checksum.

I guess the way dead test and diagnostic validate the ROM chip are different, but I followed the advice from Mike on this forum and downloaded a binary of the character ROM, which verifies as good on my VIC-20.

Yeah I made a typo when I renamed it

The diagnostic still declare the ROM as bad, with a checksum that changes every time I run it.

Checksum value changes everytime

I don't understand how that can be. What can make the checksum change everytime if the CPU can get to every bits and successfully verify every time?

Am I missing something?

Is the motherboard at fault? Or the diagnostic?

Motherboard is rev B w/ 2-pin power plug.
I tried 4 different diag from various sources including the ntsc/pal from the first post of this thread.

Help would be greatly welcomed, I am at a loss...

Thanks!

[USA_Joe]

I just noticed something on the second screenshot image. The clock is missing from the diagnostics screen.

Even a BAD ROM diagnosis should still show the clock on the screen

On a C64, if the same thing happened during a dead test, the CIA chips were suspect. On the VIC 20, those would be the VIA chips (6522's). Now this is just a guess on my part, but not seeing a clock on the screen reminded me of a C64 I have that had a bad CIA chip and a faulty trace. The ROM's are connected to the CIA chips on a C64. Not sure about the VIC-20, but it's likely the same except the VIA's.

Perhaps you might want to start checking traces for the ADDRESS BUS, and the DATA BUS. Start from the CPU, and following the path for each pin and check for continuity. This is how I found the bad trace on the C64. It was under the chip, so it wasn't visible until I pulled the chip based on the continuity testing.

Good luck!

Joe

[Marsupial]

Great catch!

Being my first use of the diagnostic on VIC-20 I wondered what this was.

Now that you mention it, I remember seeing times there in YouTube videos.

The two motherboards I have behave like that. I'll ping the whole boards as time permit.

Thank you!

[Marsupial]

I think I know why I have these issues.

the Diagnostic ROM is intended to run on a cart that has memory expansion - I am trying to run it on a non-expanded cart. I am new to VIC20 but most software I tried complained when they required a (missing) memory expansion... but not the diag. It seemingly runs OK until it gets these errors.

I'll look at building a proper diag cart and see if it resolves the problem.

[Orangeman96]

the Diagnostic ROM is intended to run on a cart that has memory expansion - I am trying to run it on a non-expanded cart. I am new to VIC20 but most software I tried complained when they required a (missing) memory expansion... but not the diag. It seemingly runs OK until it gets these errors.

Like a "traditional" 8K (e.g., VIC-1110) or 16K (e.g., VIC-1111) memory expander cartridge? -OGM

[Marsupial]

I guess those would work, wouldn't they?

I currently only have DIY style cart PCB (and a few game carts) and none has memory expansion.

[Mike]

Please check out https://www.zimmers.net/anonftp/pub/cbm/firmware/misc/vc-20diag/vc-20-diag.zip, the file 'cart-pcb.jpg' in particular.

The diagnostic cartridge requires RAM in RAM1 ($0400..$07FF) for own workspace variables. What is used as carrier is the same PCB that is otherwise used for the +3K RAM expansion or the Super Expander. A +8K or +16K RAM expansion will not provide RAM in RAM1 and that is bound to perpetuate the errorneous behaviour of the diagnostic!

...

That being said - after the culprit (defective colour RAM socket) has now been found, is there still any problematic behaviour of the VIC-20 in normal use, or are you just hunting a ghost because the diagnostic itself could not work correctly?

[Marsupial]

Having had these two dead motherboards brought back to life, I wanted to confirm all is good with the chips in a deeper manner than just running software (I still have a limited software library on the Vic)

The diag was meant to tell me if I had omitted something.
That's what I do after fixing a 64, but I have built the C64 diag suit long ago.

So far all my poking, scoping and prodding and all my gameplay... I mean testing... Make me believe there is no more problems.

Thanks for confirming the diag need its expansion. Resources online aren't exactly clear on that and I had originally missed this fact.
Unsure why I didn't see this bit of info on Zimmers before.

I am currently attempting to add a RAM1 1k expansion to a cart PCB in order to get a working diag. Part of the fun is to make the tools, and I've learnt more about VIC20 architecture trying to make this diag cart than I originally imagined.

Thanks a lot for the help, it really is appreciated!

[Orangeman96]

I am currently attempting to add a RAM1 1k expansion to a cart PCB in order to get a working diag. Part of the fun is to make the tools, and I've learnt more about VIC20 architecture trying to make this diag cart than I originally imagined.

Thanks a lot for the help, it really is appreciated!

Although I am not sure how much I actually helped, you are welcome!

I am not sure this will help as well, but there are two 3K VIC-20 memory expansion cartridges produced by Commodore to fill memory locations 1024 through 4095 (0400 through 0FFF in hexadecimal); namely: the VIC-1210 (without 'Super Expander') and the VIC-1211A with 'Super Expander'.
(Also please note that the VIC-1211M is the Japanese version of 'Super Expander', however there are significant differences between the VIC-1211A and VIC-1211M well-explored/discussed by MIke, and others, here.)

If at all possible, I recommend rerunning the diagnostic with actual memory present at locations 1024 though 4095 (decimal) to fully simulate/emulate a 3K memory expansion in toto.

Very respectfully yours,

OGM

[Marsupial]

Thanks for pointing these out. I've been digging quite a lot in order to come up with a plan that is hopefully functional. The more comparable the better.

I'm basing my tentative cart alteration from the work of Sven Petersen - he states only 2 chips (2114) are needed for the diagnostic cart. From his reverse engineering schema of the super expander, we see that the 2 other k of ram are on ram2 and ram3.

http://tech.guitarsite.de/vic-20_diagnostics.html

That's why I hope to be able to run the thing with a partial expansion.

I'm almost ready to test and will report any findings.