OPEN "temp.txt" FOR OUTPUT AS #1 'This just opens a new file, erasing any old file with the same name. OPEN "temp.txt" FOR BINARY AS #1 'And this now opens that blank file so I can get/put information to it. text$ = "1234567890" 'a simple 10 character text string.
PUT #1, 1, text$
'which I'm now writting to the disk.
'All very common practice, and nothing strange or mysterious going on so far.
'I opened a file, I put a string into it.
'But now....
'Let's start by making certain that the file contains the data I want:
in$
= SPACE$(10) ' I want a string 10 bytes long, so I can get all 10 bytes at onceGET #1, 1, in$
'which I get from the drive PRINT in$
'and then print to see my string and make certain that I did, indeed, place string information to the drive.
SLEEP 'at this point, run the program and verify what the result is for yourself. 'Exit the program after the first pause (Where the SLEEP statement would appear), and then come back and follow the code
'as I comment it below.
'READY TO CONTINUE??
'Good!
'At this point, you can now see that we wrote a string to the drive...
'OR...
'Did we really???
'Let's test a few things:
' just the first letter of what they represent (with the exception of i64 for integer64, as i stands for integer)
GET #1, 1, b
'get a byte from the start of that file GET #1, 1, i
'get an integer from the start of that file GET #1, 1, i64
'an integer64 GET #1, 1, c
'and finish with a character
'Now surely, since we wrote the data as a string, these commands are going to fail and toss us an error. Right??
'Let's try and print them, then run it and let's see!!
PRINT c
'the character will print to the 3rd line, as it's the letter "1" and I don't want it lost in the numbers above.
SLEEP 'another pause, like before, so we can stop running the code at the proper spot as we study this example code. 'NOW, RUN THE PROGRAM AGAIN, THIS TIME STOPPING IT AT THE SECOND PAUSE (SLEEP) SEGMENT.
'Executed the code, yet?
'If so, were you shocked by the results?
'We wrote string data to the drive, but then somehow we managed to get it all back as numeric values???
'WTH is up with that??
'It's simply because it's as I was saying in my post over at the QB64 forums -- computers are much stupider than folks believe.
'All the computer does is set bits on the hard drive to be either ON or OFF, and then we GET and PUT those bits into specific
'areas of the hardrive with our OPEN and GET/PUT statement.
'OPEN defines a block of the drive that we're going to use...In this case from where "temp.txt" starts, to where "temp.txt"
'ends at. I have no real idea where the heck that segment is; I trust the open statement to find the right spot on the
'drive and then make that access available for me.
'Then, once that segment of the drive is made available, I futher specify which area of that segment that I want to interact
'with, with the GET and PUT statement.
'GET FILEHANDLE, POSITION, INFORMATION....
'Or, as we commonly see it: GET #1, 1, variable (for the first byte of that file)
'It's by defining our variable types that our computer knows how to interpet those 0 and 1 bits that we want to read/write
'to the drive.
'text$ = "1234567890" <--this tells the computer to convert those 10 characters into the 0 and 1 representations of string values.
'DIM b as _BYTE <-- this tells the computer that those 0s and 1s are going to represent an integer value from -128 to 127
'The hard drive is ONLY storing bits which are either ON or OFF (0 or 1).
'It doesn't care what we put in our files -- it doesn't know the difference between a string or a number at all.
'All our hard drive knows is "This bit here is a 0. This bit after it is a 1. The next bit is a 0. Then a 1. Another 1...."
'MEM is the *EXACT* same thing, as I'll illustrate below:
DIM M
AS _MEM 'just like that OPEN command, we're now preparing to open a segment of memory M
= _MEMNEW(10) 'in this case, I'm deciding it only needs to be 10 bytes of memory.
_MEMPUT M
, M.OFFSET
, text$
'And, if you still remember our original text$, I just put it in memory, in that memblock. in2$
= SPACE$(10) 'and here I'm setting a second in$ so I can get and print that information to the screen_MEMGET M
, M.OFFSET
, in2$
'and I just got in2$ from that spot in memory.
'Now, I don't think there's any real reason for a third SLEEP statement in this demo, so I'm just going to do as I did
'above and _MEMGET and _MEMPUT that same information into a series of variables:
_MEMGET M
, M.OFFSET
, b2
'get a byte from the start of that mem block _MEMGET M
, M.OFFSET
, i2
'an integer _MEMGET M
, M.OFFSET
, i642
'integer64 'I'm turning error checking off here, as the next line would technically toss an error for us.
'"WHY," you ask?
'Because we only have 10 bytes reserved for memory and a _FLOAT requires 32 of them. (They're a HUGE variable type.)
'You can't make a blanket from a tablecloth, and you can't make a float from 10 bytes.
'(Well, at least you can't, without tossing an error -- which I'm just blindly ignoring for this demo and which
'COULD cause some serious corruption in my program if I wasn't careful. After all, who knows what variable/data is stored
'in the bytes immediately after the 10 where my memblock is mysteriously located??)
'Lesson to take from this: ONLY USE CHECKING:OFF when you either: A) Know your code is 100% correct
'OR B) You seriously don't give a damn if you corrupt your data.
_MEMGET M
, M.OFFSET
, c2
'and finally, let's get that last character
PRINT b2
, i2
, l2
, i642
'and now print the results to the screen
'RUN AND COMPARE WHAT YOU SEE......
'.
'..
'...
'No difference in the outputs?
'Shocked??
'If so, then don't be. As I was stressing in my first video: _MEM is nothing more complex than working with a file opened
'FOR BINARY access. GET/PUT gets and puts sequences of 0s and 1s onto our hard drive.
' _MEMGET/_MEMPUT does the exact same thing, except it does it somewhere in memory.
'Now, as to whether that sequence of 0s and 1s is going to be integers, real numbers, strings, or some user-defined type
'which is a combination of all three...
'Our memory doesn't care about any of that! All it does is faithfully hold a sequence of 0s and 1s in a specific order.
'It's up to us to define how we want to interpet that sequence of 0s and 1s.
'And we do that either via how we define our variable types: DIM b AS _BYTE, i AS INTEGER
'Or we specify it specifically: _MEMPUT m, m.offset, 123 AS _BYTE
'Make sense now?
'Hopefully, the above little demo will clear up all your confusion for you.
'If not, just ask once again and let me know what/where you're lost, and I'll try and help you understand what's going on. ;)