Bounty proposal: Paint

Yes, it’s a RISC OS 5 “feature”.

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/NetBSD/build/c/usbmouse?rev=1.17#l742

Yes, it’s a RISC OS 5 “feature”.

After all these years of using RISC OS I have just noticed that StrongED and Edit scroll text at five lines a time. The mouse also scrolls Paint at five lines.

Using VNC and driving from the Mac a scroll wheel mouse does alter the zoom one step at a time.

Yes, it’s a RISC OS 5 “feature”.

What would you recommend the best workaround is for this? The simplest would be I have the code ignore every 2nd-5th scroll event using a counter but then Paint would need a further update if this behaviour changes. Beyond that maybe I should reset the counter, say every second or so. How likely is this “feature” to change in the near future? I guess the code needs to check the OS version too. Anyone know how many steps RISC OS Ltd’s code will scroll?

Anyone know how many steps RISC OS Ltd’s code will scroll?

OS4.39 has a configuration tool which works in terms of fast and slow rather then steps.

Using the A9home, OS4.42, with the bounty beta Paint that configuration does not appear to affect Paint, which vertically scrolls at a value larger than OS5 does, 8?, but CTRL-scroll does work in single steps.

Pending a fix to the USB mouse driver to queue mouse wheel events so they can be interpreted at a more appropriate level I’d a) suggest that scrolling by 5 is a daft idea and b) if a window can accept scroll requests, send them regardless of whether the window has scroll bars (some applications might like this hint hint).

Hmm, this seems to be the first revision of usbmouse that has that 5 time code in it usbmouse revision 1.6 but does revision 1.6 mean I can just to RMEnsure USBDriver 1.6 as a way to detect this “enhancement”?

Yes, it’s a RISC OS 5 “feature”.

Perhaps this bounty should have attracted more generosity before building on top?

Hang, on, here’s the revision graph for a USB VersionNum file, https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HWSupport/USB/NetBSD/VersionNum?graph=1;only_with_tag=MAIN and on 6th May 2004 that seems to be on module version 0.25 (revision 1.26 of the VersionNum file), which is the same day that revision 1.6 was submitted for usbmouse.

So, I’ll do “RMEnsure USBDriver 0.25” and skip the last 4 of every 5 scroll steps in the sprite window if that’s true. Please can someone confirm if they think I’m talking sense? :)

TitaniumDev.mixed.RiscOS.Sources.HWSupport.USB.NetBSD.build.c.usbmouse

/*
			relz*=5; // a bit more movement...
			relw*=5;
*/

As tested here, that fixes the bounty Paint beta, and everything else!! Another slight disadvantage is that it would need to be applied retrospectively.

Using the A9home, OS4.42, with the bounty beta Paint that configuration does not appear to affect Paint, which vertically scrolls at a value larger than OS5 does, 8?, but CTRL-scroll does work in single steps.

David if you scroll the sprite window of the bounty Paint without CTRL held, are you saying it is vertically scrolling by a larger amount on OS 4.42? If so, is it an unacceptably large amount?

Yeah as you say it would rely on everyone running the latest USBDriver module.

David if you scroll the sprite window of the bounty Paint without CTRL held, are you saying it is vertically scrolling by a larger amount on OS 4.42?

Yes, it looked like 8, as opposed 5 on OS5.

If so, is it an unacceptably large amount?

No, it is only minor.

It doesn’t matter much as the new Paint didn’t last long on the A9home. It fell over with an undefined instruction at &27F74. The A9home was only tried as it is the only ROL hardware left here now, it was only for a scrolling and zooming test. I am not looking to use a ROOL Paint on the A9home.

It fell over with an undefined instruction at &27F74.

For info only.

A9home

