ClearView hypertext reader -- now in 32-bit!

Good news everyone!

I’ve just released the first 32-bit version of Merlyn Kline’s “ClearView” application. This is a hypertext document publishing system from the early 1990s.

If you’ve seen the “AVRD” Acorn virus reference document which used to be included with Killer – you’ve seen and used ClearView. I understand it was also used for some Ace Computing and Acorn online documentation. Sadly this isn’t the last version (which I believe was V2.01) which had a few extra features — but it is a solid base to work from!

Please download it from Github and enjoy! If you find any bugs, please open an issue ticket on Github. If you’d like to contribute, please feel free to open a pull request, or submit patches :)

Binary release files: https://github.com/philpem/clearview/releases/tag/1.09_32bit

Source code and issue tracker: https://github.com/philpem/clearview

Special thanks are due to:

• Martyn Wurthner for the 32-bit-clean EuclidX (Ace Film player) module, which is included as part of ClearView under the terms of the original Ace Computing licence.
• An anonymous and very generous benefactor (even ROOL won’t tell me who you are!) for kindly contributing towards the cost of the C compiler. I’m sorry it’s taken me nearly a year to clean the code up for release, but if you’re reading this, I hope it was worth the wait!

Enjoy!

- Phil.

is QuickGuide.Apple supposed to be an invalid draw file? Draw says: “path contains an invalid tag at location 16_10D4”
ClearView says “draw error 111 at location 4308 in draw file”

(RO 5.24 on ARMv7 Pi2, Draw v 1.30 (27-oct-16))

Otherwise this looks nice.

Firstly well done Phil for getting this software resurrected.

I get the same issue as Willard and the Apple illustration does not load in to Draw 1.30 on an ARMX6 but will load in to Artworks.

Saving the file out from Artworks and trying again gives the following error in ClearView:

Unrecoverable internal error Abort on Data Transfer @ &0001A8A

*Where gives
Address &0001A8A8 is an offset &000128A8 in application memory.

Hope this helps

Great work Phil in getting ClearView running in 32 bit mode.
As already reported, the Apple drawfile is not working. However, I already had the jpeg version of the Artworks Apple, which I dropped onto Draw and saved as a Drawfile and now the Manual works as intended.

Hi Norman,

Just tried that, load ArtWorks Apple in ArtWorks and save as Draw file and then replace the Apple one in QuickGuide and then run the SmManual text and it errors on the second page as before.

Even tried running the apple through Draw and saving from there and still the same results.

Argh, sorry folks!

I’ve re-released this as V1.09b, using the same link as above: https://github.com/philpem/clearview/releases/tag/1.09_32bit

It appears I’ve been caught by the OmniClient/LanManFS file corruption bug (https://www.riscosopen.org/tracker/tickets/459). To make matters worse, Sunfish won’t work on my Pi.
I’ve switched to building on RO4.02 on RPCEmu for now.

Sorry for the inconvenience!

@Doug – can you please try the 1.09b release?
If it fails again, can you open a Github ticket or drop me an email (philpem…gmail.com) with as much information as you can give?
As a starting point — RISC OS version, SharedCLibrary version, *Where output, whether it happens every time, and a list of steps to make it happen.

OmniClient/LanManFS

It’s unfortunate that no one can reproduce this bug as I trash many many (if not all) files because of Omniclient. Especially on OMAP4. To save a file from StrongED makes a corrupted document (filled with 0 at the end).

Hi Phil,

Thanks for the update but it gives the same error message as before on an ARMX6 andf also Iyonix.

I have sent you a PM but just in case below are the details:

1.09b fails and aborts the same as the previous version.

This is on an ARMX6 , RISC OS 5.25 (24-Aug-18), SharedClibrary 5.97 (11 Jun 2018). Draw version 1.30 (27-Oct-16).

So load ClearView to the iconbar and then drag the SmManual text in QuickGuide to the ClearView icon and it loads the first page OK.

Click the double arrow icon to go forward and it gives the following error:

Error is – Unrecoverable internal error Abort on Data Transfer @ &0001A8A

*Where gives
Address &0001A8A8 is an offset &000128A8 in application memory.

I noticed you have a Pi1 which is ARMV5 compliant so I tried it on my Iyonix and it failed in the same way on RISC OS 5.24.

So I then launched Aemulor on the ARMX6 and ran ClearView via that and tried it again and it worked so either there is still some 26bit code hiding there or perhaps it is around high vectors as even 5.24 has zero page protection to stop reads/writes etc.

Also what version of the C Complier are you using and what is the target settings for resultant code is it ARMv7/8 complaint?

Hi Doug
I was doing some work on my Pi 4 and noticed the updated ClearView so I downloaded the new files and tried it and like you said, it spat the dummy when moving onto page 2, it got as far as the drawing the rectangle round the apple then gave up. I tried the new version on my Pi-Top (3B+ RISC OS 5.27 16-Apr 2020) and it worked perfectly. Then reading your comment about thr Pi1 I checked my sCPU ettings and they are forARMv5 which is why ClearView works sucessfully on my Pi-Top. I wonder would !PatchSWP help to fix the problem?

I’ll give a Pi 3B+ a try later today. I also have the Beta RISC OS image which comes with ZeroPain. You might well be right about zero-page access, I fixed a few bad pointer references and incorrect memory initialisation issues to get this going. Wouldn’t surprise me in the least if I’d missed one.

I’m using the ROOL DDE29b compiler, the Makefile for ClearView is in ClearView.Makefile. Build commands are as follows:

CCflags = -c -depend !Depend -IRISCOSLib: -throwback -memaccess -L22-S22-L41
C++flags = -c -depend !Depend -IC: -throwback
Linkflags = -aif -c++ -o $@

These are straight out of the RISC OS Open ARMv7 compatibility primer: https://www.riscosopen.org/wiki/documentation/show/ARMv7%20compatibility%20primer

I have Aemulor running on boot. I’ll turn that off and try again. D’oh!

Hi Norman,

Already tried !PatchSWP with no effect.

I also tried it on my Iyonix running both 5.24 and also todays latest softload ROM and it still gave the same error.

I also used SetCPU/Alignment setting on the Iyonix, just in case, and it still fails on that so it may not be a strictly ARMv5 issue but is is strange it works on a Pi3 when set that way but not an Iyonix.

Hi Doug
I am using Andrew Conway’s !CPUSetip to put my Pi3B+ in ARM 5 compatability mode. I am surprised that the AMRX6 complains as it is usually very tolerant. I have never used ClearView before but I can seen that it has great potential. Sorry but run out of ideas to suggest but hopefully Phil will be able to solve.the mystery

I’ve just managed to reproduce the bug on my Pi 1 by disabling Aemulor and setting the CPU mode to ARMv7 Strict.

It’s crashing inside the RISC_OSLib Draw handling code — CV calls draw_append_diag, which in turn calls draw_doObjects, dr_SetScreenState, and then crashes just after an OS_Byte &75 SWI call (in the os_byte) function. It’s pretty clearly a null-pointer dereference.

Sadly there’s no debug info or library source included with RISC_OSLib, so I’m not sure what particular condition is being violated. It doesn’t appear to be anything ClearView is doing, as the inputs to draw_append_diag() all appear to be valid.

Bit of a head-scratcher this one.

Sadly there’s no debug info or library source included with RISC_OSLib, so I’m not sure what particular condition is being violated. It doesn’t appear to be anything ClearView is doing, as the inputs to draw_append_diag() all appear to be valid.

The sources to RISC_OSLib are here. It looks like a long hidden bug where someone’s passed 0 to os_byte() when, unusually, a non-NULL pointer is always needed even if you don’t want the result. I’ve built a copy with a fix in to try – any better?

I am using Andrew Conway’s !CPUSetip to put my Pi3B+ in ARM 5 compatability mode.

Hmmm. Does this tool change anything at all? AFAIK, the later ARM cores don’t allow to switch to ARMv5 compatibility (which was only for rotated loads IIRC), this was a unique feature of the ARMv6 core inside RPi 1 and the early RPi Zero.

Out of curiosity I downloaded ClearView and it runs fine on my Pi3B (5.27 19-Apr-20), CPU set to fast mode. I can view all of the files from the ClearV109B_32bit/zip, except film which I suspect needs another app to run. ;-)

