[fujinet] proposal: storing legacy game High scores on TNFS servers.

[tschak909]

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.

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?

---

Die Bytes 11-14 im ATR-Dateiformat werden nicht verwendet.

verwenden Sie die Bytes 11 und 12, um einen einzelnen Sektor zu bestimmen, der als schreib-lesbar markiert werden kann, ungeachtet des gemounteten Modus des Disk-Images.

Der Zweck ist, einen Sektor zu markieren, der hohe Punktzahlen speichern kann.

Wenn auf den Sektor zugegriffen wird, wird der Cache immer geleert, und WRITEs auf diesen Sektor führen zu einem vorübergehenden erneuten Öffnen als Read-Write unter Verwendung eines sekundären Dateideskriptors, der dann sofort geschlossen wird.

Spiele, die dies nutzen könnten, zum Beispiel:

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

Gedanken?

[Erhard]

Hi,

I am sorry to say that the information about the ATR header is not fully correct.

According to my collected docs things are merely as follows:

Code: Alles auswählen

ATR-Header Definition
---------------------

0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
96 02 00 23 80 00 00 00 00 00 00 00 00 00 00 00
----- ----- ----- ----- ----------- -- -- -- --
  |     |     |     |        |       |  |  |  |
  |     |     |     |        |       |  |  |  ----- Bit 0 = schreibgeschützt, Bit 1 = versiegelt (APE)
  |     |     |     |        |       |  |  -------- unused
  |     |     |     |        |       |  ----------- unused
  |     |     |     |        |       -------------- unused
  |     |     |     |        ---------------------- 32-Bit CRC (APE)
  |     |     |     ------------------------------- Imagegröße (*1) /16 hi-word
  |     |     ------------------------------------- Sektorgröße (128 / 256 Bytes)
  |     ------------------------------------------- Imagegröße (*1) /16 lo-word
  ------------------------------------------------- "Nickatari" Signatur


*1) Imagegröße
---------------
  Anzahl der Bootsektoren (3) * 128 Byte
+ Anzahl der restl. Sektoren  * 128 o. 256 Byte


SIO2PC Doku:

The 9th byte ($08)
- Bit 5 = 1 means the disk is write protected
- Bit 4 = 1 means the disk image is treated as copy protected (has bad sectors)

The 10th and 11th bytes ($09, $10)
- are a word which contains the number of the first (or of a typical) bad sector

I would not agree to re-defining any already used bytes.

Beyond this I can imagine that this might be a good idea.

Best, Erhard

[tschak909]

It's okay, there are other unused bytes, two even.

-Thom

[tschak909]

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

my_photo-1.jpg (47.2 KiB) 2303 mal betrachtet

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

Also, the documentation has been posted on how this is implemented:
https://github.com/FujiNetWIFI/fujinet- ... gacy-Games

---

Der Code zur Implementierung dieser Funktion wurde nach Master übertragen.

Jeder, der ein Software-Update durchgeführt hat* und von Master ziehen kann, kann testen:

(1) Master ziehen und bauen.
(2) Gehen Sie zu apps.irata.online
(3) gehe zu /Atari 8-bit/Games/High Score Enabled/ und wähle Jumpman.atr als READ ONLY.
(4) spiele eine halbwegs anständige Partie Jumpman (mindestens 3000 Punkte)
(5) Gib die Punktzahl in die Highscore-Tabelle ein.
(6) Schauen Sie, ob die Punktzahl bestehen bleibt.

Außerdem wurde die Dokumentation veröffentlicht, wie dies implementiert wird:
https://github.com/FujiNetWIFI/fujinet- ... gacy-Games

[tschak909]

@16kRAM (Michael Sternberg) and I played a few rounds of Jumpman. Seems to work.

my_photo-3.jpg (47.56 KiB) 2276 mal betrachtet

-Thom

[cas]

To prevent accidental writes to disks that should never be written to, I recommend to implement a "strict read-only" mode in the Fujinet firmware that will never write to the disk (on SD-Card or on a server), no matter which values are in the unused parts of the ATR file.

