The Sinclair QL Forum

Posted: **Mon Nov 16, 2020 7:29 pm**

Hi,

Andrew wrote : <<Is there any difference in code speed between compile Superbasic, compiled Pascal and complile C68?>>

It all depends what platform and what sort of program you are using. Turbo-compiling S*Basic gives no advantage on QPC2 or SGC over the interpreted code, as smsq/e is very fast already.

My SMSQ/E programs and transcoded Pascal versions run at roughly the same speed too. But many programs contain Pauses to make them slow enough to be useable, so speed is hardly a problem in these cases.

I have not timed Turbo'ed programs transcoded to C68, but they should of course be far faster !

But writing program prototypes without an interpreter is very time-consuming indeed... to debug.

Hope this helps.

Steve.

Posted: **Mon Nov 16, 2020 7:36 pm**

What is a Job on a QL? Full, gory, details can be found at http://qdosmsq.dunbar-it.co.uk/doku.php ... :jobs:jobs - but feel free to ask if there's anything you don't understand or need more information on. Basically, a job is a chunk of code, structured in a specific way, which executes as an individual process/task in a QL. It should be position independent as there's no way it will know the execution address when activated.

Re cross compiling, cross compilers (well, the one I know of!) write a pair of long words (4 bytes each) to the end of the generated code in a format known as XTcc:

Code: Select all

dc.l 'XTcc'
dc.l required_dataspace

Other QL utilities such as unzip will be able to read these two long words and configure the appropriate file header in the QL version to have the correct data space requirements. These are job files, and when EXECuted on a QL will create a job.

QL Floats are just weird. The C68 stuff you have "ripped off"

is public domain. You can find the current status of just about any QL software by looking on the QL Wiki at qlwiki.theqlforum.com. For C68, the page you want is https://qlwiki.theqlforum.com/doku.php?id=qlwiki:c68 and scroll down to the bottom.

If you are still unhappy, then this is all my own work (so, not great then!) and you are welcome to take it, use it, abuse it as you see fit. The code is from something I'm working on to convert a QSAVEd file (which is just the internal tokenised format of a Basic program) into C source code. Normally, the QL float is 6 bytes, but when tokenised, there's a value in the top nibble to determine if the float (in the file) is binary, hexadecimal or just plain old decimal. It works, but how efficient it is, I have no idea!

First, from the header file, the structure to represent a QL Float:

Code: Select all

#pragma pack(push, 1)
typedef struct QLFLOAT {
    short exponent;
    long mantissa;
} QLFLOAT_t;
#pragma pack(pop)

The conversion function is below.

Code: Select all

/*=============================================================================
 * QLFPTODOUBLE() Converts a QL 6 byte floating point value to a double in IEEE
 * format. This is a C conversion of the assembly routine qlfp_to_d() from the
 * C68 source code. There are three styles of float:
 *
 * 0xDx xx xx xx xx xx = Binary %101010101 etc.
 * 0xEx xx xx xx xx xx = Hexadecimal $abcdef etc.
 * 0xFx xx xx xx xx xx = Decimal 12345 etc.
 *
 * The top nibble, D, E or F, must be masked out before converting but will
 * return the correct type in the fpType parameter.
 *
 * According to https://en.wikipedia.org/wiki/Double-precision_floating-point_format
 * an IEEE double is:
 *
 * 1 sign bit
 * 11 exponent bits offset by 1023
 * 1 implied plus 52 fractional bits.
 *
 * The number is usually:
 * 
 * -1^^Sign * 2^^(exp-2013) * 1.Fractional Bits
 *
 * Where the 1 is the implied bit.
 *===========================================================================*/
double qlfpToDouble(QLFLOAT_t *qlfp, uchar *fpType) {
    ulong sign;
    long exponent = qlfp->exponent & 0x0fff;
    long mantissa = qlfp->mantissa;
    long temp;
    struct ieeeFloat {
        long ieeeExponent;
        long ieeeMantissa;
    } result;

    /* Extract the type. */
    *fpType = (((qlfp->exponent >> 8) & 0xF0) >> 4) - 0x0D;

    /* Lose the type marker. */
    exponent &= 0xFFFF0FFFL;

    /* Simple case first, is it zero? */
    if (exponent == 0 && mantissa == 0) {
        return (double)0;
    }

    /* Positive or negative? */
    sign = (mantissa & 0x80000000L);
    if (sign) {
        /* Negative. */
        exponent *= -1;
        if (mantissa & 0x40000000L) {
            exponent++;
        }

        /* Then drop in below. */
    }

    /* Positive. */
    exponent -= 0x402;
    exponent <<= 4;
    exponent <<= 16;
    exponent |= sign;

    mantissa <<= 2;
    temp = (short)mantissa;
    temp <<= 4;
    temp <<= 16;

    mantissa >>= 12;
    mantissa |= exponent;

    /* Exponent bits = 1 sign, 11 exponent, (1 implied), 20 fractionals
     * Mantissa bits = 32 bits of fractional */
    result.ieeeExponent = (long unsigned)temp;
    result.ieeeMantissa = (long unsigned)mantissa;
    return *((double *)(&result));
 }

