ROOL Forum: Recent posts

Mon, 13 Jul 2026 00:06:44 +0000

V1.02 (13 July 2026)
ChangeLog – Updated Download Live

New
Ultrawide and large screen modes — up to 3840×1600, including true ultrawides (3440×1440, 2560×1600, 3840×1080); 40 modes total at 60/75Hz. Large modes are offered at 64K colours where 16M won’t fit the 16MB VRAM.
High-refresh support — video refresh rate now settable up to 144Hz for ProMotion/high-refresh displays (was 100Hz).

Changed
Audio now plays at a clean, fixed 44,100Hz — the emulated sound is resampled to the host rate rather than reconfiguring the Mac’s audio device to each odd rate RISC OS requests. Pitch is preserved (duration-accurate resampling, not a relabel), and the constant device rate removes rate-change glitches.
Performance

Kinetic SDRAM fast path — since RISC OS runs from the on-card SDRAM, nearly every access was taking the slow route; SDRAM now uses the same cached fast path as motherboard RAM, for a machine-wide speed-up.

Issues Fixed

Intermittent crash during screen redraws (out-of-bounds write-cache invalidation for frame-buffers at certain physical addresses) — a long-standing latent fault; large modes are now stable.
Host and RISC OS mouse pointers drifting out of alignment in windowed mode when the window was scaled to fit.

Sun, 12 Jul 2026 22:45:53 +0000

Virtual Kinetic Box V1.01 — a Kinetic Risc PC for Apple Silicon Macs

I’m pleased to announce the first release of Virtual Kinetic Box — a ready-to-run Acorn Risc PC Kinetic for modern Macs, built on the excellent RPCEmu.

Ever wanted the Risc PC Kinetic Emulator but never quite shipped? A Kinetic with the full complement of on-card SDRAM, a fat VRAM allocation, and a modern monitor? That’s what this is.

The Machine

- Custom 5.31 ROM Fully Configured RISC OS One Distro
- Kinetic StrongARM Risc PC running RISC OS 5.31 (IOMD build), booting straight to a fully configured desktop
- Up to 384MB RAM — 128MB motherboard DRAM + 256MB on-card Kinetic SDRAM, detected and sized by RISC OS exactly as on real hardware (the OS relocates itself into SDRAM and runs from it, just like the real card). Configurable 128/256/384MB – the 384Mb is the Limit!! the Address space of the IOMD does not allow 512MB Safety to run apps in a stable mode (so don’t ask) it will run in 512MB if you want zero networking :)
- 16MB VRAM, with RISC OS 5’s sizing fully aware of it
- Resolutions up to 2560×1440 @ 75Hz, selectable live from the Display Manager — the VIDC20’s 110MHz pixel-clock ceiling (a real-hardware limit that makes no sense under emulation) has been lifted, so the mode list finally matches what the emulator can display

The Mac side
- Native Apple Silicon app, no dependencies to install — everything’s in the bundle
- Metal GPU-accelerated display — the frame-buffer is scaled and drawn by the GPU, not the CPU
- Pixel scaling option: crisp integer scaling with nearest-neighbour sampling for that proper sharp-pixel look in games; smooth aspect-fit when you’d rather fill the screen
- Full-screen at startup option
- Two-button mouse mode: right-click is the RISC OS Menu button, so Mac mice and trackpads just work

Networking, out of the box
- NAT networking with DHCP — boot up and NetSurf just works
- ShareFS/Access discovery across the NAT, so your emulated machine can see real RISC OS boxes (and other instances) on your LAN

Other CPU’s are there too, StrongArm SA-1110 ARM610,710 and A7000,A7000+ with FPA10 Support

Install
Download the .dmg, drag the Virtual Kinetic Box folder somewhere writable, right-click → Open the app (first run only — it’s not notarised), point it at the folder when asked, and you’re at the RISC OS desktop. Defaults to 1920×1080; go up to 2560×1440@75 from the Display Manager if your screen allows.

Website: https://riscosone.co.uk/index.php?/files/file/9-virtua…

