Software mouse cursor

Is there any way to get RISC OS to generate a software mouse cursor? I ask as I’ve been porting to a platform (Mini2440) which doesn’t support hardware cursors, and trying to use the desktop blind is a bit difficult!

Is there any way to get RISC OS to generate a software mouse cursor?

Not that I know of, although it wouldn’t surprise me if it was implemented (or half implemented) for one of the STB’s.

I ask as I’ve been porting to a platform (Mini2440)

Interesting! That’s the same SoC as in the A9home, isn’t it? Sounds like you’re making good progress, at any rate.

Incidentally, how are your IOMD improvements looking? Have you sent them off to ROOL yet?

If you wanted a quick-and-dirty solution for the mouse cursor, you could probably write a WIMP app that draws an icon where the mouse is. It’d obviously be completely useless outside the desktop or when dealing with error boxes, but it would allow you to get on and test stuff while deciding how best to implement a proper solution (software display double-buffering? use hsync interrupts to trigger blitting and un-blitting of the cursor each frame, while disabling read/write access to the relevant pages while the cursor is visible? Or maybe have two copies of the relevant page(s), so programs can still write to them while the second copy is used to display the cursor).

We did similar once – I think it was Andrew Hodgkinson who wrote a little app that used four small windows as a crosshair (with a hole in the middle) to represent the pointer. And as you say, it doesn’t help you when an error box pops up! It’s called Mousetastic and amazingly I found a copy which still works – you can find it on our downloads page here https://www.riscosopen.org/content/downloads/desktop-zipfiles

Interesting! That’s the same SoC as in the A9home, isn’t it? Sounds like you’re making good progress, at any rate.

Yes – which is partly why I chose it. I think the only real differences between this board and the A9home will be the video controller and the presence of IDE hardware.

The port’s mostly useable, video works (albeit only 480×272 on a 4.3” screen, as I was feeling cheap), and USB works.

My vague ‘long term’ plan for the video for this LCD driver is to put the framebuffer somewhere outside of RISC OS addressable memory, then copy from the ‘fake’ buffer to the real one, possibly with scaling, on vblank. I’ll have to figure out the performance implications though. Plus I’ll have to scale down the vblank interrupts – to get the cheap screen to look okay I’ve had to put the refresh rate above 150hz!

Incidentally, how are your IOMD improvements looking? Have you sent them off to ROOL yet?

I sent them to ROOL a couple of months ago. Only change that they won’t have is the floppy support, but that’s unstable at the moment so probably not a big deal.

My vague ‘long term’ plan for the video for this LCD driver is to put the framebuffer somewhere outside of RISC OS addressable memory, then copy from the ‘fake’ buffer to the real one, possibly with scaling, on vblank. I’ll have to figure out the performance implications though.

IIRC the S3C2440 has quite a fancy DMA controller (transfer lists, colour-key transparency, etc.), so if you were willing to forgoe scaling you could get that to do all the grunt work of copying dirty pages to the display buffer and overlaying the mouse cursor. It could probably even be used to automatically update the display start address within the LCD controller once the copy is complete (to double-buffer the display buffers).

How does the RTC work on the Mini2440? You’ll probably want to use the Cortex branch of the kernel so you can use the HAL RTC interface. The Cortex kernel should still work on older machines, although I don’t think I’ve ever compiled it to check!

We’re looking to have a big splurge of effort here in the ROOL ‘office’ with some of the main areas of interest being:

• Build environment improvements, toolchain, autobuilds, etc.
• Getting the latest RPCemu stuff reflected onto the ROOL site (ROM build, disc build, standard hard disc image, etc.)
• Testing the TouchBook stuff
• Miscellaneous things

To be honest, we’re really pleased to see such a vibrant community emerging from the shared source activity – this was our plan all along. After quite a few years of us doing pretty much everything, it’s been a welcome break! :)

•Testing the TouchBook stuff

Speaking of which, I’m hoping to sort out a release of the RISC OS port of the ‘mkimage’ utility sometime in the next few days, along with updating the wiki & ROM readme with information on how to set up TouchBook & BB-xM SD cards.

Mousetastic works for now, thanks.

Some more work reveals the LCD controller only supports 8-bit and 32-bit colour modes as used by RISC OS - the formats for other modes differ. Not sure I really care about this though. If I wind up using a double-buffer system I suppose I could try conversion.

It also enjoys eating memory bandwidth – the bandwidth reported by RISCOSmark drops from 250% to 150% when switching from 8-bit to 32-bit colour. Still, it’s noticeably quicker than my SA RiscPC!

