First post from my Pi Zero!

Hmm. It does have a 3231(?) based RTC on it. I don’t use !ScrHelp to my knowledge.

Interesting thing was again when I did a build rebooting worked. That was since my last post.

…and the spindle bearing just went on my aarch64 “build server”. Typical. It had gccsdk on that drive.

I’m so used to PC fans suddenly making that awful sound when they wear that it didn’t click with me instantly. The silence of using ARM based devices is worth it. Just like the 80’s and 90’s non IBM compatible stuff.

…and my Pi 3 just cooked the 2.4A power supply. Besides the 5A LED strip supply I have powering the USB hub that’s the biggest supply I have.

It died while trying to convert WAVs dumped from an audio CD (using an 18 year old external CD ROM drive) to MP3 so I could actually listen to them. I think I ticked off the god of tech.

…and my Pi 3 just cooked the 2.4A power supply

I doubt the capacity was the problem, just a faulty PSU.

I’m so used to PC fans suddenly making that awful sound when they wear that it didn’t click with me instantly.

I used to spend a lot of money making x86 computers silent and fanless, the prize jewel of our collection was one I bought/constructed for my wife that had an external heatsink on the side (look up the Streacom cases). We used to use it to watch movies and heat up the house.

Now we use a Pi3 to do the same job and it actually decodes HD movies (stored as ISO images on our server) better than the old Windows machine.

The more I use ARM, the more I like ARM!

Pi 3 just cooked the 2.4A power supply

My brother had a Pi power supply that melted while he was using the Pi to gather astronomical data one night. I think it was a cheap one off eBay though—where did you get your PSU from?

The more I use ARM, the more I like ARM!

I’ve been a big fan of ARM for a long time because of how well they can achieve things on a tiny power budget.

I got the USB PSU from the supermarket. It’s a reasonably good brand that they sell all over the place.
I have a lot of posts in a thread on another forum all centred around the issues I’ve had powering the Pi 3 properly. So many power supplies. So many cables and configurations. It’s so finicky.
Long story short the Pi 3 power supply works again. I’m using the Orange Pi PC2 though because I got a replacement hard drive yesterday and am in the process of slowly adding things back. It took a whole day again to build GCCSDK. It was doing it on a USB drive while I was HDD-less. No matter what it’s a long process for aarch64. config.guess and config.sub keep needing to be replaced in generated directories and the build process resumed.
Incidentally, does anyone know what can safely be pruned from a build of GCCSDK? When I copied it over to the USB HDD I discovered that it blows out to over 6GB!

Who was it that wanted to try a newer build of !Nettle to see if that was what made SSH work? My test build for GCCSDK was !Nettle. I’ll shove it on to dropbox if anyone wants a build done with a fresh build of gcc4.7.4?

Incidentally, does anyone know what can safely be pruned from a build of GCCSDK? When I copied it over to the USB HDD I discovered that it blows out to over 6GB!

Potentially everything except the ‘bin’ and ‘env’ folders? Just make sure to check that they don’t contain any links to other folders.

First post from my Pi B!
Possibly… I honestly don’t recall.

Very long story short. The HDMI mini adapter on my Pi Zero fell apart. Programs I need didn’t work on the Pi 3. The bottom end of the SD card slot on my Pi B was damaged (pretty sure it was since I got it) but it was flatly refusing to boot anything. Got it working and here I am.

I finished doing another aarch64 build of GCCSDK because I did something dumb, messed it up and had to redo it.

Sort of getting everything chugging along again. Now my only obstacle is my incredibly short attentions span!

The Pi B may be a touch over the threshold of being a little too slow but it does the job. Plus I really do think the clear case it has is really nice.
Is slow redraws when moving windows over the background a bug or something else? It’s irritated me forever. If I make a full screen window and drag another window around over it the redraw is fast.

Is slow redraws when moving windows over the background a bug or something else? It’s irritated me forever. If I make a full screen window and drag another window around over it the redraw is fast.

RISC OS doesn’t use a compositing window manager, so whenever a window moves or scrolls the changed area needs to be redrawn by the relevant app. So responsiveness when dragging windows around will largely depend on how well-optimised the redraw code is for the windows which are underneath.

In particular, the pinboard module will cache any backdrop sprite in the current screen mode, but it currently doesn’t cache decoded JPEGs. So a JPEG backdrop (as is the default on the Pi) will have to be (partially) decoded for each redraw operation, making it slower than most redraw operations for regular windows. For the smoothest/most responsive window dragging you’d either want to remove the backdrop entirely, or use a tiled sprite (plotting of tiled sprites can be hardware-accelerated on some machines, including the Pi).

There’s also evidence that the newer version of the JPEG library that was brought in for the JPEG bounty is significantly slower than the old one.

https://www.riscosopen.org/forum/forums/5/topics/6345#posts-56560

(Correction: Looks like the default Pi backdrop is supplied in both JPEG & Sprite versions, with the default being Sprite)

