Rybags

I didn't realize that, though the only analysis I did of the program in the day was stuff like XL problems and why the tape version didn't like disk etc. Moving the VB processing to the last DLI can bring benefits. The VB normally occurs after the normal 240 scanlines but in many cases that's 20, 30 or more scanlines wasted. If the processing is fast enough to finish before the next playfield start then potentially you can avoid needing to page flip in some games that might otherwise need it. Though by the looks, Shamus does all the game logic and movment in mainline code with those delay loops. So the game could becomes unplayable fairly easily with an accelerated CPU.

There's computer fonts as well as close matches for the futuristic one used on most packaging in the Warner era. The ones I have matching the packaging "SF Atarian" and variants.

I remember seeing ads in magazines for the game and thinking Wow. I don't think I saw a real one until it was about 4-5 years old, not sure I even bothered to try it (Atari only had it in the US, Namco elsewhere). It was a fairly early/pioneering v-scrolling shooter so probably not fair to expect too much of it compared closely to others later on which usually have generations newer CPU, video and sound. Looking at the arcade version in MAME, the graphics and sound are somewhat cheap feeling but we're talking a 1982 game here, so it would have looked fairly advanced against contemporaries of the day which were the likes of Time Pilot, Galaga, Jungle Hunt and DigDug. The instant comparison that would come to mind for me is Terra Cresta which is somewhat more sophisticated but then we're talking 3 years difference - both using Z80 for secondary functions but Xevious also having one as the main CPU but TC has a 68000.

I'd propose - leave pause to a normal key command which frees up a button. Probably reallocate it to something more standard like Esc or Space. That leaves 3 buttons free. I'd use them for velocity controls - throttle down, throttle up and velocity 6 (the recommended, most commonly used speed). It'd be nice to have an extra 1 or 2 such as maximum and full stop but that'd mean moving something else to the keyboard. Over the years, I've found you need many commands quickly at hand. You want tracking off if it interferes with an enemy attacking you from one end or the other, you need Galactic Map quickly if a starbase is surrounded or you've copped a lot of damage. You need LRS quickly if desperately looking for that last enemy in a sector of a squadron surrounding a starbase. You need Hyperwarp quickly for that desperate jump out of a sector without programmed destination if you're near destruction. Maybe Computer and/or Shields could be left off. The only time you quickly want shields off/on is when you're playing the tight strategy to try and save every last bit of energy to get a high rank. In general gameplay you tend to just leave them on all the time. Computer - uses next to no power so again often a rank thing. Though having both off does give that nice clean viewport look.

Cheers, Phil. I see there's some OCR been done also. I think I tried a bit of that some years back without much success. I sampled a bit from the PDF and notice the same problem. But really the problem there is the dot matrix plus the fact the original print itself had little glitches and darkness variations that can easily cause confusion.

ed - just realised I was replying to something about 4 pages back. On real hw in theory a Rom based autostart like cartridge should see the same RANDOM sequence, as you'd expect on an injected execuatable on emulator. On real hw a SIO, and possibly even IDE type loaded autoboot program should see sufficient jitter (especially rotating disk) such that the odds of the same RANDOM sequence are no different as if a user promt initiated it.

I agree a slimline form factor would be better - space for a given upgrade usually steals from adjacent areas. Off topic somewhat but in the modern day why don't we yet have a plugin emulated replacement? The thought is a PIC, AVR, something, that runs a 6502 core and can behave exactly like the OEM part. Then add things like 65C02 mode, maybe 65816, and obviously why not have a 6809 mode as well?

