The Sinclair QL Forum

Perhaps it is compacted. But from what I recall (~15yrs ago) it certainly did some odd things to its own code block before executing it.

>(not) obfuscated

I'll have a look again now I've finished PNG decoder (horrid format - makes JPEG and GIF look like model of good design, even though they preceded PNG )

Silvester wrote: I'll have a look again now I've finished PNG decoder (horrid format - makes JPEG and GIF look like model of good design, even though they preceded PNG )

We are discussing the disassembling of some SuperForth code words in the email list. So far I've seen nothing strange. In fact I'm considering extending some tools I've written, in order to disassemble the whole dictionary. It will be interesting if you share your discoveries in the list.

Beside, I'm interested in implementing some SMSQ/E and graphic features in SuperForth, as part of a library I'm writing for it.

Silvester wrote:Perhaps it (SuperForth) is compacted. But from what I recall (~15yrs ago) it certainly did some odd things to its own code block before executing it.

I'm not sure what you mean but I can't look at the original source code of SuperForth until I find some way of reading the master on a 5.25" floppy disk. Looking at a meta-compiler that was a descendent of SuperForth, and which I do have the source code for, all that is done at the start is to open a window, set various addresses so that the Forth inner interpreter can be used (about 20 instructions). Then it starts executing a cold start routine that is written in Forth. This patches a few adresses, initialises user variables, sets a few execution vectors then calls QUIT to start the text interpreter.

I don't think SuperForth does anything different but can't guarantee that until I rescue the source code. I don't remember Digital Precision ever having the source code so doubt that they added anything to obscure the code in any way. I see that for some reason I changed the registers usage in the meta compiler.

To clarify Marcos Cruz's earlier reply, all Forth addresses are 16 bit relative to register A2 (according to the manual).

Hi Gerry, Welcome to the forum!

Re SuperForth F83, my bad... I soon realised I looked at it a very long time ago (1995, acquired from DP collection). Unfortunately of all the programs in the DP set, it was the only one that didn't include the user manual! I got the gist of it from your FORTH79 (very kindly donated to Quanta library).

When I looked at it during a code trace it appeared to be writing to its own job code area. At the time (1994), having recently cracked a few MDV-only version programs to run from FLP (crafty protection), for my own use, I thought it was doing something similar. But since it worked from FLP_ etc. OK, I didn't pursue it further - just vaguely recall doing it.

Nevertheless I have, in the last few days, had another look and realise it is as you say. It is the system/USER variables, PAD and TIB that are held within job code which are overwritten. Ive done a complete disassembly back to assembly source (before I saw your message). As you say it sets up job registers in about 20 instructions and then simply launches with COLD - very neat.

I have a QL system with 3.5/5.25 (360K/720K) disks, if you need any QL/PC disks read.

-----
Edit: Additional comment, 2 Feb 2016

Within the 15712 bytes binary file which constitutes the job code area:

25% is actual 68000 source code (executable)
58% FORTH code words (nonsense as 68000)
17% internally overwritten (data and return stacks, etc)

Silvester wrote:Nevertheless I have, in the last few days, had another look and realise it is as you say. It is the system/USER variables, PAD and TIB that are held within job code which are overwritten. Ive done a complete disassembly back to assembly source (before I saw your message). As you say it sets up job registers in about 20 instructions and then simply launches with COLD - very neat.

Good thats sorted out then.

I have a QL system with 3.5/5.25 (360K/720K) disks, if you need any QL/PC disks read.

Thanks for the offer, I'll take you up on that if I have no luck with my QL hardware - it's been sitting in my loft since about 1990 and will be something of a miracle if it still works.

In the meantime I think I'll do what Marcos suggested and put the source code of the meta-compiler I mentioned on GitHub. Who knows if someone manages to assemble the machine code we might get it all going again. I'm fairly confident it compiled and generated itself and is close, if not identical to the original SuperForth.

>...it's been sitting in my loft since about 1990 and will be something of a miracle if it still works.

I have a few hundred 5.25" disks I only ever used for backing up QL hard drive, although they are 28 years old they still read OK. I don't think they would have lasted that long in my loft though (too hot in summer, too cold in winter).

>...source code of the meta-compiler I mentioned on GitHub.

Look forward to that. I only had a passing interest in Forth until a few years ago when I started to understand it from the ground up by looking at how others had implemented it from scratch. Very simple concept, yet potentially quite powerful and fast. A quick and productive way to get something up and working, but be able to build upon layer by layer. I can see why some used to call it the best kept secret in programming.

Silvester wrote: >...source code of the meta-compiler I mentioned on GitHub.

Look forward to that.

https://github.com/gerryjackson/QL-SuperForth

Silvester wrote: I only had a passing interest in Forth until a few years ago when I started to understand it from the ground up by looking at how others had implemented it from scratch. Very simple concept, yet potentially quite powerful and fast. A quick and productive way to get something up and working, but be able to build upon layer by layer. I can see why some used to call it the best kept secret in programming.

You are right. For me Forth is as you say. When you learn how it works there's no way back anymore, you're trapped . I was lucky enough to start tinkering with Forth on my Spectrum in the 1980s, and fascination and learning never end since then, no matter the implementation, the standard or the platform.

Silvester wrote:Hi Gerry, Welcome to the forum!

I have a QL system with 3.5/5.25 (360K/720K) disks, if you need any QL/PC disks read.

Hi Silvester

To get my QL working I had to buy a new keyboard membrane and it now seems fully functional. How times change, I remember that the Microvitec Cub monitor seemed excellent at the time but compared to modern monitors it is awful - it's a wonder that my eyesight survived a few years of using the QL.

The 5.25" floppy drive seems to work but most of the floppy disks I have couldn't even give a directory listing and that unfortunately included the two Forth 83 master disks that, I think were the SuperForth master disks. Even fewer floppies had readable files on them. So the only hope now is that my 5.25" drive is substandard and that someone else will have better luck.

So are you willing to try them. If so I can post them to you or are you within a reasonable travelling distance from South Wales to avoid having to trust the Post Office?

Silvester wrote: -----
Edit: Additional comment, 2 Feb 2016

Within the 15712 bytes binary file which constitutes the job code area:

25% is actual 68000 source code (executable)
58% FORTH code words (nonsense as 68000)
17% internally overwritten (data and return stacks, etc)

I've just seen this and those numbers would seem about right. I presume you obtained those numbers via a disassembler. If so could you send the disassembly of the machine code to me or make it available somewhere so I can compare it with the assembler source on GitHub. Apart from different register usage they ought to be very similar if not identical.

gerryjackson wrote: I've just seen this and those numbers would seem about right. I presume you obtained those numbers via a disassembler. If so could you send the disassembly of the machine code to me or make it available somewhere so I can compare it with the assembler source on GitHub. Apart from different register usage they ought to be very similar if not identical.

I've already sent you the disassembly done by Silvester. It's being very useful during the development of my Sfera library for SuperForth.