7800 HSC Format Breakdown

[RevEng]

I wanted to update 7800basic so games could use the HSC for game saves, in addition to hi score tables. I poked at it in the MESS debugger and updated GroovyBee's disassembly enough to produce this...

 

 

The downside is you only get 25 bytes per game, per difficulty level, and there are only 69 entries in the table. Devs shouldn't go hog wild on using it for extra storage, but 25 or 50 bytes per game seems fair.

 

You can find the updated HSC disassembly here.

 

[edit] One additional note: The 3 high score initials are encoded with 5 bits each, consolidated into 2 bytes, in the form 22211111 22-33333

[RevEng]

A potential use for that lonely unused byte... we might use it to store a running random seed value. Anybody else have any grand ideas?

[Cybearg]

Are new High Score Cartridges being produced, or is this just for the lucky folks who bought one when they were in production?

 

Is this a superior solution to using an AtariVox?

[RevEng]

The XM will come with HSC capability. I don't know of any other efforts to replicate the HSC.

 

Its a different solution to AtariVox/SaveKey. HSC is cart-based (fast), and has built-in utility routines to display the high score tables, but limited space (1725 bytes in game storage space). AtariVox/SaveKey is controller port-based (slow), has generic flash access, and more space to grow (12288 bytes in game storage, plus 16k in undefined storage)

[tep392]

Do you know what the HSC code does when it runs out of table entries? I can see that getting filled up pretty fast with all the games that now support it.

[RevEng]

Expermimentally, it looks like the HSC keeps overwriting the 6th slot with each new game it encounters. It also starts messing up the index table numbering, so other saves probably get screwy.

 

Not the most graceful way to fail... I might throw together a little utility to manage the save data at some point, so users can wipe the card if its messed up, rename the owner, delete old game entries, etc.

[+playsoft]

I've just started looking at the high score cart and that diagram was really useful thanks.

 

I did wonder what the index table is used for and I think it might be an age table, so in the event of the cart becoming full it overwrites the entry that was used the longest time ago.

 

From the disassembly in GameSearchLoop it looks like it's maintaining the eldest value and index in zAA and zB6. If the required entry is found, these are overwritten with the values for the (found) entry. If it's not found, InitializeGameSaveStructures overwrites the eldest. In both cases the code at e35A1 resets the entry to age 0 then loops over all the entries and ages (increments) any which are younger than the original age. The net result should be the entry has an age of 1 with the other entries having greater values reflecting their age.

 

I have not tested the HSC full scenario but I can see the index values changing like this when playing games and looking at A7800's hiscore.nv. Start with a blank HSC, play Galaga and it gets an index value of 1. Play Asteroids, it's 1 and Galaga is 2. Play Galaga again, it's 1 and Asteroids is 2.

 

[RevEng]

Makes sense to me!

[+wavemotion]

Another tremendous resource, @RevEng - well sleuthed and still highly useful for me in 2022

 

Given that we now have north of 69 games and that some games use more than 1 slot... it seems like the HSC memory can get rather crowded.  I think on my main emulation system, I'm using 50+ entries of the 69 available.

 

Emulators can, of course, solve this with some clever programming. I don't know if anyone has done anything in this regards. Two easy "solutions" come to mind:

1. Each game gets its own 2K SRAM for the high score cart.  It's a bit of wasted space but that's cheap these days. Drawback is potential games that might utilize/import HSC data from one game to another and it leaves a bunch of .sram files floating around.
2. Multiple High Score SRAM "carts" that a player can define with different names that can be virtually "inserted" into the emulated console. Much like you select a ROM to play, you can also select a different High Score cart. Drawback is that it's a bit of a manual process.

Though for A7800DS I'm actually thinking of a sort of auto-wear-leveling for the HSC. Clusters on the DS/DSi SD card are 32K. I could easily make 16 x 2KB SRAM (32K backed file on the SD card) where the last hex digit of the game rom CRC auto-selects the area of SRAM that gets seen in memory. In this way, I get 16x effective slots (1104 slot entries) and the player doesn't really have to even be aware. It would be akin to HSC SRAM banking that is done when the game loads. That would likely be enough spreading out of the high score data to not run into a full cart in the foreseeable future.

 

