Error message on #1

[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]

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]

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

[tofro]

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]

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."

[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]

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

[Cristian]

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

[janbredenbeek]

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.