SBASIC & C++

[Derek_Stewart]

Hi,

Please do not use: DNDsystems1@supanet.com

This is a disused email address, which was used by my partner in the Q60 production, 10 years ago.

My email address is: derek@q40.de

I will look at your PM and get back to you.

[stevepoole]

It's a pity that with so many good programs available for us, that they do not come ready for use on QPC. Most people these days have PCs, especially laptops, and if we are to attract new blood to the QL community, these are the people to target.
The only remaining advantage we have is the develoment environment : SMSQ/E, TURBO, Cport, the menu systems and the like, which should allow us to develope such software as Apps in SBasic, and then transcode them into C for use on PCs. But all those great systems come configured for mdvs, flps, and wins, whereas these days most PC owners store data not on CDs but on USB keys, ie: DOS devices, which can be swapped from one PC to another in a trice to run software.
How I would like to have the entire QL sytems on USB, reday to go, a bit like the QL on a stick. Just think of it, Write your programs in SMSQ/E, Turbo them, Cport them, (even GWASS them), without having to set up complicated boot files, which lie hidden deep in zipped files anyway.
Non QLers would find it a bit difficult to get to grips with the systems as they are. We should make the QL interfaces as simple to use as possible, leaving people with the sole task of writing apps they need. It's amazing what you can do even with bog-standard superbasic.
Steve.

[EmmBee]

Hi Steve,
Just a thought - when testing the Travelling Salesman Program, rather than spending lots of time computing the distance between two cities, you could instead use a lookup array. This array would only be needed to be computed once at the start of the program. Of course, this would only work for up to about 4000 cities, which would consume 4000*4000*6 bytes - or 96 Megabytes. QPC2 is limited to a maximum of only 128 Megabytes.
Michael

[swensont]

Ok, I had to reply:

> It's a pity that with so many good programs available for us,
> that they do not come ready for use on QPC.

Most QL software was written before QPC existed, so it is not optimised for it.
Not all of us use QPC. I moved to Linux a while back and prefer native applicaitons. I have install Qemulator using WINE, but for all my uses, I use SMSQmulator.

> software as Apps in SBasic

Software is an app. App is short for application. Apple seems to have started the mis-use of the term App to mean software and everyone under the age of 30 seems think that App is the only word for software.

> on USB keys, ie: DOS devices

Actually most USB drives are NTFS formatted, which DOS does not understand. But it is possible to format USB drives in any format. I have one formatted to EFS3.

[stevepoole]

Hi emmbee,
One version of the Travelling Salasman Program uses a 407x400 element array to calculate 100 cities. It rins 6 times faster than one without. It will Turbo compile, but halts if you execute it indicating that the DIM array statement is invalid. The solution will to be to PEEK and POKE into an ALLOCATED stack. But I won't have time to do this until mid-january.
What is more, I need to add extra array elements to sort distances, so as to avoid repeated calculations...
By then I hope to have mastered the libCport and C68 software.
Regards,
Steve.

[stevepoole]

Hi Tim,
I used the expression 'App', as I hope to write an application on QPC2 for my Nokia windows smartphone. This should be OK in 'C', if not it will have to be recoded in Java.
I use two PC's and a SGC_QL. Both PCs run QPC2 and both run OK using all Dos_ devices including various USBkeys and SDcards.
Strangely, the new PC with the downloaded free QPC2 does not recognise win1_ , but is ok with Dos_ devices, so I get by. I need to by an external dual floppy USB device to be compatible with a lot of QL boot programs... But I would have to use say DOS_USE flp?
Best wishes,
Steve.

[vanpeebles]

It's a pity that with so many good programs available for us, that they do not come ready for use on QPC. Most people these days have PCs, especially laptops, and if we are to attract new blood to the QL community, these are the people to target.

I must disagree there Most new QL users are black box QL people. It's impossible to get a feel for the QL and the hardware by using an emulator as first time user.

[EmmBee]

Hi emmbee,
One version of the Travelling Salasman Program uses a 407x400 element array to calculate 100 cities. It rins 6 times faster than one without. It will Turbo compile, but halts if you execute it indicating that the DIM array statement is invalid. The solution will to be to PEEK and POKE into an ALLOCATED stack. But I won't have time to do this until mid-january.
What is more, I need to add extra array elements to sort distances, so as to avoid repeated calculations...
By then I hope to have mastered the libCport and C68 software.
Regards,
Steve.

Hi Steve,

I forgot, but turbo arrays are limited to a maximum of 65535 elements. Would you like to send me your program, please? I would like to see it.

