Using fast storage devices as swap / paging space

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
User avatar
myelin
Posts: 410
Joined: Tue Apr 26, 2016 9:17 pm
Location: San Francisco, CA, USA
Contact:

Using fast storage devices as swap / paging space

Post by myelin » Wed Mar 14, 2018 1:02 am

I've been trying to figure out how to practically write utility programs for the BBC/Electron that can be "good citizens", not trampling on working memory (the current BASIC program, filesystem space, etc), without having to execute from sideways RAM or be severely restricted memory-wise, and it occurred to me that with filesystems like MMFS that have effectively unlimited storage, it probably wouldn't be a huge speed hit to save everything from PAGE to HIMEM into a temp file, and reload it on exit.

Does anyone know of any BBC/Electron software that does this?

Or is this pointless because it's assumed that you need to save everything before running anything?
SW/EE from New Zealand, now in San Francisco, making BBC/Electron hardware projects for fun.
Most popular: fast serial port, FX2+PiTubeDirect Tube/Cartridge adapter, USB cart interface.

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Using fast storage devices as swap / paging space

Post by crj » Wed Mar 14, 2018 1:19 am

Note that the space between PAGE and HIMEM belongs to the current language, even during OS calls.

While with BASIC, you could get away with stashing it, corrupting it and restoring it, that's not true of everything. To pick just one example, under the Hybrid Music System you can and do load AMPLE modules that claim interrupts.

User avatar
jgharston
Posts: 3057
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Using fast storage devices as swap / paging space

Post by jgharston » Thu Mar 15, 2018 5:06 am

myelin wrote:I've been trying to figure out how to practically write utility programs for the BBC/Electron that can be "good citizens", not trampling on working memory (the current BASIC program, filesystem space, etc)
You own &A8-&AF for the duration of any *command, you can trash them completely, and anything else that issues a *command must assume that they are trashed.

If you claim the NMIs you can use the NMI workspace at &A0-&A7 and &D00-&D5F. After claiming NMIs you must stick RTI at &D00 to sink any spurious NMIs. Once you have finished using it you MUST relinquish it, and bear in mind that filing systems normally use this space, so you are essentially banned from making any filing system calls while using it. Note that "filing system calls" includes OSWRCH and OSRDCH.

You can create transient space on the stack with:
TSX:TXA:TAY :\ X=Y=current SP
SEC:SBC #amountwanted:BCC errNoStackSpace
TAX:TXS :\ Claim bytes on the stack
TYA:PHA :\ Push old SP
INX:LDY #1 :\ XY=>workspace on the stack
\\\ use the space here
PLA:TAX:TXS :\ Pop old SP
See thread

&F6/7 is generally usable as it is used for OSRDRM and ROMFS calls, it is often used for the string pointer with writing text.
Similarly, &F5 holds the ROM number for ROMFS calls, so is usable if not making any ROM calls. Note that many normal sideways ROM calls do use &F5/6/7 themselves (for instance, the Plus1 *FORMAT command examines the ADFS ROM before applying a bugfix, and anything that results in a string being printed may well use them).
&FD/E is used if you generate errors, see thread for PrText and MkError
If you disable IRQs you can use &FA/B as they are used for background buffer processing.
&E8/9 is the OSWORD 0 input buffer pointer, so can be used, noting that it gets trashed if you call OSWORD 0.
&B0-&BF is transient filing system workspace. Filing systems are required to never store persistant data here, and to expect it to be trashed from filing system call to filing system call, so as long as you make no filing system calls (see above) you can use this. Along with the *command space that you own, if you write your code carefully you have &A8-&BF.

I keep meaning to write this up more fully....

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Using fast storage devices as swap / paging space

Post by crj » Thu Mar 15, 2018 5:11 pm

jgharston wrote:I keep meaning to write this up more fully....
That would definitely be interesting.

One of my current bugbears is trying to rustle up enough memory for an OSWORD block when I'm a paged ROM that hasn't allocated any workspace. So far, I've not seen any better option than using the stack.

User avatar
jgharston
Posts: 3057
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Using fast storage devices as swap / paging space

Post by jgharston » Mon Mar 19, 2018 3:22 am

crj wrote:One of my current bugbears is trying to rustle up enough memory for an OSWORD block when I'm a paged ROM that hasn't allocated any workspace. So far, I've not seen any better option than using the stack.
StackWS is a simple demo of putting an OSWORD control block on the stack.

If you are gauranteed that the OSWORD call won't make a filing system call (basically, won't call anything, as even OSRDCH, OSWRCH, etc could make a filing system call) then &B0-&BF is transiently available, so 24 bytes at &A8-&BF is available. But in all cases, the stack is the safest area, as long as you don't nest it too deeply. The GoMMC/GoSDC makes a stack frame, then calls something that makes a stack frame that calls something that makes a stack frame that... I've had code only a couple of recursion levels deep that's fallen over with a stack overflow on a GoMMC/SDC OSWORD call.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Post Reply