What's new

Dariux

Student
Joined
Feb 16, 2020
Messages
19
Reaction score
18
Location
US
Alright Everyone,

I've been annoyed long enough at the Taito F3's sync. Today, I spent a great majority of my time prodding at the Taito F3's video output with a oscilloscope. I wanted to share what I learned and see what y'all think about how we should recommend folks handle their sync issues.

Oscilloscope: Siglent SDS 1202X-E Oscilloscope
ROM Cartridge: Puzzle Bobble 3 (AMERICA)
Motherboard: MOTHER PCB (EUORPE - REGION MOD)
Screen Sampled: Monitor Colour Test Screen

How 480i Should Work

Before we begin, here is a little primer on how 480i should work, as well as some numbers.

Refresh Rate: 29.97Hz
Time Per-Frame: 33.36ms
Time Per-Line: 63.55us
(Source: Video Demystified, verified against a Nintendo Wii)

You can imagine the picture being split into two fields, A and B. This is what makes it "i" or "interlaced". 480 is how many lines there are with actual screen content (including the overscan lines), split between the two fields are equally 240 lines. Field A is shown, and then Field B for the same frame - the way this works is the timing is manipulated during Field B's V-Sync to slightly offset the electron gun. Even on non-content lines, everything is still broken apart as-if it's a line of data (so, even during V-Sync, we can abstractly break the code into "lines" of input).

V-Sync requires a few patterns during it's active lines, let's define them...

V-Sync Line Definitions

FORMATA.png
FORMATB.png
FORMATC.png
FORMATD.png


Field Definitions

Field A

The very first pulse is supposed to be part of the v-sync, specifically it's supposed to have 3 scanlines of FormatA, followed by 3 scanlines of FormatB, followed by 3 scanlines of FormatA, then 13 blanking scanlines. Finally, we end with 240 scanlines of content (262 scanlines total).

V-Sync: A, A, A, B, B, B, A, A, A
Blanking: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
Content: 1, 2, 3, ..., 238, 239, 240

Field B

The next field is supposed to adjust the electron gun by a tiny bit - this is done by offsetting the v-sync procedure mentioned above by a half scanline. To do this, we do 1 scanline of FormatC, 2 scanlines of FormatA, 1 scanline of FormatD, 2 scanlines of FormatB, 1 scanline of FormatC, 2 scanlines of FormatA, then 14 blanking scanlines. Finally, we end with 240 scanlines of content (263 scanlines total).

V-Sync: C, A, A, D, B, B, C, A, A
Blanking: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
Content: 1, 2, 3, ..., 238, 239, 240

How F3's 480i Actually Works

From my measurements, it does not work very well. There appears to be no difference between Field A and B, and the line timing is off (and inconsistent at times). Here are the numbers.

Refresh Rate: 29.49Hz?
Time Per-Frame: 33.90ms
Time Per-Line: 64.70us (±2.40us)

Field A&B

For V-Sync, we see that we have 3 FormatA fields (the first syncing line is slow by HSYNC/2), 1 FormatD field, 2 FormatB fields, 1 FormatC field, and 3 FormatA fields. We then have 252 scanlines of either content or blanking (the first blanking line is fast by HSYNC/2). It's worth mentioning that the FormatB fields have bad timing - their high pulse is still HSYNC/2 instead of HSYNC, this just makes the signal even messier. I'm not actually sure how monitors handle something like this - it seems pretty off, and not by a small amount...

I compared this to the Nintendo Wii (works on my component input) - the HSYNC timings matched between the two, but the Wii's line timings were more in-spec and as-expected (exactly 63.55us). The different V-Syncs per-fields were present, so we could tell A apart from B, and the timing on the FormatB high pulses was correct as well (HSYNC, instead of what F3 does, which is HSYNC/2).

What's Next?

Personally, I need to think about this a bit... If anyone has experience cleaning these kinds of signals, please give some pointers. I have no idea how to right these wrongs. I think for now I'm going to continue reverse-engineering the F3, and see if anything interesting comes up. For example, I still don't know what that variable resistor does? Maybe the reason it works for some folks and not for others is because that can "tune" the timing? (Please don't try this, I don't actually know what this does, and the warning on the mobo says it could cause irreversible damage.)

If we can fix the timing, the problem is pretty simple - just count A/B fields and fix the V-Sync. If the signal is slow, I'm not too sure what to do, can't exactly speed it up can we?

Screens

A Whole Frame:

WAVE0.png



Some Field Debugging:

FIELD0.png


FIELD1.png


FIELD2.png
 
Well, the actual board output still needs to be encoded into a proper 480i signal. the voltages levels aren't right, and the sync pulse is on its own channel (though, I suppose you could use some format which leaves the sync pulse on its own wire). So it is not exactly right to say it "outputs 480i". More like the signal will be changed to something akin to 480i (maybe more accurate to say NTSC compatible).

How a lot of these old systems work is they output something similar to an interlaced signal, and usually they just push new colour data out for both fields, for effectively 60fps gameplay. So even though there are two passes on the electron gun for the signal, it ends up practically being a 240 60Hz signal. The reason for this format is to remain compatible with NTSC standards.

Probably the F3 is just resetting and drawing over the same field, effectively giving us a 60fps game (as stated, that's kind of the norm in this era). In that case there is no FieldA/FieldB. That'd make sense, but even the NES does work to preserve timing on the odd frames, and the line times to me still seem slow.

EDIT: Yeah, I really shouldn't be saying 480i above. I'm just used to thinking of an NTSC signal as 525 lines of data, producing what is effectively a 480i picture (even if the hardware treats it like 240p). I'll update the original post after work to remove this confusion.
 
Last edited:
Back
Top