nescartdb submission system expectations
Moderator: Moderators
nescartdb submission system expectations
Since brizzo had to rebuild the current nescartdb.com from scratch and we don't have access to any of the original code, the site has unfortunately been read-only with no submission system of any sort. It would be helpful to know what people's needs and expectations are of a new submission system for the site before he goes about building one. Is it as simple as a way to upload some photos and data for each of the available fields? Do we need a way of editing existing entries? Are there other new fields we'd want to add that we don't have today? User accounts may also be a necessity, and/or perhaps a queue that staff members can review and approve.
Personally, I'm interested in support for non-standard cartridges, such as FamicomBox, the various modem systems, games with expansion carts, and perhaps also unlicensed carts. Potentially also a way to have schematics for board types. One frustration I have with the existing system is that it doesn't feel like there's always much reason for there to be multiple entries for a single cartridge, with multiple entries being essentially duplicates, so I'm interested in something that can combat that, like an approval system or maybe going with a more collaborative system with entry editing.
Any feedback people can provide would be helpful, and would also help show how much interest there actually is here. There's a lot still missing from the database and I'm hoping people are still interested in building this out further.
Personally, I'm interested in support for non-standard cartridges, such as FamicomBox, the various modem systems, games with expansion carts, and perhaps also unlicensed carts. Potentially also a way to have schematics for board types. One frustration I have with the existing system is that it doesn't feel like there's always much reason for there to be multiple entries for a single cartridge, with multiple entries being essentially duplicates, so I'm interested in something that can combat that, like an approval system or maybe going with a more collaborative system with entry editing.
Any feedback people can provide would be helpful, and would also help show how much interest there actually is here. There's a lot still missing from the database and I'm hoping people are still interested in building this out further.
- Controllerhead
- Posts: 314
- Joined: Tue Nov 13, 2018 4:58 am
- Location: $4016
- Contact:
Re: nescartdb submission system expectations
Variations in RAM and ROM chips don't warrant separate profiles imo, but variations in boards for a single cart and even variations in mapper chip (e.g. MMC1A vs MMC1B2 etc.) are still interesting. Sometimes a cart generally uses blobs but there's also an earlier variation that uses dips and discrete components instead. That's interesting. If new variations surface for old games it would be nice to be able to add that info.
For example, I have a version of Top Gun that uses the Konami NROM board (the same one used for Metal Gear, Life Force, etc). That variation isn't represented on nescartdb for Top Gun. I think it would be worth adding.
I would be interested in seeing new homebrew releases on nescartdb as well. Schematics would be cool but might be better housed on the nesdev wiki. Unlicensed carts could get out of hand quickly but they too would be interesting.
A simple form with a bunch of fields and image upload would be enough. Some clear guidelines on what's acceptable and what's not would also be useful. Not sure user accounts would be needed but the submissions would at least need to be moderated. There could always be a field for submitter if people are interested in getting credit for uploading rarities.
Anyway, cool to see that this might be getting new life.
For example, I have a version of Top Gun that uses the Konami NROM board (the same one used for Metal Gear, Life Force, etc). That variation isn't represented on nescartdb for Top Gun. I think it would be worth adding.
I would be interested in seeing new homebrew releases on nescartdb as well. Schematics would be cool but might be better housed on the nesdev wiki. Unlicensed carts could get out of hand quickly but they too would be interesting.
A simple form with a bunch of fields and image upload would be enough. Some clear guidelines on what's acceptable and what's not would also be useful. Not sure user accounts would be needed but the submissions would at least need to be moderated. There could always be a field for submitter if people are interested in getting credit for uploading rarities.
Anyway, cool to see that this might be getting new life.
- krzysiobal
- Posts: 1037
- Joined: Sun Jun 12, 2011 12:06 pm
- Location: Poland
- Contact:
Re: nescartdb submission system expectations
I thought of leaving the nescartdb.com in current state as the site for mainly official cartridges.
That's why I did similar website for famiclone carts or "fresh new" nes/fc carts:
http://krzysiobal.com/carts
If we need some kind of form for uploading photos of new carts to database, I can add this.
By the way, my observation after analyzing hundreds of cartridgs is that while there are not may variants of original NES/FC PCB variants and they are named, the situation for famiclone cartridges is really messy.
The same cartridge can exists in many different pcb revisions, even those discrete versions, like punch out (mmc2) which required some kind of effort to engineer:
http://krzysiobal.com/carts/?action=sea ... t=name_asc
has two different boards which suggests either they were designed by different producers (probably one based on another) or for some reason, one was later revision of the the other one.
Not counting some multicarts like 42 (22+20 in 1) or 76 in 1 which exist in many revisions, differing even in the chip orientation.
That's why I did similar website for famiclone carts or "fresh new" nes/fc carts:
http://krzysiobal.com/carts
If we need some kind of form for uploading photos of new carts to database, I can add this.
By the way, my observation after analyzing hundreds of cartridgs is that while there are not may variants of original NES/FC PCB variants and they are named, the situation for famiclone cartridges is really messy.
The same cartridge can exists in many different pcb revisions, even those discrete versions, like punch out (mmc2) which required some kind of effort to engineer:
http://krzysiobal.com/carts/?action=sea ... t=name_asc
has two different boards which suggests either they were designed by different producers (probably one based on another) or for some reason, one was later revision of the the other one.
Not counting some multicarts like 42 (22+20 in 1) or 76 in 1 which exist in many revisions, differing even in the chip orientation.
My website: http://krzysiobal.com | My NES/FC flashcart: http://krzysiocart.com
Re: nescartdb submission system expectations
gzip: I really appreciate the input! That's all good info. It sounds like it's totally fine to keep it simple, then, and we definitely need to prioritize providing clear guidance on what to submit.
krzysiobal: I'm sitting on a bunch of official cartridges, both my own and from other collectors, that I've been eager to submit to nescartdb for years now. There are tons and tons of official cartridges still not documented and we need a way to do so. Starting from scratch on a new database is not a very appealing option to me because the existing one has so much information in it (2447 entries), so we'd be duplicating a lot of work trying to get a new database to be a comprehensive resource. I think there's a lot of value in having one comprehensive resource, at least for certain categories of games. Licensed vs unlicensed feels to me like it could be a reasonable split to make, for example. Maybe a new database is the right solution, I don't know, but it feels like a ton more work than just adding a submission system to our existing community resource.
In addition to helping set the requirements of what would be built out for nescartdb, this request for feedback is also gauging how much interest there is in this work, as there need to be people interested in actually submitting entries for it to be worthwhile building that functionality. So far, there hasn't been much feedback here nor on Discord, which is disappointing. That said, with an easy to use submission system, I don't know if we'd be expecting a few users to be adding a ton of carts, or lots of users each adding a few, or what. Most (2/3) of the existing entries were submitted by bootgod himself.
krzysiobal: I'm sitting on a bunch of official cartridges, both my own and from other collectors, that I've been eager to submit to nescartdb for years now. There are tons and tons of official cartridges still not documented and we need a way to do so. Starting from scratch on a new database is not a very appealing option to me because the existing one has so much information in it (2447 entries), so we'd be duplicating a lot of work trying to get a new database to be a comprehensive resource. I think there's a lot of value in having one comprehensive resource, at least for certain categories of games. Licensed vs unlicensed feels to me like it could be a reasonable split to make, for example. Maybe a new database is the right solution, I don't know, but it feels like a ton more work than just adding a submission system to our existing community resource.
In addition to helping set the requirements of what would be built out for nescartdb, this request for feedback is also gauging how much interest there is in this work, as there need to be people interested in actually submitting entries for it to be worthwhile building that functionality. So far, there hasn't been much feedback here nor on Discord, which is disappointing. That said, with an easy to use submission system, I don't know if we'd be expecting a few users to be adding a ton of carts, or lots of users each adding a few, or what. Most (2/3) of the existing entries were submitted by bootgod himself.
-
- Posts: 1
- Joined: Thu Jul 20, 2023 9:18 pm
Re: nescartdb submission system expectations
I really hope NESdb.com gets back to what it used to be and adds more official cassette material.
Such a good museum should also have a reason to improve and exist.
Such a good museum should also have a reason to improve and exist.
Re: nescartdb submission system expectations
Is there any plans to re-introduce submissions of games into the NesCartDB database? At the time of this writing, there are 1,031 missing games.
Re: nescartdb submission system expectations
I have no further commentary on the subject but...
Sometime in the past few years, one of the many internal Nintendo things that popped up was some sort of lot check on NES/Famicom titles. I never looked much into it myself, but I've had to wonder what sort of chilling effect that just...*existing* has had on databasing efforts. Don't want to have your database explode in accuracy over night when something like that drops, might look suspicious. Just reading the leaves though, dunno what the situation actually is.
Sometime in the past few years, one of the many internal Nintendo things that popped up was some sort of lot check on NES/Famicom titles. I never looked much into it myself, but I've had to wonder what sort of chilling effect that just...*existing* has had on databasing efforts. Don't want to have your database explode in accuracy over night when something like that drops, might look suspicious. Just reading the leaves though, dunno what the situation actually is.
Re: nescartdb submission system expectations
maybe a public website that not just belonging to one certern person shall be more realiable
like this:
https://nesdir.github.io/
also include the pirate multicart roms
and u can easily search by specific keywords such as:
https://nesdir.github.io/mapper2.html
like this:
https://nesdir.github.io/
also include the pirate multicart roms
and u can easily search by specific keywords such as:
https://nesdir.github.io/mapper2.html
Re: nescartdb submission system expectations
If people are interested in a submission system being built for the new site, then please provide the feedback requested at the start of this thread. I've been fishing for feedback for around a year both here and on Discord and gzip is the only person who's had more than a couple sentences to say. If brizzo knows what people need him to build, he's more likely to build it; he's been requesting a spec for a very long time now.
Re: nescartdb submission system expectations
Is it just that something needs to be built? Or that an existing thing needs to be brought back from the brink of death?
If you're looking for a web submission system, it'd probably be trivial to design an API to do this. I could see tables for:
- DescType - Optional concept, ties in with a field in below tables
- ID - Primary key
- Desc - Description of the type
- Country/Region
- ID - Primary key
- LegalName - Formal name of the country in international matters
- CountryName
- CountryID - The country being described
- CountryNameID - Primary key or part of composite key with country ID to uniquely identify a specific name for a country
- DescTypeID - Could be used with types of "stock index <xyz> name, short name, local name"
- Locale - The locale of the name. Only needed for translations.
- Company
- ID - Primary key
- LegalName - The most correct legal name as the business is registered. This is what you'd find them under in legal books in native language.
- FoundingDate - When the company was founded. Not required, but nice to have
- Country - Legal country where the company is incorporated/situated
- CompanyName
- CompanyID - The ID this name is for
- CompanyNameID - Either primary key or part of a composite key with CompanyID to reflect a unique name for a company
- DescTypeID - What type this is, could utilize desc types of "Abbreviation, DBA name, foreign market name, etc."
- Locale - The locale of the name.
- Person
- ID - Primary key
- Legal Name - The most correct legal name for the person. This would be in their native language.
- DOB - Optional, might be interesting to folks
- Nationality - May not be exact, but something like is this person Japanese, British, Russian, etc.
- PersonName - Like company name but for name translations, nicknames, etc. of a given person, similarly would have types like "nickname, maiden name" and a locale so someone's name could be represented in multiple languages
- Platform - This would list a platform (i.e. Famicom, NES, FDS, VS., PlayChoice, etc.)
- ID - Primary key
- Desc - A human-readable description, mainly for folks reading in the database
- PlatformRelease - This would be a platform's release properties in a given market, such as the release date, the name of that platform in that market, which company was technically the vendor for that platform/country combination, etc.
- Title - In this case, a title is a singular released game, distinct from bundles and such. For instance different revisions of Super Mario Bros. would count as a single title, but SMB/Duck hunt would be a separate title.
- ID - Primary key
- Desc - This would be some sort of readable description mainly for DB maintainers
- TitlePublisher - Relational table relating a Title entry to a Company entry on the basis of which company(s) were involved in publishing.
- TitleDeveloper - Similar, points to the studio(s) responsible for development of the title.
- TitleName - Like the above name fields, would provide a many-to-one mapping of names to titles, allowing for perhaps alternate names, name translations, etc.
Edit:
- TitlePerson - A person involved with the title
- PersonID - Pointer over to the table of people
- TitleID - What title this record is providing a relation for
- Role - Some description of the person's role in the title (programmer, producer, art design, etc, this could come from a "Roles" table with a further "RoleName" table for translations)
Endedit:
- TitleRelease - This could then be an individual release of a given title, representing that specific issue
- TitleID - The title this is a release of
- CountryID - The country this release was issued in
- Date - The date this release was issued
- DistributorID - Not entirely sure on this one, might make sense to have a distinct field for a specimen such that if a particular hack or pirate copy can be authoritatively traced to a particular shop or collective, that information could likewise be provided here (distinct from, say, Nintendo being the distributor of the cartridges from their factories)
- ArtType - A table detailing different art types, such as cover art, cartridge art, PCB scans, etc.
- ArtAsset - A table of arbitrary art assets that can be shared by multiple objects
- TitleReleaseArt - This would then be a table for providing many-to-one mapping of art to a specific release. This would just be a relational mapping as the art lives in the ArtAsset table (to prevent duplication)
Is this the kind of thing you're looking for? If this is needed I'm happy to contribute a SQL schema and basic CRUD web API if it means this project will succeed. With a good object model it shouldn't be hard to CRUD it all up with something like Entity Framework or Sequelize or something depending on what ecosystem you want this thing to be in. Then you can slap whatever interface you want on top of the thing, shouldn't matter if it's good REST stuff.
If you're looking for a web submission system, it'd probably be trivial to design an API to do this. I could see tables for:
- DescType - Optional concept, ties in with a field in below tables
- ID - Primary key
- Desc - Description of the type
- Country/Region
- ID - Primary key
- LegalName - Formal name of the country in international matters
- CountryName
- CountryID - The country being described
- CountryNameID - Primary key or part of composite key with country ID to uniquely identify a specific name for a country
- DescTypeID - Could be used with types of "stock index <xyz> name, short name, local name"
- Locale - The locale of the name. Only needed for translations.
- Company
- ID - Primary key
- LegalName - The most correct legal name as the business is registered. This is what you'd find them under in legal books in native language.
- FoundingDate - When the company was founded. Not required, but nice to have
- Country - Legal country where the company is incorporated/situated
- CompanyName
- CompanyID - The ID this name is for
- CompanyNameID - Either primary key or part of a composite key with CompanyID to reflect a unique name for a company
- DescTypeID - What type this is, could utilize desc types of "Abbreviation, DBA name, foreign market name, etc."
- Locale - The locale of the name.
- Person
- ID - Primary key
- Legal Name - The most correct legal name for the person. This would be in their native language.
- DOB - Optional, might be interesting to folks
- Nationality - May not be exact, but something like is this person Japanese, British, Russian, etc.
- PersonName - Like company name but for name translations, nicknames, etc. of a given person, similarly would have types like "nickname, maiden name" and a locale so someone's name could be represented in multiple languages
- Platform - This would list a platform (i.e. Famicom, NES, FDS, VS., PlayChoice, etc.)
- ID - Primary key
- Desc - A human-readable description, mainly for folks reading in the database
- PlatformRelease - This would be a platform's release properties in a given market, such as the release date, the name of that platform in that market, which company was technically the vendor for that platform/country combination, etc.
- Title - In this case, a title is a singular released game, distinct from bundles and such. For instance different revisions of Super Mario Bros. would count as a single title, but SMB/Duck hunt would be a separate title.
- ID - Primary key
- Desc - This would be some sort of readable description mainly for DB maintainers
- TitlePublisher - Relational table relating a Title entry to a Company entry on the basis of which company(s) were involved in publishing.
- TitleDeveloper - Similar, points to the studio(s) responsible for development of the title.
- TitleName - Like the above name fields, would provide a many-to-one mapping of names to titles, allowing for perhaps alternate names, name translations, etc.
Edit:
- TitlePerson - A person involved with the title
- PersonID - Pointer over to the table of people
- TitleID - What title this record is providing a relation for
- Role - Some description of the person's role in the title (programmer, producer, art design, etc, this could come from a "Roles" table with a further "RoleName" table for translations)
Endedit:
- TitleRelease - This could then be an individual release of a given title, representing that specific issue
- TitleID - The title this is a release of
- CountryID - The country this release was issued in
- Date - The date this release was issued
- DistributorID - Not entirely sure on this one, might make sense to have a distinct field for a specimen such that if a particular hack or pirate copy can be authoritatively traced to a particular shop or collective, that information could likewise be provided here (distinct from, say, Nintendo being the distributor of the cartridges from their factories)
- ArtType - A table detailing different art types, such as cover art, cartridge art, PCB scans, etc.
- ArtAsset - A table of arbitrary art assets that can be shared by multiple objects
- TitleReleaseArt - This would then be a table for providing many-to-one mapping of art to a specific release. This would just be a relational mapping as the art lives in the ArtAsset table (to prevent duplication)
Is this the kind of thing you're looking for? If this is needed I'm happy to contribute a SQL schema and basic CRUD web API if it means this project will succeed. With a good object model it shouldn't be hard to CRUD it all up with something like Entity Framework or Sequelize or something depending on what ecosystem you want this thing to be in. Then you can slap whatever interface you want on top of the thing, shouldn't matter if it's good REST stuff.
Re: nescartdb submission system expectations
I'm working on a static nestCartDB website as an excuse to learn how to use the Statiq static website generator tool.
The way it works is that all a profile's data is kept in a yaml file and the yaml file is used to generate the profile html page. So, adding new profiles would simply be a matter of adding new yaml files to source control (and putting any relevant images in the same folder).
The idea is that the source could be put in a GitHub repo and we could use GitHub Actions to produce the static website files.
I suspect the generated website would be too large to host with GitHub Pages, but I hear there are free hosting services available for static websites.
Is this something people would be interested in contributing to?
The way it works is that all a profile's data is kept in a yaml file and the yaml file is used to generate the profile html page. So, adding new profiles would simply be a matter of adding new yaml files to source control (and putting any relevant images in the same folder).
The idea is that the source could be put in a GitHub repo and we could use GitHub Actions to produce the static website files.
I suspect the generated website would be too large to host with GitHub Pages, but I hear there are free hosting services available for static websites.
Is this something people would be interested in contributing to?
Re: nescartdb submission system expectations
So what you're suggesting is generated offline from files and then hosted as flat HTML without JavaScript/database lookups? Could be interesting, probably more accessible to beginners since you just write up a YAML for an entry and commit it. Interesting use of Git systems for that sort of thing. That's the polar opposite of what I was expressing interest in (something SQL driven with an API) so don't have a lot of thoughts, but I support creative solutions, even if they aren't in my wheelhouse!
Re: nescartdb submission system expectations
Static doesn't mean no JS.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: nescartdb submission system expectations
Here's a work-in-progress deployment for the interested: https://nestcartdb-mirror.netlify.app
A profile yaml file currently looks like this (but it will change slightly):
A profile yaml file currently looks like this (but it will change slightly):
Code: Select all
metadata:
name: Disney's DuckTales
altName:
variant:
submittedBy: Kinopio
submittedOn: 2008-01-27 05:51:00
moreProfiles:
- 2427
- 2428
- 2429
- 4106
relatedProfiles:
- 1985
- 4480
- 3780
- 2559
- 38
additionalImages:
- toolTipJS: "ddrivetip('Box Front<br>NES-UK-EEC<br>Submitted by: Kinopio<br>Linked from profile 0')"
filename: /images/175/baa5015b242d948d18dd9343337d9850.jpg
- toolTipJS: "ddrivetip('Box Back<br>NES-UK-EEC<br>Submitted by: Kinopio<br>Linked from profile 0')"
filename: /images/175/b23a435dd87e2982443b7846b30176f4.jpg
slug: disneys-ducktales
releaseInfo:
catalogId: NES-UK-EEC
region: Europe (PAL-B)
class: Licensed
releaseDate: December 14, 1990
publisher: Capcom
developer: Capcom
players: 1
peripherals: NES Controller
country: Europe
cartProperties:
cartProducer: Nintendo (NES)
color: Grey
formFactor: 3-Screw
embossedText: Nintendo® Pat. Pend. Made in Japan
frontLabelId: NES-UK-EEC
sealOfQuality: 'PAL: Round (Original)'
mfgstringPresent: Yes
backLabelId/Desc: SCN
2-DigitCode: 11
topImage:
toolTipJS: "ddrivetip('Cart Top<br><br>Submitted by: Kinopio<br>Linked from profile 0')"
filename: /images/175/1dba2bd1bcf6021a045c8eaa99108a17.jpg
frontImage:
toolTipJS: "ddrivetip('Cart Front<br>Submitted by: Kinopio<br>Linked from profile 0')"
filename: /images/175/411a6c96acdaf8a1478919974f08e59c.jpg
backImage:
toolTipJS: "ddrivetip('Cart Front<br>Submitted by: Kinopio<br>Linked from profile 2497')"
filename: /images/175/fbb6df3fc252ad747f3da83b9ac44a9c.jpg
romDetails:
- type: PRG0
label: PAL-UK-0 PRG
size: 128 KB
crc32: D029F841
x: 8
pcbProperties:
name: NES-UNROM-09
frontImage:
toolTipJS:
filename:
backImage:
toolTipJS:
filename:
pcbProducer: Nintendo
manufacturer: Not Specified
mfgRange: 9039 - 9109 (4)
estFirstRun: September 1990
pcbClass: NES-UNROM
inesMapper: 2
mirroring: Vertical
batteryPresent: No
wram: 0 KB
vram: 8 KB
cicType: 3195A
hardware: 74xx161, 74xx32
detailedChipInfo:
- designation: U1 PRG
maker: Sharp
partNumber: LH2306
partNumberSubDetail: 69
type: Mask ROM
typeSubDetail: 128 KB
package: DIP-28
dateCodePrefix: 9043
dateCodeSuffix: E
std: 9043
misc:
- designation: U2 CHR RAM
maker: Sharp
partNumber: LH5160YF-10L
partNumberSubDetail:
type: SRAM
typeSubDetail: 8 KB
package: DIP-28
dateCodePrefix: 036
dateCodeSuffix: B
std: 9036
misc:
- designation: U3 CIC
maker: Sharp
partNumber: 3195A
partNumberSubDetail:
type: Nintendo CIC
typeSubDetail:
package: DIP-16
dateCodePrefix: 9044
dateCodeSuffix: A
std: 9044
misc:
- designation: U4 HC161
maker: Texas Instruments
partNumber: SN74HC161N
partNumberSubDetail:
type: 74-161 Series
typeSubDetail:
package: DIP-16
dateCodePrefix: 035
dateCodeSuffix: EN
std: 9035
misc:
- designation: U5 HC32
maker: GoldStar
partNumber: GD74HC32
partNumberSubDetail:
type: 74-32 Series
typeSubDetail:
package: DIP-14
dateCodePrefix: 9010
dateCodeSuffix: ''
std: 9010
misc: