Below page free space (DFS)

bbc micro/electron/atom/risc os coding queries and routines
Post Reply
AJW
Posts: 906
Joined: Sun Feb 15, 2004 2:01 pm
Contact:

Below page free space (DFS)

Post by AJW » Sat May 09, 2020 3:35 pm

Apart from &b00 to &c00 assuming no soft keys and user defined chars what other spaces can you use? &a00 if no tape use?
Assuming my programme uses no data files or data is *loaded before loading the program can I also use the below?

: PAGE 19 (&13) : DFS or USER workspace 1300-13FF Second file buffer : Programs which do not use more than one data-file may use this space PAGE 20 (&14) : DFS or USER workspace 1400-14FF Third file buffer : Programs which do not use more than two data-files may use this space PAGE 21 (&15) : DFS or USER workspace 1500-15FF Fourth file buffer : Programs which do not use more than three data-files may use this space PAGE 22 (&16) : DFS or USER workspace 1600-16FF Fifth file buffer : Programs which do not use more than four data files may use this space


That's almost 2K freed up. Any other significant chunks of memory?

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Sat May 09, 2020 4:28 pm

AJW wrote:
Sat May 09, 2020 3:35 pm
Assuming my programme uses no data files or data is *loaded before loading the program
Assuming it's a BASIC program, I think you should be able to set PAGE to &1100 if you're not opening files with OPENIN or OPENOUT:
:idea:

User avatar
tricky
Posts: 4676
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: Below page free space (DFS)

Post by tricky » Sat May 09, 2020 4:44 pm

I think you might have to CLOSE #0 in !BOOT if you are *EXECing it (e.g. SHIFT-BREAK).

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Sat May 09, 2020 4:49 pm

tricky wrote:
Sat May 09, 2020 4:44 pm
I think you might have to CLOSE #0 in !BOOT if you are *EXECing it (e.g. SHIFT-BREAK).
Good point! Here's the standard !BOOT as used on all the DFS .SSDs on bbcmicro.co.uk:

Code: Select all

*BASIC
*FX21,0
CLOSE#0:CHAIN "PROGRAM"
I suppose you could add "PAGE=&1100:" between the "CLOSE#0:" and the "CHAIN".

:idea:

User avatar
vanekp
Posts: 907
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: Below page free space (DFS)

Post by vanekp » Sat May 09, 2020 5:57 pm

&0900 &0A00 are used by tape RS423 and Envelope storage, normal tape uses space in page &0300 to load save files, page &0C00 for fonts so you can use page &0900 to &0Cff if you use none of the above.

for more details look at the advanced users guide section 11 Memory usage.
Peter.

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Sat May 09, 2020 7:21 pm

vanekp wrote:
Sat May 09, 2020 5:57 pm
for more details look at the advanced users guide section 11 Memory usage.
See also:
:idea:

AJW
Posts: 906
Joined: Sun Feb 15, 2004 2:01 pm
Contact:

Re: Below page free space (DFS)

Post by AJW » Sun May 10, 2020 4:37 pm

Would page &0D be available assuming I'm not using any ROMs or SRAM for the program?

Incidentally, setting PAGE to 1300 causes "bad program".

Also, what are pages &17 and &18 used as?

User avatar
jgharston
Posts: 4121
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Below page free space (DFS)

Post by jgharston » Sun May 10, 2020 5:54 pm

lurkio wrote:
Sat May 09, 2020 4:49 pm
Good point! Here's the standard !BOOT as used on all the DFS .SSDs on bbcmicro.co.uk:

Code: Select all

