SCREEN the unknown! Is there a hidden default setting for legacy SCREEN modes?

[TempodiBasic]

Hi QB64 community
I remark this strange behaviour of SCREEN statement.
It is the same for versions 1.4 -1.5-2.0-2.0.1

reading the help in IDE and the wikiHelp on web I got these affirmations about SCREEN keyword

The SCREEN mode INTEGER values available today are 0 to 2 and 7 to 13 listed below.
QB64 can use a LONG _NEWIMAGE page or _LOADIMAGE file image handle value instead.
The empty comma disables color when any value is used. DO NOT USE! Include the comma ONLY when using page flipping.
If the SCREEN mode supports pages, the active page is the page to be worked on while visual page is the one displayed.

at this link http://www.qb64.org/wiki/index.php?title=SCREEN

So please help my buggy coder brain to understand this thing showed  by following screenshot
  [ You are not allowed to view this attachment ]  

As you can see it seems OK to type SCREEN with no parameter.
This let me think that internal code for SCREEN sets automatically to SCREEN 0 if the keyword has no following parameters, is it?

Waiting your thinking....

PS
I must test this code into QBASIC.

[TempodiBasic]

More details:
I have found a QB64 v 1.3 and the behaviour about

Code: QB64: [Select]

1. Screen
2.  
3.  

is the same, no syntax checking and it is compiled and run with no issue

on the other hand, the ancient QB45 accepts that user types SCREEN and go ahead... but at runtime it claims "Illegal Function Call".

Maybe that these added informations  may be useful!

[SMcNeill]

The problem you're seeing isn't one that the IDE is going to pick up easily for you, just from what SCREEN does.

SCREEN (handle), (border), (active), (display)

SCREEN had 4 parameters and all four are optional.

SCREEN 12 sets the display to being a 640x480, 256 color screen.  (I think, if I remember right.)

SCREEN ,4 would set the border around the screen red, for SCREEN 4 or whatever old legacy CGA/EGA screen mode it was that used to have a visible border around it.

SCREEN , , 1 sets the first PCOPY image as the active write page.

SCREEN , , , 1 sets that PCOPY page 1 as the display.

These last two options is how we used to perform flicker free animations.  Draw on one, display the other...

With all four parameters being optional, exactly what is wrong with the following statement:

SCREEN

You skip all your options, so it really doesn't do anything, but it's not technically incorrect syntax.

[Cobalt]

the second option is a "colorswitch" not border.

Guessing since that option is blank in the wiki its not implemented or the person who wrote that page didn't know what it was. But here is the description from QB45.

I would have thought that using SCREEN with no options that you were resetting Apage and Vpage options to the main display? (and presumably the colorswitch too)

[TempodiBasic]

Hi Guys
thanks for bringing these different points of thinking.

The difference of behaviour between QB64 and QB45 is subtile and I'ld prefer that of QB64.
IMHO "If I do nothing I cannot waste/break nothing " is better than "If I type wrong syntax I get runtime error!".

@Cobalt
your proposal is an interesting aspect that can switch the DO NOTHING to RESET TO DEFAULT of

Code: QB64: [Select]

1. SCREEN
2.  

As we can read from QB45 help also the colorswitch must have a value (inverted for SCREEN 0) but a feature to reset to default is interesting, like for WIDTH, or COLOR, or VIEW.
I dunno how much this aspect can be interesting for experienced (games/graphic applications) coders.
As I always do, I have noticed something and I have brought at your attention it.
Nothing to add other than thank you.

[Pete]

Com'on QB-Doo
I see you
Time to help this Italian
If we can count on you
QB-Doo
I know we'll debug Galleon

