Getting more userspace RAM on the BBC Master

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
hjalfi
Posts: 74
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Getting more userspace RAM on the BBC Master

Postby hjalfi » Thu Jun 08, 2017 10:33 am

On a Master with shadow RAM enabled, the user workspace (i.e. the RAM available to transient programs) extends from the OSHWM at &E00 to &7FFF. If I then page in a bank of sideways RAM, I also get RAM at &8000 to &BFFF. Combine the two together, and I get a whole 44.5kB of contiguous memory! (Note that the currently selected language is irrelevant here; this is a transient machine code program that's intending to stomp all over the language workspace.)

Can I actually do this in any useful (i.e. portable, non-game) sense? Not only would need OS calls to map my page of RAM back on exit, but I'd also need any file system calls which referred to addresses in the range &8000 to &BFFF to do the 'right' thing --- refer to the currently mapped page of sideways RAM (whichever that is), rather than to the file system ROM which is doing the work. I don't want to have to write my code to care about whether data is stored in &E00-&7FFF or in &8000-&BFFF; ideally the code will load at &E00, look to see the top of usable RAM is, and use the whole thing as a heap. This way, if sideways RAM is not available, my program still works, just with less workspace.

I have vague memories of a Master BIGBASIC which allowed very large programs using sideways RAM, but I don't know how it worked. anyone?

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

Re: Getting more userspace RAM on the BBC Master

Postby Rich Talbot-Watkins » Thu Jun 08, 2017 10:39 am

You should be able to do that perfectly legally (select a shadow mode, and page in your Sideways RAM bank). The only problem is if you want the file system to access data in your Sideways RAM bank - that's just not going to work. You'll either need to ensure that anything which is saved/loaded is below &8000 in memory, or you're going to have to use something like OSGBPB to load/save 256 byte blocks from some point in main RAM, copied to/from your Sideways RAM bank.

Typically this would be done using a language ROM though, thus giving you 16k of program, and the whole of main RAM (including language workspace) for your data. Unless there's any good reason not to, I'd first suggest taking that approach, as this is the proper OS friendly way to do it. If you put in second processor relocation (not sure exactly how that works), you could use it over the TUBE with a second processor, with the extra memory available.

User avatar
hjalfi
Posts: 74
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Re: Getting more userspace RAM on the BBC Master

Postby hjalfi » Thu Jun 08, 2017 2:07 pm

The problem is that what I have is a pipeline of, maybe, five different executables, each of which will load once, run, and terminate. Also, I have a horrible feeling that at least some of them will be more than 16kB of code. So ROMming them isn't really a viable option. (I don't actually know for sure how big the program is, but I'm planning for the worst.)

I suppose the correct thing to do here is to run on the second processor, because then I get to use everything from &0400 to &F800 = 61kB; but ideally I'd like to support non-Tube platforms as well.

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

Re: Getting more userspace RAM on the BBC Master

Postby BigEd » Fri Aug 04, 2017 9:15 pm

If the executables are (comfortably) under 32k, and each one sits at PAGE, there's no trouble loading them. So it's only loading and saving data that's an issue, as the data the programs build in memory might have landed up above &8000. Sounds to me like allocating a page-sized buffer just past the end of your program and using that for OSGBPB is the right answer.

It would be good to see this done. For a machine code program, treating the Master as a 48k machine is quite attractive. And probably the exact same tactic could run in the Tube too, even though it needn't be quite so careful and could use a bit more memory if necessary.

(The big Basic you remember might be BAS128 which uses 4 banks of sideways RAM for the user program and data, and presumably manages 1+2 byte pointers to do that. See here
viewtopic.php?t=9645
)

[I'm interested in your cowgol Ada-like self-hosted compiler - can you perhaps announce and explain it in a thread?]

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Getting more userspace RAM on the BBC Master

Postby SteveF » Fri Aug 04, 2017 11:32 pm

I am not sure it would meet your use case, but one thought about how you could write a big machine code program using multiple sideways RAM banks - which I haven't tried...

You could split it up into different machine code subroutines and group them arbitrarily into a series of 16K chunks, each chunk assembled to start at &8000. Instead of making direct machine code JSR calls between those subroutines, you would JSR to a stub which lives in main memory and does:

Code: Select all

.foo_stub
LDA &F4:PHA
LDA #4 \ get ROM bank we know 'foo' lives in - we might do LDA &40x instead and set up &400-&403 with the actual RAM banks in use when we load the 16K sideways RAM image on program startup
STA &F4:STA &FE30
JSR foo
PLA:STA &F4:STA &FE30
RTS


This is similar to the classic disc-based overlay style of programming, but because the RAM bank switch is pretty quick you don't really have to worry about grouping related subroutines in the same overlay.

You could potentially use a generic stub routine which peeks at bytes after the JSR and do something like 'JSR generic_stub:EQUB bank_index:EQUW foo' to make the calls; the call would be a bit slower and bigger, but you wouldn't burn main memory on a separate stub for each subroutine.

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Getting more userspace RAM on the BBC Master

Postby pstnotpd » Sat Aug 05, 2017 6:14 am

I think the whole point of bank switching is to smash the 64KB limit altogether at the cost of not having continuous ram space. Unless you'd want to handle "big" files, which typically is data, you wouldn't need that continuous space anyway.

You might want to look at Bruce Smiths Advanced Sideways Ram User Guide.

Some time back I used that to start the hexarom which is I never finished because every time I start over I get sidetracked somehow. Maybe a good time to have a go at it again 8)

As an example. I combined this hexarom with BAUW windows, which was featured in an Acorn user article and heavily uses sideways ram for both code and intermediary storage. The idea was to have the hexarom handle all the tiling and sprites while using BAUW for popup text windows.

As a POC it worked fine, but I think at the time I ran into trouble because the complexity of the hexarom graphics didn't allow for good compression.

Anyway, my point is that using the proper OS way you definitely are able to write 64KB+ programs if you design your program in a modular fashion, indeed similar to the disc based overlay style.

User avatar
hjalfi
Posts: 74
Joined: Sat May 13, 2017 10:17 pm
Location: Zürich, Switzelrand
Contact:

Re: Getting more userspace RAM on the BBC Master

Postby hjalfi » Sat Aug 05, 2017 9:18 am

Of course, as my program's a pipeline of (probably, at the latest count) six different binaries, I've effectively already using overlays...

I think that right now I'm going to aim at running this on the second processor. I have serious concerns about whether this is going to work at all, as 6502 code is pretty wordy and I need to fit a binary and its workspace into memory at the same time. If I can make this work in 61.5kB, then that would be the time to try the clever tricks to make it work on a Master. I suspect a B's going to be right out.

(I don't want to talk about Cowgol just yet until I know for sure whether it's going to work, or not. But I do have some questions about efficient use of code size; I'll post those in another thread.)

SteveF
Posts: 439
Joined: Fri Aug 28, 2015 8:34 pm

Re: Getting more userspace RAM on the BBC Master

Postby SteveF » Sat Aug 05, 2017 10:26 am

I appreciate it's probably not the style of thing you're looking to do, but if you're writing a compiler, you could consider generating PLASMA bytecodes instead of 6502 code - I think it's a lot more compact, and you can use up to 55K of bytecodes+data using the PLASMA VM on the tube, or 64K of bytecode+20K of data using the PLAS128 version of the VM with 64K of sideways RAM, all managed automatically for you. Obviously this comes at a performance cost, and it's not as cool as generating raw 6502 code. :-)

There are details in the thread here: http://www.stardot.org.uk/forums/viewto ... 55&t=12306 Note that PLASMA is both a programming language and a virtual machine that the programming language compiles down to; the programming language would not be of interest to you, but the PLASMA virtual machine just might be. You can see the virtual machine opcodes at the bottom of https://github.com/dschmenk/PLASMA/blob ... /README.md and I'd be happy to offer any advice, but I'll keep this post brief as I suspect it's not really what you're after.

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Getting more userspace RAM on the BBC Master

Postby pstnotpd » Sat Aug 05, 2017 2:26 pm

If you're going to target a 2nd processor anyway you might want to consider going for 65816.
However if you want to backport to a non-copro master eventually this might be overkill.


Return to “software: other”

Who is online

Users browsing this forum: No registered users and 2 guests