Gravitar on Space Duel PCB
- Thread starter Mitchell Gant
- Start date
Mitchell Gant
Active member
The next piece of the puzzle to solve is the high score memory problem. Space Duel, Gravitar and Black Widow all use an ER2055 EAROM memory chip to save high scores and some game statistics.
The ER2055 is a 64 byte non volatile memory that is the forerunner to moderm flash memory, but is a very different beast from chips today. Apart from it's special -28V power rail it was very slow, requiring 50mS per byte to erase, then another 50mS per byte to write a new byte. Although the chip is a bytewide parallel device, the game code could not afford for the 6502 CPU to sit with it's data and address busses stuck while the EAROM erased or wrote each byte of data. Not when there are vectors to maintain on screen, interrupts to service and bolts of plasma energy to unleash across the inky void of space towards marauding alien ships! Atari designers therefore added address and data latches to the PCB so that the 6502 could quickly write a byte of data to the appropriate EAROM address and then carry on with executing game code, while the latches held the states until the EAROM had erased or written it's data.
These latches make the EAROM appear as 64 bytes for writing addresses, but only a single byte for reading. To write or erase data you write your data to an address in the range 0x0F00 to 0x0F3F, then select the appropriate control bits by writing to 0x0E80 to perform the desired erase or write function.
For reading a byte you again *write* the the desired address, set the control bits for read, but then read from the single address 0x0A00 where the actual data will be presented.
Investigation of the software shows that all three games use a very similar EAROM control function (yay for Atari code re-use!) that is called once per second and runs a small state machine to control each of three possible modes for read, erase and write, shown in part below.
EAROM_Read: .equ 0xA00
EAROM_Ctrl: .equ 0xE80
EAROM_Write: .equ 0xF00
Read function
LDA #8
STA EAROM_Ctrl
STA EAROM_Write,X ; Set address latch
LDA #9
STA EAROM_Ctrl ; Toggle clock line in read mode
NOP
LDA #8
STA EAROM_Ctrl
CPX EAROM_End_Addr
LDA EAROM_Read ; Read EAROM data byte
Erase function
LDY EAROM_Struct_Siz
LDX EAROM_Address
ASL A
BCC loc_E577
STA EAROM_Write,X ; Set address latch
LDA #40h
STA byte_174
LDY #0Eh ; EAROM selected, erase mode, clock low
Write function
STA EAROM_Write,X ; Set address and data latches
LDY #0Ch ; EAROM selected, write mode, clock low
I saw that I could fairly easily modify some of this code so that I could use normal RAM instead, with the intention of making it battery backed RAM in future. There is already 2K of RAM for Gravitar and Black Widow, but neither game actually uses all 2K. I chose to use the area from 0x700 to 0x7BF as three chunks of 64 byte RAM, one chunk for each game.
Define new address base in Space Duel source
EAROM_Write: .equ 0x700
Define new address base in Gravitar source
EAROM_Write: .equ 0x740
Define new address base in Black Widow source
EAROM_Write: .equ 0x780
The erase function now becomes redundant, so I could simply remove the instruction so that it never writes junk ro RAM:
STA EAROM_Write,X ; Set address latch
The write function stays exactly the same:
STA EAROM_Write,X ; Set address and data latches
The read function needs the address latch write instruction removing so it doesn't overwrite RAM
STA EAROM_Write,X ; Set address latch
And then it is a simple case of replacing
LDA EAROM_Read ; Read EAROM data byte
with
LDA EAROM_Write,X ; Read EAROM data byte indexed from X
The X register still contains the correct index from before the removed STA instruction, so now it simply reads the data from that 64 byte range.
I made changes to the Space Duel and Gravitar code, assembled it, burned a ROM and tested it by playing a game to get a high score and entering my initials. Then I waited 20 or 30 seconds to give the still slow function time to do it's stuff. Then I pressed the PCB reset button and waited for the attract mode to cycle through to the high score list. My initials were still there!
I then flicked the DIP switch to bring in the Gravitar ROM bank and did the same test, again my initials were retained. I then switched back to Space Duel and the initials were still there too. Not an exhaustive test I agree, but a good start and proved that my move to RAM could work.
I also had to modify the Gravitar reset function so that it did not clear 0x700-0x7FF to zero upon reset, but that was a single instruction to remove.
Next I can do the same for the Black Widow code and perhaps rig up a battery backed RAM on the CPU expander to test it properly.
I'm fairly confident that the high score issue is solved and I can remove my ER2055 chip from my PCB now.
The ER2055 is a 64 byte non volatile memory that is the forerunner to moderm flash memory, but is a very different beast from chips today. Apart from it's special -28V power rail it was very slow, requiring 50mS per byte to erase, then another 50mS per byte to write a new byte. Although the chip is a bytewide parallel device, the game code could not afford for the 6502 CPU to sit with it's data and address busses stuck while the EAROM erased or wrote each byte of data. Not when there are vectors to maintain on screen, interrupts to service and bolts of plasma energy to unleash across the inky void of space towards marauding alien ships! Atari designers therefore added address and data latches to the PCB so that the 6502 could quickly write a byte of data to the appropriate EAROM address and then carry on with executing game code, while the latches held the states until the EAROM had erased or written it's data.
These latches make the EAROM appear as 64 bytes for writing addresses, but only a single byte for reading. To write or erase data you write your data to an address in the range 0x0F00 to 0x0F3F, then select the appropriate control bits by writing to 0x0E80 to perform the desired erase or write function.
For reading a byte you again *write* the the desired address, set the control bits for read, but then read from the single address 0x0A00 where the actual data will be presented.
Investigation of the software shows that all three games use a very similar EAROM control function (yay for Atari code re-use!) that is called once per second and runs a small state machine to control each of three possible modes for read, erase and write, shown in part below.
EAROM_Read: .equ 0xA00
EAROM_Ctrl: .equ 0xE80
EAROM_Write: .equ 0xF00
Read function
LDA #8
STA EAROM_Ctrl
STA EAROM_Write,X ; Set address latch
LDA #9
STA EAROM_Ctrl ; Toggle clock line in read mode
NOP
LDA #8
STA EAROM_Ctrl
CPX EAROM_End_Addr
LDA EAROM_Read ; Read EAROM data byte
Erase function
LDY EAROM_Struct_Siz
LDX EAROM_Address
ASL A
BCC loc_E577
STA EAROM_Write,X ; Set address latch
LDA #40h
STA byte_174
LDY #0Eh ; EAROM selected, erase mode, clock low
Write function
STA EAROM_Write,X ; Set address and data latches
LDY #0Ch ; EAROM selected, write mode, clock low
I saw that I could fairly easily modify some of this code so that I could use normal RAM instead, with the intention of making it battery backed RAM in future. There is already 2K of RAM for Gravitar and Black Widow, but neither game actually uses all 2K. I chose to use the area from 0x700 to 0x7BF as three chunks of 64 byte RAM, one chunk for each game.
Define new address base in Space Duel source
EAROM_Write: .equ 0x700
Define new address base in Gravitar source
EAROM_Write: .equ 0x740
Define new address base in Black Widow source
EAROM_Write: .equ 0x780
The erase function now becomes redundant, so I could simply remove the instruction so that it never writes junk ro RAM:
STA EAROM_Write,X ; Set address latch
The write function stays exactly the same:
STA EAROM_Write,X ; Set address and data latches
The read function needs the address latch write instruction removing so it doesn't overwrite RAM
STA EAROM_Write,X ; Set address latch
And then it is a simple case of replacing
LDA EAROM_Read ; Read EAROM data byte
with
LDA EAROM_Write,X ; Read EAROM data byte indexed from X
The X register still contains the correct index from before the removed STA instruction, so now it simply reads the data from that 64 byte range.
I made changes to the Space Duel and Gravitar code, assembled it, burned a ROM and tested it by playing a game to get a high score and entering my initials. Then I waited 20 or 30 seconds to give the still slow function time to do it's stuff. Then I pressed the PCB reset button and waited for the attract mode to cycle through to the high score list. My initials were still there!
I then flicked the DIP switch to bring in the Gravitar ROM bank and did the same test, again my initials were retained. I then switched back to Space Duel and the initials were still there too. Not an exhaustive test I agree, but a good start and proved that my move to RAM could work.
I also had to modify the Gravitar reset function so that it did not clear 0x700-0x7FF to zero upon reset, but that was a single instruction to remove.
Next I can do the same for the Black Widow code and perhaps rig up a battery backed RAM on the CPU expander to test it properly.
I'm fairly confident that the high score issue is solved and I can remove my ER2055 chip from my PCB now.
Excellent work neil
Mitchell Gant
Active member
I'd like to make the 6502 ROM expander board do software controlled bank switching so that I can have a front end screen that will allow me to choose between the three games. I know Black Widow won't work as I don't have a pair of joysticks, but I'd like to make it as complete as possible for people that may have that option.
The vector ROM expander already does bank switching via the GAL. It detects a write to the ROM area and then uses some of the address bits (A6 and A7) to latch which of four banks is required. I have already proved that this works, so all that is required is a similar hardware design for a 6502 ROM/RAM expander in the same way.
In my modified Space Duel code I have added this instruction to the reset routine:
STA $5840 ; Switch to vector ROM bank for Space Duel
For Gravitar it's
STA $5800 ; Switch to vector ROM bank for Gravitar
and for Black Widow it's
STA $5880 ; Vector ROM bank for Black Widow
To do the same for the 6502 ROM I need to make sure that as the bank is switched, it will continue to run valid code from the same address in the new bank, as the 6502 is executing instruction from the very ROM that is being switched out!
I have plenty of spare ROM space now though, so I have decided to add the following code at the same address in each game ROM bank:
.org $FFF0
Bank_Exit:
STA $80C0 ; Switch to bank 3 (game selection front end bank)
Bank_Entry:
JMP Reset
The third bank will be my game select front end software so in hear I will have a slightly different bit of code:
.org $FFF0
Bank_Exit:
STA $8000,X ; Switch to selected bank in X register
Bank_Entry:
JMP Reset
How it works is that once you have selected which game you want to play (yet to be written) the code will jump to Bank_Exit with a value in the X register of either $00, $40 or $80.
The instruction at Bank_Exit will store at one of the three addresses $8000, $8040 or $8080. That will trigger the hardware to select the desired ROM bank and then the 6502 will execute the next instruction at Bank_Entry. This is now a jump to the reset routine of the game stored in the newly selected bank, so you've just switched to that game.
Once you're in that game you also need a way of exiting back out to the game selection bank. The only way I can see to do this is to detect if Player 1 and Player 2 buttons are pressed together, not something that should normally happen during game play.
On Space Duel hardware this turns out to be fairly simple by adding this to the interrupt service routine of each game:
BIT Buttons_Opts + 4 ; Read Player 1 button
BVC Plr_12 ; If Player 1 start pressed
BIT Buttons_Opts + 6 ; Read Player 2 button
BPL Plr_12 ; And if Player 2 start also pressed then
JMP Bank_Exit ; Exit to selection bank
Plr_12:
I partially proved that this works today on Gravitar, but of course without the bank switch hardware all it does is reset straight back to Gravitar when you press both buttons.
The vector ROM expander already does bank switching via the GAL. It detects a write to the ROM area and then uses some of the address bits (A6 and A7) to latch which of four banks is required. I have already proved that this works, so all that is required is a similar hardware design for a 6502 ROM/RAM expander in the same way.
In my modified Space Duel code I have added this instruction to the reset routine:
STA $5840 ; Switch to vector ROM bank for Space Duel
For Gravitar it's
STA $5800 ; Switch to vector ROM bank for Gravitar
and for Black Widow it's
STA $5880 ; Vector ROM bank for Black Widow
To do the same for the 6502 ROM I need to make sure that as the bank is switched, it will continue to run valid code from the same address in the new bank, as the 6502 is executing instruction from the very ROM that is being switched out!
I have plenty of spare ROM space now though, so I have decided to add the following code at the same address in each game ROM bank:
.org $FFF0
Bank_Exit:
STA $80C0 ; Switch to bank 3 (game selection front end bank)
Bank_Entry:
JMP Reset
The third bank will be my game select front end software so in hear I will have a slightly different bit of code:
.org $FFF0
Bank_Exit:
STA $8000,X ; Switch to selected bank in X register
Bank_Entry:
JMP Reset
How it works is that once you have selected which game you want to play (yet to be written) the code will jump to Bank_Exit with a value in the X register of either $00, $40 or $80.
The instruction at Bank_Exit will store at one of the three addresses $8000, $8040 or $8080. That will trigger the hardware to select the desired ROM bank and then the 6502 will execute the next instruction at Bank_Entry. This is now a jump to the reset routine of the game stored in the newly selected bank, so you've just switched to that game.
Once you're in that game you also need a way of exiting back out to the game selection bank. The only way I can see to do this is to detect if Player 1 and Player 2 buttons are pressed together, not something that should normally happen during game play.
On Space Duel hardware this turns out to be fairly simple by adding this to the interrupt service routine of each game:
BIT Buttons_Opts + 4 ; Read Player 1 button
BVC Plr_12 ; If Player 1 start pressed
BIT Buttons_Opts + 6 ; Read Player 2 button
BPL Plr_12 ; And if Player 2 start also pressed then
JMP Bank_Exit ; Exit to selection bank
Plr_12:
I partially proved that this works today on Gravitar, but of course without the bank switch hardware all it does is reset straight back to Gravitar when you press both buttons.
Mitchell Gant
Active member
Today I received some Dallas DS1220 battery backed RAM chips in the post.
A quick hack of two wires for Vcc and WR to fit it in place of the 62256 RAM chip on the Space Duel/Gravitar CPU expander board and now I have battery backed RAM.
This combined with the modified high score code I did a few weeks ago and now I have working high score memory for both Space Duel and Gravitar options on the PCB. I played a few games of Space Duel, powered off and on, then switched to Gravitar and did the same. All scores stayed as I hoped they would. Not an exhaustive test I realise, but a good step.
I'm continuing to write a front end game selection program that will eventually bank switch between games. Progress is fairly slow as I'm not a great 6502 coder, it's the most I've ever written in 6502 assembler in fact!
I have basic vector drawing sussed, along with a double buffer approach the same as Atari used so the 6502 can be filling the next screen while the AVG is currently drawing the last screen. Over the weekend I got text handling working, in the same compressed Atari format that most of these vector games used, where 3 characters are stored in two bytes. I've written a crude PC application to decode and encode text sentences. Still more work to do though.
A quick hack of two wires for Vcc and WR to fit it in place of the 62256 RAM chip on the Space Duel/Gravitar CPU expander board and now I have battery backed RAM.
This combined with the modified high score code I did a few weeks ago and now I have working high score memory for both Space Duel and Gravitar options on the PCB. I played a few games of Space Duel, powered off and on, then switched to Gravitar and did the same. All scores stayed as I hoped they would. Not an exhaustive test I realise, but a good step.
I'm continuing to write a front end game selection program that will eventually bank switch between games. Progress is fairly slow as I'm not a great 6502 coder, it's the most I've ever written in 6502 assembler in fact!
I have basic vector drawing sussed, along with a double buffer approach the same as Atari used so the 6502 can be filling the next screen while the AVG is currently drawing the last screen. Over the weekend I got text handling working, in the same compressed Atari format that most of these vector games used, where 3 characters are stored in two bytes. I've written a crude PC application to decode and encode text sentences. Still more work to do though.
Nice one Neil, bit of an epic project this.
Mitchell Gant
Active member
Thanks to Phillmurr
we now have a proper 6502 ROM/RAM expander board that hosts a GAL22V10 and battery backed RAM, along with a 27512 EPROM or with a little hack a 29F010 flash device.
After a few teething troubles caused by me putting the wrong RAM chip in and bugs in the GAL code, I now have Space Duel,Gravitar and Black Widow running the same as I had with the first expander.
The new expander also has a GAL output pin spare which I have used to decode the extra vector memory space. This means I can remove the hack of a chip (shown bottom left with blue wires dangling off it).
Next I can try to implement the ROM bank switching so I can choose between games from a front end screen.
I'll also be aiming at putting this same 6502 expander board into my other vector games like Battlezone, Tempest and Asteroids so that the original EPROMs can be removed and hopefully make them more reliable. I've already done a Tempest this way with the other expander board and it stopped a lot of flakiness caused by corrosion on the EPROMs and sockets. It's a lot easier than desoldering 10x 24 pin EPROM sockets on a Tempest board!
After a few teething troubles caused by me putting the wrong RAM chip in and bugs in the GAL code, I now have Space Duel,Gravitar and Black Widow running the same as I had with the first expander.
The new expander also has a GAL output pin spare which I have used to decode the extra vector memory space. This means I can remove the hack of a chip (shown bottom left with blue wires dangling off it).
Next I can try to implement the ROM bank switching so I can choose between games from a front end screen.
I'll also be aiming at putting this same 6502 expander board into my other vector games like Battlezone, Tempest and Asteroids so that the original EPROMs can be removed and hopefully make them more reliable. I've already done a Tempest this way with the other expander board and it stopped a lot of flakiness caused by corrosion on the EPROMs and sockets. It's a lot easier than desoldering 10x 24 pin EPROM sockets on a Tempest board!
forcefulfil
EDOT King
Just brilliant!
Battlezone
Active member
Inspiring work.
These are the kind of collaborative projects that the community will need more and more. Fantastic work Neil and Phil
Hurray Banana2016-08-16 10:58:55
Hurray Banana2016-08-16 10:58:55
Mitchell Gant
Active member
Nes4life said:A UK based Asteroids / Asteroids Deluxe / Lunar Lander mod that doesn't break the bank would be very pleasant indeed
Very easy to make the ROM banks switch between the three games with the same 6502 and vector memory expander PCBs I used for the Space Duel.
But not so easy to make a playable game as there are controls and sound hardware differences. I understand Scott Brassington in the USA has done a good job trying to get this to work.
I've got Philmurr's board into my cab now and done the first step to bank switching on the GAL logic. I've also put my front end code in the ROM and tried it in my cab for the first time. Much more to do, but it's always nice to see real vector images.
And yes I know there's a 'typo' where it says P1 twice rather than P1 and P2. It's Atari 5 bit packed text format, so really a problem in the encoding software rather than me actually typing wrong!
This one is animated with text bouncing up and down and green boxes zooming in, so my camera picked up multiple vector draws.
This is fading boxes into centre of screen, but my phone camera missed off a lot of the dimmer lines.
