NES 2.0 expansion for maskROM data

[Myask]

A bit for titlefield, a bit for audio-ROM chunk presence (size tbd by mapper) …

I'm not sure whether title-final or audio-final would be more backwards-compatible. depends how emulators read it (if any did).

[lidnariq]

I admit that I haven't previously heard of any emulators honoring the Title-final field before. I don't remember seeing it on the wiki, either. (I do remember having found a number of ROMs with an appended title, but those ones are also marked as "overdumps" by Cowering, so it's apparently not Well Known)

There are plenty of other homebrew things that people could invent that couldn't possibly fit in NES2.0 (For example, someone could put a compactflash card inside a cart, effectively an oversize FDS without expansion sound. We could make a "NES video format" cart, which would stream 8x1 pixel slivers to the PPU. Someone could put something like the 2600's Harmony Cart that would just directly feed data to the CPU and/or PPU as the data is fetched. An arbitrary number of different memory spaces could be added, and trying to graft support for this onto NES2.0 is going to be, at absolute best, super awkward.

Which is why I arbitrary said "let's only worry about pre-homebrew options". It makes the addressing the problem possible at all. We cannot possibly pre-invent everything that people are going to want to do, so what's wrong with admitting that some things are just out of scope? Or at least entertaining that being reactive, rather than proactive, is an acceptable way to manage this?

As such, I am most nearly happy with either
1- a single bit specifying that there's extra data, length and contents specified by submapper
2- a small number of bits (4?) specifying the strict lookup table of (none, 960, 12288, 32768, reserved, &c) for the number of bytes of extra data (nature of contents specified by mapper) such that programs can seek past it.
I would be unhappy with grafting a chunked format coda onto NES2.0, by whatever name.

I don't know how many emulators (other than NO$NES?) support the PC-10's INST-ROM anyway.

[B00daW]

I think I've found a pseudo-metadataless format of Byte 14 that is conservative enough to suit the needs of now and the future.

Byte 14 of NES2
------------------
bits 0-3: Which extended ROM types are being used? (Should there be more than 4 including SND, PC-10, Vs. System, and NOAC clones?)
bits 4-7: (Reserved)

If bits 0-3 of Byte 14 are set, then after the CHR ROM data, the emulator or flash cart expects a byte before the data used for ROM size in 512B banks; with ~127K max.

The M50805 960B maskROM can just be loaded into the FPGA of the flash cart or emulator as 1K, and the emulation itself should only access 960B. Should any extra ROM here be larger than ~127K?

[lidnariq]

As far as I know the relevant capacities are:
960 bytes - M50805
8192 bytes - PC-10 homebrew INST-ROM with dummied encryption
8192+(9?? padded into 16/32??) bytes - PC-10 OEM software with functioning RP5H01
12244 bytes - µPD7755
32768 bytes - µPD7756 and/or the programmable µPD77P56

I don't know what extra ROM you're referring to in the Vs. System? The Namco copy protection ICs seem to be logic functions, not ROMs.

I also haven't heard/paid any attention to "NOAC ROMs" ? Examples?

I don't think it's too unlikely that we could possibly find a larger ADPCM IC used at some point in the future:
65536 bytes - µPD7757
131072 bytes - µPD7758

I'm uncomfortable with "The size, in a byte, specified as a number of 512B blocks". It doesn't provide any advantages over just specifying a raw 17+ bit number. If we're going to add a length+contents field (which, yes, chunked format that I'm unhappy with, but whatever), there's no reason to not just say "It's an 32-bit little-endian number specifying the number of bytes" instead (since it's no longer trying to fit it in the 16-byte NES header).

—

Oh, tangenting all the way back to your comment about City Fighter... it really looks like it's just a 4-bit DAC in the cartridge? The rest of the emulator code doesn't support any kind of hardware decompression or hardware controlled FIFO, and yet the in-game audio still plays with just that simple logic to remap writes to $980C to pre-multiply by 8 and then copy the write to $4011.

[ap9]

Oh, tangenting all the way back to your comment about City Fighter... it really looks like it's just a 4-bit DAC in the cartridge? The rest of the emulator code doesn't support any kind of hardware decompression or hardware controlled FIFO, and yet the in-game audio still plays with just that simple logic to remap writes to $980C to pre-multiply by 8 and then copy the write to $4011.

Here's a 2015 video capture of the City Fighter IV (plus Street Fighter II, SMB3 pirate…) on hardware:

https://www.youtube.com/watch?v=1vo_-hAkKjE

