FamiCom CrossFire-an NES with two PPUs

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

Moderator: Moderators

calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by calima »

lidnariq wrote: Sun Apr 10, 2022 12:05 pm Unless you decide to make both video outputs available? Then you could choose between "external cart slot has graphics for foreground layer" and "external cart slot has graphics for background layer"

As roles, I'd probably refer to them as "compositor" and "background"
You'd have each user switch cables by game? Annoyance to the max.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: FamiCom CrossFire-an NES with two PPUs

Post by Ben Boldt »

Just kind of a bonkers idea, would it be possible to run 2 PPUs to create interlaced video, i.e. doubling the vertical resolution? Palettes would be interleaved, so you could dither more colors together. Sprites would be interleaved, so you could have nicer-looking options dealing with sprite limit.

Heck, combine it with this idea and use FOUR PPUs, that would be awesome.
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 Apr 10, 2022 12:05 pm Unless you decide to make both video outputs available? Then you could choose between "external cart slot has graphics for foreground layer" and "external cart slot has graphics for background layer"

As roles, I'd probably refer to them as "compositor" and "background"
I have no intention to create a new type of cartridge just to 'crossfire' the PPU.
I would like to take this chance to reiterate several points: the design philosophy of FCCF is idfferent from the original FC/NES. As I have stated, it is closer to a computer designed to work without physical cartridge. Most games will be loaded from disks (Flopy, SD/CF card, USB stick or even some sort of network). Only games that take advantage of both the dual PPUs and on-card enhancement (sound, mapper, etc.) will be released on cartridge. That means, only a few native games will be on cartridge and they will be in standard FC cartridge form factor.
I know this decision will make come people (including me, sometimes) upset. Since the FC is such a 'cartridge-heavy' platform. However, I don't want the FCCF to be another C128 which people just boot straight to C64 mode to enjoy 'legacy' games. To do this, the FCCF will need a handful of games. The problem is, FC cartridges are expensive to manufacture without a second PPU onboard (I don't know why, but FC everdrive is way more expensive than SFC/MD ones), and the number of PPU is limited. I have a small collection of PPUs, but they would run out in a blink of an eye if every copy of a native game requires one. The same goes for RAM chips. Putting things onto the main board SAVES OLD CHIPS while making the distribution of games easier.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

Ben Boldt wrote: Mon Apr 11, 2022 10:34 am Just kind of a bonkers idea, would it be possible to run 2 PPUs to create interlaced video, i.e. doubling the vertical resolution? Palettes would be interleaved, so you could dither more colors together. Sprites would be interleaved, so you could have nicer-looking options dealing with sprite limit.

Heck, combine it with this idea and use FOUR PPUs, that would be awesome.
I'm sorry but I have to point out that this idea has several flaws: first, a (sort of) trivial one, is that FC C/APUs and PPUs are namufactured in pairs, and they kind of still are in pairs now. There isn't a much bigger supply of PPU than C/APU, original or clone, new-old-stock or desoldered chips from broken machines. One concern of me about the FCCF is that it will break 'the balance of stock' since it has double the number of PPUs. But I think this won't be a big issue before the number of FCCF manufactured reach 100. However, you are now suggesting 4 PPUs per C/APU...
The second one isless trivial: the PPUs can only be accessed during vblank. People are already expressing concerns that the C/APU will be a major bottleneck for the dual-PPU design. 4 PPUs will almost vertainly overload the C/APU.
The third one is: to interlace video output, you don't need 2 set of video circuit! The adjacent lines of a interlaced frame is made of 2 seperate fields. Since the PPU outputs at double framerate (or 'field rate') you just need to flicker the whold playfield/sprite to interlace your video signal. This is actually a widely used technique in demoscenes, with the only drawback being that they hardly ever show up correctly on emulators.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by lidnariq »

Andy18650 wrote: Mon Apr 11, 2022 10:45 am I have no intention to create a new type of cartridge just to 'crossfire' the PPU.
I would like to take this chance to reiterate several points: the design philosophy of FCCF is idfferent from the original FC/NES. As I have stated, it is closer to a computer designed to work without physical cartridge. Most games will be loaded from disks (Flopy, SD/CF card, USB stick or even some sort of network). Only games that take advantage of both the dual PPUs and on-card enhancement (sound, mapper, etc.) will be released on cartridge. That means, only a few native games will be on cartridge and they will be in standard FC cartridge form factor.
Hold on. What exactly will the two PPUs have available when in crossfire mode?
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

lidnariq wrote: Mon Apr 11, 2022 11:07 am Hold on. What exactly will the two PPUs have available when in crossfire mode?
What do you mean by 'What will the two PPUs have availiable'?
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: FamiCom CrossFire-an NES with two PPUs

Post by Ben Boldt »

