RISC OS FAST

RISCOSbits are very excited to announce the release of RISC OS FAST and the launch of the first machines using the technology at the SouthWest Show.

RISC OS FAST stands for ‘Fast Access Storage Technology’ and is a custom RISC OS ROM paired with specific hardware to convert the PCIe port on Raspberry Pi Compute Module IO board to provide four full-speed SATA ports.

As an indicator of the potential of this technology, when combined with the speed of the processor of the Compute Module 4, it can compile a new RISC OS ROM faster than any other RISC OS system currently released.

RISCOSbits plans to release four ROM updates per year, to keep the ROM in line with wider developments in RISC OS. The ROMs will be available from a special download site and password protected to be available for RISC OS FAST users.

In addition to the SATA driver, more disc-based developments are planned for RISC OS FAST and many of them are already underway. These include:

Bigger disc support, for drives up to 2TB and more – already well underway (we have a 1TB drive up and running)
4Kn/512e disc support – useful for using many of the less expensive larger drives currently available
Multi-format drives allowing RISC OS and Linux to use and share partitions on the same drive – in progress
NVMe support – in progress
CDFS on SATA – almost complete

Many of the developments will hopefully be fed back into the standard ROM builds.

The first system to be launched using FAST is available to buy at the SouthWest Show at a special introductory price. The limited number machine comes in a very stylish aluminium case, slightly reminiscent of fruity mini systems, and has the following specs:

2GB RAM – user upgradable
CPU at 2GHz – user overclockable
250GB SATA III SSD
3 spare SATA III ports
2x rear USB ports
2X front USB ports
4k capable HDMI port
Gigabit Ethernet
32GB micro SD for firmware and back up
Real Time Clock
Fanless cooling

Further developments are planned for future systems, and will also be available to ‘early adopters’ including:

Full ATX power supply support
Integrated Real Time Clock support
Over The Air ROM updates

We’re also offering bargain access to RISC OS FAST for those RISC OS users who already own a Compute Module 4, with a CORE kit of a 32GB micro SD card pre-loaded with the necessary firmware and FAST ROM plus the specific SATA adaptor to get the FAST speed under RISC OS.

So make a FAST dash to the RISCOSbits stand to check out the wireless-enabled demonstration model and see if there’s a system left to buy!

Or if you’re not at the show, check out the FAST information page at www.pihard.co.uk/fast.htm

This looks really impressive! When do you expect the FIRE and FURY to be available?

I was asked an awkward question at the show during my presentation, “which computer is the best?”, but I found it difficult to give a clear answer as there was not a single computer that was best on all three aspects – processor speed, storage speed and price.

I think I can now say that the combination of Rapsberry Pi I/O board (£39 in stock at Pi Hut), Compute Module 4 (£52), RISC OS Bits PCI Express SATA interface (£100) and a SATA hard disc (£33) is the best (and is cheaper and faster than a Titanium and can do bigger screen resolution). At present this is recommended for the CM4 Lite as the ROM that includes the SATA driver (supplied from RISC OS Bits on a micro SD card) is not yet eMMc aware.

The downside of course is that the supply of Compute Module 4 boards is rather sparse if not non-existent. I was fortunate in that I bought three in November 2020, hoping that RISC OS would soon work on the CM4 (actually October 2022) and be able to use the eMMc (1 Feb 2023).

I have actually set up a CM4 with eMMc on a Pi Foundation IO board with a RISC OS Bits SATA interface (12V supply required) with a dual boot via a push button into either a 1 Feb daily rom (that can do eMMc) or the RISC OS Bits 24 Feb ROM that includes the ADFS SATA driver. The benchmarks for the CM4 have been updated accordingly.

But then what filing system performs best on FAST or Chris’ ideal setup?

The SATA interface on the FAST set up uses ADFS. I bought the ‘CORE’ version which is just the ROM (on an SD card) and PCIe SATA adapter. I already had a SATA SSD drive, Compute Module and IO board.

“which computer is the best?”

Generally speaking, faster is better, but price comes into it.

There is no correct answer to a question like that, it depends upon each use case.

Me, for example, I use a Pi 3B+ as the main machine, and an original version Pi2B as the outdoor machine. The Pi1B is too slow, notably so, but the 2 is perfectly adequate.
I’m not particularly interested in the Pi4. I don’t need the extra memory, and I’m not convinced the speed boost would make any real difference. Yes, it will be faster at “doing stuff”, but given that entire universes are born, exist, and die in the space between keystrokes…….

So, when somebody says “what’s the best machine?”, the obvious reply is “for what?”.

