Jump to content
IGNORED

Storing game high scores for legacy games on TNFS servers.


Recommended Posts

Had a thought, bytes 11-14 on the ATR file format are not used.

 

use bytes 11 and 12 to specify a single sector which can be marked as read-write, despite the mounted mode of the disk image. 

 

The purpose is to mark a sector that can store high scores on public TNFS servers.

 

If sector is accessed, cache is always flushed, and WRITEs to this sector cause a temporary re-open as read-write using a secondary file descriptor, which is then immediately closed.

 

Games that could utilize this, for example:

 

  • Jumpman
  • Track Attack
  • Serpentine
  • BC's Quest for Tires

 

thoughts?

 

image.thumb.png.731d02d35e6f0a8e7c7c392d1aa3edac.png

  • Like 1
Link to comment
Share on other sites

17 hours ago, tschak909 said:

Had a thought, bytes 11-14 on the ATR file format are not used.

 

use bytes 11 and 12 to specify a single sector which can be marked as read-write, despite the mounted mode of the disk image. 

 

The purpose is to mark a sector that can store high scores on public TNFS servers.

 

If sector is accessed, cache is always flushed, and WRITEs to this sector cause a temporary re-open as read-write using a secondary file descriptor, which is then immediately closed.

 

Games that could utilize this, for example:

 

  • Jumpman
  • Track Attack
  • Serpentine
  • BC's Quest for Tires

 

thoughts?

 

image.thumb.png.731d02d35e6f0a8e7c7c392d1aa3edac.png

The code to implement this, has been pushed to master.

 

my_photo-1.thumb.jpg.7f4b1eaa738f6bb423f035c0276fe0e4.jpg

 

Anyone who has done a software bring-up and can pull from master, can test:

 

(1) pull master, and build.
(2) go to apps.irata.online
(3) go to /Atari 8-bit/Games/High Score Enabled/ and select Jumpman.atr as READ ONLY.
(4) play a somewhat decent game of jumpman (at least 3000 points)
(5) plop score in hi-score table.
(6) See if score sticks.

 

Also, the documentation has been posted on how this is implemented:

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/High-Score-storage-for-Legacy-Games

 

-Thom

Edited by tschak909
  • Like 3
Link to comment
Share on other sites

1 minute ago, FifthPlayer said:

Is there some sort of locking mechanism to prevent two people playing the game simultaneously from overwriting each other's high score records?  Probably not a situation that would happen often, but if the game is popular enough, then it could happen.

I can see no real viable way to do this. Would love to be proven wrong. :)

 

Currently, the disk image is opened read/write, sector written, then immediately closed (with the original file handle transposed back), trying to be as atomic as possible.

 

-Thom

 

Link to comment
Share on other sites

1 minute ago, MichaG said:

Do I have to use a special firmware? I use the newest from 2022-10-04. There are some scores from other players, but my highscore is not written back to the server.

It has not been released into production, yet. You have to build and upload it yourself, for now. If you have a development system, you can pull the latest. This is why I literally said "If you want to  pull from master"

 

-Thom

 

  • Like 1
Link to comment
Share on other sites

13 minutes ago, tschak909 said:

Could definitely use some help finding some more games to high-score enable. e.g. I KNOW there was at least one version of BC's Quest for Tires, that still had the high score read/write in the executable.

Why do you want to use EXEcutables instead of original boot disks?

 

Here is a quick selection:

 

178 Spelunker

544 BC's Quest for Tires (both versions)

719 Zombies

677 Caverns of Callisto

390 Crisis Mountain

292 Track Attack

092 Jawbreaker II

 

Btw.: Would you be interested to host my crack collection on your TNFS server?

 

Spelunker (1984)(Broderbund Software)(US)[m][cr CSS].atr BC's Quest for Tires (1983)(Sierra On-Line)(US)[m].atr BC's Quest for Tires (1983)(Sierra On-Line)(US)[a][!].atr Zombies (1983)(Bram)(US)[m][cr CSS].atr Caverns of Callisto (1983)(Origin Systems)(US)[f][cr CSS].atr Crisis Mountain (1982)(Synergistic Software)(US)[cr CSS].atr Track Attack! (1982)(Broderbund Software)(US)[!][OS-B][cr CSS].atr Jawbreaker II (1982)(SierraVision)(US)[!][cr CSS].atr

Link to comment
Share on other sites

1 minute ago, DjayBee said:

Boot disks are actually what I want, I was going to convert them to ATRs anyway. The idea is that the high score table needs to write to the disk somewhere, and I can mark that as writable.

 

