The Gamerz Tek G8-Bit NES clone CIRAM /CE has one-ohm resistance to ground, as reported by my multimeter with the unit powered-off. I'm playing with my own cartridge circuit setup and want to use my own RAM, so I thought I should tie CIRAM /CE high to +5V. That caused the clone to shut off, of course.
I stick Galaga in there (which is NROM so it just ties CIRAM /CE to /A13) and when I probe /A13 on the oscilloscope, the expected happens: I see very little rise and fall, unlike A13 itself which is full swing from 0-ish to 3.2-ish volts (TTL high).
How can games even work, bro?
Thanks!
P.S. It's been a good system to play with otherwise, even running Castlevania 3.
Some famiclones route PA13 out of the PPU to +CE of an internal VRAM. They don't work with carts that provide their own nametable memory (e.g. Gauntlet, Rad Racer II, Napoleon Senki, Castlevania III, After Burner) or carts that use the internal VRAM as CHR RAM (e.g. Magic Floor). This is done for two reasons:
- Ignorance on part of famiclone makers as to the existence of carts with their own nametable memory.
- Consoles using a OneBus-compatible NOAC repurpose one of the cart pins to detect carts that support a nonstandard cart edge protocol that multiplexes CHR ROM and PRG ROM onto one bus. This might be the OneBus detection pin.
Does the OneBus thingie allow CastleVania 3 to work? It plays fine on this Gamerz Tek doodad.
Can you make good quality photos of the console internals?
I guess that CIRAM /CE is connected to GND and PPU-/A13 is pulled up to VCC and wired into NES-ON-CHIP so that when external cartridge is inserted (99% of them shorts those pins), console knows that it should disable internal cartridge.
In that case CIRAM /CE might be not available and you cannot disable internal VRAM, but maybe it is routed to some test pad or jumper in the PCB and you can modify the console to take it into account.
@crazyball: It's not worth the time. I'll just have to get a real NES.
Thanks!
FYI
I wanted to add that this Gamerz Tek G8-Bit NES clone also does not breakout CPU R/~W to the cartridge interface, as near as I can tell from my experiments.
This and the previous discussion about CIRAM.~CE pertain to the non-HD version. I don't know about Hi-Def version.
Only the very simplest of games (NROM = mapper 0, about 10% of all licensed games) could possibly function without access to R/W; everything else requires it. Do you mean some other signal?
Thank you for your correction. I meant CPU R/W but obviously I'm wrong. I will look into why I am having trouble with it (always seems to be floating) in my experiment and report back.
I hooked up a divide-by-60 counter to the CPU R/~W signal and output to some LEDs.
The main loop checks the buttons (once a frame) and if Button A is down,
Code:
STA $8000
is executed.
When I hold down A, sure enough, the count increases.
But... when I don't hold down A, the count still increases (at a slower rate).
Similar behavior that I noticed before is why I thought the CPU R/~W line was floating.
When I run the ROM in FCEUX after setting a WRITE breakpoint on the range $8000-$FFFF, it does not trigger unless I press the A Button.
I don't know.
Any time that your code calls a subroutine, or enters an interrupt or NMI, R/W will be low in order to write the return address to the stack.
Oh, yes. I forgot to mention that I only count R/~W being low when CPU ~ROMSEL is also low. Sorry I forgot that.
/ROMSEL is delayed after M2 by around 30ns; R/W could fall before /ROMSEL rises.
What exact hardware is your divide-by-60 made of?
lidnariq wrote:
/ROMSEL is delayed after M2 by around 30ns; R/W could fall before /ROMSEL rises.
If that is the case, could there not be a spurious write to the ROM address space?!
Depends on how fast the parts are you're using. People who've used 10ns RAMs have reported this problem, yes. But typical 70ns+ RAMs are fine.
Most mappers use a clock edge instead of being level-based: those seem to be ok. There's a bug in the Namco's 108 (mapper 206) that's very likely this problem. (Writes to $0000-$1FFF while executing code in the range of $8000-$9FFF can cause spurious mapper writes)
I can switch to an edge-based approach as well. How many tens of nanoseconds after the fall of ~ROMSEL should I allow a falling edge of R/~W to trigger a write to ROM space, do you think?
As far as I know, 30ns is a good ballpark for the propagation delay through the 74'139 inside the NES itself that causes this race.
I'll note that Nintendo's discrete logic mappers, such as UNROM (3), CNROM (2), and ANROM (7), just use a 74'161 with R/W connected to '161./LOAD and /ROMSEL connected to ↑CLOCK.
I changed my experiment to continuously sample CPU R/~W after CPU ~ROMSEL falls. It mostly simulates asynchronous SRAM as far as the R/~W line goes, but only for 220ns. After that it ignores R/~W until the next falling edge of ~ROMSEL, when it offers another window of 220ns.
Seems to work: I can read the value sent to the ROM space and I don't get spurious reads--that I can tell. I'll do more rigorous tests later.
Thanks, lidnariq! Very helpful info.