Hi,
              *Announcement:   POWERBASIC enhancement*
    PB now initializes and operates the *Real Flat Memory Model*
  Linear 32 bit addressing of RAM > 1 megabyte without XMS handler
Under MS-DOS, an application program normally can DIRECTLY address
the possible computer RAM only up to the limit of 1 Megabyte (plus
64 K HMA area). The RAM beyond this barrier can only be accessed
with an XMS or EMS handler, and then only blocks of data can be
moved back and forth.
On an 80386 computer or better, the Flat Memory method described
here makes it possible to directly write to or read from RAM
locations beyond one megabyte, using a linear (32-bit) addressing
method without an XMS handler. This way, all implemented PB data
elements (bytes, words, strings, arrays, etc.) can be put into a
"galactic heap" of many megabytes! PowerBasic version 3.1 or
higher is needed for this.
Example (principal code):
======================== cut here ===============================
'BASIC main program
'contents of Var1% is written to FlatMem and read back to Var2%:
DECLARE SUB      FMInit     ()
DECLARE SUB      FMWriteINT (BYVAL variable%, BYVAL destination&)
DECLARE FUNCTION FMReadINT% (BYVAL source&)
$LINK "FLAT_MEM.OBJ"         'an external ASM module
FMinit                       'initialize the Flat Memory model
var1% = 12345%               'assign a value
FMWriteINT var1%, &H400000   'write it to absolute location "4 MB"
var2% = FMReadINT%(&H400000) '  and read it back from there
(similar functions for the transfer of the other PB data types are
prepared or are under work)
-----------------------------------------------------------------
;FLAT_MEM.ASM - external module for direct XMS access (the inline
;               assembler is not suited as 32 bit registers and
;               32 bit addressing is used here)
;some tricks (not detailed here) are necessary to encourage the PB
;linker not to reject this module, but finally all works well!
;assembled with Turbo Assembler Vs. 3.1
    PUBLIC     EnableFlatMem
    PUBLIC     FMWriteINT
    PUBLIC     FMReadINT
;*****************************************************************
;PowerBasic prototype:    CALL EnableFlatMem()
;*****************************************************************
;this sub first switches over to the protected mode, then makes
;some arrangements there and finally turns the machine back to
;real mode
;the code is too complex to be presented here.
;*****************************************************************
;PowerBasic prototype: CALL FMWriteINT (BYVAL variable%,_
                                        BYVAL destination&)
;*****************************************************************
 FMWriteINT:
    destination equ dword ptr ss:[bp+ 6]
    variable    equ  word ptr ss:[bp+10]
    push   bp
    mov    bp,sp
    mov    ax,variable
    xor    bx,bx
    mov    gs,bx                  ;linear address:
    mov    ebx,destination        ;    GS:EBX = destination in XMS
    mov    gs:[ebx],ax            ;write directly into XMS memory
    pop    bp                     ;(without FlatMem:  C R A S H)
    retf   6
;*****************************************************************
;PowerBasic prototype:    var% = FMReadINT (BYVAL source&)
;*****************************************************************
 FMReadINT:
    source     equ dword ptr ss:[bp+ 6]
    push   bp
    mov    bp,sp
    xor    ax,ax
    mov    gs,ax                  ;linear address:
    mov    ebx,source             ;    GS:EBX = source in XMS
    mov    ax,gs:[ebx]            ;read directly from XMS
    pop    bp                     ;(without FlatMem:  C R A S H)
    retf   4                      ;(value returned via AX)
======================= cut here ================================
Brief description of the functional principle:
After having booted MS-DOS, our 386 (or higher) CPU first runs in
pure REAL MODE, and the machine MUST stay in this mode: invoking
any memory manager (like EMM386, QUEMM or other) is NOT allowed,
because our own initialization routine (see "FMInit()" above) will
itself take over memory management (HIMEM.SYS is allowed and
proposed to be in operation, see below).
To prepare this memory management scheme, the CPU is temporarily
switched to protected mode. Here, a special "descriptor table
entry" for the FlatMem model is loaded into the CPU. This entry
defines the total (theoretically 4 gigabyte) address range in
order to represent ONE data segment with the highest read/write
access priority and with a base address of zero. Then, the CPU is
switched back to real mode WITHOUT A RESET!
The CPU is now performing a double life: on one hand, a user can
now access any physical RAM address via a 32-bit linear addressing
method. On the other hand, the classical addressing principle with
64-K segments and offset registers is still in use below 1
Megabyte (and in the HMA). All my DOS applications run error-free
with the FlatMem model, just as before. Of course, the PowerBasic
IDE is working well, too.
The FlatMem principle encompasses all RAM. That means it also
includes the regions HIMEM.SYS has reserved for e.g. SMARTDRIVE or
for a RAM disk. To avoid conflicts, a PowerBasic application
program should claim ITS FlatMem memory range by letting
HIMEM.SYS allocate and lock that memory area the program needs for
itself. Thus, HIMEM.SYS will not let anyone else interfere with
that FlatMem range. Vice versa, of course, now a PowerBasic
programmer should NOT write into ranges outside this allocated
FlatMem (e.g. not overwrite parts of the SMARTDRIVE area, although
he could do so in principal).
A somewhat strange but important thing was that the PowerBasic
linker, after lots of "ERROR 510: Invalid specification of 32 bit
alignment in module FLAT_MEM.OBJ" messages was finally willing to
accept a specially trimmed FLAT_MEM.OBJ. - And all runs well now!
(Hello PowerBasic corporation: Please do NOT change this feature
with your next PB Versions!)
The following application examples show that the FlatMem Model can
be of important practical use:
1) Fast storage of large amounts of data for later evaluation
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In my own job, measurement instruments have to be controlled to
deliver e.g. a burst of 4 megabytes of measurement results as fast
as possible via a special parallel interface card. The FlatMem
here is a very fast means not only to store this data, but also to
evaluate this data. For this, the program is not forced to move
portions of that data back below the 1 MB barrier for evaluation.
It can access the data directly inside the FlatMem range instead.
2) Graphic screen animation: storage of extra screen pages
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Several graphic screen pages can be prepared in the FlatMem and
can quickly be copied to the video RAM on demand.
3) Large data buffers for "chained" PowerBasic programs
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
If a first PowerBasic program has to CHAIN to a second one and so
forth, and if all these programs have to use a common large data
buffer, this common buffer can easily be created and directly
accessed, using the Flat Memory model.
A complete demo version with some principal sources is being
prepared
Any comments or suggestions are appreciated.
Andras
--- CrossPoint v3.11 R
---------------