nesdev.com

So according to NESdev wiki, NES 2.0 currently only has two unused bytes left for header space. We're going to probably need a byte of that for maskROM data pointer/sizing.

I'm sending the Famicom cart (Family Trainer 3: Aerobics Studio) to a MESS developer to get the maskROM PARCOR-encoded data dumped.

To be conservative with these two bytes, I'm suggesting that Byte 14 be the amount of "X data size" banks of maskROM data is after CHR data. Before we "jump the gun" I'm going to see how big the maskROM dump is before we decide the bank size value. The next step after dumping Family Trainer 3's maskROM data is to move onto the Jaleco carts to dump those.

The MESS code library has the emulation available for the Jaleco carts' µPD7756C variant. We'll have to do some RE and research to get the Family Trainer 3 M50805 PARCOR decoder emulated.

I don't think this will ever matter, because none of the existing PC-10 games has an audio ROM, but Nocash has pointed out that for a PC-10 game, the INST-ROM should also be appended after the CHR data.

Even though no PC-10 board had cart audio, there apparently is a pin for cart audio on the connector ... so we should pick a canonical ordering for whether the INST-ROM or audio ROM is serialized first. Arbitrarily, I'd say to start with the INST-ROM.

I'd say wait until all the known sample player carts are dumped, so at least we know what the relevant size ranges will be.

Does "sample player cart" also include that DDR clone?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

If you really want an extensible format, the RIFF chunk idea works really well, IMHO. This concept was also used by Disch's NSFe format.

Basically every thing you append is a "chunk" with some sort of identifier (e.g. FOURCC) and a size field, followed by the specified number of bytes. Order of chunks doesn't need to matter, and chunks of an unknown type can be skipped by the emulator, so you can add new chunk types without any need to update the base format or worry about breaking backward compatibility.

With chunks people could also embed other metadata (e.g. what controllers does this game expect, what's the board name, etc.) without really having to have an argument about whether it needs to take up precious space in the header.

I mean, UNIF, MAME/MESS format, and byuu's thing are over there. I see no need to recapitulate that argument.

I don't think it's a clever idea to append a chunked format to the existing iNES format.

Don't we already know this? In terms of internal ROM, I have read that the D7756 has 256kbit/32kbyte, the D7755 has 96kbit/12kbyte, and the M50805 has 960 bytes.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog

Well, I guess we could just pad (or not pad) the 960B M50805 maskROM data to 1K; and then use 1K (512B or 256B) as the bank multiplier...

Are these ROMs separate chips mounted on the PCB or internal to the sound chip? If they're built into the chip, then the ROM size is implied by the type of chip (i.e. the mapper).

Or we could just use a nybble or byte to specify which specific IC is used, because it also needs to signal which encoding the data is in. Then the size is part of the same detail...

Doesn't need to be the same lookup table as the RAM size ones.

Well, I guess so, but what if someone wanted to make homebrew or use a flash cart?

It is a better idea to reserve a byte for the chip type because they most mappers with speech chips have games with and without the chip (except for 86).

As you know, for the NES they got around having to support speech chips by using larger PRG-ROM chips and DPCM. You could always hack these games instead to use this method to play the sounds (after recording them and converting them)

I think it is unlikely that someone would use a speech chip in a homebrew, but if they did we would probably have to assign an iNES 2.0 mapper to it. We have plenty.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog

Good luck playing the Sunsoft bass and the vocals at once.

It's impossible to support every single possible way someone could inject audio data... we probably should limit it to the actual set of hardware used by games before the homebrew era.

To the best of my knowledge, the only parts used were the M50805, µPD7755, and µPD7756. These would correspond to 960B, 12KiB, and 32KiB.

Even a nybble is enough overallocation that we probably don't need to worry about future expansion.

I could possibly see an argument for explicitly supporting the other (larger) µPD775X parts, but I'd ... probably rather wait for a found instance.

And I'd definitely object to "someone put an MP3 player in a NES cartridge, let's embed MP3s into .NES files"

Good luck getting presentable vocals playing in 8kHz ADPCM... telephone quality is a flattering way to put it.

I wasn't trying to do something "clever", I was trying to suggest something "extensible".


...except with an easily extensible format? It's incredibly possible with chunks.


Why? There's plenty of desire to run homebrew. There's already homebrew that just barely exceeds iNES 2 PRG size constraints that I think might be valuable enough to run in an emulator.


I certainly don't think such a thing would warrant reservation of the 16 precious remaining bits of the header, but with an extensible format with optional inclusions it wouldn't be any kind of burden on any emulator author to simply not-support and ignore it entirely.

Similarly, if you don't want a ROM with MP3s in it, that's no problem for you... you don't have to download that ROM! Someone else would probably care about it though!

An extensible format means it's possible for people to add new bits of data they have a use for without having to play some political game of deciding whether it's important to be part of the format or not. Anybody that thinks it's important can pick it up and add it, anyone that doesn't can ignore it without changing a single line of code in their emulator.


All of those format arguments indicate a large desire to include other information in the file that maybe you think isn't important, but other people do. The whole reason I suggested chunks was to avoid argument and arbitration about what can go in the file-- it makes it very easy to ignore anything you don't care about!

It even makes it easy to write a tool that can just strip out metadata types that you don't like from your ROM collection.


Anyhow, the reason I suggested it is that it's very easy to implement, simple, practical solution to a general problem that seems to continually arise. This thread is maybe narrowly about one specific case of that problem, but I'm certain it will keep coming up. I don't really understand the downside to it (?), so it's a serious suggestion on my part.