"Fake" NTSC and BC.Kid

[Maren]

Looks like WinUAE's problem child showed up again A reminder that routinely testing this game should kind of be mandatory.

Here's B.C. Kid's problem in a nutshell: when using the default config + Chipset/NTSC, framerate drops down to 26-27 after the intro, creating a slow motion effect (albeit very solid, no hiccups) and glitches appear all over the screen, but what's interesting is that CPU and SND remain stable (no numbers skyrocketing) music plays back at the correct pitch while sound, which doesn't suffer from pitch abnormalities either, is perfectly synced to those 26-27 frames per second and to top it off, without crackling.

Here's the results for a series of NTSC-related tests (double-checked) I ran in a failed attempt to understand what was going on.

2.0.1:
===

1. Dynablaster on PAL = 58.8 - 59.2 FPS / CPU and SND remained stable.

2. Dynablaster on NTSC = 59.9 - 60.1 FPS / CPU and SND remained stable.

3. B.C. Kid on PAL = 49.9 - 50.1 FPS (intro) and 59.0 - 59.4 FPS (gameplay) / CPU and SND remained stable.

4. B.C. Kid on NTSC = 59.9 - 60.0 FPS (intro) 58.8 - 59.2 FPS (gameplay) / CPU and SND remained stable.

Beta 19:
=====

5. Dynablaster on PAL = 59.9 - 60.4 FPS / CPU and SND remained stable.

6. Dynablaster on NTSC = 59.9 - 60.1 FPS / CPU and SND remained stable.

7. B.C. Kid on PAL = 49.9 - 50.0 FPS (intro) 57.0 - 57.4 FPS (gameplay) / CPU and SND remained stable.

8. B.C. Kid on NTSC = 59.9 60.1 FPS (intro) 26.9 - 27.1 FPS (gameplay) / CPU and SND remained stable.


Now what I can gather from the tests:

. It's specifically the combination of B.C Kid + NTSC what causes WinUAE to behave erratically.

. Enabling CE only increased CPU usage, but rather slightly and proportionally.

. No disk image of the game works correctly when NTSC is enabled (the .ipf was used for logs and savestate)

. The framerate for a real NTSC game (Dynablaster) seems to be closer to the actual NTSC refresh rate than a fake NTSC game's (B.C. Kid) and I'm not suggesting that there's something wrong about it.

. Definitely not a problem that can be solved by switching graphics API's or any other setting in WinUAE.

. The gameplay's framerate during test 7 too was exceptionally low, but caused no further havoc.

. There's a line in winuaelog.log that states "29-359 [3016 000x000]: Shouldn't get here... this is a bug"


Attached are the logs and savestate for B.C Kid in NTSC mode.

Cheers.

[Toni Wilen]

