AemulorPro use

I’m currently having to use AemulorPro to have !Compo 1.23c run a complex composcript process. This initially involves a mix of opening dirs, running setup files, etc, to ‘get ready’ for actually running the specific composcript file. At present I’m doing the ‘setup’ by running two different obey files and running !Compo in between them. Is there a way this can be combined by having the startup of !Compo directed at AemulorPro without setting AemulorPro to always do this (and also NOT get involved when I test startup !Compo to see if a script works without AemulorPro being involved?

In short: Is there a command I can put in an Obey file that says in essence:

“If Aemulor isn’t running, run it … and then Run !Compo using Amulor” ?

@Jim
Aemulator is a module

You must add !Compo to the list of Aemulator applications.

 
| run aemulator and !Compo (with Aemulator)
dir <obey$dir>
Rmensure Aemulator 0.00 Filer_Run SCSI::SSD.$.Legacy.AemulorPro.AemulorA8_9
Filer_run !Compo

This obey script works, you just need to modify the access path to Aemulator.
I did some tests and indeed the possibilities are interesting, I like programs that use scripts.

I use !MakeDrawf and Pari/GP applications

High frequency is a very interesting area of physics…

The problem then would be running !Compo without Aemulor pro because I want to also check what works without it. That said, if I use the above to get running via Aemulor, I guess I can use a different Obey file that doesn’t mention Aemulor and not have it on the icon bar when !Compo is run?

That way I can choose which startup obey file to run. Does that make sense?

HF is interesting. But I should confess that the bulk of my work before retirement was at or above c 100 GHz. 8-] However at the moment I’m trying to write a composcript that will plot out the field strength in the ‘near field’ around a dipole array of a quasi-Yagi type as used often for VHF radio around 100 MHz. The idea being to plot the field around various dipole arrays so users can see that it may need to be clear of other objects around it – not just in the ‘beam direction’.

FWIW Usually I use !DrawGen for graphics. But here it would mean generating, say, 400 × 400 arrays of small coloured rectanges in a DrawFile. Which seems a bit excessive! So a bitmap makes more sense… and composcript has the potential of making it user-adjustable!

Challenge is that I’m a lousy programmer so just shuffle the statements about until they sort-of-work.

TBH I’m praying someone with more clue than me will at some point take on changing !Compo to no longer need emulation. But I guess it is a horrendous task given all the ‘bits’ which may need changing/replacing!

To use in 32b mode, launch !Compo directly, otherwise use the script. To change from Aemulator to version 32b you must “kill” Aemulator module with its menu.

I would be interested in some examples of equations and drawings to obtain “simple”.

In fact I would like to revise and put into practice what I learned a long time ago, a visit to your site…
https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm

!Compo without emulation a challenge…

FWIW I’m basing what I’m doing at present on the “plotblank” demo of composcripting. As it stands this loads a ‘blank’ (plain white in all pixels) bitmap file (gif) and then paints pixels with a pretty pattern. Its a demo of the ability to do this.

