In my third blog update for the day, I can report that I've all-but-finished the reverse-engineering of the arcade Asteroids 6502 code.
Aside from temporary storage, all zero page and player RAM variables have been documented. There are no variable addresses remaining for which I do not know the purpose.
About 95% of the code has been commented. There's some particularly nasty code in a few places throughout the ROM that remains uncommented at this stage; aside from some physics there's the exploding ship routine - which seems unnecessarily complex in my opinion - for example.
Importantly, I know what all the code is meant to achieve, even if I don't understand the nitty-gritty of every line in some isolated cases. It's something I'll probably have to rectify once I start transcoding to 6809 and/or C, but for now I'm satisfied that I have a well-enough commented source file on which to base my official Apple IIGS port.
From here I need to re-generate the core .ASM file and re-apply my patches for running on the IIGS. Since I annotated those patches in IDAPro, it should only take about 10 minutes before it's running again with the new source. And thereafter, I can start modifying the code 'for real' this time, including optimising for performance and incorporating pixel-shifted bitmaps.
It'll probably be a few days before I have anything rendering again, and the still screen shots will probably look no different to those I have posted already. The video should look a lot better though...
It looks like you're getting pretty close. Keep going!
ReplyDeleteI think it'd be a great service to make the commented disassembly available. Maybe pass it on to http://computerarcheology.com/ or something.
ReplyDeleteDid you happen to figure out the code that decides when a new ship can spawn? I'd always wondered how that decision was reached. I think they wait until it sees no asteroids in a large rectangle around the ship. The cool part was that Ed Logg recognized the possibility of an indefinite wait. If the ship doesn't spawn after a certain time interval an asteroid is destroyed. And it will continue to do so periodically until the ship spawns. I really have to wonder if that code is ever hit.
I plan on releasing the disassembly soon. I've actually been working with Chris @ComputerArcheology on this, who has been of assistance.
ReplyDeleteLooking at the re-spawn logic there's no evidence that I can see of asteroids explicitly being destroyed if the wait is 'too long'.
The shipSpawnTimer is used every time the player ship is to appear, such as start of wave and hyperspace, etc. A single routine handles the (re)spawn.
The routine decrements the timer and returns if non-zero. Otherwise, if coming out of hyperspace, it branches elsewhere. Otherwise it calls a subroutine to check if any of the asteroids/saucer are in the vicinity of the ship (1/8th of the screen dimensions) and extends the spawn timer if so. Indefinitely as far as I can tell. And a new saucer won't appear while the ship is respawning.
I also can't see any other code that ends up in the routine that hits an asteroid.
I patched the code so it always thinks an asteroid is 'too close' and let it run for a bit... no dice either.
Where did you come across this code? It's not actually in Asteroids Deluxe (only) by any chance?
Indeed, my memory was faulty and your guess is correct. Poking around a bit I believe the time check was in the "rocks in vicinity" subroutine and only appears in Asteroids Deluxe. Certainly doesn't appear in Asteroids' neighbourhood check routine at $7139.
ReplyDelete