New hardware and the INES 2.0 header

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
Perkka
Posts: 18
Joined: Fri Jul 05, 2019 2:29 am

New hardware and the INES 2.0 header

Post by Perkka » Wed Jan 06, 2021 7:40 am

I am currently making a expansion port sound generator for the NES. And getting help at adding support for it in Mesen.

But i am stuck at how i should define it in the INES header.
Since it’s not a mapper and will be avaiable on ”all” mappers and a game would work even if the expansion is not there. Adding mappers for it feels like a wrong way to go.

There is a ”Default Expansion Device” existing but it’s intended for $4016/$4017 devices. (This might actually get some kind of support for that address range later)


The Default Expansion Device byte has only defined bit 0-5. 6 and 7 is thus unused. I were thinking about adding it with byte 6. So it can be combined with all other expansion devices that use the controller ports.
Either that or adding a few entries like 32 for only the EPSG, 33 for EPSG+SNES Controllers. Etc

NewRisingSun
Posts: 1287
Joined: Thu May 19, 2005 11:30 am

Re: New hardware and the INES 2.0 header

Post by NewRisingSun » Wed Jan 06, 2021 7:57 am

The "$4016/$4017 devices" may not be set into stone, but I would like to know how your expansion sound device is interfaced and connected to hardware, then. I would prefer to just define additional entries instead of allocating bits, because once you have allocated a bit, you have effectively allocated 64 (bit 6) or even 128 entries (bit 7).

Perkka
Posts: 18
Joined: Fri Jul 05, 2019 2:29 am

Re: New hardware and the INES 2.0 header

Post by Perkka » Wed Jan 06, 2021 8:25 am

Currently it’s being addressed at C000,C002,E000,E002
But that depends on what signals the cart sends down through the EXP pins to the expansion connector.

There is also the possibility to use the OUT0-2 latching lines for clock and be able to send nibbles through $4016. That would be truly mapper agnostic.

NewRisingSun
Posts: 1287
Joined: Thu May 19, 2005 11:30 am

Re: New hardware and the INES 2.0 header

Post by NewRisingSun » Wed Jan 06, 2021 8:36 am

I assume we are referring to the expansion port at the bottom of the front-loading NES? How will the sound device be used with top-loading NES or Famicom consoles?
But that depends on what signals the cart sends down through the EXP pins to the expansion connector.
But if its functionality requires that the cartridge is wired a certain way, then I would say it is a mapper after all.

I could also imagine adding it as another console type (header byte 13 dec), such as "$C: Regular NES with EPSG attached to expansion port at the bottom of the console". In a way, that might even be the cleanest option, since one is basically dealing with a kind-of "modified console".

Perkka
Posts: 18
Joined: Fri Jul 05, 2019 2:29 am

Re: New hardware and the INES 2.0 header

Post by Perkka » Wed Jan 06, 2021 8:49 am

Yes i were reffering to the expansion port on the front loader.

The famicom does support sound to the cart so ic could be added as a cart passthrough device such as the game genie. It wont have stereo output that way but i doubt that’s a big deal.
It would have to have static addressing that’s not defined by thw cart though since there are no explicit pins for any expansion device. Could possibly have dip switches for some configurability.

The US toploader though does not have any audio passthrough anywhere. So it would either require a modded console or a external audio cable to the passthrough device

How does most emulators act when there is a unknown console type id?

NewRisingSun
Posts: 1287
Joined: Thu May 19, 2005 11:30 am

Re: New hardware and the INES 2.0 header

Post by NewRisingSun » Wed Jan 06, 2021 9:56 am

Perkka wrote:How does most emulators act when there is a unknown console type id?
NintendulatorNRS and Mesen run it as a standard NES/Famicom. I do not know about any other emulators, but expect them to not react to that field at all.

User avatar
Quietust
Posts: 1687
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: New hardware and the INES 2.0 header

Post by Quietust » Wed Jan 06, 2021 12:05 pm

NewRisingSun wrote:
Wed Jan 06, 2021 9:56 am
Perkka wrote:How does most emulators act when there is a unknown console type id?
NintendulatorNRS and Mesen run it as a standard NES/Famicom. I do not know about any other emulators, but expect them to not react to that field at all.
As of a few minutes ago, [standard] Nintendulator will display an error message for unsupported extended console types (i.e. all of them).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: New hardware and the INES 2.0 header

Post by lidnariq » Wed Jan 06, 2021 12:45 pm