Hmm. So in essence if I want a background image I have to convert it first to avoid the JPEG overhead. That’s a little …odd. But okay.

I plugged the power in on my Pi B after unplugging it a day or two ago. I think the last thing I did was compile a ROM and install it. First thing the Pi did was not boot properly. It decided the hard disk was blank and judging from the resolution it didn’t read the CMOS file. What a strange thing to happen!
I grabbed the latest nightly from ROOL (25th March??? It’s 6th April!) and plopped it over. First thing was my compiled version was 5.2MB vs. the one from ROOL which weighed in at 2.7MB. Really strange. The ROOL one worked too, which is good. It can see the system partition again.

e: I just saved my wallpaper as a sprite and it’s way better now!

Hmm. So in essence if I want a background image I have to convert it first to avoid the JPEG overhead. That’s a little …odd. But okay.

A bit of digging through CVS suggests JPEG backdrop support was introduced in 1997 for the ill-fated Phoebe project. So it’s conceivable that the project was cancelled before anyone had time to review the code or implement any optimisations.

As for why it’s still like that, I can’t really say. Maybe people just aren’t complaining enough?

I grabbed the latest nightly from ROOL (25th March??? It’s 6th April!)

The latest nightly should be from the 2nd of April.

The nightly builds are only updated when something changes in a relevant part of CVS.

First thing was my compiled version was 5.2MB vs. the one from ROOL which weighed in at 2.7MB. Really strange.

ROMs produced by the autobuilder are usually compressed. When building ROMs manually the compression is skipped since it usually just adds an annoying delay to the end of the build process and makes things harder to debug (you can’t just open up the ROM file in a disassembler and examine it)

As for why it’s still like that, I can’t really say. Maybe people just aren’t complaining enough?

I wouldn’t have thought it would take much to load the JPEG, dump a sprite version into Scrap, and then just use the sprite….?

I wouldn’t have thought it would take much to load the JPEG, dump a sprite version into Scrap, and then just use the sprite….?

I think the original idea of using the JPEG itself was that it takes a lot less memory – ISTR (contrary to what Jeffrey found out via CVS) that the feature was added with RISC OS 3.6, when the integrated JPEG support in SpriteExtend was done. So it was the time when people used RPCs with 4 or 8 MB RAM.

So we would need the “make it faster by using more memory” option button in the backdrop tile config window :-)

ISTR (contrary to what Jeffrey found out via CVS) that the feature was added with RISC OS 3.6

Maybe via a third-party app? CVS seems pretty clear on the fact that handing JPEGs directly to the pinboard was an Ursula feature.

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Pinboard/UrsulaLog?rev=4.1#l47
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Pinboard/s/StartLoop#rev4.1.4.2

ISTR (contrary to what Jeffrey found out via CVS) that the feature was added with RISC OS 3.6

On a RISC OS 3.7 RPC I changed …Textures.T2 to be a JPEG. Selecting it and clicking on Try gave “…Textures.T2 is not a sprite file”

Hmm. Maybe I am misremembering, and it was !Draw that gained native JPEG support in 3.6?

I used !Draw to convert from JPEG. I’ve never worked with any images on RO before that. Never needed to.

Does anybody know if the Pi B has performance issues with UHS-1 cards? I’m getting sub floppy disc speeds. It could either be the SD card or the other …thing I did with RO tonight. Could it be a FAT performance issue?

e: I tried it in the Pi3. No different.

Did you know it’s possible to use an SD card just formatted with a single FAT32 partition to run RISC OS?
It seemed logically possible so I tried it. Strange thing is disc access is slooooooooooow on the SD card.

Does anybody know if the Pi B has performance issues with UHS-1 cards?

No idea what a UHS card is, however there is a list of cards known to work/not work that might be worth consulting? Google…

As with IDE drives and all the Master/Slave issues decades ago, it seems that some SD cards follow the spec less than others. Maybe subtle timing issues? I don’t know.

I’m getting sub floppy disc speeds.

Yeah, that’s slow. I found my Class 10 SD card remarkably faster than my Class 4 one, taking an unpacking of RISC OS from hours down to…what was it, about fifteen minutes?

It could either be the SD card

Have you tried a different SD card? (not of the same type)

Could it be a FAT performance issue?

I have not really used FAT for much more than copying files to/from my PC.
Are you using the built-in DOSFS or Fat32FS?

In my limited experience, it seemed to me that FAT was faster than Filecore, but that might be greatly influenced by the media. My Beagle absolutely crawls with its 1GB USB flash devce, but then I am under no illusions that said device is anything other than utter crap. It’s just what I had to hand when setting the machine up.

I tried it in the Pi3. No different.

I believe that most of the Broadcom chips are identical asides from which ARM core(s) are present. So Pi1-Pi3 will likely have exactly the same SD controller hardware.

Did you know it’s possible to use an SD card just formatted with a single FAT32 partition to run RISC OS?

