IOMD OS_Memory 8 incorrect

RPCEmu 0.8.9, RISC OS 5 ROM from 8th June. RPCEmu configured with 32MB DRAM and 8MB VRAM.

RISC OS 40MB appears on the boot screen, running out of the desktop BASIC gets 39xxxxxx bytes.

But if I run this program:

   10SYS "OS_Memory",&108 TO ,pages%,pagesz%
   20PRINT "DRAM: ";pages%;" pages, ";pages%*pagesz%;" bytes, page size ";pagesz%
   30SYS "OS_Memory",&208 TO ,pages%,pagesz%
   40PRINT "VRAM: ";pages%;" pages, ";pages%*pagesz%;" bytes, page size ";pagesz%
   50SYS "OS_Memory",6 TO ,s%,p%
   60PRINT "Table size ";s%;" page size ";p%;" address space ";s%*p%*2
   70DIM t% s%
   80SYS "OS_Memory",7,t%
   90i%=0
  100oldv%=-1
  110FOR j%=0 TO s%-1
  120n%=(t%?j%) AND &77
  130IF ((t%?j%) AND &7)=1 THEN i%=i%+1
  140IF n%<>oldv% THEN PRINT ~j%*p%*2;": previously ";~oldv%;" now ";~n%
  150oldv%=n%
  160IF ((t%?j%) AND &70)=&10 THEN i%=i%+1
  170NEXT j%
  180PRINT "Memory table entries for DRAM ";i%;" = ";i%*p%;" bytes"

I get:

DRAM: 10240 pages, 41943040 bytes, page size 4096 
VRAM: 0 pages, 0 bytes, page size 4096 
Table size 65536 page size 4096 address space 536870912 
         0: previously FFFFFFFF now 33 
    400000: previously 33 now 0 
   2000000: previously 0 now 22 
   2800000: previously 22 now 0 
   3000000: previously 0 now 44 
   3800000: previously 44 now 0 
   8000000: previously 0 now 44 
  10000000: previously 44 now 0 
  13000000: previously 0 now 11 
  15000000: previously 11 now 0 
Memory table entries for DRAM 8192 = 33554432 bytes 

The memory table is correct, but OS_Memory 8 is claiming all the RAM is DRAM when actually some is VRAM.

Hmm… if I configure RPCEmu with no VRAM and various amounts of DRAM I get this behaviour:

4MB, 8MB: RPCEmu segfaults
16MB: Error from RPCEmu 'Bad opcode 12 E12C0070 at 0000000^' (sic, that's a ^ not a last digit)
32MB, 64MB: RISC OS hangs after 'Acorn ADFS' - no * prompt
128MB, 256MB: Boots fine to * prompt

I’m using ARM610 emulation by the way. Perhaps this is related to the above bug. If I run with 256MB DRAM and 8MB VRAM it still happens, though.

The memory table is correct, but OS_Memory 8 is claiming all the RAM is DRAM when actually some is VRAM.

Looking in the kernel there’s a warning to say “Sort out memory amounts” and it looks like it never got filled in. I think all the information is around somewhere in its head, but currently the kernel only bothers filling in 5 (soft ROM) and 1 (DRAM). Seeing as I’ve looked this far I can at least fix the VRAM/DRAM one.

Perhaps this is related to the above bug. If I run with 256MB DRAM and 8MB VRAM it still happens, though.

No, that’s an unrelated problem in the new HAL RAM probing code, I’ve been in private discussions with Jeffrey Lee about how best to tackle it – there are some odd combinations of physical SIMMs that also don’t get probed right at present.

Interestingly, RISC OS 3.60 in ARM710 mode is happy to detect all combinations of DRAM/VRAM I tried. This might give a means to test out the RAM probing code – my best idea so far was just to clip on a logic analyser to an actual machine.

I wonder if this is related to the problem I have with the soft load of RISC OS 5 on my physical RiscPC. Where although VIDCBandLimit is being set correctly, the machine behaves as if no VRAM is fitted rather the 1MB it has.

the machine behaves as if no VRAM is fitted rather the 1MB it has

Is the startup banner an odd number? eg. if you have a 32MB SIMM + 1MB VRAM banner should say RISC OS 33MB, that would suggest the VRAM was detected at the lowest level.

I just checked here (64+1 machine) and it says 65MB and my fix to OS_Memory reports that VRAM now too!

Nice to think things are moving on with the RPC ROM version.
Have got a duel boot here RO4.02/5.xx.
No Viewfinder Driver :-( 1152x 864 C32K F52.
Also with my version no Floppy Drive.
At the moment – no EtherX – the 32bit version doesn’t find the NIC card.
Might work with a Multi-podule or Podule.
Has anyone here – any influence with the Authors/Makers – to have a 32bit re-compile?
Might be possible to do a 32bit version by hand.
!StrongED doesn’t want to load – gives an error.

After a couple of re-boots the StrongEd error is -
Error window – Syntax: *Filer_Boot (application)

Yes, the start up banner reads 41MB. (32+8+1).

Ref my error with StrongEd – *Filer_Boot – RO5
- doesn’t take parameters – like RO4.
Now working on RO5.19 SA RPC.

Running RO5.19 (19 Jun 12)
I was using the old Memory8 effect to load a ‘NoVram’ mode setup file for RO5.
But the 32bitSG version of BandLimit seem to work ok.
Is there any reason that the floppy is not being recognised?
Is there anyway of using DRAM & VRAM at the same time to increase the video capabilitiies?

Ref my error with StrongEd

StrongEd 4.68 works OK for me. Is the error when you double click its icon or is it in your “add to apps” in !Configure?

I was using the old Memory8 effect to load a ‘NoVram’ mode setup file for RO5.

OS_Memory 8 now reports VRAM correctly, of all the ways to detect RO5 to select “NoVram” obey file that was probably a weak check. DRAM+VRAM should work to give full resolutions, I’m looking at VIDC at the moment so will inevitably check this along the way.

Is there any reason that the floppy is not being recognised?

On IOMD class machines there’s no DMA from floppies, it pumps the data with FIQs, and that code path hasn’t been updated in ADFS yet. It’s on (one of my) todo lists, since I still use floppies quite a bit to copy to a BBC Micro.

I had added a line to the !Run file- sometime ago.
*Filer_Boot -d <StrongED$Dir>.!StrED_cfg
The -d gave an error with RO5.

The Vram error – was made use of – while sorting out the boot files.
The App ‘BandLimit’ seems to be working ok – with both RO4.02/5.19.

The -d gave an error with RO5.

What does -d do? Can you show what the help reports? I’ve got 4.02 here, and -d is rejected for me.

*HELP FILER_BOOT RO4.02
==> Help on keyword Filer_Boot
*Filer_Boot boots the application specified.
If -d is specified then booting of
the application is delayed until the desktop is active.
Syntax: *Filer_Boot [-d]

If -d is specified then booting of the application is delayed

So it does – I’d forgotten I softload the Filer module on the RISC OS 4.02 boot sequence.
Anyway, I can’t think why booting application outside the desktop wouldn’t work, so “-d” seems an odd addition, what effect were you using it for with StrongEd – maybe that would enlighten matters?