RISC OS on the Raspberry Pi

http://www.paymentlabs.com/area0.jpg

I tried HForm again on my 1’ish TB disc and it’s still hanging, and it works fine on my 2GB usb stick.

I seem to remember someone mentioning vfat has better caching etc. than using native filecore format?

Hi Ben,

yes, Filecore obviously has the 256 GB limit, so if you (mis)use a filecore client as the access method to the hardware, you are stuck.

But non-filecore FSes can do their own stuff to access the hardware, e.g. working with SCSI_Op and raw devices (like CDVDBurn does). So RISC OS itself has no inherent disc size limitation (that I know of!), only an inherent file size limitation.

WPB: CDFaker works fine on the Pi, I used it to install the tools before the USB stick arrived!

Thanks, Malcolm, for confirming. I wonder if it can be included, Steffen (seeing as you’re “here”!)?

I tried HForm again on my 1’ish TB disc and it’s still hanging

Hmm. It stirred a memory from when I was last working on HForm, and I see that where it’s trying to work out a disc geometry for the SCSIFS case, I added the comment

REM Note the above algorithm will break down for drives above 65535*255*63 sectors = 502 GB

I bet that’s where it’s hanging. When you press Escape, is the reported line number anywhere near that? I wrote what I thought was a better algorithm for SDFS when I was adding support for that, but I was nervous about changing the SCSIFS case to match.

Steffen: as I said, I thought I’d heard that it used FileCore_SectorDiscOp – I may be mistaken. Clearly if it bypasses another layer and talks to SCSI_Op directly, it’s only limited by its knowledge of the SCSI command set, but it also means there’s a load more code duplication going on.

There is no improvement at present if you use SCSIFS_DiscOp64 – internally, FileCore converts these to the same 3+29-bit sector offset as is exposed by the SectorDiscOp API.

Hehehe. ;-)
Sorry. Just reminded me of that time I saw the rubbish being picked up. All the neatly sorted out bags of recycling stuff was thrown in with the normal black bags…
[these days, it is a dual-purpose collection truck, so recycled stuff can now be dealt with, but back then… ]

I seem to remember someone mentioning vfat has better caching etc. than using native filecore format?

I assume you are referring to the proprietory “exFAT” format? A licence must be paid to Microsoft for its use, which is why most stuff ignores it.
“VFAT” itself is not a FAT format. It is an overlay of sorts to provide long filenames within the context of a standard FAT format (using, if I remember correctly, pseudo directory entries – it was clever and hokey in equal measure). VFAT was so-named from the device driver module in Windows95.

The thing is, RISC OS relies heavily upon something called “metadata”. You see, under Windows and Linux, the directory structure does not hold any information on what a file is, only where it can be located. The file action/identifier is determined either by the extension (such as meh.jpeg or blah.exe) or by some sort of specific header in the file itself (such as “untyped” ELF executables).
RISC OS, on the other hand, uses data stored within the directory structure to determine what sort of file a file is. For example, a Sprite or a DrawFile does not intrinsically know that it is a Sprite (type &FF9) or a DrawFile (type &AFF).
No, instead, the directory structure says “file XXX is at YY and it lasts for ZZ bytes and it is of type ABC”.
It is possible in some instances to kludge this so “blah” with type &FAF may be stored to a FAT disc as “blah/html”; and under RISC OS (thanks to MimeMap) the .html will be understood as meaning it is an &FAF file. However when these file extensions are not known or not correctly preserved, it all goes very wrong. A good example is making a Zip archive under RISC OS (SparkFS adds a few things to Zip to retain filetype into) and unpacking these files under Windows (which ignores filetype info). On the RISC OS side, assuming we move these extracted files over to RISC OS, they will all appear as type &FFD (DataFile), because the vital type information was not retained.
Furthermore, while it may be possible to build application installations in a FAT media using extensions to provide type info, I don’t think RISC OS when looking for “!Run” and “!RunImage” will cope with files called “!run/obey” and “!runimage/ffa”!

