Rybags

OK, I see. What we need now then - modify my original program and put a graphics character in place of the zero in line 40. I might suggest try CTRL-Y there - that should show PF1 for 4 pixels then PF2 on 4 pixels in the top scanline.

In the early 2000s we'd generally get CPU temp from a sensor on the motherboard under the CPU itself - these will generally read well under what the core based sensors return so hitting high 80s and beyond isn't really a problem with newer CPUs. The good thing about modern CPUs is that (unless you override with BIOS settings) they will throttle automatically once temperatures become a danger. You can also notice a core sensor reading will go up and down rapidly in accordance to load where the motherboard based ones had a lot more lag. For a CPU with lots of cores you could find a sweet spot - likely running 60-75% # of threads vs logical cores available would get a lot done without too much heat or making everything else sluggish.

How are your temps going though? I've got an i5-14600KF (6P,8E cores), air cooled and it fairly easily hits 100C doing Handbrake AV1 video conversions set to use 5 cores (10 LPs) Though the modern CPUs are designed to operate that way, just throttling down once TjMax is hit.

U1Meg would remove the need for OS and MMU but if the fault lies elsewhere you get left with a non working modified machine which would be even harder to debug.

Clock crystal would only be relevant if it's a PAL computer (check the 4~ MHz one) - NTSC uses the same one for CPU and colour generation and without it the computer wouldn't work at all.

Antic just pumps data/commands to GTIA and isn't directly involved in colour generation. The colour pot comes into the CADJ pin - I'm not 100% here but without that or with a wild value you should still have colour but just not necessarily in the right order. The COLOR output pin from GTIA outputs a phase shifted square wave which I believe is converted to the necessary sinewave by external componentry in the video output circuit. I would guess your problem likely stems from a failed passive component, maybe a capacitor. There's various schematics around which might give ideas of where to look.

Internal line buffer was an early theory I had also. But a weird thing - the badline doesn't seem to be OK if you look closer - check the Bruce Lee screenshot and the video of the early program I posted, the first badline of the character is showing PF2 where you'd expect that character to be PF1. It's as if that particular sequence of reads is returning FF,FF. Though that said, according to the Altirra HW manual - in this situation there are 2 character codes read before the first character set data is read so the spurious reads aren't on adjacent cycles.

MMU performs multiple functions and not all are needed in most cases so a fault could theoretically go unnoticed in some situations. Carts working or not - diag mode carts will sometimes work when a machine goes to self test or doesn't even start normally. Other carts sometimes will work OK as they usually have a fixed memory usage architecture - games will usually only touch the first 8 or 16K.

Looks like it does - that's the OS Rom at $F000 so it should be fairly random with no obvious repeating data in that area.

That's Antic 4 - the weird looking characters are as they should appear. Can you try changing it - add 25 SCRBAS = 61440 : SCR = 240 I think that should work to make it look at Rom for the screen data.

What might be worth trying also - have it read the screen characters exclusively from Rom and see if the same artifacts occur.

Donkey Kong? or some game that has no h-scrolling. But regardless of extra testing it would seem you have an Antic there that's probably got an irreversable fault.

So it is... I didn't realise Bruce Lee was in wide mode. Now it'd be interesting to see a game that just uses normal width.

Can you try this program in Basic? If possible get a video. 10 GRAPHICS 0:POKE 82,0 20 D=PEEK(560)+PEEK(561)*256 30 POKE D+3,82 40 FOR A=1 TO 5:? "0123456789";:NEXT A 50 FOR A=0 TO 15 60 POKE 54276,A:GOSUB 200 70 NEXT A 80 FOR A=15 TO 0 STEP -1 90 POKE 54276,A:GOSUB 200 100 NEXT A 110 GOTO 50 200 FOR Z=1 TO 150:NEXT Z:RETURN

Possibly an Antic problem. Boulder Dash uses Mode 4 with scrolling but Bruce Lee uses 5 without - the corruption seems to be at the second last normal display character. If it was a memory problem, you'd probably expect the corruption to move with the scrolling in BD - does it do that?