Shift + Ctrl was never used in any official OS. Ctrl-1 is pause screen output and Ctrl-2 is bell in all OS versions. Shift + Ctrl probably avoided as some combinations won't generate a keypress. Though 0-9 all work fine, which is sort of a missed opportunity as it would have made for an easy set of F-keys.
Just checked a few more games (curiosity took over from the need to sleep).
It seems to be a common trait - 16K games have mirror images within the 32K window that carts can live in and it seems that some will favour running at the lower address.
Not sure how the mapping works exactly, it probably varies depending on how the cart is wired up, what size it is and whether it's 1 or 2 chips.
Star Raiders, 16K Rom has mirrors 8K apart.
$4000-$4FFF, $6000-$6FFF blank (return FF)
$5000-$5FFF and $7000-$7FFF read the same, code seems to execute in high copy.
$8000-$8FFF and $A000-$AFFF read the same, code executes from low copy.
$9000-$9FFF and $B000-$BFFF read the same, block is mostly blank some data at bottom, cart vectors at top.
As such, this would mean some games when converted would easily run on smaller Ram computers.
So maybe Atari shot themselves in the foot here... they made it hard for the games to be put onto cart if hacked to work on the computer but made it easier for more people to be able to run them if they only had 32 or 40K Ram.
The problem with anti-static mats... the name sort of sends a wrong message. They're often conductive material in which case powering up something sitting on it or otherwise allowing power to flow to it could be real bad.
Using equates from other sources comes down to expected syntax.
With assemblers there's generally a few common differences that you might find, the first 3 here especially relevant to equates files.
1. Assigning labels is usually done by = but some assemblers use EQU. Some allow both.
2. Comments are usually started by ; in rare cases it'll be different. In most cases, anything coming after a parsed instruction and operands will be treated as comments regardless of leading character.
3. Some only allow and expect upper case, others ignore case, some are case sensitive, e.g. WSync different than WSYNC or wsync.
4. Controlling location counter usually by *= in some cases by ORG. * on it's own usually in any to allow location counter to be used for calculations and assignments.
5. Some difference in expression of instructions, usually types with multiple addressing modes which can also act on Accumulator, e.g. LSR. Some expect LSR A, some just LSR, some allow both.
Rally Speedway is character mode - it's probably the case that charmode would be more suited to your needs. Additionally you can add detail at little extra cost if you're just dealing with maze type game worlds where movement boundaries are constricted and snap to certain pixel boundaries.
Basketball - they could have done it various ways but similar techniques have been employed in later games. Jungle Hunt is a good example, it keeps a colour map of the hero's colours per scanline. Pole Position changes fine H-Scrolling values on the fly as well as doing colour and positional change for PM objects.
OK, obviously the video is for illustrative purposes.
Have to wonder though, how do the flaky traces cope with the heat? Got to say though it's a fast process.
For whatever reason though, you just don't seem to hear about the method of heating pins with the iron individually and using a solder sucker. I did about a dozen Pokeys off 7800 carts that way, and other DIPs as well, practically all rescued and reusable.
The other thing is it's a whole bunch cheaper than having to buy a hot air station.
There's multiple playfield modes in bitmap and text and software tricks can expand on that even further.
There's no direct equivalent to TIA playfield 40x192 @ 1bpp.
As Avery mentioned there's Graphics 3 which is 40x24 @ 2bpp. Tricks can be employed to turn it into 40x192 but at great cost in CPU cycles.
Probably easier would be to just use one of the GTIA modes which allows 80x192 @ 4bpp.
The thing is you don't necessarily have a direct equivalent so it's either throw together some sort of emulation layer, change the intermediate processing or just change the individual game's programming.
Doing screen stuff on the computer is very different to 2600, and porting games across is usually not straightforward.
Part reason for Antic's existence is so you don't need to do that kernal based stuff though of course it still applies for doing lots of colour changing or PM repositioning.
I imagine your virtual worlds are represented somewhere as bitmaps or otherwise procedurally generated.
The trick with porting such things is to replace the middle-man (kernal) with code that simply renders the graphics in a way the computer can easily display them.
Realistically, the only thing similar on both systems is player/missiles and the method of dealing with them is very different. But for the purpose of porting, it's way easier to go from 2600 to computer vs the other way around.