Conference hydra::amiga_v1

       Dave, love the ability to use AMIGA key combinations for changing
       parameters.

       Art

    Dave,
    I've noticed a problem with the ESCAPE sequences for DOUBLE HEIGHT
    DOUBLE WIDTH display. This becomes a real problem when trying to
    login to a system with SYS$WELCOME containing DH/DW with no normal
    text following. Because the ESC sequences aren't interpreted, they
    get fed into the USERNAME  prompt as a response and disable any
    terminal input.
    
    Is this an Amiga limitation? Is there a workaround?
    
    Regards from DU
    Rob
    

re: < Note 228.2 by SNO78C::METRO_OA >

 Rob:	The escape sequence parser eats any AND ALL legal escape sequences.
	This means that ones it doesn't understand just get ignored.

	I just tried using the emulator with DH/DW characters (<esc>#3 and
	<esc>#4 in the text), and it worked fine.

	Please send me a specific example and I'll try to fix it. (In other
	words, I can't duplicate what you describe....)

Best Regards,
dave

    

re:	.0

VT100 V2.5 is available under:

	COOKIE""::DISK$GZ_DISK:[WECKER.AMIGA]
		VT100_25A.SHAR	- documenation and first half of sources
		VT100_25B.SHAR	- second half of sources
		VT100_25.ARC	- arc'd versiond of documentaion and exe.

Please reply to this note for questions, comments and bug reports.

    First, I want to thank you Dave for this emulator... it's really
    great!
    
    And then, to the complaints..   :-)
    
    You seem to bypass the keymap so the thing is pretty useless with
    a non-US keyboard (mine has a German keyboard). Is there an easy
    way to fix this?
    
    Also, a couple of wishlist items (these have really not much to
    do with VT100 emulation, I (mis)use it for other purposes too):
    
    - local echo
    
    - using a single cr and/or lf as a 'newline' character (on input).
    

re:	.5

->     You seem to bypass the keymap so the thing is pretty useless with
->     a non-US keyboard (mine has a German keyboard). Is there an easy
->     way to fix this?

Send me sample keymap code and I'll incorporate it (if possible).

->     Also, a couple of wishlist items (these have really not much to
->     do with VT100 emulation, I (mis)use it for other purposes too):

->     - local echo

See v2.5 (it's there).

->     - using a single cr and/or lf as a 'newline' character (on input).

Don't understand... that's what happens now (the standard VT100 escape sequence
also works (<esc>[20h or l) for newline versus line feed mode).

dave

    I am an Amiga novice (Hopefully not for long); I assume whether
    or not the characters pass the built-in keymap depends on the specific
    I/O calls made (in Basic, I have't yet figured out how to *bypass*
    the keymap). I can send you info on the location of the keys that
    are different on the German keyboard (quite a few). I guess the
    scan codes returned are always the same (like on a LK201).
    
    re newline: sorry for expressing myself a bit unclearly; what I
    wanted to see is the possibility to set e.g. CR to be the newline
    character (displayed as cr-lf on the screen when received) in the
    initialization file. (The other purpose I'm 'misusing' this for
    is for a semi-intelligent radio modem; it does not know anything
    about a VT100 and is not able to send any escape sequences).
    
    I'll have a look at V2.5...

    

    P.S. Just had an idea: why don't you simply implement a freely
    definable character conversion table that can be loaded on
    initialization? That would make it usable with *any* keyboard,
    and even for any hosts that might use strange codes (like DEC ones
    using NRC character sets...). In fact the radio modem I mentioned
    does a somewhat non-standard ASCII-Baudot conversion so I could
    'fix' that in the emulator...
    

    Uh, Dave, there seems to be a problem with your v2.5 vt100.
    
    Heres the problem.  Choose smodething that requires that a requester
    box pops upo.  Well, the box pops up on the right hand middle of
    the screen but the cursor stays in the upper Left corner.  This
    makes it sort of hard to see what you are typing.  Clicking on the
    DONE box in the requster in it s current position kill the box.
    
    (By the way how do you get the backspace key to work properly? All
    mine does is return to the begging of the line)
    
    			(Sorry about the typpos in the message)
    			Rob

    Another suggestion: The European Amiga (PAL version) has 256 pixels
    vertical resolution - that gives about 32 lines of text in
    non-interlace (minus borders). Could you make it accept bigger
    values in the init file (I assume that there is a way to find out
    if it runs on a PAL Amiga). Or just try to vreate a creen of the
    size the user wants, I gues the call will bomb out if the screen
    is too big..
    

    Oh, yes, that darn requester box. It requires that you click the
    mouse before entering a file name, which was not required when
    the file name was prompted for on the last line of the display.
    Also, to close the capture buffer, one only had to select the
    Capture menu item. Now one must also click the requester that pops
    up. 
    
    Can the extra mouse click be eliminated Dave?

I just posted a request to the net (comp.sys.amiga) for help on this
one. I spent most of the weekend trying to get the input line of the
requester PRESELECTED, but here is what happens:

	1)	when you just create a requester with a string gadget,
		nothing happens until you select the gadget

	2)	if you add the SELECTED bit to the gadget, a cursor comes
		up at the beginning of the input string BUT NOTHING YOU TYPE
		GOES TO THE GADGET... until you click on the string,
		then the cursor goes to the end of string and awaits your
		input.

	3)	Several commercial programs (like Marauder-II) bring up PRE
		SELECTED string requesters with no problem, so I know it's
		possible.

