Request help on replacing 2332 4Kx8 Char ROM -> Fixing a VIC

[Groovydrifter]

Hi!

I recently bought another VIC-20 that was sold as broken as I had a working motherboard and I needed case & keyboard to complete it. Once I did the change I couldn't resist to take a look to the broken board...

Surprisingly it had not a black screen as the seller said but a normal one with corrupt characters. You can't see what you''re typing but you can see that you're typing something and that the computer responds and does things. It looks as if someone had been there before replacing IC as most of the big ones are socketed. CONTROL+number changes to the correct colour, etc...

I then tried Gorf and a Poker cartridge and all worked normal, some vertical lines in the blue background but those most VIC-20 have them. So... Does this mean that the VIC-I is ok? Don't know.

I decided to try first replacing the char rom, as I thought that it would be as easy as replacing the Kernal and Basic ones that I replaced before in some other VIC-20s.

I was wrong. It did not work. I then gone to the board scheme to try to find out why it did not work and I found that the VIC uses both the CS lines the 2332 IC has, each one connected to two different address lines coming from the VIC-I. Ad that is the problem.

I've found datasheets calling those pins CS1 and CS2 and datasheets calling them CS and /CS. I'm replacing the ROM with an 2732 EPROM, so I must adapt the lines, but how... Both /CS and /OE (/E and /G depending the maker) lines are active LOW in the 2732 EPROMS but CS1 and CS2 I don't know... both high? CS and /CS looks like more clear to me, but does it depend on the make of the chip the signal needed? or CS1 must be active low and CS2 active high?

Supposedly 2532 EPROMs are pin to pin compatible to 2332 ROMs, so theoretically the VIC-20 should drive high pin 21 (vpp) and low pin 20 (pd, power down active high, so equivalent to /CS)... following the VIC-20 Scheme this is VA13 low and VA12 high wich is /BLCK4 low and CA12 High... wich translates in the CPU addresses 9000 -> 9FFF...

but these are the positions the VIC is... they should be 8000 -> 8FFF so pin 20 is still low but pin 21 is no longer high... and this means taht if you put a 2532 it will have vpp low and supposedly this should not happen...

So my conclusion is that I'm doing something wrong, can somebody please point me in the right direction, please?

HELP!

[srowe]

Is the PROM beyond redemption? Have you tried cleaning the pins with denatured alcohol and refitting? It might just be suffering a bit of corrosion.

[Groovydrifter]

I'm not really sure if it is even the PROM what is failing, but yes, as I had to desolder the IC from the board the pins are clean. This was one of the few "big chips" that wasn't already socketed. With the IC in the socket it acts the same as when it was soldered. There are two more still soldered, the Basic PROM and one of the VIA's, but both them seem ok, keyboard works, runs programs... you just can't read nothing from the screen unless a cartdrige is used.

I'm going to plug a Super Expander as soon as I go home to see what happens...

[srowe]

Ah I forgot that newer versions had it soldered down.

This pinout

http://ist.uwaterloo.ca/~schepers/ROMS/PINOUTS/2332.png

suggests that CE2 is active high, I'd just wire it to Vcc and connect /CE1 to the /BLK4 line.

[Mike]

suggests that CE2 is active high, I'd just wire it to Vcc and connect /CE1 to the /BLK4 line.

You need to discern between the CPU address bus and the VIC address bus. The VIC chip never asserts the /BLK4 signal, as UC5 is only active for BLK select signals generated by CPU accesses (S02 goes to G1 of UC5).

Even if that were not the case, it would still render the VIC-20 non-functional, as then the character ROM not only appeared at $8000 but also would be mirrored to $9000, which would give bus contention with VIC, the two VIAs and the colour RAM.

Actually, both CE1 and CE2 are _active-low_ with the 2332 built into the VIC-20 - whether these two pins are active-low or -high could be selected as bond-out option, BTW. Their connection to VA12 and VA13 makes sure the character ROM appears at the correct address from VIC's view, which happens to be $0000!

I'm going to plug a Super Expander as soon as I go home to see what happens...

That won't improve anything, as the VIC chip can't access anything on the expansion port. The cartridges only work, because they copy a modified character set into the internal RAM (which the VIC can access), and VIC displays the character patterns from RAM then. However, Super Expander does not feature such a soft-loaded character set, it 'just' starts through into the normal text mode, which requires a functioning character ROM.

[Groovydrifter]

That won't improve anything, as the VIC chip can't access anything on the expansion port. The cartridges only work, because they copy a modified character set into the internal RAM (which the VIC can access), and VIC displays the character patterns from RAM then. However, Super Expander does not feature such a soft-loaded character set, it 'just' starts through into the normal text mode, which requires a functioning character ROM.

You're 100% right, it did not. At least my diagnostic pointing to the char rom as the culprit looks correct.

So, to replace the 2332 PROM with a properly wired 2732 EPROM I need to, for example, wire CE1(20) in the socket to /CE(20) in the 2732 EPROM, CE2(21) to /OE(18) and A11(18) to A11(21), so it will be enabled by (CPU) /BLCK4+CA12(low) or (VIC) VA13(low)+VA12(low) wich translates to addresess 8000-8fff (CPU) and 0000-0FFF(VIC), am I correct?

I'm going to try this!

[Mike]