Andy18650 wrote: Mon Apr 11, 2022 11:05 am The second one isless trivial: the PPUs can only be accessed during vblank. People are already expressing concerns that the C/APU will be a major bottleneck for the dual-PPU design. 4 PPUs will almost vertainly overload the C/APU.
For interlacing, won't you be disabling/enabling rendering every other frame? This gives you 100% of the time that you can be writing to PPUs, not just V-Blank anymore. Certainly there are tradeoffs yet to be considered.
Andy18650 wrote: Mon Apr 11, 2022 11:05 am The third one is: to interlace video output, you don't need 2 set of video circuit! The adjacent lines of a interlaced frame is made of 2 seperate fields. Since the PPU outputs at double framerate (or 'field rate') you just need to flicker the whold playfield/sprite to interlace your video signal. This is actually a widely used technique in demoscenes, with the only drawback being that they hardly ever show up correctly on emulators.
I am wondering if the disabled PPU would be displaying 'black' for the frame and if combining the interleaved signals could take some sort of shortcut because of that.
Andy18650 wrote: Mon Apr 11, 2022 11:05 am FC C/APUs and PPUs are namufactured in pairs, and they kind of still are in pairs now. There isn't a much bigger supply of PPU than C/APU, original or clone, new-old-stock or desoldered chips from broken machines. One concern of me about the FCCF is that it will break 'the balance of stock' since it has double the number of PPUs.
I think you should step back a little on your requirements and focus on the creative aspect of this project first, and have a goal getting a prototype to do cool stuff. This is a really neat thing to think about and brainstorm, poke around with a few PPUs, write some software, etc. You don't want to start with mass production as a requirement. You don't want to exclude CPLDs. Stop writing rules and stay really open for now and be creative. If it leads us to somewhere that other people want it, then we can think about where to get PPUs, or emulate it, or do it with FPGAs or something. If it is cool enough, people will help you. Save logistical challenges for later. You might not even get to that, so why worry about it now? Just have fun, get the PPU to do something new and different. That should be the 1 requirement.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by lidnariq »

Andy18650 wrote: Mon Apr 11, 2022 11:49 am What do you mean by 'What will the two PPUs have availiable'?
When you're in FCCF mode, what holds the patterns and nametables for each of the PPUs?
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

lidnariq wrote: Mon Apr 11, 2022 2:24 pm When you're in FCCF mode, what holds the patterns and nametables for each of the PPUs?
The secondary PPU will have 16KB of VRAM (probably) with 'name table swapping', which means it will use CHR RAM. The primary PPU will have similar, if not identical VRAM configuration. I will consider on-board mapper if someone can demostrate that it can solve some programming headache of the PPU or increase the performance while costing less than 3 TTL chips (or any other off-the-shelf chips that doesn't need 'burning' firmware/logic into them). Of course in 'legacy mode' it will have only 2KB of nametable RAM but access to the cartridge, just like a regular Famicom/NES PPU.

OK the number 3 is a random choice... 'Not too many so that the FCCF remains realistic' is the point.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

An edge case not discussed in the last post is a FCCF cartridge, or even a dual-system cartridge. When inserted into a FCCF such cartridge will enable additional features such as graphics improvement, but runs fine and delivers similar gameplay on a regular Famicom. (Note that NES is not mentioned here because I would like to use the famicom cartridge interface and form factor)
However, a FCCF cartridge, even a FCCF-only one, will be just a Famicom cartridge with FCCF code on it. I think it is too hard to add direct cartridge access to the secondary PPU.
I will add support for such cartridges. For example, direct cartridge access can be enabled in FCCF mode, but honestly I don't really expect a lot of such cartridge games to appear. (What I anticipate is that most FCCF games will be distributed in digital format and loaded from card) Well, I can do little about this other than... trying to make an impressive dual-system cartridge game using MMC5+dual PPU! (That is, if my assumption, that a secondary PPU can still deliver some improvement even when the primary PPU is supercharged with an MMC5, holds true...)
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: FamiCom CrossFire-an NES with two PPUs

Post by Ben Boldt »

Sorry if I missed this, but how can both PPUs access the CHR-ROM in the cartridge at the same time? Does there need to be 2 CHR-ROMs? Or does that 2nd PPU have a dedicated onboard CHR-RAM of its own?
Andy18650 wrote: Fri Apr 15, 2022 10:38 am trying to make an impressive dual-system cartridge game using MMC5+dual PPU! (That is, if my assumption, that a secondary PPU can still deliver some improvement even when the primary PPU is supercharged with an MMC5, holds true...)
Sorry to be a realist, I hate when people do this to me, but there is no homebrew or even hacks out there developed to take advantage of MMC5's graphics abilities on the existing NES/Famicom system, which has gone decades without happening. The possibility has been there, unanswered, for a VERY long time. What you are proposing is a very much smaller subset of systems that have dual PPU. You're letting these features and requirements build up and up before you even start. I want you to be successful with this. I am not being mean or being a naysayer. I am just saying, slow down.

I want you to start small and hook 2 PPUs together and get it to do something new. If you build your vision up too much from the beginning, it will be an insurmountable, unrealistic challenge, and you will give up and we will miss out on this really cool thing you might do just experimenting with dual PPUs. Just please start with experiments and if you can make it bigger and better, and mass-produce it and add an MMC5, let that happen naturally, later, so the weight of all of that ambition doesn't crush itself.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

Thank you for being realistic! :)
I am a person who keeps being criticized as 'too ambitious' by people around me, and believe it or not, sometimes even myself. Having a great community that helps by pointing out what is realistic and what isn't is very helpful, because I kind of can't tell them apart sometimes...
OK, here's the plan for the first stage 'alpha' prototype:
-PAL system (Since PAL clone chips are easier to find, plus PAL PPUs does not have the missing dot)
-dual PPU linked with a 74LS89 (The palette translation register is an important feature of the FCCF. I want to make sure that it works before continuing)
-16KB VRAM for both promary and secondary PPU
-8KB of on-board SRAM (because... why not?)
-PS/2 keyboard support (Seems like a strange one, but in my opinion having a keyboard increases debugging efficiency)
-A 6522 VIA (I need it to do things from flashing and LED for debugging, to interfacing with the keybaord and controlling various stuff on the main baord with its GPIO pins)
The only thing that I'm not sure about is whether to include legacy mode and FC cartridge support. It is also an important feature that I want to make sure working early on, but it adds a lot of complexity such as disconnecting the BIOS ROM, limiting primary PPU VRAM to 2KB, connecting the C/APU and PPU bus to the cartridge, etc. On the other hand, if I drop this mode, I can drop the cartridge slot completely, relying on maybe ZIF ROM sockets to run different software.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

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?)
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 4:42 am -does any game use the mirrored SRAM range $0800~$1FFF ?
I know of no games that rely on being able to write memory at one mirror and read it from another. However, we know of several games that rely on there being RAM in the mirrors
-does any game try to write to CHR-ROM area (not CHR-RAM)? (i.e. should I write-protect CHR-ROM?)
Plenty do.
-does any game even 'touch'(read, write, anything) $4020~$5FFF ?
We have a whole category at https://www.nesdev.org/wiki/Category:Ma ... 4020-$5FFF
-how does battery-backed games utilize their NVRAM at $6000~$7FFF ?
It's just RAM? Some mappers have additional switches, either physical (Family BASIC) or logical (MMC1) to enable access to RAM, and that must be set to permit access.