*BASIC
*FX21,0
CLOSE#0:CHAIN "PROGRAM"
That runs headlong into the "CLOSE#0 forgets to close the EXEC handle" bug. What you need is
OSCLI "EXEC":CHAIN "PROGRAM"
or make the very first line of PROGRAM
1*EXEC
AJW wrote:
Sun May 10, 2020 4:37 pm
Would page &0D be available assuming I'm not using any ROMs or SRAM for the program?
No, as you'd be trampling on the NMI code and the extended vectors.
AJW wrote:
Sun May 10, 2020 4:37 pm
Also, what are pages &17 and &18 used as?
&1700 is a copy of DFS's workspace when DFS doesn't own the fixed workspace, &1800 is used as the *BUILD input buffer. (That's assuming DFS is the highest priority ROM claiming workspace.) DFS 1.22 is tweeked to use stack space for *BUILD and so in a DFS-only machine drops PAGE to &1800.

Code: Select all

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

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Sun May 10, 2020 6:30 pm

jgharston wrote:
Sun May 10, 2020 5:54 pm
lurkio wrote:
Sat May 09, 2020 4:49 pm
Here's the standard !BOOT as used on all the DFS .SSDs on bbcmicro.co.uk:

Code: Select all

*BASIC
*FX21,0
CLOSE#0:CHAIN "PROGRAM"
That runs headlong into the "CLOSE#0 forgets to close the EXEC handle" bug. What you need is
OSCLI "EXEC":CHAIN "PROGRAM"
or make the very first line of PROGRAM
1*EXEC
What are the practical effects of that bug? It doesn't seem to have caused any problems with any of the games on bbcmicro.co.uk so far.

:?:

EDIT: The following program behaves in the same way whether the !BOOT uses OSCLI"EXEC" or CLOSE#0 (but it behaves differently when the !BOOT uses neither):

Code: Select all

10 ONERROR CLOSE#0:PRINT'"Error opening file ";I':END
20 FORI=1TO20
30 F=OPENOUT("FILE"+STR$I)
40 PRINT"Opened file ";I
50 NEXT
Also see below.
Last edited by lurkio on Mon May 11, 2020 11:37 am, edited 1 time in total.

tom_seddon
Posts: 426
Joined: Tue Aug 30, 2005 12:42 am
Contact:

Re: Below page free space (DFS)

Post by tom_seddon » Mon May 11, 2020 2:05 am

I had this problem in early versions of BeebLink: my code didn't explicitly close the EXEC file handle with OSBYTE $77 in response to a CLOSE#0. So the EXEC file handle got closed, but as far as the OS was concerned, it was still open. Most stuff worked fine, but Magic Mushrooms produced a "Channel" error: https://github.com/tom-seddon/beeblink/issues/21

I'm not sure there's a problem doing a CLOSE#0 from inside !BOOT, though of course the EXECing will stop after that line. Are there any extant filing systems that get this wrong? I'd consider this a bug in the filing system if it doesn't behave properly.

--Tom

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Mon May 11, 2020 2:38 am

tom_seddon wrote:
Mon May 11, 2020 2:05 am
I'm not sure there's a problem doing a CLOSE#0 from inside !BOOT, though of course the EXECing will stop after that line. Are there any extant filing systems that get this wrong? I'd consider this a bug in the filing system if it doesn't behave properly.
Dunno if you'd call it "extant" exactly, but it looks like the bug might be present in the Master 128 1770 DFS, in v2.24 and possibly also in later versions:
:?:

EDIT: But see below.
Last edited by lurkio on Mon May 11, 2020 11:57 am, edited 1 time in total.

AJW
Posts: 906
Joined: Sun Feb 15, 2004 2:01 pm
Contact:

Re: Below page free space (DFS)

Post by AJW » Mon May 11, 2020 9:33 am

8)
jgharston wrote:
Sun May 10, 2020 5:54 pm
lurkio wrote:
Sat May 09, 2020 4:49 pm
Good point! Here's the standard !BOOT as used on all the DFS .SSDs on bbcmicro.co.uk:

Code: Select all

