Strange video problem

[craftsman1234]

I have noticed a problem on my Vic-20. Pet keyboard model.







There is a small pixel that appears on the screen. I first thought that it was a flaw in my Gorf cartridge but once I obtained a 8k Ram expansion I was able to test Gorf by loading it in. It seems to occur after the Vic has been on for 5 or more minutes.

The same pixel issues effect Jellymonster when loaded and can be seen in the photo. In areas that are cleared the dots are eaten only to be replaced by 2 smaller ones.

Any ideas? Bad ram?

[eslapion]

This "faulty pixel" seems to appear in one specific character so yes, I assume one bit is faulty in the ram between $1000-$1FFF.

[craftsman1234]

This "faulty pixel" seems to appear in one specific character so yes, I assume one bit is faulty in the ram between $1000-$1FFF.

Thanks, I was hoping not to have to replace any of the Ram Chips. Do you know on an original Vic-20 which of the chip would control this area of memory. It is possible to overlay a new ram chip to test it?

[phvic]

Memory addresses $1000-$1fff map to the two 2k x 8 SRAM chips, U15 M58725P and U14 M58725P in the VIC-20cr schematic, unless I'm mistaken. The lower 2k maps to U15 and upper 2k maps to U14.

Please note that I'm a total newbie and I just found this out by looking at the schematic, so take this with a grain of salt. Here's my logic so you can verify it: Memory addresses $1000-$1fff have bit 12 high, which causes the 74LS138 decoder (UC4 in schematic) to select output lines 4-7, which are connected to the 2k x 8 SRAM chips.

If I were you I would write a simple program to test the memory. I.e. write & read back some data to find out the exact faulty memory address.

Hope you get your vic fixed!

[Mike]

If there was a hard RAM fault, the RAM test routine in the OS would end up in an endless loop (blank white screen with cyan border). There are also other types of RAM faults, where the bit cell 'forgets' the correct value, albeit only after a few µs, which would go undetected by the RAM test routine.

Exactly which kind of VIC-20 do you own? Is the power-plug of the 2-prong type or is it a round DIN connector (the latter which would imply the CR model, as described by phvic).

If you have a memory expansion of +8K, or more, you can check as follows:

First type in:

Code: Select all

POKE44,32:POKE8192,0:NEW

This moves the BASIC start into the RAM expansion, then enter the following program and RUN it:

Code: Select all

1 FORT=4096TO8192:A=PEEK(T)
2 POKET,85:IFPEEK(T)<>85THENPRINTT:STOP
3 POKET,170:IFPEEK(T)<>170THENPRINTT:STOP
4 POKET,A:NEXT

The program performs mostly the same test as the RAM check (it leaves out the lower 1K), but is much slower - if a weak bit toggles between POKE and corresponding PEEK, the program ought to catch it - and then the address of the faulty RAM cell is printed. From this we can conduct, which chip is at fault.

When you have a +3K RAM expansion, you can run the program straightaway, without the preceding 'POKE44,...'.

[craftsman1234]

If there was a hard RAM fault, the RAM test routine in the OS would end up in an endless loop (blank white screen with cyan border). There are also other types of RAM faults, where the bit cell 'forgets' the correct value, albeit only after a few µs, which would go undetected by the RAM test routine.

Exactly which kind of VIC-20 do you own? Is the power-plug of the 2-prong type or is it a round DIN connector (the latter which would imply the CR model, as described by phvic).

If you have a memory expansion of +8K, or more, you can check as follows:

First type in:

Code: Select all

POKE44,32:POKE8192,0:NEW

This moves the BASIC start into the RAM expansion, then enter the following program and RUN it:

Code: Select all

1 FORT=4096TO8192:A=PEEK(T)
2 POKET,85:IFPEEK(T)<>85THENPRINTT:STOP
3 POKET,170:IFPEEK(T)<>170THENPRINTT:STOP
4 POKET,A:NEXT

The program performs mostly the same test as the RAM check (it leaves out the lower 1K), but is much slower - if a weak bit toggles between POKE and corresponding PEEK, the program ought to catch it - and then the address of the faulty RAM cell is printed. From this we can conduct, which chip is at fault.

When you have a +3K RAM expansion, you can run the program straightaway, without the preceding 'POKE44,...'.

My Vic-20 is an original Pet Keyboard model with the two prong power supply.

I'll give this test a try. If you are using no expansion is the test the same?

I've used the following test from this page while the 8k ram is installed. No error.

http://www.paradroid.net/vic20ram/

[Mike]

two prong power supply

O.K., then the 5K internal RAM consist of ten 2114 SRAMs. An additional 2114 SRAM holds the 1K nibbles for the colour RAM, but this one is not affected.

If you are using no expansion is the test the same?

The program only tests the internal memory in the range 4096 to 8191, not any external RAM.

You can't run the test without a memory expansion, because program and variable data then reside within the checked range. While a byte is tested, its original value is (temporarily) overwritten with two test values, which would either 'shot' part of the program, or its variable data. Even though I mentioned the requirement of a memory expansion, I thought the reasons for this would be obvious ...

