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: Thu Mar 31, 2022 12:16 pm Is this caused by the clock phase difference between the CPU and the PPU? I think with some clever circuit, it is possible to 'lock' the relationship on every bootup. (for example, hold the PPU's RST pin down until the CPU's M2 becomes stable, then release that on a certain edge of the M2 pulse)
Yes, but there appear to be different glitches that are caused by each of the alignments. It's not clear if a re-shaped PPU /CE signal will fix all the glitches ... because we haven't yet been able to come up with unique identifiers for each of the 4 (NTSC) alignments ... so we don't know to what extent the glitches are caused by invalid data on the data bus, or just bad timing.

(See viewtopic.php?t=20892 - these are all caused by invalid data. In contrast, viewtopic.php?t=18092 is caused by bad timing, but not all the bad timing is subcycle-level )
Indeed, I think the numbers would be higher since the PAL PPU is clocked at 26MHz instead of 21, so it might take more cycles to meet the timing requirements of the SRAM. But the PAL C/APU clock is actually slower, therefore this has a greater chance to work on a PAL machine. However, I do not want to create a region/format specific machine. If this feature only works on a PAL machine, I would just abandon it.
Most of the problems here are that no-one's sat down with a 2C07 and measured everything. Recently org has decapped one, but I don't remember any of the differences that were found - I probably forgot to read it.

For example, in the NTSC PPU, it takes the 21.5MHz clock and divides it by two and makes two biphase clocks that run at 10.7MHz. Visual2C02 calls those "pclk0" and "pclk1"; I call them "left half dot" and "right half dot".

org did figure out how pclk0/pclk1 are generated in the 2C07, using 5 latches in a twisted-ring counter where every other latch is clocked on opposite phases. So it looks like that should be two 50% duty square waves at 10.64MHz ...

But none-the-less, if the timing hasn't changed, it should still work around to somewhere around 5.5(plus or minus?) pixels from when the CPU starts the write to when the PPU finishes the write. On the 2A07, where DMA is slower, I wouldn't be surprised if that's reliable. (On the 6527P, it should be as problematic as the 2A03)
My concern is: would these 74s be fast enough? are we forced to choose 74F series chips?
Modern ALS and ACT parts are faster than the ancient "F" series parts.

It's also ok if the delay is consistently far enough away from one pixel edge - the PPUs latch the EXT pins every pixel (so that they can do the palette lookup).

Do you already know about Visual2C02? http://www.qmtpro.com/~nes/chipimages/visual2c02/

