A bit off topic, but looking at this source code again made me think (again) about how difficult it is for a programmer to work with SAMS in terms of memory page switching, and how much more useful it would be to have higher level support in terms of arrays, for instance. For an extension to XB the basic set of commands could be expressed something like this:
CALL AMSDIM(ARR,N) // Allocate an array in AMS of (any) size N. Return reference in variable ARR.
CALL AMSGET(ARR,I,VAL) // Read entry I of array ARR into variable VAL
CALL AMSSET(ARR,I,VAL) // Set entry I of array ARR to value VAL
CALL AMSFILL(ARR,I,L,VAL) // Fill L entries of array ARR from index I with value VAL
CALL AMSCOPY(ARR1,I1,ARR2,I2,L) // Copy L entries from ARR1 index I1 to ARR2 index I2
CALL AMSFREE(ARR) // Deallocate array ARR
// Data types
CALL AMSDIM(ARR,"N",N) // number (default)
CALL AMSDIM(ARR,"S",N,M) // string (fixed length M)
CALL AMSDIM(ARR,"B",N) // byte
CALL AMSDIM(ARR,"W",N) // word
// Same as above for 2 dimensional arrays
CALL AMSDIM(ARR,N,M) // Also with data types
CALL AMSFILL(ARR,I,J,L,M,VAL) // Fill a 'rectangle' at (I,J) size (L,M)
CALL AMSCOPY(ARR1,I1,J1,ARR2,I2,J2,L,M) // Copy a 'rectangle' between arrays
The reference to an array, e.g. ARR, would be a number that should not be changed by the XB program (or the reference would be lost). The XB extension would keep track of the references and the memory allocation for each array, and would take care of operations like garbage collection (depending of how advanced the implementation would be).
Edit: The idea is, of course, that it should be possible for an array to be of any size, only limited by the size of the SAMS card.
Edited by Asmusr, Tue Feb 12, 2019 12:53 PM.