How does the RTC work on the Mini2440?

Well it doesn’t use IIC, which might be an issue? (I’ve only quickly scanned over the documentation)

Found my camera and took a picture : Here

Found my camera and took a picture

Brilliant! Does anyone have any further thoughts on addressing the iconbar size issue?

How does the RTC work on the Mini2440?

Well it doesn’t use IIC, which might be an issue? (I’ve only quickly scanned over the documentation)

Yes, if the Mini2440 uses the S3C2440’s built-in RTC then you’ll definitely want to use the Cortex kernel + HAL RTC interface. To get it working you’ll need to modify the check at line 2380 of s.NewReset to accept whatever location your device descriptor uses (I decided to make the code a bit pedantic and make sure it only accepted RTC devices that advertise themselves as being on an IIC bus). Other than that you shouldn’t need to modify any of the other kernel source, since you can simply ignore the IICOp function pointers that the kernel passes to the RTC device.

the LCD controller only supports 8-bit and 32-bit colour modes as used by RISC OS That is pretty much what the Iyonix does with the new graphics card (32 bit mode is available it just has swapped colours).

The only loss I noticed is a decent frame rate using kinoamp.

256 colours is horrible, and 16 million is too slow.

However 256 greys works nicely (decent monochrome replay is better than no decent replay). Does your port support 256 greys?

The Cortex kernel should still work on older machines, although I don’t think I’ve ever compiled it to check!

There are quite a few v5+ instructions littered around the Cortex kernel. I’m having to work through removing them, and then hopefully the kernel will still work!

Really? Hmm. Perhaps I’d better check tonight to see if anything is wrong. I was fairly certain that it would all compile OK if the environment is set up correctly (an ARMv4 machine type, and the ARM600 MMU file selected instead of the VMSAv6 one; I can’t remember off the top of my head what settings control those).

Although thinking about it, I think you might need to switch to using the Cortex branch of HdrSrc as well.

Cheers, switching to Cortex HdrSrc helps. New problem – the myISB/myDSB/myDMB macros. All of which need conditions & temp registers on pre-v7 targets, none of which have them.

Ah, yes. I forgot about those :)

Okay, Cortex kernel is now running. Few fixes -

- In hdr.Options, GetKernelMEMC and ARM6Support need to be set properly. I used M_CortexA8 as the switch variable

- myISB/myDSB/myDMB seem not to be required – I left the pre-v6 entries for these blank

- The fail code in LookForHALRTC doesn’t pull R12 off the stack, leading to a horrible crash

I have a vague feeling there was something else, but can’t quite remember ATM.

- In hdr.Options, GetKernelMEMC and ARM6Support need to be set properly. I used M_CortexA8 as the switch variable

Yes, that’s right. But it should probably be based around the value of MEMM_Type (defined in Hdr:Global.Machine.Machine)

- myISB/myDSB/myDMB seem not to be required – I left the pre-v6 entries for these blank

Also correct – looking at a diff now, they only get used from code that would get called on ARMv6+. I’ll add some extra conditionals to avoid compiling that code on older machines.

- The fail code in LookForHALRTC doesn’t pull R12 off the stack, leading to a horrible crash

Well spotted!

I have a vague feeling there was something else, but can’t quite remember ATM.

It looks like I added a few CLZ instructions (in ARMv6+ code paths), so you might have had some warnings about those. Plus there were a few other bits that got changed in hdr.Options to enable extra debug output, although I don’t think they should hurt.

Was it that you had to copy over an extra CPUDesc entry from your kernel? Otherwise I’d expect the kernel to panic and go sit in WeirdARMPanic.

I’ll let you know once I’ve checked in fixes for the above.

Your/my fixes are now checked in. The new Cortex kernel seems to work fine on my Iyonix, and compiled into an IOMD ROM OK (apart from some warnings about some BKPT instructions), so it should work OK now on the mini2440.

I have a vague feeling there was something else, but can’t quite remember ATM.

In AMBControl there was an assert that was checking whether the required L2PT protection bits match the hard-coded value of &FFE. The clause was wrong, since I’d copied the L2PT flags from the VMSAv6 code and not the ARM600 code.

That was it!

I just spotted this crazily cheap netbook with an ARM920 inside. Don’t know what actual chip it is, though.

...this crazily cheap netbook with an ARM920 inside…

Strange that they only quote a 2 hour battery life… perhaps they intended to claim 12 hours!

Thought about getting that one or the UbiSurfer earlier this year. What put me off though was the warning that you couldn’t install additional software. Staff wasn’t too helpful when asked why that should be the case though.