It turns out that the EXT pins are accepted during pclk0, go all the way through the palette RAM, and are finally permitted to go further through the rendering stage afterwards during pclk1. (There's some more sources of latency before it hits the actual DAC, I believe). "pclk0" is directly visible externally during rendering as the PPU's ALE signal.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by lidnariq »

Andy18650 wrote: Thu Mar 31, 2022 12:33 pm it would actually be easier to just throw an 8KB chip at it (and the 8KB chip has a high enable CS pin which can be directly hooked up to A13 of the PPU, reducing the supply logic for the PPU to one single 74LS373).
But where are you storing the pattern tables? Is this for the bonus PPU?

It's harder to get smaller RAMs anymore - even when part pulls or New Old Stock. Might just use a 32KB RAM for both nametables and pattern tables, and add either a 74'670 or something more modern and affordable to handle some bankswitching of pattern and/or nametables.
Andy18650 wrote: Thu Mar 31, 2022 12:40 pm Yet another idea while searching for the Memblers' GTROM
GTROM is mapper 111. Basic idea is that pattern tables can be switched between two 8KiB banks, and nametables can be switched between two different sets of 4-screen nametables.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

The https://www.nesdev.org/wiki/PPU_pin_out ... escription page says 'In a dual-PPU system, it (the RST pin) can be used to synchronize the "foreground" and "background" PPUs'. Does this mean that the PPU actually drive the RST pin when set to output? If so, it would be super convenient to just connect the two RST pins of the PPUs and the video 'drifting' problem is solved. (I think this is how it is done in the TMS9918, however it is achieved by driving the RST pin to an unusual 9V and it has to be done by external circuitary, not by another 9918). However, the RST pin resets more than just timing registers, it affects PPUCTRL, PPUMASK and PPUSCROLL, too. So I doubt whether it can be used to sync the video,

Also, is a 'write to both PPU' address range helpful? (I know this was initially used to solve the drifting problem. Assume we can solve that problem in another way) I can see writing to both PPUSCROLL would be useful, when the secondary PPU is used to add more colours to a color cell, rather than parallax scrolling. But I cannot find another situation where this is helpful.

P.S. I double checked my Famiclone, it has a 6540 and a 6538 and doesn't work. (Probably because they are incompatible?) It turns out that I planned to buy an 6541 but the deal fell through. As abundant as old chips are here in China, 6541s are still quite expensive, costing some $10 per chip (and the seller only have 27 of them). Anyway, to restore my famiclone (one of several, actually) and to take the picture of that rare(-ish?) PPU, I bought one anyway and it's currently being shipped.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by lidnariq »

Andy18650 wrote: Sat Apr 02, 2022 12:22 pm The https://www.nesdev.org/wiki/PPU_pin_out ... escription page says 'In a dual-PPU system, it (the RST pin) can be used to synchronize the "foreground" and "background" PPUs'. Does this mean that the PPU actually drive the RST pin when set to output? If so, it would be super convenient to just connect the two RST pins of the PPUs and the video 'drifting' problem is solved. (I think this is how it is done in the TMS9918, however it is achieved by driving the RST pin to an unusual 9V and it has to be done by external circuitary, not by another 9918). However, the RST pin resets more than just timing registers, it affects PPUCTRL, PPUMASK and PPUSCROLL, too. So I doubt whether it can be used to sync the video,
For 312-line and RGB PPUs you don't care at all - there's no missing dot on these PPUs, and they'll forever stay synchronized thereafter.

(RST pin is only ever an input)

For NTSC PPUs, it's necessary but not sufficient. After reset is asserted and de-asserted, the PPU stops rendering for at least one vblank and refuses updates for one vblank. So you have to release them from reset at the same time to start synchronized, but have to use other means to keep them synchronized thereafter.

I have no idea whether the PAL-M famiclone PPU has a missing dot...
Also, is a 'write to both PPU' address range helpful? (I know this was initially used to solve the drifting problem. Assume we can solve that problem in another way) I can see writing to both PPUSCROLL would be useful, when the secondary PPU is used to add more colours to a color cell, rather than parallax scrolling. But I cannot find another situation where this is helpful.
I don't have any other ideas for why it might be useful. Someone else might?
P.S. I double checked my Famiclone, it has a 6540 and a 6538 and doesn't work.
I haven't ever heard of a 6540 yet - a photo of it would be nice.
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 »

You probably need to do some clock gating stuff to synchronize the chips if reset doesn't actually make all of the frame generation start at the same time every reset pulse on both chips.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: FamiCom CrossFire-an NES with two PPUs

Post by tepples »

Some clock gating is probably necessary anyway in order to compensate for skipped dot every second field after background and sprites on one PPU are left turned off for a while.
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

lidnariq wrote: Thu Mar 31, 2022 2:03 pm Do you already know about Visual2C02? http://www.qmtpro.com/~nes/chipimages/visual2c02/
Yes, however I never spend much time studying the internals of the PPU chip since I didn't think I would need it (turns out that I was wrong!)
lidnariq wrote: Sat Apr 02, 2022 12:38 pm I haven't ever heard of a 6540 yet - a photo of it would be nice.
The 6540 is a PAL C/APU, it works with the 6541 and was said to be 'the first Famicom/NES clone chipset'. However, it seems that UMC soon moved to the 6538 instead. Maybe it's because the 654x is too 'carbon copy' to be 'safe' for them so they changed the design a little bit to avoid lawsuits?
Andy18650
Posts: 43
Joined: Sat Mar 26, 2022 9:58 pm

Re: FamiCom CrossFire-an NES with two PPUs

Post by Andy18650 »

Clock gating may not be as easy as it sounds. Usaually 74LS chips deal with signals that are 10MHz or less at TTL level, the PPU clock is more than double that and is a non-TTL-level signal (it looks like a sinewave on oscilloscope).

My idea is to use a strobe register to pull the RST pin of both PPUs to low if the PPUs has drifted out of sync. However, my concern is, since the PPUMASK is cleared by RST, and would stay that way for the whole vlank, the next frame would be empty, this will create a visible 'flash' on the screen
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: FamiCom CrossFire-an NES with two PPUs

Post by lidnariq »

Worse than that - the game won't know that rendering has been disabled and won't necessarily re-enable rendering.

For a 2C02-compatible design, the only real option is either expecting the code to make a point of keeping the two in sync, or something that can detect when both PPUs don't have the missing pixel at the same time (e.g. comparing /RD or ALE) and stall one accordingly.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: FamiCom CrossFire-an NES with two PPUs

Post by Pokun »

Ben Boldt wrote: Thu Mar 31, 2022 10:12 am You should never pry out any chip or component, because it can remove the plated thru-hole. You can tell because some brownish copper "barrel" piece remains attached to the pin. This is damage that can/will cause problems. Here are some steps how I remove DIP chip without any force:
  • Keep soldering iron tip clean. Use solder sucker on all pins, first pass. Only 1 sucking per pin. (If solder remains, leave it for now.)
  • Use a tweezer to lightly wiggle each pin. If the pin is loose, it is finished desoldering. With light force, you can sometimes break the last bit free safely, but heavy force will easily cause damage to the pin, thru-hole, and your tweezers.
  • Any pin not loose or still visibly has solder, fill back up with lead-based solder and suck the solder out again. Repeat with tweezer. Each reattempt, add new lead solder first.
  • Any stubborn pin that won't clear solder: Add lead solder, leave iron on this pin longer than normal to heat it up more. Move the tip around a little to "stir" the solder. Then attempt sucking again, repeat as necessary.
When all pins are loose, the chip should pull out with zero or very small force. This is the correct method that your antique PCB/chips deserves.

Also: do not use a solder pot or hot air gun with Famicom PCBs. They will de-laminate/burn/burst before it is hot enough to remove the chip.
Thank you, I saved your tips and I shall try them next time I attempt to desolder something.
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 03, 2022 12:11 am Worse than that - the game won't know that rendering has been disabled and won't necessarily re-enable rendering.
I don't see whether that can be an issue... All 'legacy' games runs with the secondary PPU disabled (or simpler than that, with the 'palette translation register' set to all zero) unless they are specifically re-programmed take advantage of both PPUs. In that case (or with software written for with dual-PPU in mind), each time the software synchronizes the PPUs, it will be aware that it has done so, and will initialize the PPUs.

An unrealted question: is there any use case for the potential 'VRAM DMA' feature? I think it can be used to speed up the proocess of setting up a scene, thus reducing loading time. Or it can be used to set up the pattern table, since the FCCF uses CHR-RAM instead of CHR-ROM in 'native mode'. It can also be used in a 'pseudo bitmap' mode like the TMS9918 mode 2. The CPU can decompress a bitmap image while the PPU (or PPUs) is (are) rendering, and the DMA to copy the image into pattern table during vblank. I think with the help of VRAM DMA, this process can actually be fast enough to create an 'FMV'. However, I expect the image data to consume a lot of memory space so game's won't be utilizing this feature much.
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 Apr 03, 2022 6:29 am I don't see whether that can be an issue... All 'legacy' games runs with the secondary PPU disabled (or simpler than that, with the 'palette translation register' set to all zero) unless they are specifically re-programmed take advantage of both PPUs. In that case (or with software written for with dual-PPU in mind), each time the software synchronizes the PPUs, it will be aware that it has done so, and will initialize the PPUs.
Every time *software* synchronizes the PPU, yes. But then the PPUs' reset inputs need to be software-controlled when in CrossFire mode. Or at least some less-terrible way of detecting relative phase: the only knob the CPU has is "cause one PPU to run 1 pixel faster per 2 vsyncs"
I expect the image data to consume a lot of memory space so game's won't be utilizing this feature much.
Well, if you provide extra CPU RAM, it seems even more desirable.

Recently I overheard someone wishing they could bankswap zeropage. Maybe providing 32KB RAM and being able to select one of four different 8KB pages would be a good way to handle both.
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 03, 2022 12:12 pm Recently I overheard someone wishing they could bankswap zeropage.
Another person who should move to SNES ;)
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 03, 2022 12:12 pm Every time *software* synchronizes the PPU, yes. But then the PPUs' reset inputs need to be software-controlled when in CrossFire mode.
This is super easy: use an address decoder that goes low when a certain address is accessed, then aonnect that output to the RST pins of the PPU. Then a dual-PPU reset would be as easy as just an STA or STX or STY or whatever will cause that address to be accessed. The content written to the address is discarded, so that no preparation is needed. This is called a 'strobe register' and it is often super handy to use. (you can see that I borrowed a page from the ATARI 8-bit machines here)
lidnariq wrote: Sun Apr 03, 2022 12:12 pm Or at least some less-terrible way of detecting relative phase: the only knob the CPU has is "cause one PPU to run 1 pixel faster per 2 vsyncs"
On the other hand, I don't know how to achieve this easily. Since it would require some careful timing to let one PPU run exactly 1 pixel faster, otherwise it would cause the same unsynchronized situation. And the program needs to keep track of how many frames have passed since it turned off the PPU to know how many pixels need to be compensated. Plus it requires gating a 21(or 26)MHz signal, which is not a trivial thing to achieve.
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 04, 2022 9:35 am On the other hand, I don't know how to achieve this easily. Since it would require some careful timing to let one PPU run exactly 1 pixel faster, otherwise it would cause the same unsynchronized situation. And the program needs to keep track of how many frames have passed since it turned off the PPU to know how many pixels need to be compensated.
I'm just talking about what the 2c02 itself does - the CPU can directly tell it to skip drawing one pixel (and thus run slightly fast) every other redraw.
Plus it requires gating a 21(or 26)MHz signal, which is not a trivial thing to achieve.
No, not for this - I'm not currently talking about forcing two 2C02s to stay synchronized, but instead just detecting when they're not.

(It's only 21MHz: only the 2C02 and its direct clones have the missing pixel that can cause them to drift out of sync. The PAL 2C07 and the PAL-B famiclones have no missing pixel)

During normal rendering, the PPU does this, 170.5 times per scanline:
ALE is asserted(high) for one half pixel
nothing is asserted for one half pixel
/RD is asserted(low) for one full pixel

so detecting out of sync by one pixel is easy, although not direction.

Recovering how many pixels the two different by means of comparing timing of hsync, vsync, or NMI should be the rest - start with the 21.5MHz clock, divide by 4 (don't need to handle PAL consoles, they can't get out of sync), and count how many cycles exactly one of the two signals is true.
Post Reply