NROM-368: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(Created page with "'''NROM-368''' is a name for an extension to discrete logic mappers 0 (NROM), 3 (CNROM), 13 (CPROM), and [[iNES Map...")
 
(→‎Hardware: we almost exclusively call the signal on the card edge "/ROMSEL", not "PRG /CE". Replace the latter with the former for consistency.)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''NROM-368''' is a name for an extension to discrete logic mappers [[iNES Mapper 000|0 (NROM)]], [[iNES Mapper 003|3 (CNROM)]], [[INES Mapper 013|13 (CPROM)]], and [[iNES Mapper 099|99 (Vs. System)]], allowing 46 KiB of linearly addressed ROM instead of 32 KiB.
'''NROM-368''' is a name for a theoretical extension to all mappers incapable of banking PRG, such as [[NROM]], [[CNROM]], [[CPROM]], [[iNES Mapper 184|Sunsoft 1]], and [[iNES Mapper 218|CHR-less]], allowing 46 KiB of linearly addressed ROM instead of 32 KiB.
The name comes from the naming scheme for Nintendo's [[NROM]] boards, as 368 kilobits of PRG ROM are addressable.
The name comes from the naming scheme for Nintendo's NROM boards, as 368 kilobits of PRG ROM are addressable.
Its original intent was to provide more space for a game written in C, as cc65 tends not to be good at optimizing for space.
Its original intent was to provide more space for a game written in C, as cc65 tends not to be good at optimizing for space.
To date it has not been used for any ROM release.


== Format ==
== Format ==
The PRG ROM is 49152 bytes in size.
The PRG ROM is 47104 bytes in size.
The first 2048 bytes are ignored; the rest is loaded into $4800-$7FFF.
Due to constraints of the [[iNES]] format, it is padded at the beginning with 2048 bytes of ignored data so that it is an even multiple of 16384 bytes; the rest is loaded in order into $4800-$7FFF, $8000-$BFFF, and $C000-$FFFF.


So an [[iNES]] or [[NES 2.0]] image would look like this:
So an [[iNES]] or [[NES 2.0]] image would look like this:
Line 11: Line 13:
# 2048 bytes: Ignored.
# 2048 bytes: Ignored.
# 47104 bytes: PRG ROM mapped to $4800-$FFFF.
# 47104 bytes: PRG ROM mapped to $4800-$FFFF.
# 8192*''n'' bytes: CHR ROM mapped to PPU $0000-$1FFF.  
# 8192×''n'' bytes: CHR ROM mapped to PPU $0000-$1FFF.
 
The [[UNIF]] encapsulation should ignore all padding and just have <tt>PRG0</tt> be exactly 47104 bytes.


== Hardware ==
== Hardware ==
Just as the addition of PRG RAM and bus conflict avoidance to these mappers takes [[PRG RAM circuit|one chip to decode]], the addition of $4800-$7FFF also takes one chip that uses PRG /CE, M2, and A14-A11 to construct an enable signal for the PRG ROM.
Just as the addition of PRG RAM and bus conflict avoidance to these mappers takes [[PRG RAM circuit|one chip to decode]], the addition of $4800-$7FFF also takes one chip that uses /ROMSEL, M2, and A14-A11 to construct an enable signal for the PRG ROM.
A [[74238|74HC238]] 3 to 8 line decoder has been suggested:
This is a [[7485|74HC85]] comparator.
<pre>
      ,--v--.
  A0 --|    |-- Vcc
  A1 --|    |-- Y0
  A2 --|    |-- Y1
/CE1 -o| 74  |-- Y2
/CE2 -o| 238 |-- Y3
CE3 --|    |-- Y4
  Y7 --|    |-- Y5
GND --|    |-- Y6
      `-----'
</pre>
If CE1 and CE2 are both low and CE3 is high, then the Y indicated by A0-A2 is asserted.
Otherwise, none of Y0-Y7 are asserted.
The 238 produces positive enables.


:''TO DO: How to wire up the 238''
:''TO DO: Once the circuit is tested on a real PCB, details of how to wire up the '85 will be given here.''
A14 through A0 go to the PRG ROM as is, and PRG /CE goes to A15.
A14 through A0 go to the PRG ROM as is, and /ROMSEL goes to A15.
When burning the EPROM, you have to rearrange the 16 KiB segments of the PRG ROM into the order 1, 2, 0, 0, as PRG /CE is inverted compared to A15.
When burning the EPROM, you have to rearrange the 16 KiB segments of the PRG ROM into the order 1, 2, 0, 0, as /ROMSEL is inverted compared to A15.


== References ==
== References ==
*[http://nesdev.parodius.com/bbs/viewtopic.php?t=8921 BBS topic]
*[http://forums.nesdev.org/viewtopic.php?t=8921 BBS topic], including [http://forums.nesdev.org/viewtopic.php?p=94322#p94322 wiring instructions]
[[Category:Mappers using $4020-$5FFF]]

Latest revision as of 21:20, 15 July 2019

NROM-368 is a name for a theoretical extension to all mappers incapable of banking PRG, such as NROM, CNROM, CPROM, Sunsoft 1, and CHR-less, allowing 46 KiB of linearly addressed ROM instead of 32 KiB. The name comes from the naming scheme for Nintendo's NROM boards, as 368 kilobits of PRG ROM are addressable. Its original intent was to provide more space for a game written in C, as cc65 tends not to be good at optimizing for space.

To date it has not been used for any ROM release.

Format

The PRG ROM is 47104 bytes in size. Due to constraints of the iNES format, it is padded at the beginning with 2048 bytes of ignored data so that it is an even multiple of 16384 bytes; the rest is loaded in order into $4800-$7FFF, $8000-$BFFF, and $C000-$FFFF.

So an iNES or NES 2.0 image would look like this:

  1. 16 bytes: Header. PRG ROM size must be 3. Trainer and battery are forbidden; NES 2.0 PRG RAM size must be 0.
  2. 2048 bytes: Ignored.
  3. 47104 bytes: PRG ROM mapped to $4800-$FFFF.
  4. 8192×n bytes: CHR ROM mapped to PPU $0000-$1FFF.

The UNIF encapsulation should ignore all padding and just have PRG0 be exactly 47104 bytes.

Hardware

Just as the addition of PRG RAM and bus conflict avoidance to these mappers takes one chip to decode, the addition of $4800-$7FFF also takes one chip that uses /ROMSEL, M2, and A14-A11 to construct an enable signal for the PRG ROM. This is a 74HC85 comparator.

TO DO: Once the circuit is tested on a real PCB, details of how to wire up the '85 will be given here.

A14 through A0 go to the PRG ROM as is, and /ROMSEL goes to A15. When burning the EPROM, you have to rearrange the 16 KiB segments of the PRG ROM into the order 1, 2, 0, 0, as /ROMSEL is inverted compared to A15.

References

Retrieved from "https://www.nesdev.org/w/index.php?title=NROM-368&oldid=8688"