Gravitar on Space Duel PCB
- Thread starter Mitchell Gant
- Start date
What a tricksy problem to diagnose neil. Well done on the hunt.
Mitchell Gant
Active member
After hopefully curing the hardware problem I can return to software issues.
Playing the real PCB in my cab feels a lot slower at some parts when the bunkers get busy compared to playing in MAME.
I can't help thinking that all the extra interrupt code to re-map the buttons that I described here http://www.ukvac.com/forum/gravitar-on-space-duel-pcb_topic349983_post980511.html?KW=buttons#980511 is taking up too many CPU cycles.
How can this be improved I wondered?
Well the real Gravitar code uses the interrupt service routine to decide whether it's player 2 in a cocktail cab or an upright cab and makes up a single byte bit pattern that is then stored in RAM at $1D. The main game code then looks directly at this RAM data at $1D and takes action based on which bits are set representing which buttons are pressed.
I thought that instead of using lots of shifts to reconstruct the same bit pattern Gravitar expects in the RAM copy, it may be faster to change all the locations in the main code that look at that RAM copy to suit the pattern Space Duel hardware has. A search of instructions that read location $1D soon found all of them, so it looked a possible speed up solution.
Space Duel hardware has the buttons mapped across several memory locations just using bits 6 and 7 rather than a single 8 bit byte. For any player only three memory locations need to be read for all buttons while in a game. For speed I thought that it would be best to simply read all three hardware button locations and store them in three RAM locations. This meant finding two extra bytes, preferrably in zero page for speed. After some more digging I found two unused locations at $8A and $8B.
So the interrupt service routine code can now be reduced to
LDA $900 ;7-Shields 6-Fire
STA byte_1D
LDA $902 ;7-Rotate left 6-Rotate right
STA byte_8A
LDA $904 ;7-Thrust 6-P1 start
STA byte_8B
which is a lot less instructions than all the shifting I had previously.
I then went through all the main code and replaced all the reads of $1D and subsequent logical AND instructions to match the new locations and bit positions.
For example the thrust button handling code
LDA $1D
AND #10h ; Check Thrust button (Gravitar hardware)
becomes
LDA byte_8B
AND #80h ; Check Thrust button (Space Duel hardware)
After replacing all the locations for each button I tested in MAME and verified it worked. After a few failed attempts I managed to get it to play.
The next step will be to burn a EPROM and try it in the actual cab and see if I can see an improvement in speed. After that it will need to be compared side by side with a real Gravitar by a more experienced player than me. Backflipper is on that list
Arcade Club now has a working Gravitar too, I saw someone playing it just this last Saturday night that was doing very well on the negative gravity level, but I left before I could chat to him. If Andy gets a Space Duel cab working I will ask if I can put my conversion in there for some testing by such players maybe.
Playing the real PCB in my cab feels a lot slower at some parts when the bunkers get busy compared to playing in MAME.
I can't help thinking that all the extra interrupt code to re-map the buttons that I described here http://www.ukvac.com/forum/gravitar-on-space-duel-pcb_topic349983_post980511.html?KW=buttons#980511 is taking up too many CPU cycles.
How can this be improved I wondered?
Well the real Gravitar code uses the interrupt service routine to decide whether it's player 2 in a cocktail cab or an upright cab and makes up a single byte bit pattern that is then stored in RAM at $1D. The main game code then looks directly at this RAM data at $1D and takes action based on which bits are set representing which buttons are pressed.
I thought that instead of using lots of shifts to reconstruct the same bit pattern Gravitar expects in the RAM copy, it may be faster to change all the locations in the main code that look at that RAM copy to suit the pattern Space Duel hardware has. A search of instructions that read location $1D soon found all of them, so it looked a possible speed up solution.
Space Duel hardware has the buttons mapped across several memory locations just using bits 6 and 7 rather than a single 8 bit byte. For any player only three memory locations need to be read for all buttons while in a game. For speed I thought that it would be best to simply read all three hardware button locations and store them in three RAM locations. This meant finding two extra bytes, preferrably in zero page for speed. After some more digging I found two unused locations at $8A and $8B.
So the interrupt service routine code can now be reduced to
LDA $900 ;7-Shields 6-Fire
STA byte_1D
LDA $902 ;7-Rotate left 6-Rotate right
STA byte_8A
LDA $904 ;7-Thrust 6-P1 start
STA byte_8B
which is a lot less instructions than all the shifting I had previously.
I then went through all the main code and replaced all the reads of $1D and subsequent logical AND instructions to match the new locations and bit positions.
For example the thrust button handling code
LDA $1D
AND #10h ; Check Thrust button (Gravitar hardware)
becomes
LDA byte_8B
AND #80h ; Check Thrust button (Space Duel hardware)
After replacing all the locations for each button I tested in MAME and verified it worked. After a few failed attempts I managed to get it to play.
The next step will be to burn a EPROM and try it in the actual cab and see if I can see an improvement in speed. After that it will need to be compared side by side with a real Gravitar by a more experienced player than me. Backflipper is on that list
Arcade Club now has a working Gravitar too, I saw someone playing it just this last Saturday night that was doing very well on the negative gravity level, but I left before I could chat to him. If Andy gets a Space Duel cab working I will ask if I can put my conversion in there for some testing by such players maybe.
Monstermug
Active member
That's some clever bit of coding there! Great job.
Does this mean there be a spike in Space Duel PCBS in the near future?
Awesome refactoring of the code neil.
Mitchell Gant
Active member
I've made a little progress but it's been a busy summer doing other things.
I'm slowly coding some DIP switch settings so that each game can have its own unique DIP settings rather than reading the actual PCB DIP's. Each game is different and you can't open up the cab each time you want to change games!
I intend to have the DIP settings for each game stored in battery backed RAM for the front end menu screen bank, then modify each game so that rather than read the PCB DIPs it calls a bankswitch to the menu bank then returns a byte with the stored DIP data.
That part is mostly done but I now need to make a way of editting the DIP data from the menu screen. That opens up a whole lot of code that needs writing now. Suddenly the simple front end game select screen now needs expanding and sub-menus building.
I'm slowly coding some DIP switch settings so that each game can have its own unique DIP settings rather than reading the actual PCB DIP's. Each game is different and you can't open up the cab each time you want to change games!
I intend to have the DIP settings for each game stored in battery backed RAM for the front end menu screen bank, then modify each game so that rather than read the PCB DIPs it calls a bankswitch to the menu bank then returns a byte with the stored DIP data.
That part is mostly done but I now need to make a way of editting the DIP data from the menu screen. That opens up a whole lot of code that needs writing now. Suddenly the simple front end game select screen now needs expanding and sub-menus building.
Mitchell Gant said:
Hey, that sounds great but don't over-engineer it. If 99% of people want default settings with free play then just hard-code that in. Don't spend ages trying to get the edge cases supported when a sensible default would make most of us happy