*BASIC
*FX21,0
CLOSE#0:CHAIN "PROGRAM"
That runs headlong into the "CLOSE#0 forgets to close the EXEC handle" bug. What you need is
OSCLI "EXEC":CHAIN "PROGRAM"
or make the very first line of PROGRAM
1*EXEC
AJW wrote:
Sun May 10, 2020 4:37 pm
Would page &0D be available assuming I'm not using any ROMs or SRAM for the program?
No, as you'd be trampling on the NMI code and the extended vectors.
AJW wrote:
Sun May 10, 2020 4:37 pm
Also, what are pages &17 and &18 used as?
&1700 is a copy of DFS's workspace when DFS doesn't own the fixed workspace, &1800 is used as the *BUILD input buffer. (That's assuming DFS is the highest priority ROM claiming workspace.) DFS 1.22 is tweeked to use stack space for *BUILD and so in a DFS-only machine drops PAGE to &1800.
So if a user has another ROM as well as DFS then DFS could be using &1700?

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Mon May 11, 2020 11:30 am

lurkio wrote:
Mon May 11, 2020 2:38 am
tom_seddon wrote:
Mon May 11, 2020 2:05 am
I'm not sure there's a problem doing a CLOSE#0 from inside !BOOT, though of course the EXECing will stop after that line. Are there any extant filing systems that get this wrong? I'd consider this a bug in the filing system if it doesn't behave properly.
Dunno if you'd call it "extant" exactly, but it looks like the bug might be present in the Master 128 1770 DFS, in v2.24 and possibly also in later versions: http://mdfs.net/System/ROMs/Filing/Disk/Acorn/DFS.txt
Actually, even on Master DFS 2.24 my test program above seems to behave in the same way whether the !BOOT uses CLOSE#0 or OSCLI"EXEC"!

:?:

User avatar
jgharston
Posts: 4121
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Below page free space (DFS)

Post by jgharston » Mon May 11, 2020 5:13 pm

lurkio wrote:
Sun May 10, 2020 6:30 pm
jgharston wrote:
Sun May 10, 2020 5:54 pm
That runs headlong into the "CLOSE#0 forgets to close the EXEC handle" bug. What you need is
OSCLI "EXEC":CHAIN "PROGRAM"
or make the very first line of PROGRAM
1*EXEC
What are the practical effects of that bug? It doesn't seem to have caused any problems with any of the games on bbcmicro.co.uk so far.
It caused much hair-tearing in the mid-1980 when I first used a Master until I realised what was going on.
!BOOT:
*BASIC
CHAIN "FRED"

FRED:
10CLOSE#0:INPUT "Select: "A$

BANG!
The EXEC file is only closed when the the OSRDCH handler sees EXEC_CHN<>0, does a BGET from it, and gets an EOF. So, when FRED starts running, !BOOT is still open until the first call to OSRDCH to close it. (1)

At the first OSRDCH after the CLOSE#0 (within the INPUT) the OSRDCH handler sees EXEC_CHN<>0 so does BGET#EXEC_CHN, the DFS gets a BGET on a closed channel and bombs out with Channel.

Changing FRED to:
5*EXEC
10INPUT "Select: "A$

fixes it, as *EXEC does IF EXEC_CHN<>0 THEN TMP=EXEC_CHN:EXEC_CHN=0:CLOSE#TMP
whereas DFS 2.24's CLOSE#0 just does CLOSE and neglects to tell the MOS that it's closed the MOS's EXEC file.

(1)This impacted some code being discussed in the Vitrual ABUG meeting a couple of weeks ago, a custom filing system only had one channel, the chained program strted by doing OPENIN and promptly bombed out running out of channels - because !BOOT was still open as the program had not yet done anything that would have closed it, such as prompting for user input or using *EXEC.

Code: Select all

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

User avatar
jgharston
Posts: 4121
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Below page free space (DFS)

Post by jgharston » Mon May 11, 2020 5:27 pm

AJW wrote:
Mon May 11, 2020 9:33 am
So if a user has another ROM as well as DFS then DFS could be using &1700?
The private workspace gets claimed by ROMs in the order that the ROMs are called, after the size of the shared workspace has been claimed.

So, if all ROMs have agreed that &1700 is the maximum amount of shared workspace needed, then the highest ROM will claim private workspace at &1700, the next ROM will claim workspace higher than there, the next ROM higher than there.

For instance, if you have:
ROM 15 FRED needs 2 pages of shared workspace, 1 page of private workspace
ROM 14 DFS needs 9 pages of shared workspace, 2 pages of private workspace
ROM 13 BILL needs 0 pages of shared workspace, 2 pages of private workspace

The MOS asks how much shared workspace the ROMs need. The maximum is DFS's 9 pages, so the shared workspace ends at &E00+&900 = &1700.
The MOS then asks the ROMs to claim private workspace.
FRED is called and told available workspace is at &1700, do you need any?
FRED wants 1 page, remembers it's at &1700, adds its needs and passes &1800 back to the MOS.
DFS is called and told available workspace is at &1800, do you need any?
DFS wants 2 pages, remembers it's at &1800, adds its needs and passes &1A00 back to the MOS.
BILL is called and told available workspace is at &1A00, do you need any?
BILL wants 2 pages, remembers it's at &1A00, adds its needs and passes &1C00 back to the MOS.
The MOS sets the bottom of user memory to &1C00.
When BASIC starts it sets PAGE to the bottom of user memory, which has been set to &1C00.

FRED's private workspace is at &1700
DFS's private workspace is at &1800 and &1900
BILL's private workspace is at &1A00 and &1B00

If you swap FRED and DFS, then DFS's private workspace will be at &1700 and &1800 and FRED's will be at &1900.

Code: Select all

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

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Mon May 11, 2020 5:35 pm

jgharston wrote:
Mon May 11, 2020 5:13 pm
It caused much hair-tearing in the mid-1980 when I first used a Master until I realised what was going on.
!BOOT:
*BASIC
CHAIN "FRED"

FRED:
10CLOSE#0:INPUT "Select: "A$

BANG!
The EXEC file is only closed when the the OSRDCH handler sees EXEC_CHN<>0, does a BGET from it, and gets an EOF. So, when FRED starts running, !BOOT is still open until the first call to OSRDCH to close it. (1)

At the first OSRDCH after the CLOSE#0 (within the INPUT) the OSRDCH handler sees EXEC_CHN<>0 so does BGET#EXEC_CHN, the DFS gets a BGET on a closed channel and bombs out with Channel.
I can't reproduce that error with JSBeeb's Master config, which reports that it's using DFS 2.24:

Nor can I see any difference between the behaviour of CLOSE#0 and that of OSCLI"EXEC" in relation to my test program above.

:?:

AJW
Posts: 906
Joined: Sun Feb 15, 2004 2:01 pm
Contact:

Re: Below page free space (DFS)

Post by AJW » Mon May 11, 2020 7:17 pm

jgharston wrote:
Mon May 11, 2020 5:27 pm
AJW wrote:
Mon May 11, 2020 9:33 am
So if a user has another ROM as well as DFS then DFS could be using &1700?
The private workspace gets claimed by ROMs in the order that the ROMs are called, after the size of the shared workspace has been claimed.

So, if all ROMs have agreed that &1700 is the maximum amount of shared workspace needed, then the highest ROM will claim private workspace at &1700, the next ROM will claim workspace higher than there, the next ROM higher than there.

For instance, if you have:
ROM 15 FRED needs 2 pages of shared workspace, 1 page of private workspace
ROM 14 DFS needs 9 pages of shared workspace, 2 pages of private workspace
ROM 13 BILL needs 0 pages of shared workspace, 2 pages of private workspace

The MOS asks how much shared workspace the ROMs need. The maximum is DFS's 9 pages, so the shared workspace ends at &E00+&900 = &1700.
The MOS then asks the ROMs to claim private workspace.
FRED is called and told available workspace is at &1700, do you need any?
FRED wants 1 page, remembers it's at &1700, adds its needs and passes &1800 back to the MOS.
DFS is called and told available workspace is at &1800, do you need any?
DFS wants 2 pages, remembers it's at &1800, adds its needs and passes &1A00 back to the MOS.
BILL is called and told available workspace is at &1A00, do you need any?
BILL wants 2 pages, remembers it's at &1A00, adds its needs and passes &1C00 back to the MOS.
The MOS sets the bottom of user memory to &1C00.
When BASIC starts it sets PAGE to the bottom of user memory, which has been set to &1C00.

FRED's private workspace is at &1700
DFS's private workspace is at &1800 and &1900
BILL's private workspace is at &1A00 and &1B00

If you swap FRED and DFS, then DFS's private workspace will be at &1700 and &1800 and FRED's will be at &1900.
If it's a game it wouldnt need to take account of anything outside of DFSs minimal workspace though ordinarily?

AJW
Posts: 906
Joined: Sun Feb 15, 2004 2:01 pm
Contact:

Re: Below page free space (DFS)

Post by AJW » Mon May 11, 2020 10:06 pm

JGH seems to be right.

I used CLOSE#0 and CH."MAIN" which is supposed to change Mode to 1 and chain "MAIN2". However it doesn't change mode.

Wheen I use OSCLI"EXEC":CHAIN"MAIN" MAIN runs including selecting Mode 1 and loads in MAIN2.

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Mon May 11, 2020 11:17 pm

AJW wrote:
Mon May 11, 2020 10:06 pm
JGH seems to be right. I used CLOSE#0 and CH."MAIN" which is supposed to change Mode to 1 and chain "MAIN2". However it doesn't change mode. Wheen I use OSCLI"EXEC":CHAIN"MAIN" MAIN runs including selecting Mode 1 and loads in MAIN2.
I have been able to use CLOSE#0 to do what you're trying to do:
:idea:

AJW
Posts: 906
Joined: Sun Feb 15, 2004 2:01 pm
Contact:

Re: Below page free space (DFS)

Post by AJW » Tue May 12, 2020 10:12 pm

Im using Beebem on Mac with DFS 1.2.

User avatar
jgharston
Posts: 4121
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Below page free space (DFS)

Post by jgharston » Wed May 13, 2020 2:43 pm

jgharston wrote:
Mon May 11, 2020 5:13 pm
fixes it, as *EXEC does IF EXEC_CHN<>0 THEN TMP=EXEC_CHN:EXEC_CHN=0:CLOSE#TMP
whereas DFS 2.24's CLOSE#0 just does CLOSE and neglects to tell the MOS that it's closed the MOS's EXEC file.
Odd, I've tested every DFS with my Master, and can't reproduce the error. But I have clear memories of the frustrations the error caused. I'm sure it was with a Master, as it was while I was doing summer work at Camp Beaumont.

Code: Select all

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

johnkenyon
Posts: 248
Joined: Wed Jul 20, 2011 3:21 pm
Location: Coventry
Contact:

Re: Below page free space (DFS)

Post by johnkenyon » Wed May 13, 2020 3:28 pm

I've seen something along the lines of

*BASIC
*K.0CH."MYPROG"|M
*FX138,0,128

Rather than running the chain command from "inside" the EXEC loop, define a function key, and then insert it into the buffer for execution after the EXEC loop has ended.

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Wed May 13, 2020 4:18 pm

johnkenyon wrote:
Wed May 13, 2020 3:28 pm
*BASIC
*K.0CH."MYPROG"|M
*FX138,0,128

Rather than running the chain command from "inside" the EXEC loop, define a function key, and then insert it into the buffer for execution after the EXEC loop has ended.
Thanks, that's a neat trick!

@AJW, sorry for hijacking this thread, but if I may just add the following: my interest in this CLOSE#0 business is in relation to bbcmicro.co.uk: back in 2015(!) we were still figuring out how to automate the creation of !BOOTs for all the .SSDs in Mick's games collection, and we wanted to come up with a !BOOT that would leave the (virtual) Beeb in as "clean" a state as possible, which would ideally mean avoiding soft key definitions:
:idea:

johnkenyon
Posts: 248
Joined: Wed Jul 20, 2011 3:21 pm
Location: Coventry
Contact:

Re: Below page free space (DFS)

Post by johnkenyon » Wed May 13, 2020 10:27 pm

lurkio wrote:
Wed May 13, 2020 4:18 pm
johnkenyon wrote:
Wed May 13, 2020 3:28 pm
*BASIC
*K.0CH."MYPROG"|M
*FX138,0,128

Rather than running the chain command from "inside" the EXEC loop, define a function key, and then insert it into the buffer for execution after the EXEC loop has ended.
Thanks, that's a neat trick!

@AJW, sorry for hijacking this thread, but if I may just add the following: my interest in this CLOSE#0 business is in relation to bbcmicro.co.uk: back in 2015(!) we were still figuring out how to automate the creation of !BOOTs for all the .SSDs in Mick's games collection, and we wanted to come up with a !BOOT that would leave the (virtual) Beeb in as "clean" a state as possible, which would ideally mean avoiding soft key definitions:
:idea:
If you want the soft keys cleared before chaining the program, your !BOOT file becomes

*BASIC
*K.0*FX18|MCH."MYPROG"|M
*FX138,0,128

User avatar
lurkio
Posts: 2919
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Below page free space (DFS)

Post by lurkio » Wed May 13, 2020 11:12 pm

johnkenyon wrote:
Wed May 13, 2020 10:27 pm
If you want the soft keys cleared before chaining the program, your !BOOT file becomes

*BASIC
*K.0*FX18|MCH."MYPROG"|M
*FX138,0,128
I thought I'd tried that some time ago and I vaguely recalled that it didn't work. I just tried it again now in BeebEm and I can confirm that it doesn't seem to work: the *FX18 seems to immediately clear all soft key definitions including the one you've just activated with the *FX138 command! So it never gets to the CH."MYPROG".

:!:

johnkenyon
Posts: 248
Joined: Wed Jul 20, 2011 3:21 pm
Location: Coventry
Contact:

Re: Below page free space (DFS)

Post by johnkenyon » Thu May 14, 2020 9:04 am

lurkio wrote:
Wed May 13, 2020 11:12 pm
johnkenyon wrote:
Wed May 13, 2020 10:27 pm
If you want the soft keys cleared before chaining the program, your !BOOT file becomes

*BASIC
*K.0*FX18|MCH."MYPROG"|M
*FX138,0,128
I thought I'd tried that some time ago and I vaguely recalled that it didn't work. I just tried it again now in BeebEm and I can confirm that it doesn't seem to work: the *FX18 seems to immediately clear all soft key definitions including the one you've just activated with the *FX138 command! So it never gets to the CH."MYPROG".

:!:
I tested it and thought that it did work, then I tested it again, and it didn't (same behaviour on M128 and B)!

*K.0OSCLI("FX18"):CH."MYPROG"|M
does work though, although it isn't BASIC1 friendly.

The conclusion is that soft key expansion gets suspended when you hit |M
A further test with *FX138,0,65 added at the end of the boot file shows that the keyboard buffer is not cleared (the letter A appears after the *FX18 command)

Coeus
Posts: 1821
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Below page free space (DFS)

Post by Coeus » Fri May 15, 2020 8:11 pm

jgharston wrote:
Wed May 13, 2020 2:43 pm
Odd, I've tested every DFS with my Master, and can't reproduce the error. But I have clear memories of the frustrations the error caused. I'm sure it was with a Master, as it was while I was doing summer work at Camp Beaumont.
The version I think I have seen gets stuck in a loop printing "Channel". Because the fling system does a BRK on attempig to read a closed channel the code within the OS never gets to remove the now closed channel number stored away as the current EXEC file thus after BASIC (or similar language) has printed the error message it tried to read from the input channel and that fails with a further error and so on.

Of course, many game loaders may not ever hit the problem. If nothing reads from the OS with OSRDCH/OSWORD but instead reads the keyboard directly the problem won't show up.

Interestingly MS-DOS avoids this issue by having the OS remember the location in a batch file but close the file itself when it is about to run a transient program. When the program returns it re-opens the file and seeks to the previous location. That makes batch files rather slow.

AJW
Posts: 906
Joined: Sun Feb 15, 2004 2:01 pm
Contact:

Re: Below page free space (DFS)

Post by AJW » Fri Jun 05, 2020 10:15 pm

A bit disappointed to find my program doesnt display graphics proprly when i load in data from &1300 instead of &1400. The program only uses one openin for the map data at 1400. Sprite data at &900 loaded in a loader program. Was hoping to free 2k for sprites but apparently can only use from&1400 as i say.

Post Reply

Return to “programming”