In my case the idea is to use this as a map of field strength around one or more antenna ‘elements’ (think in terms of VHF antennas which has a set of ‘rods’ along a pole. As shown here:
http://ukhhsoc.torrens.org/makers/Armstrong/600_Range/Manuals/Customer/Page11.gif

The field level equ can be something like E = w/sqroot(w^2 + r^2) where r is the distance from the element to the place where you want to know E. (Normalised) And w is a scaling measure of the dipole element length – depends on the scale of the plot in wavelengths.

Then multiply that by a coswave scaled by the wavelength and plot by some suitable variation of the pixel’s colour.

For multielement, add in contributions from elements at different locations wrt each pixel. Alternatiely, if you have 2 or 3 elements, ‘paint’ each one’s field pattern using a different one of the red/green/blue values to see how they add/subtract.

If the size of the plotted area is big enough you see the resulting ‘directionality’ well away from the elements as well as tne near field patterns that are associated.

That then lets you know the space to ‘keep clear’ around the array if you want the shown directionality and gain.

In part, doing this because the result will be useful when trying to assess and explain such antennas for those who buy/make/use them. But also a nice ‘test’ of what composcript can do.

Indeed, it should be possible to make this ‘interactively alterable’ by the user. Composcript lets the user associate actions with clicks on objects on the canvas. There is a demo script that shows being able to click on ‘next’ and ‘back’ text objects to step though a slideshow – which can, of course, include animations as well!

Not sure I can manage all the above. I’m too old, slow, and muddled. But simply doing the plots would be useful. And given the demo scripts may help people realise the astonishing unrealised potential of compo and composcript. It can do far more than most RO will have realised!

For now I’ll just go on using AemulorPro. But I really hope someone – or a group of someones – who are far more computer skilled than me can generate a fully 32bit version. Could be stunning on some of the new hardware that is appearing!

TBH I’m praying someone with more clue than me will at some point take on changing !Compo to no longer need emulation. But I guess it is a horrendous task given all the ‘bits’ which may need changing/replacing!

But I really hope someone – or a group of someones – who are far more computer skilled than me can generate a fully 32bit version. Could be stunning on some of the new hardware that is appearing!

So is the source code available – or to be made available – through a medium that allows this “someone” or “someones” to access it and collaborate on fixing things? And is the plan to agree with all of the copyright holders (whoever they may be) to apply a licence which clearly allows for this to happen?

There is a source code (in BASIC) for the main program. This is for version 1.18. The code (squashed BASIC) for the other versions is also available.

Compo also tends to work by calling small bits of code (various forms) for specific tasks. These are available, but dealing with them means piecemeal updating. BASIC tends to work. Other parts may be compiled, etc.

This ‘fleet of small boats’ approach means that simply writing a new version for each, individually, might be simpler. So people could simply write a new bit as a new-does-what-old-did replacement with the same filename. I guess the way it interfaces is shown by the relevant parts of the main program. But means that we could have many people doing one or two bits, rather than it all being left to just one or two people. But I don’t know enough about programming to tell.

Beyond that, best to discuss these matters with Andrew if interested. My views on coding, etc, aren’t well-enough informed.

The background to this was that Rob sent me copies of the code he had some years ago. Just in case he lost it. I then passed that on to Andrew recently.
Before that, I’d managed to ‘lose’ my copy of the ‘archive’ from my main machine when updating as far as my ARMX6.

However every now and then I had another search though the piles of old backup CDROMs and DVDROMs I’d made – and recently FOUND what Rob had sent to me. Sent Andrew a copy, and that led to where we now are.

BTW Rob has been looking at the forum, but is away on holiday at present, I think. But he decided to move away from RO programming some years ago.

So people could simply write a new bit as a new-does-what-old-did replacement

That is not ‘simple’ … and difficult without exact documentation of the interfaces between the ‘bits’, AND of what each ‘bit’ did what it did and why. That information may be in a separate document, or in the original source code. Without either, too many assumptions have to be made, which takes time and leads to something not working.

This is above my head so my views can only be innocent presumtions – hence I may be wrong.

But the source code for version 1.18 of compo IS something Andrew and I have – and it is in plain BASIC. I am assuming that can give useful info on how each helper ‘bit’ is called and used. What it does is then shown when you use capabilities in the existing working versions. No one person may have the time and determination to do all. But perhaps one or a few people could tackle one or a few each.

That said, composcript, etc, allow the user to add their own functionality anyway. So that could replace some of the ‘came with’ abilities relying on misterious bits. Alternative approach perhaps.

No one person may have the time and determination to do all. But perhaps one or a few people could tackle one or a few each.

So is this source going to be available in a form that these “few people” can tackle “a few each”? All of the (very valid) technical points that Martin raises aside, this really needs:

• The source to be available under a clear, Open Source licence that makes “a few people” feel safe to work on it, and

• The source to be available in a form that makes it possible for “a few people” to collaborate on changes without tripping each other up (by which I mean in a source repository like ROOL’s, or one of the many public ones).

ETA: If you’re saying that the task is a collection of simple, small fixes, then the best way to make it happen is to make the bar to entry as low as possible. People need to be able to spot simple fixes, make them, and then see those fixes become part of a single, common build of Compo without jumping through many hoops. What we don’t want is multiple, competing versions of Compo on different people’s websites, each with a different bit fixed and no easy way to merge them all back into a whole (either for practical or licence reasons).

In short: Yes, I agree with the above. If/when/how that may happen I can’t say. But the potential seems worth people at least trying to do this.

It is also worth bearing in mind that composcript can also enable new ways to do some of the old tricks and then bypass needing to call bits of old code which remain closed books. Composcript is documented.

What I’m seeking is to attract people towards seriously looking at what may be possible, and the best ways to achieve it.

But the potential seems worth people at least trying to do this.

I did some tests hoping not to offend anyone for copyright :-(
n fact there is a problem with all the cs_prog, because !Compo (32b mode) does not return the correct address of the spritearea and therefore all the programmed scripts are Ko.
No problems with 26b mode the adress is correct and therefore contains at least one sprite.
!Compo modifies HIMEM to store its spriteareas
You can check addresses: (ARMX6)

 
26b Mode
*show *select*
.selected(Number) : 3
.selected.imagebase(Number) : 105628032

32b Mode
*show *select*
.selected(Number) : 3
.selected.imagebase(Number) : 14828380
 

Any suggestions about sprite areas and organization of the memory of a program in Basic are welcome

Is it that the SWI returns a different value? If so, is this difference in value systematic? (Pun alert!) … by which I mean predictable/consistent? The script example I’m working on uses the SWIs to call the start value and width/height of the loaded bitmap image. Hence my question.

Is the highmem change in the main BASIC code?

’m working on uses the SWIs to call the start value and width/height of the loaded bitmap image

This is the problem that prevents the scripts from working!
In your program, do a test on the dimensions of the sprite (width and height), the good values​with callblank are (400,400) but (1,1) in mode 32b

Himem doesn’t seem to change, but the wimpslot does, it’s the same in both modes.

This makes me ask: Is the problem with the ‘C’ code I wrote, or in the composcript loading the ‘blank’ image, or in the main Compo BASIC. or…?

The ‘C’ I wrote does make two swi calls, carried over from the initial ‘plotblank’ demo. I am using an old version of the ‘Acorn’ compiler.

Trying to determine where the code would need changing.

Hello, Eureka (for archmides user) :-)

In !Run file you need to change the line

 
Set Compo$MemoryManager Auto
 

with

 
Set Compo$MemoryManager Dynamic
 

Otherwise these DAs do not appear in the TaskManager

Otherwise these DAs do not appear in the TaskManager and therefore the scripts cannot retrieve the sprites.
Auto :-(

@Jim
I hope to read your articles and use them.

Bon appétit.

YES!!!!! :-))))