Sounds like PCM (not ADPCM) with some filtering. The pitch is also higher than emulated (FCEUX). I'd say it uses expansion sound (not 4011) given the greatly varying amplitudes with different Famicoms/clones.

[tepples]

Volume differences would apply just as much to the MMC5's DAC at $5011. Do they behave otherwise similarly, other than that City Fighter audio has a different scale amount?

[B00daW]

lidnariq: Regarding NOAC clone consoles, just in case if something pops up in the future, I was simply referring to them being potentially the only other consideration where a different ROM type may need to be attached; as long as it was compatible with CPU and PPU.

If we're going to use a 32-bit chunk of data before the ROMs to specify byte(s) size, I don't see why that should be an issue; and it sounds like a great solution. We would just have to prioritize load order within the "extra ROM" portion of the header. For instance, INST, PC-PROM, AUD, Title; even if all bits are set for some reason. It would expect them in the respective order.

This seems to be fleshing out nicely.

[lidnariq]

Please don't do that.

It combines all the disadvantages of a chunked format with all the disadvantages of a monolithic non-chunked format.

Furthermore, there's already a convention for the extra PC-10 data without a Length indicator.

And, finally, you've precluded the possibility of combining both PC-10 and audio data, which is the very reason I pointed out as being a complication in the first place. Yes, I don't think it exists, but there is an audio in pin on the PC-10 cart connector, so we don't know whether it does exist.

To repeat what I said earlier

As such, I am most nearly happy with either
1- a single bit specifying that there's extra data, length and contents specified by submapper
2- a small number of bits (4?) specifying the strict lookup table of (none, 960, 12288, 32768, reserved, &c) for the number of bytes of extra data (nature of contents specified by mapper) such that programs can seek past it.

[Myask]

Why would a NOAC clone have new data that needs to be in the file for the cartridge?

Furthermore, there's already a convention for the extra PC-10 data without a Length indicator.

And, finally, you've precluded the possibility of combining both PC-10 and audio data,

/agree

[B00daW]

Oh... I don't think I precluded anything. If the bits say that the ROMs are present, then they're just in the ROM format in the order the NES 2.0 expects them to be.

Regarding a NOAC clone, I'm not really sure yet... but stranger things have happened. The point is to future-proof the best we can. Hell, there may even have to be an NES 3.0 in 10 years. ;P

Once we get the M50805 data, some of us on #nesdev can work on making an NES 2.0 formatted version of Family Trainer 3: Aerobics Studio and likely host it on archive.org.

[lidnariq]

Oh, I see, you meant a bitmask.

There's already a pre-NES2.0 bit indicating whether a given dump is for the Playchoice 10 ... but it's more-or-less meaningless unless the instructions ROM (and decryption key) is attached. Nocash has pointed out that it's extremely difficult for the Z80 in the Playchoice-10 to communicate with the game, and vice versa, so the games have to be able to run without it ... hence why there are dumps omitting that data.

But I don't see why we should proactively allocate a bit until we've found an instance that needs it though. I'm not saying that there couldn't be another address space somewhere in the Vs. System or a NoaC that would need it, but ... I'd really really like to wait until we have an instance that actually documents the need for it. There isn't enough space to allocate bits for anything that seems possible, or even likely.

I do, however, agree that we oughtn't have to use the file size to determine whether a given chunk of data is present. Perhaps there's merit in including a bit that indicates whether a PC-10 image includes=needs the decryption ROM.

[B00daW]

Oh... Another thing. Seems that we'll need to have a dump of the Decoder ROM with the M50805 too. So that's 312B Decoder ROM + 960B Parameter ROM = 1272B total for M50805 audio ROM.

[B00daW]

So with that Moero!! Pro Yakyuu bootleg dump we have something to move forward with the extra ROM with NES 2.0. Best approach is to likely put it on a submapper of the original. The mapper can designate what the ROM types are.

So for Byte 14 of NES 2.0 we can probably just use the first two bits for the amount of extra ROMs; equaling 3 max. (Would there be a need for having more than 3 extra ROM types? Maybe we can leave the bit 3 of Byte 14 reserved for now.)

Before the extra ROM data we could use 3 bytes little-endian to determine ROM sizes.

Thoughts?

[lidnariq]

If we're trying to put things into the 16-byte NES header ... I really dislike putting a separate length field afterwards.

If we're not trying to put things into the 16-byte NES header ... there's absolutely no reason to be parsimonious and specify a 3-byte type.

[B00daW]

Alright... Well, I'll move forward with the byte 14 bits 0 and 1 specifying extra ROM amount and then mapper/submapper will determine ROM sizes.