Doom Video glitch problem "SOLVED"

[Imperious]

Hi Everyone.

My Early model Vic (Pet style keyboard PAL unit) has a weird glitch, especially noticeable running Doom.
As You can see black vertical bars where wall graphics should be.



I have a self made 32k expansion as well as the 3k Super expander to give the 35k extra required.
So far I have done the following as diagnosis

1. tested all Memory blocks, all passed.
2. Tried running a few unexpanded games only, no probs there
3. Tested all the 2114 chips by putting a new one over each, one by one.
4. Swapped out 6502
5. Swapped out 6561E chip with a 6561-101

What I'm leaning towards as the culprit is a dodgy Character Rom chip, and it would help prove that if my suspicion that VicDoom uses
Petscii characters for graphics is correct?
Another weird behaviour is I was testing the Text Colour change in basic by pressing CTRL-Number keys and occasionally got letters instead.

Any Vic hardware guru's got any ideas?

[Mike]

Here's the rub:

I have a self made 32k expansion as well as the 3k Super expander to give the 35k extra required.

The Super Expander cartridge comes with a ROM mapped to $A000 .. $AFFF in BLK5 that clashes with the RAM of your 32K expansion in that range.

my suspicion that VicDoom uses Petscii characters for graphics is correct?

Are you kidding?

Another weird behaviour is I was testing the Text Colour change in basic by pressing CTRL-Number keys and occasionally got letters instead.

That would be a contact problem of the keyboard unrelated your RAM expansion issues.

...

Edit: I see you're the same guy from over at Lemon64, who didn't get VIC Doom running, with those issues, and already was aware of the Super Expander ROM and RAM clashing.

If you just disconnect the +5V from the power supply pin of the ROM you open the door for all funny behaviours of the logic in the ROM chip! One of the first lessons learned in digital electronics courses is, that logic signal pins should never see voltages applied to them when there's no supply voltage. So you have something sitting on the external address and data busses that messes up the signals in multiple ways.

Break the trace leading from the edge connector of the cartridge going to the OE pin of the ROM, and install a switch that either pulls up the OE pin over 4K7 to +5V or reconnects it to the edge connector of BLK5. Or remove the ROM chip entirely.

[Imperious]

Thanks for the reply.

Yes, I am the same Imperious from Lemon64, I was registered here before but some serious screw up happened when I tried to
retrieve my password and all my posts got deleted. Change of email address happened a bit later too.

I forgot to add that i'd tried disconnecting the Rom chip before, although only the VCC pin. Thanks for the tip about
that not being good enough. This time I'll remove the chip entirely and see what happens.
I won't likely repeat that mistake again either. That's also the first time I've heard that btw.

I have worked for years as a Electronics tech, but mostly in the days of CRT, VCR, Analog Audio systems, so exposure
to Digital electronics was practically non existent unfortunately. I know a heck of a lot more now than I did though,
always learning. I got into repairing pc's at work too, but You don't need any digital knowledge to fix them except back in
the early days perhaps whan a PC motherboard resembled that of a c64 with DIP ic's everywhere.

With respect to the Petscii graphics, looking at the walls in Doom, some of the blocks look a bit like the ones on the front
sides on some of the keys. It was really only a slight suspicion there and perhaps a major stretch of the imagination too.
I am aware that most create their own graphics for games.

Thanks for the help. I'll update this post after I've removed the Rom chip and tested.

[Imperious]

Update

No Dice I'm afraid. I pulled the Rom chip out of the superexpander and it made no difference at all.
I still have those black vertical lines where wall should be.

Unless someone has another suggestion I'll order some 27c64 Eproms, make an adaptor socket, then start with the character
Rom first.
My VIC has a Arfon Microexpansion with 7 cart bays, there could be a weird quirk with that, hope not though.

[Mike]

I still suspect there's something fishy with your self-made 32K expander.

For example, a fault in the BLK decode logic can easily lead to accesses of two different BLKs actually accessing the same byte in the RAM chip. Writes are thus 'duplicated' from one BLK to another BLK. A simple RAM check still will see both addresses writable, but won't see this duplication.

Here's a simple program to check for this kind of crosstalk (download). It will use only the first byte of all BLKs present, but you get the idea:

Code: Select all

10 POKE55,0:POKE56,30:CLR
11 DIMB(3):B(0)=1:B(1)=2:B(2)=3:B(3)=5
12 FORT=0TO3:AD=B(T)*8192:BY=PEEK(AD)
13 POKEAD,85:IFPEEK(AD)<>85THENB(T)=0
14 POKEAD,170:IFPEEK(AD)<>170THENB(T)=0
15 POKEAD,BY:NEXT
16 FORT=0TO3
17 IFB(T)<>0THENPRINT"BLK"CHR$(48+B(T))" PRESENT."
18 NEXT
19 :
20 FORS=0TO3:IFB(S)=0THEN30
21 FORT=0TO3:IFB(T)=0ORS=TTHEN29
22 A1=B(S)*8192:A2=B(T)*8192
23 B1=PEEK(A1):B2=PEEK(A2)
24 POKEA1,255-B2
25 IFPEEK(A2)<>B2THENGOSUB33
26 POKEA2,255-B2:POKEA1,B2
27 IFPEEK(A2)<>255-B2THENGOSUB33
28 POKEA1,B1:POKEA2,B2
29 NEXT
30 NEXT
31 END
32 :
33 PRINT"CROSSTALK BLK"CHR$(48+S)" > BLK"CHR$(48+T):RETURN