Actually, QB64 brought this stuff forward from QBasic and Qbasic brought it forward from GW-Basic. The border parameter in the  SCREEN statement was originally implemented in GW-BASIC, but only for SCREEN 0 and SCREEN 1. The values were 0 and 1, however it is interesting to note in these values are reported as zero or non-zero in Qbisic. So the QBasic interpreter will accept values from 0 to 255, without erroring out. I guess in the GW-BASIC days, many monitors were still black and white. BAck then, the "colorswitch" allowed the user to set SCREEN 0 and SCREEN 1 to access a color monitor. The COLOR statement had a similar parameter for a third argument called "border." It was a value between 0 - 15. It does nothing on DOSBox emulated QB programs, but if running pure QB, I think it just allowed a user to color the window the program was running in. Anyway, neither the border nor colorswitch arguments are useful today, and are simply ignored by QB64. Even the error-out part is ignored. For instance...

This will be accepted by the QB64 IDE and will compile / run: SCREEN 0, 5125, 0, 0 but will not work in QB45 unless that second (colorwsitch) parameter is between 0 and 255.


QB🐶Doo

[SMcNeill]

the second option is a "colorswitch" not border.

Guessing since that option is blank in the wiki its not implemented or the person who wrote that page didn't know what it was. But here is the description from QB45.

I would have thought that using SCREEN with no options that you were resetting Apage and Vpage options to the main display? (and presumably the colorswitch too)

It took some digging in old manuals (going back to GW BASIC) to find this:

For both composite monitors and TVs, the colorswitch is a numeric expression that is either true (non-zero) or false (zero). A value of zero disables color and permits display of black and white images only. A nonzero value permits color. The meaning of the colorswitch argument is inverted in SCREEN mode 0.

Which just proves I'm growing senile as I get older...  I swear, at some point in my life, I was coding in a BASIC dialect where that second parameter was for the outer border color of your screen, but it was only for those pure monochrome green looking screen modes.  Set, the border was visible, at 0, the border was invisible

Of course, I also seem to remember that back in those cavemen days, we also had screen modes 3, 4, 5, and 6, but they were only for certain video cards or monitors or TVs or some such...  Digging through documentation now, I can't even find references to those modes.  They've been washed out of history it seems!

Ir's no wonder that I tend to stick exclusively with 32-bit modes anymore.  The others are all old and obsoleted like my brain, it seems.  😭

[Pete]

Yeah Steve, that's also from the GW-Basic article I was referencing...

http://www.antonis.de/qbebooks/gwbasman/screens.html

Anyways, don't feel bad, I lived through this era, but never needed to use those arguments back then. They are very obscure.

So if it helps, have a QB-Snack, and PUT it behind you!

Pete

[SMcNeill]

Com'on QB-Doo
I see you
Time to help this Italian
If we can count on you
QB-Doo
I know we'll debug Galleon

Actually, QB64 brought this stuff forward from QBasic and Qbasic brought it forward from GW-Basic. The border parameter in the  SCREEN statement was originally implemented in GW-BASIC, but only for SCREEN 0 and SCREEN 1. The values were 0 and 1, however it is interesting to note in these values are reported as zero or non-zero in Qbisic. So the QBasic interpreter will accept values from 0 to 255, without erroring out. I guess in the GW-BASIC days, many monitors were still black and white. BAck then, the "colorswitch" allowed the user to set SCREEN 0 and SCREEN 1 to access a color monitor. The COLOR statement had a similar parameter for a third argument called "border." It was a value between 0 - 15. It does nothing on DOSBox emulated QB programs, but if running pure QB, I think it just allowed a user to color the window the program was running in. Anyway, neither the border nor colorswitch arguments are useful today, and are simply ignored by QB64. Even the error-out part is ignored. For instance...

This will be accepted by the QB64 IDE and will compile / run: SCREEN 0, 5125, 0, 0 but will not work in QB45 unless that second (colorwsitch) parameter is between 0 and 255.


QB🐶Doo

You may be right Pete -- I'm getting my obsolete options screwed up across commands. 

http://www.antonis.de/qbebooks/gwbasman/color.html

Back in the day, it was COLOR with the extra switch that shaded that border.

