Hong Kong version Famicom clock frequency is 21.3125MHz

Hong Kong version Famicom clock frequency is 21.3125MHz
by mark_k on 2009-06-30 (#48454)

Hi,

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

-- M

by Dwedit on 2009-06-30 (#48455)

Does it use NTSC-like timing (3 pixels per CPU cycle) for running games in 50Hz mode, or PAL-like timing? (3.2 pixels per CPU cycle)
How about the length of VBLANK?

by mark_k on 2009-07-01 (#48461)

Hi,

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.

-- M

by tepples on 2009-07-01 (#48462)

Typical unrolled loop to copy a nametable row or an 8x16 pixel tile: 1 write per 8 CPU cycles
Code:
.repeat 32,I
lda copyBuffer+I,x
sta PPUDATA
.endrepeat

Or if the buffer is in an unused part of the stack page, same timing
Code:
.repeat 32
pla
sta PPUDATA
.endrepeat

Typical unrolled loop to clear both nametables, as seen in init code: 1 write per 4 CPU cycles
Code:
ldx #$24
stx PPUADDR
ldx #$00
stx PPUADDR
txa
@loop:
.repeat 8
sta PPUDATA
.endrepeat
dex
bne @loop

So in non-pathological code (i.e. not an unrolled loop of INC PPUDATA), the PPU will be chip-selected only 1/4 of the time at maximum. That's more than suitable for extending a 20 line vblank to cover 71 lines.

As for turning into grayscale, I imagine that the NTSC-to-PAL circuit would generate its own color burst signal.

by mark_k on 2009-07-01 (#48475)

I'll have to test some more PAL NES carts (which might have longer vblank routines) on the console and see whether the effect in 50Hz mode is the same as in 60Hz mode (i.e. same as when used on a normal NTSC console).

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?)

by mark_k on 2009-07-06 (#48597)

A little update on this...

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?

by Dwedit on 2009-07-06 (#48606)

So does this mean that it halts the PPU even during forced blanking? Of course, games will merrily continue writing their data for the PPU during that time.
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.

by mark_k on 2009-07-09 (#48722)

Well it would ideally halt the PPU for 51 scanlines in each frame. But if the CPU accesses the PPU during the period when it is halted, the PPU is clocked, i.e. the CPU can access the PPU during the halted period. So in that case the PPU is effectively halted for something less than 51 scanlines, which means the frame is shorter than it should be. Hence the slight picture/sync disturbance when that happens.

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.)

by mark_k on 2009-07-18 (#49027)

I have uploaded an archive of pictures of my HK Famicom. Quality isn't the greatest but better than nothing. Includes a couple of shots of the hopeless bodge to fix a blown fuse done by a previous owner. :)

The archive is about 15MB in size.

http://rapidshare.de/files/47884893/Hong_Kong_Famicom_pics.tar.html

-- M

by kyuusaku on 2009-07-18 (#49030)

Looking at the pins from the power/RF board to the main board, there are 8 connections..

-VCC to mainboard
-VCC from mainboard to RF modulator
-GND
-video
-audio

leaving 3 signals for..

-NMI input?
-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.

by mark_k on 2009-07-22 (#49109)

It's explained in the patent linked above, it's relatively simple or more to the point, much cheaper than a full standards converter while still allowing 50Hz operation.

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).

by tepples on 2009-07-22 (#49114)

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.

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.

by kyuusaku on 2009-07-22 (#49116)

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.

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.

by mark_k on 2009-07-23 (#49139)

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.

I'm not sure how else the PPU could be halted?

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.

Could you post some more info and ideally pics of that console?

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.

by kyuusaku on 2009-07-23 (#49143)

mark_k wrote:
I'm not sure how else the PPU could be halted?

The cleanest way would be an "enable" control signal. I guess in this case gating the clock is enough.

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.

by mark_k on 2009-07-28 (#49278)

kyuusaku wrote:
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.

Hmmm, interesting. I wonder whether Nintendo themselves manufactured the power/video board, or whether it was fitted by the company which imported Famicoms into whichever country it was sold in.

Probably the cheapest way to get a picture from it would be to buy a USB TV tuner for your computer. Most of those have multi-standard tuners.

The PCB of your console is a normal Japanese Famicom board, I think. (Is the crystal 21.47727 MHz?) The switch on the back is most likely a 50/60Hz switch (and the chip part number MK5060 suggests it has that ability).

If Nintendo did make the entire console, the later HK Famicom would probably have been cheaper to make due to not needing hand-wired alterations. The hand-wired parts remind me of the "PAL booster" products which were available for the Super Famicom. They plugged into the SFC multi-out port, and had a 50/60Hz switch. Internally, the console was modified by rewiring a couple of pins on the multi-out socket to carry the clock signal (instead of S-video Y and C if I recall). That allowed the 50/60Hz switch to function. The alterations to your console are probably similar.

The picture of the underside you uploaded is quite blurry. What is the text on the underside of the power/video board?

by kyuusaku on 2009-07-28 (#49280)

mark_k wrote:
Hmmm, interesting. I wonder whether Nintendo themselves manufactured the power/video board, or whether it was fitted by the company which imported Famicoms into whichever country it was sold in.
Nope, it's made by Bung for the HK market.

Quote:
Probably the cheapest way to get a picture from it would be to buy a USB TV tuner for your computer. Most of those have multi-standard tuners.
I have one, but it doesn't have a RF tuner :\ Not dying to use this FC or anything since I don't have a multi-system TV, might implement it's 50Hz mode in my Famiclone some day though.

Quote:
The PCB of your console is a normal Japanese Famicom board, I think. (Is the crystal 21.47727 MHz?) The switch on the back is most likely a 50/60Hz switch (and the chip part number MK5060 suggests it has that ability).
I didn't write it down while I had it open but I believe it was standard 21.47 MHz.

Quote:
The picture of the underside you uploaded is quite blurry. What is the text on the underside of the power/video board?
Just says Makko Toys ie Bung.