Jump to content
IGNORED

SuperCharger jumpstart 2/2


EricBall

Recommended Posts

In part 1 I covered how to write to SuperCharger RAM and the Control Register ($1FF8/$FFF8). Now I will cover the SuperCharger header and file format.

 

Actually, The SuperCharger doesn't really have a file format; instead it has a audio format. The file is just a standardized way of storing the data which is used to create the audio. This file is then used by a tool like MakeWav or WPlayBin to create the audio or by an emulator to execute the code.

 

Supercharger 8448 bin format
6114 bytes       24 pages each 256 bytes
2048 bytes       padding (ROM pages)
  8 bytes        game header
                 - start address LSB
                 - start address MSB
                 - RAM config byte (saved in $80)
                   D7-D5 write pulse delay
                   D4-D2 bank config
                       000	3	ROM
                       001	1	ROM
                       010	3	1
                       011	1	3
                       100	3	ROM
                       101	2	ROM
                       110	3	2
                       111	2	3
                    D1 write enable (1 enable, 0 disable)
                    D0 ROM power (0 power on, 1 power off)
                  - page count (number of non-blank pages)
                  - checksum (sum of all 8 game header bytes = $55)
                  - multi load index number
                  - progress counter LSB (page count)*256/21 - (MSB-1)*256
                  - progress counter MSB (page count)/21 + 1
  8 bytes        padding
 24 bytes        page number table
                       page # * 4 + bank # - 1 (0<=page #<=7, 1<=bank #<=3)
  8 bytes        padding
 24 bytes        page checksum table
                       sum of bytes in page + page number value + page checksum = $55
184 bytes        padding

 

So, the first 6K of the file is the code & data for the game. This doesn't have to be in order because the header contains a page mapping table. So not only doesn't it have to be Bank 1, Bank 2, Bank 3, but you could have the odd numbered pages (e.g. $11xx, $13xx, $15xx; each page is 256 bytes) followed by the even numbered pages (e.g. $10xx, $12xx). Why would you want to do this? Putting the banks out of order may reduce the number of RORGs you have to do. (i.e. if you use bank layouts 2+3 and 1+3, you could lay out the file as Bank 2, Bank 3, Bank 1 so only Bank 1 needs RORGs.) Also, if you put any usused pages after the used pages then MakeWav etc will automatically skip those pages when creating the audio stream (smaller file, faster loads).

 

