Supercharger programming

[supercat]

I'm working on a 1K minigame for the Supercharger and am having a couple problems. Perhaps someone else who's dealt with the thing can offer some advice.

 

-1- The program starts fine in emulation. On a real unit, however, it dies about 2/3 of the time on startup. My code turns on an audio beep before it does anything else, and the times that it dies (black screen) it does not beep, suggesting that it's dying before it starts executing my code. Is there a potential issue with the header information and such (which I don't really understand but just copied out of Stella-Sketch)?

 

-2- My understanding of the Supercharger was that the first memory access over address $F000 that occurred at least four but no more than six cycles following an access to $F000-$F0FF would trigger a memory write. This would suggest that the sequence:

  lda $F0E7
 lda $F123

would store $E7 into address $F123. This doesn't seem to work in Z26, though. It does work if I use:

  lda $F0E7
 nop
 lda $F123

but that doesn't really seem right, since the address fetch for the last instruction will take place on the fifth cycle following the trigger access; it would seem that this should trigger a write on the address fetch, rather than on the following data fetch.

 

My code currently uses (ZP),Y for all the accesses and that seems to work, but it's a real pain in the tusch. What is supposed to work there?

[+batari]

I'm working on a 1K minigame for the Supercharger and am having a couple problems.  Perhaps someone else who's dealt with the thing can offer some advice.

 

-1- The program starts fine in emulation.  On a real unit, however, it dies about 2/3 of the time on startup.  My code turns on an audio beep before it does anything else, and the times that it dies (black screen) it does not beep, suggesting that it's dying before it starts executing my code.  Is there a potential issue with the header information and such (which I don't really understand but just copied out of Stella-Sketch)?

 

-2- My understanding of the Supercharger was that the first memory access over address $F000 that occurred at least four but no more than six cycles following an access to $F000-$F0FF would trigger a memory write.  This would suggest that the sequence:

  lda $F0E7
 lda $F123

would store $E7 into address $F123.  This doesn't seem to work in Z26, though.  It does work if I use:

  lda $F0E7
 nop
 lda $F123

but that doesn't really seem right, since the address fetch for the last instruction will take place on the fifth cycle following the trigger access; it would seem that this should trigger a write on the address fetch, rather than on the following data fetch.

 

My code currently uses (ZP),Y for all the accesses and that seems to work, but it's a real pain in the tusch.  What is supposed to work there?

885326[/snapback]

I only have basic knowledge of how it works, but from what I understand, I think the timing can be customized. In the header, there is a byte which must be set a certain way to set the write pulse delay, enable/disable writes, etc.

 

This value can also be set after startup by accesses to $F0XX then $FFF8 I believe.

 

This is from http://www.io.com/~nickb/atari/doc/sctech.txt

 

00002000: E2 F2 0B 18 38 00 24 02 00 00 00 00 00 00 00 00
          \_/   I        I
           I    I        ---- Multiload Index (0=first or only)
           I    I             (Sequence number)
           I    I
           I    ---- Write Pulse Delay, bankswitch scheme,
           I         RAM enable/disable, ROM configuration
           I
           ---- Start address low/high

Bankswitchscheme on startup
---------------------------
After loading the tape, the value contained in the 3rd byte of the
header is loaded to $80. And bankswitching is set according to the
value of that byte.

(remember?)

  D7-D5 . . . WRITE PULSE DELAY

  D4-D2 . . . RAM/ROM CONFIGURATION
                 VALUE   $F000  $F800
1.              XXX0 00XX   3     ROM
2.              XXX0 01XX   1     ROM
3.              XXX0 10XX   3      1
4.              XXX0 11XX   1      3
5.              XXX1 00XX   3     ROM
6.              XXX1 01XX   2     ROM
7.              XXX1 10XX   3      2
8.              XXX1 11XX   2      3

  D1   . . . . WRITE ENABLED (=1)

  D0   . . . . ROM POWER (OFF=1)

[Eckhard Stolberg]

-1- The program starts fine in emulation.  On a real unit, however, it dies about 2/3 of the time on startup.  My code turns on an audio beep before it does anything else, and the times that it dies (black screen) it does not beep, suggesting that it's dying before it starts executing my code.  Is there a potential issue with the header information and such (which I don't really understand but just copied out of Stella-Sketch)?

