Compo returns

Just read the above. I’ll leave doing anything here about the’zips’ question until Andrew reports further. Here the zips seemed OK, but maybe for some reason I didn’t twig.

Not yet had time to see if having things on ‘HD4’ rather than ‘Host’ helps with some puzzles I get. But did make some progress this morning with re-learning about the sheer scope of composcript.

FWIW I was drawn (pun alert) back to Compo when I realised it could be used for scientific graph plotting by feeding data to a selected object area on the canvas. i.e. use composcript to facilitate types of graphic the ‘usual graph packages’ like !Tau can’t provide. Having started re-using Compo I realised again just what massive potential was being left in limbo…

Using RPCEmu is ‘ok’ but for some purposes having the speed, etc, of modern machines would really help with processes like the above which may need to write to every individual pixel in an image. Compo could make that interactive as well as fast and giving superb results.

Nice quality of the scan! If you complete it, might be nice when you remove also the visible paper holes.

@Stefan: Yes, I didn’t bother to hide the holes on the initial demonstration.

if you can get the original scans to me

@John: Yes, I can of course send you scans. Are you sufficiently finished with Dr Wimp to take this one on?

I realised again just what massive potential was being left in limbo…

@Jim: I wasn’t aware either, so am very pleased to support the effort.

Meanwhile, I have a big birthday coming up, so I plan to continue and complete this scanning job starting next week.

Thanks, Bernard! :-) Look forward to getting a copy!

I now have the main test composcripts working on RPCemu. The problems tend to be on my ARMX6. I’m also wondering about a specific point which someone may already know the answer to:

The ‘plotblank’ demo produces a graphic via using a program compiled with ‘C’.

I’m wondering if the (32bit) output from my AcornSoft compiler will work now on RPCemu. Not yet written a test prog to find out. Will it work?

..and, come the day – “Happy Birthday” :-)

@John: Yes, I can of course send you scans. Are you sufficiently finished with Dr Wimp to take this one on?

The ‘new’ second edition is available on the Archive web site and I’m ploughing on with a revised third edition. It’s slow progress and I’m not spending as much time on it as I did with the second edition.

However, I spoke to Gavin at the show on Saturday and assured him that I am making progress with it and it will be finished – hopefully sometime late this year.

Running the scans through ABBYY FineReader would be a fairly mechanical process which wouldn’t need me to think too hard – unlike the third edition.

It might be sensible to send me the scans in batches so that I don’t get sensory overload. I can then return the text to you so that you can make an assessment before sending me the next batch.

I have a copy of the older manual which I think has a nicer cover than the later one linked upthread. I’ll scan it and put it up for people to see as it might be preferred.

Here is a jpeg of the scan to show what the cover looks like.

http://jcgl.orpheusweb.co.uk/temp/CompoCover.jpeg

I think we could perhaps also change the design by replacing the banner text with a new title that shows the manual will be updated for new release(s).

Compo, of course, makes that easy to apply. 8-}

It might be sensible to send me the scans in batches

@John: wilco. I also use ABBYY (v.11 Pro Edition 2013) so we can perhaps share the OCR tasks.

a nicer cover than the later one

@Jim: I entirely agree. And I can edit out ‘Clares’ with PhotoDesk. Why and where a new title, though?

I was tempted to suggest some sort of sticker that said ‘Revived!’ That could go where the current title sits, possibly in a natty frame.

Is the jpeg OK? – I do have a PNG, but it big (14MB).

Is the jpeg OK?

@Jim: yes your 3.6MB JPEG is excellent.

I tried editing the name using !Compo. 8-] This worked OK, but thought I’d leave it as is for what I made available, so leaving the decision open.

@John: wilco. I also use ABBYY (v.11 Pro Edition 2013) so we can perhaps share the OCR tasks.

That sounds like a good approach.

I’ve stayed with v10 pro because I didn’t see the sense in shelling out for a version which runs on Windows 10. For that reason I’ve kept a Windows 7 machine in commission – initially a tower but now a lovely Samsung 17" laptop which Andrew Rawnsley supplied back around the time of the end of this century’s first decade.

I look forward to getting my hands (eyes?) on the first batch.

so we can perhaps share the OCR tasks.

http://jeanmichelb.riscos.fr/Musique/Rhapsody4.html

The manual is not complete, it takes time, the OCR is not 100% reliable, and you have to recreate the images with the program and its different panels which contain the icons.
So it’s very good if the work can be shared, cooperative…

In addition to !Compo (I’m currently using my old 1.23a) I have a number of composcripts which Rob sent to me as demos, etc, or results from conversations with him (c 20 years ago). Most of these work with RPCemu. Some also work with AemulatorPro on my ARMX6. But it should be possible to update/fix ones that don’t. To keep composcript general it would be good if people could help with tackling having !Compo able to run old scripts on newer hardware.

