RiscPC update Aug2014

SYS “OS_Memory”,9,&400 TO ,addr%

Hanging relative to ‘S space’ isn’t the strongest of tests, since that also exists on Tungsten (Iyonix) so will return a valid value there too. Controller type 4 is intended to be S0-S7 (Risc PC TRM table 1.15) with S0 being IOMD’s internal registers.

If we’re wanting to expose the region 0×3600000 to 0×37FFFFF then it might be better to either define a new controller type, recycle “Tube ULA” which I got allocated a few years ago and seems quite apt here, or add a dummy HAL device reporting the ASIC on the OPEN bus.

Shame about the lack of OS_Memory 25 I suppose.

Not sure what that brings to the party? You want the logical address, so you want OS_Memory 9.

Hanging relative to ‘S space’ isn’t the strongest of tests, since that also exists on Tungsten (Iyonix) so will return a valid value there too.

Yes, I think I was a bit hasty in saying it was the best way of doing things.

With ref to the ‘PC card’ – honorary podule – Acorn expansion card :-)
and the 8th podule – Nic card.

• Nic card info RO 5.21 RO 4.02
  &F982B000 &302B000 Extension ROM or NIC base address
  *
  Take one number from the other and you get &F6800000

&F6800000 + &302B000 = &F982B000 Extension ROM or NIC base address
&F6800000 + &3750000 = &F9F50000 For ‘PC Card’

Does this make any sense?

If we’re wanting to expose the region 0×3600000 to 0×37FFFFF then it might be better to either define a new controller type, recycle “Tube ULA” which I got allocated a few years ago and seems quite apt here, or add a dummy HAL device reporting the ASIC on the OPEN bus.

In the absence of a strong objection either way, I’ve gone with

SYS"XOS_Memory",9,6<<8 TO,asic_base%;flags%

Note – the physical address range is 0×03600000 to 0×037FFFFF inclusive, but I note the PC card support module only seems to use 0×03700000 relative addresses – the difference is described in the TRM on page 1-11.

The HAL device route I think implied I’d have to auto detect the ASIC so as not to create a ghost device for something that’s not really there, and since there were other coprocessors aside from the PC card that would need a pile of extra hardware prodding. The controller address API on the other hand is just telling you the base address – go knock yourself out!

Is it still possible to do a *save xxx of the ro5.21 roms?

Yes, but why? You already have the ROM image since that’s what you loaded in order to get to the point of wanting to save it!

Is this OS_Memory call implemented in RO 4.02?
Is there a version of StrongHlp file that covers it?
Or an update page for the PRMs – is PRM 5a – the last version?

As for the saving of a working RO 5.21 to a ROM file – RedSquirrel doesn’t seem to like to load RO 5.21 from a rom file. (does it understand the RO 5.21 format)
RO 5.21 works from a softload.
Is there a source version of the ‘Softload’ prog?
Thanks

Is this OS_Memory call implemented in RO 4.02?

RO3 PRMs
http://www.riscos.com/support/developers/prm/memman.html#86750

“This call is only available from RISC OS 3.5 onwards.”

Does that help?

Is this OS_Memory call implemented in RO 4.02?

OS_Memory 9 has been around since RISC OS 3.5, but controller type 6 is only understood by RISC OS 5.

Is there a version of StrongHlp file that covers it?
Or an update page for the PRMs – is PRM 5a – the last version?

There are docs on the wiki: https://www.riscosopen.org/wiki/documentation/show/OS_Memory%209

Is there a source version of the ‘Softload’ prog?

The source is here in CVS: https://www.riscosopen.org/viewer/view/castle/RiscOS/Utilities/Debugging/SoftLoad/

The ROM format is basically the same between 5.21 and 4.02 (at least for IOMD), I suspect the problems you’re seeing with RedSquirrel are down to a bug in some part of the hardware emulation which only triggers if you try booting straight into 5.21.

What value does the output of the SYS call equal on a 26bit system?

RO 5.19 dated 12 Feb 2012 works from direct from disc with RS.
Version dated 12 Nov 2012 doesn’t.
RO 5.21 24 Aug 2014 ok as a softload.

Has anyone done a util – If32bit {run command} ELSE [*run xxx]
Something like that for setting the *wimp slot for ‘DA Picture’

ie If32bit *wimpslot -min 50000k ELSE -min 24576k

