joshcampbell191 / openfpga-cores-inventory Goto Github PK
View Code? Open in Web Editor NEWopenFPGA Cores Inventory
Home Page: https://joshcampbell191.github.io/openfpga-cores-inventory/
License: MIT License
openFPGA Cores Inventory
Home Page: https://joshcampbell191.github.io/openfpga-cores-inventory/
License: MIT License
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.
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?
There are at least three tools currently for updating and managing the cores on the Pocket:
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.
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.
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.
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.
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)
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/
.
Hey there. Jotego has released over a dozen public cores on his Github here https://github.com/jotego/jtbin/tree/master/pocket
This way the updaters can quickly/simply throw up a link to help get support for developers
( release | prerelease ).tag_name
vs what the core self-reports in its core.json
file which is fine for most cores...tag_name
paradigmIdeally 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
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"
}
Ordered as below
Ghosts'n Goblins
Pang!
Both cores listed as early access with public access information still to come. Cores are both on Jotego's Patreon
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:
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.
3 new cores are now listed at https://github.com/psomashekar/pram0d-pocket-dist-public
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.
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)
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.