QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: SMcNeill on February 01, 2022, 03:48:46 pm
-
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.
-
page 8 of 18 .... should "with AUTOMATICALLY" be "will AUTOMATICALLY" ? That just jump out at me as I was skimming thru, so it may be exactly what you wanted there.
Looks great Steve. You have always written in a very understandable voice. Unlike the religious Bibles of our day, The QB64 Bible should never come to an end as QB64 seems to evolve rather quickly. There are so many members pushing QB to do more in just about every facet of it's syntech. Terry Ritchie's slant was on Gaming, from what I have read, your focus will be more a reference book for coders. I gather it will be more in depth than those old "For Dummies" books?
Anyway, you have a great start there, and not being a coder of game programs, I'd very much welcome this new Reference Tool Book.
-
@SMcNeill
Nicely written, it reads nicely. I'm glad you started, I'm looking forward to continuing. I also learned a few things I didn't know about before.
-
Well done, as always, Steve! Congrats on your retirement.
-
Well done, as always, Steve! Congrats on your retirement.
I've been retired for a while now. The problem is, I've just been too busy to notice it!
I don't do a lot of farming anymore, but I still have about a thousand projects going all on at the same time that I'm trying to work on and finish before I die. I just don't think I'm ever going to catch up though! By the time I end up finishing one thing, I've got six new things that I need to get around to sometime, adding to my ever-growing list of chores.
But, I guess that's just what life is all about -- work until you die. And then you just end up making work for other people!! (The poor undertakers, grave keepers, preachers, tax men...) /sigh!
-
nice work, Steve, look forward to reading more.
That OCR analogy is earth-shatteringly revelatory! You can read SCREEN 0 but SCREEN 12 and above requires a mapping of pixel clouds to symbolic characters
-
Is it much trouble to make a.pdf version?
-
Is it much trouble to make a.pdf version?
It is at this point -- for me, at least. I work in Word. Always have. It's the tool/software I'm used to using and most comfortable with, and it saves *.docx files.
When I finish working on this little project, it's simple enough to convert from docx to pdf, but it's not worth the time and effort while adding to and editing the document on a regular basis.
If there's a particular version you want converted, just pop it into an online editor and format it into whatever you want. ;)
https://smallpdf.com/word-to-pdf -- Try this one if you like.
-
Thankyou Steve.
Update: It worked.
-
@SMcNeill Unless the Senior Librarian (@bplus) objects, and he won't, we'll be putting this into the Learning Section. Just the sort of thing we want there. The Junior Librarian (@Qwerkey) will be copying it to there when finished.
-
@SMcNeill Unless the Senior Librarian (@bplus) objects, and he won't, we'll be putting this into the Learning Section. Just the sort of thing we want there. The Junior Librarian (@Qwerkey) will be copying it to there when finished.
Right and Qwerkey please refer to me as the Sexagenarian Curator.
-
Aye-aye, Sir! And I very much regret that in 12 days time I become a Septuagenarian Curator (and I'm still such a kid).
-
Curators are like bottles of wine...
-
Curators are like bottles of wine...
One loose cork away from turning into vinegary piss? 😁
-
The effort and time you're setting aside for this project is highly appreciated, Steve.
-
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!
-
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.
-
and saw his blinking cyan 'A' and saw that it was good
Actually he just saw red...
-
Actually he just saw red...
And no disgusting _MEM! You just put us all in our place
-
Actually he just saw red...
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. ;)
-
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. ;)
-
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.
-
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. ;)
-
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.
-
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!"
-
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.
-
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.
-
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.
-
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.
-
@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!
-
Updated to what I have so far with this... Progress has been much slower than I imagined, but that's life here on the farm! The last cold spell which came through this way ended up freezing a few water pipes and busting them for us, and I've spent the last few days digging up fields and replacing water lines. Had to replace a water tank, a pump, several control switches, and about 300 feet of line so far!
Current repair bill -- $2580.00, for all that!!
So why do we always hear about the government having to spend hundreds of thousands of dollars to fix a simple broken water main in the center of town??
The older I get, the more I strongly believe that we need the farmers running our government and the government employees need to just learn to pick beans on a farm! :P
Updates in this version:
Numbers and Overflow
Screen 256
Screen 32 (started, but not finished)
Changed the save file to include the date in it, so folks can easily tell how old their version is verses the current one available from the download link in the first post in this topic.
More to come as time, and life on the farm, allows. Today I've got to replace several water filters and such in the house as the broken lines let dirt and grit into my system, but this should be a one-day job. Hopefully, I can get back to working on my little bible with a little more free time starting tomorrow again. ;)
-
Small update just to prove to myself that I haven't forgotten about this project. ;)
Finished up the Screen 32 topic.
Added _BIT type into the discussion.
Next up: _FLOAT type. People bring it up all the time, so it needs a nice little bit of documentation on it. If anyone has any specific questions or ideas they'd like me to address or include when talking about _FLOAT, feel free to bring them up here.
-
@SMcNeill
My suggestion...
After a brief description, mention in detail with examples if possible, of what's wrong with it (c/f PRINT, PRINT USING, etc).
Then mention what's right with it , eg how big numbers in theory you could go (+precision), when one should always use ## (irrespective of dims, types, declare, constants, etc). how it matches up to other .,variable types (I started on the number space of _FLOAT study, for the case of integers - so one could compare to INTEGER64 values).
Maybe have some speed comparisons e.g
SINGLE vs DOUBLE vs FLOAT vs INTEGER64