That lets me run 1.23c and it will run the ‘plotblank’ scripts that call my new plotting routines (compiled from C) WITHOUT needing Aemulor!! EXCELLENT. Faster, as well.

THANKS. Jim

FWIW as yet I’m only plotting the time-averaged rms E field around one dipole. So a boring plot. But now that works (without Ameulor) I can add in the waveshape modulation and then having more than one dipole in a phased array to show how the result becomes directional and you get antenna ‘gain’. When I get somewhere with that I’ll put a copy on the web and write about it.

At some point I’m hoping the prog will be able to read in a file listing the relative locations and phases of a user-chosen set of elements. Allowing ‘graphic DIY’ of an antenna by the user.

People in EM tend to use expensive software packages for this kind of thing. Here it can just be a natty free demo / learning tool. And also as part of a compo controlled slideshow presentation.

Looking at the code, !Compo takes Risc OS 32b into account, which is a very good thing.

Ok for a walk in electro-magnetic fields with a teacher…

Scripting can be used for many other areas.

Indeed. I’d forgotten just how much composcript opens up to being possible. When the idea of making it available again cropped up I had a fresh look and realised the sheer open flexibility it offers. Presentation slide shows with interactive graphs, animations, etc, changeable with a click on an object on the preset canvas, etc. In essence you can plug in your own code, leaving Compo to render/act/respond.

