The QB64 Bible (Work In Progress)

[johnno56]

As a user that is 'still' learning, I appreciate the time and effort you have put into this project so far, sure there a a couple of typo's - but hey - that's what auto-correct is for, right? The QB64 "help" has a huge quantity of commands. You have your work cut out for you. You have far more patience than I. Well done, sir. Well done!

[OldMoses]

In the beginning was SCREEN 0, before this was nothing made that was made for darkness was upon the face of the display. And there was nothing to attract the eye of man nor beast, nor potatos, nor breakfast cereals, nor fruitbats, nor.... [voiceover: skip a bit brother!]

Then didst the fingers of Steve move over the void of the keyboard, and sayeth, let there be _MEMPUT m, m.OFFSET, 65 AS _UNSIGNED _BYTE, and lo did the fingers of Steve move again upon the face of the keyboard, saying let there be _MEMPUT m, m.OFFSET + 1, 132 AS _UNSIGNED _BYTE. And then Steve rested and saw his blinking cyan 'A' and saw that it was good.

Good job with this, screen 0 is something I use for computational test beds on occasion, but I'm normally in 32 bit. Still it's thought provoking to see what's under the hood.

[Galleon]

and saw his blinking cyan 'A' and saw that it was good

Actually he just saw red...

Code: QB64: [Select]

1. DEF SEG = &HB800
2. POKE 0, 65
3. POKE 1, 132

[_vince]

Actually he just saw red...

And no disgusting _MEM!  You just put us all in our place

[SMcNeill]

Actually he just saw red...

Code: QB64: [Select]

1. DEF SEG = &HB800
2. POKE 0, 65
3. POKE 1, 132

132 is Blinking Red.   OldMoses's reference to blinking cyan comes from:

It’s honestly not!  Let me break it down for you with a quick example:  Let’s say the second byte stored in memory has a composite value of 195.  From that we now know that:
   
   Foreground Color = 195 Mod 16.  This comes out to be a value of 3.
   Background Color = 195 \ 16.  This comes out to be a value of 4.
   Blink Toggle = 195 \ 128.  This comes out to be a value of 1.  (1 says “YES, it’s blinking.”  0 says, “No, it’s not.”

So this composite value of 195 is the exact same as what we’d get with a simple color statement like the following:  COLOR 3 + 16, 4 – It’s blinking Cyan on a Red background!

Combined with the value of 65 from before, we now know what the very first character on the screen looks like – it’s a blinking cyan letter “A”, with a red background! 

195 is, indeed, blinking cyan on a red background.  ;)

[SMcNeill]

And no disgusting _MEM!  You just put us all in our place

Shush now!  Peek and Poke are such old school commands, they need to silently go the way of LET.  So much of their functionality was actually dependent on the old DOS operating system, that they're only useful for a few little things nowadays.  They're best regulated to obsoleted commands, much like us old fogies who remember them.

Besides, the lesson was about decoding (or generating) that value itself; not in how you get it from memory.  ;)

[_vince]

Shush now!  Peek and Poke are such old school commands, they need to silently go the way of LET.  So much of their functionality was actually dependent on the old DOS operating system, that they're only useful for a few little things nowadays.  They're best regulated to obsoleted commands, much like us old fogies who remember them.

Besides, the lesson was about decoding (or generating) that value itself; not in how you get it from memory.  ;)

SCREEN 0 is such an old school mode, it needs to silently go the way of LET.  It only exists on QB64 for compatability -- if you're going to use that then why not the &HB800 compatability layer?  We have OCR now.

[SMcNeill]

SCREEN 0 is such an old school mode, it needs to silently go the way of LET.  It only exists on QB64 for compatability -- if you're going to use that then why not the &HB800 compatability layer?  We have OCR now.

Honestly, why do we have a SCREEN 0?  We have an actual $CONSOLE, which is an actual terminal window, rather than an emulated graphical version of a terminal window. 

The main reason for &HB800 to silently go the way of LET is because of its limited functionality.  It's the address of Screen 0 in memory, but will it work for 32-bit screens?  PEEK and POKE were the old ways of directly accessing memory, but they're limited to specific emulated usability.  _MEM, on the other hand, works across screen modes and works with images, sound files, and variables and arrays.

It's much like advocating someone only keep a 3/8th inch wrench in their toolbox, when an adjustable wrench is available instead.  Sure, that one wrench works fine on 3/8th inch nuts, but what about everything else you'll encounter?

Learn _MEM to access SCREEN 0 memory, and you can use that knowledge for a ton of other things.  &HB800??  Not so much.  ;)

[_vince]

It's much like advocating someone only keep a 3/8th inch wrench in their toolbox, when an adjustable wrench is available instead.  Sure, that one wrench works fine on 3/8th inch nuts, but what about everything else you'll encounter?

I'm advocating working your way up to a full set of wrenches in your toolbox instead of relying on a large clunky adjustable wrench which is _MEM -- only for emergencies.  Do you require low-level byte-level access to a thing in QB64?  Perhaps there's a good reason every now and then but more than likely you were using the wrong size wrench.

[SMcNeill]

