32k memory management for dummies

Discuss all aspects of programming here. From 8-bit through to modern architectures.
aqarius
Posts: 11
Joined: Thu Nov 02, 2017 4:15 pm

32k memory management for dummies

Postby aqarius » Wed Jan 03, 2018 3:09 am

Hey guys,

I've been doing a bit of work converting a game I made for the C64 to the BBC. I've successfully written code to draw sprites in Mode 1 that are equivalent to what I was using on the C64, and am now looking at bringing across all the gameplay code. Memory is a lot tighter on the Model B compared to the C64, so I'm adapting the game to use multi-load features, and I will also be cutting down the Mode 1 screen area to 256 x 192 to save memory (the game was designed to be easily portable to the ZX Spectrum so mostly uses a 256xN screen area). As I understand it, &0E00 is the typical start address for user programs, and some pages below this may be suitable for temporary variables in a machine code program, without disrupting the operating system too much. But where a disk operating system is present, that start address will be brought forward well into the 1000's. I just wondered if anyone had some wisdom on how to manage tape/disk versions of software? I'm coming from a position of relative ignorance, but I imagine games that were released on tape and disk didn't use vastly different amounts of memory. Did tape versions simply avoid memory that was required for DFS, or did games loaded from disk often repurpose DFS memory, assuming no multi-load occurred afterwards? Or was it quite safe to temporarily overwrite DFS memory, and still be able to load new data from disk, accepting that the memory may be reset?

TL;DR, I'm trying to figure out how much memory I can realistically use in a BBC game that uses Mode 1 @ 256x192.

Any tips would be much appreciated.

PS: I have a plan for Acorn Electron that involves using Mode 6 instead of a custom Mode 1.

User avatar
richardtoohey
Posts: 3390
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand

Re: 32k memory management for dummies

Postby richardtoohey » Wed Jan 03, 2018 3:27 am

Can't answer all your questions, but often disc games would load in MODE 7 (lowest memory usage), then do *TAPE and shuffle code down to &E00.

That wouldn't work for multi-load games.

Look also for custom modes e.g. the 10K MODE 8 ... but not the resolution you are after:

http://www.dfstudios.co.uk/articles/ret ... ts-part-2/

Might be of interest, anyway.

User avatar
tricky
Posts: 2008
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 32k memory management for dummies

Postby tricky » Wed Jan 03, 2018 7:29 am

Lots of disc games that just use *load move page down to &1100 and I don't see why this wouldn't work for multi-load with *load, although it would be breaking the rules.

The last time that the was a survey on here, more than half machines had sideways ram. For a small amount of effort, this gives you an extra 16K from &8000 and is disc and multi-load compatible.

For my games, I use 32K-3bytes, but you have to do everything after load yourself (maybe more work than you want).

A last resort for me would be to go master only where you have 128K or 512K with 96K easily accessible with Bank switching sideways RAM.

Phantasm
Posts: 15
Joined: Thu Jan 19, 2017 9:56 pm

Re: 32k memory management for dummies

Postby Phantasm » Wed Jan 03, 2018 4:22 pm

tricky wrote:For my games, I use 32K-3bytes, but you have to do everything after load yourself (maybe more work than you want).


out of interest what does 'do everything after load yourself' comprise of in order to load data without going through the standard *LOAD routines?

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

Re: 32k memory management for dummies

Postby crj » Wed Jan 03, 2018 4:55 pm

I'm willing to bet he's no longer interacting with filesystems once running.

In fact, I'm assuming the 3 bytes in 32K-3 are IRQ1V and an RTI at &D00. (-8

User avatar
tricky
Posts: 2008
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 32k memory management for dummies

Postby tricky » Wed Jan 03, 2018 5:57 pm

Phantasm, load everything up front, no further communication with the OS/filesystem/BASIC/anything :shock:
crt, close, but I don't see why I should waste &D00 if I have claimed the NMI :lol: but if I have a byte that can be RTI that I can put there, then I will.
The third byte is &FC as OS 1.2 (and the others I guess) still has one last hook that is run:

Code: Select all

