Re: reading status channel in ML

From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2006-04-10 09:19:01

Hallo Steve,

* On Sun, Apr 09, 2006 at 02:31:51PM -0600 Steve Judd wrote:
 
> Anyways, here is the routine I use to read the error channel (available in
> the Fridge, in one of the diskio.*.s files):
> 
>          LDA #13
>          JSR CHROUT
> *
> * This method is a bit faster on output to screen.
> *
[... open, chrin, chrout, close...]

BTW: You depend on $BA containing the number of the last accessed drive.
If there was no access before, your routine fails.
 
> and here is another one that was on the Merlin 128 disk, which is compact
> but slower:
[... talk, tksa, chrout, ...]

Why do you think that this one is slower? Have you done any
measurements?

CHRIN, CHROUT and the like the same, but having some wrappers around
them. Thus, this second version should be faster than the first one.

For example: OPEN (15,8,15) does absolutely nothing (but setting the
internal tables). (This is because no file name is given.)

CHKIN performs the TALK, TKSA calls; CLRCHN performs the UNTLK call.
CHRIN calls ACPTR.


Of course, both of your sample have one "problem": They depend upon the
error channel sending a CR as last character. Although they do,
"theoretically", it would be clearer to wait until EOF is signalled.

 
> I think my basic rule has been to use CLOSE, followed by CLALL when
> finished.
[correct to CLRCHN by you]

Well, I tend to disagree again. Although this works, I would change the
order: First CLRCHN, then CLOSE. It seems the "right" order to me to
first "detach" from a file (sending UNTALK or UNLISTEN), and THEN
closing it, than the other way around. Remember: If you close the file,
from an API's point of view, you still are outputting to that file,
although it is already closed.

Why does it work nevertheless? Well, if closing a file on the IEC bus,
the routine ($F63A) perform an UNLISTEN. Now, the floppy (at least, 154x
and 157x) considers UNLISTEN and UNTALK equal, so it gets the equivalent
of UNTALK, nevertheless. I am not sure if UNLISTEN = UNTALK is a
documented thing, or just works "by accident".

If this would not be the case, the CLRCHN would not be able to send an
UNTALK to the floppy (as the file is already closed), so, the floppies
command/error-channel would remain open.

Thus, again: I would reverse the order of CLRCHN/CLOSE.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.