Ok... anyone know what I'm doing wrong?

    Same problem with Scribble!, the requester must first be selected
    before text can be entered. They claimed they would fix this in V2,
    but alas NO FIX in V2 from what I have seen. Perhaps they are stymied
    too!
    
    Paul

    
    Wait a minute.  I'm almost positive my Scribble! requestors come
    up already selected (i.e no click just start typing).  Maybe we
    have different versions of 1.2.  I understand these range from
    33.45 to 33.47.  I've got 33.47.
    
    I'll check scribble! tonight...I could be wrong.
    
    regards,
    
    steve mcafee 

    Yup, my Scribble! requestors come up pre-selected...
    

Look on page 55 of the 1.2 Update manual.  There is a new function,
ActivateGadget().

Unfortunately, the update manual does not describe the argument(s) to
ActivateGadget.  I would bet that it takes a single argument, a pointer
to a struct Gadget.

VT100 does not work when built using the latest version of Lattice C.

The file EXPAND.C defines the following functions:

	dopen
	dnext
	dclose

These functions conflict with library functions of the same name added
in the Lattice v3.10 distribution.  In the Lattice Library, these functions
allow low-level (AmigaDOS) file manipulations, and are called by fopen,
fclose, etc.

If VT100 is built with Lattice, it will Guru as soon as it tries to open
the VT100.INIT file.  (VT100 calls fopen to open the init file;  fopen
calls dopen to open the AmigaDOS file; dopen in EXPAND.C gets called with
the wrong arguments: Guru 3.)

The easiest way to fix the problem is to make dopen, dnext, and dclose
static functions.  I believe they are not called outside of EXPAND.C,
and thus can be made static.  If static, they are no longer global, and
thus do not obscure the library routines.

I noticed the problem with VT100 v2.4, and the fix I just suggested worked
fine there.  I was going to report this problem, but I had thought that
someone on the Usenet had already discovered it.

I haven't tried building VT100 v2.5, yet.  But I did notice from the
source that the dopen-dnext-dclose problem still existed.

Ooops....

	1)	I forgot to rename the EXPAND.C functions... will do.

	2)	I know about ActivateGadget(), however:

		a) Does anyone know the order/number of parameters?
		   (it MUST at least take a window parameter also...)

		b) How can I use it since Manx 3.20a doesn't  about the
		   function, the linker tells me that it's undefined ?!?!?!

dave

Re: .18

The 1.2 documentation makes it sound that both ActivateWindow() and
ActivateGadget() should be called to activate a gadget.  (At the start
of the Intuition section, the manual mentions ActivateWindow/ActivateGadget
and implies both were used to activate the string gadget that the workbench
uses to get the new name during a rename operation.)

To use a 1.2 only function with a 1.1 compiler release, you would have
to write a little jacket routine to call the AmigaDOS library using
the proper entry vector offset.  I'll see if I can come up with anything
by disassembling Lattice function.

I noticed that the "Amiga Programmer's Handbook, volume I" came out with
a new 1.2 edition.  Unfortunately, I don't remember who wrote it or if
I got the name of the book right.  The cover has a grainy picture of the
golden gate bridge on it.  I remember looking up ActivateWindow in the
book in a bookstore and noticing that ActivateWindow took only one
argument.

    
    FYI I noticed a 1.2 version of the AMIGADOS manual in Waldens last
    weekend.  It seemed thicker but I didn't go through the index to
    check it out.  Any one have a new copy?
    
    steve mcafee

Here is a listing of ActivateWindow() and ActivateGadget() produced by
MetaScope.  Note that $ introduces a hex constant.


Listing of window "Memory":
_ActivateWindow
24A37C   MOVE.L  A6,-(A7)
24A37E   MOVEA.L _IntuitionBase,A6
24A384   MOVEA.L 8(A7),A0
24A388   JSR     -$1C2(A6)
24A38C   MOVEA.L (A7)+,A6
24A38E   RTS
_ActivateGadget
24A390   MOVEM.L A2/A6,-(A7)
24A394   MOVEA.L _IntuitionBase,A6
24A39A   MOVEM.L $C(A7),A0-A2
24A3A0   JSR     -$1CE(A6)
24A3A4   MOVEM.L (A7)+,A2/A6
24A3A8   RTS

