A guide to programming the Sinclair QL

[Derek_Stewart]

Hi Rich,

I agree - at the moment, there are some old books written in 1984, which are not really relevant for modern systems, plus:

- QDOS / SMS Reference Manual - https://kilgus.net/smsqe/QDOS%20SMS%20R ... Manual.pdf (aimed at machine code)

This version of the QDOS / SMSQ Reference Manual is out of date, the most up to date manual is v. 4.3 - 29/06/2017, available from Wolfgang Lenerz at:

http://www.wlenerz.com/QLStuff/SMSQE_Guide.zip

[XorA]

Hi,
I can see one problem porting C programs to QLs. C language allows you to construct code in a huge number of ways. For example just consider FOR loops : Converting C FOR loops to QL Basic FOR loops would probably need to be done by hand, as I doubt whether software could do it, there being just too many combinations.
So forget QL Basic for now. This leaves the possibility of converting PC C into a QL C. As Tim said, QL C contains many keywords specific to the QL. This is a botlekneck when converting QL C to PC C, and the opposite would be much harder to achieve. CPort was written over 30 years ago by a professional QL firm, so who would have the time to write a cross-compiler to convert from PC C to QL C today?
Perhaps it would be more feasable to do it for QPC2, as this emulates QLs already via software. But again, a major task, and one that perhaps only Marcel Kilgus would be capable of undertaking in any case. But that would be to ask a great deal from him!
The fact that nobody has attempted it before reveals the difficulty of the task...
Very few QL programs seem to have been written in QL C, probably because Qlers love to tinker with code, and C code is far less easy to comprehend than Basic, so tinkering would be problematical.
Perhaps the best solution would be for a C programmer to write his algorythm in pseudocode, which somebody could rewite in Basic for QLers. This would ammount to authorised reverse-engineering!
Regards,
Steve Poole.

Nice long rant, unfortunately almost 100% wrong and very misleading to people reading this thread.

1) There is a actively maintained 68k cross compiler, it just needs QL linker info added, there was some basic work on this done on the forum which can be obtained by search.
2) qdos-gcc and c68 cross compilers already exist.
3) I ported Wander engine and one of the collosal cave versions from "PC C" to "QL C" in a matter of minutes + a couple of hours debugging. Its really not that hard to port CLI stuff. GFX stuff its pretty easy to extract the GFX routines and convert them to access QL screen structure.
4) Seems to be a fair number of QL C programs on dilwyns site

Please don't go round trying to make out C on QL is some unassailable task when all the tools are already there for a competent programmer.

[NormanDunbar]

Norman, Norman, Norman,
You had to be so bold ....
Recompiling is a form of porting, just a trivial form. Just a semantics.

Maybe. Possibly. But I respectfully disagree!

Now, converting C to/from Basic as Steve mentioned is not trivial and I'm not sure if it is necessary.

On this, we agree. In fact, if I ever get more time, I am seriously looking at a new version of CPort. Well, thinking about it anyway! I have Jan Jones' book, and Kernighan & Ritchie, so how hard could it be? FLW!


Cheers,
Norm.

[stevepoole]

Hi Xora,
Thanks for the updated information. When I had asked for such QL C info some two years ago, nobody replied....

It will be great if software migration to and from PC to QL does become commonplace and common knowledge.

But most QLers write in basic, because C code is long-winded and not very readable, even if you do include plenty of remarks. You can cobble together a QL program, run and test it in a few hours. In C this is just not on : Just look at mainstream programming : People write code on platforms which run on platforms which run on platforms which run C, C++ or Java.

So when you look at other people's C++ code, most of it is composed of classes to which you have no access. Hardly tinkerable! I sometimes write C++ code, but much prefer first to code in Basic... then port it.

Best Wishes,
Steve.

[XorA]

because C code is long-winded and not very readable

Being a fulltime C coder I have to disagree, only having 20 keywords makes C nice and easy to understand. There are reasons C is the no1 language in the world

[stevepoole]

Hi again Xora,
If C is used so much, it is rather because it executes very fast, being a compiled language quite close to machine code...
C is popular on PCs, but so is C++ C# and java.
There are 63 C++ keywords, with 16 data types.That is a lot of combinations to master, so you have to be very careful with type conversion. In QL Basic, maths are done in float by default! So the QL is very easy to prototype on, being an 'interpreted' language with built-in type conversion. You concentrate more on the algorythm than on the syntax. (The QL was designed to allow trial-and-error coding, difficult using a compiler).
QDOS and SMSQ have a wide range of functions without often requiring extensions. In C++ you can't do a great deal without INCLUDing libraries, if you have them.
I learnt Basic in about a month, two hours a day. It took ma about 2 weeks to learn enough C++ to port a simple basic program, but when it comes to writing complicated prototypes, QPC basic is by far the fastest to produce with... especially for occasional programmers that QLs were built for : The QL as a 'busines machine' uses professional programs, rare commodities these days in terms of new software!
If C was so easy to use, QL basic would have been abandoned years ago... (I am not entirely against C, it has its uses...but I write PC C, not QL C). My QL just sits in a corner, where it gets truned on to ensure backward compatibility. If I want basic, I use QPC2.
And I only use QPC2 when I need something I don't have on my laptop.
Regards,
Steve.

[pjw]

because C code is long-winded and not very readable

Being a fulltime C coder I have to disagree, only having 20 keywords makes C nice and easy to understand. There are reasons C is the no1 language in the world

I always assumed that QDOS, MC68 and SuperBASIC were an attempt at escaping from the Unix and C orbit; a quantum leap into the modern age. Ok, it didnt quite reach escape velocity, but that may be due to its premature demise, caused by, among other things, Sinclair bungling and the rampant Wintel oligopoly. The main reason C is the no1 language in the world today is because it is, er, the no1 language in the world!

Just my humble opinion, based on distant memories of the reasoning behind decisions I made many years ago, and why I never delved into Unix or C (and therefore may perhaps not be entitled to an opinion on these matters).

[pjw]

Steve, there used to be a C interpreter for the Atari ST. I dont know how good it was/is, as I only used it sporadically.

ALL: BTW there is a very nice MC68 assembler interpreter too, called EASy68K at http://www.easy68k.com. Very nice. Useful for testing tricky non-QDOS-specific routines..

[janbredenbeek]

I've written several programs in C when I was already an experienced QL coder (it was not before the early 90s when C68 appeared which was the first decent C compiler for the QL). I even wrote a library in C to implement pop-up windows and menus as I didn't want to rely on the PE when distributing programs.
C is most suitable when writing complex applications, while S*BASIC is ideal for scripting and 'quick' solutions - much like shell scripts in *nix systems. Though I have to say that, with SB compilers and MultiBasics, the boundary between the two categories has become a bit blurry.

Jan.

[XorA]

but I write PC C, not QL C

Its the same language, I assume you mean you use a lot of Windows specific functions when your on a PC, as I've previously discussed porting *nix CLI stuff to QL is mostly easy.

GFX stuff is fairly easy as long as original program was decently written and separates the output from the logic.

And luckily for people like me who are C programmers by trade the QL gods wrote the QL specific libraries and they are nicely on dilwyns page and other C68 related pages.