Rybags

Possible IO conflict? Modem and speech synth would likely have used memory-mapped IO, likely on D6 or D7 pages. Though if done as PBI mapped devices maybe not. Some people have built 1400XLs though unknown if they're fully equipped.

600XL or XEGS I think might be best suited to a transparent case. You'd need to lose the shielding (top at least) to make it worthwhile. Keyboard would hide much of the internals so maybe XEGS would be the preferable one. 1200XL would probably be OK in terms of being able to see lots of the innards but it's probably the best looking of the later machines and best left alone.

For sure it would be Antic. If bad Ram was producing similar symptoms you'd expect the distance between each corrupted cell to be a power of 2 - though if Ram was that bad the computer probably wouldn't even power up successfully.

I'd not worry too much about SSD writes. I went to all SSD about 4 years ago (just have a 4 TB spinny in a removable bay that I occasionally turn on). My current setup is 500 GB nvme drive and 2 x 1 TB SSDs, one mainly for games/emu and the other for torrents/general storage. The storage one is the older and is a Samsung QVO (quad level cells = somewhat lower # of write cycles) Current state is 35,000 power on hours, 93730 GB writes, health at 100% - I think these are good for ~ 300-360 write cycles so it's just under 1/3rd through it's useful life. And this is a computer that for the most part is only powered down for cleaning, upgrades or if I go away for more than a couple of days.

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.