It is currently Thu Sep 19, 2019 6:10 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Jun 18, 2019 2:40 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
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.


Top
 Profile  
 
PostPosted: Tue Jun 18, 2019 2:50 pm 
Offline

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Jun 18, 2019 3:11 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
Does the OneBus thingie allow CastleVania 3 to work? It plays fine on this Gamerz Tek doodad.


Top
 Profile  
 
PostPosted: Tue Jun 18, 2019 3:22 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 541
Location: Poland
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.


Top
 Profile  
 
PostPosted: Tue Jun 18, 2019 8:43 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
@crazyball: It's not worth the time. I'll just have to get a real NES.

Thanks!


Top
 Profile  
 
PostPosted: Thu Jun 27, 2019 1:15 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
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.


Top
 Profile  
 
PostPosted: Thu Jun 27, 2019 1:31 pm 
Offline

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


Top
 Profile  
 
PostPosted: Thu Jun 27, 2019 8:04 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
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.


Top
 Profile  
 
PostPosted: Fri Jun 28, 2019 1:47 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
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.


Top
 Profile  
 
PostPosted: Fri Jun 28, 2019 2:42 pm 
Offline

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


Top
 Profile  
 
PostPosted: Fri Jun 28, 2019 3:09 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
Oh, yes. I forgot to mention that I only count R/~W being low when CPU ~ROMSEL is also low. Sorry I forgot that.


Top
 Profile  
 
PostPosted: Fri Jun 28, 2019 3:13 pm 
Offline

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


Top
 Profile  
 
PostPosted: Fri Jun 28, 2019 3:54 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
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?!


Top
 Profile  
 
PostPosted: Fri Jun 28, 2019 4:06 pm 
Offline

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


Top
 Profile  
 
PostPosted: Fri Jun 28, 2019 4:16 pm 
Offline

Joined: Tue Jan 23, 2018 11:19 pm
Posts: 24
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?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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