As batari mentioned, there is the write pulse delay, which might not be set correctly for your Supercharger. But I think the Stell-A-Sketch header leaves it to the SC to find the proper write pulse delay, so this is probably not your problem.

 

If your game crashes before it executes even a single instruction, I would suspect a loading problem. What are you using to transfer your binary to the SC? I think I have experienced a similar problem, if the footer tone after the binary transfer wasn't long enough.

 

-2- My understanding of the Supercharger was that the first memory access over address $F000 that occurred at least four but no more than six cycles following an access to $F000-$F0FF would trigger a memory write.

885326[/snapback]

The SC doesn't count cycles. It counts address changes. The write will go to the fifth different address after the access to $F0xx, but only if this address is in the ROM area and if writing is enabled. Writes to the control byte at $FFF8 will alway happen immediately. There is no address counting or RAM enable for this.

 

 

Ciao, Eckhard Stolberg

[kisrael]

I'm really no supercharger expert though I did use one during JoustPong dev.

 

It seemed kind of tempremental at times...does it seem to get through the full loading process? do other ROMs play ok on it consistently?

[supercat]

If your game crashes before it executes even a single instruction, I would suspect a loading problem. What are you using to transfer your binary to the SC? I think I have experienced a similar problem, if the footer tone after the binary transfer wasn't long enough.

I'm using WPLAYBIN. Though I'm thinking I may have to reexamine some of the header to make sure I didn't bump anything. How does the header in the BIN file compare with the headers of the tape blocks?

 

The SC doesn't count cycles. It counts address changes. The write will go to the fifth different address after the access to $F0xx, but only if this address is in the ROM area and if writing is enabled. Writes to the control byte at $FFF8 will alway happen immediately. There is no address counting or RAM enable for this.

 

Counting address changes. Interesting. Does it look at the entire address (well A0-A12) when making the determination, so the sequence:

Foo:
 LDA $F0xx,x
 NOP
 LDA MyAddress

is guaranteed to work for any value of MyAddress other than Foo+6 or Foo+7 [either of which would cause a write to address Foo+8]?

 

If they're counting address changes, I wonder why they need the write pulse delay to be programmable? I would have guessed that they needed that to get suitable timing accuracy over a several-cycle period, but accuray within a single cycle shouldn't have been a problem.

 

I wonder why that other document says the SC writes are based on cycles?

[Eckhard Stolberg]

I'm using WPLAYBIN.  Though I'm thinking I may have to reexamine some of the header to make sure I didn't bump anything.  How does the header in the BIN file compare with the headers of the tape blocks?

The header format of both the SC tapes and the emulator binaries are described in Chris Salomon's text that batari linked to in his post above.

 

Counting address changes.  Interesting.  Does it look at the entire address (well A0-A12) when making the determination, so the sequence:

Foo:
 LDA $F0xx,x
 NOP
 LDA MyAddress

is guaranteed to work for any value of MyAddress other than Foo+6 or Foo+7 [either of which would cause a write to address Foo+8]?

No, that would only work for Foo+6. When you access Foo+7 that already is the 5th different address after initiating the write. Therefore you would overwrite the opcode for the next instruction after LDA MyAddress.

 

Also worth noting is the fact that accesses to $F0xx during the writing process will not interrupt it. So

LDA $F012
NOP
CMP $F034

will write $12 to $F034 without initiating a new write with the value $34.

 

If they're counting address changes, I wonder why they need the write pulse delay to be programmable?  I would have guessed that they needed that to get suitable timing accuracy over a several-cycle period, but accuray within a single cycle shouldn't have been a problem.

Acuracy within a single cycle can be a problem, if you don't have access to the clock line on your cart and therefore don't know when addresses are valid. I think Atari even changed the design of the 7800 because of this. On the older models some games with superchip RAM had problems.

 

I wonder why that other document says the SC writes are based on cycles?

886468[/snapback]

That was just the first theory we came up with when we started analysing SC games. Back then we didn't know much about the inner workings of the 6507 opcodes. And since there is a memory access for every cycle, that was easy to confuse. We only noticed we were wrong when we actually tried to add SC support to the emulators.

 

 

Ciao, Eckhard Stolberg