Talk:NROM

FamicomHDL

I have made some of FamicomHDL already and I think the following code seems to work for implementing NROM-128 with vertical mirroring:

import Language.FamicomHDL;
import Language.FamicomHDL.Cartridge;
import Language.FamicomHDL.Memory;
nrom :: Mapper ();
nrom = do {
  prgrom <- makeROM 0;
  chrrom <- makeROM 16384;
  connects $ zip cpuAddress (take 14 $ addressPins prgrom);
  connects $ zip cpuData (dataPins prgrom);
  connects $ zip ppuAddress (take 13 $ addressPins chrrom);
  connects $ zip ppuData (dataPins chrrom);
  connect romSelect (chipEnablePin prgrom);
  connect ppuA13inv ciramEnable;
  connect ciramA10 (ppuAddress !! 10);
  connect (chipEnablePin chrrom) (ppuAddress !! 13);
};

Perhaps commands should be added for some of these things make shortcut. --Zzo38 22:38, 28 October 2012 (MDT)

CIC Diodes?

Some NES-NROM boards have slots for diodes too. —Bregalad (talk) 01:40, 5 May 2014 (MDT)

I can't think of a context in which diodes could be useful on an NROM board... do you have a photo somewhere (e.g. NesCartDB) ? —Lidnariq (talk) 03:20, 5 May 2014 (MDT)

I also can't think of where they could be useful (not that they are useful on CNROM either...) but NES-NROM-xxx-02 and NES-NROM-xxx-03 boards have slots for 2 diodes next to the CIC. I don't have any game using one of those boards so I can't check where they connect, but you can see the slot clearly on the NesCartDB.—Bregalad (talk) 04:03, 5 May 2014 (MDT)

Those diodes were intended to go from the CIC /RST and CIC CLK lines to vcc, providing overvoltage protection for the key CIC. But I have no idea under which situation that would have been useful.—Lidnariq (talk) 12:35, 5 May 2014 (MDT)

Oh thank you ! I don't know why but I thought about the CNROM diodes when I saw them (since they're close to the CHR ROM as well). My bad, thank you very much for clarifying this.128.178.195.59 13:25, 5 May 2014 (MDT)

Suggested reforms for this page

There is some thing I would belive would change positively. The page is about simultaneously mapper #0 and NROM, the former being wider than the later. Since I don't know if anyone else agree I won't change anything myself (since I bet 99% that any changes will be reverted immediately and everyone disagreeing), so this is just suggestions:

- Mapper #0 is defined as any board that lacks a mapper and bankswitching capability

- It is written explicitly that NROM is just one board that implements "no mapper", but other boards (RROM, Family basic, 3rd party boards, etc, etc....) also implement the same functionality

- It is written explicitly in the intro that there is no registers, and the "registers" paragraph is deleted.

- PRG RAM capability should be left open for anything 8k or less. There is nothing preventing you to implement NROM with 8k PRG RAM while still following iNES mapper #0 specifications. More than 8k is possible but it would not follow iNES mapper #0 anymore and would be a sparate "mapper" (despite being no mapper, oh the irony). I don't know how to word that correctly. In all cases, I believe that NROM + 8k PRG RAM is a valid configuration, as well as less PRG RAM and not relying on mirroring. Bregalad (talk) 07:59, 27 May 2015 (MDT)