It is currently Wed Jul 17, 2019 5:28 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue Jun 30, 2009 5:35 pm 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jun 30, 2009 6:36 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4191
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?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 01, 2009 5:53 am 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 01, 2009 6:14 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21506
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 01, 2009 3:15 pm 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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?)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 06, 2009 1:14 pm 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 06, 2009 5:00 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4191
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.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 09, 2009 3:30 pm 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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.)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 18, 2009 10:15 am 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 18, 2009 12:39 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1668
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 22, 2009 2:53 am 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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).


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 22, 2009 8:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21506
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 22, 2009 9:49 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1668
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 23, 2009 3:31 pm 
Offline

Joined: Sun Feb 26, 2006 4:16 pm
Posts: 60
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. :(


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 23, 2009 5:59 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1668
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:

Image

Image

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group