@Robert
We do have very limited numbers of “FIRE” Lite (maybe we should call it a FIRE Liter?!) machines available now at a very special introductory price. Called Lite, because they only have 2GB RAM, rather than the 4GB that the FIRE will have. One of the things that’s a strong point about the system is it’s upgradeable – just pop out the Compute Module, pop an upgraded one in and you’ve got a “better” system! Similarly, you can replace many of the components inside without replacing the system as a whole.

If anyone’s interested in the Lite version (2GB RAM is more than enough for RISC OS for the most part anyway), use our Contact Form (using Other until I update the form) to get in touch. Numbers are very limited though…

@Chris
Wow! Thanks for the recommendation! Glad you’re enjoying going FAST! :-)

For those with a CM4 and IO Board already, the CORE option that Chris is talking about is available in less limited numbers.

I already shared my first impressions on FAST on my twitter here:

https://twitter.com/PaoloFabioZaino/status/1629944261650030595

I agree with Rick that defining the “best machine” needs a “for what” attached to it. However, FAST indeed helps in so many tasks when using RISC OS that is a bit like Iris, it solves a lot of problems, hence I can recommend it pretty much to anyone.

The only thing that FAST doesn’t help me with is portability, and given that most of my coding on RISC OS is done during launch breaks at a Caffe or while travelling, for me (and again for what I use RISC OS 5 the most) the best machine is still the PineBook Pro. Maybe, one day, we’ll have a RISC OS laptop with fast CPU, high memory bandwidth and Sata or NVMe support, in that case that would become the best machine for me.

However at the moment, when I code on RISC OS on the weekends, FAST is definitely the best platform hands down (and already my develop system). It provides fast processing (and compilers benefits from that), disk I/O performances never seen before ( and compilers benefits from that), faster memory (so higher bandwidth) and, well you know :)

As an always wanted plus it also offers upgradeability!

So, I am absolutely happy with it and thanks again to RISCOSBits for pulling this together! Awesome job! :)

Wow, you’re brave giving a Twitter link in 2023!

Small comment about the code structuring (further down your page). Why are you describing what the functions do at the BL point rather than at the entry to the function itself? The comments after BL should be “adequate”, and what you have there likely moved to after the function label (where you can also describe prerequisites, like blah in R1, corrupts R5 ¹ and flags…).

¹ Though Life is Easier of you just assume and implement basic APCS everywhere.

Wow, you’re brave giving a Twitter link in 2023!

XD ahah! I started that account during Covid time, previously I only had my computer related blog and the stuff about music (on which I do not engage much, they are mostly to advertise new music productions being available). I have mastodon too now, but in all honesty, my favourite way is still releasing RSS feed to who is interested :D

Why are you describing what the functions do at the BL point rather than at the entry to the function itself?

No particoular reason tbh, just trying to “put something together” that looks and feel redabale for most users. I had read Chris M. comment on the assember being cryptic (as well as others too), so I am trying to figure out a way to make it less cryptict for the average coder.

Hence thank you very much for your comments :)

I’ll take them all onboard and if anyone else has ideas to suggest (to make ASM more readable for everyone), please let me know.

I haven’t posted on here because, in all honesty, this forum is more of a “grumpy land” where folks posts just to correct back in most cases or to complain and there seems to be not much interest (except from the usual suspects like Jeffrey, Sprow, Jon and few others) to make RISC OS better, so it’s becoming more and more inrelevant to me (which is a shame, ’cause I know ROOL guys really want to make it a central place for everything RISC OS).

If people are interested in this stuff I’ll make an effort to post on here as well, but I doubt it.

1 Though Life is Easier of you just assume and implement basic APCS everywhere.

I was thinking the same thing, but then I’d have to write something somewhere to describe why and how to read it I guess, or is it something on here I could link too already?

VI’m not particularly interested in the Pi4. I don’t need the extra memory, and I’m not convinced the speed boost would make any real difference.

It makes a big difference, The 4B is 3x to 4x faster running programs, but also the networking is quicker, making it fast enough to use via VNC, so I can have RISC OS anywhere.

Hopefully we’ll get USB3 support eventually, which will allow SSD’s to be used at their full potential.

Paolo, reply moved to Aldershot.

Here’s the disk benchmark from RISCOSmark5.

HD Read - Block load 8MB file                             300102   10063%
HD Write - Block save 8MB file                            337317   11092%
FS Read - Byte stream file in                               1763     851%
FS Write - Byte stream file out                             1793     933%