[craftsman1234]

two prong power supply

O.K., then the 5K internal RAM consist of ten 2114 SRAMs. An additional 2114 SRAM holds the 1K nibbles for the colour RAM, but this one is not affected.

If you are using no expansion is the test the same?

The program only tests the internal memory in the range 4096 to 8191, not any external RAM.

You can't run the test without a memory expansion, because program and variable data then reside within the checked range. While a byte is tested, its original value is (temporarily) overwritten with two test values, which would either 'shot' part of the program, or its variable data. Even though I mentioned the requirement of a memory expansion, I thought the reasons for this would be obvious ...

Mike,

I plugged in my 8k ram expansion and typed the the first poke commands and then the program. You can seen the program change the characters on the screen and continue for a minute or so after that . The program does not find an error and ends.

I ran it 5 times.

[craftsman1234]

two prong power supply

O.K., then the 5K internal RAM consist of ten 2114 SRAMs. An additional 2114 SRAM holds the 1K nibbles for the colour RAM, but this one is not affected.

If you are using no expansion is the test the same?

The program only tests the internal memory in the range 4096 to 8191, not any external RAM.

You can't run the test without a memory expansion, because program and variable data then reside within the checked range. While a byte is tested, its original value is (temporarily) overwritten with two test values, which would either 'shot' part of the program, or its variable data. Even though I mentioned the requirement of a memory expansion, I thought the reasons for this would be obvious ...

Mike,

I plugged in my 8k ram expansion and typed the the first poke commands and then the program. You can seen the program change the characters on the screen and continue for a minute or so after that . The program does not find an error and ends.

I ran it 5 times.

Okay an update. I recalled that the pixel could be overwritten by game graphics but would show up a few seconds later and this gave me an idea. I added a for/next loop to increase the time between writing to memory and reading it.

Numerous times running the program and it now exits at

5378

[Mike]

5378

That's in the range of 5120 to 6143, provided by the two chips UE4 and UD4. Furthermore, the sticky bit is located in the upper nibble, so this must be UE4 at fault. I would set a socket and replace it rightaway, no point in further checking with the piggyback method you mentioned.

[craftsman1234]

5378

That's in the range of 5120 to 6143, provided by the two chips UE4 and UD4. Furthermore, the sticky bit is located in the upper nibble, so this must be UE4 at fault. I would set a socket and replace it rightaway, no point in further checking with the piggyback method you mentioned.

Mike, thanks for the fast reply. Do you or anyone on here recommend someone to get the chips and sockets from?

[craftsman1234]

Update. Well I drove from North Denver to Colorado Springs about 90 US miles to check on a Vic-20 several carts, tapes and a 24k Golden Ram Expansion Chassis going for 50 US dollars. Well got there and it was a pawn shop. The owner had owned a Vic-20 and 128 so at least he knew what they were. He was not able to test it with the TV's he had so I told him that I with offer 20 for the lot and not worry about the 30 return policy that he had. He took 25.

I was really after the expansion board.

The next part of the journey was to get the 2114 chips to repair the ram in the other Vic. There is a store in Colorado Springs that is called OEM. They have just about everything you can image for recycled and new PC parts. They had the sockets for the Vic-20 ram and I picked up additional 28 pin sockets for the 64's.

The ram I got was labeled NEC 8402A5 μPD2114LC

When I got home I removed the old chip at UE4 and installed a gold socket and the new chip.

After turning on the Vic-20 this is what it shows.



I had gotten several of the Ram chips so I tried each one. No luck.

1 time out of 10 if I plugged in the cartridge (Cosmic Cruncher) the program would load.

The solder job looks okay. Did I get the wrong Ram chips? The chips on the MB are OKI MSM2114L3RS 1563

Lucky I have another working Vic now that shows 28159 bytes free.

[eslapion]

The ram I got was labeled NEC 8402A5 μPD2114LC

These chips don't appear to be standard 1k x 4 bit SRAM chips at all.

You should've checked to see if you can find a datasheet for them before plugging them in. You might have damaged your VIC.

[craftsman1234]

The ram I got was labeled NEC 8402A5 μPD2114LC

These chips don't appear to be standard 1k x 4 bit SRAM chips at all.

You should've checked to see if you can find a datasheet for them before plugging them in. You might have damaged your VIC.

Thanks, lets home not. I have some 2114 on the way.

[Mike]

Ouch, sorry to hear about the new problems you got.

The ram I got was labeled NEC 8402A5 μPD2114LC

Those *are* SRAMs. However, I've seen photos of NEC µPD2114LC in the 'net with '-5' behind the type, i.e. 500 ns. If there is no indication of access time behind a hyphen, this most probably means you got chips which are even slower than 500 ns.

Anyway, 500 ns are already too slow for the VIC-20. Take SRAMs with access time of 300 ns, if possible, which would be indicated by '-3' after the type. 400 ns (with '-4') might also work.