C Kernel

I believe callbacks are only checked when returning to USR and IRQsema isn’t set. From the kernel notes callbacks are handled by Initial_IRQ_code.

Thanks for the IRQsema hint. I’ll move on to interrupts when I have everything else playing nice.

Just thought of an interesting issue. RISC OS supports modes where a 32-bit word contains multiple pixels (my ARMX6 for one, with 16 colour mode support, so eight pixels per word). If the aim is to have multiple CPUs capable of redrawing their window content simultaneously, how is it proposed to coordinate read/modify/write of pixels that are in the same word? (e.g. one window overlapping another with just a thin window border between)

Compositing window manager.

Or, more simply, saying who on earth is going to use a 16-bit, let alone 16-colour, mode in 2021?

The most sensible approach, it seems to me, is to lie to the application, and convert its output to 32-bit pixels.

Being a relatively new newcommer to RISCOS world, I’d discovered it by being unsatisfied with Linux on Pi for my projects. Went down the path of bare metal programming. Initially, when I’d heard that you guys are thinking of moving away from an assembler drrived kernel I’m aghast and feel I’d missed out. :)

Regardless, I can appreciate the lack of portability. I’ve been using EmBox for my projects but Pi isn’t fully supported there. I’ve contributed to that with GPIO, SPI, and Mailbox support but the remaining lift of supporting VC4 has been a big one for me. Moving on …

Recently came across BMC64 on Pi. That is bare metal Commodore 64 on Pi hardware. And that got my attention, does it have hardware acceleration? Sure enough, it does! How? Further investigation showed this library was providing the hardware interface … https://github.com/rsta2/circle it support Pi 1 thru Pi 4 with sound and VC, the full set of pererpherals that I can see. Also, it does not even attempt to provide a kernel. It does have a minimal scheduler which is optional to use.

I’m suggesting that you may want to consider this library as a base for the new C/C++ based RISCOS kernel. It appers to be quite mature, well maintained and you’d get full support of all Pis. You’ll also have a simpler transition to x64 architecture this way. And finally, I’d really like to see the SWI mechanism retained for system calls, I like it! it is very simple and direct to the hardware.

Please though, can we just stick with ARM based chips? I very much like the BBC Basic and it’s access to including assembler. I’d call that a fundimental feature of RiscOS that makes it a fantastic platform for learning.

Perhaps remove RISCOS from the category of viable daily driver system and rather the B track of excellent trainer, fun project platform, and gaming system? The reason being, to compete with the mainstream will force changes that remove the distinctiveness of the platform.

The retro community grows daily. I’d say a component of that success is accessibility and friendlyness. RISCOS isn’t that common amonst the Atari, Amiga, C64, or Vic20s, or even the BBC Micro (outside of UK), there is lots of room for growth. In any case, it is a supportive community in which to make a transition. Perhaps after that, there is room for further growth when the system has stabalized in its transition.

FYI: Here is the BMC64 project that utilized the Circle library https://github.com/randyrossi/bmc64

I’m suggesting that you may want to consider this library as a base

Circle does look like an interesting library. And, perhaps inadvertently, it is also (yet another) extremely good example of why getting away from an assembler environment as fast as possible is a Good Thing.
You will notice that, like Linux, only the really low level stuff (exception handling and machine startup) are handled in assembler. The rest is in C. Therefore, making the transition to AArch64 meant rewriting the little bits in assembler and rebuilding the project. Well, there may have needed to be some bug bashing due to the larger word size, but it would be nothing compared to trying to translate an entire system in large amounts of assembler to the new platform.

And finally, I’d really like to see the SWI mechanism retained for system calls

I think it is nice and easy too, but I’m not sure how well SWIs would work in a C environment. Not to mention, it relies upon a specific behaviour of one particular processor family, so really isn’t a great idea for long term viability.

Please though, can we just stick with ARM based chips?

If the next incarnation is done correctly, it ought to be fairly processor agnostic. Obviously any RISCOS64 will be aimed at ARM, however it would be a massive missed opportunity if it wasn’t able to be “reasonably easily” built for the likes of RISC-V or, even, dare I say, x86.

I very much like the BBC Basic and it’s access to including assembler.

Please use an appropriate assembler for the platform to write bits of code in assembler.
That way we can finally ditch the assembler in BASIC (after three and a half decades of good service). It will certainly save the headaches of “no, your bits of assembler within BASIC won’t run on AArch64”…not to mention reinventing the BASIC assembler to even understand and generate 64 bit code. Really, efforts would be far better spent elsewhere.

Perhaps remove RISCOS from the category of viable daily driver system

Depends a lot on what people expect. To be honest, RISC OS is not my “daily driver” (ugh, horrible phrase). My phone does all that – from emails (IMAP) to Netflix and a dozen things in between.

The reason being, to compete with the mainstream will force changes that remove the distinctiveness of the platform.

