FS-UAE: NTSC still not quite right [Solved]

[mr_a500]

I'm trying to reproduce my real Amiga setup in emulation, but I still have NTSC/PAL problems. My real Amiga 500 is NTSC and I run both NTSC and PAL games with WHDload without problems.

If I run FS-UAE in NTSC mode, PAL games & demos (running in PAL mode through WHDload) run way too fast and music is fast and choppy. (Real Amiga does not do this.)

If I run FS-UAE in PAL mode, NTSC games have slow choppy music. Also, it appears that the NTSC screen doesn't clear correctly on opening and there is a corrupted chunk of the PAL Workbench at the bottom.

Basically, any music played will become choppy if a screen is opened which is not in the original mode. (NTSC on PAL or PAL on NTSC)

Since most of my games and demos are PAL, I've had to switch my Workbench setup and all other programs to PAL screens, but I have some programs that only work in NTSC and I'd like to be able to just plug in the CF from my NTSC Amiga and have it work properly.

[FrodeSolheim]

FS-UAE currently calculates the rendering frame rate on startup, so when the Amiga later switches refresh rate the Amiga will run with incorrect speed (the sound issues are of course just a bi-effect of this).

I can improve this. Will also first have to modify FS-UAE so full video synchronization will automatically be enabled/disabled on demand when the Amiga refresh rate changes and equals/not equals the host refresh rate (no automatic mode switching yet).

[FrodeSolheim]

Please try the latest development release:
http://fengestad.no/fs-uae/2013/01/1...19dev-released

This version should automatically adjust to Amiga PAL/NTSC mode change.

[mr_a500]

Wow, that was fast. Thanks Frode. Yes, it's looking good now. Sound is nice and stable. The only thing left is the bit of uncleared screen when opening NTSC screen on PAL overscan.



...but I don't think I'll be running Workbench in PAL overscan now that NTSC is working fine, so it doesn't really matter to me.

[mr_a500]

One problem with NTSC is that I can't get the viewport right. With PAL mode, (after much tinkering) I've managed to get Workbench and games reasonably centred with viewport. With NTSC, I can't find a way to move it down vertically.

Here are screenshots (same viewport, same setup) showing what I'm talking about:

PAL:


NTSC:


I think NTSC screens are opening "too high".

If I don't use viewport, it automatically centres, but that screws up screen drag and also causes automatic scaling unless I use scale_x=0 scale_y=0... and that prevents the scaling that I do want in fullscreen.

[mr_a500]

Here's another screenshot. Fantastic Voyage allows you to switch between PAL and NTSC. Notice how much higher the NTSC starts (chunk of PAL screen still visible at bottom - not refreshed properly).



(at least the sound remains smooth - previously, this switch resulted in jerky audio)

[FrodeSolheim]

The garbled graphics at the bottom: I think this happens because I don't clear the frame buffer when target_graphics_buffer_update() is called. Will follow up on that.

