[comp.sys.atari.st.tech] MGR questions

7103_2622@uwovax.uwo.ca (Eric Smith) (02/27/91)

In article <GJH.91Feb26102918@ghiggins.hpl.hp.com>, gjh@hplb.hpl.hp.com (Graham Higgins) writes:
> 
> ++ I really hate that I can't press CTRL-G in emacs (under MGR),
> 
> 
> This bit me for a while until I tracked it down --- it is a "feature" of
> 'vt52.prg'.

It's a bug. Mea culpa. Your solution (recompiling vt52.c) should work
admirably.

> Question --- has anyone succeeded in getting mgr to recognise any of the ST
> cursor keys, or the HELP/UNDO keys?
> 

Nope. The best you could do is write a program that uses Keytbl() to remap
those keys to something else before running mgr. The reason is that mgr only
passes the lower 8 bits of characters to applications, so HELP etc. all get
mapped to ^@.

> I have another question. With a machete, I rejigged 'zmdm' to run under mgr
> (removing the screen memory calls and anything else I thought might interfere
> with mgr), and it works, but whilst it is connected to the RS232 port,
> mgr/mint/kshv4 (something, somewhere in that trio) prevents me both from
> opening other windows (can't get a pty) and from doing anything in another
> already-existing window (cannot fork, try later). Could anyone hazard a guess
> as to whether it's something I did to the zmdm code, or whether there's
> something else that's biting me. 

Sounds like something is grabbing all of memory. Does zmdm use Malloc(-1L) to
allocate a buffer, by any chance? You could try using "limit" to restrict the
amount of memory it will steal.

> I redid the whole thing as an mgr application, using mgr library calls, but I
> suspect that m_setup() remaps the ports 'cos I can't get any characters out of
> the rs232 port, I wonder if Bconstat(rs232) is actually checking the rs232
> port? Bconstat(console) seems to work OK.
> 

No, Bconstat(rs232) should always talk to the rs232 port under MiNT. The
console (BIOS device 2) is the only one that is ever re-mapped. It is
true that m_setup() does a _binmode(1) call, so all stdio stuff is in
binary mode. However, I can't zmdm using the stdio package for I/O! The
only other thing I can think of is that zmdm might be getting some sort of
job control signals from the terminal; if you want to be sure, you might
try opening "AUX:" and then using ioctl() to set the process group of
the rs232 port to the process group of zmdm.
-- 
Eric R. Smith                     email:
Dept. of Mathematics            eric.smith@uwo.ca
University of Western Ontario   7103_2622@uwovax.bitnet

gjh@hplb.hpl.hp.com (Graham Higgins) (03/01/91)

++ It's a bug. Mea culpa. Your solution (recompiling vt52.c) should work
++ admirably.

It does.

>> [HELP/UNDO seen by mgr?]

++ Nope. The best you could do is write a program that uses Keytbl() to remap
++ those keys to something else before running mgr. The reason is that mgr only
++ passes the lower 8 bits of characters to applications, so HELP etc. all get
++ mapped to ^@.

Ah, lux fiat. So, Keytbl() mapping of cursor keys to appropriate
control sequences would probably allow cursor key driving of me.tos
--- where's that compiler?

> [process problem with zmdm & rs232 port query]

++ Sounds like something is grabbing all of memory.

It was. Limit constrains zmdm to behave.

++ Bconstat(rs232) should always talk to the rs232 port under MiNT.

It does. Once I could actually get in to it, the core zmdm
read-rs232/console-echo loop seems to work OK. 

*However* --- the poster who commented that the rz/sz code was "tight" was
quite correct, although I managed to hack zmdm around to work under mgr,
neither rz nor sz appear to work inside zmdm. C'est la vie.

Thanks for the info.

Graham
======

------------------------------------------------------------------
Graham Higgins                  |  gjh%ghiggins@hpl.hp.co.uk
Hewlett-Packard Labs            |  gjh%ghiggins@hplb.hpl.hp.com
Filton Road, Stoke Gifford      |  gjh%hplb.csnet@csnet-relay.arpa 
Bristol, U.K.                   |  ...!mcvax!ukc!hplb!gjh          
Tel: +44 272 799910 x24014         Fax: +44 272 790554             
------------------------------------------------------------------
Disclaimer: My opinions above are exactly that, mine and opinions.
------------------------------------------------------------------