I'm advocating working your way up to a full set of wrenches in your toolbox instead of relying on a large clunky adjustable wrench which is _MEM -- only for emergencies.  Do you require low-level byte-level access to a thing in QB64?  Perhaps there's a good reason every now and then but more than likely you were using the wrong size wrench.

Thing is, you're doing the exact same "low level" access either way.

DEFSEG seg_address is the same as m = _MEMIMAGE(image), in this case.
PEEK is equivalent to _MEMGET.
POKE is equivalent to _MEMPUT.

The difference, however, is that the PEEK/POKE method only works in a much more limited scope.  You can only use it for this one specific thing, and truthfully, you'll soon forget it exists once you get used to other, more versatile, methods.  Search the forums -- how many programs make use of DEFSEG and PEEK/POKE?  How many use _MEM?

It's rather obvious that DEFSEG and PEEK/POKE have became depreciated commands.  They have limited support and an ever declining user base.  If you want to write code in the modern era, it's best to learn the contemporary methods/style, or else nobody will ever pay much attention to your work.  It's a lot like writing code that heavily utilizes GOTO instead of DO, FOR, WHILE loops...  People see it, and then they dismiss it outright.  "It's just too old skool for me!  Puhh!"

[Dimster]

Is there something between Peek/Poke and _Memget/_Memput?  If Peek/Poke zero in too finely to an area in memory, and _Memget/_Metput is to broad a cover of the entire memory are there Most Common areas of memory we access routinely? So perhaps just define a range in memory and it's just a Get/Put. That could lead to holding just the right wrench's which Vince is suggesting.

[_vince]

Is there something between Peek/Poke and _Memget/_Memput?  If Peek/Poke zero in too finely to an area in memory, and _Memget/_Metput is to broad a cover of the entire memory are there Most Common areas of memory we access routinely? So perhaps just define a range in memory and it's just a Get/Put. That could lead to holding just the right wrench's which Vince is suggesting.

PEEK and POKE are entirely meaningless and exist on a compatability layer for old dos/16-bit tricks.  _MEM is the real thing and actually works with your native memory.  Both are dirty hacks and should not be used but that's the distinction.

[SMcNeill]

Is there something between Peek/Poke and _Memget/_Memput?  If Peek/Poke zero in too finely to an area in memory, and _Memget/_Metput is to broad a cover of the entire memory are there Most Common areas of memory we access routinely? So perhaps just define a range in memory and it's just a Get/Put. That could lead to holding just the right wrench's which Vince is suggesting.

PEEK and POKE are emulated in QB64, as they tend to point to specific places in DOS memory.  In QB45, and earlier versions, they were used for direct memory access just like we now use _MEMGET and _MEMPUT.  They *used to be* direct memory access tools, untiL THE OS changed from 16 to 32 bits.  _MEM has basically replaced them for modern systems, and now they're just emulated commands which are barely supported.

Mem does tend to zero in on a specific region of memory, as you suggest.  _MEMIMAGE(image), for example, only gives access to where that one specific image is stored in memory.   _MEM(Array()) only gives access to that particular array.  _MEM(variable) only gives access to that single variables range of memory.

[QB64Curious]

Steve,

Will you leave a copy of this on your github, as it updates?

As you guys might know (if you don't, what the heck have you been doing -- hiding your head under a rock somewhere??), I've transitioned into a writer/novelist now that I've more or less officially retired here at the farm.  October to January still keeps me busy with farm life, but otherwise I've got the rest of the year free to indulge my hobbies however I want.

For ages, I've been promising, "Some day, I'm going to sit down and end up writing up some sort of overly complex and wordy manual for QB64 that everyone can laugh at and nobody will probably ever use!"

Well, I just so happen to be snowed in -- and have been snowed in for the last few weeks -- and my boredom and restlessness has now gotten to the point where I finally decided to sit down and start on this little project:  The QB64 Bible.

For now, all I've got is basically a write up about SCREEN 0 -- (and it's only about 14 pages long) -- but I hope it shows the style and format I'm shooting for here, and the information which I want to try and gather up into one easy to find and reference area.

Feel free to download it.  Study it.  Point out anything that seems unclear or imprecise, or that you just don't like, and offer any ideas of what you guys think should go into this little project.  I'm just starting on this, but if all works out, I can probably churn out a few hundred pages of nonsense by the end of the month (provided I stick with this project exclusively during that time), so at that point it might actually have enough information in it to become something that somebody, somewhere, might want to make use of sometime in the future.

Just remember:  This is a work in progress and is subject to any and all revisions, edits, changes, additions, and deletions -- at my whim and whimsey -- for the foreseeable future.

[LM]

@SMcNeill

I enjoyed reading what you have so far and I look forward to reading the upcoming chapters.  Now I understand why I couldn't get "Screen 256" to work the way I expected.  It would be great if all the functionality worked in this mode too, but at least I know it wasn't because I did something wrong.  Regarding SCREEN 0: I appreciate the deeper explanation of it that you provided. I make quite a bit of use of SCREEN 0. This mode is useful/adequate for many things when graphics are not needed.

One way I learned more about BASIC programming in my childhood/teenage years (in addition to my dad teaching me) was to study the IBM BASIC manual and read the write-up for each command/statement from A to Z. I expect that I will learn many things from reading your book. Your work on this is greatly appreciated!