It is currently Wed Dec 13, 2017 8:06 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 45 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Tue Jun 20, 2017 9:26 am 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 1:30 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 1:40 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 2:28 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3968
Does "sample player cart" also include that DDR clone?

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 2:34 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5893
Location: Canada
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.


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 4:04 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 5:18 pm 
Offline

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

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 5:33 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 6:04 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 431
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).


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 6:05 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 6:36 pm 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 544
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?


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 6:41 pm 
Offline

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

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 7:14 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 7:22 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Jun 20, 2017 7:51 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5893
Location: Canada
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 45 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot], Yahoo [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group