\\ FFFE    EQUW   DC1C                             // 5 ~JMP()
\\ DC1C    STA    &FC     ;save A                  // 3 - can't really use &FC if an interrupt might happen!
\\ DC1E    PLA            ;get back status (flags) // 4
\\ DC1F    PHA            ;and save again          // 3
\\ DC20    AND    #&10    ;check if BRK flag set   // 2
\\ DC22    BNE    &DC27   ;if so goto DC27         // 2
\\ DC24    JMP    (&0204) ;else JMP (IRQ1V)        // 5 - need to point &204/5 to my IRQ handler
\\ So irq_handler should be hit ~24 cycles after vsync
It should be possible to run without interrupts and poll for vsync once per frame, but I usually have timers running and sometimes I cut it a little fine and wouldn't want to drop a frame for a 1ms overrun that will be caught back up before anyone notices!

aqarius
Posts: 11
Joined: Thu Nov 02, 2017 4:15 pm

Re: 32k memory management for dummies

Postby aqarius » Wed Jan 03, 2018 9:02 pm

Thanks for the info guys, I'm starting to get a clearer picture of how things work. I haven't had a disk drive up till now but I've received one today. :)

It's a Master I've got so I did contemplate using more of the memory, but generally I prefer to make things work on the unexpanded base model of hardware (although I'm excluding Beeb Model A in this case :oops: ). I could certainly put sideways RAM to use where available to avoid the multi-load.

What tricky is describing (essentially binning MOS and taking over the full 32k) is pretty much exactly what I'd do on the C64 if I wasn't going to use the kernal routines again, which is usually the case.

What I'm wondering is, is it possible to use DFS reserved memory (&E00 onwards) in between loads, and then call some ROM routine to set it all back up for DFS to use again? In the C64 version of the game I have about 1k of working memory that doesn't need to be kept between game levels, and it'd make sense to relocate it to an area it can alternate with DFS (if that'd work). If not, I could probably work with &1100 - &4FFF to be honest. The C64 game (Super Carling The Spider) was actually an enhancement of an unexpanded VIC-20 game that ran in 4k, so it should definitely be possible to run the game with its various improvements in about 16k. The C64 game uses about 63k of the 64k available, but it crams everything into a single load, which I'm not going to attempt on the BBC/Electron.

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

Re: 32k memory management for dummies

Postby crj » Wed Jan 03, 2018 9:41 pm

I've not tried this, but so long as the FDC was left in a relatively normal and recoverable state at the hardware level, it ought to be possible to page in the disk filing system and fake the calls the OS makes to it at boot.

However, it might be better to borrow the trick that Exile used: move important data out of the way then hook into the OS's Break handling via OSBYTE 247-9 and require the user to press Break. That's certain to bring everything back up cleanly.

User avatar
tricky
Posts: 2008
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 32k memory management for dummies

Postby tricky » Wed Jan 03, 2018 10:52 pm

There are plenty of people here who know the os better than me, but maybe you could do something like:
Load game
Load level into screen memory (maybe changing to mode 7 while loading - see the code in my phoenix loader)
*Tape
Copy level down and play
*Disc
Load next level to screen
...