After the 6K of game code & data is 2K of padding. What's this you ask? It's the SC address space reserved for the ROM. This is then followed by the header (maybe I should call it a footer, eh?). Assuming that you ORG'd your data & code at $1000, then this should be ORG'd at $3000. First in the header is the start address of your game, MSB first. This is easy, a simple DC.W Start_Label. Next is the Control Register setting you want your game to start with. (Just be careful that if you do start with write enabled that you don't have your Start_Label at $10xx since that would result in spurious writes!)

 

Okay, the next byte is the number of non-blank pages you are loading. So for a 6K game this would be 24, for a 4K game it would be 16. This tells MakeWav et.al. both the number of pages to make into audio and the number of entries in the page number table.

 

The next byte is a checksum. Ideally this should set so the sum of the first 8 bytes in the header is $55. However calculating checksums is a pain and MakeWav et.al. will do it automatically so just set to $55.

 

The next byte is the multi load index. For single load games and the initial load for multiple load games this is zero. For multiload games this can be used to select which level to load. For multiload games this means rather than having to cue up the tape for a specific load, the user could just rewind and play the whole thing through and the SuperCharger would find the right level to load. Obviously with CDs and PCs this isn't as big an issue any more. One important note for multi-loaders: for some reason the SuperCharger clobbers the last page of Bank 1 as part of the load process, whether or not that page is loaded. So don't put anything there which you want to keep between loads.

 

The next two bytes are used to control the speed of the load bars. Again, MakeWav et.al. will calculate this for you. This is then followed by 8 more bytes of padding.

 

The next chunk is the important bit because it determines where the 6K of pages at the beginning of the file are stored in SuperCharger RAM. If you have 6K of code & data in bankwise order this shouldn't be too difficult. But if you are making use of the unused page feature or other re-ordering you will need to be careful when calculating these values. Note the ranges for page (0-7) and bank (1-3) and page is uses the most significant bits (e.g. The last page in the first bank is $1C and can be mapped to either $17xx or $1Fxx.)

 

Finally there's another 8 bytes of padding, 24 bytes of checksums (again MakeWav will handle this so set to $55) and a final 184 bytes of padding.

Link to comment
Share on other sites

Would you agree with my calculation that a 1K minigame entry should be 1008 bytes or less not counting headers (figuring eight bytes for the program header and 4x2 bytes for the block headers)?  I know makewav doesn't need the checksums, but the real tape format does.

920938[/snapback]

Any SC file will be 8448 bytes, whether it uses 1K or 6K. I don't think MakeWav is smart enough to handle files of other sizes.

 

Hmm, on the other hand there's nothing that says you can't make a standard 1K bin which intentionally accesses $1FF8 to kick on write mode. MakeWav would load it as a standard <=4K cart. Probably wouldn't work on a CC/CC2 or in an emulator though.

Link to comment
Share on other sites

Any SC file will be 8448 bytes, whether it uses 1K or 6K.  I don't think MakeWav is smart enough to handle files of other sizes. 

921540[/snapback]

 

The minigame rules allow for physical file sizes bigger than 1k in cases where common data formats require it (e.g. a 1K ROM for the 2600 should be a 2K file with the first 1024 bytes blank). So for SDI, I put code+data in the first 1006 bytes, then a slew of zeros, and then some headers starting at $2000 with zeroes mixed in.

Link to comment
Share on other sites

  • 14 years later...

I'm having trouble understanding this. What do the values *in* the page table refer to? Presumably pages in the 6k block at the beginning of the bin file.

 

For example, if the second index in the page table is 04, that refers to the page (of 256 bytes) in the bin file at offset $0400.

 

Meanwhile, the second index in the page table refers to the second page of the the first RAM bank. In other words, bank 0 offset $0100.

 

So, using this example, 256 bytes starting at $0400 will be copied to RAM bank 0 starting at $0100.

 

Have I completely misunderstood this or is that right?

Link to comment
Share on other sites

The values only refer to where the page will be copied in the SC ram and are encoded like this:
[address page offset] * 4 + [bank number]
The values are in the same order as the pages in the first 6k block of the binary file. So the first value refers to the first page in the binary, the second value to the second page in the binary and so on.


So in your example a value "$04" as the second index in the page table means that the second page in the binary ($0100-$01ff) will be copied in the second page of bank 0

 

You can find some more info in the following docs:

https://web.archive.org/web/20110423060211/http://www.io.com/~nickb/atari/doc/sctech.txt

 

https://www.biglist.com/lists/stella/archives/199901/msg00026.html

 

The Cuttle Cart manual is a good source of info about the Sc too:

https://atariage.com/manual_page.php?SystemID=2600&SoftwareLabelID=1160&ItemTypeID=&currentPage=10&maxPages=24

Edited by alex_79
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, JetSetIlly said:

So, using this example, 256 bytes starting at $0400 will be copied to RAM bank 0 starting at $0100.

 

Have I completely misunderstood this or is that right?

SuperCharger RAM is different than standard RAM update schemes because it is treated as ROM but this lets the whole 6K of ROM be addresses as RAM without offsets.

 

Here are two update examples that illustrates the difference using a cross compiler for the SuperCharger and a standard CBS RAM scheme similar to the Superchip:

SameProgram_SuperCharger_ROMtoRAM_example.thumb.jpg.82a9efe7e1da81ac62211e2f2abbb0f5.jpg

 

SameProgram_Standard_RAM_update.thumb.jpg.10a2600ee949350a86e4a5770d13f5e8.jpg

 

 

 

  • Thanks 1
Link to comment
Share on other sites

2 hours ago, alex_79 said:

The values only refer to where the page will be copied in the SC ram and are encoded like this:
[address page offset] * 4 + [bank number]
The values are in the same order as the pages in the first 6k block of the binary file. So the first value refers to the first page in the binary, the second value to the second page in the binary and so on.


So in your example a value "$04" as the second index in the page table means that the second page in the binary ($0100-$01ff) will be copied in the second page of bank 0

 

You can find some more info in the following docs:

https://web.archive.org/web/20110423060211/http://www.io.com/~nickb/atari/doc/sctech.txt

 

https://www.biglist.com/lists/stella/archives/199901/msg00026.html

 

The Cuttle Cart manual is a good source of info about the Sc too:

https://atariage.com/manual_page.php?SystemID=2600&SoftwareLabelID=1160&ItemTypeID=&currentPage=10&maxPages=24

 

Okay, I've got it. So if:

 

V = pageTable[idx]

 

then

 

bank = V & 3

page = V >> 2

 

I seem to have it mapped correctly now.

 

I'm using the original Supercharger ROM to test so transition counting etc. When the tape register is hit, I'm simply dumping the bin file into RAM, and setting the PC and bank configuration register and continuing from there. Not bothering with the actual tape loading procedure just yet (although that would be interesting to do, and loading from a sound file would be smart).

 

Thanks for your help

 

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...