A memblock is a block of memory. The amount of memory that it represents is counted in bytes. A byte is an 8 bit number in the range of 0 to 255 . When you combine multiple bytes, they become new representations of numeric values.
A number that is the combination of 2 bytes, i.e. a 16 bit number, is called a WORD. 4 bytes - 32 bits, is called a DWORD (double WORD). A FLOAT is also made up of 4 bytes. BYTE, WORD, DWORD, and FLOAT are known as data types. There are other data types that you'll encounter in DBC:
REAL same as FLOAT
LONG a 4 byte signed whole number
INTEGER same as LONG
STRING same as BYTE except up to 255 bytes strung together and only interchangeable through the use of CHR$() and ASC()
DWORD this is actually an unsigned LONG. That means it's only the positive values of a DBC INTEGER
Once a memblock is created of a particular size, you access and write data to it by reading or filling the bytes with values.
The data type of the value you read or write determines how many bytes are read or written at a time. To read values from the memblock you use
value=memblock byte(<mem num>,0 based position)
value=memblock word(<mem num>,0 based position)
value=memblock dword(<mem num>,0 based position)
value=memblock float(<mem num>,0 based position)
The positions in a memblock are the byte positions of the memory. The first position is 0. The next position is 1 and etc. where each position represents a single byte of memory. So if you were to read a float or a dword out of a memblock, you would always advance the position by 4 bytes. The first dword would be located at 0, the second dword at 4, the third at 8 and so on.
Values/information can be stored in any order in a memblock. You could have bytes, followed by words, followed by bytes, then floats, then dwords, etc. It's important to know what data type you are looking for or writing so that you access the correct position.
To write values to a memblock you use:
write memblock byte <mem number>,<position>,<value>
write memblock word <mem number>,<position>,<value>
write memblock dword <mem number>,<position>,<value>
write memblock float <mem number>,<position>,<value>
Since the first position is 0, that means the last memory space is the size of the memblock-1.
So, if I create a memblock 4 bytes long:
make memblock 1,4
The byte positions range from 0 to 3. If I try to access position 4, DBC will probably complain and not allow it; but even worse, I could crash the computer because I might be access memory that's reserved for some thing else.
That's where you have to be careful! It's completely legal to do something like:
write memblock dword 1,3,90000
Which translates to: write the dword value 90000 at position 3 in memblock 1. DBC wouldn't complain in this instance because I'm only directly accessing position 3 but indirectly accessing 3 bytes beyond it.
This could really blow things up because a DWORD is 4 bytes long and position 3 is the last byte of the memblock I created. But it would try and write the value to positions 3,4,5,6. And 4,5,6 could be memory for anything!
As long as you are careful with the use of memblocks, they can be great tools. You can create your own array types, your own storage formats, your own user defined types, and the list goes on. They are especially useful for manipulating the color data for images and bitmaps as well as the mesh data for objects.
The real power comes in using them with DLLs. DBC will return the pointer to a memblock with the command get memblock ptr(mem number). The pointer is the actual memory address that the operating system can recognize as the 'location' of the allocated memory. You can pass this pointer to a DLL so that the DLL can use the information to whatever extent.
For example, you could have your own matrix or terrain function in a DLL and you could pass a pointer to a memblock to the DLL. The DLL could create the terrain or matrix and update the information in the memblock in the form of a mesh that the pointer references. From the memblock you could create a terrain object to use with DBC as large as memory would allow. So instead of a 70 x 70 grid size limit for a matrix, you could create one that's say 120 x 120 and because it's done in a DLL, it would be done very quickly.
The possibilites are really up to your imagination.
Enjoy your day.