RISC OS mouse pointer issue not fixed?

What release of RISC OS are you using? The mouse-pointer-trail was fixed months ago.

Have you tried an HDMI monitor?

Theo

I've seen something like when the boot sequence didn't finish, due to some error in pre-desk which stopped the monitor definitions from being loaded. I suspect the default 640x480 resolution in ROM doesn't have suitable timings for the Pi.

Check the messages on screen while it boots. If you don't spot anything,

try !Reporter to log the boot sequence.

---druck

The current version.

It works on an HDMI monitor. But that doesn't help me use it on the composite display.

Unfortunately on an interlaced 640x480 display those messages are too small to read. I don't suppose they get recorded to a log file somewhere?

!Reporter will log them if it's set up to run at boot, and you can add a command at the end of boot to save the result to a file.

--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 
http://www.nckc.org.uk/

Thanks. I can see I'm going to need to mug up on RISC OS. I think I'll try and get a Pi VM up and running so I can have a play around and roll back any mistakes I make.

I'm not sure you'll be able to run RISC OS in a Pi VM - IIRC the VMs that people did before the Pi was released (Qemu and gxemul) aren't really emulating the Pi hardware, just the Pi CPU and a few incorrect peripherals. So you can't take a standard Pi SD card image (RISC OS or Linux) and boot it on them.

What you can do, however, is take backup images of SD cards as you go so you can rollback that way.

The reason I ask about what version is that there have been four public releases of RISC OS for the Pi so far - RC5 to RC8. RC5 and RC6 are from Oct/Nov 2012 and RC7/RC8 from Mar 2013 (to find out your ROM date, click the middle button over the Raspberry icon and slide to Info). For RC5/RC6 the GPU driver module (VCHIQ) hadn't then been cleared as BSD licensed so it's softloaded on boot. If your boot gets interrupted then you get software rendering of the mouse cursor as a fallback, which doesn't always get it quite right.

For RC7/8 the VCHIQ module is ROM unless it's somehow been disabled ('unplugged'). So you shouldn't get the software mouse cursor for that. If you want to check, press Ctrl-F12 to get a task window and type *Unplug to list anything that's unplugged.

Theo

I'm not expecting it to work, but it's still worth a try.

That's certainly an option. Would be nice if DD actually gave some onscreen feedback while duping though.

It would either have been RC7 or RC8. I had to switch to Raspbian to do some testing on the TFT display but I'll make sure I grab RC8 next time. Now that Wheezy is officially released I'm guessing there will be a Raspbian update at some point and I may as well do a clean install. In the mean time ... RISC OS fun.

I'll give it a go. It probably won't be until the end of the month though as I don't have much free time right now.

Cheers!

-A

use ddrescue if you want feedback (or is that dd_rescue? I get the two confused - actually both seem to give feedback)

else ping the running dd with a SIGUSR1 signal (using the kill or killall command)

--
?? 100% natural

I hadn't heard of ddrescue, but I have dcfldd which can do md5, sha1, sha256, sha384 or sha512 checking on the fly. extra's like hashwindow=BYTES hash=NAME hashlog=FILE and more.

Cheers, Ron M.

Or, pipe the data through both dd and pv (pipe view). Pipe view gives real-time progress info.

HTH

--
Robert Riches 
spamtrap42@jacob21819.net 
(Yes, that is one of my email addresses.)

I have found that the RISC OS versions of these utilities do work on the PI, SCSI::0 must have been changed, as I had no luck on my Iyonix with the older RISC OS 5.18.

I have a RISC OS port of sash that includes dd

and managed to port pv by configuring in the cross-compiler, and compiling with the RISC OS native gcc.

It can be used like pv -S --size 2M SCSI::0 imagefile

Note that RISC OS doesn't support the extensive piping with | in the unix way so chaining pipes is unlikely, easily anyway. I have ported dcfldd and will now have to verify how well that works. It is possible that is quicker to do a checksum after an image is written, rather than on the fly.

Thanks for mentioning pv, Robert

Ron M.

Sorry, that's wrong, pv needs the > included

pv -S --size 2M SCSI::0 > imagefile

-S is needed to Stop at --size 2M

in Linux I guess that would be

pv -S --size 2M /dev/sdb > imagefile

SCSI::x or /dev/sdx to suit drive number.

Ron M.

I tried writing the 2 Gb archlinux image from RISC OS, but the these ports only get as far as 58724352 bytes and then quit. I dont know why they even get that far, but it looks like the useage with drives at the low level will be severely limited.

Ron M.

58724352 = 2^12 * 3^5 * 59

( 58724352 / 2^12 ) - 1 = 7 * 2^11

Does either expression suggest anything to you?

--
?? 100% natural

I've found one problem with SCSI::0 is that it takes notice of the DOS partition size rather than the HD size. There are probably a few other filing system type things that it is doing that make it unsuitable for use as the equivalent of /dev/sdx Wiping the first 512 byte sector will make it forget the dos size for writing, but you cant do that when you are reading back.

I did manage to write the full image by using Duncan's pipe utility.

*pipe pv archimage | SCSI:0 but the card didn't boot archlinux properly, and not being able to read it back mean't I can't compare to see where it went wrong. *pv -S -s 512 /dev/zero > SCSI::0 works ok, but pipe was needed for image write for some reason.

There are SCSI commands for BASIC that can do the job, and a program could be built that does a verify would be an advantage when the integrity of cards is questionable.

Ron M.