ErikM

INV programmer here, I'm watching this thread too for any more comments or questions about the game.

Hi. INV+ programmer here, dos486.com is my site. INV+'s source code is just a text file. The ".a" extension doesn't mean anything and isn't any kind of standard, that was just my own choice to mark Atari code separate from PC x86 assembler code (".asm") that I was also doing at the time. DASM and the other assemblers don't care what the file extension is, they will take any file containing text. Yes, .bin files are the machine code to run on an emulator, or on a real Atari with the help of some kind of development cartridge that it can be loaded onto. Yes, BombDelay and all those other lines are just defines, they are defining names for memory locations. I am not promising that INV+'s code is any sort of good material to learn from. There are much better tutorials out there than my 18 year old mess of a game.

Erik here, INV+ programmer. I just came across this thread. Always neat to see that work still active in the community. 8930 is amazing indeed, what was that, at least 8 invader waves? I never scored more than 3000 or so myself, though I was always looking for bugs more so than seriously score attacking.

I started from scratch, not anybody else's code (well, there's vestiges of tutorial stuff like Nick Bensema's "How to Draw a Playfield".) I don't know about anyone who worked on it after me, if Piero did anything or if it was based on my code or not.

> four independent detailed player-controlled flickerless objects on the same scanline. That part does work, as I remember. Not perfectly, since the register hits happen throughout the scanline so there'd be some graphical jitter. It's the loop at K00 in the source. The rest of the kernel was to be basically two simultaneous streams of Kaboom's bombs. The challenge is to reposition either sprite while still writing the other's graphics every scanline or two, and also reading the four paddles. That's the code at Kernel that can branch to DoBomb0 or DoBomb1. I don't think that part ever worked. I don't have any of your emails or biglist posts, that was all on my college email account which is long gone.

Hi. Erik here. I do remember this. The kernel wasn't anywhere near completed. I've actually still got the code, although it doesn't seem to work. Z26 and Stella both show it rolling the screen like crazy so there's really nothing to see. Here it is, maybe you can get some closure out of it. As for disappearing on you, I just got busy with school and work and lost interest in 2600 programming. No elaborate tale there, I'm afraid. - Erik TANK.TXT TANK.BIN

Old thread, but I just now thought to visit Atari Age for the first time in a long while. The timing of the shots in INV+ is entirely intentional, to match that of the arcade Space Invaders. I can appreciate that some might not like it. There is an adjustment available with the difficulty switches - A means you have to press the fire button once for each shot, B means you can hold it down and it will autofire (after the intentional delay.) And yes, the invaders are blocky. They are not sprites; they are drawn with the same low-resolution playfield mechanism that makes up the walls in Breakout and mushrooms in Centipede and so on. I was going for the fully accurate arcade gameplay, compromising on the graphics to do it. (Back in 1997 when I started INV, we had no idea how to do the tricky rapid hits on sprite registers to get 7 or 9 or 11 sprites per line.) By the way, now might be an appropriate time to reveal the Easter Egg initials hidden in INV+. Try hitting the saucer with your very _first_ shot of the game!

There's no separate PAL version for INV+. It's a single binary that supports all of NTSC, PAL-50, and PAL-60. To cycle between the modes, flip the Color/B&W switch down and up.

To my knowledge, INV+ is the first game to support three-way switchable video modes. It has standard NTSC, and also has PAL modes for both 50 Hz and 60 Hz. The former allows the game to display and play on PAL TVs that can't sync to 60 Hz, while the latter allows correct colors on PAL TVs while maintaining the 60 Hz gameplay speed. The third mode of PAL 60 Hz isn't necessary for games that make the gameplay speed independent of the TV frame-rate, but it's a good solution for games where conversion to nonsynchronous game timing would be difficult or impossible.

