ZeroPain and *Hon -> *Pointer -> HidePointer module

I have been investigating many ZeroPain logs which all have the same location but many different Wimp tasks and Last App. One example is…

Time: Thu Jul 23 17:03:36 2015
Location: Offset 0000e504 in module WindowManager
Current Wimp task: FullNames
Last app to start: Reporter
   
R0  = 0000006a R1  = 5eb00008 R2  = fc12164c R3  = 00000001
R4  = 00000000 R5  = 00000000 R6  = 00000000 R7  = 00000000
R8  = 00000000 R9  = 000003fe R10 = 2122fa4c R11 = 00000124
R12 = 20004ab4 R13 = fa207f18 R14 = fc12d0f0 R15 = fc12d090
DFAR = 0000006a  Mode SVC32  Flags nzCV if   PSR = 30000013
   
fc12d048 : 13a00034 : MOVNE   R0,#&34            ; ="4"
fc12d04c : 128c6e6d : ADDNE   R6,R12,#&06D0      ; =1744
fc12d050 : 1affffe7 : BNE     &FC12CFF4
fc12d054 : e3a00022 : MOV     R0,#&22            ; ="""
fc12d058 : eb000000 : BL      &FC12D060
fc12d05c : e8bd80e2 : LDMIA   R13!,{R1,R5-R7,PC}
fc12d060 : e92d4806 : STMDB   R13!,{R1,R2,R11,R14}
fc12d064 : e59c118c : LDR     R1,[R12,#396]
fc12d068 : e59c2190 : LDR     R2,[R12,#400]
fc12d06c : e3510001 : CMP     R1,#1
fc12d070 : 23800c01 : ORRCS   R0,R0,#&0100       ; =256
fc12d074 : 1a000009 : BNE     &FC12D0A0
fc12d078 : e59c12d0 : LDR     R1,[R12,#720]
fc12d07c : e1a0b000 : MOV     R11,R0
fc12d080 : eb00000f : BL      &FC12D0C4
fc12d084 : 78bd8806 : LDMVCIA R13!,{R1,R2,R11,PC}
fc12d088 * e590e000 * LDR     R14,[R0,#0]
fc12d08c : e33e0086 : TEQ     R14,#&86           ; ="ŷ"
fc12d090 : 01a0000b : MOVEQ   R0,R11
fc12d094 : 059c12cc : LDREQ   R1,[R12,#716]
fc12d098 : 0b000009 : BLEQ    &FC12D0C4
fc12d09c : e8bd8806 : LDMIA   R13!,{R1,R2,R11,PC}
fc12d0a0 : e1a0b000 : MOV     R11,R0
fc12d0a4 : eb000006 : BL      &FC12D0C4
fc12d0a8 : 78bd8806 : LDMVCIA R13!,{R1,R2,R11,PC}
fc12d0ac : e590e000 : LDR     R14,[R0,#0]
fc12d0b0 : e33e0086 : TEQ     R14,#&86           ; ="ŷ"
fc12d0b4 : 01a0000b : MOVEQ   R0,R11
fc12d0b8 : 03800c01 : ORREQ   R0,R0,#&0100       ; =256
fc12d0bc : 0affffed : BEQ     &FC12D078
fc12d0c0 : e8bd8806 : LDMIA   R13!,{R1,R2,R11,PC}
fc12d0c4 : e52de004 : STR     R14,[R13,#-4]!

My investigation so far seems to indicate:

1. It it caused by the *Pointer or *Pointer 1 commands.
Note that *Hon uses *Pointer 1

2. The logic flow may be something like…

s.wimp01   Pointer_code
           Pointer1_code
           setptr_shape
           SWI XWimp_SpriteOp
s.wimp04   wimp_SpriteOp
+e4fc      BL do_spriteop
             SWI XOS_SpriteOp   r0=&6A and V are set on return
+e500      LDMVC                ignored
+e504      LDR  r14,[r0]        to get error number
           -> ZeroPain log

3. Note that *Help Pointer gives…
*Pointer turns the mouse pointer on/off.
Syntax: *Pointer [0|1]
…which is misleading because 0=Off, 1=On
and it does not indicate that *Pointer acts like *Pointer 1 (On)
or that there is a Pointer 2 which appears to do absolutely nothing!

4. These ZP logs only appeared on my Iyonix, not on my RPi.
I do have more modules loaded on my Iyo but my RPi is clean, but neither of the two vector listing programs I have will work (not suprisingly!), so I have not yet checked what is on SpriteV.
However, I noticed module HidePointer v0.20 (20 Aug 2005) © Zap developers.
This seems to be the cause of the ZeroPain problems, as without it there is no problem.

5. I cannot find the source to HidePointer on the Zap website.
However, it does seem to execute code on CallEvery 9cs which can load r0 with &6A then call XOS_Byte.
HidePtr also sits on ByteV!
Could this be a clue?

Anyone know where to find the HidePointer source, or make any sense of this?

and it does not indicate that *Pointer acts like *Pointer 1 (On)

Eh?

<tries it…> Damn. Never knew that!

or that there is a Pointer 2 which appears to do absolutely nothing!

I wonder if there was supposed to be an option for a secondary pointer (like a hand icon) that might have been used this way back in the days of Arthur, but it is now mostly historical? Just a guess…

Bingo. Just downloaded the Arthur 0.30 archive from 4corn and browsing the gibberish in Notepad (!), I can see this:

Syntax:  *POINTER {0/1/2}

I can look in more detail later but it looks like a nasty thunderstorm is incoming so I’ll probably yank the plugs soon. Better safe than smouldering rubble…

Anyone know where to find the HidePointer source, or make any sense of this?

The logical place…there’s a reverse engineered (from module binary) source on the Zap CVS → http://cvs.tartarus.org/CVS/zap/sources/extensions/HidePointer/s/module%2Cfff?revision=1.1&view=markup

I can look in more detail later but it looks like a nasty thunderstorm is incoming so I’ll probably yank the plugs soon. Better safe than smouldering rubble…

Might be worth getting an isolation transformer to power your kit so you can carry on with techno stuff and avoid the feeling that you’re in an isolated farmhouse in the French countryside. :)

Seriously though, the isolation option caters for the instances where a power line zap comes in without thunderclouds visible.

source on the Zap CVS

Handy, for when you want to know the innards. Like now.

Might be worth getting an isolation transformer to power your kit so you can carry on with techno stuff

Already spoke to EDF, years ago. With three phase delivered at 230V(380V) via half a mile (or so) of bare overhead line, the only viable option is a full on-line UPS. EDF can supply me with one that is arranged so the incoming-mains-end can sacrifice itself without effecting the other end – heavy duty suppression and spark gaps. Needs to be professionally installed (if the earthing is naff, then it plain won’t work, so this must be fitted and checked). Price? Eye watering.

That said, if the spark is happy travelling miles to earth, there probably isn’t a whole lot the earth end can do when we’re talking about domestic voltages, except try to fail sort-of gracefully.

Actually, the hardware that was trashed last time was the ADSL router. Lightning either directly hit the phone line, or induced a huge current in it (by hitting a mains line running alongside, perhaps?). The results? Dead Livebox with bits rattling around inside. Bulging PSU brick (which tripped out the power). Everything connected to the Livebox, also toast. http://www.heyrick.co.uk/blog/index.php?diary=20120905

I don’t really believe that any isolation transformer nor UPS would be able to protect a phone jack. I’ve seen suppression sockets with ways to plug in phone equipment (and sometimes RJ45s too). These might work if there is a nearby hit that causes a transient – but a direct hit? Doubtful they’d be any good at all. Since I’ve been here (2002), I can recall three direct hits. One to the power line that caused a tungsten bulb to explode. One to the power line that made a bright blue flash in the meter (but I had already pushed the trip switch so it didn’t go any further, although the meter smelled like the back end of a laser printer for days afterwards!), and the one linked above that hit the phone line.

[a fourth one, in ‘98, hit the TV aerial (since removed) that arced across the roof and destroyed dozens of old nails – the roof was going to be reroofed in a few weeks but it was surreal to see a bunch of slates just fall off; that was however not one of my better moments, having wanted to get a ladder to get into the old loft to put some buckets around – so there I am walking through a thunderstorm with a large three-section metal ladder….yeah, I’ll be flying a kite next, right?]

So…

avoid the feeling that you’re in an isolated farmhouse in the French countryside. :)

Perhaps better to just accept that this is an isolated farmhouse in the country, and make sure that equipment has batteries.
At the moment, the only RISC OS machine that I can do this with is an emulator, though I have my eye on some of the Pi solutions being discussed here. What would be really good (though I’m not sure if it is a design spec of any of them) is to have the display switchable between internal and external so a “Pi laptop” could run autonomously, or it could plug into a monitor and, well, act like a Pi…
[kind of like how laptops do it]

Okay, I looked.
Nominal “support” for *Pointer 0-2 is present in Arthur 0.30 and 1.20 but has been removed in RISC OS 2.00. So it was an early idea that was not continued. More on this in a bit…

The emulators themselves were a barrel of laughs. Host system: an EeePC 901 with XP SP3.

• ArcEm – was capable of loading Arthur 0.30 (the only one to do so) but had many bugs and as such was unable to enter the Desktop no matter what my graphics options were. Seemed to behave better in 16bpp than 32bpp.

• Archie (using DOS/32A in place of DOS4GW) – needed ROMs split into four parts; though I have little confidence in this as it wasn’t even capable of starting RISC OS 2.00 (crashed in UtilityModule with that as the only active module (nothing unplugged, I checked)). Not only that, but somehow it took out my video adaptor so all I could see was every other line bright white and Windows was unable to recover from this (Alt-Tab, etc) and I suspect it crashed the driver as the machine refused to go into standby mode. So I needed to hard-reset. Gee, thanks. <deleted!>

• Arculator – starts Arthur 1.20 in a heartbeat. Fails with Arthur 0.30. Kind of weird to see there are only 23 modules in Arthur (UtilityModule, FileSwitch, DeskTop, BASIC, Debugger, SystemDevices, ADFS, Econet, NetFS, NetPrint, ARMBasicEditor, WindowManager, FontManager, SpriteUtils, SoundDMA, SoundChannels, SoundScheduler, WaveSynth, StringLib, Percussion, HardCopy, International, Podule).

• RedSquirrel – crashed when trying to set up an Archimedes era machine – broken config file perhaps?

• RPCEmu – not tried; doesn’t support the hardware (ARM2, MEMC, VIDC).

Just to be a masochist, I have !A310Em running Arthur 0.30 under RISC OS 3.70 under RedSquirrel. Having a look at the ROM in Zap, it looks like this was a case of “here’s a great idea” that was never implemented…

→ Command interpreter code is called. There is no other command, so this looks to see if there is a parameter. If not then it jumps to the *Pointer 1 code. If there is, it tries to match the ASCII for 0, 1, or 2. If ‘2’, it jumps to a hard branch (to &03858038) which pushes R0 to R13+0 (with no address update so just overwrites previous R0) if V is set (unlikely in this code path) and then every register is reloaded and then the routine either exits if V is set (which it won’t be…), or it exits restoring flags (which it does). In essence, *Pointer 2 has no effect.

Along the way – here’s a screenshot of Arthur 0.30 (ugly): http://www.heyrick.co.uk/random/pics/arthur030.png (9K PNG)
Here’s one of Arthur 1.20 (slight redesign, nothing major): http://www.heyrick.co.uk/random/pics/arthur120.png (9K PNG)

For people with wide screens, here’s a composite: http://www.heyrick.co.uk/random/pics/arthur030and120.png (18K PNG)

Interesting to look at the palette – Arthur 0.30 has four shades of blue; Arthur 1.20 removes cyan to instead have a sort of flesh/tan colour. Neither version has a true black – it’s a very dark blue.

Okay. That’ll do pig.
It is clear now that *Pointer 2 was an idea that never made it to production code. What was it supposed to do? We may never know…

Along the way – here’s a screenshot of Arthur 0.30 (ugly): http://www.heyrick.co.uk/random/pics/arthur030.png (9K PNG)
Here’s one of Arthur 1.20 (slight redesign, nothing major): http://www.heyrick.co.uk/random/pics/arthur120.png (9K PNG)

Having never seen pictures of early AmigaOS before (AFAIK), today I realised that the colour scheme is very similar to Arthur: http://www.theregister.co.uk/2015/07/24/amiga_turns_30/

So is this just a coincidence, or were Acorn inspired by AmigaOS, or were they both inspired by something else? (DOS? Windows 1.0? – although I think the Amiga predates Windows by a little bit)

Also:

ArcEm – was capable of loading Arthur 0.30 (the only one to do so) but had many bugs and as such was unable to enter the Desktop no matter what my graphics options were. Seemed to behave better in 16bpp than 32bpp.

The only problem I ran into with Arthur under ArcEm is that Arthur refused to enter the desktop because the system sprite pool had been configured to 0KB. If you configure it to a larger size first then it seems to work (configuring from within Arthur didn’t seem to work – but using !Configure in 3.10 did the trick). I also set the emulator to 1MB of RAM, just in case (not sure how much Arthur will reliably work with).

Of course there are some issues with ArcEm that need resolving (probably one or two null pointer dereferences, and I need to teach it about the new screen modes), so perhaps they were the cause of your issues.

(And ArcEm does show the use of dark blue for black in Arthur 0.30, which is what I was really interested in – so presumably that’s a bug in Arthur rather than a bug in any emulator)

I realised that the colour scheme is very similar to Arthur

Ah, the original Workbench. Actually, that’s mostly blue and white.

Try this. Also from 1985.

I rather suspect that there was a phase that people went through in the mid ‘80s when everybody was like "Oh my God, we can have MULTIPLE COLOURS on screen at the SAME TIME! Let’s use them ALL! EPIC!¹ AWESOME!² RAD!³"

Then, a couple of years later, everybody realised how utterly dreadful this was, especially when people still connected computers to domestic TVs using RF cable; and so the world settled down to conventional shades of grey.

Were Acorn inspired by Amiga/Windows? Possibly. Or maybe they developed in a similar way of shoving all sorts of horrid colours onto the screen simply because they could? What better way to show off a 16 colour palette than to use ’em all! ;-)

¹ Too recent.

² Too clichéd.

³ Totally eighties.

Arthur refused to enter the desktop because the system sprite pool had been configured to 0KB.

Ah, yes. I forgot that. I did a *Configure SpriteSize 16 and then restarted the emulator (the setting having been written to the CMOS file).
Dunno how much I actually allocated – it didn’t want to know about “64K”, so I’m guessing it is page units or something weird like that? Using *SInfo reports that the sprite area is 128K so… I guess it is 8K units? It seems to be 4K units in RISC OS 5. Not that anybody should be using the sprite area these days…

Right – ArcEm v1.50 with Arthur 0.30 and a 128K sprite area leads to this: http://www.heyrick.co.uk/random/pics/arcem_arthur_fail.png (11K PNG)

There is also a missing part of display redraws, which may or may not be related to the above problem: http://www.heyrick.co.uk/random/pics/arcem_display_fail.png (13K PNG)

Relax: THESE PROBLEMS ARE SPECIFIC TO ARTHUR 0.30 – I’ve just tried Arthur 1.20 and it appears to work okay.
As you appear to be the current maintainer (“I need to teach it about the new screen modes”), I think World+Kitten would prefer you to spend time with this nice current being-used RISC OS in preference to anything to do with supporting a long long long dead piece of prehistoric code. ;-)

BTW, if anybody wants to join in the fun, the Arthur 1.20 image on 4corn has an extra byte at the end of the file. ArcEm rejects the ROM (sensibly!) so you’ll need to strip it off before using the ROM. This can be done easily with any RISC OS text editor, or within the Windows world using something like Hexplorer (text editors will probably eat the file, assuming they don’t freak out and interpret it as Chinese).

There is also a missing part of display redraws, which may or may not be related to the above problem: http://www.heyrick.co.uk/random/pics/arcem_display_fail.png (13K PNG)

Is that actually with the emulator configured for 1MB of RAM? One of the limitations of ArcEm is that it makes assumptions about how the OS will configure MEMC (the row/column address lines move round in odd manners depending on the RAM size). If the OS misdetects how much RAM there is and sets up MEMC “incorrectly” then ArcEm’s video and sound output will be corrupt.

I guess I could make it detect that and at least pop up a warning message of some kind.

Is that actually with the emulator configured for 1MB of RAM?

Arthur reports 1024K (but it might not understand anything greater?); I can’t try as running ArcEm from the command line using any options (I tried --help and --rom <romname> and --memory <various> seemed to have no effect – the emulator just started as if double-clicked…

Edit1: Also tried setting --memory 512K (original A305 had half a meg) as a parameter in a shortcut. No dice, still 1024K reported.

Edit2: Arthur 1.20 reports 4096K so this may be what is happening.

I can’t try as running ArcEm from the command line using any options (I tried —help and —rom <romname> and —memory <various> seemed to have no effect – the emulator just started as if double-clicked…

Hmm, so I see. I guess the command line parsing is busted for the Windows version. I guess I’ll add that to the todo list!

(And yes, default memory setting is 4M)