Rybags

Cool. I've looked at some of the code and documentation for this game some years back also with a view to converting it. The graphics mapping has a hardware addon that allows byte based addressing using the (ind,X) instructions - external hardware monitors the Sync pin on the 6502 and detects when certain instructions execute then modify the subsequent memory access. That alone was just about enough to turn me off attempting to do much with it. I just gave it a quick run - nice how you've set up ZXC to shoot from each base. Of course the aspect ratio isn't right but not much we can do about that other than adjust H-width on monitors that allow it. Though in fact a lot of LCDs will allow stretching a 4:3 image to fit in 16:9 which would probably make it about correct. Another thing I noticed - the sounds are practically identical. The arcade version runs 6502 at 1 MHz and supposedly it's Pokey at 1.25 which would mean that any AUDF values would need to be adjusted (and entirely possibly some poly sound esp type C would turn out very differently)

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.