Test Drive was only on A2, C64 and MS-Dos (5.25" candidates). We never got Winter Games or Summer Games 2 but A2 did. So yep, I'd be saying 99% Apple as well.

What's the deal with that weird controller in the box pic? Just a prop and of no real relevence to the game itself?

Not that I know of. Issues with both native and cross-platform assemblers can include stuff like: - Zero page values represented as absolute instead of zp in generated instructions. - Forward reference to labels not working properly. Then there's other things like whether it supports just base 6502 or variants like 6502C and 65816. I guess a validator program might be good, it could verify itself by checksum of the generated test instructions.

The only way to find out is put it in properly and see if it works. Generally a fried chip won't hurt the rest of the system.

Good thought... quick way to abort a tape boot from memory is press Break twice quickly.

By the looks of it you couldn't remove much material off it either, the tracks run right near the edge.

No. With such tools you'll usually need a distinctive mark on whatever's rotating for it to be able to work properly - preferably towards the outside rather than inside. In theory you could probably sacrifice a floppy by putting a mark on the media. Or maybe just measure the the hub after putting a mark on that... though it'd be a less accurate reading from something close to the centre, though in the 280-300 rpm range it probably wouldn't matter much.

I've just opened my brown Computer Chess, it has the jagged type PCB - though probably an earlier rev to the one you show. There's a good couple of mm each side of the outcrops excess space. I think I've got a pulled apart grey cart somewhere but had a look and can't find it - maybe they have a bit more room inside? Also note there's 3rd party carts that have different dimensions (though OSS orange are slightly narrower), and even C64 cart shells were used for some titles (they're slightly wider than a grey or brown cart from what I can see from my Easyflash) That straight edge one... looks just about homebrew in itself.

I'd be pulling and reseating (or adding socket for) MMU and PIA. Though sort of strange that all those games were OK but a Basic cartridge failed.

CTIA is very rare - supposedly only went into production machines for less than 18 months. Lots of people would have taken the upgrade offer which means even more rare. Detection method - the only thing I can think of besides setting up a mode and prompting the user is PM collisions. Unsure if that'll work. PMs can work a bit differently when GTIA modes are enabled.

OS Rom for CTIA? I don't get that. Supposedly the official OSes for 400/800 are rev A and B for NTSC and only A for PAL. It would be fair to assume an OS-A NTSC machine has CTIA but it's not a given. Plenty of people took up Atari's offer to upgrade to GTIA (from memory you paid for the chip but the official service centres installed it for free) It's been discussed before, and the generally accepted thing is that PAL CTIA probably never existed.

CTIA detection - how does that work? Do you use a GTIA mode and create PM to PF collisions or something?

You don't need to change anything. If you're happy with having the loading pic which then waits for the key or fire button, the RTS should be sufficient to continue the load process. The RC pics seem to have a 2E2-2E3 segment which is an INIT. So if you just append your executable file to the pic executable it should be enough. Not sure if RC allows a set delay also which for a game might be desirable. But you could add it yourself easily enough, like just alter the code there. skp dec timer1 bne skp2 dec timer1+1 beq stop skp2 Before the pic runs you'd need to set word timer1 to some value, e.g. 600 which would be 10 seconds delay for an NTSC machine.

Not sure if there's an option to generate source code with RC. But the executable generated - runs with interrupts disabled, checks for fire button and key presses at the bottom of screen. If one of those conditions met, it enables VBlank and issues an RTS. So, should be suited fine for chaining as an early part of a game. One thing to note, the memory occupied won't be cleared so don't rely on RAM containing zeroes (which really we shouldn't do anyway)

You don't have to open anything. Just start with Basic or Memopad and hold a key down.

The main things that will be different are key repeat and the tables that control tape loading. Supposedly the tapes shouldn't have a problem though as there's meant to be 5% tolerance built into Pokey. If it actually is an NTSC OS though, the key repeat on a PAL system would be annoyingly slow. You should be able to pick it straight away.

Older machines are easy to detect. Bit 0 of PORTB switches the OS in or out. So regardless of version or aftermarket modification that should be a universal indicator. PORTB on XL/XE by default will have all bits in output mode - though in a testing situation you'd probably want to do save/restore and put them in output mode to test the OS switchability.

I'm not sure it was written with the older machines in mind (though should have) But it seems to have found you 've got a PAL Antic and NTSC GTIA. Does that agree with what I suggested to try in your thread about the modded 800?