Diversion: FWIW Although my second textbook is available as a PDF, my first isn’t. I had to write that via writing an extension program for VIEW/PipeDream which then rendered maths, etc. Problem is that this only ran on the Master-era machines and I never managed to get it to work on fully RO machines. So the old files aren’t renderable and I only have paper copies.

Mention this because topics like antenna analysis and design, and the field patterns and propagation of EM ‘beams’ was a key part of that 1st book.

Further OT: Oddly, the main reason I regret the loss of access is that the same field anaysis approach would apply to QUAD electrostatic speakers in Hi-Fi. :-) Not sure how many here would pick that reference up! 8-} Mind you, I could now use Compo to illustrate this and even automate showing some results. If only I could program better than my usual “so why doesn’t that work, then…” loop…

It’s a shame if we can’t get your work back :-(
The text in view files is visible in an editor, but retrieving a book is a big job.
Your second book is Information and Measurement?
I had a friend who had a Quad amp, it was a reference!

Good scripting.

So the old files aren’t renderable and I only have paper copies.

You have the files, yes?
Do they work under emulation?

If so, then perhaps they can be recovered that way? Even if the images are recreated by using screenshots from the emulator, it’s a start.

The text in view files is visible in an editor, but retrieving a book is a big job.

Where there’s a will, there’s a crazy person who says “let’s try this improbable method”.

Example – many years ago I was tasked with migrating a small company from a custom DOS based program (called Snip, if I remember correctly) to a standard Windows database. Actually, I wasn’t tasked with anything, the narcissistic arsehole I was living with was (and for paid for it), but I ended up with the job as he was such a dick he couldn’t even correctly install Windows.

Aaaanyway, I inherited this cluster* and set about sorting out the mess. ;)

The creator of Snip was on talking terms with the company, but those terms usually meant “yes, I can do that in return for cold hard cash”.
When it came time to do the export to dBase file, the guy saw the writing on the wall and quoted an obscene price. The company was not happy but had to start working out what to cut back on in order to afford it.
I asked to borrow their backup machine over the weekend. Given this was way before GDPR they handed it to me.

I played with Snip, it was odd, but it did have a function to spew out a report on many many pieces of paper.

By Sunday night, I had the company machine “printing” a report, and the narcissist’s PC receiving a database file by Xmodem on the serial port.

In between? My trusty A5000 that was pretending to be a printer, interpreting the control codes to build each page in a memory buffer, and every form feed it would strip the data out of the “page”, make the next bit of the database, and write it to the output buffer. When a 256 byte block was ready, it would be sent, and the pointers shuffled for the next time.
It was some crappy BASIC that I threw together to do the job.

On Monday, narcissist took the file and claimed he’d worked magic. I was expecting that, which is why the final record said something like “Created by Rick, fueled by tea”.

Of course, I didn’t see a single penny for it, but whatever, sometimes improbable things are possible if one simply turns reality the other way up and then looks at the problem again.

If the document source files are in VIEW format, then they can still be read by PipeDream.

View format would be the ‘easy part’ of the problem.

I used bitmap fonts of the kind EFF (IIRC) produced and the first column of a View/PipeDream file as ‘control codes’ to switch fonts to include bitmap glyphs I made to deal with some of the more ‘unusual’ symbols I needed, and to be able to lay them out into equations of quite complicated types. I also used some of these font glyphs as ‘elements’ to assemble like bricks to make graphs and diagrams! I tried reconstructing this on my RPC some years ago – and gave up!

It would/will be quicker to scan the pages and find someone who can OCR stuff that has really ‘hard sums’ equations to get to being able to generate even a half-decent PDF.

The typesetters at the Institute of Physics then used the printout to typeset the book. It was clear enough for that, but not really easy on the eye as printed by myself.

Later on, of course, the magic of !TechWriter came along and I dumpted my bodged approach.

I’ll scan an example page from the book so people can see the challenge.