It would be good to have a kind of 'magic code' in the unused bytes of the ATR images that flag the "write only highscore sectors" (restricted write) function, so that writing to disk does not happen by accident.

To prevent confusion, the new (and possibly default) mode should not be called/shown as "read only" mode, maybe as "restricted write" mode.

Greetings

Carsten

[tschak909]

The header bytes specify a sector range and number of sectors. If they are 0, then high score mode is not enabled.

If they are, then any writes outside of that sector range are not done, and an error is issued.

If they are, any writes inside the sector range happen.

This means, that to use this mode at all, you have to modify the ATR header to specify a starting sector, and number of sectors.

-Thom

[HiassofT]

As the ATR header already contains a bit indicating write protect (bit 5 of the 9th byte / offset 8) it'd be best to add another bit in that byte indicating the highscore feature and documenting that they are mutually exclusive and if both are set then write protect has precedence.

This would allow simple on-the-fly write-protecting of images in a standard conformant way and also allow other software to not get confused about the "highscore sector" of fujinet. ATR also has this for it's copy protected format (enabled by bit 4 of that byte) and then the sector number stored in bytes 10/11.

So using eg bit 6 of that byte for Fujinet's "highscore sector" support and bytes 10/11 for the sector number would be a possibility.

See the "COPY PROTECTED DISK SUPPORT" section of Nick Kennedy's ATR specs
http://pages.suddenlink.net/wa5bdu/readme.txt

Recall that an SIO2PC disk image has a 16 byte header. There are a few
bytes now used to tell SIO2PC about the good/bad status of the disk.
The 9th byte of the header contains information in individual bits. Bit 4 =
1 means the disk image is treated as copy protected (has bad sectors).
Bit 5 = 1 means the disk is write protected. The 10th and 11th bytes of
the header are a word which contains the number of the first (or of a
typical) bad sector. What I mean by typical is that it does contain both

EDIT: fixed the wrong "byte 11/12" typo which should have read "byte 10/11", same as in official specs.

so long,

Hias

[tschak909]

Thanks, am grinding this through my head, and thinking about it.
-Thom

[tschak909]

The current crop of high-score enabled games on apps.irata.online:

-Thom

[cas]

The header bytes specify a sector range and number of sectors. If they are 0, then high score mode is not enabled.

My experience with software is that not all software will adhere to the specs, so it might be possible that the "unused" bytes in the ATR will contain random content, and that could be dangerous with this new feature (which I like) being enabled.

Greetings

Carsten

[tschak909]

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

https://github.com/FujiNetWIFI/fujinet- ... r.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)

[tschak909]

A video showing the High Score Enabled feature now available for the #atari8bit #fujinet.

By using a few previously unused bytes in the header of ATR files, a range of sectors can be specified to be read-write, even if the disk image is mounted read only. With this feature, games on public TNFS servers can have high score tables on their disk images marked read-write, and scores will be written back to the server, transparently, without needing to change the game.

In addition, web pages can be set up to post high score table changes, as demonstrated in the video.

You can see the scores for these games here, and they refresh every 30 seconds: http://scores.irata.online/

Youtube video: https://www.youtube.com/watch?v=eOVfPQiFx7c

[tschak909]

ok, actually applied a consistent design style to each of the high score pages, based on screenshots from each game, what do you all think?

Since portrait displays have dead space for pages like this, the game backgrounds are placed to better utilize it.

[tschak909]

I have started to experiment with grafting high scores into existing games, starting with Pac-Man, which had its source code found in 2018.

starting with some display code.

If anyone wants to hack along, the code is in github:
https://github.com/FujiNetWIFI/fujinet- ... ts/pac-man

(the following is my opinion)

This is what can happen, when source code is preserved, and why I feel that retrocomputing projects should be open source.

-Thom

[tschak909]

#FujiNet #atari8bit #highscores Adventure Intl's Rear Guard has been High Score Enabled.
TNFS: apps.irata.online/Atari 8-bit/Games/High Score Enabled/Rear Guard (BASIC).atr
Scores: http://scores.irata.online/rearguard.html #retrogaming Scott Adams