*satadevices
Ctl Prt PMP  Type   Description                                Capacity
  0   0   0  ATA    Samsung SSD 870 EVO 500GB                  466 Gbytes

I got a different result using a Crucial BX100 120GB SSD:

HD Read - Block load 8MB file                             345349   11581%
HD Write - Block save 8MB file                            181169    5957%
FS Read - Byte stream file in                               3280    1584%
FS Write - Byte stream file out                             3356    1747%

@Chris Hall: Nice results !

I just wondered regarding the benchmark list on your website why the CM4 (with eMMc 2000 MHz) is still quite slow at ROM unpack/compile (without RAM FS) and Cold Boot time compared to the Titanium ? I would have thought that the increased I/O access would also be of a benefit here ?

I think the cold boot time is a combination of networking trying to find an IP address, and the SATA stuff looking for drives on other ports. The IP thing is easily overcome by using a Fixed IP, but the port scanning by SATA is more problematic.

Cold boot time and ROM unpack and compile not yet updated. The ROM compile failed (both Pi and Titanium) at building the rom module for ROMFonts so I’m going to try another daily build. ROM unpack was 29s. Also it is still booting from SCSI at the moment…

ROM unpack and compile updated (I had a lot of trouble getting the rom to compile – first it stuck at rom module build ROMFonts at the sed -e ‘s\/x23.*$//’ > Fonts.Encoding.UTF8 line (this seems to be new) but I managed to compile an October 2022 tarball. Looks like there is something wrong with the daily tarballs.

So the FAST system is now faster and cheaper than the Titanium.

Cold boot time (with static IP) is an unimpressive 27s. It may be due to a conditional boot script, see below?

CMDLINE.TXT:

console=serial0,115200 console=tty1 root=PARTUUID=9c85ad43-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot splash plymouth.ignore-serial-consoles disable_gamma


CONFIG.TXT:
[gpio5=1]
disable_overscan=1
fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
hdmi_blanking=1
max_usb_current=1
init_emmc_clock=400000000
ramfsfile=CMOSZZ
ramfsaddr=0x508000
sdtv_mode=2
kernel=RISCOS.IMG
device_tree=
max_framebuffer_width=3840
max_framebuffer_height=2160
hdmi_pixel_freq_limit=250000000
[pi4]
enable_gic=1
hdmi_enable_4kp60=0
over_voltage=4
arm_freq=2000
[all]
[gpio5=0]
#With button pressed eMMc aware RISC OS
disable_overscan=1
fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
hdmi_blanking=1
max_usb_current=1
init_emmc_clock=400000000
ramfsfile=CMOSSD
ramfsaddr=0x508000
sdtv_mode=2
kernel=RISCOSEM.IMG
device_tree=
max_framebuffer_width=3840
max_framebuffer_height=2160
hdmi_pixel_freq_limit=250000000
[pi4]
enable_gic=1
hdmi_enable_4kp60=0
over_voltage=4
arm_freq=2000
[all]
[pi4]
# Run as fast as firmware / board allows
arm_boost=1

[all]

Looks like there is something wrong with the daily tarballs.

Today’s Titanium and Raspberry Pi tarballs built just fine on the Titanium’s ADFS with DDE31b.

I am using DDE 30b and it fails at the same point whether using RAMfs or ADFS on the cm4.

I am using DDE 30b and it fails at the same point whether using RAMfs or ADFS on the cm4.

Confirming that, with DDE30b the build does stall in ROMFonts at the sed command.

stalls at sed command

I have been having to use a homebrew sed for yonks.

See https://www.riscosopen.org/forum/forums/4/topics/17450#posts-134569

We do have very limited numbers of “FIRE” Lite (maybe we should call it a FIRE Liter?!) machines available now at a very special introductory price. Called Lite, because they only have 2GB RAM, rather than the 4GB that the FIRE will have.

Thanks. Currently in the throes of a house move, but when that is sorted I will hopefully be in a position to order either a Lite or full machine. It’s great to see new RISC OS hardware still being produced.

Benchmarks updated using a Crucial MX200 250GB SSD:

HD Read - Block load 8MB file                             356879   11967%
HD Write - Block save 8MB file                            340657   11202%
FS Read - Byte stream file in                               3097    1496%
FS Write - Byte stream file out                             3301    1719%

This approaches the RAMfs performance and so is being limited by the underlying Filecore software. I wonder whether an NVMe driver will be filecore or non-filecore?

8MB is a very small size to use when testing sequential access, most benchmarking software on other platforms will be using 512MB to 1GB. If you bump it up a bit you should see slightly better figures, unless you are using an SSD with a very small cache.