Yes, that should work. It needs to be a particularly fast EPROM in any case, with access times not exceeding 300 ns.

so it will be enabled by (CPU) /BLCK4+CA12(low) or (VIC) VA13(low)+VA12(low)

The character ROM completely 'sits' on the VIC side of the address and data bus. While the CPU is allowed its turn in each cycle, the address bus buffers UD8 and UE8 are opened in the direction CA -> VA and then VA13 becomes /BLK4.

The data bus however remains separate, unless BLK0 (excluding RAM1..3) or BLK4 (excluding I/O2 and I/O3) are accessed by the CPU. Then, the data bus buffer UF8 is enabled, with direction CDx -> BDx for write cycles and CDx <- BDx for read cycles.

[Groovydrifter]

Well, the adapter worked! so lets call it a partial success because the char rom was not the problem...

[youtube]zx4bbJAU1zs[/youtube]

These sort of counters running in some chars... any ideas?

Edit:

I have two damaged VIC IC's, so why not check if it is the VIC that is bad too? At least I know how these two VIC's fail, the IC is already socketed...

Surprise...



I then strightened the pins (15 - 16, DB1 -DB0) and inserted it back in it's position... no change, so I removed it again and put in one of the known failure ones.

It booted perfectly, presenting the failure I already knew. Another VIC bites the dust .

[Mike]

Maybe you should have shown that Youtube video in the first place.

It shows, that not the character ROM is the problem, rather VIC for some reason points the character base address into the zeropage, which is why you see the counters.

What happens, when you enter POKE36869,240 blind?

[Groovydrifter]

The screen continues with all the caracters garbled, but some of them change the shape. The computer responds with a garbled READY and shows the garbled cursor. I've also noticed that C=+SHIFT changes the screen like if there was no char rom inserted, completely ramdom lines appear in all characters.

Yeah, the video would have been a good idea, I'm learning... consider that I touched a VIC-20 for the first time 3 months ago and this week I see the board scheme for the first time too... I have too much info in my head just now and probably not the right one.. hehehehe

[Mike]

Well, ok. If you insert the suspect VIC into a working VIC-20, and the error goes with the VIC chip, then it's defective. In that case, it looks as if the base register of screen and character RAM in 36869 has bit 3 (value 8) stuck at 1.

I first suspected an errorneous init table in the KERNAL, with the value for 36869 having its bit 3 flipped, in which case the POKE I gave would have restored the correct display (and you'd have had to burn a new KERNAL EPROM).

Eventually the error could be nailed down by reading out 36869, and checking whether it contains another value than the correct value of 240 (with no expansion or +3K), or 192 (with +8K or more) - but of course that's a bit difficult to check with a garbled display. Maybe like this:

Code: Select all

POKE36869,240:IFPEEK(36869)<>240THENPOKE36879,26

If 36869 doesn't hold the correct value after the first POKE, the border colour changes to red (note the third address contains a 7 as fourth digit!).

[Groovydrifter]

ufff... I had to type it several times, because I was getting two response lines, I suppose one with an error and then the ready prompt, but finally I achieved to type this blind and the border stayed cyan. Then I typed just the final poke to check if it was going to change anyway and yes, it did turn red.

If you remember this thread: Vic 20 color strangeness

I finally bought those two VIC-20 on ebay with the VIC malfunctions as a hidden "gift" and put them in good service replacing the VIC IC's. I keep in a jar all the faulty chips I replace, so I digged for them, I tried them in this board and they showed the same fault that they had in the other boards, with no additional malfunction whatsoever. The repaired VIC-20 have now working VIC ICs in sockets, but I cannot take them out as I sticked to them a heatsink and I can't reach the IC to pull it out without risk of breaking it.

But as I said I'm learning, and I'll keep this board once it's repaired as a test one after moving to sockets all the IC's that already are not.

[Groovydrifter]

Well... final update: The VIC was replaced and the computer is fixed now. I bought one from Spirantho's shop with a heat sink pre-installed.

I will like to ask two questions about some image distortions most of my vic-20 have...

First, I see on most of them some vertical darker lines. Adjusting the level of the cvbs using the variable resistor makes them almost disappear in the white part, but they are still visible in the colored parts (and colours look washed).

And second, the characters are displayed distorted depending of the color they are. Blue ones are very nice but the same characters in red are VERY distorted.

Is there a fix for any of these problems? Already replaced electrolytic capacitors with no success (other than finding one big 2200uF capacitor burnt and about to burst...)

[Mike]

First, I see on most of them some vertical darker lines. Adjusting the level of the cvbs using the variable resistor makes them almost disappear in the white part, but they are still visible in the colored parts (and colours look washed).

That's quite normal. It's the clock circuitry coupling into the video signal.

And second, the characters are displayed distorted depending of the color they are. Blue ones are very nice but the same characters in red are VERY distorted.

That's also quite normal, especially the difference between the colours - white, black, (light) blue and (light) yellow are okay; all others are distorted. There's a lot of cross-talk between chroma and luma, where parts of the chroma signal get mistaken for luma information by most monitors and TV sets, especially for PAL.

This can be fixed by the S-Video mod.

[Groovydrifter]

Thank you! Very interesting reading. So the fist step may be re-adjusting the variable capacitor I should have never touched...[emoji15] and then do a s-video mod...