The invaders in INV+ are drawn with the console's playfield graphics, not the sprite graphics. If you're not familiar with the 2600's technical capabilities, just know that it's the same mechanism used to draw such things as the walls in Breakout and "mushrooms" in Centipede. The resolution available with playfield graphics is very low, of course, but that's just about the only way to get a full rack of 11 x 5 objects on the 2600. The homebrew Space Instigators uses a very intricate hardware trick to get 9 invaders per line. That trick is actually extendable to 11, but has some problems; either the invader formation has to be very wide (almost the entire width of the screen), or you get display artifacts with the spacing between invaders becoming uneven. So it's gameplay, not graphics, that drives INV+, of course. I took care to replicate as many other aspects of the arcade SI as possible. The 11x5 invader formation is a big part of the gameplay, of course, and there's several other details that match the arcade. Examples are the fact that invaders don't shoot in the last row before landing, and that the starting position of the invaders requires them to advance 11 times to reach Earth on the first level and one row closer in waves 2, 3, 4, and 7. Also, the saucer appearance, behavior, and scoring are dead-on for the arcade, an aspect where Instigators falls short.

Heh, that's my original code from way back when (1997), that I originally wrote for INV. Funny how things can come full circle. The advantage of the 32-bit version over a shorter one is that it's less prone to artifacts in the distribution of the output. For example, if you pull an 8-bit random number from an 8-bit LFSR, you can never get zero. One easy way to seed any shift-based RNG is to just simply call it once per frame whether or not you need a random number. Unless the user manages to press Game Reset on exactly the same frame after every bootup, you'll get a reasonably random initialization of the sequence.

NE146, I saw your first post last night but didn't have time to reply then. Glad you got a chance to test it more. Your observation is right - you can't fire again until after the invader finishes exploding. This is intentional, of course - the player's missile graphic is also used to animate the explosion. There is also a delay even after that, that could be shortened, but I like it as-is. I'm no longtime veteran of the arcade SI, but I played it a fair bit in MAME while working on INV, and that delay is present in the arcade SI as well (or at least on my MAME.) I'm doubly blown away now by it especially with the extras such as shot counting, and point value of the ufo's being shown amongst others. Well, those are supposed to be basic parts of the game, not really "extras", I just never got around to coding them before. The real "extras" over arcade SI are two-player simultaneous play and the invisible-invaders mode. If this gets sold in cart form, count me in. Al covered that one.

If nobody else has any comments or suggestions, I'm going to move ahead and release it this weekend.

The shot timing is intentional. If you load up the arcade Space Invaders in MAME, you'll see that it behaves that way too. Overall, I'm quite satisfied with the playability of this game. IMO, it compares quite favorably to both the arcade SI and the 2600 Space Instigators.

It's been a while, but here's another version that I'm ready to release. I re-did the invader marching sound effect to sound like space invaders instead of squeaky alien toys. I also lowered the pitch of a couple other sound effects, and I'm pretty happy with the way it sounds now. Comments are welcome, of course. inv60904.zip

Nukey Shay: I'm not planning to add more features now. Nobody ever plays 100 of the 112 Space Invaders games anyway. I've got two-player mode and invisible invaders mode, which is a fair bit of variety, enough for the sort of time that anyone would actually spend playing this. The fancy stuff you mention all came in later versions of Space Invaders, not the original. With the exception of the Rainbow effect, but that's really cosmetic, nobody really tries for it in gameplay. It might be a nice addition but I don't really think is worth the amount of optimization I'd have to do to get ROM space for it. If nobody else reports back with any bugs in a day or two, I think this is ready for final release.

I haven't tried it on a Cuttle, but I have tested it extensively on 2600 hardware on a Supercharger. It should work fine on the Cuttle, too, but testing is always appreciated Let me know if anyone finds the easter-egg to display my initials (it's obfuscated in the source, although extensive digging might find it.) Hey cool, this post bumped my title up to "Space Invader", how appropriate

