Linux Port

Hi all,

according to GraphicsV documentation there should be a possibility to enable shadow screens for better animation. I have been looking into the code and it seems this swi is not supported yet.
The SDL code will require an offset on ‘pixel’ before blitting and this offset should be properly computed from the values sent by the swi.

I hope people understand what i am talking about and can help out to get this working.

Best regards,
Jan Rinze.

Many many years ago I wrote an Internet module for Red Squirrel which passed across calls to the Windows network stack. It was a pretty horrible hack, but it worked for the limited amount of testing I did with it. Strangely enough just after I donated the source, something very similar appeared in Virtual Acorn.

I’ve still got the source somewhere, it wouldn’t some of the workarounds for Windows non-BSDness, but the big question is how are Linux calls be made from RISC OS?

Many many years ago I wrote an Internet module for Red Squirrel which passed across calls to the Windows network stack. It was a pretty horrible hack, but it worked for the limited amount of testing I did with it. Strangely enough just after I donated the source, something very similar appeared in Virtual Acorn.

Would be great for RPCEmu IMHO.

As with this project, details of the guest to host API are needed.

Many many years ago I wrote an Internet module for Red Squirrel which passed across calls to the Windows network stack. It was a pretty horrible hack, but it worked for the limited amount of testing I did with it. Strangely enough just after I donated the source, something very similar appeared in Virtual Acorn.

Did you post this to the RPCEmu list as well at some stage? If it’s the same one (called VANetPodule or something like that). I did have a go at getting it working with RPCEmu and had some success (I can’t remember how much now).

Unfortunately I couldn’t get the podules to load properly at start up (they completely hung the machine with RO5 on RPCEmu) and moved on to looking at other things.

If anyone wants to continue with it, I’m happy to send what I had, but be warned I was also messing about with building RPCEmu in Visual Studio at the time so it might not be in such a good state.

The RPCEmu code had the ability to load Windows podules removed several releases ago, so I had to add that back in as well.

This weekend I sat down to see if I can come up with a solution for the shadow screens.
The result can be found on github .

Two things I noticed when trying to experiment with it:
- max screenmemory is 16MB (because it is a podule?)
- CPU heavy for animation but very smooth.

On a side note, the a sound system yet so many demos or games will fail with the no SWI&40182 or such.

Quick update:

Simply switched on the modules for sound in the Linux ROM and now running !Doom smoothly. :-) (no sound output yet..)

Also made an OpenGL backend for RISC OS too. (my Acer lappie has a Tegra K1 with very good OpenGL support.)

I will look into the sound handling of RPCemu and see if it is possible to transplant that to get sound working.

See: github

I’m wondering how i can keep the repo up to date with the changes from the RISC OS CVS.

Maybe a script or something could help here?

I tend to keep the RISC OS sources in a Mercurial repository, using “hg convert” to pull the changes. I’m sure that, if git doesn’t have a tool/command to do this, there’s probably something that will. One tool to look at is tailor.

I’m back. After few days work I’ve updated it to the RISC OS CVS from 23rd December. This is uploaded as a new rebased branch so I’ve got a clean set of patches for ROOL CVS. The only difference between the tip of the Linux branch and the Linux2-start tag should be

Other recent changes:

• Use of Linux header eliminated with an automatically generated headers for constants and a manually created header for types. All types and constants (except system call numbers) should be prefixed with ix_ to avoid collisions with RISC OS definitions.
• Support for writing ,xxx filetype extensions where POSIX extended attrubutes are not supported. I can now run builds in Linux tmpfs.
• Solid window drags seem to be broken.
• Added a flag to Fileswitch for requesting open and create to be passed to the filing system, rather than seperatiley calling the filing system to create, then open, then only if the file is buffered truncate it.
• Juggle the memory map so that dynamic areas occupy a continuous range of memory.
• Use the upstream implementaion of CheckMemoryAccess, this will mean it returns the wrong results if memory is allocated by directly calling mmap.

Planned changes:

• Replace IXSupport_PatchTable with OS_PlatfromOps and include a cmpxchg implementation
• Rename symbols beginning with __PVirt to start with __PlatformOps

Under consderation:

• Detect screen memory changes page faults.
• Move the path handling parts of IXFS to a seperate Linux process
• Then use seccomp to restrict the system calls RISC OS can make.

This weekend I sat down to see if I can come up with a solution for the shadow screens.
The result can be found on github.

I’ve had a look at SDL multiple screens code in the branch Linux_opengl commit 19ef451bec190b0a279d799e0e0743973f8094e8 and have a few comments.

• There is no protection against the screen memory being resized from RISC OS whilst the SDL process reads from it, making a crash with SIGBUS possible.
• It’s more restricted in the start address than GraphicsV, one could call SDL_CreateRGBSurfaceFrom for every change in start address.

- max screenmemory is 16MB (because it is a podule?)