Perkka wrote:
Wed Jan 06, 2021 8:25 am
Currently it’s being addressed at C000,C002,E000,E002
But that depends on what signals the cart sends down through the EXP pins to the expansion connector.
Basically nothing's already available on the NES's expansion port. A15 is the only portion of the address bus.
(And if it requires cooperation from the cartridge PCB, I agree with NewRisingSun - that's a mapper, not an expansion port device)
There is also the possibility to use the OUT0-2 latching lines for clock and be able to send nibbles through $4016. That would be truly mapper agnostic.
This is the only option for a NES expansion port option, because the full data bus is available, and the only clocks available are OUT0-2 and reading from $4016 and $4017.

For the Famicom, the only option is sending data via some of OUT0-2 and using one of the above same 5 signals as the clock.

The top-loader is even worse, only providing access to OUT0 and the $4016 and $4017 read strobes.

User avatar
rainwarrior
Posts: 8006
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: New hardware and the INES 2.0 header

Post by rainwarrior » Wed Jan 06, 2021 3:20 pm

Perkka wrote:
Wed Jan 06, 2021 7:40 am
Since it’s not a mapper and will be avaiable on ”all” mappers and a game would work even if the expansion is not there. Adding mappers for it feels like a wrong way to go.
For this reason, it sounds like it has no need to be in the iNES header at all? This would be an emulator option, not part of a cart?
Perkka wrote:
Wed Jan 06, 2021 7:40 am
The Default Expansion Device byte has only defined bit 0-5. 6 and 7 is thus unused. I were thinking about adding it with byte 6. So it can be combined with all other expansion devices that use the controller ports.
No, do not do this. This certainly does not deserve to occupy an entire bit in this field. No device does. That's not how this field works.

The default expansion device field is not intended to offer every possible permuation of devices. It is an enumerated list of interesting/useful cases.

If you actually release a ROM that can make use of your expansion device, we can add the one case it needs.

(Are you really planning to make things with this device that require a large variety of peripherals?)

If you plan to release 100 ROMs like this all using different mappers... I'll just say that this is kind of an extreme ambition, and I definitely don't think we need to try and future proof the format for that right now.

Perkka
Posts: 18
Joined: Fri Jul 05, 2019 2:29 am

Re: New hardware and the INES 2.0 header

Post by Perkka » Wed Jan 06, 2021 6:38 pm

Feels like a lot of feelings here, I made this thread askimg for suggestions and telling my thoughts about it to make a good decicion.
Nothing about my expansion device is set in stone right now.
But i want to make it as good as possible.

If i would add all as separate mappers it would not be able to run even with missing audio before it get support.
If i would add it as an expansion device it would likely require several slots depending on addressing (or it could figure out addressing depending on mapper choice), but would likely work on most emulator since i guess they would simply skip the extra audio if the expansion device is not added.
If i add it as a console type it would most likely not start anywhere before it had support added.

I dont know if i should add $4016 addressing support or not, maybe skip exp line addressing all together.
All different types gives different issues to overcome on the consoles.

Exp line addressing cant be done on famicom so it would need dip switches or something to decide addressing.
$4016 could be dones with a cable to the expansion port on the famicom.
$4016 will work well on the frontloader
$4016 will require a lot more cpu grunt since its only possible to send nibbles. But it would only require one entry in default expansion device and be totally mapper agnostic.

I dont know if the nes has enough cpu power so i maybe should only use $4016 and skip all other addressing. I kind of wanted the other type since it would be s5b compatible and use less cpu

I do currently have a working prototype and have it playing some VGMs

lidnariq
Posts: 10273
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: New hardware and the INES 2.0 header

Post by lidnariq » Wed Jan 06, 2021 7:10 pm

Perkka wrote:
Wed Jan 06, 2021 6:38 pm
If i would add all as separate mappers it would not be able to run even with missing audio before it get support.
[...]
If i add it as a console type it would most likely not start anywhere before it had support added.
So release the same ROM data with different headers? There's nothing wrong with saying "this header is technically wrong but will work in existing emulators". I use it all the time for mapper 218 work.
Perkka wrote:
Wed Jan 06, 2021 6:38 pm
Exp line addressing cant be done on famicom so it would need dip switches or something to decide addressing.
In which case it must be physically on the cart PCB in which case it is by definition a mapper.

I get it, it's really tempting to design something for maximum extensibility. It increases the usability by third parties, theoretically. Hence wanting a bitmap. Hence wanting an expansion port device in the first place. But like every other pipedream, it's ultimately a fool's errand.

Your only choices are couple your hardware to a specific mapper—which is correct because mappers describe specific existing hardware; to use a SPI-like protocol to send from the Famicom or top-loader; or something that's front-loader only and can send at most 7 (one edge) or 14 bits (both edges) as a time via writes to $4016.

Post Reply