The Sinclair QL Forum

Posted: **Sat Jun 04, 2022 12:32 pm**

I want to program on the QL, using C, and perhaps do/port some of my programs/games.

I was able to compile XTC68 in my linux, I compiled the tipical "Hello World", and execute it in the sqlux emulator, even I was able to compile a complex program (xtc68 has a big problem with long paths...)

But now I want to access the hardware and/or the rom traps.

I think I was able to put the screen in 8 color mode with this:

Code: Select all

#include <qdos.h>
void main(void){
	short dm = 8;
	short dt = -1;
	mt_dmode (&dm,&dt); 
}

not sure if it's ok, but works.

But when I try to read the keyboard, I was totally lost, and I can't found information on internet about how to do it?

There area any simple source code? or any tutorial that can I use to learn?

Posted: **Sat Jun 04, 2022 2:51 pm**

aalea wrote:
Code: Select all
#include <qdos.h>
void main(void){
	short dm = 8;
	short dt = -1;
	mt_dmode (&dm,&dt); 
}
not sure if it's ok, but works.

Looks OK to me.

aalea wrote: But when I try to read the keyboard, I was totally lost, and I can't found information on internet about how to do it?

Using QDOS, you can actually read the keyboard in several ways:

Read a row of the keyboard directly(raw), like KEYROW in S*BASIC
Read a byte from the keyboard queue (like INKEY$)
Even more sophisticated methods using the C stdio library

I guess you know how to do (3) when you know C.

(2) works like so:

Code: Select all

int channelID;
char key;
int error;

channelID = fgetchid (stdout);  // get the QDOS channel ID for stdout
error = io_fbyte (channelID, -1, &key); // Fetches last keypress into key

If you don't want to wait for a key, change the "-1" in the io_fbyte call (the "timeout") to 0 or the number of ticks you want to wait for a key press. When error==ERR_NC, no key was available.

And (1) is even a bit more tricky, because you need to talk to the co-processor like so:

Code: Select all

long  IPCcmd [2] = { 0x09010000L, 0x00000102L };  // The "1" in the second long is the keyrow #

int keyRow = mt_ipcom ((char *)IPCcmd);  // returns the same as S*BASIC KEYROW

The above example is set to read KEYROW (1) (replace the "1" in the second long with the row # you want to read, it's set to - Cursor keys, ENTER, ESC - in the example) and returns a bit mask of pressed keys in the respective row. Consult the SuperBASIC manual to see how the keys are encoded. If you want to understand the "magic" behind IPCcmd, consult the QDOS Technical Guide on MT.IPCOM.

aalea wrote: There area any simple source code? or any tutorial that can I use to learn?

Not that I would know of a suitable one that handles QDOS from C. Best is to read the QDOS Technical guide (which will explain everything in a very concise manner, and in Assembly). Second best is to ask here, when you get stuck

(All documentation can be found on dilwyn.me.uk)

Posted: **Sun Jun 05, 2022 11:16 am**

As I'm trying to do a game, we focus in the way #1

tofro wrote: And (1) is even a bit more tricky, because you need to talk to the co-processor like so:
Code: Select all
long  IPCcmd [2] = { 0x09010000L, 0x00000102L };  // The "1" in the second long is the keyrow #

int keyRow = mt_ipcom ((char *)IPCcmd);  // returns the same as S*BASIC KEYROW
The above example is set to read KEYROW (1) (replace the "1" in the second long with the row # you want to read, it's set to - Cursor keys, ENTER, ESC - in the example) and returns a bit mask of pressed keys in the respective row. Consult the SuperBASIC manual to see how the keys are encoded. If you want to understand the "magic" behind IPCcmd, consult the QDOS Technical Guide on MT.IPCOM.

Yes, that's works well.

I'm a bit confusing about how the QDOS Tecnical Guide show the parameters.

In the mt_mode D1.B and D2.B are the parameters of the C function, and the return is on it, so for the mt_ipcom I was try to get the reply in the first byte of IPCcmd (that I interpret as D1.B , and alwais get 0x09

) do not realize that IPCcmd are really A3, and the function return a integer.

OK, now, next problem: Multitasking

I do a simple loop forever that show the return return of mt_ipcom in a windows.
But at the same time I can see superbasic cursor on the background, I can even type basic programs while the program (the job) is running.

I was thinking that sd_curs/sd_cure will do the job, but not, how I do to capture the keyboard on this job so I do not see garbage at background while play??

When I do a simple "hello word" the program print "Press a key to exit" at the end of the windows, and the cursor do not return to the s*basic windows until press a key (and the job finish).

Posted: **Sun Jun 05, 2022 1:35 pm**

aalea wrote: OK, now, next problem: Multitasking

I do a simple loop forever that show the return return of mt_ipcom in a windows.
But at the same time I can see superbasic cursor on the background, I can even type basic programs while the program (the job) is running.

I was thinking that sd_curs/sd_cure will do the job, but not, how I do to capture the keyboard on this job so I do not see garbage at background while play??

When I do a simple "hello word" the program print "Press a key to exit" at the end of the windows, and the cursor do not return to the s*basic windows until press a key (and the job finish).

Using mt_ipcom to query the keyboard directly isn't exactly multitasking-friendly (after all, your job is hogging a device it doesn't own - the keyboard queue is still connected to Basic).
Standard QDOS doesn't change the foreground job that owns the keyboard to the new job when it is started with EX - The keyboard will stay connected to Basic and still receive keypresses. mt_ipcom will also not "eat away" keypresses it detected (SMSQ/E is a bit more friendly in that respect as it will by default make the new EXed job the foreground job). That is, on QDOS, you'll need to do that manually using <CTRL>-"C". That can only be done when the new job is displaying a cursor - But simply displaying a cursor isn't enough - you need to manually make the new job the foreground job.

The standard way (and the way to solve your problem) to start "game-like" applications that want to take over devices like the keyboard or the complete screen - or even everything, which would be normal for a game - and don't want to be "disturbed" by multitasking is to start them with EXEC_W or EW, which will suspend SuperBASIC until the new application has finished. Another possibility that the overwhelming majority of games used to take is not to start the game using EX, but rather LRESPR (or LBYTES and CALL) the code - it will then run within SuperBASIC's context instead of a separate job and also prevent Basic from eating CPU in the background (note, for making LRESPRable code, you need to use a different startup code - crespr_o - when linking in C68 - see the manuals for that, you basically add a "-screspr_o" to your linker command line). When developing, LRESPR/CALL is a bit of a nuisance, though. I'd recommend you do that only once you released the game.

Posted: **Tue Jun 07, 2022 7:45 am**

Yes, that solve the situation, sorry but I'm very newbie in the QL system.

I take note about the lrespr way, and yes, I need to check the documentation, I I mistakenly assumed that because C68 is native and XTC68 is cross-compiler the documentation will not apply.

The Sinclair QL Forum

There are any place with references for C programing?

There are any place with references for C programing?

Re: There are any place with references for C programing?

Re: There are any place with references for C programing?

Re: There are any place with references for C programing?

Re: There are any place with references for C programing?