Status update?

Hi all,

I used RISC OS for many years from its inception to about 1996 during which time I wrote and released lots of OSS and featured in Acorn User Magazine a few times. Maybe someone remembers my game TwoPlay? Anyway, I’ve been using RPis for years and recently bought an M1 Mac (which I love) and, consequently, am getting back into Arm assembly language programming albeit the new Aarch64 Armv8 version. So I have a bunch of questions:

1. What is the status of RISC OS wrt everything new? 64-bit? Multicore? Floating point? Memory protection? Etc.

2. The RISC OS world used to be a great source of tutorials on things like asm programming. Do you guys have any good references for tutorials about things like the new instructions in A64, Neon and so on?

3. BASIC+asm was an awesome combo. These days I’m using OCaml and F# mostly. What is the state of the art in terms of languages for RISC OS now?

4. I don’t suppose anyone still has a working copy of TwoPlay? :-)

Hope all’s well!

Cheers,
Jon.

TwoPlay? Wasn’t that the game whose app icon was a seesaw? If it is, it ceased to run so long ago, that I don’t even remember what sort of game it was. For some reason my memory whispers that it had something to do with blind typing, but well… that’s my rusty memory.

1. What is the status of RISC OS wrt everything new? 64-bit?

Nope

Multicore?

Not really, some demos with many restrictions on use, e.g. no SWIs on other cores.

Floating point?

Mostly still using the FPEmulator for the 20 year deprecated FPA instructions (so a slow soft float). But recently BASIC64 gained the ability to use VFP instructions internally instead.

Memory protection? Etc.

Nope.

2. The RISC OS world used to be a great source of tutorials on things like asm programming. Do you guys have any good references for tutorials about things like the new instructions in A64, Neon and so on?

I’m not aware of any, and certainly not for Aarch64.

3. BASIC+asm was an awesome combo. These days I’m using OCaml and F# mostly. What is the state of the art in terms of languages for RISC OS now?

Probably still C, though with reasonably recent ports of Python 3 and Lua.

I not aware of an OCaml or F# port.

4. I don’t suppose anyone still has a working copy of TwoPlay? :-)

I’ve not found it straight away, I’ll have a look through some old archives. How was it released? Commercial, PD? coverdisc? ftp site? web site?

Floating point?

RiscLua uses VFP (and FPA for older machines).

What is the state of the art in terms of languages for RISC OS now?

The current RiscLua is based on Lua 5.4.3. One based on 5.4.4 due out soon.

Alas, 64-bit, multicore, pre-emptively multitasked, memory protected, etc RISC OS is very unlikely to happen without substantial financial investment. The developers do a heroic job, but such an overhaul (together with compatibility layers for existing applications and so on) is a huge task that in practice needs salaried programmers and quite a few of them.

Where this money comes from is left as an exercise for the reader.

It’s not just money, there are several possible approaches different approaches to achieving 64 bit RISC OS which have yet to be settled, and which ever is chosen there is the issue of how to maintain compatibility with the existing 32 bit ecosystem without just turning in to a legacy emulated platform.

For 2 if you search for Neon, you’ll find several people have made use of it to greatly speed up FP code.

As for 3, the need to move to 64 bits shows us the problem with relying on assembler, so I wouldn’t be fussed if 64 bit BASIC didn’t have a 64 bit assembler. As for other languages, we’ve got Norcroft C, GNU C/C++, Python 3 and Lua with sufficient maturity for serious development.

so I wouldn’t be fussed if 64 bit BASIC didn’t have a 64 bit assembler.

I, too, would prefer it to continue with the 32 bit assembler to maintain compatability.

I, too, would prefer it to continue with the 32 bit assembler to maintain compatability.

You do understand, I trust, that a 32 bit assembler in a 64 bit BASIC on a 64 bit system would be about as useful as a chocolate teapot.

Please, people, forget any notion of compatibility. Any 64 bit RISC OS that isn’t some sort of emulation of the 32 bit world will not behave the way we currently know. AArch64 is quite different to ARM32. If it helps get you in the mindset, imagine porting RISC OS to MIPS, or (god help us) x86-64.

Which, I hope, will be theoretically possible due to the shiny new RISC OS being written in C or something this time around, and not tens of megabytes of assembler source!

@Jon: Regarding 64 Bit Assembler, I got those two books for coding under Linux 64 on my Raspberry Pi 400, both quite different and good:
Book 1
Book 2
I coded some fractal stuff, link here
Once Linux will run decently on the M1 I might get one, too :-)
NEON and VFP on 32 Bit is fully integrated in the RISC OS Basic and quite fun to code still.

