Rybags

What Dos are you referring to that has code in the B600 area? Cart based SDX? I think that the filespec needs the EOL terminator - so follow the "D1:OLD,NEW" with ,$9B And shouldn't it be BUFFER .BYTE "D1:OLD,NEW" and not BUFFER = I would have thought that would generate an assembly error.

It would be fair to assume it uses the frame counter as basis - but in both PAL and NTSC cases it is slightly out, slower than broadcast and slower than 50/60 FPS. But what you describe is out by orders of magnitude rather than the small % factor you'd get over that time period by counting frames. Assuming a 16 bit counter only, 65535 frames in NTSC would equate to about 1092 seconds or 18 minutes. Possibly it uses only the positive part of a signed integer which would equal half that. Maybe trim your BM down such that it executes in about 7 minutes and see what the result is (hint - do it in Altirra so you can use the F1 turbo button so you're running in seconds rather than minutes - although running much quicker the time result will still reflect what real hardware would see)

Not really valid at the OS level though. If it was an end user application then it would be. Maybe Option+Select+ key would be a better choice. Console key + Shift or Ctrl and another key would be tricky for some combinations.

I can't think of a lot of software that uses such combinations. I do remember the word from Atari when XL came out was that software using the Help key would allow alternate key combinations to allow legacy compatibility, though can't particularly name any titles that even used Help (maybe AtariWriter?)

The default OS doesn't use any such combinations. Avoid Shift-Ctrl-A as it generates code $FF which is the default no key condition. Conflict - you're dealing with a case of these combinations only being used by addon software or system mods. Where do you see your own usage case in the overall totem pole situation? I guess if it's application software then you're down the order a bit from something like an OS or driver. But you're talking about an OS and monitor so you're just about top of the tree here. Still it would be nice to be able to have no conflicts. I guess you know of the invalid combinations that just don't do anything? They coincide with the keys that appear on the same rows as Shift and Ctrl. That being Help, BVCXZ and JKL;+* I'd also tend to give Shift-Ctrl-ESC a miss - it's fine on normal hardware but not on Windows based emulation.

It was handy to have some of the big games such as the Lucasfilm ones on Rom. Tramiel era gets criticised but they did pursue a lot of minor revenue angles such as cross licencing older games with other companies.

Some of the games that were media shifted weren't even modified to run direct from cartridge. They just used the Rom to stream the game code down into Ram. Result being that potential to be able to run on lower Ram systems was lost.

As a collectable, I suppose worth aquiring. Price, not sure. Maybe the XE release is rare since the game had been around for a fair while and most people who wanted it would have had plenty of chance to buy the original release. If wanted for the sake of having the game I'd prefer the original. The brown carts are much better quality and more durable and the packaging and manuals the same.

It's been a long time for me but fairly sure there's a utility that sets the default core. And yeah - if you have plenty of Ram then avoid the R suffix cores, not needed.

Fairly sure at least as far as the Rom contents go, it's identical to the earlier brown cart and there were no official different revisions of this game.

CPU is 6502 as well. I would guess this is probably their last game that used 6502 or Pokey as main CPU or sound processor. Some later games see one or both of those chips but as slave processors. I'm not sure the 6502 is compatible with the more advanced sound chips - but also like you say the sound and music of the game is much of a step sideways from other versions rather than the usual up you'd expect from an arcade game (though in this case the game originated elsewhere and wasn't the usual downport)

Mostly 16 KHz mode there I'd say. Check this out - especially the part around 7m40s - music by the same author.

The CPU is worth a look also. If the IRQ pin isn't connected you can have trouble. You could just check continuity between the CPU IRQ pin and Pokey and PIA. PIA is a 6520, though could be labelled as 6820 - "Atari part # CO14795 or CO12298 - sometimes no Atari number, Hitachi HD68B21, GTEu G65SC21P" (from AtariMax Jindroush site mirror)

If the program could be found then emulation could be used to work out what's going on.

Pretty good. But I do suspect it is a filtered voice pair in conjunction with a low frequency note on the other voice/s.