Linux Port

Is the “Networking” section of the source nonfunctional still or am I just doing something wrong?

e:Sorry about the mistake. Anyway what I mean, now I have a keyboard, is whether there is any translation layer for networking, or just the networking modules with nothing to talk to.

The stub Internet module translates Socket_ SWI calls to the equivalent Linux system calls, it currently currently does not implement the FIOSLEEPTW and FIOASYNC ioctls (Taskwindow sleep and Internet events), SO_DEBUG, SO_TYPE, SO_RCVTIMEO, and various IP socket options.

Netsurf works, and have just implemented FIONREAD which is sufficient to make WebJames work.

What are you trying?

*ping some.lan.ip.address
ping: socket: EPROTONOTSUPPORT

Netsurf says no DNS servers are configured.

In “Network” only Econet isn’t greyed out.

Packman can’t resolve anything.

That’s about as far as I got.

Tristan, you need to either run a DNS server on 127.0.0.1 (localhost) or configure Resolver with the IP address of your DNS server using the command line interface:

Set Inet$ResolverDelay 2
Set Inet$ResolverRetries 3
Set Inet$Resolvers 127.0.0.1
Set Inet$LocalDomain default
ResolverConfig

ping: socket: EPROTONOTSUPPORT

I have tried altered the validation to accept opening RAW sockets, but ping crashes. It would also require extra permissions.

In “Network” only Econet isn’t greyed out.

In configure? How did you manage to open it?

Posting from RISC OS Linux running in Armbian mainline on a Pinebook.

That did the trick. Excellent!

Sorry about the Configure thing. I was thinking of “Configuration”

I’m back in business now, so to speak.

I saw mention of a patched !GCC somewhere I think. Is that available?

I’ve done a bit of work on GCCSDK and have uploaded a patch and modified SharedLibs to: http://timbaldwin.fastmail.co.uk/GCCSDK_RO_Linux_1/

It needs work doing on the signal handling etc, at present it will crash if you press escape etc.

I haven’t tried gcc yet.
Glad I left mention of how I added the middle button. Accidentally reset the repository and lost the functionality.
Incidentally I tried StrongKey without the menu button being mapped to the mouse. As far as RO is concerned it has the same scancode as esc, so I guess it’s just not mapped.

Does the desktop still run if the SDL or OpenGL renderer isn’t executed?
Out of curiosity I just set up the RO VNC server on the Linux port. I gave it some compression and turned on the screen update tracking filter. It worked. Obviously the framerate was lower on the VNC client window but that’s not the point. I know the rendering frontends are real resource hogs. At least the SDL one is. If RO Linux could be ran “headless” on something, perhaps even with the host running VNC on another port (if the whole device is headless) it would get around the SDL rendering issue via VNC and allow the use of the Linux host xorg too if desired.

Just a thought anyway. My main use case is so I can use something a little more powerful than a headless Pi Zero running RO.

I had a post disappear into the great unknown earlier apparently. That’s unfortunate.

Short version. I got networking and VNC set up and altered a copy of run_RISC_OS that doesn’t run the front end. It worked fine.
Trouble is even after disconnection from VNC the RISC_OS process usage remains at 100%. I suspect this may be more of a VNC server issue.

Was this a new version of https://sourceforge.net/projects/riscose/ which I recently found again?

No. This port allows RISC OS itself to run on Linux. Therefore you can run RISC OS apps, because RISC OS is running.

Riscose aims to implement RISC OS SWIs with a load of C code and includes an ARM emulator. Therefore, you can run RISC OS applications, because there is a RISC OS compatible runtime. I don’t think riscose got very far. There would be many Acorn and third party SWIs to implement. It is a bit like WINE, which tries to achieve the same for Windows apps.

I think someone else started a similar project to riscose, but I forget its name.

Therefore you can run RISC OS apps, because RISC OS is running.

Are there any tests or benchmarks comparing app speed running natively to app speed under the port, on identical hardware? AIUI, this Linux port has relatively low overhead costs, but utilises hardware more fully than current native OS versions, so should in practice be faster.
Is there any anticipated timescale for the release of the port in a form non-Linux adepts without specialist tools can easily install? I’d like to have a play, but just don’t know Linux anything like well enough, if the posts above are anything to go by.

I think someone else started a similar project to riscose, but I forget its name.

Are you thinking of this? ROLF – An alternative GUI for Linux

That’s the one! I remember reading that blog post about running AWViewer some time ago.

I have not tried the Linux port, as I don’t have a machine set up running Linux. I guess I could create another SD card for my Pi, but RISC OS already runs on there…

What’s the correct incantation for running run_RISC_OS with the OpenGL fronted?

RISC_OS__GUI=Built/opengl ./run_RISC_OS

