joshcampbell191 / openfpga-cores-inventory

openFPGA Cores Inventory

Hi there 👋

openfpga-cores-inventory's Issues

Core Version Number

Would it be possible to add the Core Version Numbers into the API? I want to build some auto notifications into Discord for when a new Core drops or gets updated.

Add a JSON API for developers

Since this website is already the de facto place to to view the list of available cores for Analogue Pocket, why not also add a JSON API for the different application developers in the community?

The Problem

There are at least three tools currently for updating and managing the cores on the Pocket:

• update-pocket
• pocket_core_autoupdate_net
• Pocket_Updater

Both update-pocket and pocket_core_autoupdate_net maintain their own internal list of cores, and Pocket_Updater uses the list from pocket_core_autoupdate_net. This means that every time a new core is created, update-pocket, pocket_core_autoupdate_net, and this project all need to be separately updated. This is not only inefficient, but it also makes these tools less reliable because the developer may not have seen a newly released core, and thus the tool will not have it available to the end user.

The Solution

Add a JSON endpoint to openfpga-cores-inventory website that all developers can reference as the place for the most up-to-date list of cores. The only place where a new core would have to be added is this repo. This is also nice for members of the community who don't use an updater tool and prefer to do it manually, as this will be the only place anyone goes to add new cores.

The Implementation

This new API would live at /openfpga-cores-inventory/api/v0/repos.json (or somewhere else if we decide on a better location). I am thinking that the list of cores will be maintained in a YAML file that can then be referenced in both the markdown file already on the site, and in the JSON files for building out the full JSON response. This way, only a single file will have to be updated to both add to the inventory table on the website and to the API.

First Steps

In order for this to be successful, we'll want some input from the developers of the current tools on the structure for the API. Since it is possible to version the API (i.e. v0), this can always be changed in the future (while maintaining backwards compatibility), but it would be good to get it as right as we can at the start.

I already have a local branch for adding all this, so once the details are worked out, I am more than happy to run with this myself.

mark cores that aren't available via the api

color code or add a column or something to mark the cores from the "other" list, to make it more obvious why some cores don't get installed via updaters. (basically, jotegos cores)

Move repo to GitHub organization

A Reddit comment suggested that we create a GitHub organization and move the repo there. This would give us a better URL to serve up the JSON at https://openfpga-cores-inventory.github.io/.

Jotego's public cores

Hey there. Jotego has released over a dozen public cores on his Github here https://github.com/jotego/jtbin/tree/master/pocket

Include a donation link for the developer of each core in the api

This way the updaters can quickly/simply throw up a link to help get support for developers

Include the core's self reported version number (from `core.json` -> `core.metadata.version`) somewhere

• in Pocket Sync I'm doing some nasty heuristic stuff to check ( release | prerelease ).tag_name vs what the core self-reports in its core.json file which is fine for most cores...
• Except
  • NeoGeo & PDP-1 don't have tags that match their version (NeoGeo's close & I could probably get it by widening up my heuristic)
  • GameGear misreports it's internal version number so always looks like it has an update (this is something Spiritualized will need to fix, there's a github issue for it)
  • Any non-github-releases cores might not fit well with the tag_name paradigm

Ideally there's a root level version param just re-reporting whatever the core says in it's core.json file

---

Also, let me know if there's any funding links etc you guys have got & I'll get them into the launch page of Pocket Sync beside the Thank You since it's this project that'll be keeping it up to date

Include not-required assets from data.json

I think it would be useful to include all of the assets in the data.json file for each core, instead of just the ones flagged as required. instead just include that required flag in the api response, for updaters to handle however they want.
this came up because the super gameboy core has both bios files in data.json not listed as required, but..they kind of are.

      {
        "name": "SGB BIOS SNES",
        "id": "0x103",
        "required": false,
        "filename": "sgb_snes.smc",
        "parameters": "0x2",
        "extensions": [
          "smc"
        ],
        "size_exact": null,
       "size_maximum": 522488,
        "address": "0x00000000"
      },
      {
        "name": "SGB BIOS GB",
        "id": "0x104",
        "required": false,
        "filename": "sgb_boot.bin",
        "parameters": "0x2",
        "extensions": [
          "bin"
        ],
        "size_exact": 256,
        "address": "0x60000f00"
      }

