ROOL Forum: Recent Posts

Wed, 02 Dec 2020 11:35:06 -0000

In case it helps, I noticed that *pointer 1 (turn on pointer) in an obey file leads to a “press space or click mouse to continue” message, which surprised me.
However, having tried echo-ing some things then running another obey file (ie. two echo lines, then a “run xyz”), it auto-paused to click mouse/press key. So, I’m not sure you’d actually need to do anything.

Wed, 02 Dec 2020 11:25:44 -0000

@DavidS

Thank you for solution with Basic.

Wed, 02 Dec 2020 09:59:47 -0000

I’d be interested in attending such a call. I get extremely little time to work on RISC OS these days (family etc) but I did make a start on reworking the window manager in to C some years back and would be happy to share my experiences of that.

Wed, 02 Dec 2020 08:39:27 -0000

By moving to C did you mean from ARM assembler ? In which case I certainly agree. But at the moment the shared C library cannot use VFP or Neon,

I am aware, the qestion is how much of clib do we need?
There is a very small stub in HAL, which I have used . I think it might be worth investigating using Norcroft to start with.

When I say kernel , I mean Kernel, not the complete ROM.

There are things , MMU activation is a good example that needs to be assembler.

Wed, 02 Dec 2020 08:04:32 -0000

HFORM might run on older machines, but out of the box it will produce discs which wont work with anything before 5.2x due to using an ID Len larger than the maximum on older OS’s (21 vs 19).

Sure about that? The bounds HForm uses are:

IF FileCore <= 2.98 THEN
  max_idlen%=15
ELSE
  REM Allow big directories too
  IF FileCore <= 3.74 THEN
    max_idlen%=19
  ELSE
    max_idlen%=21
  ENDIF
ENDIF

Wed, 02 Dec 2020 07:05:38 -0000

Does anyone have a copy of (or know a source of) HFORM for RISC OS 3.1 that doesn’t have anonymous variable and procedure names

You’ll want the uncrunched HForm 2.56, which is attached to my RISCOS 3.20 ROM thread on StarDot

Wed, 02 Dec 2020 05:04:07 -0000

@Norman Lawrence

If so, then perhaps a 64 GB emmc and 250 ssd would be a better option for the laptop.

Yes that is a possible option. But the NVMe driver might not be ready yet at time of the shipping. So the NVMe driver will be delivered as software update at a later point.

@Chris Hall Thanks!

@DavidS

Is not that a bit of overkill for pure ARM code?

program in ARM assembler is quiet fun and you know what your program is doing then 100%. C is of course better for portability reasons ( to 64 bit for example)

I look forward to finally having a standard method of sound input, instead of a per HW type different modules system as we have had to this point.

That was the initial motivation for the new sound system as in the past it was like everyone hacked their own hardware implemention. And we need a new one for the new RK3399 boards. So with Jason’s implementation all aspects of a modern sound system should be well organised and future proofed.

Wed, 02 Dec 2020 02:41:05 -0000

YET ANOTHER OFF-TOPIC THOUGHT:

I was looking through my backup thumb-drive that has all of the backup stuff that I still have from before the medical loss of home et al. There are directories devoted to American software for RISC OS, Atari, and Amiga. This got me wondering how much American software is lost to history?

You see it is a common thing here for coders to exchange some software at various gatherings, and sell there works in local computer stores that support there platform. It is fairly rare for US coders to put anything on the internet, unless it is part of a project already online.

While probably not very much RISC OS stuff (never a lot of users over here), it did get me thinking about how much stuff has been lost to history. Even in the stuff I have on my backup I can not find most of the American stuff online. That goes for the Atari stuff (my biggest American Software backup, over 3GB by itself, most titles less than 100KB each), Amiga stuff, or RISC OS stuff (only about 20MB worth of RISC OS stuff on my American software backup).

The American source software I have on my backup I know to be only a very small fraction of what there was, and I know that most of the American stuff never made it to the internet (and good luck contacting the owner/coder). Yes it is unlikely to have a significant effect on RISC OS, though it does still put forth the question. How much is lost because us Americans are stuborn about putting much on the internet?

Wed, 02 Dec 2020 02:21:47 -0000

I do wish we had a quick and dirty (minimally optimizing) C Compiler available to get the intermediate work done without spending so much time in compiling.

Wed, 02 Dec 2020 02:18:00 -0000

As much as I dislike the concept of jumping ISAs, I will likely still be using RISC OS thereafter if it does happen. As such I will be doing a bit more in C, especially as releated to the OS and potential enhencements.

I think that while the PMT may be worth postponing a little, it is still worth a rewrite of the components that make up the WIMP API. I think I will begin with the Window Manager, and work out from there as time and patience allows.

Yes I would strongly prefer RISC OS stay AARCH64, though I will not stand in the way of a future either. So I guess RISC OS will become somewhat like Amiga in that the CPU is not as important, beyond it being RISC.

So I am digging into the existing code for the Window manager (mostly Assembly) to see how it is structured, so I can figure out a clean path to a full C convertion.

Wed, 02 Dec 2020 02:12:42 -0000

Well I am back at the libraries project. I will be using C for code from here, as it seems that there may be a need of being ISA neutral.

While I do not care for the idea of jumping ISAs, I will still likely use RISC OS, so long as it stays as simple as it is. Though we will likely need a better native library form in some way or another, because the AARCH64 does not have an equilevent to SWI with a comment feild.

Some things will always be ARM Assembly for me, even after we jump ISAs, if we do. We are going to need the Emulation Layer to get away with jumping ISA anyway.