TURBO'd app that hangs the QL on termination...

Anything QL Software or Programming Related.
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TURBO'd app that hangs the QL on termination...

Post by tofro »

On a black-box QL, Lightning (or Speedscreen) really can speed up things considerably.

If you got the memory, there's no reason I wouldn't use it there.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TURBO'd app that hangs the QL on termination...

Post by tofro »

pjw wrote: I would have noticed. Perhaps there is a specific version, or software configuration (eg TK2 + Turbo) that behaves in that way? Or perhaps another toolkit containing ALCHP thats overwriting TK2?
Now that you object, I'm not so sure anymore. Was it maybe a re-directed RESPR that did that?

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: TURBO'd app that hangs the QL on termination...

Post by pjw »

I ran this test (quicker for me than peering through the source code):

Code: Select all

10 REMark SMSQ/E only
20 :
100 IF PEEK$(\\-4, 4) <> 'SBAS' THEN
110  ch = FOPEN("con_")
120 ELSE
130  ch = 1
140 END IF
150 :
160 CLS#ch
170 PRINT#ch; 'Initial'
180 PRINT#ch; 'Free'! CDEC$(FREE_MEM, 11, 0)
190 BEEP 2,2: PAUSE#ch
200 a = ALCHP(1E6)
210 PRINT#ch; 'Memory reserved'
220 PRINT#ch; 'Addr $'; HEX$(a, 32)
230 PRINT#ch; 'Free'! CDEC$(FREE_MEM, 11, 0)
240 PAUSE#ch
250 RECHP a
260 PRINT#ch; 'Memory released'
270 PRINT#ch; 'Free'! CDEC$(FREE_MEM, 11, 0)
280 PAUSE#ch
290 PRINT#ch; 'Many reseverations'
300 a = ALCHP(1E6)
310 b = ALCHP(1E6)
320 c = ALCHP(1E6)
330 PRINT#ch; 'Free'! CDEC$(FREE_MEM, 11, 0)
340 PAUSE#ch
350 CLCHP
360 PRINT#ch; 'CLCHP'
370 PRINT#ch; 'Free'! CDEC$(FREE_MEM, 11, 0)
380 PAUSE#ch
390 :
400 PRINT#ch; 'Many reseverations again'
410 a = ALCHP(1E6)
420 b = ALCHP(1E6)
430 c = ALCHP(1E6)
440 PRINT#ch; 'Free'! CDEC$(FREE_MEM, 11, 0)
450 PAUSE#ch
455 IF JOBID = 0 THEN
456  CLCHP: STOP
457 ELSE
460  QUIT
462 END IF
Compile it or LOAD and RUN it from an SBASIC daughter job. Use some tools, eg QPAC2's Jobs, to check who owns the memory
and to see what happens to it. Run two versions in parallel, if you like, and see what happens. I rest my case ;)


Per
dont be happy. worry
- ?
stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO'd app that hangs the QL on termination...

Post by stevepoole »

Hi Martyn,

Just two extracts from SMSQ revision 6 guide, which may or may not be of interest...

SMSQ/E prefers QUIT in place of STOP within SBASIC jobs, else the job is not removed.

LRESPR cannot be used from a job, other than job 0, to load system extensions, (menu_rext etc).

Good luck with your debugging,

Steve.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TURBO'd app that hangs the QL on termination...

Post by tofro »

If you could elaborate a bit on what that program actually does, (like "allocate memory using ALCHP", working with PE, Menue Extensions, whatever) we could maybe help a bit better. Just from a guts feeling, I would vote for the timers as a culprit.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: TURBO'd app that hangs the QL on termination...

Post by pjw »

stevepoole wrote:LRESPR cannot be used from a job, other than job 0, to load system extensions, (menu_rext etc).
Just to clarify: You can LRESPR machine code toolkits in SBASIC daughter jobs; these remain local to that job and disappear again when the job dies. But certain system extensions, such as the mentioned menu_rext, should only be loaded in job 0, preferably at boot time. Which extensions are "system extensions" is not always obvious, though.


Per
dont be happy. worry
- ?
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO'd app that hangs the QL on termination...

Post by martyn_hill »

Hi everyone and thanks for chipping-in.

A few clarifications, whilst i continue to track down the issue:

a) This is being run on a Min 1.89 QL, no SMSQ/E here. I'm going to try Min 1.98 - just in case...
b) I do not make any (explicit) allocations at all - not even LRESPRs in the app itself. That said, I make much use of a (customised) DIYTK routine to handle screen-area saving (those W_STORE/W_SHOW extensions) which themselves allocate memory. I'll check the logic...
c) I use the DIYTK Timers, but then I also use them in other TURBO'd apps that don't exhibit this behaviour. They are disabled before termination with T_OFF - I'll try placing the T_OFF in the SB wrapper that starts the job itself...
d) I use the TH_LOAD/TH_USE/TH_FREE/TH_REMV routines from the Thing extension - but I've checked I've paired off every TH_USE with a corresponding TH_FREE before TH_REMV.

As for what the app actually does, well it may not shed much light, but it tracks and displays timings of the Scalextric cars passing over sensors on the track - monitored via some free input pins on Hermes. In the process, race timings and individual lap times are recorded between sessions against named 'drivers' (selectable from a list before each race.) The main race timer is displayed using custom 'sprites' like an old-fashion 7-segment-like LED display (actually just partial screen-saves, displayed using a variant of W_SHOW).

To facilitate the reading/writing of the various race-stats and other data (like drivers names), I use the MEM device (again, heavily customised!) mapped over the memory that TH_LOAD allocates when I read the data from storage (SDC). I take care of EOF (so as not to overwrite beyond the end of the allocated area) with a combination of the adjustments to the MEM device code, plus some simple SB.

I also implemented 'marque' text banners that scroll across the screen, alerting the drivers during the race. I remember being quite proud of that routine - a simple state-machine, called periodically to advance each scrolling window, based on individual timers. In fact, as a project (over a couple of years, now I think of it), I was able to stretch my programming skills and the humble QL - all in SuperBasic plus extensions - it was only due to the slow timer-display updates that I then started to compile in Turbo to keep up with the action!

...Well, you did ask, Tobias... :-)

Here are some screen-captures of it running (in 'debug' mode - where it doesn't try to access Hermes) on QPC2 - oh, and it doesn't hang in SMSQ/E, but thats not much of a comparison.
RMS_1.png
RMS_2.png
RMS_3.png
RMS_4.png
RMS_5.png


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO'd app that hangs the QL on termination...

Post by stevepoole »

Hi Martyn,

Quite an impressive piece of programming !

< 'The CON window remains visible, no further KB input is recognised' >

This includes 'CTRL C' ? (As the job does not appear to have been removed... rather than a 'crash'...)

Steve.


stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO'd app that hangs the QL on termination...

Post by stevepoole »

One other possibility is that you have somehow closed #0 of job 0 under QDOS. (SMSQ handles this case).

Steve.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO'd app that hangs the QL on termination...

Post by martyn_hill »

Hi Steve - thanks!

Yeah - CTRL-C also tried each time (along with CTRL-Space and others) - nothing doing.

Meanwhile, I tried also Min v1.98 - no change.

I even tweaked the SB source so as to run the app under the interpreter (which I haven't done for ages). In this case, it STOPs quite properly - which points back to how TURBO is closing it down - and what it takes down with it!

I too was wondering about the state of Chan #0 and whether the app is somehow smashing it as it closes-down.

It's time to play with some more serious debugging tools :-)


Post Reply