My RiscPc is getting very long in the tooth like me and I wondered if there’s any progress towards a “snap” of this port that I could try on my Ubuntu 19.04? I dont have any software compilation tools or mind paying for the port if I can run some of my software like Artworks and Impression.

This may sound silly but why not get a Raspberry Pi model 2 or 3 (cost £30), a USB pen drive to transfer data, the free Aemulor and then you know that it will all just work. If your copy of Impression predates the dongle-free version then £60 to !Store will get you Impression-X (as well as 5.13, the final, dongle-free version).

Not silly at all. Ive RPis (x3) but wanted to run on one box, USB external storage, keyboard and mouse.. Actually that’s wrong as I have a portable as well and they all use a NAS as well which can take a pen drive with the RISCOS software on it. for storage. Hence a snap.

Stupid question, but does someone as a working version for the latest Raspbian used by the Pi4?

Why does FPEmulator as provided by ROOL fail to assemble on IXFS (over Tmpfs or Btrfs) but succeed on Filecore, TBAFS, DOSFS (with only Sources.HWSupport.FPASC being a DOSFS image) and Rpcemu HostFS?

It fails by trying to include a directory as a assembly source file:

FPEmulator (Sources.HWSupport.FPASC.riscos)...
do mkdir -p o.Linux
do mkdir -p rm.Linux
create o._dirs
objasm -PD "FPEAnchorType SETS \"0x21900000\"" -APCS 3/32bit -PD "CoreDir SETS \"^.coresrc.s.\"" -PD "VeneerDir SETS \"^.vensrc.riscos.\"" -PD "FileExt SETS \"\""   -I^ -depend !Depend    -g -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"Linux\"" -pd "UserIF SETS \"Sovereign\"" -o o.Linux.FPEmulator s.Linux
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: File "^.RISCOS" could not all be loaded at line 107 in file ^.RISCOS
 included by GET/INCLUDE directive at line 107 in file "^.coresrc.^.vensrc.riscos.options"
 included by GET/INCLUDE directive at line 63 in file "^.coresrc.s.main"
  107 00000000         GET     RISCOS
Error: Bad GET or INCLUDE at line 107 in file ^.coresrc.^.vensrc.riscos.options
 included by GET/INCLUDE directive at line 63 in file "^.coresrc.s.main"
  107 00000000         GET     RISCOS

The workaround is to change “GET RISCOS” into “GET Hdr:RISCOS”, but what is the actual cause?

IXFS behaves similar to Filecore:

>*DIR IXFS:$.dev.shm
>*CDIR X
>*LOAD X 10000

'X' is a directory
>H%=OPENIN"X"
Opened directory $.dev.shm.X 0
>PRINT BGET#H%

'IXFS:$.dev.shm.X' is a directory
>CLOSE#H%
>H%=OPENUP"X"
Opened directory $.dev.shm.X 2
>PRINT BGET#H%

'IXFS:$.dev.shm.X' is a directory
>CLOSE#H%
>*ChangeDynamicArea
>*ChangeDynamicArea -ramfssize 1000K
>*RAM
>*CDIR X
>*LOAD X 10000

'X' is a directory
>H%=OPENIN"X"
>PRINT BGET#H%

'RAM::RamDisc0.$.X' is a directory
>CLOSE#H%
>H%=OPENUP"X"

'X' is a directory
>PRINT BGET#H%

Handle is either illegal or has been closed

Arranging for H%=OPENUP"X" to return an error does not fix FPEmulator builds.

The pre-built RISC_OS from latest source always aborts with the following. Using a working rom to build the latest version from source also aborts. The last working version I have is built from source on 31/12/18.

14 of 14 interrupts counted.
Starting kernel...
HAL initialised
IICInit
InitCMOSCache entry
InitCMOSCache failed
IMB_Full done
InitDynamicAreas
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
Machine ID duff,zero substituted
KeyInit
OscliInit
Enabling IRQs
IRQs on
Debug terminal on
HAL_InitDevices
Error: UndefinedInstruction:Undefined instruction at &2201ABB0 (Error Number &80000000)
*

Stupid question, but does someone as a working version for the latest Raspbian used by the Pi4?

Current versions don’t seem to work but an older one from December runs fine on the RPi 4 using Raspbian.

The pre-built RISC_OS from latest source always aborts with the following. Using a working rom to build the latest version from source also aborts. The last working version I have is built from source on 31/12/18.

I’ve tried it with a Amazon Web Services A1, and it also fails. But it worked on my Chromebook and Raspberry Pi 1.

I had made a mistake in calculating the address of RISCOS_AddDevice (the offsets in table of kernel entries are relative to the base of the table, not the base of the kernel) so the HAL was jumping into the middle of a literal pool and faulting on “MSRCS SPSR_s, R0”

Then I found that in a test case I had misaligned a label so it was calling 2 bytes before the the code.

I have uploaded a fixed version.