Emulation

Murklesoft’s 6502Em & Z80Em worked on the Iyonix, but have problems under new versions of RISC OS.

I know that the author could provide the source code of these emulators to the one that will correct this.
… and perhaps he will agree for a free distribution.

I looked at the code, but I have not the necessary time/skills required.
Anyone?

I really shouldn’t volunteer… but I will anyway. ;-)

Three cheers for nemo! :)

What does 6502Em do that BeebIt doesn’t?

Not to be BeebIt

I’m still trying to get !65Host working. It’s mostly identical to !65Tube which I have repaired, but 65Host is proving stubborn.

I’m still trying to get !65Host working

!65Host gets the address of the system variable table (OS_Byte) via the undocumented/Internal use only OS_Byte 166 and directly writes to it, which is a bit naughty these days. Possibly worth modifying if you haven’t already.

OS_Byte 166 is neither undocumented nor internal use only. This is nonsense.

It is the documented and portable way of finding the MOS vars so they can be accessed from interrupt handlers that couldn’t use OS_Byte directly.

My MosVarFix module ensures that OB166 continues to work correctly even when somebody forgot all about the Mosvars when moving zero page around in some versions of RO5.

TBH I’m still reeling from the realisation that 65Host’s memory emulation is designed to allow paging as complicated as the Master’s (it seems it was intended to emulate both) but then that developer must have been hit by a bus, because the actual ROM bank paging is implemented by literally copying 16KB blocks around memory – 32KB if the currently paged socket is RAM.

This every time there’s a service call. It’s dreadful.

OS_Byte 166 is neither undocumented nor internal use only. This is nonsense.

It is not documented in the RO 3 PRMs (IIRC), so can be considered as undocumented for the RISC OS API starting with at least RISC OS 3.0.

It is absolutely relied upon by interrupt code writers. For example, when I produced and published replacement keyboard drivers for 3.50 I was advised to use that call by Acorn engineers. KB or SB, I forget which.

SoundChannels and InternationalKeyboard use it. 65Host uses it. There will be other interrupt-related code that uses it. Omitting it from one piece of paper in no way makes it go away, any more than you or I adding something to this site’s Documentation suddenly makes it official.

Nor does omitting it from an edition of the PRM implicitly deprecate it – there’s plenty of things not in the PRMs.

As for the limitations of the documentation, take RemV which even on this site continues the fiction that R0 and R2 contain corrupted values depending on whether examine or remove has been chosen. This has always been wrong – both registers must contain the value because Kernel code does not agree with the published API. In fact in deference to that, the Kernel’s RemV handler ends with:

    LDRCCB  R2, [R2,R4]   ; CC here means ‘buffer not empty’
    MOVCC   R0, R2
    LDMFD...

Although that detail is irrelevant to users of the API, it’s of vital importance to implementors. So should we remove that from the Kernel because of what a PRM says?

Good luck with that.

Now this may have come about by historical accident – an implementation did this, some software accidentally relied on it, so it has been maintained as compatibility. However, unless those details are retained in documentation, Johnny-come-latelys may well decide that they know better than decades of precedent and start breaking things. When that happens the correct response is “Oops, I’ll fix it”, not “I have in my hands a piece of paper”.

For example, when I produced and published replacement keyboard drivers for 3.50 I was advised to use that call by Acorn engineers. KB or SB, I forget which.

Those are probably the two most useful sentences you’ve said on the subject. If it’s a thing which Acorn were advising people to use (well into the mid-nineties), then yes, we should continue to maintain support for it.

Nor does omitting it from an edition of the PRM implicitly deprecate it – there’s plenty of things not in the PRMs.

Perhaps you should start documenting them, because in case you haven’t noticed, the people making the changes to the OS don’t always have access to all the right information.

I hardly need point out that InternationalKeyboard and SoundChannels still use OS_Byte 166. Is that because (if Steffen is to be believed) these modules might be used on RISC OS 2?

“Undocumented from RISC OS 3” my ****

“Undocumented from RISC OS 3” my ****

Perhaps you should start documenting them, because in case you haven’t noticed, the people making the changes to the OS don’t always have access to all the right information.

May I suggest that if anyone knows of documentation they add it to the wiki published documentation.
Further, if there is no written documentation of any element, anyone with knowledge of the correct situation should produce documentation which attempts to describe the behaviour under as many versions of the OS as possible.
With that documentation others, perhaps in cooperation with the document author, can try to produce something that produces a uniform behaviour across OS versions.