Not really. I suppose it could be possible if every file has an extension and there’s a ton of *DOSMap commands to tell RISC OS what that means, but the problem is that RISC OS uses metadata for file information. Sprites, executables, Templates, DrawFiles, Obey files… all of these are denoted by a “type” which is held as part of the file catalogue. Such a concept does not exist on FAT or POSIX based filesystems as they have a heritage of using a type suffix. This is why sometimes you’ll come across files with weird names like MyPic,ff9 – the tail is a bodge that is used to translate a file held on a non-Filecore system to something RISC OS can understand (provided the interface software (ie Samba) does such a translation).

Strange thing is disc access is slooooooooooow on the SD card.

My Pi1, decent make class 10 SD card. Quite zippy. Try a different SD card, aim for a class 10, but avoid anything that proclaims great things about super speed. Like with mice and keyboards, more bling = less compatibility. And Google for that list of cards known to work or fail. Sadly, one cannot assume the good brands such as Sandisk are okay, failures affect all types…

http://elinux.org/RPi_SD_cards

It looks like many UHS (ultra high speed?) cards work, but some don’t.

I think I worked it out. By the way it’s a SanDisk 16GB UHS-1 MicroSD. I have a few I use for different OSes, but hadn’t tried another on the B. Short story, it isn’t the SD card. I went through and tried again. Slow access speeds and RO only reporting about 2.9GB. On reflection that number seems very FAT-16.

Are you using the built-in DOSFS or Fat32FS?

I think you hit the nail on the head. Answer: I have no idea how to tell but I’m going to assume DOSFS.

Such a shame. Besides working terribly it worked well hahaha. I might make a 2GB partition just to see how it works with FAT. It should be fine. I don’t really get how it does it but it seems to handle the metadata for the file types quite well on the USB stick which I use for all my work and other bits and pieces. It doesn’t use the comma suffix.

I’m off to bed shortly but I had a realisation.
For starters, I made the partition FAT32 with the LBA flag enabled because that is what the boot partition on the Raspbian image was set up like. I think it’s fair to assume that the bootloader supports FAT32.
So the bootloader shoves the RO ROM into RAM and runs it. It boots up but lacks FAT32 support.
A postmortem after checking the partition with the linux chkdsk implies that RO wrote a FAT to a different location. The files which usually reside on the boot partition were lost and recovered as .chk files. The files written by RO were visible. On fixing the boot files, reinstering and booting the FS was unreadable and scrambled.

I think this is a real shame. If the RO ROM supported FAT32 OOTB It’d go from being one of the most finicky OSes on the Pi setup wise to the easiest. Ie grab an SD card and splat the bootloader files, ROM, and the self extracting HD4 onto it. Then just boot and do a few easy config steps.

If the RO ROM supported FAT32 OOTB It’d go from being one of the most finicky OSes on the Pi setup wise to the easiest.

Root cause: RO doesn’t have proper partition support. This has been identified as a “good thing” to add (see the file system bounty)

The Pi uses a fiddled partition arrangement with overlapped FAT and RO filesystems use so any use of chkdsk “fixes” the deliberate “break”

While that’s true, that’s not what I did.
My SD card had a single 16GB(ish) partition. I checked on a Raspbian image how the boot partition was laid out. Ie FAT32 and the LBA flag set. So I made the 16GB partition similarly, although I suspect setting the LBA flag is pointless on an SD card.
The boot files which usually reside on the FAT partition of my RO SD cards got dumped on to it.
It booted fine and saw an almost empty SDFS entry, except for the boot files. Trouble was it saw a partition slightly less than 3GB. I didn’t think t check that until later and installed some things, which of course caused some corruption to the boot files because I’m guessing the second FAT was ignored and rewritten at the top of RO’s perceived end of the FAT partition.

I really thought it had a chance of working because the ROM is loaded into RAM and booted. If I recall it even read the USB drive (FAT32) which I use as a storage and work drive for RO.
So there was no phantom FileCore mapping on the SD card, so no black magic data overlay with partitions and LOADER.
Besides the slow drive access, incorrect partition size, and corrupted boot files (which were still named correctly until chkdsk), it managed to extract the HardDisk4 image, and I installed it fine on the FAT partition, and it worked.

So, besides the ??? FAT issue, a single FAT32 partition on an SD card used as loader and OS could be made to work i believe.

I did some poking around. It’s trying to use dosfs. I thought fat32fs was a part of the ROM! It didn’t exist in any form on the SD card I threw together, but i found it in the RPi SD that I use.
I didn’t have any success unplugging dosfs then using fat32fs to mount the SD card. I think I was doing something wrong.
Is it possible to lump the binary module into a ROM, or does it need to be built from source as a part of the ROM build? I couldn’t find any info on that.

So my Zero started malfunctioning then the HDMI adapter broke last(?) week and my Pi B has been acting weird. I thought I was just imagining things. Perhaps not.