Emulation

Jon guessed

OS_Byte 166 is a throwback to MOS meant for 16 bit addresses

As I’ve pointed out many times before, this wasn’t even true on the BBC Micro. It has always been capable of returning more than 16bits even on the MOS, and the convention chosen in Arthur ensured that it could return 32bit addresses. And that’s how it’s always used.

Not only is OS_Byte not limited to bytes (at all, in or out), but all the code that uses such calls rebuilds the 32bit address as Jeff has pointed out.

The galling bit is that when somebody put the ‘new’ API in, presumably in the belief that the old API wasn’t 32bit, they actually had to look at that line of code that Jeff has highlighted… and they still couldn’t see it was 32bit. Sheesh.

Martin quibbled

Why regard OS_ReadLine as ‘broken’

It’s hamstrung by a 26bit API, which means that perfectly innocent code that uses a buffer in a Dynamic Area could suddenly start setting bits it didn’t mean to in a 32bit build.

However, it is definitely broken and always was because it checks the wrong bits anyway.

It has always been capable of returning more than 16bits even on the MOS

No, actually, it isn’t. Yes, I know you can return an extra 8 bits in A, giving a total of 24 bits.
Except for the fact that pretty much everywhere (except one co processor document) it states very clearly that A is preserved.
The co pro document is a bodge, reconning the API for a specific use case.

If the value to be returned by the “where is the MOS stuff?” call was supposed to be larger than 16 bits, it would have been an OSWORD.

and the convention chosen in Arthur ensured that it could return 32bit addresses

Certainly, so it really wouldn’t be a big deal for the high vector builds to OR in the upper halfword so the end result was a valid address that still worked. By all means have a ReadSysInfo, but breaking the older API is… unnecessary.

It’s hamstrung by a 26bit API

Not to mention the fun of shoving both into the same vector – https://www.riscosopen.org/wiki/documentation/show/ReadLineV
It’s easy on RISC OS 5, it’s always the 32 bit style.
But on older machines, it’s bit 31 of the buffer size that determines whether it’s the original 26 bit API or the newer 32 bit.

Take a moment to think about this. Remember I was having a go above for the half-assed way of bashing in an extra 8 bits in the Accumulator?
Well this is another shining example of fail. A nice new API was created to work around obvious deficiencies in the old, and it was shoehorned into the existing API with a bit to select which, and then unleashed on the older (26 bit) version of the OS where:

1. it wouldn’t really affect new 32 bit machines
2. it may be an issue on machines with the greatest amount of legacy code that might interpret the bit 31 as either huge or a negative number. At any rate, code written in ‘92 isn’t going to know anything about the 32 bit version of ReadLineV.

because it checks the wrong bits anyway.

And, yeah… cerise sur le gâteau…

No, actually, it isn’t.

You then go on to show that 24 is greater than 16, proving me correct. Perhaps you’re quibbling about the definition of “always”. Let me rephrase it – OSBYTE was capable of returning more than 16bits before Arthur existed. As far as RISC OS is concerned, that may as well be ‘always’. And OS_Byte has always been able to return 32bit values. Ça suffit.

I can’t clarify that further without pasting the actual code from every Acorn version of RISC OS and Arthur… which I would do (he says pointedly) if it brought me any joy.

You then go on to show that 24 is greater than 16, proving me correct.

Certainly, three eight bit registers can return a 24 bit result if you’re willing to simply ignore the bit that states that one of the registers is preserved on exit.
You know why we can’t add a pressure value to OS_Mouse? It’s because it will break anything that assumes that R0-R3 are used and nothing else is touched.
Anything that tries to retrofit meanings to additional registers that available documentation says are supposed to be preserved is wrong. Pure and simple.

Let me rephrase it – OSBYTE was capable of returning more than 16bits before Arthur existed.

And let me rephrase it – BBC AUG p180 documenting calls 166 and 167. A is preserved.
That leaves two registers, X and Y. And what, pray tell, is eight plus eight?

This is in response to: As I’ve pointed out many times before, this wasn’t even true on the BBC Micro. It has always been capable of returning more than 16bits even on the MOS
Which is demonstrably incorrect. It’s a 16 bit value and nothing else because the accumulator is preserved. Look at the OS code.

And OS_Byte has always been able to return 32bit values. […] without pasting the actual code from every Acorn version of RISC OS and Arthur… which I would do (he says pointedly) if it brought me any joy.

Knock yourself out. I’m not arguing RISC OS behaviour. And if you actually read my message rather than skipping bits, you’ll maybe have noticed that I think that the high order bits of the high vector address should be ORed into the value read from the 16 bit value in OS workspace to form a valid 32 bit address.

I’m arguing your assertion that the BBC MOS could return bigger values. Technically, yes. But when the docs say that A is preserved, one expects A to be preserved; additionally the standard MOS had no need to use more than 16 bits as that was sufficient to represent the entire addressing range of the processor. Anything add on that did return larger values did so in contravention of the API (it probably should have added an OSWORD, but there’s enough “probably should have” in any API…).

I’m arguing your assertion that the BBC MOS could return bigger values. Technically, yes.

Once again, thank you for establishing this fact. Again.

This is in response to: “As I’ve pointed out many times before, this wasn’t even true on the BBC Micro. It has always been capable of returning more than 16bits even on the MOS”
Which is demonstrably incorrect.

“Always” refers to OS_Byte. The observation that OSBYTE changed during the 8bit era is of historical interest only – when OS_Byte was born, OSBYTE had the API I described.

And if you think OS_Byte always preserves its “A” – R0 – then OS_Byte,0 would like a word.

I’m not going to argue with you any more on this subject.

And if you think OS_Byte always preserves its “A” – R0 – then OS_Byte,0 would like a word.

OSBYTE &00 (0) *FX 0 Identify  Operating  System  version

Entry  parameters:
   X=0  Execute  BRK  with  a  message  giving  the  O.S.  type
   X<>0 RTS with O.S.  type  returned  in  X

On exit,  X=0,  OS  1.00 X=1,  OS  1.20
          A and Y are preserved
          C is  undefined

Or the original user guide: OSBYTE call with A=&0 (0) Read operating system version number
If X=0 on entry then the operating system version number will be returned as an error message. If X is non-zero on entry then on exit X will contain the opeating system series number – for example OS 2.00 would return X=2. On exit A and Y are preserved, C is undefined.

So… <shrug>

I’m not going to argue with you any more on this subject.

Yeah, it’s boring me too, pointing out the many places where MOSVARS was clearly considered to be a 16 bit entity… and a remnant of the MOS lingering in RISC OS.

Whatever.

You are continuing to get confused between OSBYTE and OS_Byte.