Once transcoded into C, you will no doubt want to convert the C code to use pointer arithmetic for even more efficiency. Pointers are addresses, and there is no calculating where an array element is, you just go straight there and get the value. Do you already know C? In case you need to learn this language, the book I can recommend is the one by Kernighan and Ritchie, who are the authors of the C language, and this book is known as the C programmer's bible. However, there are many books available.

To Derek Stewart,

I downloaded libcport and c68 as you suggested.
Using dos_use flp
LRUn dos5_libcport.example1 works fine.
LRESPR dos5_libcport_runtime.exts gives not found, yet the file is shown with dir_dos5_libcport !

Mystery...

Steve.

QPC2's DOS_DEVICE does not recognise file headers. This would explain why the SuperBASIC program runs correctly, but EXEC file will not work, as it would not recognise the file as being executable. This would mean that DOS_USE flp cannot be used. All of this seems to be quite complicated, because I have done the same as you and have downloaded the files from Dilwyns website, and the file does EXEC properly, I just cannot figure out what I have done. Perhaps someone would like to explain what Steve has to do here. If, somehow, you can get your files onto a QXL WIN file, then you could use WIN_USE flp with no trouble. About your new PC not recognising win1_, surely, isn't this just a case of configuring the Devices section on QPC2's front panel?

Michael

[stevepoole]

Hi EmmBee,
After reading other posts, I think my problems with the libCport and C68 downloads probably came from my not unzipping properly. I will try unzipping everything agin using QL UNZIP only, not PC unzip.
As for the travelling Salesman Program, it is badly written and needs optimisation. I have no time to do this before mid-january, and would like to know what acceleration a typical C program gets compared to its SBasic equivalent.
If I had libCport runnning, I would write a Sbasic program using all the maths funtions nested in two loops, run it and time it over a few minutes. Then transcode it into compiled C and compare timings.
If the speedup is notable, I will find the time to optimise the TSP before considering converting it to C, for the final test.
The TSP is an important problem in computing as it the core of the Hamiltonian challenge, echoed by the Clay Mathemeatical Institute within their Millenium problems list.
If compiled C is no faster than interpreted SBasic, there seems little point in spending futher time on the TSP.
After a two year break away from QL coding, it is great to see that the community is still alive and kicking on the forum.
Steve.

[EmmBee]

Ok, I had to reply:

> It's a pity that with so many good programs available for us,
> that they do not come ready for use on QPC.

Most QL software was written before QPC existed, so it is not optimised for it.

I just cannot agree with the above. I would rather say that QPC is indeed fully optimised for all the software that has been written for the QL so far. It's all a question of using and knowing what QPC is capable of. Let us take, for example, software on floppy disks. The QPCManual.pdf on page 21 fully describes how floppy disks can be used. QPC even provides floppy disk images, which are files on the hard disk that act just like the floppy disks themselves. When using these images, there is no noise of the floppy drive whirring, and no time delay, it is just like using a win file. This is actually better than the real thing.

Hi EmmBee,
After reading other posts, I think my problems with the libCport and C68 downloads probably came from my not unzipping properly. I will try unzipping everything agin using QL UNZIP only, not PC unzip.

Hi Steve
Yes, you have to use QL UNZIP, but I feel the real problem is you have not set up QPC properly. You need to read the QPCManual.pdf on pages 23 onwards. Page 23 describes WIN disks, which are the main medium that has to be used, and will explain how to format them. Page 25 describes the DOS_DEVICE and explains why you cannot store executable files on them. After reading this part of the manual you will understand why DOS_USE flp will not work as expected.

As for the travelling Salesman Program, it is badly written and needs optimisation. I have no time to do this before mid-january, and would like to know what acceleration a typical C program gets compared to its SBasic equivalent.

Well now, tofro says "you can still calculate with ~50% - 200% improvement , even on compiled S*BASIC", but RWAP reckons if you use Turbo, the code will probably be quicker than C code.

Myself, I would guess that C code would definitely be quicker, and especially so if you are willing to spend some additional time and convert the transcoded C program to use pointer arithmetic. So, what will the eventual acceleration be? We will just have to wait and see.

The Travelling Salesman Program is particularly interesting because of the difficulty involved in producing an optimum result. It's not like searching a map. When searching a map, the target town is known, and heuristics can be used to guide the search. The TSP has no target town and no such heuristics can be used. It is all down to algorithms and computing power alone. The more towns involved mean a corresponding increase in the operation time. This is why it is so important for the code to run as fast as possible.

I am thinking of perhaps writing my own simple version of the TSP. It would be interesting to compare its results with that of the Lin-Kernighan Traveling Salesman Heuristic.

Michael