Does anyone know of any other emulators that are dealing with the potential "filling up" of HSC contents?  I know the SaveKey/AtariVox is another option and I do support that for StellaDS and could probably port the code over... but it feels like the HSC is still a pretty viable thing (and it's damn cool!).  Did anyone ever make an improved-but-backwards-compatible highscore ROM that used a larger SRAM area?

 

[RevEng]

It's mostly an ignored problem. Part of that is due to HSC not existing in a useful physical form right now. Atari didn't release it. Curt Vendel produced a repo from the schematics, but it had problems remembering the scores due to parasitic drain. XM was supposed to provide a working HSC, but it's not likely happening.

 

Both the CuttleCart2 flash cart and the MiSTer 7800 core use a separate HSC area/file for each game. A7800 and Mame just ignore the issue, and use a single global storage file in your home directory. I think the former behaviour is fine, personally. The problem of a stuffed HSC is much bigger than some new game trying to access another game's save data and failing.

 

Expanding the HSC memory would be a bit tricky. It would require an updated HSC rom *and* would also require some kind of graceful behaviour for games that access the nvram directly. The address space that HSC can use is pretty much fixed, so the nvram would likely need to be bankswitched, and leave the default bank for games that do direct access. Given how tough it's been to just get a standard HSC that works, I don't think we'll see that mega HSC anytime soon.

[+wavemotion]

More good info, thanks @RevEng

 

Last night I settled on an 8x density on the HSC by using virtual cart slots backed to a single 16K SRAM file.  Each 2K SRAM slot is based on the first letter of the cart filename.  The first time you run a game with HSC support and enter an owner-name it will replicate that (along with the magic numbers) across all 8 virtual cart slots. Similarly if you later change the cart owner's name, that gets replicated across all 8 virtual cart slots.  The user is blissfully unaware - they think they have one save cart but under the hood it's magically spread out across 8 virtual high score carts. 

 

In this way, the effective number of game entry slots is 552 though based on the game filename it's not quite evenly distributed. But it's good enough - and virtually ensures that we won't run out. Now I don't feel so badly playing every variation and difficulty on @PacManPlus's PMC 40th as it has lots of room to breathe!

Edited November 4, 2022 by llabnip

[Ecernosoft]

1 hour ago, llabnip said:

More good info, thanks @RevEng

 

Last night I settled on an 8x density on the HSC by using virtual cart slots backed to a single 16K SRAM file.  Each 2K SRAM slot is based on the first letter of the cart filename.  The first time you run a game with HSC support and enter an owner-name it will replicate that (along with the magic numbers) across all 8 virtual cart slots. Similarly if you later change the cart owner's name, that gets replicated across all 8 virtual cart slots.  The user is blissfully unaware - they think they have one save cart but under the hood it's magically spread out across 8 virtual high score carts. 

 

In this way, the effective number of game entry slots is 552 though based on the game filename it's not quite evenly distributed. But it's good enough - and virtually ensures that we won't run out. Now I don't feel so badly playing every variation and difficulty on @PacManPlus's PMC 40th as it has lots of room to breathe!

Hey, is it possible to detect HSC?

I think it would be great for ICT3 as it uses passwords that fit nicely into 8 bytes. Therefore you could save your progress. And also, maybe you’re high-scores too! ( those are even smaller at 4 bytes)

[PacManPlus]

5 hours ago, Ecernosoft said:

Hey, is it possible to detect HSC?

I think it would be great for ICT3 as it uses passwords that fit nicely into 8 bytes. Therefore you could save your progress. And also, maybe you’re high-scores too! ( those are even smaller at 4 bytes)

 

 

Here's the HSC detection routine I've been using, and I *believe* the other homebrew authors use it as well (please correct me if I'm wrong):

 

;	HSCEXIST - THIS ROUTINE CHECKS FOR THE EXISTENCE OF THE HIGH SCORE CART
;	INPUT: NONE
;	USES A
;	RETURNS: HSCHERE = $00 IF NO HSC, $01 IF HSC EXISTS
HSCEXIST
	LDA #$00									;INITIALIZE TO ZERO
	STA HSCHERE
	LDA $3900									;SEE IF HI SCORE CART IS THERE
	CMP #$C6
	BNE HSCENOHSC
	LDA $3904
	CMP #$FE
	BNE HSCENOHSC
	INC HSCHERE
HSCENOHSC
	RTS

 

 

Edit I *love* the idea that @llabnip has regarding the HSC.  I wonder if that could make it onto a cart...  

Edited November 4, 2022 by PacManPlus

[Ecernosoft]

1 minute ago, PacManPlus said:

 

 

Here's the HSC detection routine I've been using, and I *believe* the other homebrew authors use it as well (please correct me if I'm wrong):

 

;	HSCEXIST - THIS ROUTINE CHECKS FOR THE EXISTENCE OF THE HIGH SCORE CART
;	INPUT: NONE
;	USES A
;	RETURNS: HSCHERE = $00 IF NO HSC, $01 IF HSC EXISTS
HSCEXIST
	LDA #$00									;INITIALIZE TO ZERO
	STA HSCHERE
	LDA $3900									;SEE IF HI SCORE CART IS THERE
	CMP #$C6
	BNE HSCENOHSC
	LDA $3904
	CMP #$FE
	BNE HSCENOHSC
	INC HSCHERE
HSCENOHSC
	RTS

 

 

Thanks!