Credits & licence
Virtual Kinetic Box is built on RPCEmu and released under the GNU General Public Licence v2 — enormous credit and thanks to the RPCEmu developers, whose work this stands on. Modified source is available on request per the GPL. RISC OS is © RISC OS Developments Ltd / RISC OS Open Ltd.

Feedback, bug reports and mode-file contributions very welcome!

I will only be making a Mac Based Version

Future version work started: 64MB XVid Podule with 2D Blitz for 4k Resolutions (matching Vpod or Viewfinder)

Sun, 12 Jul 2026 19:53:00 +0000

Colin/David i have a Kinetic Version all working and had for a while on my Apple Silicon , will be posting soon.
It will come with a Installer so no messing around with QT Dependencies

Starts up in Fullscreen mode
Kinetic Support with 512MB Ram + 16MB VRAM with 2K Resolutions

It does help when you actually have the real hardware to probe to get this stuff working
Sorry been absence for a while, working on multiple projects a couple top secret – will have to wait for the London Show to see them :)

Plus opening a Shop too, as if i wasn’t busy enough!

Sun, 12 Jul 2026 18:42:19 +0000

Files taken from the Luminist archive ought to work with !DeBrown or !DeBrown2.

The program checks for ImageMagick 7 and InfoZip. Not sure that it checks for !PDFUtils — so best make sure it has been seen by the filer. (If you were getting results before, then it must have been.) The messages about “stored” and 0% are from InfoZip — I set it just to store the files and not attempt to compress them since attempting the latter results in a corrupt .cbz file.

With !DeBrown2 the files are modified “in place”. If you have a way of seeing thumbnails of the files you should see them gradually being cleaned. If they are unchanged then it would seem that mogrify is either not being called or is failing for some reason. There should be messages about mogrify being called appearing on the screen — though I find text on the little window in the centre of the screen i not very easy to see…

Sun, 12 Jul 2026 18:00:16 +0000

Drive numbers are allocated on a first-come-first-served basis. If your NVME drive always starts up faster than your SATA drive, the obvious solution would be to change CMOS to boot from drive 5.

There was a discussion on this matter several years ago (2018, at a guess) – sadly I can’t find the thread in question. As I recall, someone (Jeffrey Lee?) proposed a mechanism whereby SCSI drive 4 would only be allocated if the drive ID matched the value held in CMOS RAM: this would be controlled by a “reserve drive 4” bit elsewhere in CMOS. The paucity of unused space in CMOS may be a problem¹.

Another mechanism (that would only work for the Raspberry Pi) would be to supply the drive name as an optional parameter in CMDLINE.TXT: the rest of the process would work much as for the CMOS case discussed previously.

¹ Well, the cross-platform portion of CMOS. The Raspberry Pi CMOS has plenty of unused space beyond byte 256.

Sun, 12 Jul 2026 17:09:36 +0000

JPEG2000 files are file type &A65.
An experimental command line decoder, which has been created for PhotoDesk, is available at https://coleman.orpheusweb.co.uk/downloads/djp2000_v10…
This includes a file type sprite, which will need to be *Iconsprite’d.
It will create NetPBM files: P5 for greyscale images, P6 for RGB images, and P7 if the JPEG2000 image has an Alpha channel.
There is currently no RISC OS software to read P7 type files so let me know if you come across one of those and I’ll see what I can do.
My email is in the zip file, so any problems with it please do let me know.

Sun, 12 Jul 2026 16:43:15 +0000

Now puzzled that the link I gave seems to ignore the final “/EQMM.htm” It should be in the URL and take you to the actual EQMM list.

Sun, 12 Jul 2026 16:38:32 +0000

My apologies! The copy of EQMM_1950_05 that I have is from the “Luminist” site.

As per: https://readitfree.org/PU/EQMM.htm

I’d assumed the ‘Archive’ site as some other files in the same directory had come from there. (I find the Archive a PITA to use, but sometimes have Hovson’s Choice!)

I’ll try again, but am probabl doing something wrong. Is there a set of “Filer_Boot” commands I can launch when loading DeBrown2 to ensure it works for me?

The processed front cover is an annoyance, but a secondary matter compared readability of the body text!

