FamiCom CrossFire-an NES with two PPUs

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by lidnariq »

Andy18650 wrote: Sun May 08, 2022 11:19 am I don't understand. why does games write to an area that is ROM? wouldn't that cause a bus conflict? The idea behind this question is that if no games write to CHR-ROM, I can jsut load the CHR-ROM from the SD card and leave it there. If it's a CHR-RAM game, then it will be aware what it's doing. If a CHR-ROM game tries to write to the ROM expecting nothing will change when something does change, the game is likely to crash/have major visual artifact.
There's no bus conflicts on CHR, because the PPU has separate /RD and /WR strobes. The CHR ROM gets enabled, but isn't hooked up to /WR, so no write happens.

As to why? Sometimes, because of mapper hacks, from a game that had CHR RAM but was modified to have a fixed ROM CHR instead. Sometimes because of bugs.
The category seems to be composed of not-so-popular game (I don't have time to go through them one by one, so correct me if I'm wrong) Such games will only run on physical cartridge.
Er. What's the distinction you're making here? Why does it matter if it's a physical cartridge?
What I wanted to ask was, how many bytes are used? considering many games' 'savefile' could be encoded into a 'password', then I don't think it will be too long.
You can't know, unfortunately. Every programmer did something different, so every game will use a different part of RAM...
What I want to do is to bankswitch a battery-backed $6000~$7FFF SRAM area, then we can have multiple games saved on a single machine (but then I realize if I load the game from SD card, I can just write to a file. If I use battery-backed cartridge, it would have it's own WRAM and battery...)
But how is this relevant to how games used that area?
I know, but I am only able to read/write-break a single address, not a range of addresses.
Ranges should really be obvious in both FCEUX and Mesen...
it's because I want to create a 'generic mapper' with a 74LS670. The idea is to catch mapper writes, analyse it, then emulate it in BIOS.
You may wish to read how the Game Doctor works - it's basically this idea.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by aquasnake »

Andy18650 wrote: Sun May 08, 2022 4:42 am The first schematic of the first revision of FCCF is complete!
However, I don't know how to post PDF file here...
I spent a month studying the architecture of the Famicom, and some commonly used mappers. I realize that I still have a ton of uncertainties, for example:
-does any game use the mirrored SRAM range $0800~$1FFF ?
-does any game try to write to CHR-ROM area (not CHR-RAM)? (i.e. should I write-protect CHR-ROM?)
-does any game even 'touch'(read, write, anything) $4020~$5FFF ?
-how does battery-backed games utilize their NVRAM at $6000~$7FFF ?
-does any game use mirrored PPU registers ?(I know some demos does as discussed before, but FCCF is nor meant to be 'demo-compatible')
Currently, my way to figure this out is to have software switch for all these problems, and use an everdrive to test a ton of games one by one. If the game crashes then switch on a 'compatibility switch' until it runs, then try to trun off some of the 'switches' to find what exactly the game needs. Needless to say this is a VERY tedious and inefficient process. So is there any alternative way to do it? (for example, by analysing the code with a script or by setting breakpoints in an emulator?)
-does any game use the mirrored SRAM range $0800~$1FFF ?
yes, some VT games(based on portable consoles) do use
-does any game try to write to CHR-ROM area (not CHR-RAM)? (i.e. should I write-protect CHR-ROM?)
yes, many
-does any game even 'touch'(read, write, anything) $4020~$5FFF ?
yes, many
-does any game use mirrored PPU registers ?
no, because for the gating address of PPU, only CE, A0-A2 are passed to it, and the mirror address of any PPU register cannot be used to realize other applications
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Fiskbit »

I'm pretty sure there are games that write to CHR-ROM as a piracy detection mechanism and expect the write to be dropped. I don't have examples, but I think I saw an unused function for this in one of the games I was looking at to compare against the game's FamicomBox version.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by aquasnake »

If you extend the implementation of Game Genie slightly, you can write or virtually read any address between $4020 - $ffff without conflicting with the output data of the cart ROM.

In other words, you need to control the CPU data bus and insert a bridge output permission logic
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

I'm corry for many stupid mistakes I made in my last post...
aquasnake wrote: Sun May 08, 2022 5:53 pm There's no bus conflicts on CHR, because the PPU has separate /RD and /WR strobes.
This is the first one... for some reason I thought the PPU access its memory like a 6502 (with R/W line to control bus direction) while it's actually like a 8080 (or should I say 8085, since it has multiplexed data bus)
lidnariq wrote: Sun May 08, 2022 12:57 pm Ranges should really be obvious in both FCEUX and Mesen...
This is the second... It turns out that I have not tried using the debugger of FCEUX (I have just started using it a few days ago) and I was somehow refering to my memory of using Altirra...
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

lidnariq wrote: Sun May 08, 2022 12:57 pm As to why? Sometimes, because of mapper hacks, from a game that had CHR RAM but was modified to have a fixed ROM CHR instead. Sometimes because of bugs.
OK then, a CHR-RAM write protect software switch ;)
lidnariq wrote: Sun May 08, 2022 12:57 pm But how is this relevant to how games used that area?
Well, I thought, if each game only uses a small part of the that RAM, I can use a 'finer' banking system (for example, 1KB or 2KB granularity with 32KB total) and keep a tiny 'file system' in some part of the NVRAM. Then I can have multiple game save files on the same machine. Kind of like how 5th-gen consoles do it. But then I realize all games (other than maybe a few titles written for/converted to FCCF) that require NVRAM comes with it on the cartridge. And there are few benifits of this complex system other than being able to have multiple save files for the same game. So whether this feature will be implemented is still unclear... It's cool though.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

