[net.games.hack] Trouble w/ I/O in Hack 1.0.2 on SVR2

mom@sftri.UUCP (Mark Modig) (04/24/85)

OK, I give.  I have been trying to get Hack 1.0.2 running on a 3B20
w/ SVR2.  The program appears to start ok, but you must enter
exactly four commands to get any response. [To clarify, this begins
from the beginning-- When it asks if you are experienced, you would
have to enter, for example, y, a return, and two more characters. 
Up until this time, there is no output to the terminal.  When you
have entered the fourth character, the y is echoed properly, the
return would be taken as an answer to the next question {what
character are you?, etc....}]
Then to get any more action, you have to enter four more
commands, and until you do, there is no output to your terminal.
Once you enter four commands, it executes them, and waits until it
has four more.  It's always four, as near as I can tell. I've tried
using setvbuf to make all I/O unbuffered, but it doesn't seem to
help.  The input appears to be read OK, just in these weird four
command chunks.  (I've just tried simple one character commands so
far, e.g. movement.)  Anybody have any ideas?

Mark Modig
ihnp4!sftri!mom

ronald@hcrvax.UUCP (Ron Williams) (04/26/85)

<The line-eater comes and takes all your possesions.>
Mark Modig asks:

> OK, I give.  I have been trying to get Hack 1.0.2 running on a 3B20
> w/ SVR2.  The program appears to start ok, but you must enter
> exactly four commands to get any response.

This is because of the insane way termio(7) has been implemented.
If you read carefully the section describing ICANON, MIN, and TIME,
you will see that your EOF character, (ascii 04), determines how many
characters must be typed before a read returns when canonical processing
(cooked mode) is disabled.  If you don't understand this section, just
set your EOF character to be ^A.

psc@lzwi.UUCP (Paul S. R. Chisholm) (04/28/85)

< Smokey the Bar says, "Stamp out software pirates" [squish!] >

>From ihnp4!mhuxn!mhuxm!sftig!sftri!mom Tue Apr 23 18:24:29 1985
>From: mom@sftri.UUCP (Mark Modig)
>Newsgroups: net.games.hack
>Subject: Trouble w/ I/O in Hack 1.0.2 on SVR2

[Note:  Hack is a screen oriented game that does character-at-a-time
input, ala vi and emacs, instead of line-at-a-time input, as in ed,
sh, and almost everything else.  Hack is a varient of "rouge"; see
also "Under Bell Labs" and "ad&d" (not the TSR version).  -psc]

> OK, I give.  I have been trying to get Hack 1.0.2 running on a 3B20
> w/ SVR2.  The program appears to start ok, but you must enter
> exactly four commands to get any response. [To clarify, this begins
> from the beginning-- When it asks if you are experienced, you would
> have to enter, for example, y, a return, and two more characters. 
> Up until this time, there is no output to the terminal.  When you
> have entered the fourth character, the y is echoed properly, the
> return would be taken as an answer to the next question {what
> character are you?, etc....}]
> Then to get any more action, you have to enter four more
> commands, and until you do, there is no output to your terminal.
> Once you enter four commands, it executes them, and waits until it
> has four more.  It's always four, as near as I can tell. I've tried
> using setvbuf to make all I/O unbuffered, but it doesn't seem to
> help.  The input appears to be read OK, just in these weird four
> command chunks.  (I've just tried simple one character commands so
> far, e.g. movement.)  Anybody have any ideas?
> 
> Mark Modig
> ihnp4!sftri!mom

Oh, I've seen *this* one before!  Since Unix System III, the termio(7)
structure has had an array of user definable control characters, e.g.,
character erase (# by default, but usually ^H).  The problem is, two
of these entries are overloaded.  They mean EOF and <something else>
when canonical processing (e.g., treating the number sign or backspace
as somthing special), and and time and character counts when canonical
processing is off.  So hack turns off canonical processing, and the
next read(2) from the terminal waits until it gets four characters,
because c_cc[VMIN] = c_cc[EOF] = cntl(D) = 4.  If you'd redefined the
EOF character to ^Z, you'd need to type 26 commands before hack saw any
of them.  Got it?

The fix is to find where canonical processing is turned off, and make
sure c_cc[VMIN] is set to 1 (and c_cc[VTIME] is set to 0, which means
no timeout when c_cc[VMIN] > 0).
____
Please restrict followups on whether this worked to net.games.hack or
simple email, and discussions of termio(7) to net.unix and att.unix,
please, *please*, *P*L*E*A*S*E*!]
-- 
	-Paul S. R. Chisholm
	...!{pegasus,vax135}!lzwi!psc   The above opinions are my own,
	...!{hocsj,ihnp4}!lznv!psc      not necessarily anyone else's,
	...!{pegasus,cbosgd}!lzmi!psc   including my employer's.

hmm@unido.UUCP (04/29/85)

In the SYSV Terminal driver, the field for the EOF character has
another meaning in raw i/o: it denotes a minimal char count.
I assume you have EOF set to ctl-D, the ASCII code for this is 4.
Guess what happens ?  read() returns when 4 chars are read.

Simple fix:
Set EOF to ctl-A (ASCII 1) before you play hack.
Don't forget to reset it after playing !

Better fix:
Find the terminal initialization routine in hack (sorry, I haven't got
the time to do it myself) and fix it.  Maybe you should post it,
since this bug should occur on all SYSV hacks...

	Hans-Martin Mosner
	Universitaet Dortmund (Germany)
	ihnp4!hpfcla!hpbbn!unido!hmm 
	      seismo!mcvax!unido!hmm