nescartdb submission system expectations

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

nescartdb submission system expectations

Post by Fiskbit »

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.
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: nescartdb submission system expectations

Post by Controllerhead »

Bootgod wrote: Fri May 12, 2023 4:13 pm >> Someone make me a damn logo! :)
I made a damn logo =p

Image
Image
gzip
Posts: 23
Joined: Sat Mar 13, 2021 2:29 pm
Contact:

Re: nescartdb submission system expectations

Post by gzip »

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.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: nescartdb submission system expectations

Post by krzysiobal »

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.
Image My website: http://krzysiobal.com | Image My NES/FC flashcart: http://krzysiocart.com
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: nescartdb submission system expectations

Post by Fiskbit »

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.
fcxiaopengyou
Posts: 1
Joined: Thu Jul 20, 2023 9:18 pm

Re: nescartdb submission system expectations

Post by fcxiaopengyou »

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.
asm6hackr
Posts: 60
Joined: Fri Dec 29, 2023 4:03 pm

Re: nescartdb submission system expectations

Post by asm6hackr »

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.
User avatar
segaloco
Posts: 278
Joined: Fri Aug 25, 2023 11:56 am
Contact:

Re: nescartdb submission system expectations

Post by segaloco »

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.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: nescartdb submission system expectations

Post by aquasnake »

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
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: nescartdb submission system expectations

Post by Fiskbit »

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.
User avatar
segaloco
Posts: 278
Joined: Fri Aug 25, 2023 11:56 am
Contact:

Re: nescartdb submission system expectations

Post by segaloco »

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.
MetaFight
Posts: 2
Joined: Sat Feb 10, 2024 5:32 am

Re: nescartdb submission system expectations

Post by MetaFight »

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?
User avatar
segaloco
Posts: 278
Joined: Fri Aug 25, 2023 11:56 am
Contact:

Re: nescartdb submission system expectations

Post by segaloco »

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!
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: nescartdb submission system expectations

Post by Dwedit »

Static doesn't mean no JS.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
MetaFight
Posts: 2
Joined: Sat Feb 10, 2024 5:32 am

Re: nescartdb submission system expectations

Post by MetaFight »

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):

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: 
Post Reply