The new BASIC would have to be clever enough to work out what combination of 64 bit instructions would emulate the 32 bit ones.

You do understand, I trust, that a 32 bit assembler in a 64 bit BASIC on a 64 bit system would be about as useful as a chocolate teapot.

You could implement an interpreter for the assembler instructions. Worse evils have been committed when getting legacy code to run.

On a 64-bit system, a SWI can return a 64-bit pointer. An interpreter or converter system could lose half of that data when storing into a 32-bit value and reloading. That is a big problem.

The only sensible way to run legacy BASIC with 32 bit assembler on a 64 bit machine is via an emulator, anything else with just be unnecessarily complex and less than 100% compatible.

These days I’m using OCaml and F# mostly. What is the state of the art in terms of languages for RISC OS now?

It’s possible to use bare-metal rust (i.e. without any of the standard library), cross-compiled from Linux.

See here

On a 64-bit system, a SWI can return a 64-bit pointer.

One of the 256 possible SWIs in AArch64 you mean? ;-)

Only if we let it… We might not choose to do so. It is not a totally daft idea to keep int/long as 32 bits and restrict the virtual address space to the bottom 4Gb, at least to get going. I think one of the DEC Alpha configurations used this for some time before going LP64.

Writing in a HLL may help, but maybe not magically as much as you might think/hope. How much of your code correctly uses (u)intptr_t to store things that may be pointers rather than cramming them into an int? Given that RISC OS C has been ILP32 for all this time, I suspect a lot of existing code will be expecting just that and break ‘interestingly’ when moved to a different model. At least if code has been ported to different systems it may lessen the effort required to port it to a newer RISC OS world.

Not really, some demos with many restrictions on use, e.g. no SWIs on other cores.

https://github.com/Simon-Willcocks/RISC-OS-Kernel-in-C/wiki/Screenshots/Screenshot%20from%202021-10-19%2018-07-49.png

That was 4 cores using DrawMod to animate cogs, a month or so ago. I’m currently trying to get WimpManager to initialise, which involves Sprite Ops, which are giving me headaches.

I’m replacing the HAL section of a RISC OS ROM with a kernel written in C and multi-core aware modules. Because it’s such a large task, I’m trying to get as far as I can without re-building the OS (I’m afraid I’ll break it), and manually identifying various entry points:

  _binary_AllMods_start = 0xfc0217a8 ; /* Complete hack, matches SysModules_Info(+4?) in my RISC OS ROM */
  system_font = 0xfc040f94 ; /* Ditto, HardFont, from vdufontl1 */
  JTABLE = 0xfc01014c ; /* SWI table from ROM. */
  SpriteVecHandler = 0xfc036cd0 ; /* Avoiding BranchNotJustUs */
  ByteVarInitTable = 0xfc041a35 ; /* Read only, ROM defaults */

Any system SWI (0-255) can be re-implemented in C (most aren’t, yet), there’s support for multi-core aware modules (module, really, I’ve only done one!), and I’ve bypassed the use of internal structures by the SpriteOp code (BranchNotJustUs) in the kernel.

At the moment, I’ve done something wrong with OS_ReadVduVariables, and WindowManager is failing with “No room to get sprite”. I think I’ll take a break and see if I can get a sprite plotted on the screen, instead. Found that one, at least, the graphics window is {0,0,0,0}. Silly question, can I change it without using VDU 24? (Of course, I could just write to the workspace, but that’s horrible.)

Didn’t someone back along redo the Sprite module in ‘C’ ?

can I change it without using VDU 24?

You really do need the VDU system working to get anywhere.

Didn’t someone back along redo the Sprite module in ‘C’ ?

Someone did implement a subset of it in a module. Then wanted to do it in C++ ISTR.

@Colin If they did, they didn’t integrate it with the ROOL version. [Correction: SpriteExt is written in C, and provides many features of OS_SpriteOp, could that be it?]

@Stuart Yes, but it doesn’t look easy to use just parts of it. I’ve spent a happy few hours creating a C structure for the workspace, so I can hopefully fiddle enough to convice the sprite code to work. I expected getting DrawMod would be more difficult, but it wasn’t.

I don’t suppose anyone still has a working copy of TwoPlay? :-)

How was it published? I track the preservation status of all commercial game titles and this isn’t one I’ve seen mentioned in any magazines or sales literature to date, certainly not from any of the main publishers at any rate.

How much of your code correctly uses (u)intptr_t to store things that may be pointers rather than cramming them into an int?

We were not talking about C.

We were not talking about C.

I will wager that even more things would break in BASIC programs if you changed the default integer size to be 64 bits.