00027F68 : EBFFEA67 : g͡Π: BL      &0002290C
00027F6C : E3580000 : @@X„ : CMP     R8,#0
00027F70 : 159B0018 : X@õU : LDRNE   R0,[R11,#24]
00027F74 : 112FFF38 : 8ˇ/Q : Undefined instruction
00027F78 : E5BD0014 : T@ΩÂ : LDR     R0,[R13,#20]!
00027F7C : EBFFEDA6 : ¶ÌˇÎ : BL      &0002361C

Titanium

00027F68 : EBFFEA67 : g͡Π: BL      &0002290C
00027F6C : E3580000 : @@X„ : CMP     R8,#0
00027F70 : 159B0018 : X@õU : LDRNE   R0,[R11,#24]
00027F74 : 112FFF38 : 8ˇ/Q : BLXNE   R8                 ; ARMv5 or later
00027F78 : E5BD0014 : T@ΩÂ : LDR     R0,[R13,#20]!
00027F7C : EBFFEDA6 : ¶ÌˇÎ : BL      &0002361C

Since it’s an error on legacy system with access to a ROL modified Paint I don’t think it counts as a problem. From the sound of things you’re of the same mind.

Really, with Paint in the ROM, testing on A9 is testing a use case that won’t happen (Or at least it’s unlikely to happen)

Here’s an updated build.


If USBDriver >= 0.25, the last 4 of every 5 scroll wheel events should now be skipped. Please can you re-test on RISC OS 4 and 5 and confirm if it works? If it doesn’t, can you let me know what version of the USBDriver module shows up on your system¹?


¹Strangely when I run RISC OS 5 in RPCEmu I find no trace of a module called “USBDriver”, on disc or in memory. Is it loaded conditionally perhaps or have I got the name wrong?

It doesn’t matter much as the new Paint didn’t last long on the A9home. It fell over with an undefined instruction at &27F74. The A9home was only tried as it is the only ROL hardware left here now, it was only for a scrolling and zooming test. I am not looking to use a ROOL Paint on the A9home.

Unfortunately, it does matter to me in the longer term because one of ROOL’s requirements is that the software supports RISC OS 3.5 and up.

Not that strange.
The only USB drivers for the RPC were (are) third party items – the RPC used a bus mouse hardware item and RPCEmu is using a pass-through of the Windows (or linux) mouse functionality as part of the emulation. So, basically it isn’t present in the IOMD build.

You can have the same fun by running an old Acorn era utility that accessed the ADFS module functions on RPCEmu and then trying on a Beagle or Pi installation with no ADFS module present :)

It fell over with an undefined instruction at &27F74.

This must either be a build setting of the DDE that emitted that instruction, or an assembler routine that Paint has loaded. Either way, it’s hopefully safe to say that that has nothing to do with any of the code changes I am making to Paint. :) Well, unless of course something’s erroneously overwritten that location in memory!

Unfortunately, it does matter to me in the longer term because one of ROOL’s requirements is that the software supports RISC OS 3.5 and up.

Since it’s in ROM the OS revision wouldn’t be the issue, after all if you’ve loaded a v5.2x OS v3.5 – v4.3x compatability doesn’t enter in to it.
If it’s to be included in an RPC (IOMD) ROM then use of an ARMv5 or higher instruction would be the issue.

Since it’s in ROM the OS revision wouldn’t be the issue, after all if you’ve loaded a v5.2x OS v3.5 – v4.3x compatability doesn’t enter in to it.
If it’s to be included in an RPC (IOMD) ROM then use of an ARMv5 or higher instruction would be the issue.

Of course. Not sure why I was equating ARM chip version with OS version!

If USBDriver >= 0.25, the last 4 of every 5 scroll wheel events should now be skipped.

How are scroll wheel events differentiated from clicks on the scroll arrows? Both deliver the same scroll request so does that mean that 4 out of 5 clicks on the scroll arrows are ignored too.

How are scroll wheel events differentiated from clicks on the scroll arrows? Both deliver the same scroll request so does that mean that 4 out of 5 clicks on the scroll arrows are ignored too.

Argh good point, thank you! What I need to do is read the mouse pointer location when the scroll event is received. If it is very near the scroll buttons, the workaround (and the zoom feature) need to be disabled. At the moment, it does what you said.

Here’s an updated build.

The updated build seems to be the same as the previous one.

Unfortunately, it does matter to me in the longer term because one of ROOL’s requirements is that the software supports RISC OS 3.5 and up.

True! RISC OS 5 is supposed to be able to run on a RiscPC as a softload. So that is a bit of a mystery ATM. (I am building a standalone application.)

RPCEmu does not need a USBDriver module, the host does all that. On the Titanium USBDriver is a 0.82.

The updated build seems to be the same as the previous one.

That’s my mistake, sorry! Had a condition back to front :( Please can you give this one more go?

Please can you give this one more go?

That download is identical to the previous 2 as verified by !DirSync, and its zoom jumps in large increments as before.

Can these downloads at least have individual filenames? All 3 arrived here as PaintBountyFeb17.