Strange problem with Display Toolkit and Q-emuLator

Anything QL Software or Programming Related.
Post Reply
User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Strange problem with Display Toolkit and Q-emuLator

Post by programandala.net »

I'm having problems with Display Toolkit's DMODE (and sometimes also with FLIM_H and FLIM_W; other keywords work fine) in Q-emuLator. It seems those keywords are not properly linked in with the MGE ROM (sometimes also with JM) under certain conditions I don't understand. JS and Minerva (1.89 and 1.98) seem to work always fine. I've had no similar problem with QPC2.

I use DMODE in a boot file, to prepare the screen for the main program. But many times DMODE is interpreted as a undeclared variable, thus giving an error. It seems DMODE works fine or not depending on the boot's content. Sometimes it works fine after removing some lines. Other times it works fine after adding some REMarks at the start of certain lines. I've found no logic at all -- in fact those "offending" lines are not executed in the tests! I suspected the problem had something to do with the lenght of the boot file, but it doesn't. Then I thought it had something to do with the Q-emuLator's option to press F1 or F2 at the inital prompt, but it doesn't.

I've done a lot of tests, trying to guess what causes the problem, but I didn't success. I don't know if the problem is in the toolkit, in Q-emuLator, in the ROMs or any combination of them.

Actually, the fact DMODE, FLIM_W and FLIM_H are not linked in is clear because they remain lowercase in the QL listing. But not always the three words are not linked in at the same time.

I want to show you some examples about DMODE.

The following test doesn't work with MGE and JM. It should print the screen mode (0 or 8) and then stop, but it prints "*" instead, because DMODE is not linked in:

