I guess this might be of interest to an emulator author interested in options for every little console variation.
I finally got a Hong Kong version Famicom recently. That uses NTSC CPU and PPU chips, but there is an NTSC-to-PAL conversion chip in the power/modulator section. (Nintendo patented the conversion technique used by this, the patent is interesting reading.) That chip converts the colour encoding, but can also halt the PPU in order to get a 50Hz picture. There is a 50/60Hz switch on the back of the console. Strangely, on the old PAL TV I tested the console with, the 60Hz PAL picture is fine but the 50Hz picture appears in black and white.
Anyway. The crystal frequency in the Hong Kong Famicom is 21.3125MHz (vs 21.47727 for a normal NTSC Famicom). The reason for the difference is probably so the horizontal scan rate is closer to the 15.625kHz PAL standard. Maybe some PAL TVs were not tolerant of variations???
The result is that (in full-speed mode) the Hong Kong Famicom has a frame rate of about 59.5 Hz.
The console main board ID is HVC-CPU-NPC-26-01
A label on the power/modulator shielding reads HVC-HKG-26
The NTSC-to-PAL chip has 20 pins and is marked N NPC26
It will use NTSC-like timing. Regarding the length of vblank, I have not run any test code on the console yet. For compatibility I would think the console is essentially halted during the "extra" vblank time. Well, the PPU will be halted, but the CPU is probably not.
The patent (European patent 512861) mentions there being an extra 51 scanlines in vblank when in 50Hz mode. And from paragraph 53: "On the other hand, since the operation of the PPU is stopped during a clock stopped period, if the CPU intends to access the PPU, the CPU cannot access the PPU. Such a matter becomes an obstacle to the job of the CPU. Then, in this embodiment shown, the PPU clock stopped state is released when the CPU intends to access the PPU so that the CPU can access the PPU even if the PPU clock is stopped."
But allowing the CPU to access the PPU during the extra vblank time would surely reduce compatibility??? I need to test the console with as many games as possible to see if there are any issues; I haven't tried many yet. One I did try was a PAL Rad Racer cart. On a normal NTSC console there are graphical glitches. There were also glitches on the HK Famicom in 60Hz mode, as you would expect. In 50Hz mode I was expecting the same glitches, and they seemed to be present. But in addition, it looked like the display sync was being interfered with.
The 50Hz picture may have appeared in black-and-white on my TV if there is no colour burst on the extra blank scanlines, which might cause that particular TV to show the whole picture in monochrome.
Code: Select all
.repeat 32,I lda copyBuffer+I,x sta PPUDATA .endrepeat
Code: Select all
.repeat 32 pla sta PPUDATA .endrepeat
Code: Select all
ldx #$24 stx PPUADDR ldx #$00 stx PPUADDR txa @loop: .repeat 8 sta PPUDATA .endrepeat dex bne @loop
As for turning into grayscale, I imagine that the NTSC-to-PAL circuit would generate its own color burst signal.
In the case where the CPU accesses the PPU in the "halted period" (and the access is allowed by clocking the PPU), that could disrupt the video signal, which might explain the effect I saw with PAL Rad Racer in 50Hz mode.
As far as the PPU is concerned, it outputs a normal NTSC signal (it's not aware that time stops for those extra 51 scanlines). But what if the CPU accesses the PPU during the extra lines? Each access causes the PPU to be clocked. So when the extra 51 line time is over and the PPU clock is restored, it will be a few cycles "further along" than it otherwise would be.
If during the extra scanlines the CPU accesses the PPU enough times corresponding to half a scanline, the video signal output by the PPU would then be half a line ahead of where it should be. (Does that make any sense?)
On the first TV I tested the console with, the 60Hz picture appeared in colour but the 50Hz picture was in monochrome. However after adjusting the fine tuning I did get the 50Hz picture to show in colour. (No idea why only the 50Hz picture had that problem!)
On another older TV, there was no colour problem in 50Hz mode. But that TV has manual tuning only.
I have noticed that with many games (e.g. Castlevania, Super Mario Bros 3), there is a momentary picture disturbance in 50Hz mode, when starting a game or on some other visual transition. One game which reliably shows that is Joshua (Wisdom Tree); pressing Select to cycle between screens before starting a game causes the disturbance. This is probably due to the PPU being accessed when it is halted, for the reason I guessed at above?
I'm guessing that games made by Micronics (Ghosts n goblins, 1942, Athena, Tiger Heli, etc) with their slow load times are probably more compatible with this console.
With that in mind, it should be quite easy to detect whether you're running on an HK Famicom in 50Hz mode. It might also be possible to vary the frame rate, e.g. by accessing the PPU enough at the correct time you might be able to increase the frame rate to 51Hz, say. (Not very useful.)
(I haven't verified this by hooking the console up to an oscilloscope or anything. And all this only applies when the console is in 50Hz a.k.a. SLOWER mode. When in 60Hz NORMAL mode it should be completely compatible with a normal Famicom, lower clock speed aside.)
The archive is about 15MB in size.
http://rapidshare.de/files/47884893/Hon ... s.tar.html
-VCC to mainboard
-VCC from mainboard to RF modulator
leaving 3 signals for..
-21 MHz input to sync with PPU?
I'm not sure how the PPU could be halted via it's clock since it's presumably a dynamic chip and there isn't a dedicated halt signal. Or maybe /RES really does that?
When it does halt it halts for 50 lines or 17050 cycles after 20 lines of Vblank? Like you said, 21312500 / 4 / 341 = 15625 Hz line rate so 15625 / (262 + 50 ) = ~50
The NTSC->PAL transcoding must be pretty complicated.
I haven't traced out the circuit of the actual console yet, but from the diagram in the patent, the converter chip receives as input the 21MHz clock, /IRQ, /WE and /200X. It outputs PPUCLK and /IRQ'. So the chip does control the PPU clock.
It would use /WE and /200X to determine when the CPU is trying to access the PPU. As for /IRQ, I'm not sure whether that refers to the CPU /IRQ line (pin 32) or PPU /INT (pin 19, connects to CPU NMI pin on a normal NES).
But kyuusaku said "dynamic chip". I took this to mean that some of the internal registers are DRAM cells and may decay if the clock line stays constant for 51 scanlines (3.3 ms) at a time. We already know that OAM will decay in a stock 2C02.mark_k wrote:I haven't traced out the circuit of the actual console yet, but from the diagram in the patent, the converter chip receives as input the 21MHz clock, /IRQ, /WE and /200X. It outputs PPUCLK and /IRQ'. So the chip does control the PPU clock.
I don't have this Famicom, but I do have an unofficial PAL Famicom (original mainboard, 3rd party RF board with a few jumpers to mainboard). I believe it just transcodes NTSC video, but I'll check it for a 50 Hz mode; it would be funny if Nintendo took the idea from this device since they would later go on to sue and bankrupt the maker.
I'm not sure how else the PPU could be halted?kyuusaku wrote:It seems 4116 and 4164 DRAM of the early '80s can retain their contents between 2-4ms so perhaps the PPU can too. The patent strongly suggests the clock line is what halts the PPU, but it might be deceptive since there appear to be only 3 potentially digital signals between the mainboard and RF board.
Could you post some more info and ideally pics of that console?kyuusaku wrote:I don't have this Famicom, but I do have an unofficial PAL Famicom (original mainboard, 3rd party RF board with a few jumpers to mainboard). I believe it just transcodes NTSC video, but I'll check it for a 50 Hz mode; it would be funny if Nintendo took the idea from this device since they would later go on to sue and bankrupt the maker.
An update on my HK Famicom. Something about it is flaky/faulty. The internal fuse had blown at some point, and whatever caused that may have caused more damage, perhaps to the voltage regulator or PPU. Or maybe an electrolytic capacitor has dried out inside. Or maybe I caused ESD damage when cleaning the PCB (aarrgh!)??? Therefore, any picture disturbance in 50Hz mode with my console does not imply that a fully-working HK Famicom would do the same.
I tested my console with Super Mario Bros. 3 (US version via a converter) today. In 60Hz mode, the initial curtain-raising appears in colour. After the SMB logo comes down and the background changes from black to beige, the picture goes monochrome. Also there is occasional "noise" in the upper part of the picture. On starting a game, the world map appears fine, but entering the first level the picture goes mono again. The background being a light colour, particularly at the left-hand side of the picture appears to cause this problem. Some other games seemed to work fine though, e.g. Mega Man 3 (US).
I'll open it up and check that Vcc is at the correct level. With just a multimeter there's probably not a lot more testing I can do.
The cleanest way would be an "enable" control signal. I guess in this case gating the clock is enough.mark_k wrote:I'm not sure how else the PPU could be halted?
Here's my FC:
The 3 jumpers carry the CPU clock in, PPU clock out and /DBE input. Why /DBE I don't know, it can't rely on CPU access to sync with the PPU (must sample video signal).
I can't get it to tune in well on any US cable channel frequencies, too lazy to try air channels or tap composite video. Because of that I can't be sure what the back switch does but almost certainly it also switches from 50/60Hz because of the jumpers. This add-on board was made in early 1988 so it's pretty clear Nintendo didn't come up with it themselves.