That was never a competition that RISC OS had any plans of participating in. I mean, in the phone arena even Microsoft failed, and when it comes to little embedded devices we’re up against Linux.
It would be a losing battle to even attempt to pretend to be mainstream. However, we can think larger than “odd little niche system from when ARM was in its infancy”. Maybe, if it is possible to provide a simpler alternative to Linux, there may be some opportunities there? For this, however, it would be good if we could at least compete with Linux on a more even field, rather than the current “it runs on about six or so different machines ¹ and they’re all 32 bit ARM devices”.

¹ I’m counting the Pi family as one machine type; of which there are, what, about a dozen variations?

Just for clarity, if not already checked, here are the SoC items NOT supported with Circle library currently. On another post here though, sounds like this is changing for some of the new Pis at least.

Not supported:

Bluetooth
Camera
USB device (gadget) mode
USB isochronous transfers and audio

I’ve seen circle, and examined its code to see how the SD interface works (for a different bare metal project). It certainly has its points. (But, I’d forgotten, it’s C++, not C, and also copyleft, which is why I just used it as documentation.)

I implemented an Aarch64 assembler for BBCSDL in the summer. It’s clunky compared to the others, but it works (although I think adding floating point would be at least as much work again).

https://github.com/rtrussell/BBCSDL/blob/master/src/bbasmb_arm_64.c

Sorry, but C (or even possibly Rust) is the way to go for 99% of new code. It’s really hard these days to generate assembler code that’s better than the compiler can (and a lot more error-prone).

I’ve been having issues with getting outline font plotting to happen where and how big I want it (each character is very large and on top of the previous at a fixed location near the bottom left of the screen). Taking Jan Rinze’s advice, I tried tracing execution in RPCEmu (which is beautifully written and a dream to fiddle with), and found a secret FontManager SWI &400bf, and dynamic area handling code both in the module and the dynamic area code in the kernel (the former cut and pasted from the latter).

When the documentation for modules says the module will not receive SWI calls until after its initialisation code has returned, is it missing “unless the module is in ROM, when it will be registered for SWIs (and service calls?) first”?

The SWI in question is here and is called Font_ChangeArea internally.

Looking at this line in the font manager, and this line and this line in the kernel, I would guess that no, Font_ChangeArea will not be called before font manager is initialised.

I find amusing that memory handling for the FontManager and the RAM disc is in the kernel and not in the relevant modules.

Thanks, Julie.

Yes, but the ChangeDyn line checks if a single module has been initialised before it calls the SWI, which is why I wondered about whether all the ROM modules could have been added to the list at the same time, before their initialisation.

        LDR     r1, [r1, #Module_List]  ; any modules active?

André They’ll be first against the wall to be modified to use the published interface.

Yes, but the ChangeDyn line checks if a single module has been initialized before it calls the SWI, which is why I wondered about whether all the ROM modules could have been added to the list at the same time, before their initialization.

Wasn’t the initialization split in 2 parts, with first the minimal set of modules initialized first to allow USB keyboard scan?

Wasn’t the initialization split in 2 parts, with first the minimal set of modules initialized first to allow USB keyboard scan?

Yes, it was, and that probably didn’t include the FontManager.

ModuleInitForKbdScan (HAL_KbdScanDependencies) and ModuleInit.

10
        ; Modules needed for keyboard scanning, no need to list those
        ; before 'FirstUnpluggableModule' since they can't be unplugged
        DCB     "SharedCLibrary,BufferManager,DeviceFS,RTSupport,USBDriver,"
        DCB     "DWCDriver,InternationalKeyboard", 0
20
        ; Two USB controllers on Pi 4
        DCB     "SharedCLibrary,BufferManager,DeviceFS,RTSupport,USBDriver,"
        DCB     "DWCDriver,XHCIDriver,InternationalKeyboard", 0

Long time, no updates. I’ve made progress, but have reached the point where I need to edit the RO code itself. It would be helpful if I could enable the debug output in the Wimp; can anyone tell me how do I do that?

Wimp.Options.s.!Debug. Like the comment near the start of the file says, set the debug option to true, and then turn on any of the other ones you want.

The Wimp uses the NdrDebug debug macros, so check that file to see the different output options supported. Just be aware that some of them do require the module to be in writeable memory, so you’ll either have to softload the Wimp or just cheat and change the kernel so the ROM image is writeable.

Thank you kindly, I’ll give it a whirl!

(Failed at the first hurdle: no writable filesystems!)

Fantastic project! I browsed the github repo today, absolutely amazing!

Thanks. It’s driving me around the bend!

I’m pretty sure there are one or two tiny details I need to fix and suddenly everything will start to work, but I’m *****d if I know what they are.

I’m looking at a OS_SpriteOp returning “Bad sprite reason code” to the Wimp, but that’s only before SpriteExtend is loaded, which seems to deal with that code (0×211). Why isn’t it loaded first, or have I missed something (not for the first time).

I really like your name. Heh heh. Simon WillCOCKS

I really like your name. Heh heh.

🤦🏻‍♀️ Oh, do grow up.

Something’s not right with the fonts, but I’m getting recognisable desktop screens now.

https://github.com/Simon-Willcocks/RISC-OS-Kernel-in-C/wiki

Nice well done.

Nice job Simon! :)