I've had a BBC Master with a "Super-CoPro" for ages came from Mark Haysman - I persuaded him to sell me one of the prototypes. I didn't know it at the time but it looks like I was able to snag one of the 18 he's talking about!
Hacking Asteroids
- Thread starter guddler
- Start date
Well, I've made a small amount of progress this morning in so much as I've compiled 'tinymame' with just asteroids in it which turns out was only necessary due to the fact main mame was taking so long to build.
Then I've found the source from this thread which is cool because I had a horrible feeling it might have been lost and I've converted it to VASM. Wasn't entirely trivial but it was mostly syntax changes, although I had used a few BeebASM specific directives in there. Took a couple of hours I guess.
Seems to work so far.
My next step is to look at my 6809 stuff for the Vectrex and decide if 1) VASM can do all of what as6809 can, 2) what the output looks like in comparison and 3) if good, convert my Vectrex stuff to VASM.
I'm undecided at the moment. It's missing some things that I was using in BeebASM, but they were naughty shortcuts like FOR NEXT loops and stuff anyway.
Then I've found the source from this thread which is cool because I had a horrible feeling it might have been lost and I've converted it to VASM. Wasn't entirely trivial but it was mostly syntax changes, although I had used a few BeebASM specific directives in there. Took a couple of hours I guess.
Seems to work so far.
My next step is to look at my 6809 stuff for the Vectrex and decide if 1) VASM can do all of what as6809 can, 2) what the output looks like in comparison and 3) if good, convert my Vectrex stuff to VASM.
I'm undecided at the moment. It's missing some things that I was using in BeebASM, but they were naughty shortcuts like FOR NEXT loops and stuff anyway.
Mitchell Gant
Active member
Last week I was taking a look at Asteroids code and I've managed to create an assembler source file that, when assembled, will give an exact binary image of Asteroids revision 2.
Link to thread here, along with file to download:
http://www.ukvac.com/forum/forum_posts.asp?TID=347998&KW=&PID=921390&title=vector-monitor-adjustment-faint-center-circle#921390
A good starting point for anyone wanting to alter Asteroids game function. May be of interest to someone.
I've labelled some variable names in the source file, copied from work done by Lonnie (I think he may be 'Displacer' on here?).
Beware of changing code and running on real hardware, if you mess up the vector code you can damage your monitor or burn the CRT. Test in MAME first!
Link to thread here, along with file to download:
http://www.ukvac.com/forum/forum_posts.asp?TID=347998&KW=&PID=921390&title=vector-monitor-adjustment-faint-center-circle#921390
A good starting point for anyone wanting to alter Asteroids game function. May be of interest to someone.
I've labelled some variable names in the source file, copied from work done by Lonnie (I think he may be 'Displacer' on here?).
Mitchell Gant
Active member
Here's a slightly tidier source file for Asteroids Rev 4:
** Updated for language pointer table fix **
https://www.ukvac.com/forum/data/uploads/1089/Ast_Rev4.zip
I've marked a few lines through the code with a comment ;UNUSED? where I think there is unused data.
I've made another version of this file where I've removed this possibly unused data, assembled and tried briefly in MAME, all appears to work but doesn't mean it hasn't let some strange bugs creep in!
That modified version will fail game ROM test though unless I work out how to find and fix the checksum location.
Mitchell Gant2015-10-18 11:41:09
** Updated for language pointer table fix **
https://www.ukvac.com/forum/data/uploads/1089/Ast_Rev4.zip
I've marked a few lines through the code with a comment ;UNUSED? where I think there is unused data.
I've made another version of this file where I've removed this possibly unused data, assembled and tried briefly in MAME, all appears to work but doesn't mean it hasn't let some strange bugs creep in!
That modified version will fail game ROM test though unless I work out how to find and fix the checksum location.
Mitchell Gant2015-10-18 11:41:09
cparsonsuk
Active member
- Credits
- 205CR
I can follow some of that but it's not as readable as my 6809 code!
cNp
cNp
Mitchell Gant
Active member
Thanks for the hint for ROM check, I've not managed to understand much of it yet...
I have found a problem in the disassembled file I'd done though, which I've now fixed and updated the file link above.
Looks like the languages are stored along with a table of pointers to each language data. This table is located at $7887. Previously If you altered any code that moved those language tables, it would break the code, as the pointer table was still hardcoded data.
I've updated the assembler file to make the table contain labels rather than fixed hex data, that now fixes the problem.
It didn't show up at first as the English language seems to be stored in the vector ROM, whereas the other three languages are stored in program ROM starting at $788F. I had not altered anything in the vector ROM, so the hardcoded address pointer was still valid.
Tables of pointers in ROM were the biggest problem when I was doing the Star Wars disassembly too. There's lots in Star Wars too!
There may be other tables still hardcoded in this Asteroids disassembly too.
I have found a problem in the disassembled file I'd done though, which I've now fixed and updated the file link above.
Looks like the languages are stored along with a table of pointers to each language data. This table is located at $7887. Previously If you altered any code that moved those language tables, it would break the code, as the pointer table was still hardcoded data.
I've updated the assembler file to make the table contain labels rather than fixed hex data, that now fixes the problem.
It didn't show up at first as the English language seems to be stored in the vector ROM, whereas the other three languages are stored in program ROM starting at $788F. I had not altered anything in the vector ROM, so the hardcoded address pointer was still valid.
Tables of pointers in ROM were the biggest problem when I was doing the Star Wars disassembly too. There's lots in Star Wars too!
There may be other tables still hardcoded in this Asteroids disassembly too.
Mitchell Gant
Active member
cmonkey said:
It looks like the ROM check routine scans through vector ROM $5000 - $57FF, then program ROM $6800 - $7FFF, by breaking it down into 1K byte chunks and simply doing an exclusive OR on every byte in that chunk.
Somewhere in each 1K chunk of ROM there is a byte (that I thought were unused stray data bytes!) that will make the sum of XOR's of the 1K chunk equal to zero. If any '1's are detected then the hex result is displayed on the test screen along with the 1K chunk number that represents the ROM chip location.
I guess they did as 1K chunks because early Asteroids boards had PROMs rather than 2K ROMs.
Mitchell Gant
Active member
I've managed to change the ROM checksum routine to prove how it works so I'm able to produce altered code and still have it pass the Asteroids ROM test.
I took out all the 'unused' data bytes throughout the disassembly, some of which I know are actually ROM checksum bytes. Then I added in a single zero byte into the code so that it would be located anywhere in each of the 2K blocks (so 6800-6FFF, 7000-77FF, 7800-7FFF)
I then changed the ROM test routine cmonkey had pointed me to at $7E34, so that instead of checking 1K blocks it does 2K blocks. This was easy, just change the LDA #$4 at $7E2E to an LDA #$8 so it does 8x 256 byte blocks instead of 4x 256 bytes.
The XOR checksum result of each 1K block is stored in RAM starting at $0D onwards. Any result other than zero in these RAM locations will throw up an error on the test screen, showing the ROM number and it's failed XOR result.
That result is stored by an X register indexed store :
STA byte_D,X
INX
I simply added another store and increment X so now it's:
STA byte_D,X
INX
STA byte_D,X
INX
Then I ran the modified code in MAME and entered test mode. It showed ROM failures for each ROM of course, but now with pairs of identical fail numbers, so 0 and 1 ROMs failed with the same checksum number, as did 2 and 3, 4 and 5 and 6 and 7.
I noted each number then replaced the zero data bytes I'd added for each 2K block in the assembler file.
Re-assemble and test in MAME, now it passes the ROM test and does not show any errors. Job done!
That should help if anyone else needs to modify Asteroids in future and fix the checksums.
I took out all the 'unused' data bytes throughout the disassembly, some of which I know are actually ROM checksum bytes. Then I added in a single zero byte into the code so that it would be located anywhere in each of the 2K blocks (so 6800-6FFF, 7000-77FF, 7800-7FFF)
I then changed the ROM test routine cmonkey had pointed me to at $7E34, so that instead of checking 1K blocks it does 2K blocks. This was easy, just change the LDA #$4 at $7E2E to an LDA #$8 so it does 8x 256 byte blocks instead of 4x 256 bytes.
The XOR checksum result of each 1K block is stored in RAM starting at $0D onwards. Any result other than zero in these RAM locations will throw up an error on the test screen, showing the ROM number and it's failed XOR result.
That result is stored by an X register indexed store :
STA byte_D,X
INX
I simply added another store and increment X so now it's:
STA byte_D,X
INX
STA byte_D,X
INX
Then I ran the modified code in MAME and entered test mode. It showed ROM failures for each ROM of course, but now with pairs of identical fail numbers, so 0 and 1 ROMs failed with the same checksum number, as did 2 and 3, 4 and 5 and 6 and 7.
I noted each number then replaced the zero data bytes I'd added for each 2K block in the assembler file.
Re-assemble and test in MAME, now it passes the ROM test and does not show any errors. Job done!
That should help if anyone else needs to modify Asteroids in future and fix the checksums.