lidnariq wrote: Sun May 08, 2022 12:57 pm Er. What's the distinction you're making here? Why does it matter if it's a physical cartridge?
Because physical cartridges will have the mapper hardware on the cartridge. The FCCF just need to hide all additional features and pretned to be a stock Famicom. If a game doesn't need a physcial cartridge to run, I would need to 'catch and emulate' the mapper. I only want to run common games in this way, which means I won't try to emulate mappers that are only used by a few games at the cost of adding complexity to the main board.
lidnariq wrote: Sun May 08, 2022 12:57 pm You may wish to read how the Game Doctor works - it's basically this idea.
I knew it... the further I'm into this 'run from cartridge' system, the more I realize I may probably doing when has been done before by game 'backup' devices. However, I only knew there is a Game Doctor for the SFC/SNES (and that's what Google search take me to...), I can find little information about the FC version other than 'this device does exist'...

By the way, many of the things discussed here is NOT in the first revision hardware. The first revision is basically a Famicom with a VIA and an additional PPU.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by aquasnake »

Don't design anything too complicated. 8K bank granularity is the smallest unit. Don't try to be smaller. I even think the 4K bank granularity of mapper31 is meaningless. In order to be compatible and reduce the hardware implementation cost, I'd rather retain twice the redundant data and convert it to 8K switching
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

aquasnake wrote: Sun May 08, 2022 8:15 pm 8K bank granularity is the smallest unit. Don't try to be smaller. I even think the 4K bank granularity of mapper31 is meaningless.
Then there is a problem: MMC3, a mapper chip widely used in many cartridges, support 1KB CHR-ROM banking. What's the meaning of this? How many games takeadvantage of it? I really want to support this mapper, but 1K granularity is well beyond even my limit.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by aquasnake »

Andy18650 wrote: Mon May 09, 2022 4:28 am
aquasnake wrote: Sun May 08, 2022 8:15 pm 8K bank granularity is the smallest unit. Don't try to be smaller. I even think the 4K bank granularity of mapper31 is meaningless.
Then there is a problem: MMC3, a mapper chip widely used in many cartridges, support 1KB CHR-ROM banking. What's the meaning of this? How many games takeadvantage of it? I really want to support this mapper, but 1K granularity is well beyond even my limit.
for MMC3
prg bank mode: 8 + 8 + 8 + 8
chr bank mode: 2 + 2 + 1 + 1+ 1 +1
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

I have a few problems with the analog part of the FC circuit:
-in both FC and NES, the CPU clock is not directly connedted to the PPU clock, but connected via a transistor follower circuit. What's the purpose of this circuit? Is it for delaying the clock signal or simply provide curent?
-the clock for both the CPU and PPU is not a TTL-level digital signal, but a sinewave coming directly out of the oscillation circuit. Are the chips designed to work with this signal? If so, do they accept TTL-level clock signals?
-The audio output of the FC is strangely 'inverted' by a 74HC368, is this a way to amplify the signal? Wouldn't that hurt audio quality? (I mean, the 74HC368 is not designed to accept analog signal)
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

aquasnake wrote: Mon May 09, 2022 6:36 am chr bank mode: 2 + 2 + 1 + 1+ 1 +1
Yes, this is what I'm talking about. So you are suggesting CHR-ROM should have finer banking, right?
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: FamiCom CrossFire-an NES with two PPUs

Post by TmEE »

Both CPU and PPU need AC coupled clock, directly driving a TTL signal causes weird instability but through a small capacitor all is good.

Inverter of a logic chip is used as a crude amplifier. Sound quality was not a concern, RF modulator (which people generally used) kills it wholly anyway lol
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by aquasnake »

I just don't suggest you do 4K(2K or even less) PRG bank switching mode. Of course, you can try it if you think my suggestion makes you feel more challenging
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by lidnariq »

Andy18650 wrote: Sun May 08, 2022 8:11 pm I knew it... the further I'm into this 'run from cartridge' system, the more I realize I may probably doing when has been done before by game 'backup' devices. However, I only knew there is a Game Doctor for the SFC/SNES (and that's what Google search take me to...), I can find little information about the FC version other than 'this device does exist'...
NewRisingSun has documented this on our wiki: https://www.nesdev.org/wiki/RAM_cartridge and https://www.nesdev.org/wiki/Super_Magic_Card and probably others that I'm forgetting.
Andy18650 wrote: Mon May 09, 2022 6:44 am So you are suggesting CHR-ROM should have finer banking, right?
Yeah, if you're going to higher compatibility. You'll need four 74'670s to be able to address 256KiB of CHR with 1KiB granularity.
Post Reply