There is the small problem of knowing what the original file system was, but I have some code for that somewhere.
You may need to *disc, *card, *adfs or *mmfs (I may have a couple of those wrong and the mmc variants may forget which disc image was loaded, so that is another issue.

Coeus
Posts: 560
Joined: Mon Jul 25, 2016 11:05 am

Re: 32k memory management for dummies

Postby Coeus » Thu Jan 04, 2018 12:01 am

tricky wrote:There is the small problem of knowing what the original file system was, but I have some code for that somewhere.
You may need to *disc, *card, *adfs or *mmfs (I may have a couple of those wrong and the mmc variants may forget which disc image was loaded, so that is another issue.


There isn't a perfect solution to this as there does not appear to be an API to say "select filing system X" where the filing system could be anything at all. If you are prepared to assume that a useful filing system will be in ROM then you can do this.....

After loading the first part of the game you need to call OSARGS with A=0, Y=0 and it will return the number of the current filing system, i.e. the one the user loaded your game from. Save this away somewhere and then, when you want to re-enter that filing system call OSBYTE &8F, which is actually "issue ROM service call" and set X (call number) to &12 and Y to the number of the filing system saved earlier.

Just how well a filing system will tolerate having had its workspace tramped and the re-selected in the way may vary. Even when a filing system is de-selected because another filing system has been chosen instead, it is still allowed to keep files open so it isn't expected to completely re-initialise upon being re-selected.

hexwab
Posts: 26
Joined: Wed Jul 08, 2015 8:27 pm

Re: 32k memory management for dummies

Postby hexwab » Thu Jan 04, 2018 5:28 am

Assuming you don't want to disrupt the OS too much, the low-hanging fruit available are:
0400-07FF no gotchas
0900-0AFF cassette buffers, don't go doing any byte-based I/O from tape
0B00-0CFF function key definitions (*KEY) and user-defined characters, don't go using these
1100 onwards should be free with DFS, assuming you don't want to do any byte-based I/O from disc (loading/saving entire files is OK). I don't know how much of DFS workspace you can trample on if all you care about is direct sector reads/writes (which you will need to use the API for, as the underlying hardware can vary wildly).

So that's 4K of easy savings to be had. As for zero page, 00-9F is safe enough.

For more details the definitive guides are http://mdfs.net/Docs/Comp/BBC/AllMem and http://mdfs.net/Docs/Comp/BBC/Disk/DFSMem .

HTH.

One final note: there's a huge number of games that use all the memory on a model B, and a notable minority that use any extra RAM for frills such as a larger display area or sampled sounds or less disc activity, but precious few that really take advantage of more memory to do things not possible in 32K (and lots of things are not possible in 32K, let's be honest). Underexplored territory ahoy.

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

Re: 32k memory management for dummies

Postby crj » Thu Jan 04, 2018 7:21 am

Coeus wrote:If you are prepared to assume that a useful filing system will be in ROM

It will be.

It really isn't practical to implement a filing system which isn't in a paged ROM. Where would you put it, for starters? And how would you invoke it? The consequences of changing the filing system vectors from within code called by another filing system's *RUN implementation don't bear thinking about!

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

Re: 32k memory management for dummies

Postby crj » Thu Jan 04, 2018 7:39 am

hexwab wrote:0B00-0CFF function key definitions (*KEY) and user-defined characters, don't go using these

Actually, &B11 onwards is safe provided you have no function keys defined, and page &C is fair game if you're not using user-defined characters. On the other hand, both those pages are used by Econet instead on the Master.

As for zero page, 00-9F is safe enough.

&00-&8F is for the current language, and completely safe. &90-&9F is reserved for Econet, so you should poke an RTI (&40) to &D00 before touching it.

Alternatively, if you're feeling dirty you can use the trick we did back at school when converting existing video games to load via Econet: prompt the user to unplug their Econet cable and REPEAT UNTIL NOT (?&FEA1 AND 4) before proceeding.

User avatar
tricky
Posts: 2008
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: 32k memory management for dummies

Postby tricky » Thu Jan 04, 2018 8:07 am

I don't want to put you off at all, but it is possible to have a floppy and mmc, which usually means Dfs and an mmc (turbo mmc, smart spi, mmfs) which all have the same file system number "for compatibility". You can check which ROM slot by checking the extended vector table ROM entry for the main file system vector. JGH confirmed that this is always at the same address and is what Acorn did bitd.

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

Re: 32k memory management for dummies

Postby crj » Thu Jan 04, 2018 9:09 pm

Really? That's a shame.

As I see it, the ability to select a filing system by number serves two purposes:
  • Select a known, desired FS without using OSCLI
  • Determine the current FS and restore it having done something with a different FS.
The latter feels to me like the far more common and useful case, the more important "compatability" to preserve when implementing a new FS!

Coeus
Posts: 560
Joined: Mon Jul 25, 2016 11:05 am

Re: 32k memory management for dummies

Postby Coeus » Thu Jan 04, 2018 9:58 pm

tricky wrote:I don't want to put you off at all, but it is possible to have a floppy and mmc, which usually means Dfs and an mmc (turbo mmc, smart spi, mmfs) which all have the same file system number "for compatibility". You can check which ROM slot by checking the extended vector table ROM entry for the main file system vector. JGH confirmed that this is always at the same address and is what Acorn did bitd.


So presumably to be sure to re-select the right filing system you would still need to save the number but then only issue service call &12 to the specific ROM that had claimed the filing system vectors previously.

Coeus
Posts: 560
Joined: Mon Jul 25, 2016 11:05 am

Re: 32k memory management for dummies

Postby Coeus » Thu Jan 04, 2018 10:05 pm

crj wrote:Really? That's a shame.

As I see it, the ability to select a filing system by number serves two purposes:
  • Select a known, desired FS without using OSCLI
  • Determine the current FS and restore it having done something with a different FS.
The latter feels to me like the far more common and useful case, the more important "compatability" to preserve when implementing a new FS!


Indeed this does feel like needing to do something that feels like a kludge due to shortsightedness of others. I would hope that new filing systems that are made to behave much like old ones, and can therefore be used in place of an old one, would also take a filing system number for themselves which they will always respond to and would provide the option to turn off any responding
to the number of the filing system they are a compatible replacement for.

Unfortunately people do write code that assumes it will only ever run from DISC or TAPE hence why filing system writers feel the need to masquerade as those. No credit to me for this feature, rather this is due to JGH, but VDFS on B-Em can response to *DISC, *DISK, *ADFS, *FADFS and the corresponding filing system numbers but you can also turn that off and have it respond only to *VDFS and its own filing system number (*FSCLAIM command).

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

Re: 32k memory management for dummies

Postby crj » Fri Jan 05, 2018 3:17 am

Coeus wrote:but you can also turn that off and have it respond only to *VDFS and its own filing system number (*FSCLAIM command).

Is there online documentation of that somewhere? (Google's not finding it.)

I'm intending to write a filing system that can ape DFS in much the same way. It would be silly to reinvent the wheel if someone has already chosen a command syntax for it.

Coeus
Posts: 560
Joined: Mon Jul 25, 2016 11:05 am

Re: 32k memory management for dummies

Postby Coeus » Sun Jan 07, 2018 10:13 pm

crj wrote:
Coeus wrote:but you can also turn that off and have it respond only to *VDFS and its own filing system number (*FSCLAIM command).

Is there online documentation of that somewhere? (Google's not finding it.)


I don't think there is any kind of official standard for how to do this because the official standard thing for a filing system to do is to have its own number and only respond to that but in the case of VDFS one can say:

Code: Select all

*FSCLAIM ON

after which it will respond to any of

Code: Select all

*VDFS
*DISC
*DISK
*ADFS
*FADFS

and the those filing system's associated filing system numbers via service call &12, or after an:

Code: Select all

*FSCLAIM OFF

it will only respond to *VDFS and its own filing system number.

A filing system masqurading as another is also currently under discussion for MMFS in 8bit hardware.

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

Re: 32k memory management for dummies

Postby crj » Sun Jan 07, 2018 10:53 pm

Indeed. I see that discussion. (-8

I'm surprised it claims both *DISC and *ADFS without - so far as I can see - any behavioural changes depending on which is used. Isn't something which does *DISC going to be surprised by the ADFS filing system presentation and vice-versa?

Coeus
Posts: 560
Joined: Mon Jul 25, 2016 11:05 am

Re: 32k memory management for dummies

Postby Coeus » Tue Jan 09, 2018 5:47 pm

crj wrote:Indeed. I see that discussion. (-8

I'm surprised it claims both *DISC and *ADFS without - so far as I can see - any behavioural changes depending on which is used. Isn't something which does *DISC going to be surprised by the ADFS filing system presentation and vice-versa?


Bear in mind this was a feature of the VDFS ROM as I found it on JGH's mdfs.net so this wasn't my design decision and I can only give a personal perspective.

It is possible for programs to work equally well on either DFS or ADFS. If you stick to the 7 character filenames and one character directory names, avoid changing the current directory and avoid referring to files in the default directory with an explicit $. then you should be OK.

That may seem a bit restrictive but I'd bet there is quite a range of software that does work within these constraints which means if VDFS refused to masquerade as one or another of those filing systems on the basis that it didn't emulate the exact behaviour of that filing system that would make sure you couldn't use it for software that tried to select that filing system even if the software did work within those constraints.

Of course, having a genuine dual personality would be the Rolls-Royce solution and could be a future enhancement but how many people would use it, i.e. would it be worth the effort?

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

Re: 32k memory management for dummies

Postby jgharston » Tue Jan 09, 2018 9:04 pm

Coeus wrote:There isn't a perfect solution to this as there does not appear to be an API to say "select filing system X" where the filing system could be anything at all.

Yes there is, service call &12 (link):
A%=143:X%=18:Y%=filingsystemnumber:CALL OSBYTE

If you need to be able to select TAPE/ROM (as the above doesn't work before the Master):
DEFPROCfs(Y%):LOCAL X%,A%
IF Y%<4:A%=139.5+Y%/2:X%=Y%+1 ELSE A%=143:X%=18
CALL &FFF4:ENDPROC


Is there online documentation of (VDFS) somewhere? (Google's not finding it.)

It's probably within 6502Em that the original version came with before Sprow updated it, and before I updated Sprow's update.

Code: Select all

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

Coeus
Posts: 560
Joined: Mon Jul 25, 2016 11:05 am

Re: 32k memory management for dummies

Postby Coeus » Tue Jan 09, 2018 10:11 pm

jgharston wrote:If you need to be able to select TAPE/ROM (as the above doesn't work before the Master):
DEFPROCfs(Y%):LOCAL X%,A%
IF Y%<4:A%=139.5+Y%/2:X%=Y%+1 ELSE A%=143:X%=18
CALL &FFF4:ENDPROC


Probably I should have been more explicit. By not a a perfect solution I did mean not able to select TAPE/ROM as these aren't implemented in a sideways ROM and therefore don't get that service call. That function is a neat way round that, though. Also, do I take it from before the master that the TAPE and ROM filing systems are part of the OS that overflows the OS address space into the terminal ROM on the master?

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

Re: 32k memory management for dummies

Postby crj » Wed Jan 10, 2018 12:43 am

jgharston wrote:If you need to be able to select TAPE/ROM (as the above doesn't work before the Master):
DEFPROCfs(Y%):LOCAL X%,A%
IF Y%<4:A%=139.5+Y%/2:X%=Y%+1 ELSE A%=143:X%=18
CALL &FFF4:ENDPROC

Oh wow, that's grim!

I've just spent a little while staring at it, and concluded that it:
  • Does *OPT 1,0 if you call PROCfs(0)
  • Uses floating-point maths, for no apparent reason
  • Depends on floating-point precision for correct operation
  • Relies on *TAPE2 selecting 1200 baud
At the very least, couldn't you use A% = 139 + ((Y%+1) DIV 2) rather than A% = 139.5+Y%/2 ? Or, if determined to optimise and obfuscate, A%=279+Y%DIV2 ?

I remain unsure what the correct behaviour is if someone attempts to select filing system 0...

User avatar
BigEd
Posts: 1552
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: 32k memory management for dummies

Postby BigEd » Wed Jan 10, 2018 9:49 am

(Not to worry, BBC Basic's floating point is OK with halving and numbers ending in .5)

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

Re: 32k memory management for dummies

Postby jgharston » Sun Jan 14, 2018 6:47 pm

crj wrote:I remain unsure what the correct behaviour is if someone attempts to select filing system 0...

Filing system zero ois defined to not exoist. It means "no filing system"

Code: Select all

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

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

Re: 32k memory management for dummies

Postby crj » Mon Jan 15, 2018 12:34 am

jgharston wrote:
crj wrote:I remain unsure what the correct behaviour is if someone attempts to select filing system 0...

Filing system zero ois defined to not exoist. It means "no filing system"

Yes, but I'm not aware of any null filing system, let alone any way to select it. Which, as I say, means it's not clear what to do if somebody requests it by number.

User avatar
Rich Talbot-Watkins
Posts: 1153
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: 32k memory management for dummies

Postby Rich Talbot-Watkins » Mon Jan 15, 2018 2:30 pm

OS 0.1 had *NOTAPE, which I assume deselected the filing system. Presumably they considered it useless enough to remove!

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

Re: 32k memory management for dummies

Postby crj » Mon Jan 15, 2018 4:23 pm

Thank you! That was bugging me. I knew that I could remember an implementation of filing system 0 from somewhere, but my hazy memory was leaning towards somehow ending up with no filing systems under fileswitch on the Archimedes.


Return to “programming”

Who is online

Users browsing this forum: No registered users and 4 guests