Code: Select all

  100 tk2_ext
  110 lrespr "flp1_display_code"
  120 print dmode
  130 stop
  330 defproc init_ql_colours
  400 enddef
  410 deffn rgb(red,green,blue)
  430 enddef
  440 defproc init_the_window
  450   let csize_w=3-(scr_w=512)
  460   let csize_h=scr_w>512
  470   let tw=fopen("con_")
  480   csize #tw,csize_w,csize_h
  490   let tw_w=minimum(800,scr_w)
  500   let tw_h=minimum(600,scr_h)
  510   let tw_x=(scr_w-tw_w)/2
  520   let tw_y=(scr_h-tw_h)/2
  530   window #tw,tw_w,tw_h,tw_x,tw_y
  540   paper #tw,black
  550   ink #tw,light_grey
  560   wipe_the_window
  570   init_the_font
  580 enddef
  590 defproc wipe_the_window
  600   border #tw,0
  610   cls #tw
  620   border #tw,8
  630 enddef
  640 defproc splash_screen
  650   if flim_w(#0)=512 and flim_h(#0)=256 
  660     lbytes dev$&img_ayc8_scr,address(#0)
  670   endif
  680 enddef
If I remove lines 640-680, the program works fine with MGE, but still fails with JM.

If I remove all lines from 330, nothing changes:

Code: Select all

  100 tk2_ext
  110 lrespr "flp1_display_code"
  120 print dmode
  130 stop
If I reset the emulator with JM and don't boot the file, but type in the LRESPR command instead, DMODE works.

Another test that doesn't work fine:

Code: Select all

  100 tk2_ext
  110 lrespr "flp1_display_code"
  120 print dmode
  130 stop
  330 defproc init_ql_colours
  400 enddef
  410 deffn rgb(red,green,blue)
  430 enddef
  440 defproc init_the_window
  450   let csize_w=3-(scr_w=512)
  460   let csize_h=scr_w>512
  470   let tw=fopen("con_")
  480   csize #tw,csize_w,csize_h
  490   let tw_w=minimum(800,scr_w)
  500   let tw_h=minimum(600,scr_h)
  510   let tw_x=(scr_w-tw_w)/2
  520   let tw_y=(scr_h-tw_h)/2
  580 enddef
  590 defproc wipe_the_window
  630 enddef
  640 defproc splash_screen
  680 enddef
 1700 deffn prog_device$
 1850 enddef
 1860 deffn prog_found_in(device$)
 1910 enddef
If I remove line 520, DMODE works fine with the MGE ROM!

I've tried with and without TK2_EXT, with LRESPR and with LBYTES and CALL. No difference.

Another test that doesn't work with MGE... unless I remove line 510!:

Code: Select all

  100 rem tk2_ext
  110 rem lrespr "flp1_display_code"
  110 let a=alchp(1094):lbytes "flp1_display_code",a:call a
  120 print dmode
  130 stop
  330 defproc init_ql_colours
  400 enddef
  410 deffn rgb(red,green,blue)
  430 enddef
  440 defproc init_the_window
  450   let csize_w=3-(scr_w=512)
  460   let csize_h=scr_w>512
  470   let tw=fopen("con_")
  480   csize #tw,csize_w,csize_h
  490   let tw_w=minimum(800,scr_w)
  500   let tw_h=minimum(600,scr_h)
  510   let tw_x=(scr_w-tw_w)/2
  580 enddef
  590 defproc wipe_the_window
  630 enddef
  640 defproc splash_screen
  680 enddef
 1700 deffn prog_device$
 1850 enddef
 1860 deffn prog_found_in(device$)
 1910 enddef
The Display Toolkit manual mentions problems with JM ROM, but only with the BYTES keyword.

I don't see any logic. Any clue?


Marcos Cruz (programandala.net)
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Strange problem with Display Toolkit and Q-emuLator

Post by RWAP »

The problems with the JM ROM are no doubt due to the fact that you cannot generally use a toolkit in the same program which initiates the toolkit on the JM ROM (this was fixed in JS ROM).

Hence you may need to have a double boot program - ie. a short program to use RESPR, LBYTES and CALL to link in the toolkit, then LRUN main_program.

You can also run into problems if keywords are used in the main program before you link in the toolkit (as the names are already on the name table).

I say "generally" as Toolkit II's TK2_EXT command includes additional coding by Tony Tebby to overcome these restrictions. I actually had agreement from Tony to use this code in one of my own toolkits!

The other thing to check is that you are setting aside the correct amount of memory in your RESPR call - it may be that the DMODE toolkit actually needs you to set aside more memory than just the number of bytes that the code occupies - check the manual (if there is one), and do WSTAT flp1_display_code to check the file size as a minimum amount of memory to set aside with RESPR.

Finally, you should NEVER use ALCHP to reserve memory for a toolkit - as it can easily be cleared but the name table retains the links to the machine code definitions, so it will crash the QL.


User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Re: Strange problem with Display Toolkit and Q-emuLator

Post by programandala.net »

RWAP wrote: The problems with the JM ROM are no doubt due to the fact that you cannot generally use a toolkit in the same program which initiates the toolkit on the JM ROM (this was fixed in JS ROM).
I didn't know that. I tried the JM ROM just to get any clue comparing different ROMs. The ROM I need for the program is MGE.

Hence you may need to have a double boot program - ie. a short program to use RESPR, LBYTES and CALL to link in the toolkit, then LRUN main_program.

You can also run into problems if keywords are used in the main program before you link in the toolkit (as the names are already on the name table).
Keywords are used after linking in the toolkit, but anyway I tried also a double boot: the first one links in the extension(s), and the second one prepares the screen (using some toolkit keywords) and loads the main program. No difference: The second boot fails as well with some words of the toolkit, without a pattern.
RWAP wrote: The other thing to check is that you are setting aside the correct amount of memory in your RESPR call
The Display Toolkit's manual is clear about that, with examples of RESPR call and LRESPR, so that cannot be the problem in this case.
RWAP wrote: Finally, you should NEVER use ALCHP to reserve memory for a toolkit
Right. I knew the difference between ALCHP and RESPR but I typed in the wrong one in that example, it was a mistake.

I'll keep on investigating...


Marcos Cruz (programandala.net)
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Strange problem with Display Toolkit and Q-emuLator

Post by RWAP »

I have just tried your program using the MGE_ROM, Q-emulator and the DISPLAY_cde from the Sinclair QL Homepage - http://www.dilwyn.me.uk/tk/display2.zip

Maybe the version of display_code you have has a bug (or is a different toolkit)?


User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Re: Strange problem with Display Toolkit and Q-emuLator

Post by programandala.net »

RWAP wrote:I have just tried your program using the MGE_ROM, Q-emulator and the DISPLAY_cde from the Sinclair QL Homepage - http://www.dilwyn.me.uk/tk/display2.zip

Maybe the version of display_code you have has a bug (or is a different toolkit)?
Thank you for the try and the idea. I downloaded the toolkit again, compared it with my copies using a file comparation tool and found no difference. Then tried the downloaded version and the problem still happens.

But somehow among many tries I succeeded to get a boot that works so far, don't know how or why, changing lines around.

I use Wine on Debian, so the last thing I can try is a real Windows, though I hardly believe it has something to do. Anyway at the moment I cannot use any real Windows, so that test must wait some weeks.

It's one the most curious bugs I remember.


Marcos Cruz (programandala.net)
User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: Strange problem with Display Toolkit and Q-emuLator

Post by dilwyn »

You will get this problem with most toolkit extensions on version AH or version JM ROM.

The interpreter will not allow you to use a keyword in the same program as that in which it was loaded. It must be loaded by a separate program. something like:

This is one of the purposes of the BOOT program on a QL. It is always best to have a boot program load the extension(s), then use it in another separate program, or MRUN the lines the use it. On AH and JM, the interpreter cannot retokenise a keyword in a line of basic after that which loads the toolkit.

For example:

100 LRESPR display_cde
110 PRINT DMODE

Although interestingly this can sometimes work:

program one:

100 LRESPR display_cde
105 MRUN program2_bas

program two:

110 PRINT DMODE

The rule of thumb is that the toolkit must have been installed before a line of BASIC which tries to use its extension has been loaded.

There are a lot of old PD and Quanta Library programs which do this and they are almost certainly guaranteed to work on AH and JM ROMs, while they always work fine on later ROM versions.

Dilwyn Jones

Dilwyn Jones


User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Re: Strange problem with Display Toolkit and Q-emuLator

Post by programandala.net »

After many tries, I've found out a clue: Display Toolkit is not properly installed in Q-emuLator (the last version, registered) when the MGE ROM is used and the speed is 100% of QL's:

if MGE and speed=100 then PROBLEM
if MGE and speed>100 then FINE
if JS then FINE
if Minerva189 then FINE

I don't know if there are any other factors, but that's what happens.

i've just published the project, a port of a text adventure in Spanish, though the boot fails under the conditions I mentioned. May someone try it and confirm? The link to the download section is:

http://programandala.net/es.programa.as ... l#descarga

The source of the boot file is the first one listed on the following page:

http://programandala.net/es.programa.as ... ql.listado

Thank you in advance


Marcos Cruz (programandala.net)
User avatar
programandala.net
Chuggy Microdrive
Posts: 74
Joined: Mon Dec 13, 2010 12:41 pm
Location: Spain
Contact:

Re: Strange problem with Display Toolkit and Q-emuLator

Post by programandala.net »

programandala.net wrote:After many tries, I've found out a clue: Display Toolkit is not properly installed in Q-emuLator (the last version, registered) when the MGE ROM is used and the speed is 100% of QL's:
Daniele Terdina has confirmed that this is a MGx ROM bug combinated with a Q-emuLator patch.


Marcos Cruz (programandala.net)
Post Reply