RISC OS on the RPi4, RPi 4

I have up ’til now not tried RISC OS on my RPi3, despite the rapid progress made in its use when it first came out. So the RPi4 seemed an unsurmountable problem when it appeared.

However, now it has obviously become a mature platform for RISC OS, so I have taken the plunge and ordered one.

Is there a single resource dealing with its use, or can those who’ve already become adept with its use with RO point me towards useful resources at this point-in-time that I might consult?

I anticipate that this thread might form a useful resource for other late-adopters as well as for me if experienced users take the time to respond.

There’s Using RISC OS on the Raspberry Pi (but I expect you already knew about that).

Another likely late-adopter here – not ordered one yet, financial considerations. Not sure what RAM size to go for when I do bite the bullet – how accessible is the extra memory?

Not sure what RAM size to go for

I went for 4GB for my initial foray.

I went for 4GB for my initial foray.

At £54 for the 4GB and £73.50 for the 8GB, I wouldn’t want to end up buying both. But is it worth considering the 8GB at all? If I can expect in the not-too-distant future, if not already, to be able to use more than 4GB – at least 4GB of it from BASIC – then it’s worth the extra £19.50…

4GB is more than adequate for RISC OS, the only reason I have 8GB Pi4’s for Linux is web browsing with multiple tabs open, each being a separate process able to use a large amount of memory. Even if a RISC OS browser could do this, I suspect performance would be abysmal with no forking or cowing.

What is the maximum WimpSlot these days using a nightly build? 2+GB? (I don’t have any huge memory systems)

I suspect performance would be abysmal with no forking or cowing.

Cowing? You intimidate your computer into doing what you want?
Enquiring minds…..

Copy On Write ;-)

What is the maximum WimpSlot these days using a nightly build? 2+GB?

Wot!!! WimpSlot max is 512MB, it is the RAMdisc that can go up to 2GB.

OK, so what is the largest application slot that works if you build a custom ROM?

At £54 for the 4GB and £73.50 for the 8GB, I wouldn’t want to end up buying both. But is it worth considering the 8GB at all? If I can expect in the not-too-distant future, if not already, to be able to use more than 4GB – at least 4GB of it from BASIC – then it’s worth the extra £19.50…

It’s probably at least another couple of months until the nightly Pi ROM builds will support using all 8GB of RAM. I’m currently putting the finishing touches on the AbortTrap system (which is being co-opted to help deal with some memory permission compatibility issues that are present when using the long descriptor page table format), but there are also a couple of other bits that could probably do with improving before the OS is in a suitable state to allow us to turn on 8GB support without too many things breaking.

OK, so what is the largest application slot that works if you build a custom ROM?

1.75GB is believed to be the limit – any higher than that and you’ll run into some known issues with the RMA being pushed above the 2GB barrier (known issues within the OS, and probably some issues lurking in third-party software). However I don’t know if anyone’s actually tried this yet (try setting AplWorkMaxSize in hdr.KernelWS to &70000000). Previous discussion here.

OK, so what is the largest application slot that works if you build a custom ROM?

By way of a helpful answer I suppose that would depend on how much customising one was up for. I think the 512MB limit is fairly well baked in.

edit – The post above has the correct answer.

In real terms right now there is not an issue. Iris, which seems to going down in legend as a memory gobbling monster, is not that big. Here, with three tabs open, it has swallowed up about 330MB. There are three wimpslots each of about 8MB, one for Iris itself and two for WebKit. The rest is various dynamic areas the largest of which is 108MB for Shared Libraries.

Hope this is of some use.

What is the memory map for RO5.xx.

Thanks Jeffrey – that’s interesting. If 1.75GB is as big as WimpSlot’s ever likely to get, there’s not a lot of point me going beyond a 4GB Pi!

It’s using indirection operators on a huge slab of memory – the bigger, the better – from BASIC, or accessing that huge slab from assembler embedded in BASIC, that interests me.

I probably used to understand about Dynamic Areas too. Must investigate.

try setting AplWorkMaxSize in hdr.KernelWS to &70000000

That built OK but on the Titanium the ROM aborted on data transfer on start up.

&26c4 in FileSwitch

However with a value of 40000000 :-

It’s probably at least another couple of months until the nightly Pi ROM builds will support using all 8GB of RAM.

8GB builds, though incomplete, have been OK here, no errors have been seen.

There’s Using RISC OS on the Raspberry Pi (but I expect you already knew about that).

I’ve found your very useful wiki contribution on config.txt which is very relevant!

Given that Wimp slots are (theoretically) paged, if you need huge swathes of memory, why not a small slot and a massive Dynamic Area?

why not a small slot and a massive Dynamic Area?

I was suddenly wondering that on reading elsewhere, but have forgotten (if I ever knew) about Dynamic Areas. Must investigate.

That built OK but on the Titanium the ROM aborted on data transfer on start up.

&26c4 in FileSwitch

OK, so some debugging to do then! Thanks.

I was suddenly wondering that on reading elsewhere, but have forgotten (if I ever knew) about Dynamic Areas. Must investigate.

If you want “unlimited” amounts of memory (i.e. more than can fit in the logical address space) you’ll want to look into Physical Memory Pool DAs. You can allocate as much physical memory as you like, and then selectively map the pages in & out of a smaller logical window to allow access to the content. This is how RAM discs are currently implemented – even at 2GB size they only take up a 1MB space in the logical memory map.

It’s using indirection operators on a huge slab of memory – the bigger, the better – from BASIC, or accessing that huge slab from assembler embedded in BASIC, that interests me.

I wonder whether BASIC treats the indirection address as a signed or unsigned integer? If signed, then 2GB will be your limit. Unsigned, 4GB. In both cases the range addressable will be the limit minus &8000 minus the size of the BASIC program and its other variables.

Previous discussion here.

Thanks – I knew I’d seen it recently but couldn’t find it again!

Physical Memory Pool DAs

Fond memories of Bas128… “It’s suicide”. Bas8G anyone?!!! ;-)

However with a value of 40000000

That’s progress. Why not churn out some nightlies like this (for one platform, say) to help shake bugs out?

If signed, then 2GB will be your limit. Unsigned, 4GB.

Unless you can switch between multiple areas of memory, yes. I think it’s unsigned – just an address. What I’m hoping is that I can have 4GB available in BASIC/assembler (including the software itself) and still have other applications running in the rest of the 8GB.

However with a value of 40000000

That’s progress.

A bit more progress, 60000000 also works, which is a WimpSlot of 1572832k.

I think it’s unsigned – just an address.

It depends on context. &FFFFFFFF is -1 after all.

The problem may be if any part of the addressing and/or handling of such addresses uses a signed instruction rather than an unsigned one.

Which it might, as size% = module%!-4 etc.

So, thanks, Clive, for volunteering to be our guinea pig. ;-)

BTW, what on earth do you need that sort of array for? And is it always populated with lots of data, or would a sparse array be better (if a lot of the content is a fixed value, like null)?