NES 2.0 expansion for maskROM data
Moderator: Moderators
NES 2.0 expansion for maskROM data
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'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.
Re: NES 2.0 expansion for maskROM data
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.
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.
Re: NES 2.0 expansion for maskROM data
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.
Re: NES 2.0 expansion for maskROM data
Does "sample player cart" also include that DDR clone?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES 2.0 expansion for maskROM data
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.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.
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.
Re: NES 2.0 expansion for maskROM data
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.
I don't think it's a clever idea to append a chunked format to the existing iNES format.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: NES 2.0 expansion for maskROM data
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.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.
Re: NES 2.0 expansion for maskROM data
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...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.
Re: NES 2.0 expansion for maskROM data
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).
Re: NES 2.0 expansion for maskROM data
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.
Doesn't need to be the same lookup table as the RAM size ones.
Re: NES 2.0 expansion for maskROM data
Well, I guess so, but what if someone wanted to make homebrew or use a flash cart?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.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: NES 2.0 expansion for maskROM data
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.
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.
Re: NES 2.0 expansion for maskROM data
Good luck playing the Sunsoft bass and the vocals at once.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
Re: NES 2.0 expansion for maskROM data
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.B00daW wrote:Well, I guess so, but what if someone wanted to make homebrew or use a flash cart?
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.tepples wrote:Good luck playing the Sunsoft bass and the vocals at once.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES 2.0 expansion for maskROM data
I wasn't trying to do something "clever", I was trying to suggest something "extensible".lidnariq wrote:I don't think it's a clever idea to append a chunked format to the existing iNES format.
...except with an easily extensible format? It's incredibly possible with chunks.lidnariq wrote:It's impossible to support every single possible way someone could inject audio data...
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:We probably should limit it to the actual set of hardware used by games before the homebrew era.
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.lidnariq wrote:And I'd definitely object to "someone put an MP3 player in a NES cartridge, let's embed MP3s into .NES files"
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!lidnariq wrote:I mean, UNIF, MAME/MESS format, and byuu's thing are over there. I see no need to recapitulate that argument.
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.