VIRTUAL arrays with DEF SEG, VARSEG, VARPTR, PEEK$

[Davide Vecchi]

I have to save to file and load from file a VIRTUAL array (single or double precision). I think i can' t use BLOAD and BSAVE because BSAVE is limited to 64K. So i' m now using DEF SEG, VARSEG, VARPTR, PEEK$ for the first time, and i' m wondering whether there is some known problem or special need in using these statements with VIRTUAL arrays.

Thanks in advance.

Davide Vecchi

[Lance Edmonds]

Because all elements of VIRTUAL (EMS) arrays are accessed through the EMS page-frame, unless the array occupies < 16K of EMS (a single page) , the whole array is not "visible" to the application code at the same instant. There are other minor complications with the page frame but essentially, it's not possible to perform a load/save of an entire VIRTUAL array in a single action, such as with BSAVE/BLOAD.

The easiest way to achieve your goal is to simply open a copy the array into conventional memory space (ie, into a conventional memory space), and then write the data to disk from there.

Alternatively, write the array subscripts into a disk file one by one.

While neither option that I've suggested is "fast", both techniques can be used to get the job done.


-------------
Lance
PowerBASIC Support
( mailto:[email protected][email protected]</A> )

[Michael Mattias]

The bottom line is that operations which access memory directly - BSAVE/BLOAD, PEEK/POKE, pointers, Unions - cannot be used with VIRTUAL arrays.

MCM

[Davide Vecchi]

Michael, what you remind is very important to me, thanks; i imagine that not even DEF SEG, VARSEG, VARPTR can' t be used with VIRTUAL arrays at all, since (i think) they access memory directely. Hours saved. Thanks.

Davide Vecchi
[email protected]

-------------

[Emanuele Colombo]

Che ne dici di parlare in lingua cristiana di PB?
Programmo con PB DOS da molti anni, ma ho sempre bisogno di aiuto.
Ciao.

[Davide Vecchi]

Emanuele, we can mail each other in Italian language without any problem, but here is due writing in English, since they guest the forums here for the benefit of everybody.
For me is very positive having direct contacts with experienced PB programmers, and i often get bonuses from external helps. Mail me when you want!

Bye.

Davide
---------------
Emanuele, io e te possiamo mailarci tranquillamente in Italiano, ma qua bisogna scrivere in Inglese, in quanto qua ospitano i forum a beneficio di tutti.
Per me è molto positivo avere contatti diretti con programmatori PB esperti, e anch' io traggo spesso giovamento da aiuti esterni. Mailami quando vuoi!.

Ciao.

Davide
[email protected]

[G Grant]

If you're still interested, I've posted a couple of functions in the source
code section that work very much like BLOAD and BSAVE for virtual arrays.
If you decide to try them, let me know if they work for you, or if you have
any problems with them.

[Davide Vecchi]

G, i just saved your posted code; i tink i' m not going to try it soon, because at that time when i was needing to save virtual arrays, i went for EMS instead of disk and found that it was large enough for the current customer needs. When their needs will grow (and they will), i won' t miss to try your code and post any feedback. Thank you very much for the moment.

Davide Vecchi
hs[email protected]

[Hans Ruegg]

VARSEG and VARPTR for VIRTUAL arrays:

Yes, I think you *can* use VARSEG and VARPTR for VIRTUAL arrays,
if you know how to do it. This is what I found by experimentation:
When you call VARSEG or VARPTR for an element of a VIRTUAL array,
the 16k memory page which contains the referred element is
automatically mapped onto the predefined page frame in conventional
memory. VARSEG will then give the segment address of that page frame,
which is always the same (in my experiments it was always &HD000; it
may be a different value according to your system's memory
configuration). VARPTR will give the offset of the referred array
element within this segment. You can then PEEK and POKE directly to
all array elements located in the same 16k page.
To give an example:

DIM VIRTUAL a(100000) AS BYTE
segm?? = VARSEG(a(17384))
offset?? = VARPTR(a(17384)) 'offset?? will be 1000 because a?(17384)
'is located in the second 16k page at
'offset 1000 (16384+1000=17384).
DEF SEG = segm??
b? = PEEK(0) 'b? will contain the value of a?(16384)
POKE 2000, b? 'the value of b? will be POKEd into a?(18384)
'because 16384+2000=18384
'or you could save the entire 16k page in a temporary string buffer:
TempBuf$ = PEEK$(VARPTR(a(16384)), 16384)
DEF SEG

I suppose you could also use BLOAD and BSAVE, as long as you do not
cross the border of a 16k page.
I have had no problems so far with using VARPTR and VARSEG in this
way. If anybody found a reason why it would not be safe to do so,
please inform me.

Hans Ruegg.

[Walt Decker]

Would it not be possible to set a 32bit pointer to the virtual array instead of using DEF SEG, VARSEG, and VARPTR?



------------------

[Hans Ruegg]

Walt,

yes, as far as I see it is possible to use pointers, with the same
restrictions that apply to the use of VARPTR, PEEK, POKE, etc.
(You may try it out!) I just wondered why use them. If I want to
access a single array element, I can do it the "normal" way. If
I want to move or copy a large number of elements, PEEK$/POKE$
is much faster than any operation with pointers (which would
necessarily involve a DO...LOOP or FOR...NEXT block with many iterations,
which slows the process down, while PEEK$/POKE$ does not involve
this kind of loop.)

Hans Ruegg