But is BCKid even supposed to work in NTSC? (It does "fake" NTSC which isn't even 60Hz but something like 57Hz..)

Note that working in older WinUAE does not mean anything.

(EDIT: probably going to move these to separate thread because this may get interesting..)

[Maren]

Sorry but I have absolutely no idea. Quite honestly I never fully understood how the fake NTSC thing worked.

[Toni Wilen]

I checked the code, in NTSC mode it still attempts to do "fake" NTSC.

Copperlist waits for vpos 262, then it triggers level 6 interrupt. Interrupt routine then reads current vpos, adds 36 (Why 36?) and writes it back.(which in PAL Amiga moves current vpos to 286. Why???. "Normal" fake NTSC routines simply poke static last PAL line 312)

In NTSC hardware 312 is also accepted and Agnus keeps counting until counter wraps around (it is 9-bit counter in OCS, 11-bit in ECS and AGA).

I think current behavior is correct. (but most monitors probably won't sync properly) Previously emulation had equal or larger test but real hardware only have "does vpos equal last line?" test. (I did some real hardware tests month or so ago and updated emulation)

EDIT: correct in timing but not exactly correct display, it isn't really made for PAL or NTSC 512 line tall displays

[Maren]

Thanks for the answer, but since I'm still a lil bit clueless...what would be the correct settings for this game? more specifically refresh rate, given that apparently it wasn't meant to be played on real NTSC amigas. I just don't quite grasp the non-50hz PAL game concept, if I got your right

[Mclane]

Originally Posted by Maren

Thanks for the answer, but since I'm still a lil bit clueless...what would be the correct settings for this game? more specifically refresh rate, given that apparently it wasn't meant to be played on real NTSC amigas. I just don't quite grasp the non-50hz PAL game concept, if I got your right

I don't think the non 50hz idea was only really grasped when consoles like the Snes and MD came to be, easpecially the region locking issue. Suddenly every one was complaining about the 17% (?) speed loss and wanting things to run at 60fps.

Before that no one really even mentioned it...

[Maren]

Originally Posted by Mclane

I don't think the non 50hz idea was only really grasped when consoles like the Snes and MD came to be, easpecially the region locking issue. Suddenly every one was complaining about the 17% (?) speed loss and wanting things to run at 60fps.

Before that no one really even mentioned it...

I don't know anything about these consoles so I have no idea where you're coming from, but I never heard any PAL Amiga users complaining about speed loss, in fact, it was quite the opposite; I did hear a couple of NTSC Amiga users complaining about things moving too fast

Either way, I'm talking about these nonstandard refresh rates (neither 50hz nor 59.94hz)

[Toni Wilen]

Originally Posted by Maren

I don't know anything about these consoles so I have no idea where you're coming from, but I never heard any PAL Amiga users complaining about speed loss, in fact, it was quite the opposite; I did hear a couple of NTSC Amiga users complaining about things moving too fast

Most Amiga games are PAL. Too fast in NTSC. Most old console games were NTSC (US&Japan) -> extra borders + slower in PAL. (some supported PAL-60)

Thanks for the answer, but since I'm still a lil bit clueless...what would be the correct settings for this game? more specifically refresh rate, given that apparently it wasn't meant to be played on real NTSC amigas. I just don't quite grasp the non-50hz PAL game concept, if I got your right

It is made for PAL Amigas. For some unknown reason programmers decided to use weird ~57Hz refresh rate by modifying vertical position counter from 262 to 286 but decided to ignore real NTSC Amigas.

Fake NTSC: OCS Agnus didn't have software PAL/NTSC support. Someone invented this method to "emulate" NTSC by modifying vertical position counter register every frame from line 262 to line 312. (This only changes refresh rate from 50Hz to 60Hz but it does not have real NTSC timing)

Note that older WinUAE versions always used 60Hz when vertical position was modified (because it was simple and most programs wanted 60Hz), now it is emulated more accurately. One change is BC Kid using ~57Hz rate (which is correct) instead of 60Hz.

[Maren]

Alright, thank you, that clears it up a lot

Now that this has been moved to a separate thread, I'll take the opportunity to ask a lil bit more about timing.

. When you say "60hz" do you actually mean 59.94hz?
. When you say "57hz" do you actually mean 57.00hz? something else?

Believe it or not, decimals in display timing can make a world of a difference and I want my custom mode line to be as accurate as technically possible.

[Fabie]

BCkid is a rare game and uses a strange interlace effect unique in all amiga games

I connect my A1200 through my lifeview 3000 TV card and the program DSCALER
The program DSCALER fails to show correctly the game BCKID
I tried all Dcsaler' deinterlace filters...however none of them works with this game

ALL my other amiga games works perfect using DSCALER and my TV card

incredible but true

[Maren]

Originally Posted by Fabie

BCkid is a rare game and uses a strange interlace effect unique in all amiga games

I connect my A1200 through my lifeview 3000 TV card and the program DSCALER
The program DSCALER fails to show correctly the game BCKID
I tried all Dcsaler' deinterlace filters...however none of them works with this game

ALL my other amiga games works perfect using DSCALER and my TV card

incredible but true

It really isn't that incredible. Most of these video capture cards work at fixed, standard PAL/NTSC refresh rates and resolutions, so if you input something slightly different, bad things are meant to happen.

Also, there's no point in applying de-interlacing because there's no need to weave the fields together in the first place. B.C. Kid has no interlaced frames.

[Fabie]

Originally Posted by Maren

It really isn't that incredible. Most of these video capture cards work at fixed, standard PAL/NTSC refresh rates and resolutions, so if you input something slightly different, bad things are meant to happen.

Also, there's no point in applying de-interlacing because there's no need to weave the fields together in the first place. B.C. Kid has no interlaced frames.

some amiga games uses interlaced frames and interlaced effects and other amiga games don't use anything of that
you will notice it using a program like DCSALER and using certain DSCALER 'filters
For example..the filter "simple wave" is a total flicker fixer for the Amiga
(no flicker at pal high resolutions of 640x512 or any other PAL/NTSC interlaced resolution )
using that filter you will see that certain games uses interlace effects and interlaced frames
but
if you use the filter"high motion" you will have a strong flicker on interlaced resolutions but you will not notice any interlaced effects on games

[Maren]

Originally Posted by Fabie

some amiga games uses interlaced frames and interlaced effects and other amiga games don't use anything of that
you will notice it using a program like DCSALER and using certain DSCALER 'filters
For example..the filter "simple wave" is a total flicker fixer for the Amiga
(no flicker at pal high resolutions of 640x512 or any other PAL/NTSC interlaced resolution )
using that filter you will see that certain games uses interlace effects and interlaced frames
but
if you use the filter"high motion" you will have a strong flicker on interlaced resolutions but you will not notice any interlaced effects on games

Sorry bur I think you didn't read the whole paragraph. I'm talking about B.C. Kid specifically, not any other title, and B.C. Kid has no interlaced frames therefore requires neither weaving nor de-interlacing filters (the later of no use without a weaved source) All weaving a perfectly progressive source like B.C Kid's would do is halve the framerate, alter the aspect ratio (unless horizontal resolution is corrected proportionally) and introduce unnecessary interlacing artifacts, so if you really want the image to be larger (e.g. 640x512) simply upscale it.

Only when you scan-double an interlaced output you get flicker, and that's where weaving (the real flicker-fixer) comes in handy.

As for what "high motion" does, I'm not familiar with it so I can't argue, but this is going way beyond the scope of a WinUAE-related discussion.