Turbo compiled Apps in ROM...

[martyn_hill]

Ah, yes, Ralf - I have that RPM toolkit and will try that as well as manual inspection...

[RalfR]

Attention, do not confuse Liberation's "RPM" with Jochen's "Thing and EPROM Manager"!

[tofro]

I'll dig a bit deeper to see exactly what Turbo'd apps do that currently renders them non-rentrant today... Might be a dead-end, but worth a look...

Well you could always load a Turbo-compiled job twice (once with FET and once with LBYTES) and compare. Then activate the job loaded with FET and let it finish - then compare again to the LBYTESed area. This should give you the differences.

I do understand that a TURBOed job that has ">64k" set in its compile options would need to be relocated - It's clear it has to fiddle with its code area in this case. But I basically see no need to modify its own code areas when it's compiled with the "<64k" option which should in principle result in a PC-relative program.

[martyn_hill]

Attention, do not confuse Liberation's "RPM" with Jochen's "Thing and EPROM Manager"!

Good call, Ralf - it is the "Thing and EPROM Manger" I was also meaning to refer to...

[Martin_Head]

I've been having a quick look at my Turbo decompiler notes. And it looks like the compiled program writes to its own program area. Which means that it looks like it can't be placed in a ROM.

It stores some WHEN_ERROR addresses near the start of the job, and it also looks like something to with channels (maybe channel definition blocks) are also in the program area. Also the pointers for DATA lines. See the attached notes.

Also if you look at a disassembly of a Turbo'ed program, there are some big gaps, which suggest that something will get written there.

[martyn_hill]

Thank you Martin!

So, WHEN ERROR, DATA and Channel-blocks (so far). These may be too tedious to unravel...

[Martin_Head]

I don't know if looking at the Turbo sources would help to identify what may get stored in the program area during run time.

I've never really got around to looking at how Turbo itself works, as I have only really been interested in the de-compiling side.

[pjw]

I dont know if its any help, but there are a few technical documents on SuperCharge and Turbo in existence. In an email to me by Simon Goodwin (SNG) writes:

There was a project report describing the thing that came
before Supercharge (which generated macros for Metacomco's
assembler). I attach the raw text, hope it helps. This was
included in the Turbo documentation Tim Swenson edited
from my large collection of development files. I also
attach one about the intermediate code and an example of
the output - including the macro form used by the original
compiler - from an article I wrote in QL World about ten
years ago, and which gave a good overview of the
architecture and main datastructures.

I still have these documents if you are interested. Im sure SNG wouldnt mind if I passed them on to someone for a good cause, though I wouldnt make them generally available without his permission. Tim might have more, and a better idea of what might be useful for this endeavour..

[tofro]

I still have these documents if you are interested. Im sure SNG wouldnt mind if I passed them on to someone for a good cause, though I wouldnt make them generally available without his permission. Tim might have more, and a better idea of what might be useful for this endeavour..

I guess the file you are referring to is contained in the Turbo Manuals package from the late George Gwilt in https://github.com/SinclairQL/GeorgeGwi ... rbom16.zip , called "TurboRep.txt"

[pjw]

<>
I guess the file you are referring to is contained in the Turbo Manuals package from the late George Gwilt in https://github.com/SinclairQL/GeorgeGwi ... rbom16.zip , called "TurboRep.txt"

Thats the one. It looks like trbom16 contains the complete collection. Its pretty esoteric stuff, but could be useful for research purposes. Ideally, they shouldnt be hidden away in obscure repositories..