Some games use it for just save data, some use it for a large mutable world, and some use it as a way to partially emulate the FDS.
-does any game use mirrored PPU registers ?
I don't know of any
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?)
Yes, both FCEUX's and Mesen's breakpoints are up to this task.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

I think before I proceed I need to clarify the reason behind those questions: I want to minimize the hardware while hitting a 'target compatibility'.
The 'target' is:
60%~70% of games can be loaded from a SD card and run without a physical cartridge. The game may have slight slowdowns and may behave slightly differently from running on a real FC/NES, but won't freeze/crash/have major visual artifact.
95% or more games can be run by inserting a physical cartridge, with minimal visual/behavioral differences from the same cartridge inserted into a real FC/NES.
lidnariq wrote: Sun May 08, 2022 10:04 am I know of no games that rely on being able to write memory at one mirror and read it from another. However, we know of several games that rely on there being RAM in the mirrors
To me, this sounds like I can just throw 8K of RAM there and walk away without bothering having a 'switch' to mask 2 address bits. (I may still implement it, for reasons I will get to later)
lidnariq wrote: Sun May 08, 2022 10:04 amPlenty do.
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.
lidnariq wrote: Sun May 08, 2022 10:04 am We have a whole category at https://www.nesdev.org/wiki/Category:Ma ... 4020-$5FFF
The category seems to be conposed 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.
lidnariq wrote: Sun May 08, 2022 10:04 am Some games use it for just save data, some use it for a large mutable world, and some use it as a way to partially emulate the FDS.
I know this. 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. 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...)
lidnariq wrote: Sun May 08, 2022 10:04 am I don't know of any
Sounds like I can leave all my additional hardware registers exposed even in 'legacy mode'! that saves a LOT of trouble.
lidnariq wrote: Sun May 08, 2022 10:04 am Yes, both FCEUX's and Mesen's breakpoints are up to this task.
I know, but I am only able to read/write-break a single address, not a range of addresses.

Remember the 'reasons' I mentioned earlier? well, 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. This is pnly needed for SD card games since cartridge games will have their own mappers. I have an idea to swap the highest address line of 'basic' 8K of RAM. This will swap between two different zero pages, allowing for faster mapper write analysis. if the alternate zero page may be overwritten by some games, I may need to implement some simple protection by zeroing out the bit.
Post Reply