Apollinus PDT

I have a customer looking to buy a modern RISC OS machine, but he’s running a CAD program called Apollonius PDT (Parametric Design Tool), I think from Oak Solutions in the 90s.

Although it can be made to load/run via Aemulor, it is prone to error messages when you do anything with it – Abort at &FFAF33B0 (system workspace) – repeatable on both Titanium and i.MX6. This happens quite frequently (every few seconds) and whilst not fatal, makes the program effectively unusable.

I’ve tried various screen mode combinations in case that was the problem, as well as various Aemulor settings. ROMs back to early last year.

Doesn’t help that although the main program is in BASIC, any attempt to load and save it (Zap, StrongEd, etc) either reports an error (StrongEd – too many line numbers) or just causes the program to stiff on the next run. This is version 1.21 15 Oct 1996.

Just wondering if anyone has any first hand experience of the software, and/or knows any tricks to it. I’d really like to tell him something other than “You’ll need VRPC for that one”, but I’m rapidly running out of ideas…

Hi Andrew. As the program is in BASIC I could take a look. Please would you send it to me? I might look at the raw binary tokens. Someone else may be more familiar with it, but if I can help I will.

“You’ll need VRPC for that one”

“You’ll need ArchiEmu?” :)
We really all need a new Aemulor.

More seriously, it’ll work, and it’s perhaps a good interim solution before going to a better solution than Apollonius PDT. For example ProCAD+
http://rougol.jellybaby.net/meetings/2000/aug/

the main program is in BASIC

But presumably – because Aemulor is required – some is not BASIC?
Is it obvious what amounts & percentages are BASIC and not BASIC, or is it assembler contained within the BASIC program?

But presumably – because Aemulor is required – some is not BASIC?
Is it obvious what amounts & percentages are BASIC and not BASIC, or is it assembler contained within the BASIC program?

Sounds likely, but since examination of the BASIC file causes problems when the file is saved I would suggest that some element of compression of the BASIC has been done.

IIRC StrongED etc have issues with some of those compression techniques and chuck up the too many line numbers etc

So the question is: What is revealed if the program is loaded (on a machine that doesn’t cause problems) and then the utility ¹ BasicRip* (that’s the wayback link as the original seems to have gone the way of many things) is used to pull the decompressed BASIC from memory? Does that produce a modifiable BASIC file?

As Martin points out there is probably assembler in there and it may be 26 bit or alignment problems

¹ Had a copy for years but I wanted to be sure you could all collect one of your own so I went on a quick wayback journey (original URL from the RISC OS Filebase)

I started to 32bit this a while back – but was side tracked :-|
Should be no problem though :-)

Firstly, thanks for the feedback everyone :)

It has three non-BASIC modules, of which only two are significant – “Apollonious” and “TaskX”, the latter being an ACE Computing module. I thought it was already 32bit but could only find EuclidX. Someone may have already done TaskX, so that’d be helpful to know.

The fact it works under Aemulor, but throws up these spurious errors is what concerns me – makes me think some change in OS5 is tripping it up. The customer currently runs an Iyonix, so I’m guessing some combination of OS5+Aemulor has worked historically. Perhaps alignment issues, as Steve suggests.

Colin, if you can help, both myself and the customer would be very appreciative :)

Also thanks David for the suggestions. Yes, I did my bit to assist David Snell get things ARMv7/32bit in the past, so I know the merits of ProCAD. Of course, that doesn’t mean a customer is willing to change! Gotta work with what we have, then make gentle suggestions :) Needless to say, he’s also a Eureka man, so Aemulor will definately be needed.

Gotta work with what we have, then make gentle suggestions :)

I agree yes.

so Aemulor will definately be needed

Yes, we must find a way to get Adrian coming back on Aemulor development.
I could fund a part of this project as it’s very important for me too.

Yes, we must find a way to get Adrian coming back on Aemulor development.
I could fund a part of this project as it’s very important for me too.

Don’t you think the development that will come from the ARM on ARM discussions between Jeffrery and Jon is a better path?
The aim is something that will work on all¹ existing 32-bit operational machines and be easily modified to work on future revisions.

If there’s money available perhaps funding a development machine for ARM on ARM, if required, is the thing to do.

Don’t you think the development that will come from the ARM on ARM discussions between Jeffrery and Jon is a better path?

Aemulor is here for much longer. So I would prefer to fund and have both :)

Do someone have a valid e-mail address for Adrian Lees?