Since the emulators have separate cmos files – is there a free to use cmos location – that Softload helper files could use to determine whether to load of not?

To tell if the OS is 32 bit, you can so it the legit way: https://www.riscosopen.org/wiki/documentation/show/OS_PlatformFeatures%200%20Flags

Or you can drop into assembler and CMP PC,PC and if the result is equal then it is a 32 bit system.

OS_PlatformFeatures is probably better as you can obtain more potentially useful information from the one call.

To answer one of my questions – I have come up with this.

Next to do – a automatic RO5.21 startup with RedSquirrel – by using a CMOS setting to store info for the Sofload helpers to read.
What CMOS setting is safe to use between RO4.02 and RO5.21.

In DA Picture !run file – seems to work ok – with RO 4.02 &5.19/21.
**********
WimpSlot -min 24576k
*If32bit *WimpSlot -min 80000k
*run <daspict$Dir>.DAPicture %0
**********
DIM Code% 56
:
PRINT “Assembling :”
FOR Pass% = 4 TO 6 STEP 2
O%=Code%:P%=0
[OPT Pass%
.base%
B Skip%
EQUD &79766748
EQUD &216C6776
EQUD end%-base%
EQUD 0
EQUD &20
.Skip%
TEQ R0,R0
TEQ PC,PC
MOVNE PC,R14
MOV R0,R1
SWI “XOS_CLI”
CMP PC,#0
MOV PC,R14
EQUS “ver 1.00”
    ALIGN
    EQUS “32OK”
.end%
]:PRINT "Pass “;Pass%;” successful…"
NEXT Pass%

SYS “OS_File”,10,“Mem:If32bit”,&FFC,,Code%,O%
*********

Using RO 4.02 I notice that the Module ‘MouseScaler’ by Jarman/Spooner – the faster movement of the mouse causes the pointer to move farther.

But with RO5.21 it doen’t seem to have any effect.

The code looks ok – but was there any changes that effected the mouse?

Is there perhaps a replacment?

Ref the module ‘MouseScaler’ managed to get it to work in the Horz direction with RO5.21 but not in the vertical direction.

What is the start address of the softloaded ROM and can the startup checks be bypassed -searched for in !Zap?

Ironically, your If32Bit transient utility is missing the “32OK” word at the end to say that it’s safe to run on a 32 bit system… :) See this for example.

    DCD   &20 ;= 32bit :-|
But 32OK noted.

Where does it say that “32OK” is required? That is for podule loader code, isn’t it?

Our version of FileSwitch accepts any old thing typed as a Transient utility. Hmmm…

Where does it say that “32OK” is required?

I’ve forgotten exactly where this originated – I believe it was at Castle. As I understand it, it’s checked for by Aemulor and, if found, stops the utility from being run in emulated 26-bit mode. We didn’t introduce any checks in FileSwitch or similar to block transients which don’t have this footer, in contrast to ROL and their transient utility header. Our reasoning being that most transients would continue to work fine and, if they did hit a 26 bit issue, they would probably just data abort in a fairly harmless fashion. That seemed better than stopping pretty much every transient utility in existence from running.

I’ve forgotten exactly where this originated – I believe it was at Castle. As I understand it, it’s checked for by Aemulor and, if found, stops the utility from being run in emulated 26-bit mode.

I repeat: Where does it say that “32OK” is required?

In a brief Google, numerous examples of podule loader, no mention of transient utilities. Otherwise you are relying upon what would appear to be undocumented behaviour – https://www.riscosopen.org/wiki/documentation/search?query=32OK and Google…

It originated at Pace: http://gerph.org/riscos/ramble/appexecution.html
http://www.iyonix.com/32bit/32bitTech.shtml
https://www.riscosopen.org/news/articles/2013/10/11/more-expansion-cards-join-risc-os-5

It originated at Pace:

Actually those links all reference a marker in podule headers so I’d be inclined to repeat Rick’s comment:
“Where does it say that “32OK” is required?
In a brief Google, numerous examples of podule loader, no mention of transient utilities. "

Now if Steve R wants to update the documentation to reflect the assertion that it is required in utilities fine, equally if Steve wishes to change his mind about the requirement and avoid the task of altering the documentation – also fine.

I repeat: Where does it say that “32OK” is required?