The sources to RISC_OSLib are here. It looks like a long hidden bug where someone’s passed 0 to os_byte() when, unusually, a non-NULL pointer is always needed even if you don’t want the result. I’ve built a copy with a fix in to try – any better?

Cheers Sprow – that seems to have fixed it! I wonder how long that’s been in there… and if the same mistake exists elsewhere!

I’ve done another release as 1.09c which is linked against Sprow’s patched RISC_OSLib — can anyone who’s had problems please give it a go?

Download from https://github.com/philpem/clearview/releases/tag/1.09_32bit

Hi Phil,

109c works here now on my ARMX6 and thanks to you and Sprow in solving the issues and along the way resolving a bug in another application.

Doug

That was it, now works fine on my ARMv7 Pi2!

So now the question is, are there any publicly available interesting docs in clearview format? I’m not an old-school Acorn user, so I’d never heard of clearview before.

/me goes off to browse the drobe archive…

A lot of educational software (from dec_DATA?) was advertised as made with ClearView.

Hi Phil
109c is working on my Pi4 and ARMbook laptop so well done (and thanks to Sprow). Do you have any information about creating Ace film clips? Are there any alternative Apps that can produce these files?

Cheers Sprow – that seems to have fixed it! I wonder how long that’s been in there… and if the same mistake exists elsewhere!

The bug’s been there as far back as CVS history stretches (1996), so anyone calling that will have found the reset vector overwritten by OS_Byte’s R2. I did also check all other occurrences of os_byte() in rlib for similar, but no matches found.

So now the question is, are there any publicly available interesting docs in clearview format? I’m not an old-school Acorn user, so I’d never heard of clearview before.

The only free one I know of is AVRD, the old Acorn Virus Reference Document. That should be in the Arcade BBS archives.

109c is working on my Pi4 and ARMbook laptop so well done (and thanks to Sprow). Do you have any information about creating Ace film clips? Are there any alternative Apps that can produce these files?

It was a fairly common animation storage format in the 90s. I seem to recall The Complete Animator’s file format being Ace-based, so perhaps that might work?

If R-Comp have updated the playback library, I’d be quite interested in adding TCA support to ClearView. With that said, I’d probably have to beg, buy or borrow a copy too — all I have is the PC version.

The bug’s been there as far back as CVS history stretches (1996), so anyone calling that will have found the reset vector overwritten by OS_Byte’s R2. I did also check all other occurrences of os_byte() in rlib for similar, but no matches found.

Ouch!

Hopefully the next release of the C compiler will include the fix.

Speaking of ClearView, I’ve been in touch with Merlyn. Sadly V1.09 is the latest he has, though I have V2.01 kicking around here in binary form. It’d be a bit of a slog, but I could (in theory at least) add in some of the features from 2.01. Job for later perhaps.

Hi Phil,

The InitApp utility crashes badly on my Pi3+ when run from WIMP but is OK when WIMP not running. So OK when I boot but as the !Run file runs !Boot it crashes when I click on the app. Commented the run of !Boot at the top of the !Run file and works OK.

Rachel

the only clearview version of the AVRD I could find:
hensa/virus

file is a112.arc

is AVRD 1.82
and the new Clearview does indeed display it properly!