No it’s not an emulator. It’s the value VideoSizeFlags is set to in caste.RiscOS.Sources.Kernel.s.Linux It’s trivial to alter, just don’t consume too much address space.

but the big question is how are Linux calls be made from RISC OS?

Load the system call number into r7 (constants in the Objsam header LinuxSyscalls) then either call the SWI IXSupport_LinuxSyscall, provided by the module IXSupport.

Or more directly call __HAL_LinuxSyscall, which is simply defined in HAL as:

__HAL_LinuxSyscall
        SWI    0
        MOV    pc, lr

The address of the SWI instruction is significant! A seccomp filter is installed which causes SWI instructions at other addresses to raise a SIGSYS signal, the signal handler then transfers control to the RISC OS SWI handler. To find __HAL_LinuxSyscall from a ROM module link to ${PVLIBS}.

From ROOL C you can use the header file “ix/syscalls.h”, define ix_SYSCALL_branch to use the branch rather than the IXSupport_LinuxSyscall SWI.

I have written partially written a shim Internet module which is sufficiently complete to browse this website in Netsurf. Currently however DNS does not work, so one has to add the IP address to the hosts file.

When it encounters an unrecognised call it print details out to standard error.

I am using it to post this message.

SWI 0

The standard Linux way, to avoid having the SWI number in the instruction (and thus the need to treat an instruction as data in order to extract it ¹). :-)

But… What do you do about OS_WriteC?
[Edit: ah, that’ll be what the SIGSYS is for, yes?]

¹ I don’t know why ARM never optimised SWI to place the number into a special register or somesuch

May be a daft question but would it be possible to use this system to use Linux device drivers within RISC OS ?
Say we wanted a wifi system is it possible to connect to the device driver running on a minimal Linux kernel on a seperate core and use the required software SWI to communicate with RISC OS? Or Using the Linux kernel like a Hal for RISC OS

Or Using the Linux kernel like a Hal for RISC OS

That’s kind of what the Linux port is doing, from RO’s perspective anyway.

I just want to say I find the Linux port a useful tool and don’t feel it dilutes RISC OS as an entity. It has some uses on ARM architectures with unsupported chipsets.
If it were possible to compile GCCSDK for ARM32 platforms, it would be a little more useful to me as a development environment. Currently I just use a !Nettle session to another machine with GCCSDK and have an NFS share.

I’m making a backwards incompatible change to filetype handling, currently IXFS prefers POSIX extended attributes to ,xxx suffixes. I will change it prefer reading suffixes over extended attributes and (by default) remove extensions that are no longer correct.

If you have some files with out of date extensions you can fix them like:

./comma2attr --attribute-priority --recurse /path/to/directory

Should IXFS (RISC OS filing system that translate to the Linux API) be a seperate module, like is the traditional for RISC OS filing systems?

I think it’s mostly up to you. As long as it’s in a module, I don’t think the OS cares which module it is.

Progress report:

• Filetype handling configurable using special fields
• Shift-Break now works as key state resent to RISC OS on reboot
• Fileswitch can pass though imagefs files
• Symbolic links to directories appear as imagefs files, thereby preventing inappropriate traversal.
• Filer now allow imagefs files as applications
• Optional case-sensitivity of file names (Fileswitch may cause problems).
• Scripts now run RISC OS in a namespace based sandbox using Bubblewrap.
• Well defined exit codes if RISC OS fails to start.
• Files and directories in unreadable directories can be accessed.
• A usable binary download

I still need to request SWI numbers etc.

What do we need to be able to run gcc in this version of RISC OS?

*gcc
Internal error: abort on data transfer at &9B7F00E0

Since there is code to patch at runtime, can’t we use it for a tool to patch the libraries manually?
That way we can patch the ‘bad’ instructions that cannot be patched during runtime due to the way it is loaded.

I have written partially written a shim Internet module which is sufficiently complete to browse this website in Netsurf. Currently however DNS does not work, so one has to add the IP address to the hosts file.
When it encounters an unrecognised call it print details out to standard error.
I am using it to post this message.

Just add ‘set inet$resolvers 8.8.8.8’ in the !run file of the browser and it will resolve the DNS.

What do we need to be able to run gcc in this version of RISC OS?

Here is a source patch for GCCSDK.

Just add ‘set inet$resolvers 8.8.8.8’ in the !run file of the browser and it will resolve the DNS.

Or have a DNS server running on localhost.

Hi. I’ve recently successfully built this in aarch32 and aarch64. Still works fine. May I suggest an included shell script for normal usage?

I have a question about the graphics. Yes I’m being lazy and don’t want to dig in to find out. IIRC the size and resolution causes a performance hit. Can I assume it’s copying from its “VRAM” to an SDL surface constantly?
If I’m right, is it feasible just to have RO write to its VRAM in a manner compatible with SDL (or anything else) and have it create a surface pointer with the correct resolution (and colour depth / mode? It’s been a while) just pointing to the VRAM? I’m guessing double / triple buffering could be made to work like that too. Again, been a while.