The hardware ignores the low nibble of PF0, yes, but my code doesn't. To move the invaders around the screen, those playfield bytes get shifted and rotated to heck and back. Look at the code at the labels MoveEachRow0 and MoveEachRow1. I'm sure I could optimize BoardInit quite a bit by making it a loop, allowing junk to get stored into the low nibble of PF0, and masking out those bits in the rotation/movement code. But... 1) I wrote that code 7 years ago and don't even understand it now, and 2) why bother if I don't need to recover ROM space for anything now

The forum kept choking when I tried to edit the attachments. Seems to be there now, as Release Candidate 5.

Changelog 4/29/04: - Fixed a bug: in a two-player game, if player 0 got game over, his sprite continued to be drawn in black which would obscure player 1 if P1 moved to the spot where P0 died. - REALLY added a pause if the game ends due to invaders reaching Earth. (The fire button now won't start a new game until after a 4-second pause.) I've tested it extensively on real hardware, and I think it's ready for release now. If no one posts back with any bug reports in the next couple days, I think INV+ is finally ready for final release and I can move on to a new project. I've updated the original post with a new attachment; it's zipped and includes the source as well. It's not the most logically organized piece of code ever, and most of it is far from optimized, but it is extensively commented so maybe somebody can learn from it.

I'm about ready to go into final release with this, so if anyone wants to test it for bugs, now's your last chance...

Thanks to Albert for testing this and catching some problems. Changelog 04/19/04: - REALLY fixed the bug where one missile could hit two fast-moving invaders. (The code to check it was there, but in the wrong place.) - REALLY fixed the bug where sound effects could get stuck. - Tweaked the saucer noise; it now sounds less piercing and a bit more like the arcade (in MAME at least) - Saucer doesn't make noise if it appears while the game isn't in progress - Increased the delay between player shots slightly. This makes it closer to the arcade gameplay, and makes it a bit harder to accidentally repeatedly damage a shield (which is also a factor when you're counting shots for the saucer score.) The new version is attached to the first post, as inv41904.zip. I'm just about ready to release this, unless someone finds a bug that really needs fixing... have at it!

I wonder if there might be different behavior in different versions of the 6502 architecture? I know the 65C02 has additional instructions and addressing modes that the 6502 and 6507 don't. Perhaps later versions of the chip do update the V flag on a compare instruction...?

Actually, the link that you give agrees with me that the compare instructions don't affect the V flag. "Affects Flags: S Z C". And I listed all the other instructions you mention, except for SBC. Looks like my reference was wrong on that, but the point stands... the only opcodes that do something computational to the overflow flag are ADC, BIT, and SBC. CLV, PLP, and RTI do obvious things to it and are just about never used in 2600 programming anyway. To Nukey Shay: LDA definitely doesn't update the overflow flag, so LDA/BVC definitely doesn't work. BIT/BVC certainly does, so that's probably what you've been using...?

Actually, that doesn't work. LDA doesn't affect the overflow flag. I've gotten burned by that a couple times, in fact. This does work; BIT *does* set or clear the V flag as appropriate. According to my 6502 reference, the *only* computational instructions that affect the V flag are ADC and BIT. (PLP and RTI also do, by pulling it from stack, and of course CLV clears it.) Instructions that don't affect the overflow flag, but you might think they do, are LDA/LDX/LDY, CMP/CPX/CPY, SBC, all the IN_ and DE_ ops, and all the T__ transfer ops. Here's how to remember how the sign and carry flags work with the compare instructions. CMP does the same thing as SEC+SBC without changing the accumulator. So suppose A holds the number 55, and we do CMP #30. The result of the 55 - 30 would be 25, binary %00011001. The topmost bit of the result is clear, so the sign flag is; and the result of the subtraction did not go below 0 so the carry stays set. Suppose A held 30, and we did CMP #55. The result of the subtraction would be -25, or in binary %11100111. The topmost bit is set, so the sign bit is set (meaning negative). And the result of the subtraction went below 0, so the carry gets cleared. CPX and CPY behave the same as CMP, of course. Maybe Andrew can work that into a more coherent form for the tutorial lesson on branching.