Pocket: identifying the required beta key

[mattpannella]

me and @neil-morrison44 were discussing ways to possibly make the beta process smoother on pocket. right now it seems the biggest issue is when a new beta key is released, people don't understand that they need to download the new one, they update their cores, and then nothing works because they have the old beta key

if there was a way for the updaters to identify which beta key is required by a core, we could at least message that to users and hopefully cut down on confusion

a couple ideas that I think would work

1. add the checksum of the beta file in the data_slot inside the core's data.json file. this would technically be a non standard addition to the file, but openfpga seems to ignore things that aren't standard. then we could compare the checksum against the user's file
2. add a date to the beta file name. beta-2023-12-06.bin or something. simpler than checksum but maybe would effect your workflow for mister?

[jotego]

Having different names for the key on each release may create further confusion. I like having the checksum, so the user can get feedback. I have added that feature to jtframe (commit) for both the beta.bin and .rom files. It looks like this:

{
    "instance":{
        "magic": "APF_VER_1",
        "variant_select": {
            "id": 0,
            "select": false
        },
        "data_path": "",
        "data_slots": [
            {
                "id": 1,
                "filename": "aliens.rom",
                "md5": "c29784def287afe117fd37d4a22bd15b"
            },
            {
                "id": 2,
                "filename": "aliens.sav",
                "md5": ""
            },
            {
                "id": 17,
                "filename": "beta.bin",
                "md5": "41ff1124153aa387f6efcfaa7fc69f90"
            }
        ],
        "memory_writes": [
            {
                "address": "0xf9000000",
                "data": "0x0"
            }
        ]
    }
}

So you can give feedback on the game file itself too. You should not stop the process if the game checksum fails as the user may have a hacked or home-brew ROM. I am going to prepare files on a separate branch of JTBIN so you can test with it before making this public. I'll post here again when it is ready.

[jotego]

Checkout this branch:

https://github.com/jotego/jtbin/tree/jtcores_20231111

This contains both full file names for ROMs and MD5 codes for everything

[mattpannella]

I am away for a trip until Wednesday, so I will try and test this out as soon as I can when I get home.

[jotego]

About where to copy the beta.bin file to, it is safe to copy it to all common folders. But, if you want to keep it to the minimum, this yaml file contains the list of cores in beta phase. It is the one used for releases, so it will be up to date for each release.

[mattpannella]

started working on this tonight, but i am running into an issue. the md5 i generate from oct 31st's beta.bin does not match the md5 in the instance json data_slots on branch jtcores_20231111 (41ff1124153aa387f6efcfaa7fc69f90) here are the hashes i calculate from the file:

MD5: 93d32ed43855da0a7fa1fbd0ceb8863e
SHA1: 0147f75ee5c498ebb8e0dfbaadf873ecf7242951
SHA256: 79b1e648f687ce3c701c30163b05958e923781ff2d5ceff9585dbed635d471cd
SHA512: 36a29530310fd5d8fc8835328f1d95cbcc4be4f8395f5139f43f811a87d7b7563647c6c2cffc1b1c9e015aeec16290af636a0c5d28f128c3684b57a7195ce6c7
CRC32: 0b9d7985

is there a new beta key coming in the next release or am i calculating the wrong file hash

[jotego]

Your numbers are right. I am not sure what went on there, but I can see that when I regenerate the files I get the same numbers as you:

{
    "id": 17,
    "filename": "beta.bin",
    "md5": "93d32ed43855da0a7fa1fbd0ceb8863e"
}

Let me delete that branch and prepare a fresh one

[mattpannella]

ok great I figured it was a future file or a mistake. I'm pretty much done on my end then. I just wanted to make sure I was using the correct hash method before building

[neil-morrison44]

It’ll probably be next week before I can get anything into Pocket Sync to use the hash - but I don’t foresee any problems with it

[jotego]

It’ll probably be next week before I can get anything into Pocket Sync to use the hash - but I don’t foresee any problems with it

Thank you. How about the long file names? Are you set for that?

[neil-morrison44]

@jotego should be fine yeah - it’s only the .rom names that’ve changed not the JSONs, right?

Users will have to reacquire the files & the old ones will just sit there but that’s no big issue

[jotego]

The JSONs have the .rom names too, so those have changed too. I have added a md5 field to .rom and beta.bin files in the JSON so you can verify that the created files are correct and provide feedback to the user.

This branch is basically tomorrow's update for the Pocket. You can test it ahead of time.

[neil-morrison44]

Cool, yeah - the filename of the JSON hasn’t changed (that wouldn’t cause issues, but there’s an option in Pocket Sync to handle when a core’s files move around).

All seems fine, I’ll get something added to Pocket Sync to tell users their beta.bin doesn’t match next time I’m working on it

[jotego]

Thanks all for your help. It was a bit messed up yesterday due to RBF files getting deleted (probably in a git merge step) but we got through it :-)