Long explanation, I know.
The tl;dr version is: RISC OS native formats contain various features necessary for RISC OS to operate correctly. Non-native formats won’t work correctly, if at all, for running large swathes of OS utility code (such as the boot sequence).

Jeffrey, I see you have added the GPIO HAL device.
Tested on my Pi and works OK.
Any chance the model A/B detection could be added ?
It reads the model ID from GPIO28-31. A=0, B=1 upto F=16
Cheers

Jeffrey, I see you have added the GPIO HAL device.

Yes, although I kept forgetting to email you about it!

Any chance the model A/B detection could be added ?

I think they’re still deciding how the board revisions are going to be detected. E.g. in the videocore mailbox property interface there’s a message for reading the board revision (although I’m not sure if it works yet). I’ll have to give the latest start.elf a try this weekend to see if that message is implemented yet, and if so, I’ll probably go with what that returns, as that should (hopefully) be a future-proof way of doing things.

Ben:
It just say’s Escape Pressed – HForm stopped.
If you need a crazy fool to test anything like that, I kind of meet both of those requirements for testing things that are possible to cause disasters. For some reason I actually like it ;-) (backups are king!)

Rick:
I’m fairly familar with all this, I was being lazy…
Basically to be correct what I was saying was that the Fat32FS Module under RISC OS may have better (larger?) caching. I haven’t got a clue whether this is random or not.
I call it vfat out of habit as that’s the extension of mkfs under linux.
Must stop myself going on a rant about fat/ntfs are so horrible..too late..
BTRFS/ext4/ZFS/XFS there are plenty of good filesystems out there..I mean defragmentation! WTF?
I remember the first time I started using windows/linux, and the extensions confused me. I couldn’t work out how a system didn’t know what format the file was in, and required these bizarre things at the end of the filename.
I couldn’t think why anyone would design something like that.

Anyway! Ideally I would like to split up my Hard disc into three partitions, two for RISC OS (2 250GB) and the rest fat for swapping data and backing up data on linux/riscos

Fat32FS Module under RISC OS may have better (larger?) caching

It is possible. Either way, RISC OS would work lots better with its own native filesystem. You can fiddle with the amount of caching (ADFSBuffers or DirCache or something like that, poke around the config options); though it is a fairly lightweight filing system so I don’t see any particular speed hits for the sort of stuff I use native format with.

Must stop myself going on a rant about fat/ntfs are so horrible..too late..

Given my time with FAT32 USB keys and needing my flippin’ Linux-based PVR to correct errors Microsoft’s chkdsk cannot even detect… you really don’t want to start me on a rant about how terrible FAT is, not to mention anything Microsoft has done connected to FAT.

As for NTFS… My eeePC has no swap file, so there’s no VM in use. It seems “interesting” to me that from time to time when my SSD gets full (like <100Mb free), XP SP3 just freezes with the HDD light solidly on for like 45-60 seconds. Running diagnostics shows no additional system load. It is as if the machine pauses for up to a minute and this time just ceases to exist. You want me to tell you what I think of NTFS?
Not to mention that lovely oddity where XP will start to boot from an incorrectly shut down machine, only to blue screen with a message about “Unmountable boot volume”; God forbid the system invoke chkdsk. No, it looks like MS’s official help is to build up an alternative boot, flag the drive as non-primary, boot into clone XP, then scan the damaged drive. Or, as I do, pop in Hirren’s BootCD, boot to a DOS prompt, then load up ntfschk and leave it to fix the problem, which it does in about thirty seconds.
Seriously, if I was to tell you my real thoughts on Microsoft’s ability to create filesystems, I’d be banned from these forums. On the plus side, you’d know obscenties in four languages (English, French, Spanish, Japanese).

BTRFS/ext4/ZFS/XFS there are plenty of good filesystems out there..

I don’t think RISC OS has image support for any of those…..yet.