I should explain that I do hope, sometime, to get Compo able to process an entire magazine. If I can do that I can get it to offer a user option to leave colour covers in colour But I’ve not done any programming recently due to being a 24/7 carer, etc. The distractions/gaps mean I keep forgetting the details of what I’ve done as well as how to tweak and add features. :-/

Similarly, I’ve managed to re-lose the handbook for me ARMX6 that I found two days ago! Need it as the keeper battery probably needs replacing and I want to check what type of battery and where it is in the machine before I pop the box.

Sun, 12 Jul 2026 16:01:18 +0000

Further to my previous comment about the number of different types of download available for a particular item on the Internet Archive. The “full text” download is little use. There is a download of a zip file of .JP2 (JPEG 2000) files. The “ABBYY.gz” file is an XML file of paragraph styles that doesn’t seem to have any relevance that I can see.

There is also a download of a Comic Book archive. But the type of archive varies. For EQMM-1953-05 it is a .cbz file, and unusually all the pages are “clean”; you could download and view this as it stands. However for “Scientific Detective”, it is a .cbr file — a .rar archive rather than a .zip. I’ve no idea whether SparkFS can handle these or not. But the file for “Scientific Detective 4” does not have clean pages. The files in the archive however, in each case, are standard JPEGs, one for each page.

BTW, the reason why there isn’t an option not to process the first page is that I’m using REPEAT to process the JPEG files. The reason why the input files in your case are not being processed is quite simple — !DeBrown2 assumes that the input files are JPEGs, and REPEAT works by specifying the type of file. But these are not JPEG files in this case, but JPEG2000 files which I assume have a different filetype.

Sun, 12 Jul 2026 15:18:09 +0000

RPi3B, RO5.31 (29-Jun-26)

This machine has run for ages with one non-removable drive, a SATA SSD with a USB adapter. It is drive SCSI::4 and it’s called HardDisc4.

Recently I tried, as an experiment, adding an NVME drive with a case and USB adapter. Suddenly the original drive became SCSI::5, though still of course named HardDisc4, and the NVME drive became SCSI::4. Of course the machine would not now boot because the NVME drive didn’t have a !Boot on it.

What determines the drive numbering in the case of USB? Is the numbering going to be consistent for a given combination of drives/adapters? Is there a way of imposing the mapping that I choose?

It doesn’t help that one can only specify a drive to boot from by number. Name would be more helpful. We’ve got all that spare space on the SDFS boot drive or partition where we could put a mapping.

Sun, 12 Jul 2026 14:33:03 +0000

Oh, it might — depending on the site where you downloaded it.

I cannot find EQMM for May 1950 on the Internet Archive (archive.org) — I assume this is the site you mean? I can find the one for May 1953, however.

There is a problem with any of the scans on the Internet Archive. At the moment I am unable to find a satisfactory way of converting them to image files. Using pdfimages as before, but forcing output to .png, produces three images for each page in the input file. Only the third of these contains the text — as white on black. If you invert these images you would get a correct and non-stained image which would not need debrowning. I did this on the Pinebook Pro but under Linux. It took about 5 minutes to complete a test run on a PDF containing 6 pages of Scientific Detective (a magazine you had mentioned previously).

I suspect that RISC OS would be no faster (and it will be slower if pdfimages makes use of more than one processor core on Linux). You’re looking at over an hour for a full magazine. It would also use a lot of disc space as it would be generating 300 images or more. When you get the images you would need to keep only every third one — that is to say 002, 005, 008, etc. You could then get !ConvImages to invert them and zip the result to get a .cbz file. No “debrowning” as such is required.

I’ve tried using mutool as an alternative. It produces stained images as expected, 1 per page, but too low in resolution to be readable.

As it happens, this particular issue of EQMM is on Luminist and should be debrownable in the usual way. I’ve just processed it using a shell script on the PBPro and it completed in less time than generating the omages for a PDF with 6 pages…

Where you can only get a magazine file from the Internet Archive, I can’t see a satisfactory means of treating it at present. However you can download other formats than PDF. One of these is a .zip file containing .jp2 (JPEG 2000) images of the pages, but I’ve no idea whether these can be opened on RISC OS.

Note the issue is with the generation of the images for each page — this would equally be a problem if you were using !Compo, I think.