Absolutely.

-Thom

 

Link to comment
Share on other sites

23 hours ago, tschak909 said:

I can see no real viable way to do this. Would love to be proven wrong. :)

 

Currently, the disk image is opened read/write, sector written, then immediately closed (with the original file handle transposed back), trying to be as atomic as possible.

Even if the high score sector is read immediately before writing it there’s a gap in which somebody else’s high score can be written before yours. When your high score is saved, only your changes will be preserved: the last writer wins.

 

These games aren’t expecting the high score sector to change under them, so they just read the high scores into memory whenever it’s convenient, possibly only once when the game is loaded. That leaves a large window of time for other writes to happen.

Link to comment
Share on other sites

8 hours ago, Eyvind Bernhardsen said:

Even if the high score sector is read immediately before writing it there’s a gap in which somebody else’s high score can be written before yours. When your high score is saved, only your changes will be preserved: the last writer wins.

 

These games aren’t expecting the high score sector to change under them, so they just read the high scores into memory whenever it’s convenient, possibly only once when the game is loaded. That leaves a large window of time for other writes to happen.

I hear you, and it is indeed a valid concern. Maybe someone else could also jump in? :)

 

If anyone wants to hack on the relevant code in the firmware, it's here:

https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/media/atari/diskTypeAtr.cpp#L113 (sector range code is temporarily removed, as the compiler is doing a very bizarre optimization that needs a work-around)

 

I have also created a repository for all the high score tools that will be made to extract high score sectors for web display:

https://github.com/FujiNetWIFI/fujinet-high-scores

 

To that effect, one of the example scrapers for Jumpman is up, this link will change.

http://scores.irata.online/jumpman.html (temporary)

 

-Thom

  • Like 3
Link to comment
Share on other sites

48 minutes ago, tschak909 said:

Maybe someone else could also jump in?

I doubt that this problem can be solved unless you implement some sort of file locking which only allows one player per ATR at a certain point in time.

On the other hand, for home-use this is a non-problem.

 

You can solve it only if you write a parser/scraper for every game which compares the to-be-saved scores with what's alreday on the server and merges the results.

But if you go this far then you also can implement saving (and loading) the high-scores to/from Hi-Score Café.

Link to comment
Share on other sites

2 minutes ago, DjayBee said:

I doubt that this problem can be solved unless you implement some sort of file locking which only allows one player per ATR at a certain point in time.

On the other hand, for home-use this is a non-problem.

 

You can solve it only if you write a parser/scraper for every game which compares the to-be-saved scores with what's alreday on the server and merges the results.

But if you go this far then you also can implement saving (and loading) the high-scores to/from Hi-Score Café.

It is worth noting that the write happens followed by the close. 

If any other open as write happens while a sector is being written, the write will retry again.

 

This does mean that at worst, a race condition would happen with two people saving at the exact same time, and the person who got there last, would overwrite with older data...

 

I knew this going in, but given potential use patterns, I do not think this will actually be a problem, in practice.

 

FWIW, I do features like this, to spur on people coming together in some form, even if it is to ruthlessly critique it. :)

 

-Thom

Link to comment
Share on other sites

5 minutes ago, tschak909 said:

This does mean that at worst, a race condition would happen with two people saving at the exact same time, and the person who got there last, would overwrite with older data...

You will have this race condition quite often because many titles read the high score table only while booting and from there on only write changes to disk.

Link to comment
Share on other sites

2 hours ago, DjayBee said:

You will have this race condition quite often because many titles read the high score table only while booting and from there on only write changes to disk.

If someone has a better way to do this, please step forward. I did this to try and incite a feature. :)

 

-Thom

 

Link to comment
Share on other sites

17 minutes ago, tschak909 said:

If someone has a better way to do this, please step forward. I did this to try and incite a feature. :)
 

I did not want to talk this feature small or to express that you had a bad idea.

Every "hack" has its caveats. You just need to know and accept them.

 

And I also expect that most people will use this feature on their own servers where they will not have this problem.

Link to comment
Share on other sites

4 hours ago, tschak909 said:

FWIW, I do features like this, to spur on people coming together in some form, even if it is to ruthlessly critique it. :)

Hey, my critique was ruthFUL :P

 

I think the feature is worthwhile as it is, it would just work better on shared servers if games were patched to merge high scores (and even then it wouldn’t be perfect unless there was a way to explicitly lock the file for writing).

  • 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...