Just recently, using VT100 V2.4, I started noticing lots of disk activity
while using a script file to dial in to work. The first part of the script
( setting up the modem, dialing, and the multiple carriage returns to break
into the LAT ) has my poor drive continuously grinding while the rest of the 
script has no disk activity. I've been wondering if I might have fragmented 
the disk by editing files, including the script file, on a very full disk.

Any experience out there with this?

Thanks,
Dick

I noticed the same problem this weekend as I was trying out v2.5.
I assumed it had to do with looping.  (Perhaps the file is re-read every time 
through a loop?)  I solved the problem by running the script out of RAM:.
However, I notice the script is still giving the poor Amiga heartburn - the 
cursor flickers badly during those same loops.

	Paul

Well.. I don't know about script thrashing (I've never had a problem)... but....

VT100 (V2.6 DBW 870227) is now available in:

	COOKIE::DISK$GZ_DISK:[WECKER.AMIGA]VT100_26A.SHAR	- first half
					   VT100_26B.SHAR	- 2nd half
	docs, executable, icon:		   VT100_26.ARC

There are some major re-writes to the SCRIPT/INIT facility, self selecting
requesters and lots more.... READ THE DOCUMENTATION!!!!

Please bang on it hard (before I release it to the USENET) ... This is why
I have it pre-dated.

Thanks!
dave

    Sheesh .. you are on a tear dave. Can hardly keep up! Thanks.

    
    When you use goto's in script files, a seek is done back or forward
    to that position in the file. If you dont have any addbuffers set
    AmigaDos may have to keep re-reading in that sector, thus the 
    thrashing.
    	Solution:  1.) Addbuffers dfn:  nn (this is probably why Dave
    					    never sees this problem).
    		or 2.) Put script file in Ram: (as you found).

    Steve.

I put up V2.6 last night.  So far it looks good, though I haven't had time to 
use it much.  (Seems to get better every day!)

The icon certainly is nicer than the one I had before.  This gave me an idea 
for a 1+, though I am not certain what is involved in implementing it.  How 
about supporting Project Icons which are attachted to script files?  Then it 
would be easy to click the icon for who/what you want to connect to and be 
done with it.  This would also allow the tool itself to be in a more 
convenient place - perhaps in the C: directory.

	Paul

Maybe this is a dumb question but why did it become necessary to acknowledge 
that the script file is finished in V2.6? ( No big deal but just thought it
was an unnecessary step )

Was also wondering if anybody has done any fancy scripts for a SCHOLAR modem
to look for errors on autodialing (ie. busy, no answer, etc.) and then retry
on other lines. I have one that tries a 2400 line and if it doesn't get
"Attached" in a given period of time will try calling a 1200 line. I'll
mail this to anyone interested but won't post it as it is an embarassing hack.

This may be indicating a need for testing multiple string conditions by some
sort of case structure.

A single dynamic case statement should be sufficient as it can be reused within
a loop or reinitialized and used in other places. Also limitations of 10 cases
should be sufficient for anybody's needs.

Proposed script syntax:

/* Allow initialization of case structure prior to entry of case elements   */
	CLEAR CASE
/* Allow entry of case elements as search strings with associated commands  */
	CASE 1 "Speed:1200" BAUD 1200
	CASE 2 "Attached" GOTO Login
	CASE 3 "Busy" GOTO Retry
	CASE 4 "No answer" GOTO Next_number
/* Allow for a default exit in the event of no match being found            */
	CASE DEFAULT GOTO Exit
/* Perform the ON command using the case statement built from the elements  */
	ON CASE

Any comments or interest for something like this?

Dick

I have extended v2.6 to recognize when it has been started via a project icon
and utilize the corresponding project file as its init file.  This makes it
possible to easily have different init files for high and low res or whatever
and invoke them from the workbench.  It also lets you keep the executable in C:.

Is this of general interest?

	Paul

Yes!

re:	.29

Please send me the "diffs" and I'll include it in the next version.

thanks!
dave

V2.7 by Tony Sumrall (acs@amdahl) is now available in:

	cookie::disk$gz_2:[wecker.amiga]vt100_27.shar

He has done some real nice additions, and the code is PD since it wasn't done
at DEC.

Enjoy!
dave


P.S. I'm using it right now and it works fine.

    2.7.... Where's the sources?  		--The Smokey guy
    

re:	.33

They haven't arrived yet (like I said I didn't do this version). I will post
them as soon as they show up.

dave

re: last 3,
I don't understand the conversation.  Aren't all the sources
in the vt100_27.shar file on Dave's machine?

    The VT100_27.shar file that I copied from Dave's machine contains
    only three files:
    
    	README
    	vt100.doc
    	vt100.uue
    
    Someday I would like to hack on VT100 to add a CASE statement
    so I could write a modem error handling init file.  Other folks
    have had this idea. so someone may get to it before I do.  The
    sources for V2.7 may be available someday on Dave's machine, as
    he said earlier.
    
    regards,
    -jim