Part of my brain still thinks SCREEN was used to toggle that border on and off, but that may have been a side-effect of dropping from a 16 color mode to a 2 color mode with the colorswitch.  (A blue border, toggled to become black or white, would go black, makingit appear invisible against the rest of the black screen.)  At least, it's a reasonable enough explanation that I don't feel like I've gone COMPLETELY crazy...

...Yet.

[SMcNeill]

Anyways, don't feel bad, I lived through this era, but never needed to use those arguments back then. They are very obscure.

People nowadays need to remember, back in those days, we seldom (if never) read documentation.  Most commands were picked up by a series of trial-and-error runs.  If that second param seemed to make the border disappear on my TV when it was used, then that's what our brains always remembered it doing...  Of course, nobody gave a crap about something like that even back then, so the main thing you remembered was, "nothing I need to worry about; it's worthless", and generally speaking that still holds true today.

Honestly, I don't think I've seen a SCREEN statement where that second parameter has been used for over 30 years.  I imagine IF you managed to dig up archaic code that used it, you'd never be able to run or understand it.  Those were the days of obscure peek/poke addresses, liberal use of GOTOs that went to a line that GOSUBed to a line that was just a GOTO, and other such insanities like all one letter variable names and such...

LOL!  How in the BLEEP did we ever code anything back then and make it work??

[Dimster]

So which came first the chicken or the egg? Was it the drastic change in monitors from  back in the day to what we have today, or was it advances in the coding languages (or perhaps advances in coders expectations) that makes that Screen parameter obsolete? 

[Pete]

Back in the early days, then most aggravating thing I can recall was the code required line numbers. That sucked... and it sucked, too. Every damn time you wanted to modify a program, you had to redo your line numbering. I used to code with 10, 20, 30, etc. so if I needed to make modifications, which only needed a few lines here and there, I could just squeeze them in as 21, 25, etc. What a pain, I remember writing a utility to renumber code. I probably ran the utility on my utility, to modify it! I also recall later making some REMLINE line remover app. Now you can make your code look 20 years younger, with my line remover formula!

You know the COLOR "border" and SCREEN "colorswitch" were so obsolete at the time QBasic was created, some popular authoritative sources didn't even bother to mention they existed!

Well, I don't miss the good for nothing days a bit. I loved programming back then, but I really appreciate how much easier it is today. I mean 4K memory, a tape recorder drive, and a 12" black and white TV for a monitor! GOTO was way over used, all SUBs and FUNCTIONs had to be declared, and you had to know every memory saving trick in the book. Still, I was able to code a fully working 4 player Monopoly game on that 4K system, with single character variables, just like Steve was talking about.

Pete

[moises1953]

I think that SCREEN does nothing.

Example:

Code: QB64: [Select]

1. SCREEN 2
2. PRINT "SCREEN"
3. SCREEN
4.  
5.  

In this case you should rescale the screen if you had set mode 0, but leave mode 2 as it was.
You can try to put SCREEN 0 in the last line.

[TempodiBasic]

@moises1953
Yes, you're right, it doesn't anything

as Steve said

The problem you're seeing isn't one that the IDE is going to pick up easily for you, just from what SCREEN does.

SCREEN (handle), (border), (active), (display)

SCREEN had 4 parameters and all four are optional.

and so I stressed the concept

The difference of behaviour between QB64 and QB45 is subtile and I'ld prefer that of QB64.
IMHO "If I do nothing I cannot waste/break nothing " is better than "If I type wrong syntax I get runtime error!".

.................
about the use of colorswitch parameter of SCREEN, it seems to be an ancient parameter got back from GWBASICA, and already at time of GWBASICA it seems to be obsolete as our hystorical mentor (Pete) let us know.

You know the COLOR "border" and SCREEN "colorswitch" were so obsolete at the time QBasic was created, some popular authoritative sources didn't even bother to mention they existed!