HTH

Cheers,
Norm.

Posted: **Mon Nov 16, 2020 9:58 pm**

Chain-Q wrote:This is my first post in this forum. Glad to be here. So I'm Karoly Balogh (a.k.a Charlie on the demoscene, a.k.a. Chain-Q on IRC and various other forums), the maintainer of the Free Pascal m68k port, and I also wrote a big chunk of the new/resurrected m68k backend a few years back.

A warm welcome, great to hear about your 68K activities!

Chain-Q wrote:I'm not a native English speaker (I'm Hungarian, but I live in Germany), so sorry if I make mistakes.

My English ist not better! By the way, living in Germany provides the chance to meet, once the pandemic is under control.

Chain-Q wrote:* I do have a huge pile of Amiga and Atari hardware, some 68k Macs too. I also have some experience with Linux/68k and NetBSD/68k, but I'm completely new to the QL or QL clones.

That's interesting because there is a Linux/68k port for my Q40 and Q60 machines from a guy named Richard also in Germany. Recently I had a short but fascinated look at NetBSD/68k, because it supports a plain 68000 target with a primitive MMU. And not only that, but it even has a complete distro - which would save much work compared to Linux if I want it on the Q68. (Easier to add a primitive MMU than dealing with ucLinux.)

Chain-Q wrote:Hardware donations are welcomed, but not in any way expected.

If you like the Q68, and it has a good chance to be actually used, not just collected, I will see what I can do...

Chain-Q wrote:* The port currently uses a simple BASIC loader, to allow direct cross-compiling. I read somewhere you need some QL native tool to to make your binary executable on the QL after cross compiling it, so I just decided to work that around for now...

C cross compilers just append the characters 'XTcc' after the binary, followed by 4 binary bytes with the data space. The usual tools can move that onto a native filesystem. And by chance, native TFTP support via Ethernet is also nearing for the Q68, automaticlly converting 'XTcc' style executable as you upload them.

Chain-Q wrote:* The compiler can run on real 68k too, but it needs a ton of memory (32MB as a minimum, 128MB recommended for larger projects), and it's quite slow even of a '060/100Mhz... It works quite OK though on fast emulators like UAE though. So if there's something like that for the QL, we can talk about hosting the compiler on QDOS compatibles as well, but it's still a long journey to that point.

The Q68 has 32 MB RAM, but it's only about 68030 / lowend 68040 speed. The Q60 has a 68060 with up to 80 MHz and 128 MB RAM, but suffers from not supporting modern flatscreen monitors. So there probably is no suitable QL platform for compiling. But the same goes for QDOS-GCC. Not very important as long as the resulting executable runs fast.

As a free emulator my recommendation would be SMSQmulator. Unlike QPC and Qemulator, it is open source. The author works under Linux and ported the modernized QL OS named SMSQ/E to the Q68 hardware.

Posted: **Mon Nov 16, 2020 10:07 pm**

Hi Chain-Q,

Glad meet another developer, if you are usd to Amiga OS, QPC2 is the best emulator to use, it can allocate any of the host PC memory, the operating system is SMSQ/E and probably the best QL based operating system.

The source code to C68, which the QL C compiler, has all the source code available on the QL Hompage.

I am interested in Pascal, so would like to see FreePascal available. I did think FreePacal could be ported to the QL, but I never did more than read up about FreePascal.

I also like all M68K computers, I have lots of Atari and Amiga hardware, but I prefer the QL operating system for development.

Let me know if there is anything I can do.

Posted: **Tue Nov 17, 2020 7:57 am**