Really, though, we’d need a filing system designed to work with the specific nature of flash based media. None of this 512 byte sector stuff, how many FSs take into account the erase block size of a flash device (IIRC, it’s around 128K a time). Not to mention hardcore journalling in case of power loss during a write so the media can be brought back to a reliable state. Plus reduced write-behind caching to deal with the quick-remove nature of these devices.

I mean defragmentation! WTF?

Um, yeah. <cough> *Compact </cough>

E format (and I presume F, F+, etc) auto-compacts. You might notice some floppy writes take longer than others (it isn’t so obvious with a harddisc).

and required these bizarre things at the end of the filename.

The idea of extensions made sense to me, but they just seemed like a really ass-backward way to do things. I guess it was the “simplest hack” back in the dawn of Unix and CP/M, and DOS just borrowed heavily from that.

There’s a lot about Linux I don’t like (I really loathe the case sensitive filenames), and I reckon a lot of it can be traced back to its teletype heritage. But, then, a lot of the weird stuff in RISC OS (OS_Byte, anybody?) can be traced back to the Beeb. History has a lot to answer for!

2×250Gb partitions? Wow. I have a 2Gb partition for startup and apps, plus a 2Gb FAT device for MP3s and stuff. My full MP3 collection takes up more space, but I’d reckon an 8Gb drive would be plenty. What do you plan to fit on all that storage space?!?

>2×250Gb partitions? Wow. I have a 2Gb partition for startup and apps, plus a 2Gb FAT device for MP3s and stuff. My full MP3 collection takes up more space, but I’d reckon an >8Gb drive would be plenty. What do you plan to fit on all that storage space?!?

As long as you are using SD-cards, there is no problem. But have you tried nowadays to buy a hardisk smaller than 1 Tb? You’ll find hardly anything smaller than 500 Gb, even that is nowadays “vintage” and only to find in less frequented shops or second hand…

It’s not so much I’ll fill up 250Gb, I just want one disc for development things. I’ll probably need a lot for this 100Gb for libraries, documentation, and email of which I have a lot.
The other disc for mp3, again a lot.
But realistically the main reason is the size of my disc, and I need three discs so splitting it that way is easier.

I only really ever used E format, as when I was using Arthur etc. it was from a loan A310 which I had over summer,

Anyone know if the Raspberry Pi Foundation intends to offer pre-loaded cards to stockists for RISC OS too?

ROOL plans on selling pre-loaded SD cards direct to users.

The new ROM image is freaking sweet! I can use Fuse/Mednafen/BeebIt/ArcEm in fullscreen cheers for the excellent work! Damn.. the RISCOS should be the official “distro” for the RPi not that multi-megabytes-image- Linux (that even takes ages to boot)…

YES. I can’t start to understand why it’s debian: it’s a bloated PC server OS, not a desktop solution.
Risc OS is: it flies on the Pi, boots to a fast, elegant desktop and leaves all the resources to the user.

I can’t start to understand why it’s debian:

I believe it is due to Ubuntu being all elitist and saying “your ARM is too old, no longer supported”.
Haha, could be their loss supersized.

I thought the problem of the cursor redraw had been solved with the introduction of the VHCIQ module?

I’ve put the module in the proper place, rebooted, checked that it’s running, but the cursor is still messing up window redraw – usually in an area just close to the cursor, unless I drag stuff fast.

The good news (which is probably unrelated) is that I have a beautifully crisp display at my monitor’s native resolution (1280 * 1024) for the first time from the RPi.

The poor news is that the monitor settings are not remembered across a reboot – every time I set them, there is a message “Can’t save screen mode because resolution or colours is unknown.” I don’t understand how either can be unknown, because of course I’ve just set both of them.

I thought the problem of the cursor redraw had been solved with the introduction of the VHCIQ module?

Are you running a ROM from today?

