Error message on #1

A place to discuss general QL issues.
Post Reply
User avatar
Cristian
Aurora
Posts: 960
Joined: Mon Feb 16, 2015 1:40 pm
Location: Veneto

Error message on #1

Post by Cristian »

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
Aurora
Posts: 908
Joined: Sat Oct 25, 2014 9:53 am

Re: Error message on #1

Post by martyn_hill »

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: 2833
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Error message on #1

Post by RWAP »

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


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

Re: Error message on #1

Post by tofro »

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Aurora
Posts: 908
Joined: Sat Oct 25, 2014 9:53 am

Re: Error message on #1

Post by martyn_hill »

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
Aurora
Posts: 960
Joined: Mon Feb 16, 2015 1:40 pm
Location: Veneto

Re: Error message on #1

Post by Cristian »

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
Aurora
Posts: 908
Joined: Sat Oct 25, 2014 9:53 am

Re: Error message on #1

Post by martyn_hill »

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
Aurora
Posts: 960
Joined: Mon Feb 16, 2015 1:40 pm
Location: Veneto

Re: Error message on #1

Post by Cristian »

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


User avatar
janbredenbeek
Super Gold Card
Posts: 628
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Error message on #1

Post by janbredenbeek »

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.


Post Reply