Rybags

GTIA modes can only scroll at 80 pixel resolution, not 160. If done like that, character mode would be the likely avenue. But there's not really any advantage to be had here other than some extra colour. You could equally do a game in Antic 4 or 5 and just use chunky sprite movement for much the same CPU cost.

250ns is supposedly the maximul supported latency - though I don't think any DRam by that time was slower than 200.

Different numbers have been used to describe them. Supposedly 4464, 41464 and 2464 are much the same thing. I'm not sure on the exact reason, possibly when new chip carrier formats came out, or just different companies coming up with their own naming scheme.

4464 - no. That is the 4 bit x 64k DRAM. Only used by XEGS and 2/4 chip 65 and 130XE.

This appeared in my Google news feed. https://hackaday.com/2024/04/13/picontrol-brings-modern-controllers-to-atari-2600/ Not for USB controllers - just Bluetooth. But still handy as the latest couple of console generations tend to use Bluetooth.

Maybe slightly lift and reseat the major ICs. OS and Basic are the ones at top right near the serial plug (OS the bigger) Though that photo looks like not much is socketed at all?

The legacy video I would say is much the same, but entirely possible that it generates a stronger/more saturated colour signal which could affect mods that otherwise work well on a standard system. I can't recall if I tested RF on mine and probably didn't use the stock monitor port much either (600XL)

Are these components recommended for stock GTIA or Sophia usage case? By the looks of things the colour is way overdriven. Possibly the colour needs some attenuation. I don't think Sophia uses the tuning pot, it's just needed as the original GTIA uses internal delay taps which can have drift to achieve the phase delay where Sophia probably uses some sort of internal clock multiplier which would mean it's not required.

Touch tablets are resistive single-touch surfaces. The X/Y comes in through the paddle inputs. Buttons - left/right should correspond to the paddle fire buttons. These are the same inputs as joystick left/right. Fairly sure the stylus button corresponds to the joystick fire button. Behaviours you observe are probably "correct" - the different programs expect a certain input device to be used. Not sure if or how the mentioned programs can use different input devices.

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.