The poor news is that the monitor settings are not remembered across a reboot – every time I set them, there is a message “Can’t save screen mode because resolution or colours is unknown.” I don’t understand how either can be unknown, because of course I’ve just set both of them.

That may be one of the bugs in the screen setup plugin that I’ve fixed recently. But on the other hand other people are reporting issues with not being able to save their mode as well (or the settings being lost), so it’s something I’ll look into.

Are you running a ROM from today?

Yes and no. I built it yesterday – what I’d forgotten is that it was from sources from the day before.

This morning it’s fine, so my apologies for more noise.

(Why does the ROM still say September 3rd? Where does the date come from?)

And the monitor settings not being saved seems to be related to the lack of the X in VIDCBandwidthLimit etc. I had put it in the BBxM, but forgotten that I had not done it on the RPi.

So everything is looking good this morning.

I think it’s good RISC OS isn’t the default OS on the Pi.
Primarily RISC OS isn’t a known operating system, and people won’t generally be interested in trying it.
I got a Pi and hadn’t thought about using RISC OS, I’m a heavy linux user. However I ran debian and it was painfully slow and I even had to create a swap file on the SD card (arrrgggh!).
Then I tried the alpha RISC OS version, all I can say is “wow”. I personally think this is what a lot of people will say.
I was brought up on RISC OS, and was forced (due to lack of phoebe etc.) to dump RISC OS and move to linux, which from a career point of view was great.
But I greatly missed RISC OS, and was deeply sad to see it’s demise. (I wasn’t aware of ROOL, I vaguely knew of Castle)
The Pi has “brought me back into the fold” as it were, I’ve been using it as my primary desktop at home now since the alpha started.
Sure it’s not perfect, but the linux desktop is annoying me too much now. The only issue I have at the moment is a javascript browser.
I’m deeply impressed with the speed of RISC OS on the Pi. It’s not fast enough (the Pi) for my liking, so as soon as there is an A9 solution avaliable I’ll be upgrading. The thought of RISC OS working on a multi-core A15 makes me drool to be honest.
I dearly hope a portion of the million or so Pi users reach the same conclusion I do, given the likely audience we should have some good assistance with progressing RISC OS at a faster speed – both with more applications and hopefully multi-core, pre-emptive OS in the years to come.
Given the A15 avaliablity, which is likely to be 2013 ish for a decent speed and general avaliablity as against massive order avaliability for phone manufacturers. If we get a decent addition of RISC OS technical assistance due to the “Pi” effect, as well as more cash for development, things could get very exciting for RISC OS.
Here’s hoping, maybe it is just a !PipeDream ;-)

(Why does the ROM still say September 3rd? Where does the date come from?)

Looks like my fix for that got lost during a merge; I’ve now resubmitted it, so everything should be OK with latest sources.

I’ve also updated the HAL to read the board model & revision; Board_Model is the model number as reported by the GPU (currently seems to be 0, presumably model A boards will up this to 1), and Board_Revision is the revision (which seems to match what linux returns in ‘cat /proc/cpuinfo’ – so see the info here for working out how the IIC code should be set up).

The GPIO HAL device will now also report the board revision, reduced to just a simple ‘B rev 1.0’ (revision field will be 0) or ‘B rev 2.0’ (revision field will be 1) rather than the raw revision number. This avoids the GPIO module from having to worry about all the different minor revision numbers.

“Add support for GraphicsV_SetBlank”
Is this the start of HW accel GPU support for Pi?

No. SetBlank is used to turn the display on and off, e.g. for screensavers.

With more (hopefully) people at least trying RISC OS on a Pi, is it worth doing this mod, as a lot of users may only have two button mice/mutimedia keyboards.

(Tank, I’m still interested in that adaptor/switch unit, I’ve been working away.)

I just tried a client wireless access point on my Pi, it works fine with a cross-over cable, however not with a normal cable, my linux PC (and iirc my Iyonix) work happily with a standard cable. Should the Pi’s interface be autosensing for cable type?