Chain-Q wrote:This is my first post in this forum. Glad to be here. So I'm Karoly Balogh (a.k.a Charlie on the demoscene, a.k.a. Chain-Q on IRC and various other forums), the maintainer of the Free Pascal m68k port, and I also wrote a big chunk of the new/resurrected m68k backend a few years back. As some of you already discovered it, inspired by #QLvember I decided to hack together a quick-and-dirty QL target for Free Pascal this month. If there's interest though, there's nothing stopping extending it further. (But for that I need contributors too.) I'm not a native English speaker (I'm Hungarian, but I live in Germany), so sorry if I make mistakes.

Welcome, good to see a fellow professional here (I'm in Germany, too

) I actually have ported my QPCPrint ESC/P2 printer emulator from Delphi to Lazarus last year, so while I don't use the 68k backend I'm highly impressed with the whole project and downright thrilled that there is a QL cross compiler.

* I do not have QL hardware, so the only thing I can work with so far is the unregistered version of Q-emuLator on my MacBook (I found 40 the USD registration price a bit steep for now, until I wasn't sure I could get something working), which means I also do not really have access to expanded QL things, which probably influenced a lot of my assumptions while making the port. Hardware donations are welcomed, but not in any way expected.

Do check out QPC, it's the emulator I've been developing for the last 25 years. It's free now (formerly 125€) and uses the much advanced OS SMSQ/E (still QDOS compatible). The emulation core was written in pure assembler at a time when 486s were all the rage, but I think it's still among the fastest for the QL. Oh, and it is 68020 compatible.

* The port currently uses a simple BASIC loader, to allow direct cross-compiling. I read somewhere you need some QL native tool to to make your binary executable on the QL after cross compiling it, so I just decided to work that around for now...

Like with files on the Mac there is a header that can get lost on PC drives. But I see Norman has covered that pretty well. If there are more questions, I'm also one of the main developers of the SMSQ/E operating system and happy to help out.

* The code FPC generates is not position independent, but the QL startup code (by me) can relocate the binary after loading.

That is the same with the main C compiler we have, C68.

* I do not get the entire job concept of QL yet, and what are the implications of it for my code. But we'll get there eventually. Probably this is because I don't really have any user experience with the QL, so some things are just hard to relate to.

In other OS a job is called "process". Minus the memory protection

* The compiler can run on real 68k too, but it needs a ton of memory (32MB as a minimum, 128MB recommended for larger projects), and it's quite slow even of a '060/100Mhz... It works quite OK though on fast emulators like UAE though. So if there's something like that for the QL, we can talk about hosting the compiler on QDOS compatibles as well, but it's still a long journey to that point.

QPC is some 1000 times faster than a QL and supports up to 256MB of RAM. Also it has limitles screen resolution, so unlike emulators like QemuLator that targets retro uses like games and hardware compatibility it's actually designed to be used as a desktop environment.

I think this is best summed up by this tweet (and video):
https://twitter.com/chainq/status/1328194649052368897

5:20 in the morning? Up early or up late?

I long for the times where I could still work all night on interesting stuff.

And I have a related question too: to support QLfloats, I ripped the double_to_qlfloat function from the C68/QDOS-GCC libc implementation for now, but sadly no source archives available online states what's the license for this code. Therefore I haven't committed it to FPC SVN yet, because I'm not sure I can redistribute this or even include in the RTL. This is why the source is not possible to compile currently. The FPC RTL comes under the LGPL license, with a static linking exception to allow static linking. If it's not possible to use these functions from the libc under this license, they will have to be rewritten too.

If that is the dtoqlfp routine from the C68 source then this was Dave Walker's code and I'm 1000% sure he would be okay with it. Also, last year he gave me all his remaining sources and stuff and given me explicit permission to do with it as I wish. You certainly have my blessing.

Cheers, Marcel

Posted: **Tue Nov 17, 2020 8:23 am**

mk79 wrote:I actually have ported my QPCPrint ESC/P2 printer emulator from Delphi to Lazarus last year, so while I don't use the 68k backend I'm highly impressed with the whole project and downright thrilled that there is a QL cross compiler.

Slightly off topic, but why did that require porting? I was under impression Lazarus was quite compatible to Delphi.

Posted: **Tue Nov 17, 2020 8:48 am**

Peter wrote:
mk79 wrote:I actually have ported my QPCPrint ESC/P2 printer emulator from Delphi to Lazarus last year, so while I don't use the 68k backend I'm highly impressed with the whole project and downright thrilled that there is a QL cross compiler.
Slightly off topic, but why did that require porting? I was under impression Lazarus was quite compatible to Delphi.

There are subtle differences, even more so when coming from a very old Delphi version I guess. The Windows API has slight changes, one API that gave me grieve was simply broken when called from 64-bit (I submitted a patch and it's fine now). In another place I had to rewrite some 3rd party UI code because it became soooo slow (like adding 10 seconds to the startup time slow). But all things said, it is fairly compatible and downright amazing for a free package.

Posted: **Tue Nov 17, 2020 8:53 am**

Tha fancy thing with FreePascal over all the existing QL Pascal compilers is its support for object-oriented variations of the language - so, the first really OO compiler available for the QL - I'm well tempted to give it a spin soon once there is a little spare time.

Posted: **Tue Nov 17, 2020 9:12 am**

tofro wrote:Tha fancy thing with FreePascal over all the existing QL Pascal compilers is its support for object-oriented variations of the language

Good old Object Orientation, Tony Tebby will be rather cross I imagine! I remember reading in QL Toady, just how much he hated OO. (I think it was QL Toady!)

Cheers,
Norm.

Posted: **Tue Nov 17, 2020 10:55 am**

NormanDunbar wrote:
tofro wrote:Tha fancy thing with FreePascal over all the existing QL Pascal compilers is its support for object-oriented variations of the language
Good old Object Orientation, Tony Tebby will be rather cross I imagine! I remember reading in QL Toady, just how much he hated OO. (I think it was QL Toady!)

Yes, he did. I remember that article, when reading it, I pretty much got the impression he might not have understood the concept (or, rather, didn't want to - his counter-arguments were rather ridiculous). That's fine with me, not everything is for everyone...

The Sinclair QL Forum

QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL

Re: QL / PASCAL