Programatically open NTSC screen on PAL amiga

[dalton]

Hi,

I know it's possible to switch between PAL and NTSC using the BEAMCON0 register. But I want to try to do system-friendly software. Is it possible to choose when you open a screen with Intuition's `OpenScreen` whether it should be PAL or NTSC?

Cheers

[Thomas Richter]

Certainly - pick the right mode ID. The ones for PAL derive from the PAL monitor, the ones for NTSC for the NTSC monitor. The corresponding monitor masks (upper 16 bits of the 32-bit mode ID) you find in <graphics/modeid.h>, in particular

#define NTSC_MONITOR_ID                 0x00011000
#define PAL_MONITOR_ID                  0x00021000

However, a better approach would be to allow the user select a mode ID, e.g. by an ASL-ScreenMode requester.

[dalton]

Ah! Does this go in the `ViewModes` property of `struct NewScreen`?

The pixel aspect ratio is very important for my application, and it's a screen saver so a requester on start is not really an option. Maybe I can work something out with tooltypes to make the mode user-configurable.

[thomas]

ViewMode is a 16bit UWORD, it cannot hold these values.

You have to supply a TagList with the SA_DisplayID tag.

A TagList can be provided by a struct ExtNewScreen or by the use of the OpenScreenTagList function.

[Thomas Richter]

Originally Posted by dalton

The pixel aspect ratio is very important for my application, and it's a screen saver so a requester on start is not really an option. Maybe I can work something out with tooltypes to make the mode user-configurable.

The problem with a fixed monitor ID is that you do not even know whether the mode you selected is available, or if available, even displayable on the monitor of your user. For example, the user may have a VGA monitor attached to a graphics card, and 15kHz modes like NTSC may not even be visible by this monitor, or whether this is an OCS PAL machine without the ability to generate NTSC.



The best you can do is to use the same mode as the workbench (as this is clearly available and visible), and then scale the graphics of your application. Or, as said, use an ASL requester, and filter upfront by the aspect ratio. The pixel aspect ratio is included in the DisplayInfo structure, see <graphics/displayinfo.h>:

struct DisplayInfo
{
        struct  QueryHeader Header;
        UWORD   NotAvailable;   /* if NULL available, else see defines */
        ULONG   PropertyFlags;  /* Properties of this mode see defines */
        Point   Resolution;     /* ticks-per-pixel X/Y                 */
        UWORD   PixelSpeed;     /* aproximation in nanoseconds         */
        UWORD   NumStdSprites;  /* number of standard amiga sprites    */
        UWORD   PaletteRange;   /* OBSOLETE - use Red/Green/Blue bits instead */
        Point   SpriteResolution; /* std sprite ticks-per-pixel X/Y    */
        UBYTE   pad[4];         /* used internally */
        UBYTE   RedBits;        /* number of Red bits this display supports (V39) */
        UBYTE   GreenBits;      /* number of Green bits this display supports (V39) */
        UBYTE   BlueBits;       /* number of Blue bits this display supports (V39) */
        UBYTE   pad2[5];        /* find some use for this. */
        ULONG   reserved[2];    /* terminator */
};

In particular, the "Resolution" field is what you are after. It is not a "resolution", though, but a size of the pixels (larger values mean larger pixel dimensions). If Resolution.X is approximately equal to Resolution.Y, then you have approximately square pixels.


Note, however, that NTSC (lo-res, hi-res interlace) pixels are (in reality) not exactly square, even though the database says so.

[Bruce Abbott]

Originally Posted by dalton

The pixel aspect ratio is very important for my application, and it's a screen saver

Screen saver graphics are by definition not very important.

The user may not appreciate you changing the screen mode to a scan rate that their monitor cannot handle. For example I have an A600 with Vampire RTG and nothing connected to the composite or RGB ports. Furthermore my TV is set up to not scale HDMI input, and it can't handle many of the Vampire's standard scan rates, so the only safe choice is to clone the Workbench screen.

It sucks to not have control over what screen modes you can use, but that's the price we pay for having the flexibility of hardware that is not tightly controlled. Even modern PC apps can have the same problem. We bought a Hewlett Packard Tablet as a replacement for our Windows 7 laptop to run our drone app. Turned out to be useless because the tablet is stuck on a ludicrously high resolution that cannot be changed, and Windows 10 can scale text but not graphics so the buttons were too small to operate on the touch screen.

Maybe I can work something out with tooltypes to make the mode user-configurable.

Good idea. You might want to put some other options in there too. Even better would be to have the settings stored in a text file in ENV: or S:, and include a preferences editor for easy configuration via the GUI.