[tokra]

For example, a fault in the BLK decode logic can easily lead to accesses of two different BLKs actually accessing the same byte in the RAM chip. Writes are thus 'duplicated' from one BLK to another BLK. A simple RAM check still will see both addresses writable, but won't see this duplication.

I've seen this problem with the FinalExpansion on NTSC - while being a 35K expander I could not get Doom working. Mike's program does not check for crosstalk with 3K RAM in BLK 0 though.

I hacked the test a little to include BLK0:

http://www.tokra.de/vic/doom/crosstalk.prg

Also my program tests 4 addresses per block ($x000,$x400,$x800,$xc00). I just tested it with my FinalExpansion in NTSC and found that memory writes to BLK 1,2,3 or 5 will sometimes be duplicated to BLK0. It's not like every write duplicates to BLK0 but about 20% do. I've even had some runs of the program where it said everything was fine. Usually 2 to 3 failed writes per run though. So it might be a good idea to put this program in a loop and let it run for some time. Delete line 17 before doing this though, or you won't see when a failed write occurs.

[Imperious]

Thanks heaps for that, I'll give that a run and report back, likely before the Formula 1 race starts tonight (I'm in Australia).

Here is the 32k expansion I built.

[Mike]

Here is the 32k expansion I built. [...]

Yeah, that's exactly the design Eslapion, lordbubsy and I discussed in the thread 'vic-1110 8k ram cart upgrade (and other solutions)'. It uses a generic 32Kx8 SRAM and a 74LS08 to recombine the four BLK select signals into two address lines and a chip select. I'd take the wiring around the 74LS08 under extreme scrutiny.

Thanks heaps for that, I'll give that a run and report back, likely before the Formula 1 race starts tonight (I'm in Australia).

Good luck.

[tsm]

I'd take the wiring around the 74LS08 under extreme scrutiny.

You may want to unwire it from the PCB and test it with some DIP switches, pull-up resistors and a multimeter. Try every combination of the switches on the inputs and see if the outputs are correct. I did just this before putting it in my Super Expander. There's a nice truth table in the thread where the modification is described.

[Imperious]

Apologies for the delay, got sidetracked with other retro computer stuff.

I don't seem to get any errors at all from what I can tell, the program was running well over 15 minutes in a loop (video clip cut short deliberately).
Youtube vid attached. Let me know if I stuffed it somehow by modifying the wrong lines.
Couple of typo's but the "1" key is a bit dodgy on my keyboard.

[youtube]k0qKEzCbPUI[/youtube]

[Imperious]

It's taken me an awful lot of time and brain energy to finally figure out the cause of this problem, and in a way I am pretty
annoyed at myself as to the cause, but at the same time I have learn't bucketloads about how the Vic-20 works so definitely not
wasted time in that respect.
I even went down the unlikely path of redesigning the chip and block select part of the 32k memory expansion to use a 74hc21 as a
4 to 1 AND gate for the chip select, and a 74hct00 as the block select. At the moment the unused pins are floating, so I'll deal with that
if and when I get any problems. I had an idea that separating the ouputs of chip select and block select to different IC's might help.
Made no difference of course but I was clutching at straws. A different brand of Ram chip also made no difference, Alliance vs Cypress.

I have spares for every single IC in the Vic-20 so tried sitting new chips on top of their equivalent, that made no difference. Ram tests all passed
with flying colours. My Vic-20 had no problems with Kweepa's game "The Keep" so that proved there couldn't really be a video related problem as
both games appear to the untrained eye to have a similar style of drawing the graphics.

Where I mentioned this earlier "Another weird behaviour is I was testing the Text Colour change in basic by pressing CTRL-Number keys and occasionally got letters instead."
I got the same behaviour in Vice when I tried that a couple of days ago.

As it turns out there wasn't a single fault anywhere whatsoever inside my Vic, every part working perfectly.

The Moral of the story and Answer to the problem is "DO NOT USE A 65C02" processor as a 6502 replacement. As I got a couple of these very cheap
on Ebay to try and resolve intermittent crashing issues and left it installed as they run nice and cool.

So I'll probably order a couple of R6502's as spares, if there are any compatibility issues there that anyone knows about please let me know?

[Jeff-20]

Off topic, how are you capturing the video above?


Sent from my iPhone 6 Beta using Tapatalk

[Imperious]

I have an Avermedia H727 capture card in my PC, it has Analog and Digital tv. Composite, s-video, component, and Hdmi inputs.

I captured that through s-video from my Vic-20 with the Avermedia software which is absolute rubbish except capture functions produce a decent result.
The Digital TV is so bad I installed Mediaportal which is a Lot better.

[tokra]

The Moral of the story and Answer to the problem is "DO NOT USE A 65C02" processor as a 6502 replacement. As I got a couple of these very cheap
on Ebay to try and resolve intermittent crashing issues and left it installed as they run nice and cool.

I don't think the 65C02 does undocumented opcodes, does it? They are being used in Doom if I am correct: Doom code improvement-discussion

[Imperious]

You are correct, the 65C02 doesn't do undocumented opcodes, there were also other changes.

Doom was the only game I tried that gave problems, although there is still a lot of software I haven't tried.

Interestingly whilst doing some research about this I found out that when the Apple2C was released it broke some of
the software, which is because it used a 65C02.