glmwc@marlin.jcu.edu.au (Matt Crowd) (12/17/90)
Hi, I have a couple of questions...
1) How does one get the 2.0 standard file requestor to appear on your
own custom screen? I have it appearing on workbench at the moment.
Example code would be nice!
2) What happens if a PAL picture is loaded into a NTSC machine? Does
the picture cut off at the 200 line mark? There is a bug in my machine
that causes it to boot sometimes in NTSC instead of PAL, and on one
of the occasions it did, I loaded a PAL picture. The picture extended
down past the 200 line mark (maybe 20 lines or so), even though the
mouse could not be moved below the 200 line mark. Is this what happens
on a _real_ NTSC machine?
3) Is the OS supported solution to determine whether a program is
running on NTSC or PAL -
if(GfxBase->DisplayModes & PAL)
printf("PAL\n");
else
printf("NTSC\n");
(I might have meant DisplayFlags here, I don't have the code here, that
is from memory!)
Will this work on NTSC machines that are running PAL under 2.0?
Thanks in advance! I'm sure I would know the answer to these questions
if I were a developer, but C= Aust. won't let people programming any
kind of game (even an OS friendly adventure) become a developer...
--
Matt Crowd
Email Address glmwc@marlin.jcu.edu.aupeter@cbmvax.commodore.com (Peter Cherna) (12/19/90)
In article <1990Dec17.033055.3516@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >Hi, I have a couple of questions... > >1) How does one get the 2.0 standard file requestor to appear on your >own custom screen? I have it appearing on workbench at the moment. >Example code would be nice! use the {ASL_Window, mywindow} tagitem-pair when calling AslRequest() or AllocAslRequest(). The requester will appear on your window's screen. >2) What happens if a PAL picture is loaded into a NTSC machine? Does >the picture cut off at the 200 line mark? There is a bug in my machine >that causes it to boot sometimes in NTSC instead of PAL, and on one >of the occasions it did, I loaded a PAL picture. The picture extended >down past the 200 line mark (maybe 20 lines or so), even though the >mouse could not be moved below the 200 line mark. Is this what happens >on a _real_ NTSC machine? Remember that the IFF-viewer is opening the screen based on its understanding of the picture's mode. A 2.0-aware program can very easily open a PAL or NTSC screen depending on what' appropriate. If you just say "give me hires" or "give me hires-lace", etc., you'll get a screen whose size depends on whether the machine is jumpered to NTSC or PAL (or fixed to NTSC or PAL for older Amigas). What happens depends on the software in question. I think our Display program knows everything there is about modes a picture was saved in. You can use ScreenMode to change your Workbench to either PAL or NTSC. (Note that your machine is still PAL even if the Workbench is in NTSC). We know of no bugs that cause a PAL machine to boot as NTSC. Do you have a hardware problem? I wonder what would happen if the NTSC/PAL jumper was loose or missing. Check the jumper which is just adjacent to Agnus. I don't know the jumper number, but on later motherboards, it's labelled "PAL/NTSC". >3) Is the OS supported solution to determine whether a program is >running on NTSC or PAL - > > if(GfxBase->DisplayModes & PAL) > printf("PAL\n"); > else > printf("NTSC\n"); Depends for what use. Some programs may try to jam this flag to change the "type" of machine (not a supported concept). In general, this bit should reflect the hard-state of the machine, i.e. whether it was born or jumpered NTSC or PAL. Under 2.0, to be more precise you can GetDisplayInfoData() on any basic mode, like HIRES_KEY, and check the DisplayInfo.PropertyFlags DIPF_IS_PAL bit. >Will this work on NTSC machines that are running PAL under 2.0? NTSC machines with PAL workbenches are still NTSC machines. They should normally report "ntsc" through any correct test. If you use GetScreenData() to learn about the Workbench, this call may lie about the Workbench screen if it's at all unusual. NTSC machines will report NTSC Workbenches, and PAL machines will report PAL Workbenches. (The reasons for all this lying are involved.) Under 2.0, use LockPubScreen() to figure out the true dimensions and mode of a screen. > >-- >Matt Crowd >Email Address glmwc@marlin.jcu.edu.au Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
jesup@cbmvax.commodore.com (Randell Jesup) (12/19/90)
In article <16641@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >is in NTSC). We know of no bugs that cause a PAL machine to boot >as NTSC. Do you have a hardware problem? I wonder what would happen >if the NTSC/PAL jumper was loose or missing. Check the jumper which >is just adjacent to Agnus. I don't know the jumper number, but on >later motherboards, it's labelled "PAL/NTSC". That's true under 2.0, but under 1.3 about 1/20th of the time (I think) a PAL machine boots up in NTSC mode. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
glmwc@marlin.jcu.edu.au (Matt Crowd) (12/19/90)
In article <16641@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <1990Dec17.033055.3516@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >>1) How does one get the 2.0 standard file requestor to appear on your >>own custom screen? I have it appearing on workbench at the moment. >>Example code would be nice! > >use the {ASL_Window, mywindow} tagitem-pair when calling AslRequest() or >AllocAslRequest(). The requester will appear on your window's screen. Thanks. >>2) What happens if a PAL picture is loaded into a NTSC machine? Does >>the picture cut off at the 200 line mark? There is a bug in my machine >>that causes it to boot sometimes in NTSC instead of PAL, and on one >>of the occasions it did, I loaded a PAL picture. The picture extended >>down past the 200 line mark (maybe 20 lines or so), even though the >>mouse could not be moved below the 200 line mark. Is this what happens >>on a _real_ NTSC machine? > >Remember that the IFF-viewer is opening the screen based on its >understanding of the picture's mode. A 2.0-aware program can >very easily open a PAL or NTSC screen depending on what' appropriate. >If you just say "give me hires" or "give me hires-lace", etc., you'll >get a screen whose size depends on whether the machine is jumpered >to NTSC or PAL (or fixed to NTSC or PAL for older Amigas). Sorry but this program must run on 1.2|1.3 as well as 2.0+. Support for the 2.0 file requester is given if the machine IS running under 2.0 >We know of no bugs that cause a PAL machine to boot >as NTSC. Do you have a hardware problem? I wonder what would happen >if the NTSC/PAL jumper was loose or missing. Check the jumper which >is just adjacent to Agnus. I don't know the jumper number, but on >later motherboards, it's labelled "PAL/NTSC". I'll check this out. I don't think the problem is confined to me over here though. It only does this sometimes and I just reboot and it is alright. NB: it hasn't happened under 2.0 yet... >>3) Is the OS supported solution to determine whether a program is >>running on NTSC or PAL - >> >> if(GfxBase->DisplayModes & PAL) >> printf("PAL\n"); >> else >> printf("NTSC\n"); > >Depends for what use. Some programs may try to jam this flag to >change the "type" of machine (not a supported concept). In general, >this bit should reflect the hard-state of the machine, i.e. whether >it was born or jumpered NTSC or PAL. No, I just want to determine NTSC or PAL, not change it. >Under 2.0, to be more precise you can GetDisplayInfoData() on any basic >mode, like HIRES_KEY, and check the DisplayInfo.PropertyFlags DIPF_IS_PAL >bit. Can't really use 2.0 calls, the only reason I have 2.0 at all is because a 3000 owner up here sent to C= asking for the latest version and they sent him the developer disk! I have been trying to work things out from the includes/examples... >NTSC machines with PAL workbenches are still NTSC machines. They >should normally report "ntsc" through any correct test. > >If you use GetScreenData() to learn about the Workbench, this call >may lie about the Workbench screen if it's at all unusual. NTSC >machines will report NTSC Workbenches, and PAL machines will report >PAL Workbenches. (The reasons for all this lying are involved.) >Under 2.0, use LockPubScreen() to figure out the true dimensions and >mode of a screen. All I really want to do is have the program open it's own screen which is 200 lines high in NTSC or 256 in PAL. It seems that the DisplayFlag method is correct from your reply. Thanks. >-- > Peter Cherna, Software Engineer, Commodore-Amiga, Inc. > {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com >My opinions do not necessarily represent the opinions of my employer. >"Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!" -- Matt Crowd Amiga Man Email Address glmwc@marlin.jcu.edu.au
peter@cbmvax.commodore.com (Peter Cherna) (12/20/90)
In article <1990Dec19.094324.3621@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes: >In article <16641@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >>We know of no bugs that cause a PAL machine to boot >>as NTSC. To clarify: there are no such bugs under 2.0. From time to time under 1.2 or 1.3, a PAL machine does boot into NTSC. Sorry if I misled anybody. >All I really want to do is have the program open it's own screen >which is 200 lines high in NTSC or 256 in PAL. It seems that the >DisplayFlag method is correct from your reply. Thanks. Instead of setting NewScreen.Height to 200 or 256, use the special STDSCREENHEIGHT constant, which will make you open up to 200 or 256, depending on whether you're NTSC or PAL. Under 2.0, you will also get the overscanned height, if the user has adjusted his TextOverscan rectangle. >-- >Matt Crowd Amiga Man >Email Address glmwc@marlin.jcu.edu.au Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
jnmoyne@lbl.gov (Jean-Noel MOYNE) (12/20/90)
Maybe what the original question was: what happens on the screen of
the NTSC user when the program opens a screen in PAL mode. Well it's
simple, to experiment it yourself, open a non interlaced screen of 256+56
lines high, you'll get an overscan screen, and miss a part of it .. but
it's harmless.
This 1.2/1.3 bug is harmless too, but rather annoying, because since
the original CLI window opens only with 200 lines, you can't see it until
you've done all your startup-sequence and so ... when you're using
floppies the reboot time beeing long, you don't like it. The best fix
against it is to write a small program: test the flag in GfxBase, and if
it's not PAL reset the machine, and the place this program at the
beginning of the startup-sequence.
One funny thing I noticed: when you're on a PAL machine which has
booted in NTSC mode, if you open and display a PAL picture, you can see
that the Amiga opens the screen less than 256 lines, it opens it high
enough for what it thinks is more than overscan and stops here. (i.e.
it'll open something like 240 lines ... maybe 232 (or 232+1 (-:)
JNM
--
These are my own ideas (not LBL's)
jnmoyne@lbl.gov ... but it's allready written at the top of this.