[Coco] MM1 programmes

[KnudsenMJ at aol.com]

In a message dated 11/17/03 5:04:31 AM Eastern Standard Time, 
bdevries at gil.com.au writes:

> OK, I found what was wrong. I needed to insert:
>  IF INKEY(#path) =0 THEN blah, blah.
>  Remember that in OS-9/68K BASIC the INKEY routine returns the number of
>  chars waiting in the buffer, *not* the first key in the queue.
>  It appears that if you try to read from the buffer, and there's no waiting
>  chars, it seems to lock up.

By "lock up", you don't just mean that it waits for another byte to come in?  
You mean it really gets hosed and freezes even after more bytes come in?

I agree that INKEY() in any form is invaluable when you want to check an 
input without getting stuck waiting for it.  My C programs use an OS-9 stat call 
to simulate that.  The lack of any easy way to do it in UNIX or the C library 
is an ongoing scandal.  MSDOS has getch() which accomplishes the same end.

But if your code is truly locking up, that's a bug in BASIC.  But if you can 
avoid it by always pre-testing with INKEY(), then you have a good work-around. 
 Thanks.

>  It does ON ERROR GOTO, I dunno if CTRL-C is catchable, though.

On my MM/1, Ctrl-E (BREAK keypad key) is the "hard" interrupt, and Ctrl-C is 
the "soft" one.  In my C code for UlitMusE I catch both of these and can tell 
the difference.  Don't know if BASIC can catch one of these without getting 
killed itself; maybe the TMode command can adjust the break characters, if not 
their behavior.
--Mike K.