JT cores missing

Ordered as below

1. Name
2. Platform
3. Author
4. Version
5. Date

Ghosts'n Goblins

1. jtgng
2. Ghosts'n Goblins
3. Jotego
4. no version
5. October 4th, 2022

Pang!

1. jtpang
2. Pang!
3. Jotego
4. no version
5. October 14th, 2022

Both cores listed as early access with public access information still to come. Cores are both on Jotego's Patreon

API should not serve up ROM and BIOS links

As discussed in #6, it's probably a good idea to remove the direct links to ROM and BIOS files, as this is a legal gray area. However, I do think that it is valuable for the API to let developers know when a core requires a BIOS file to be added before it's functional.

With this in mind, I propose this:

• Remove links to all ROM files
• Keep file_name

This would make the JSON structure look something like this:

"assets":  {
  "location": "Assets/gba/common/",
  "files": [
    { "file_name": "gba_bios.bin" }
  ]
}

I can see this being useful in an updater app. If a file_name is provided, then they can prompt the user to provide the file, or the updater can provide it.

snow bros 2 is out.

arcade game.

https://github.com/psomashekar/pram0d-pocket-dist-public

pram0d's new cores are available

3 new cores are now listed at https://github.com/psomashekar/pram0d-pocket-dist-public

Add the ability to developers to exclude a core from the API

On a couple occasions, @ericlewis has requested for @mattpannella's updater not pull in one of his cores. We should allow developers a way to signal to the API not to serve up a certain repository if they don't feel the core is ready for the limelight. One way to do this would be to check for a certain semver label on the Git tag. For example 0.1.0-noupdate, or something like that.

`Mazamars312.amiga` casing

Hey,

looks like this is Mazamars312.Amiga once it's installed

The platform name is a lowercase amiga on the Pocket, which confuses things, but the platform for NeoGeo is ng on the Pocket and it has a "identifier": "Mazamars312.NeoGeo",

(had a look at doing a PR but I'm only seeing it specified in the auto-generated file so I'm not sure where it's coming from)

Feature Request: some sort of "news" section in the JSON response (or via another API)

This'll be quite a vague feature request since I don't have an exact use for it, but adding an (autogenerated) section like:

{
  "news": [
    { 
      "title": "agg23's SNES core updated to 0.4.2",
      "core_identifier": "agg23.snes",
      "news_type": "update",
      "date": "2022-12-11T01:28:02Z"
    },
   {
     "title": "New jtgng core from JOTEGO",
     "core_identifier": "jotego.jtgng",
     "news_type": "new_core",
     "date": "2022-12-9T01:28:02Z"
   }
  ]
}

In Pocket Sync I'd check for news stories since the last time the user used the app & present them, & now @mattpannella's CLI updater has a splash screen the same could happen there.

Could also be supplementary to the JSON, would make sense as an RSS feed (if those were a thing anymore).

Eventually, if I add (optional) notifications to Pocket Sync I could use it to pop up notifications for new cores / updates etc

On supporting non-github release('d) cores

As per the Snow Bros 2 core & following on from the chat in the discord.

(I'll just talk about the output JSON in this rather than the input yml)

I think what could work is something along the lines of (forgive the typescript notation):

type CoreRepo = {
  platform: "github",
  owner: string,
  repo: string
} | {
  platform: "github-within-tree",
  owner: string,
  repo: string,
  path: string, // "releases" for the snowbros 2 core
  filename: string // "pram0d.snowbros2_*" for the snowbros 2 core
} | {
  platform: "bitbucket", // just shoving this in here as another example
  owner: string,
  repo: string
}

Then in updaters they'll do their current behaviour for platform: "github", and switch to a new download method for "github-within-tree" (which is a rubbish name, there'll be a better one...)

The "new method" (for whatever better name github-within-tree ends up getting) would compose the API call for https://api.github.com/repos/psomashekar/pram0d-pocket-dist-public/contents/releases then find the most recent file which matches the filename glob & download it (which isn't actually as different from using the releases API as I thought it would be...)

There's a couple of terminology things that might change since release.tag_name doesn't apply since it's not tagged & repository itself might make more sense as download but that's small fry stuff.