Page 1 of 1

Error message on #1

Posted: Mon Nov 06, 2017 12:27 pm
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?

Re: Error message on #1

Posted: Mon Nov 06, 2017 6:09 pm
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...

Re: Error message on #1

Posted: Mon Nov 06, 2017 6:54 pm
by RWAP
Some of the disk interfaces also used #1 to output file error messages - the original MicroP did this, from memory

Re: Error message on #1

Posted: Mon Nov 06, 2017 7:51 pm
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

Re: Error message on #1

Posted: Mon Nov 06, 2017 7:59 pm
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."

Re: Error message on #1

Posted: Mon Nov 06, 2017 9:10 pm
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?

Re: Error message on #1

Posted: Wed Nov 08, 2017 12:06 am
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 :-)

Re: Error message on #1

Posted: Wed Nov 08, 2017 9:50 am
by Cristian
For me is crystal-clear now. Thank you very much Martin!

Re: Error message on #1

Posted: Wed Nov 08, 2017 3:06 pm
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.