That’s me done for now.

I hardly need point out that InternationalKeyboard and SoundChannels still use OS_Byte 166. Is that because (if Steffen is to be believed) these modules might be used on RISC OS 2?

Please re-read what I actually said instead of making something up.

If it’s a thing which Acorn were advising people to use

Acorn advising paid up developers behind closed doors and documenting for public use are two entirely different things. Given the lack of public documention (re PRM) on the block 166 sits in, I’d say it wasn’t for general public use.

It’s possible 166 was the only way to get the address back in the day, but should it not now be deprecated in favour of OS_ReadSysInfo 6

OS_Byte 166 is neither undocumented nor internal use only

Could you please point me to the documentation as I could not find any when I implemented it in ADFFS, I had to look at the OS code to figure out what it was doing.

InternationalKeyboard and SoundChannels still use OS_Byte 166

Should they not be using OS_ReadSysInfo?

and documenting for public use are two entirely different things.

Certainly. I would like to consider the PRMs to be the authoritative description of the API and structures (etc) at their point in time, otherwise, what’s the point?

Unfortunately, there is the description, and there is reality. :-/

but should it not now be deprecated in favour of OS_ReadSysInfo 6

Indeed, but the OS vars call is RISC OS 5.17 onwards. And you know what RISC OS is like regarding insane levels of backwards compatibility…

Oh, and nemo uses some version of 4 on an emulator, so that particular ReadSysInfo won’t be available to him, meaning… OS_Byte 166 will be kicking around for a little longer yet.

Could you please point me to the documentation as I could not find any when I implemented it in ADFFS

It helps to remember that Arthur was mostly a direct port of the Beeb MOS, and RISC OS came from Arthur.
So… BBC AUG page 180. ;-)

It is also documented in the Arthur PRM (page 14/21), the RISC OS 2 PRM (page 45/53), and the most recent RISC OS 3 PRM (page 1-50/64). It is also briefly mentioned here, but not why – because you’re probably not supposed to do that any more…).

This behaviour is documented under the description of OS_Byte, it is not mentioned in the list of OS_Byte values (which, perhaps, might have been useful).
The page references are first what it says on the actual page, and secondly the physical page in the PDF file.

Should they not be using OS_ReadSysInfo?

That’s what happens when you have somebody using old outdated software. ;-p

        MOV     r0, #6
        MOV     r1, #0
        MOV     r2, #OSRSI6_OSByteVars
        SWI     XOS_ReadSysInfo
        MOVVS   r2, #0
        CMP     r2, #0
        BNE     %FT01

        MOV     r0, #OsByte_OSByteVarTableLo
        MOV     r1, #0
        MOV     r2, #&FF
        SWI     XOS_Byte
        ORR     r2, r1, r2, LSL #8
01
        STR     r2, OsbyteVars          ; set up osbyte vars address

Heaven preserve us.

1. Keyboard Handlers are called under interrupts.
2. Keyboard Handlers must handle the Tab key
3. The buffer code returned by the Tab key is configured via OS_Byte
4. Interrupt code cannot call OS_Byte to read it
5. Therefore Keyboard Handlers need to access the MosVars direct

This has always been the case.

No appeal to authority is required, just comprehension.

Should they not be using OS_ReadSysInfo?

WHY FOR CRYING OUT LOUD WHY?

WHY?

Is it because somebody broke OS_Byte 166, is that why?

Or is there some reason that has so far defied explanation as to why OS_Byte 166 had to die? (spoiler: there isn’t, it was a mistake)

The reason I’m so scathing about this one is that there are only two possible explanations for events:

A. It was a mistake

This is the one I cling to for the sake of generosity of spirit. It was an oversight, caused by somebody being slightly unfamiliar with all the dark and distant corners of this ancient OS. It happens, you say “oops” and you fix it. (It didn’t happen that smoothly, there was carping and weasel words and attempts at justification but hey, humans.)

B. It was deliberate

This is the one that gets me riled, because if so it’s incompetence.

Why?

Because if somebody decided that despite knowledge of what this call was, what it was for, what was using it and under what circumstances, but still decided to stop it from working in the way that it was done, means that they reasoned thus:

1. This call returns an address that is used by interrupt code
2. I am moving the thing it points to
3. In fact I’m removing the memory entirely, so access will cause an exception
4. I’m not going to raise an error when the address is read, no, I’m going to continue supplying the old now-invalid address with no warning despite knowing it can’t work
5. Because the best way of dealing with API change is causing address exceptions in interrupt code

This is why I very much hope it was A.

dark and distant corners of this ancient OS

Probably somebody decided that MOSVars being a limited value (16 bits allocated in memory) made sense when it was stuffed into page zero so the values pointed at something, but then with the high vector releases, better to use a new API to get the actual address of the MOSVars and deprecate the ancient OS_Byte method…

Because the best way of dealing with API change

…is to understand that “it happens” when you’re making assumptions as to the internal workings of the operating system. Most of the PRMs explain that these OS_Byte values are for reading and writing OS variables. What the PRM does not do is explain what these variables are. There was a document floating around – this: http://www.drobe.co.uk/archives//freenet.barnet.ac.uk/Acorn/programming/docs/zeropage.txt
What that is is people working out what is where to use that in preference to the documented OS call, which may have application in specific circumstances, but is usually not a good idea to make assumptions about private OS workspace…

And, finally, as was made quite clear in the example code taken from the keyboard handler – it isn’t as if it is difficult to support the new API with fallback to the old.

Heaven preserve us

I believe everyone in this conversation is aware of the issues around calling SWI under IRQ. I’m not sure why you single OS_Byte out though, as the majority of SWI can’t be called under IRQ.

WHY FOR CRYING OUT LOUD WHY?

OS_Byte 166 is a throwback to MOS meant for 16 bit addresses, it’s just luck some code continues to work when it returns a 32bit address. I believe it’s for this reason a 32bit equivalent was added to OS_ReadSysInfo many years ago.

As the OS is developed, there are going to be deprecations and casualties along the way. The same thing applies to the CPU cores. As developers we either move with the times and embrace modern methods or we don’t.

Murklesoft’s 6502Em & Z80Em worked on the Iyonix, but have problems under new versions of RISC OS.

I use Chris Gransdens MESS. But at this time only for MSX1/2(Z80)-Emulation.
6502 should also work.

It doen’t seem sensible though to break existing calls.

a throwback to MOS meant for 16 bit addresses

Indeed, the actual value of MOSVARS in memory is two bytes. That means it can reside anywhere between &00000000 and &0000FFFF. Which, with the first 32K being system workspace, it did work, though it implied that the location was pretty much fixed unless the call was to get special treatment to fake up the real location. Long story short, it was a half assed over zealous bit of nonsense to port MOS so much that you stuck the MOSVARS into a 16 bit address on a machine that, in its smallest incarnation, had sixteen times as much RAM as a Beeb.

I don’t think it would be hard for high vector builds to return the full address as 24 bits plus 8 bits (if it doesn’t already), by simply patching in the &FFFFxxxx bit. This should suffice for legacy code, and simply tell everybody to use ReadSysInfo when and where possible.

You know, the problem here isn’t really whether or not OS_Byte 166 works. The problem here is that we’re still stuck with the arcane and convoluted keyboard handling that relies upon numerous calls to OS_Byte to do anything at all. As per nemo’s example, working out what character code the Tab key provides. Something that possibly shouldn’t have any issues with reentrancy and ought to be IRQ safe (as in, LDR whatever bit of memory that value is stored in, return it) only the whole thing is frustrated ¹ by the OS_Byte SWI call mechanism.

It doen’t seem sensible though to break existing calls.

Candidate #1, OS_ReadLine.
Candidate #2, any of the disc sector ops on media that needs a 64 bit address.

As things progress, other stuff is realised as not really being up to the job. Arguably OS_Byte 166 was broken from its very first implementation…

¹ I was unaware of “frustrate” being used in that context until it became the Brexiteer’s new favourite word.

Candidate #1, OS_ReadLine.

That call was already broken by putting flag bits in a pointer.

ORR r2, r1, r2, LSL #8

If R2 holds the upper 24 bits of the address, that code would’ve worked.

Why regard OS_ReadLine as ‘broken’ when there is an OS_ReadLine32 (which can be used pre-RO5 with CallASWI) which avoids the flags in r0?

Why regard OS_ReadLine as ‘broken’ when there is an OS_ReadLine32

Yup. The original ReadLine was limited so a new API was created… Sort of the point this whole thread is about.