I don’t recall saying it is required, despite all your emphasis. Just search the RISC OS source tree and you’ll see that it’s the done thing. As I actually did say above, I’ve forgotten where it originated (thence where it is documented) so perhaps someone else might remember this detail and satisfy your lust for documentary evidence.

As I understand it, it’s checked for by Aemulor

Who was first? It is a bit asinine to have two different ways of marking a Utility as being 32 bit; though I note that neither method seems capable of denoting a utility that is agnostic and will run correctly on 26 and 32 bit systems.

I think the evidence is pointing initially at this being something Aemulor-related, having just spoken to Ben and he can’t remember where this comes from either. We wonder if Adrian came up with this or someone at Castle? Maybe Adrian could shed some light on it. And yes, it’s also lost in the mists of time which of these things (32OK footer vs ROL’s header) actually came first.

neither method seems capable of denoting a utility that is agnostic and will run correctly on 26 and 32 bit systems

That’s because it’s not required. It would be perverse in the extreme to write a 32-bit only transient utility. :)

I don’t recall saying it is required, despite all your emphasis.

Could this not be inferred from “Ironically, your If32Bit transient utility is missing the “32OK” word at the end to say that it’s safe to run on a 32 bit system… :)” ?

Just search the RISC OS source tree and you’ll see that it’s the done thing [...] perhaps someone else might remember this detail and satisfy your lust for documentary evidence.

I am not looking for “documentary evidence” (my emphasis), I am simply asking (“done thing” or not) that important issues that may relate to the correct (or otherwise) behaviour of software are properly documented. As it stands not only is this the first that I have heard of this “32OK” footer, it does not appear to be mentioned or otherwise described.
So let me ask you – what may be the outcome of running a 32 bit safe Utility without the header (ROLtd branch only) or this footer? Answer? Nothing at all. It works as expected.¹
Now let me ask you another question – what would be the outcome if I performed this same test with Aemulor running? I cannot try as I don’t have a copy, but if Aemulor uses this method to determine if a piece of software is to be run as 32 bit or emulated as 26 bit, it might be a bit flamin’ useful to mention this, don’t you think? Or does whoever implemented this think that developer time is better spent chasing obscure bugs because we’re all relying on a behaviour that is not otherwise mentioned. What, we are supposed to know by osmosis?

Please don’t think I’m being an ass about this. I just think (arbitrarily) altering an executable format and then not making this information widely known is… well… rude.

¹ For the pedants, I am referring to RISC OS 5 here. That’s what this site/forum is about, right? ;-)

“Ironically, your If32Bit transient utility is missing the “32OK” word at the end to say that it’s safe to run on a 32 bit system… :)”

Sigh. You’re really spoiling for a fight aren’t you?

Aside from my smiley that you quoted indicating clearly that I’m saying that in a light-hearted way, I was stating something that I had observed in the RISC OS source tree and which I have always (since first seeing it) assumed to be an established practice. I have never claimed – and this is getting tedious repeating this fact – to know why this is done nor from where it originated.

So let me ask you – what may be the outcome of running a 32 bit safe Utility without the header (ROLtd branch only) or this footer? Answer? Nothing at all. It works as expected

Your conclusion is incorrect, because we are currently in possession of two established facts here:

1. Something expects or expected (historically) to see that footer, otherwise it wouldn’t exist
2. A significant number of transient utilities in the RISC OS source tree itself implement this, which rather underlines point 1 above.

Do not allow the fact that none of the people contributing to this thread thus far is in a position to know or recall where this convention came from or why it arose to be conflated with an incorrect belief that it is not required.

Now, it may well turn out to be the case that it’s an anachronism, a failed attempt to establish a protocol or some other dead-end. It may well be the case that it’s completely harmless to not bother with it. I’m pretty confident that nothing in RISC OS 5 checks for it or cares whether it’s present or not. But (and this is a big BUT) we are not in a position to say definitively that if you try to do X, or use software package X and this footer isn’t present, something bad might happen. Unlikely – I’ll grant you that.

For crying out loud, it’s four bytes on the end of your transient utility and every one in the RISC OS source tree does it. Is it really worth all this discussion? Maybe we should just say it is advised for reasons which are lost in the mists of time. Yes, I agree things like this need to be documented. You can stop jumping up and down about it now. This probably was documented somewhere, at some time, but that documentation is currently AWOL.

And those are the last few minutes I’m going to spend on this subject. The documentation on our wiki is available for community editing. Knock yourself out.