Star Wars code/mathbox re-assembly project
- Thread starter Mitchell Gant
- Start date
Mitchell Gant
Active member
Alpha1 said:Neil,
Is there any update on this?
Sorry, nothing done directly on this, but I haven't forgotten about it and I'm still slowly doing bits on the vector drawing tools for all Atari vector stuff (see last nights effort on a BZ board below).
Part of the problem is deciding what exactly to do with it! If you want me to change the colours of Tie fighters, towers, bunkers etc then it's a simple change of a couple of bytes of data. Or change the speech or some sounds is not too difficult. If you're expecting a new play level then that's beyond my level of software development I'm afraid! And there's no ROM space left to add much anyway. Unless you removed the test modes perhaps...
If anyone has any ideas or wants to download the tools and source and start developing something themselves then I'll help as much as I can of course.
Mitchell Gant
Active member
Alpha1 said:
Changing the text is fairly easy if you stick to the text line limits sizes. Same size or less would work, anything longer may not.
Speech samples are stored in the sound ROM as Texas Instruments own LPC format, but the QBox tools can convert from 8KHz mono Windows WAV format. The key here is to get *good quality* speech samples, as any noise makes for more memory use and poorer playback.
I've done a speech warning module for a fire engine (of all things!) that uses a similar type of codec (Speex) to the Texas LPC. I supposed the customer was going to provide professional, decent speech samples, but to test it out I had to record some myself using a laptop. The quality was terrible from the builtin microphone, you got the laptop fan and hard drive whirring in there, but it proved the system worked. I found that recording in 48KHz and filtering then downsampling to 8KHz worked best. Problem is the customer never provided any samples and ordered several units to go into fire engine builds. So my poor quality, Derbyshire accent voice samples are out there in some fire engines somewhere! Not the sexy female voice I'd wanted them to provide.
Memory space/size constraints are same as text though, you really need to keep speech clips same or less size as the ones you want to replace, or trade off a longer clip against another shorter one. It's a problem if they are larger as there is not much free space in the original ROMs.
If you want to PM me some text and record some decent WAVs I don't mind having a go Ollie. Not today though, got to go and help make pretty video projections for a gig tonight.
Mitchell Gant
Active member
Star Wars gone done 'bin on a diet.
A leaner, slimmed down Star Wars program ROM that outwardly looks and plays exactly the same as every other Rev2 ROM Star Wars machine out there. Except this Star Wars Lite code removes some unimportant code/data and leaves a significant 6030 bytes of free memory space.
Space to do things in like extra code or data. Memory space to play in!
Basically I've removed all the code in Star Wars that runs the diagnostic test mode and the accounting screens, along with tidying up some of the suspected unused code and data that was left in the original ROMs.
So apart from the one the attract screens text being messed up, it plays like Star Wars. If I remove the attract screens next I could recover another good chunk of free space for even more code or data. Quite what yet I have no idea, but it's a place to start.
I made some notes what I'd done over the past two days so I knew what I did in future. I'll paste them below to the handful of folks who may be interested:
21/03/2015 Copy latest disassembly to StarWarsLite folder
To assemble use command line:
..AS09 -l -s -n StarWars.asm
This turns on list file, generates Motorola S19 output and turns off optimisations to keep output same as original.
Strip out Test Mode and Accounting screen functions, but use extra org's to keep function calls working from Hi page memory.
Strip out text that is obviously used in test mode/accounting screens. Strip out pointers to that text from table. Fortunately test/accounting text was at end of pointer table.
Works/plays OK in MAME at this point, but attract screen 2 (Obi Wan is gone but..) has text shifted in wrong places. Suspect I've removed pointer/data to text offsets.
Find and remove calls to accounting screen and test mode when service switch is on. $64F4, $650C, $D7A6, $F2CC
Hi page code calls two functions, one to get random numbers ($CE45), and another to check and wait on Math hardware ($CDBA).
Next I moved the function code for Gen_Random and Math_Run_Start to the top of ROM ($FFDF and $FFE9 respectively), just before the interrupt vectors, rather than being in the middle of other code at $CDBA and $CE45. I re-assemble the Hi Page code to use these new addresses.
This way I can change the main code in future without having to keep re-assembling the Hi Page code.
This now stops working in MAME. Doh! Looking at the IRQ interrupt code I spot:
IRQ:
ldx $A,s ; Get calling address
cmpx #$6000 ; Bounds check for return address in ROM
bcc loc_EF5E
swi
loc_EF5E: ; Only allow IRQ calls from lower in ROM than BADIRQ function
cmpx #BADIRQ
bcs loc_EF64
swi
loc_EF64:
BADIRQ is located at $EF54 as a trap in case the program crashes, and sticks in a loop until the watchdog resets the game.
BADIRQ:
$EF54 bra BADIRQ
So the IRQ interrupt code checks that the calling address is above $6000 (ie in ROM space) and also disallows calls from above the IRQ code address. This is normally the test mode code that I've now removed.
Commenting out the check works and the game appears to run again in MAME... I say appears to as it runs attract mode OK and plays through easy level space, trench, explosion, space, then resets when first bunkers/towers level is reached. Clearly there's something else been altered!
Looked at the Hi Page code and did a search on all text 'jsr' so I could look at all the subrioutine calls. Didn't take long, though it was pretty much the last jsr that was still hardcoded to jsr $CE45. Changed it to jsr Gen_Random label, that is now set to new location at $FFDF. Now plays properly through bunkers/towers stage.
Took out some other suspected unused data areas at $95BD, $AA25, $B34C ("Hally was the whipcracker text" and an other copyright text), $CE4F ("DURFEY GOT WIRED" text).
Took out unused function at $D8F7
That leaves $178E (6030) bytes free from $E850
Realised that removing accounting/test setup screen means can't alter game difficulty, seems to ignore DIPswitch settings in favour of what NOVRAM holds. Still got more accounting NOVRAM functions to find that could probably be removed.
A leaner, slimmed down Star Wars program ROM that outwardly looks and plays exactly the same as every other Rev2 ROM Star Wars machine out there. Except this Star Wars Lite code removes some unimportant code/data and leaves a significant 6030 bytes of free memory space.
Space to do things in like extra code or data. Memory space to play in!
Basically I've removed all the code in Star Wars that runs the diagnostic test mode and the accounting screens, along with tidying up some of the suspected unused code and data that was left in the original ROMs.
So apart from the one the attract screens text being messed up, it plays like Star Wars. If I remove the attract screens next I could recover another good chunk of free space for even more code or data. Quite what yet I have no idea, but it's a place to start.
I made some notes what I'd done over the past two days so I knew what I did in future. I'll paste them below to the handful of folks who may be interested:
21/03/2015 Copy latest disassembly to StarWarsLite folder
To assemble use command line:
..AS09 -l -s -n StarWars.asm
This turns on list file, generates Motorola S19 output and turns off optimisations to keep output same as original.
Strip out Test Mode and Accounting screen functions, but use extra org's to keep function calls working from Hi page memory.
Strip out text that is obviously used in test mode/accounting screens. Strip out pointers to that text from table. Fortunately test/accounting text was at end of pointer table.
Works/plays OK in MAME at this point, but attract screen 2 (Obi Wan is gone but..) has text shifted in wrong places. Suspect I've removed pointer/data to text offsets.
Find and remove calls to accounting screen and test mode when service switch is on. $64F4, $650C, $D7A6, $F2CC
Hi page code calls two functions, one to get random numbers ($CE45), and another to check and wait on Math hardware ($CDBA).
Next I moved the function code for Gen_Random and Math_Run_Start to the top of ROM ($FFDF and $FFE9 respectively), just before the interrupt vectors, rather than being in the middle of other code at $CDBA and $CE45. I re-assemble the Hi Page code to use these new addresses.
This way I can change the main code in future without having to keep re-assembling the Hi Page code.
This now stops working in MAME. Doh! Looking at the IRQ interrupt code I spot:
IRQ:
ldx $A,s ; Get calling address
cmpx #$6000 ; Bounds check for return address in ROM
bcc loc_EF5E
swi
loc_EF5E: ; Only allow IRQ calls from lower in ROM than BADIRQ function
cmpx #BADIRQ
bcs loc_EF64
swi
loc_EF64:
BADIRQ is located at $EF54 as a trap in case the program crashes, and sticks in a loop until the watchdog resets the game.
BADIRQ:
$EF54 bra BADIRQ
So the IRQ interrupt code checks that the calling address is above $6000 (ie in ROM space) and also disallows calls from above the IRQ code address. This is normally the test mode code that I've now removed.
Commenting out the check works and the game appears to run again in MAME... I say appears to as it runs attract mode OK and plays through easy level space, trench, explosion, space, then resets when first bunkers/towers level is reached. Clearly there's something else been altered!
Looked at the Hi Page code and did a search on all text 'jsr' so I could look at all the subrioutine calls. Didn't take long, though it was pretty much the last jsr that was still hardcoded to jsr $CE45. Changed it to jsr Gen_Random label, that is now set to new location at $FFDF. Now plays properly through bunkers/towers stage.
Took out some other suspected unused data areas at $95BD, $AA25, $B34C ("Hally was the whipcracker text" and an other copyright text), $CE4F ("DURFEY GOT WIRED" text).
Took out unused function at $D8F7
That leaves $178E (6030) bytes free from $E850
Realised that removing accounting/test setup screen means can't alter game difficulty, seems to ignore DIPswitch settings in favour of what NOVRAM holds. Still got more accounting NOVRAM functions to find that could probably be removed.
You saved a pretty useful amount of ROM there.
Have you got enough to try and build another stage of play?
Could you possibly borrow the millenium falcon, tie fighter and asteroid dodging section from Empire strikes back? Or even the AT-AT stage.
Have you got enough to try and build another stage of play?
Could you possibly borrow the millenium falcon, tie fighter and asteroid dodging section from Empire strikes back? Or even the AT-AT stage.
Mitchell Gant
Active member
I've been learning more about how it works by altering/removing parts of the code and then playing it in MAME. Badly. With PC keyboard cursor keys. But it lets me see how some of it works.
I accidentally swapped the function calls for background stars and bunkers/towers level surface dots, which looked strange.
I spent the last couple of hours fighting with how to record a video file from MAME so I could put up on Youtube. It wasn't a pleasant experience as my MAME version would not allow video capture or input playback from invalid Star Wars ROM checksums. Even though it runs the modified ROMs fine to play!?!?!
I eventually installed and used trusty old VirtualDub to capture, crop, compress and upload to Youtube. Crude method but it worked.
http://youtu.be/z20kfg0BJ7M
There are a few other changes in that code that I've been playing with over the last week. The towers stage never times out or advances to the trench stage. In fact it's not really the towers stage at all but a new stage that happens to just do mostly the same as the towers stage up to now.
I also removed attract screens and test modes, so just the high scores screen shows now until you start a game. High scores not are saved now either, though I'd not actually intended to remove that code. Oops.
That has freed up 8386 bytes in ROM. Not enough to do a vast amount, I'm afraid you'll have to forget complex extra new levels with objects borrowed from ESB, which had much more banked memory. But enough to experiment with a little more I hope.
I've got the cycle of edit code, assemble, split output file to MAME ROM format/names, and run in a MAME window to just a few seconds, so it's fairly easy to just remove subroutine calls and see what happens.
I accidentally swapped the function calls for background stars and bunkers/towers level surface dots, which looked strange.
I spent the last couple of hours fighting with how to record a video file from MAME so I could put up on Youtube. It wasn't a pleasant experience as my MAME version would not allow video capture or input playback from invalid Star Wars ROM checksums. Even though it runs the modified ROMs fine to play!?!?!
I eventually installed and used trusty old VirtualDub to capture, crop, compress and upload to Youtube. Crude method but it worked.
http://youtu.be/z20kfg0BJ7M
There are a few other changes in that code that I've been playing with over the last week. The towers stage never times out or advances to the trench stage. In fact it's not really the towers stage at all but a new stage that happens to just do mostly the same as the towers stage up to now.
I also removed attract screens and test modes, so just the high scores screen shows now until you start a game. High scores not are saved now either, though I'd not actually intended to remove that code. Oops.
That has freed up 8386 bytes in ROM. Not enough to do a vast amount, I'm afraid you'll have to forget complex extra new levels with objects borrowed from ESB, which had much more banked memory. But enough to experiment with a little more I hope.
I've got the cycle of edit code, assemble, split output file to MAME ROM format/names, and run in a MAME window to just a few seconds, so it's fairly easy to just remove subroutine calls and see what happens.
You are aware that you can write to rom directly from the MAME debugger aren't you?
Just wondering why you're going through the whole edit/assemble/split routine when you can just simply NOP subroutine calls directly from the running code?
Just wondering why you're going through the whole edit/assemble/split routine when you can just simply NOP subroutine calls directly from the running code?
Mitchell Gant
Active member
cmonkey said:
No I wasn't aware I could change ROM data from the debugger.
Alhough I've not just been removing calls to subroutines, more removing completely many parts, and shuffling some from the banked ROM area, so the assemble/split/run cycle needs to be done anyway.
Let's say, for example, you wanted to NOP the first subroutine call in the vector rom at $300b (I've no idea what that subroutine does!)
From the debugger you'd issue the following two commands :-
maincpu.mw@300b=1212
maincpu.mb@300d=12
This would overwrite the 3 bytes of rom at address $300b with 3 NOPs.
From the debugger you'd issue the following two commands :-
maincpu.mw@300b=1212
maincpu.mb@300d=12
This would overwrite the 3 bytes of rom at address $300b with 3 NOPs.
That's a handy tip Adrian, didn't know that.
Not needed, the hardware is already there, one of the POKEY ports have been "defined" for networking. At least the schematic says so.
The developers eperimented with a head-to-head version but it simply didn't work out.
The real challenge is.....how to alter the game for a two player set-up ?
Awesome work by the way.Level422015-06-11 10:42:28
The developers eperimented with a head-to-head version but it simply didn't work out.
The real challenge is.....how to alter the game for a two player set-up ?
Awesome work by the way.Level422015-06-11 10:42:28
Hi homebrew colleagues,
right now i am developing a daughter-pcb for HighscoreSavekits / onlinekits for the 6809 CPU.
this pcb will provide bankswitching and will add some extra space (two banks) to Star Wars in a single EEprom / or ROM
i think this is perfect for homebrew as well.
The rom-Positions will be
Bank 0 $0000-$1fff
Bank 1 $2000-$3fff
Bank 2 $4000-$5fff
Bank 3 $6000-$7fff
regular Rom $8000-$ffff
the bankswitching itself will be by writing a byte into $8000 (or a similiar rom address)
the advantage is: only burn one EEprom for testing and playing. simple installation.
i use that method on my programs for arcade HSS and my multi DK (Dk with /DK_Pauline/D2K/D2KPauline all in one single chip)
the handwired prototype is done but not yet tested.
I'll keep you informed.
right now i am developing a daughter-pcb for HighscoreSavekits / onlinekits for the 6809 CPU.
this pcb will provide bankswitching and will add some extra space (two banks) to Star Wars in a single EEprom / or ROM
i think this is perfect for homebrew as well.
The rom-Positions will be
Bank 0 $0000-$1fff
Bank 1 $2000-$3fff
Bank 2 $4000-$5fff
Bank 3 $6000-$7fff
regular Rom $8000-$ffff
the bankswitching itself will be by writing a byte into $8000 (or a similiar rom address)
the advantage is: only burn one EEprom for testing and playing. simple installation.
i use that method on my programs for arcade HSS and my multi DK (Dk with /DK_Pauline/D2K/D2KPauline all in one single chip)
the handwired prototype is done but not yet tested.
I'll keep you informed.