I’ve been wondering if that would be appropriate via the forum here, or if we should set up an email list for !Compo users and ‘updaters’?

Reactions?

Can someone help with this?

http://jcgl.orpheusweb.co.uk/Compo/plotblank.zip

It’s the ‘plotblank’ script demo. One that Rob did. It works OK under RPCemu on my Linux box. But not if I use AemulorPro on my ARMX6. There even if I try to recompile the ‘C’ file it falls over with a ‘division by zero’ error. :-/

Ideally. I’d like to fix this and be able to write modified ‘C’ progs to use as a scientific graph plotter for field levels around the elements of some types of antenna! It has the potential (pun alert) to aid antenna design!

Remember to check error returns from your _kernel_swi calls.

Sorry about this. I’m a numpty in this topic, so I don’t understand the above. Can you explain? That said I’ll try running it again and make a note of the fuller report it pops up.

I suspect the sprite might be created differently than the receiving program expects?

The _kernel_swi(OS_SpriteOp, ...) call isn’t quite like SYS "OS_SpriteOp",... in BASIC: the latter will throw an error if something goes wrong (e.g. sprite wasn’t in memory where expected) whereas the former will return a pointer to the error block, or NULL if there wasn’t an error. There is a way of bodging this to make life a bit easier for initial debug, which is to OR in the constant _kernel_NONX with the SWI number.

The prog loads a PNG and uses that to get the ‘sprite’ object on the canvas. IIUC the ‘C’ prog this is then assumed to be a sprite where each colour is a 0-255 value range. It then alters these one pixel at a time, generating values according to the formula in the C prog.

I did recompile this and compared the ‘old’ compiled version with the new one. Both fail on my ARMX6 and the errors vary from try to try. This is using AmeulorPro. But the original works fine on RPCemu. So far as I can see it should just be peek-and-poking ‘chars’ into the sprite area held in Compo.

I’m using a full colour screen mode on my ARMX6 and assume this means the above should be OK in terms of the internally held sprite data.

The errors aren’t always the same. And sometimes they are in a small white taskwidown requiring a “*quit” to exit. But at other time a plain error which pressing ‘return’ clears. If I’d doing something different I dunno what it is!

Beyond that I’m baffled. I can imagine that the result of a C compilation 20 years ago might fail now, but so does the modern attempt, which compiled without any fuss.

Compo loads the sprite and then moves it so its bottom-left corner is at 100,100 on the canvas, as per the ‘C’ prog. Then things go off-course!

Can someone else try this and say if they get the same problem on modern hardware? Given my high ‘numpty’ level that may help check.

It’s worth pointing out that ABBYY Fine Reader can no longer be purchased outright, only rented for a subscription (£84/yr). It’s being promoted largely as a tool for producing “searchable PDFs”. That is, PDFs where there is an underlying txt layer but the scan is still visible.
Back when you could still buy it, I did a free trial of the Mac version; I didn’t find it to be particularly accurate. Certainly, it was inferior to the open-source program Tesseract.

I’d be happy to have a go at OCRing the scans if needed.

I’d be happy to have a go at OCRing the scans if needed.

Wouldn’t it be better to get a friendly typist to read the pages and type the text out into a simple text document, then rebuild the document with just scans of the images inserted in a nice open document format?

Don’t underestimate the amount of work required. I had the original Impression User Manual, in Impression, and to recapture the images took a huge amount of work. The text was already formatted and arranged in chapters.

Just to say: YES!!! Cracked it!!!… 8-}}

Ok, I’ll calm down now. Then explain that I CAN now get the ‘plotblank’ script run OK on my ARMX6. :-)

I was using Compo 1.23a. Decided to try 1.23c, and yes, that does the job. Just have to remember to use AmeulorPro as well. But I was doing that anyway.

In principle this means it becomes possible to write a !Compo ‘interactive EM field pattern’ generator. e.g. to plot the near and far field patterns of an antenna array and let the user see how they alter when you tweak the array layout, etc. Quite an amazing ability for those wanting to deal with such a mind-bending task. (OK, all antenna engineers are mad, anyway. :-) ) Great teaching tool to have interactive DIY graphics for engineering.

I’ll treat myself to a cup of tea. ..

OK, all antenna engineers are mad, anyway. :-)

Too long stood in front of active transmitter ones?

‘interactive EM field pattern’ generator. e.g. to plot the near and far field patterns of an antenna array

Don’t think I’d understand much of that, unless pretty pictures…

I’ll treat myself to a cup of tea. ..

…but this I can absolutely get behind. I think I’ll do likewise.