NES 2.0 expansion for maskROM data

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

NES 2.0 expansion for maskROM data

Post by B00daW »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 expansion for maskROM data

Post by lidnariq »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 expansion for maskROM data

Post by tepples »

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

Re: NES 2.0 expansion for maskROM data

Post by Dwedit »

Does "sample player cart" also include that DDR clone?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 expansion for maskROM data

Post by rainwarrior »

lidnariq wrote: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.
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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 expansion for maskROM data

Post by lidnariq »

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.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 expansion for maskROM data

Post by Great Hierophant »

tepples wrote: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.
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.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NES 2.0 expansion for maskROM data

Post by B00daW »

Great Hierophant wrote: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.
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...
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: NES 2.0 expansion for maskROM data

Post by AWJ »

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).
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 expansion for maskROM data

Post by lidnariq »

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.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NES 2.0 expansion for maskROM data

Post by B00daW »

lidnariq wrote: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?
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 expansion for maskROM data

Post by Great Hierophant »

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

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 expansion for maskROM data

Post by tepples »

Great Hierophant wrote: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
Good luck playing the Sunsoft bass and the vocals at once.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 expansion for maskROM data

Post by lidnariq »

B00daW wrote:Well, I guess so, but what if someone wanted to make homebrew or use a flash cart?
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"
tepples wrote:Good luck playing the Sunsoft bass and the vocals at once.
Good luck getting presentable vocals playing in 8kHz ADPCM... telephone quality is a flattering way to put it.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 expansion for maskROM data

Post by rainwarrior »

lidnariq wrote:I don't think it's a clever idea to append a chunked format to the existing iNES format.
I wasn't trying to do something "clever", I was trying to suggest something "extensible".
lidnariq wrote:It's impossible to support every single possible way someone could inject audio data...
...except with an easily extensible format? It's incredibly possible with chunks.
lidnariq wrote:We probably should limit it to the actual set of hardware used by games before the homebrew era.
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.
lidnariq wrote:And I'd definitely object to "someone put an MP3 player in a NES cartridge, let's embed MP3s into .NES files"
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.
lidnariq wrote:I mean, UNIF, MAME/MESS format, and byuu's thing are over there. I see no need to recapitulate that argument.
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.
Post Reply