Error message on #1

A place to discuss general QL issues.
User avatar
Cristian
Gold Card
Posts: 364
Joined: Mon Feb 16, 2015 1:40 pm

Error message on #1

Postby Cristian » Mon Nov 06, 2017 12:27 pm

One of my QLs (unexpanded, JM Rom) after trying to access a (likely defective?) MDV cartridge, doesn't print the "bad or changed medium" on #0 area at the bottom of the screen but on #1. Why this behaviour?


martyn_hill
Trump Card
Posts: 236
Joined: Sat Oct 25, 2014 9:53 am

Re: Error message on #1

Postby martyn_hill » Mon Nov 06, 2017 6:09 pm

Hi Christian

Typically, such system messages will try #0 first, but if busy (e.g. waiting for user input, as is often the case), will revert to #1 instead, before failing to print anything...

That'd probably explain what you see...


RWAP
RWAP Master
Posts: 2247
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Error message on #1

Postby RWAP » Mon Nov 06, 2017 6:54 pm

Some of the disk interfaces also used #1 to output file error messages - the original MicroP did this, from memory


User avatar
tofro
QL Wafer Drive
Posts: 1158
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Error message on #1

Postby tofro » Mon Nov 06, 2017 7:51 pm

RWAP wrote:Some of the disk interfaces also used #1 to output file error messages - the original MicroP did this, from memory


Which is actually a severe mis-use of QDOS. The Technical Guide explicitly says you cannot assume #1 to be open. You may do so for #0.

Tobias


martyn_hill
Trump Card
Posts: 236
Joined: Sat Oct 25, 2014 9:53 am

Re: Error message on #1

Postby martyn_hill » Mon Nov 06, 2017 7:59 pm

My bet is still the standard QDOS message writing utility: UT.WTEXT

From the QDOS/SMSQ Technical Guide, I found something I remember reading:

"As a special concession, interrupt servers and other supervisor mode routines can call these routines with A0=0.
If the command channel is in use, they will attempt to use channel 1."


User avatar
Cristian
Gold Card
Posts: 364
Joined: Mon Feb 16, 2015 1:40 pm

Re: Error message on #1

Postby Cristian » Mon Nov 06, 2017 9:10 pm

Thank you all for your suggestions. Still, I can't see a definite explanation.
Maybe more information from my side could be helpful:
- when I type for example "save mdv1_prog_bas", #0 should not be busy. But I get the message on #1;
- it's a plain QL with no interfaces. On the contrary, the other trumpcarded QL displays the error on #0;
- the microdrives unreliability on my unexpanded QL seems increased (writing problems, apparent lacks of motor movement fluidity and some led light unstableness. I also tried other mdv units). I suppose the message display issue should not be correlate with other possible issues such as defective mdv chips controllers and so on, am I right?


martyn_hill
Trump Card
Posts: 236
Joined: Sat Oct 25, 2014 9:53 am

Re: Error message on #1

Postby martyn_hill » Wed Nov 08, 2017 12:06 am

Hi Christian

I would doubt an MDV hardware fault giving rise to the #0/#1 message behaviour.

As for #0 being free or busy - if the cursor has already returned and flashing - as is often the case once the save routine has successfully written and during the automatic verify phase - then #0 will be 'busy' waiting for your next command. Then, should the verify fail a few seconds later, the error message would redirect to #1.

I.e. its all in the timing of when the error is detected - before the command prompt re-appears, or after. Anyway, you will be able to see for yourself by whether the cursor is already flashing in #0 at the point when the error message is printed to #1 :-)


User avatar
Cristian
Gold Card
Posts: 364
Joined: Mon Feb 16, 2015 1:40 pm

Re: Error message on #1

Postby Cristian » Wed Nov 08, 2017 9:50 am

For me is crystal-clear now. Thank you very much Martin!


User avatar
janbredenbeek
Trump Card
Posts: 171
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Error message on #1

Postby janbredenbeek » Wed Nov 08, 2017 3:06 pm

martyn_hill wrote:Hi Christian

I would doubt an MDV hardware fault giving rise to the #0/#1 message behaviour.

As for #0 being free or busy - if the cursor has already returned and flashing - as is often the case once the save routine has successfully written and during the automatic verify phase - then #0 will be 'busy' waiting for your next command. Then, should the verify fail a few seconds later, the error message would redirect to #1.

Since the physical MDV I/O takes place in the background under interrupts, if there is an I/O error in that process, UT.WTEXT gets called while #0 may be already waiting for input and thus be in use. Hence, the message gets printed on #1.

Jan.



Return to “General QL Chat”

Who is online

Users browsing this forum: No registered users and 1 guest