When it comes to graphics placement, I am not yet convinced there is a bug (and also, you didn't say what viewport setting you used, so a bit difficult to comment your case).

When I fire up an NTSC Amiga 1200 and use the workbench prefs to set up max overscan, the entire WB display is still visible (see screenshot). Relative to the 752x572 buffer FS-UAE uses internally, the WB screen uses 724x482 with offsets x=2 and y=0... -So if you define a viewport which starts with y > 0, the overscanned WB display will be cropped.

Regarding the game, it seems that the game simply starts the display output earlier with the "NTSC" game option. This may (or may not) be completely normal...

[FrodeSolheim]

Regarding the leftover graphics: If you use the git repo, you can update the master branch and test with the latest commit (clear buffer on target_graphics_buffer_update).

[mr_a500]

It might not be a "bug", but it's frustrating not being able to centre NTSC as well as PAL.

I'm using:
window_width = 720
window_height = 550
viewport = * * * * => 34 10 692 550

In PAL, in windowed mode, Workbench and The Settlers (largest PAL screen game I have) are nicely centred.


If I use this in NTSC, Workbench titlebar is cut off at the top:



If I switch to viewport = * * * * => 34 0 692 550, titlebar is completely visible (though screen not as nicely vertically centred as in PAL), but The Settlers and other PAL screens are 10 pixels too low. (yes... this annoys me )

[FrodeSolheim]

I can at least explain one 10 pixel difference: The "normal" 320x200 Amiga display window starts at coordinates $81,$2C IN both PAL and NTSC mode (http://amigadev.elowar.com/read/ADCD.../node006F.html).

The y coordinate, converted to decimal (and line-doubled) is 88. But instead of 88, this Amiga display window starts at y coordinate 36 in FS-UAE. The difference comes from VBLANK_ENDLINE_PAL (26) number of lines being skipped. 88 - 26 * 2 = 36.

But when in NTSC mode, VBLANK_ENDLINE_NTSC (21) number of lines are skipped instead. 88 - 21 * 2 = 46, and this y coordinate is where it appears in the FS-UAE frame..

So using the same Amiga window coordinates, the resulting image will be placed 5 lines * 2 = 10 pixels further down in NTSC mode. This is not really a decision I've made, this is due to inherited UAE code.

Centering-wise, I don't know what is "correct" here. I suppose that depends of how correct is defined. For example, I don't know if the PAL / NTSC output would appear exactly the same distance from the top of the screen on a real monitor connected to an Amiga...

But is definitively possible for FS-UAE to adjust this 10 pixel difference so the same window start coordinates will end up at the same FS-UAE buffer coordinates in both NTSC and PAL mode...

-Any experts on this matter around?

[mr_a500]

On real Amiga, switching NTSC to PAL actually bounces the screen up, not down. Strangely, when I run the same NTSC/PAL switcher in FS-UAE, it affects only the current screen (ABCdir), not Workbench.

Anyway, I don't think I'll bother you with this minor problem anymore. Once the graphics refresh problem is fixed, I think I'll just use the PAL setup. The occasional time I want to plug in my CF card NTSC setup, I'll just use no scaling and no viewport.

[FrodeSolheim]

Originally Posted by mr_a500

On real Amiga, switching NTSC to PAL actually bounces the screen up, not down.

Yes, that's what I meant too. The playfield will currently be displayed 10px further up when in PAL mode!

Originally Posted by mr_a500

Anyway, I don't think I'll bother you with this minor problem anymore. Once the graphics refresh problem is fixed, I think I'll just use the PAL setup. The occasional time I want to plug in my CF card NTSC setup, I'll just use no scaling and no viewport.

OK, but it's no bother. I think it is interesting to read the Amiga hardware manual, read the UAE source code and discuss it

As noted, the graphics refresh problem should be fixed in the latest available git commit.

[mr_a500]

Originally Posted by FrodeSolheim

88 - 26 * 2 = 46

This mathematics confused me for a few seconds.

[FrodeSolheim]

Originally Posted by mr_a500

This mathematics confused me for a few seconds.

That's because you assumed it was "normal" mathematics (Joke aside, fixed the typo now! )

[FrodeSolheim]

Btw, leaving aside what the correct behaviour is when displaying PAL/NTSC screens.

If you for your setup increase window height with 20, from 550 to 570, and use:

viewport = * * * * => 34 0 692 570

This should center your PAL screens again for you, at the cost of a slightly bigger black area at the bottom of the NTSC WB screen...

EDIT: btw, I realize now that we talked about two different 10 px differences, yours was of course simply that your "centered PAL screens" got displaced by 10 pixels when you panned the viewport 10 pixels up see the start of the overscanned NTSC Workbench...

[mr_a500]

I didn't want to increase window height, just set the NTSC starting line the same as PAL screens. (any chance that could be an option?)

I just quickly tested the screen refresh fix and it seems fine. Thanks!

[FrodeSolheim]

Originally Posted by mr_a500

I didn't want to increase window height, just set the NTSC starting line the same as PAL screens. (any chance that could be an option?)

Yes, but I don't think that's what you really want. This would effectively move NTSC screens 10 pixels further up...

As I understand it, what you want is rather a way to add a specific vertical offset to the display when in NTSC mode... There are many ways this could be done. (An option to start rendering NTSC screens at a vertical offset into the FS-UAE buffer, or include a custom amount of ntsc vblank lines, or allowing a separate viewport_ntsc option if also allowing negative coordinates there, etc).

Since you compile your own versions, you can also play around with it yourself. Here's a simple hack. Open custom.cpp and find line 3086 (or thereabouts):

minfirstline = VBLANK_ENDLINE_NTSC;

If you want to move the all NTSC content down 30 pixels, you can change this to:

minfirstline = VBLANK_ENDLINE_NTSC - 30 / 2;

(you should be able to move NTSC content down by up to max 42 pixels vertically this way).

[mr_a500]

Originally Posted by FrodeSolheim

Since you compile your own versions, you can also play around with it yourself. Here's a simple hack. Open custom.cpp and find line 3086 (or thereabouts):

minfirstline = VBLANK_ENDLINE_NTSC;

If you want to move the all NTSC content down 30 pixels, you can change this to:

minfirstline = VBLANK_ENDLINE_NTSC - 30 / 2;

(you should be able to move NTSC content down by up to max 42 pixels vertically this way).

Yes! I'll do that. Thanks.

[Toni Wilen]

I think, as usual, this is display specific behavior, PAL/NTSC displays can have large tolerances, this is not digital stuff that either happens or does not happen.

It is the very first visible line, any earlier line is always blank, 100% guaranteed. Any following line _may_ be visible depending on display and display adjustments. This is not guaranteed.

UAE core will always show all possible lines, it does not attempt to emulate display tolerances etc.. (I don't think you would like to see display that slightly changes size when emulated old CRT display warms up )

[mr_a500]

Originally Posted by Toni Wilen

(I don't think you would like to see display that slightly changes size when emulated old CRT display warms up )

Actually, I'd love that. No, I'm kidding.

I know what you mean. It also depends on the monitor. I did a lot of adjustments opening my monitor and fiddling with v-height, v-pos, etc. (...so really, fiddling with positioning in FS-UAE really is a true emulation )

I moved NTSC screens down 38 pixels and now I'm happy with it.