Conference hydra::amiga_v1

    There are some bugs in X0.1.  You might not want to use it if you
    have to use parity.  Even and Odd parity will not work properly
    and cause funny things to happen.
    
    I have added a VT52 parser tonight and will make sure it is in the
    next version (X0.2).  The vt52 parser will enable you to play games
    that use vt52 esc sequences.
    
    If you have any neat ideas or comments, please send 'em to me. 
    
    Thanks to all of those who have been sending me comments!
    
    		--Mike

    How about a sizing gadget - I like to be able to log-in monitor
    while doing other things. A sizing gadget would allow using interlace
    with 24 lines on the lower half of the screen and a local program
    on the upper half.
    
    Paul

    This may sound kinda cludgey, but what about using the amiga
    mouse....The kludgey way, perhaps the only way, would be upon
    pressing a mouse button, move the cursor to the location of
    the mouse...Send an x,y cursor positioning command???  Does
    this sound ugly??
    
    brad

    The WTP (Wombat Terminal Program) in public domian uses the mouse
    in it's VT100 Emulator.  You might want to take a look at how it
    is handled there.  You just point and click and like magic, that's
    where your cursor is.
    
    Randy
    

    First let me say that I like the improvements you have made.  The
    extended character sets alone have made it worth using.  I'm not sure
    I have the absolute latest version so please keep that in mind...
        
    There are two things I don't like about the new transfer window:
    
      1.  I don't think it should exist until the first time I try to
          do a file transfer.  Give it a close gadget so that if I want
          to close it after the transfer then I can.  At the start of
          a file transfer simply check to see if the window exists.
          If it does, then use it, otherwise create one.
    
      2.  Why is there a menu option to send this to the back when we
          have gadgets on the window?  (I realize the old version kept
          this window in front during all file transfers.)  If I want
          that window to stay in front then I'll click on the front
          gadget.  The only time I think the window should send itself
          to the front is when a file transfer starts or ends.

    I posted this here rather than mail you, because I thought others
    may not agree and they should be heard.
        
    regards,
    
    steve mcafee

    Yes, that File Transfer Window seems to get in the way at the
    completion of the transfer. It would be nice if it would go away
    rather than requiring a CLICK to BACK and then a CLICK to the Main
    Screen to get back to work.
    
    The other thing that gets in the way for me is having to click the
    DONE gadget on any of the Transfer windows. Personally, I like to
    have my term log off after completing a file transfer in my absence.
    Having to click a DONE gadget inhibits the process.
    
    Paul

      --1.  I don't think it should exist until the first time I try to
      --    do a file transfer.  Give it a close gadget so that if I want
      --   to close it after the transfer then I can.  At the start of
      --    a file transfer simply check to see if the window exists.
      --    If it does, then use it, otherwise create one.
     If I add a close gadget, then I will have to add some sort of backing
    store for that window so that you won't lose the text in it.  I
    don't have the patience or time to do that.  If I do add a close
    gadget, people will have to be content with it losing the information
    in the window.  Is that ok?
      
    --  2.  Why is there a menu option to send this to the back when we
    --      have gadgets on the window?  (I realize the old version kept
    --      this window in front during all file transfers.)  If I want
    --      that window to stay in front then I'll click on the front
    --      gadget.  The only time I think the window should send itself
    --      to the front is when a file transfer starts or ends.
    	Is is simply a convenience.  If you have your terminal window in
    workbench, and you also have many other windows such as an editor and
    a cli, AND the log window is hidden behind those windows, AND you
    want the log window, you would have to hit the back gadgets on every
    window except the log window.
    	It also allows an easy way to get the log window in the front
    or back without selected it or deselecting any other windows.  I
    will modify this someday so that when you do use the gadgets on
    the log window, it won't select it.
    
    		--Mike

    --The other thing that gets in the way for me is having to click the
    --DONE gadget on any of the Transfer windows. Personally, I like to
    --have my term log off after completing a file transfer in my absence.
    --Having to click a DONE gadget inhibits the process.
    	The log window no longer (since X0.0) inhibits input to the
    terminal.  The ESC key will now work to stop transfers, and you
    can also type when it is finished.  If you make a script file to
    do a transfer and then log off the machine when the tranfer is done,
    it will no longer need a Human to press the "DONE" gadget.
    
    	--Mike

    --    The WTP (Wombat Terminal Program) in public domian uses the mouse
    --in it's VT100 Emulator.  You might want to take a look at how it
    --is handled there.  You just point and click and like magic, that's
    --where your cursor is.
    	Does WTP use the ANSI locator reports?  I believe the DEC level
    3 terminals have the ability to have some sort of locator such as
    a mouse, tablet, or other x,y cartesian device.
    	If WTP just moves the cursor to that pointer position without
    telling the host, then it become useles...
    
    		--Mike

I don't know which version I was using, (about 2 nights ago);
but I lacked documentation and wound up with an interlaced screen/window.
I really wanted a non-interlaced, regular 24-line window.
How about a gadget for toggling interlace mode?

Dave

    You can have interlace on or off in your VT200.init file.

    How about allowing resizing but carrying a full logical screen (24x80
    or 24x132) and scroll bars?

	Paul

	RE: 10, 11, 12
    
    I think I stated somewhere in the release notes that the current
    implementation of Smokey does not have a display list.  A display
    list is some sort of structure that remembers every character on
    the screen and the attributes of that character.  The attributes
    would be things like the font and graphics rendition.  I do support
    a line table though; a line table has information about line width
    and font information (top, bottom, double width, and normal).  Since
    there is no display list, it is impossible to have selective erase,
    resize, scroll bars, and other similar features without losing the
    information on the screen.  For Example, if you have a workstation
    that runs the UIS windowing system, you probably have noticed that
    the windows remember the information on the screen after a resize
    operation.  I will not be adding a display list because it would
    mean a total rewrite of all of the routines dealing with the output.
    I already had to do an almost total rewrite when I added the line
    table.  That was enough.
    	That note aside, here are some things I can do without the display
    list.  I will probably add some sort of way to iconify a window.
    You will be able to iconify the terminal window and the file transfer
    window.  I was thinking it would be nice if when you iconified the
    file transfer window, there would be two ways to get the window
    back.  ONe way would be to click on the icon, and the other would
    be click on a gadget in the title bar of the terminal window.
    	The icons will work like windows as far as depth is concerned.
     YOu will be able to bring the icons to the front by pushing other
    windows back and vice versa.
    	I've also received comments (and even some code suggestions)
    to make project icons.  A project icon when clicked would automatically
    start the terminal emulator and make it read an initialization file
    associated with the icon.  This would make it useful if you log
    into different systems.  YOu could have one icon named "VMS" and
    another named "ULTRIX."  The VMS icon would start up the emulator
    with a word length of 8 and no parity.  THe Ultrix icon would start
    with 7 word length and even parity.  I will add user control so
    they can set up the emulator the way they want it, and then through
    a menu save the icon.  Some of this stuff won't happen for a while
    yet, but I am still thinking about it and do plan on doing it. 
    	I would greatly appreciate any comments on the stuff I have
    just proposed.  Post them here so that others can argue with you.
    As I've said before, I will stop working on this when I go back
    to school, so please don't try and get me to do any outrageous coding.
    Remember, I am not Leo Schwab :->
    
    		--Mike
    
    

    Re: WTP
    
    The mouse does communicate with the host, but I do not know how.
    All I know is that it does work.  WTP also uses speech.  You can
    set it up so that it will give you verbal responses.  Instead of
    the bell, it will say 'attention!"  I wound up turning that option
    off.  You and also select screen flash and/or audio tone for the bell.
                                              
    You should get a copy of it from PeopleLink, or somewhere else.
    I comes packaged with the source code.  Maybe you could get some
    clues from that.
    
    Randy
    

    	re. .14
    
    	Can't the terminal emulator just translate the mouse coordinates,
    at the time the button is pressed, into screen coordinates for the
    VT2xx, and then the terminal program could send an absolute positioning
    command (I am assuming the vt2xx has one, I believe the vt100 series
    did) for the cursor like gotoxy or some such??  Seems to me that
    this would be the easiest way to do it..Perhaps not the most elegant
    but probably the easiest??
    
    brad

    Although the VT100 and VT200 have absolute positioning commands
    they never send them, they only receive them.  Thus, programs are
    not prepared to receive an absolute positioning command from the
    keyboard.
    
    There have been some extensions made to the VT200 escape sequences
    to support the mouse on VAXstations.  Some programs have learned
    how to deal with those extensions.  If possible, the Amiga emulator
    should use those same escape sequences, for compatibility with such
    programs.
        John Sauter

    I think all of your are trying to refer to locator support which
    really only exists for the VT3?? terminals.  You can get a
    VT330/34?/320 with a mouse or other xy device.  I don't know what
    host software supports this stuff yet.  Does anyone know of any
    software that supports a mouse.  If There is a lot of support, I
    could easily add locator support.  The only problem is that Smokey
    would still have to respond as a vt2?? device.  The extra code to
    make it act like a vt3?? would take me at least two weeks.
    
    Mike

    re .17
    
    I'm not quite sure what you mean by mouse control (is there some
    DEC standard mouse convention?) but I would like to see a click
    of the mouse turned into the appropriate sequence of arrow keys
    to get the cursor to the right spot. That could be wonderful for
    editing!
    
    dov

    It was my understanding that the VT300-class terminals only support
    the mouse in Regis mode.  The emulators (some of them, anyway)
    have defined and implemented mouse support in text mode, and software
    is starting to be written which uses the mouse by means of this
    interface.
        John Sauter

    >>     I'm not quite sure what you mean by mouse control (is there some
    >>DEC standard mouse convention?) but I would like to see a click
    >>of the mouse turned into the appropriate sequence of arrow keys
    >>to get the cursor to the right spot. That could be wonderful for
    >>editing!
           Yes, there is a DEC standard for "mouse" stuff.
    I don't think sending multiple arrow keys presses to imitate a mouse
    poisition is appropriate.  The only editor it would probably work
    with is EDT.  In TPU or EMACs or other editors, I always use more
    than one buffer.  This would make the arrow keys stuff sloppy.
    

Re: .20

For what is it is worth, about four years ago there was an experimental
bit mapped terminal developed in Hudson that changed sequences of mouse
movements into arrow key combinations.

    re: .21
    
    What were the results of the experiment?  Did people complain about
    the mouse sending garbage?
    
    

Re: .22

Well, I think that there was only one prototype built.  The entire project
was a one man type of affair.  I think that the guy who designed, built, and
used the system thought it was a good idea :-).

By the way, the engine in that terminal was a 68000.

    Version X0.2 is in VIDEO::USER$7:[LEIBOW.VT200]VT200.ARC.
    
    I have added a vt52 parser for you game players.
    
    I have fixed several bugs.  I have fixed the communications bugs.
    Parity now works, and the user interface will not let you select
    invalid settings.  For example,  you cannot select 2 stop bits when
    you have a word length of 8.  I have fixed some other things that
    caused the amiga to crash either during or after smokey exited.
    I have fixed some memory bugs.  It used to eat memory like Charlie
    Brown's Kite Eating Tree.
    

Mike,

   The terminal in question was the "Pixette".  "They" (Eastern Research
Lab in HLO-2) made about 60 of them.  You (Mike) can find one in my Parker
Street office, around the corner from your own.  I will hunt you down next
time I am around PK and show it to you.

In the Pixette, the mouse sequences may be defined by the host, with arrow
key emulation being a special case.

From my experience with the Pixette, the "arrow-key" feature for the mouse
is a good thing to have for hacker-types, but it can cause some undesirable
behavior.  (It is on my list of things to add to "Whack", my multi-session
VT300 emulator for the Atari-ST.)  The "arrow-key" mode is good for command
line editing on VMS, as well as for EDT.  You can get into truoble, however,
with applications that are upset by you hitting uparrow or downarrow
too many times, or by applications that will interpret each keystroke as
an invalid command, and print an error message.  Hitting the mouse button
at the wrong time can cost you a long wait while the computer prints
out "no further commands to recall" and then repaints the screen
sixty-four times.

Real mousing requires the sequences used by the VSII, and proper application
support (I have a package for VAX Emacs and dgc's Microemacs, others exists
for TPU.)  Since applications are responsible for enabling the mouse
sequences, ARROW-KEY mode and VSII mode can live quite happily in the
same emulator.

		Happy hacking,

<I'd still like to see a menu option for toggling interlace,
 If setting things in the .init file was good enough, then we wouldn't
 need menus for baud,bits, etc...>

Another request:

  VT100 didn't always to this, but started around v2.4 (I think).
  I have always found it useful to terminate the terminal program,
  without losing my line.  (read, *PLEASE* don't automatically hang it up)

  I like to be able to do this so that I can change terminal programs,
  reset options (like those only settable from init files.. ahem)
  get new preferences colors, on my terminal screen, etc.


Dave

>> <I'd still like to see a menu option for toggling interlace,
>>  If setting things in the .init file was good enough, then we wouldn't
>>  need menus for baud,bits, etc...>
    This could be done.  The menu option would have to be disabled unless
    you have a custom screen, or interlace on in the workbench screen.
    
>> Another request:
>>
>>   VT100 didn't always to this, but started around v2.4 (I think).
>>   I have always found it useful to terminate the terminal program,
>>   without losing my line.  (read, *PLEASE* don't automatically hang it up)
>>
>>   I like to be able to do this so that I can change terminal programs,
>>  reset options (like those only settable from init files.. ahem)
>>  get new preferences colors, on my terminal screen, etc.
>>
	I have hacked my modem to ignore the DTR signal from the computer.
    Therefore, my modem never hangs up.  Question:  Does Smokey make
    your modem hang up upon exit?  I have not changed any of the modem
    control code on purpose.  If this stuff acts differently from Vt100
    2.6, then I made the change by mistake and I will fix it.  Could
    someone tell me how their Smokey acts?
    
    Thanks
    
    Mike

    Could someone please mail me the sources for kermit.c from DBW 2.4?
    I would like to see something from way back very much.
    
    To bad I just cant tell Sherman to set the Way Back machine ...
    
    		--Mike

    Although there have been no major changes, there is a new version
    of Smokey in my directory.  I will not be posting another update
    for a couple of weeks.  This one should be pretty bug free.  In
    this new version, the parser menu is more complete.  Anyhow, to
    make this sound more official ...:
    
    Version X0.3 of Smokey the VT200 terminal emulator is available
    now in VIDEO::USER$7:[LEIBOW.VT200]VT200.ARC.  This archive contains
    the executable, readme, vt200.doc, fonts, and fonts.com.  After
    you unarchive all of the files onto a bootable workbench diskette,
    type "Execute fonts.com" and it will put all of the fonts into the
    FONTS: directory.  If you already have the fonts from X0.?, then
    you don't have to do install the fonts again.  Once the fonts are
    copied into the FONTS: directory, you can remove all of the files
    with an _8 attached, and all of the .font files.  (14 files).  The
    only files that should be left in the current directory shoould
    be read.me, vt200.doc, and vt200.
    
    Please mail or post your comments!
    
    							--Mike Leibow

In answer to a recent reply:

I don't have the latest version,
but the smokey version I do have DOES hang up the modem when
I hit the close gadget.

My microvax is where I do all my work, and it doesn't take
disconnects very well (frequently requires a reboot),
so I always have to be careful to log out before terminating the
terminal program, or I won't be able to dial in again until I reboot the
machine.

Thanks,
Dave

Did I see this request somewhere?  (I coudn't find it.)

Need some way to stop KERMIT once it is started.  Last nite I started pulling
vt200 v0.2, and almost immediately realized I wasn't in image mode.  The only
way I could find to stop it was to manually disconnect the modem.

Have I overlooked something?

	Paul

       
       re: .31
       
       An abort Kermit command.
       
       That one has my vote for feature I would most like to see.  On too
       many occassions I have started a long session of down loading only
       to find that I forgot to direct the output to DF1:, with DF0:
       already 96% full.  After pressing CTRL everything, the only way
       out has been to reboot.  Thank goodness my modem gracefully
       disconnects so I can start again without major surgery.
       
       Art
       

    I've been using the escape key.  Try it.  If it doesn't work, mail
    me somethin describing how your emulator was set up.  I'll try and
    reconstruct the error.
    
    Also,
    Art Gosling brought to my attention that some of the arguments to
    the commands in the script files don't work.  The reason is because
    there are extra characters after the argument.  For example,
    
    	SMOOTHSCROLL	OFF	# blah blah blah
    
    Won't work, but
    
    	SMOOTHSCROLL	OFF
    
    will work.  THis will be fixed for X0.4.
    
    

    Yet another one...
    
    This new version contains several new options.
    	o  Display Controls font
    	o  ICONIFICATION!!!
    	o  ICONIFICATION!!!
    
    There are still a few bugs, but I am working desperately on them.
    One of them happens somewhere in a script file while the window
    is iconified.  All I can say, is don't iconify during a script file
    unless you want to visit your guru.
    There is a font bug.  SOmetimes the line drawing font is selected
    when it shouldn't be.  I don't know why this happens yet, but will
    probably never happen to you.  If you actually want to see this
    bug, then login to VIDEO:: with the user name DEMO and select the
    VT220 demo.
    	The demo sometimes uses 132 column mode, but if your auto wrap
    is OFF, you'll just get some garbage at the right column.
    
    Oh well, enough with the warnings and garbage, here is the stuff:
    
        Version X0.4 of Smokey the VT200 terminal emulator is available
    now in VIDEO::USER$7:[LEIBOW.VT200]VT200.ARC.  This archive contains
    the executable, readme, vt200.doc, fonts, and fonts.com.  After
    you unarchive all of the files onto a bootable workbench diskette,
    type "Execute fonts.com" and it will put all of the fonts into the
    FONTS: directory.  Once the fonts are copied into the FONTS:
    directory, you can remove all of the files with an _8 attached,
    and all of the .font files.  (16 files).  The only files that should
    be left in the current directory should be read.me, vt200.doc, and vt200.
    
    Please mail or post your comments!
    
    							--Mike Leibow
    

    What is iconification?
    
    

    What is iconification?
    
    	If you have a vax workstation with the UIS terminal emulator,
    look at that.
    
    	Iconification is a word that is making its way into the
    comuter-english language that means turn your window into an icon.
    
    	--Mike

    I've been using the latest version of VT2?? and am very happy with
    it.  Good job.
    
    Here is a suggestion though...and I think someone pointed it out
    earlier.  It would be nice if when a script is completed that no
    action has to be taken.  Currently, a requestor appears and you
    have to click on it to go away.  Perhaps the requestor could appear
    long enough to notify you that the script is completed, and then
    go away automatically.
    
    It would be nice if the iconification could be selected by a gadget
    instead of a pull down menu.  I'm still a little confused about
    iconification.  When selected, the window closes and is replaced
    by a small gadget.  Is the program still running uninterupted? 
    If this is the case, it is a nice feature...but would be made even
    nicer if there was a simple on screen gadget to select it.  Just
    a thought.
    
    If the script requestor can't be eliminated, perhaps it could be
    located in a different position.  How about this:  position the
    the requestor so that the 'done' gadget on the requestor is in the
    same screen position as the 'execute script' line on the pull down
    menu.  It would save an additional mouse movement later (not a very
    big deal, but a timesaver).
    
    Being able to select 'Depth' from a menu would be useful.  You could
    leave it at one for most use, then select 3 when a sixel file is
    to be displayed.  On screen selection of screen colors would be
    nice too.  (I think that someone mentioned using a utility that
    comes with Grabbit to do this).
    
    Last, but not least:  How about a simple graphic display of the
    keyboard map?  By hitting Shift Help or something like that, a numeric
    and special function keyboard diagram could be displayed, showing
    how the keys are assigned.  This would be a tremendous help for
    all of us A1000 users.  It would be created the same way it is created
    in software packages: using the line drawing character set to outline
    the keys.  There are several times I could use this.  How about
    it?
    
    Other than that, you have done a very good job.  Keep up the good
    work.
    
    	Randy
     

>    I've been using the latest version of VT2?? and am very happy with
>    it.  Good job.
Thanks!    
>    Here is a suggestion though...and I think someone pointed it out
>    earlier.  It would be nice if when a script is completed that no
>    action has to be taken.  Currently, a requestor appears and you
>    have to click on it to go away.  Perhaps the requestor could appear
>    long enough to notify you that the script is completed, and then
>    go away automatically.
This could be put in a log window?  Anyone else think this would be
    advantageous?    
>    It would be nice if the iconification could be selected by a gadget
>    instead of a pull down menu.  I'm still a little confused about
>    iconification.  When selected, the window closes and is replaced
>    by a small gadget.  Is the program still running uninterupted? 
>    If this is the case, it is a nice feature...but would be made even
>    nicer if there was a simple on screen gadget to select it.  Just
>    a thought.
Yeah, would be nice.    
>    If the script requestor can't be eliminated, perhaps it could be
>    located in a different position.  How about this:  position the
>    the requestor so that the 'done' gadget on the requestor is in the
>    same screen position as the 'execute script' line on the pull down
>    menu.  It would save an additional mouse movement later (not a very
>    big deal, but a timesaver).
This is software.  OF COURSE IT CAN BE CHANGED :->    
>    Being able to select 'Depth' from a menu would be useful.  You could
>    leave it at one for most use, then select 3 when a sixel file is
>    to be displayed.  On screen selection of screen colors would be
>    nice too.  (I think that someone mentioned using a utility that
>    comes with Grabbit to do this).
GREAT IDEA.  I will add this when I get home this evening.    
>    Last, but not least:  How about a simple graphic display of the
>    keyboard map?  By hitting Shift Help or something like that, a numeric
>    and special function keyboard diagram could be displayed, showing
>    how the keys are assigned.  This would be a tremendous help for
>    all of us A1000 users.  It would be created the same way it is created
>    in software packages: using the line drawing character set to outline
>    the keys.  There are several times I could use this.  How about
>    it?
This is something that I will probably add when I get into the V1.?
    range.  I will break out of the X0.? range when I stop makeing
    absolutely huge changes to the code.  Right now, I am working on
    making the code re-entrant.  I have already modularized it and broke
    it into many files.  By Monday, It will look nothing like the DBW
    VT100 code that it came from.
    
When it is re-entrant, I will add some sort of session manager.  I have
    given up the idea of multiple sessions from the serial.device since
    I can't get the information I need on how to write a driver.  I
    will make the terminal emulator handle the sessions instead of the
    serial driver.  I don't think this will be finished until sometime
    in november.
    
    	--Mike       
    Other than that, you have done a very good job.  Keep up the good
    work.
    
    	Randy
     

    Sounds like you have a lot to do before Thanksgiving.
    
    Plenty for us to be grateful for when that day rolls around.
    
    	Randy
    

re: .37

I like the iconify option in the menu, where (I believe)
it belongs.  Just my 2 zorkmids worth. (Gee, IBM keyboards
have cent signs... [3270's anyway])

Dave

Re: The annoying "Script Done" requester.

One alternative to putting up the requester would be to set the Screen/Window
title to "VT200 Script Done" until the next keyboard input or menu selection.

This is in keeping with the way the Workbench reports errors and displays
the output of its version menu item.

    I like the idea of putting nonsense requester messages in the title
    bar.  I think I will do it that way.  The message will disappear
    when there is keyboard or menu input (as suggested in .41).
    
    If I forgot to mention it before, the window can be iconified as
    long as no local system stuff is being done (such as file xfers
    or scripts).  While iconified, all stuff coming in through the serial
    port stills goes through the ANSI parser and gets stuffed in the
    display list.  In other words, no information is lost.
    
    	--Mike
    
    PS.  eventually I will fix the event handlers to let you iconify
    whenever you want.  Right now, the script, and file xfer stuff does
    its own event handling and doesn't work the way it should.

    Before you start making changes, how about one more (and one
    more, and one more, and... %-) - Sometimes I like to have an
    interlaced screen, sometimes not, sometimes 3 planes, other
    times 2, maybe 1200bps, maybe 2400, and so forth. Some of
    these options are menu-selectable, but others are settable
    only from scripts. I don't like having umpteen scripts
    lying around my boot disk, or having to edit my config each
    time I use Smokey, so how about:
    
    % vt200 -b1200 -i -d3
        ^      ^    ^  ^
        |      |    |  +-- 3 planes deep
        |      |    +----- interlace ON (how to make it off though?)
        |      +---------- 1200 baud
        +----------------- Accept no substitutes
    
    Priority path would run: 
    		1) Command line arguments take absolute precedence.
    		2) Init file for stuff not in command line
    		3) Hardwired defaults for anything else.
    
    Sound useful? It's the way VT100 used to be, except for the
    init file stuff. Dunno why Dave removed command line options.
    
    And of course, good work Mike. One helluva package.
    
    .E

    How are chances of getting the A500/A2000 keyboard supported?  I just
    got my 2000, and now I'm going bonkers doing double key translations in
    my head.  (NEXT NOTE - thats the comma above enter on the real vt200;
    but its moved to the minus to the left of enter on the 1000; but now
    minus is two up from enter on the 2000.  Also, now that the PF keys are
    there I keep reaching for them, but they don't work.)  I guess I will
    eventually learn to type on this thing, but I am going to have
    scrambled brain for awhile.

    If you have better things to do, if you can provide sources I will try
    to take a look at what is required.  Does anybody know where the codes
    for the new keys are defined?

	Paul

    	New stuff:
    		Text Blink Attribute
    		Depth control from menu
    		Interlace control from menu
    
    	Bug Fixes:
    		Colors with various depths
    		graphic renditions fix (Font changes used to be delayed)
    		other various quirks fixed
    
    	New Bugs (technical):
    		AbortIO() for timers doesn't seem to work correctly.
     		Since I am using one timer for text blink and for cursor
    		blink, there can be trouble when an AbortIO() is followed
    		immediately by a sendIO() using the same request block.
    		The only way this can happen is if cursor blink is disabled
    		and text_blink is turned off and then on before one
    		unit of blink time.  So, If you are going to use an
    		application that maybe blinking stuff clearing the screen
    		and blinking stuff rapidly, then make sure your cursor
    		blink is on.  I will try and talk to Commodore soon
    		to see if there is a workaround.
    
         Version X0.5 of Smokey the VT200 terminal emulator is available
    now in VIDEO::USER$7:[LEIBOW.VT200]VT200.ARC.  This archive contains
    the executable, readme, vt200.doc, fonts, and fonts.com.  After
    you unarchive all of the files onto a bootable workbench diskette,
    type "Execute fonts.com" and it will put all of the fonts into the
    FONTS: directory.  Once the fonts are copied into the FONTS:
    directory, you can remove all of the files with an _8 attached,
    and all of the .font files.  (16 files).  The only files that should
    be left in the current directory should be read.me, vt200.doc, and vt200.
    
    Please mail or post your comments!
    
    							--Mike Leibow

    

    A couple of requests:
    
    First, could you bind SHIFT-down arrow to page down, SHIFT-up arrow
    to page up? It's so much more logical! (You can leave the other
    bindings for compatibility.)
    
    Second, how about combining init and script files? Why not be able
    to start up with a script (like login to work), or set attributes in
    a script (like set screen to interlace)
    
    That's all I can think of, which is a good commentary on the quality
    of VT200!
    
    dov

    
    re: .45  (starting up with a script at login).
    
    You can do this by placing:
    
    exit script-file-name
    
    at the end of your VT200 init file.
    
    regards,
    
    steve mcafee

>        First, could you bind SHIFT-down arrow to page down, SHIFT-up arrow
>    to page up? It's so much more logical! (You can leave the other
>    bindings for compatibility.)

    Forgive me if I ask a dumb question but I haven't slept in a while:
    What does the previous question mean?  More logical than what? what
    other bindings?
    
    		--Mike

    Sorry for the confusion. I just don't like the way the A-1000 keys
    are transformed into LK01 keys. I'd like to see the following
    additions:
    
    SHIFT-up arrow (on the Amiga) --> Prev Screen
    SHIFT-down arrow		  --> Next Screen
    SHIFT-left arrow		  --> ^H (goto beginning of line?)
    SHIFT-right arrow		  --> ^E (goto end of line)
    
    for that matter, why not provide a facility for key (and maybe mouse
    event?) binding. Then if I don't like the letter q, i can reuse
    that key for some more useful purpose ;-)
    
    ie
    
    DEFINE KEY q "^Mxyzzy^M"
    
    dov

    Please ..... One resizing gadget needed!!!!

    Second that motion!
    
    dov

    
    re: .45,
    
    Mike about you problem in AbortIO'ing a time request, (which can
    lead to a guru) this is the only way I have found to cleanly abort
    a timer request. Seems that aborting the request does not clear
    the sigbit, as it does with other devices so you just need to add
    a Wait() as follows:
    
    	    AbortIO(Timer);
    	    WaitIO(Timer);
    	    Wait (1L << Timer_Port->mp_SigBit); /* this needed for timer*/
    
    hope this helps.
    
    Steve Drew.
        

    RE: .52
    	If I have to wait on the timer, then people will get this ugly
    one half to one second delay whenever my code decides nothing on
    the screen has to blink anymore.  OF course, at low speeds (< 4800)
    the output will catch up almost immediately.  I will add the waits
    to my aborts in the next version.  I will post the new version tonight
    becase I think it is a kind of drastic bug, and I would like to
    fix it.
    
    RE: Resize
    	If I add resize, I gotta add scroll bars.  I don't wanna mess
    with super bitmaps.  Therefore, I don't wanna mess with scroll bars,
    therefore I don't wanna mess with resize.  ALTHOUGH, I did add
    interlace control in the menu which will resize your terminal between
    48 and 24 lines.  This is a DEC non-conforming resize because it
    doesn't clear the display.
    
    RE: Lots of other requests (keyboard stuff)
    	----BIG MOUTH ON----
    	I have been trying to implement a half way decent VT220 emulator
    that will follow the DEC STD 070 Video Standard Reference Manual
    to an adequate degree.  I haven't read the thing fully, but what
    I have read, I have tried to implement.  For some reason, I don't
    know why, but I don't want to add to many non DEC things to this
    terminal emulator.
    	----BIG MOUTH OFF----
    
    When I actually do start doing non DEC things, I want to make a
    bundled package something like this:
    	1) A terminal that works specifically with:
    		A) Proportionally spaced client software
    		B) No idea of character cells.  Everything is
    			in pixels, rasters, and other graphic
    			elements.
    		C) more rectangular operations and less "left-to-right"
    		   and "scroll-upward"
    		D) Special word processors or editors
    		E) games!
    	2) .... Still thinking.....
    
    	I still have to find out what ANSI has specified about this
    kind of stuff.  I would like the new terminal to be designed for
    a multisession windowing atmosphere.  My end goal, is to impress
    a need for terminals in the market place again with my new software.
    
    If the terminals can match the speed of our X Servers while going
    over a slow wire (~ 9600 baud) then I've gotton somewhere.
    
    Oh well,
    
    Maybe its just a big dream....
    
    
    --Mike

    RE: .53
    
    Mike, you don't have to wait on the timer the signal is already
    set from the AbortIO so the Wait mearly clears the signal up.
    
    Steve.
    

    Version X0.5+ of Smokey is available.  It has a fix for the blink
    bug (Thanks Steve).
    
    The whole package is in VIDEO::USER$7:[LEIBOW.VT200]VT200.ARC
    The executable is in    VIDEO::USER$7:[LEIBOW.VT200]VT200EXE.ARC
    
    The executable is the only different file so I stuck it in its own
    ARC file.
    
    	--Mike
    

    Thanks for giving us the EXE only version.  Downloading everything
    else was becoming a nuisance.
    
    Now, how about 3D graphics and a stereo sampled gong for the bell?
    
    	Randy
    

    The gong is easy...
    
    	Anyone want to help me do the animation for the bell?
    
    	--Mike
    
    PS: really!

    
    Smokey is really getting powerful.  I really like iconification!
    
    Couple of things:
    
      What is the motivation for keeping the file transfer window around
       all the time?  Sometimes it can be a real nuisance.  Wouldn't it
       be better to create the window before the first transfer and give
       it a close gadget?  If I delete it after the first transfer then
       when I start the second transfer a new one could be opened.  If I
       don't delete it then the second transfer could continue using thesame window.
    
     Regarding the script termination requester:  How about a switch
      on the script "exit" command?  (e.g. "exit fast" for no requester)

    thanks for all your work,
    
    steve mcafee

    Oh please, would it be possible to beep the bell, sound a gong,
    or yell "Hey Bozo!" when a download is completed? I usually leave
    my machine going for a while and do something else, and I then
    have to keep monitoring it to see if the U/DL has completed. Since
    I use PopCLI, this means walking over to it and wiggling the mouse.
    How about it? Or is it already done in X0.6? You're coming out
    with new versions faster than I can complain about them! Come on,
    give us all a chance to moan & gripe!
    
    Ed_who_just_this_morning_was_going_to_bomplain_about_lack_of_blink,_
    sixel_problems_in_2_planes,_and_Odin_knows_what_else...until_Mike_
    beat_me_to_it_with_the_release_of_X0.5

    

    mike_who_can_not_help_but_stay_awake_nights_and_add_features_or_fix_bugs_
    in_a_terminal_emulator_named_Smokey__
    

    Perhaps you could add a menu selection that removes_underscores_from_
    replies_making_them_easier_to_read...
    
    I second the vote for the bell when a transfer is complete.  Other
    packages have them, and they are a real timesaver.
    
    	Randy
    

    Version X0.6 is available in VIDEO::USER$7:[LEIBOW.VT200]VT200.ARC
    or 							     VT200EXE.ARC.
    
    I have finally changed the script and file transfer useless requester
    messages.  Now, when you are in "script mode" or "file transfer
    mode," your pointer will be "SCPT" or "XFER"   When the script or
    file transfer operation is complete, the pointer will resume its
    normal shape, and the bell will ring twice.
    
    The bell can now be any sound that you want provided that you can
    get it in an IFF file.  Find your favorite sampled sound, and rename
    it to S:Bell.Sound.   When the terminal emulator starts up, it will
    try to read that file.  If it is successful, it will use that as
    the bell sound.  If is not successful, it will use a default bland
    sound.  If you specify no volume in the initialization file, then
    no attempt will be made to read the IFF file.             
    
    I put a SOUNDS.ARC file in the [.vt200] directory also.  It contains
    all of the sounds from the Missile Command game by Glen Meriman.
    (SP?).  These are the only sounds that I had access to, so they
    are the only  ones the emulator has been tested with so far.  My
    favorite bell sound is EXPLOSION.ARC.  It gets my attention.
    
    
    This is my last version.  I will not be making any more updates
    until I come back to work again.  I hope to come back next summer
    for 3 months.  My address at school is in the readme file.
    
    If there is a desperate need for a change to Smokey, I may do it
    before I leave, but only because it Gurus or something.
    
    Please don't let that stop you from sending my comments gripes
    questions or whatever.  I still would like to work on it in the
    future.
    
    Have fun...
               
    --Mike

    I brought my machine to work today.  I was wondering what kind of
    performance I could get with Smokey.  I am hooked up to our cluster
    (VIDEO::) at 9600 baud.  I have a program that can show my scrolled
    performance and non scrolled.
    
    Over a 9600 baud line:
    	SCROLLED:	960 CPS
    	NONSCROLLED:	960 CPS
    Both of these numbers were with jumpscroll and 1 bit plane.
    
    	--MIke

    We'll miss you !
    You've done a terrific work! I'm using Vt200 at 9600bps since 2/3
    weeks doing all you can immagine.
    It works like a charm !
    
    Please , before leaving, post somewhere ( or mail me) that tiny
    program to play IFF sampled sounds. I will appreciate a lot.
    
    If at the end of your study you'll ever think of coming to work
    to europe ( Italy ) gimme a call ... 
    
    marco

    Whoops!  I uploaded the arc files using text mode instead of image.
    If you copied X0.6 before 1300 EST then you have bad arcs.  Better
    copy em again.
    
    Sorry,
    
    Mike.

    Thank you for everything Mike.
    
    IFF sounds for a bell...I love it.  Imagine having the terminal
    sneeze!  
    
    
    In stereo!
    
    
    Wow!
    
    	Randy
    

Did you find someone to take over maintenance while you are gone?  If not, can
you make the sources available somewhere in case the need or desire arises?

	Many thanks for the fine work,
	Paul

    
    Yes, Mike please make the latest sources available before you go.
    Great job on the script and file transfer mouse pointers!
    Excellent idea!
    
    thanks for all your effort,
    
    steve mcafee

    I'm having some trouble using Smokey (thanks Mike) with PeopleLink
    which I didn't have when using VT100 v2.6. The terminal doesn't
    seem to do the line feed correctly and some characters are garbled.
    I used both VT100 and Smokey pretty much with the default parameters.
    Is there anything I should put in the .INIT to fix this? Thanks.
    
       mitch

    I have a similar problem on GEnie ... line feeds but no carriage
    return on some lines and a wierd checkerboard graphics character
    where you'd expect a blank space. May have something to do with
    using the 8-bit filter.

    Geez,
    
    Wish I could give more help.  I don't have accounts on either machines,
    but heres my guess:
    
    VT100 2.6 automatically chopped off the 8th bit on every incoming
    character.  Smokey will do that if you choose any parser other than
    VT200 8 BIT CONTROLS.
    
    If someone has a chance, could you try it with PARSER VT100 or PARSER
    VT200_7 and see what happens?
    
    Thanks,
    
    --MIke

    re .71:
    
    Your suggestion worked. It was fine with VT200 7 bit controls. Thanks.
    An enhancement for the future might be to add the WXmodem capability
    like one the Comm terminal program. It's significantly faster than
    XModem. I don't know if anyone besides PeopleLink uses it.
    
       mitch

Mike-

Have you given any thought to supporting the SSU (Sessions support
Utility) protocols?  Am I wrong in thinking that SSU can be done
over a phone line?  It would be great to have two windows at once
to work from home on!  I don't know much about the protocol, is
it limited to supporting only two windows?

I know you are leaving soon, but I thought this might be a good way
for me to start hacking on my machine again if you can leave the
sources for smokey behind.  I turned my amiga on for the first time since
marriage ceremony madness overtook my life early this year.

I am sure that having SSU hooks in smokey would really seal this off
from being released to the outside world :-)

-dave

� Have you given any thought to supporting the SSU (Sessions support
� Utility) protocols?
    
    Yes, but it is not called SSU.  SSU is the name of the VMS program
    that will switch your terminal driver so that you are speaking to
    a device that understands TD/SMP (Terminal Device/Session Management
    Protocol).
    
� ... Am I wrong in thinking that SSU can be done
� over a phone line?  It would be great to have two windows at once
� to work from home on!  I don't know much about the protocol, is
� it limited to supporting only two windows
    
      SSU can be done over any virtual wire.  The protocol will allow
    an 32768 sessions, but I don't think there are any implementations
    that can handle more than 10.
    
� I know you are leaving soon, but I thought this might be a good way
� for me to start hacking on my machine again if you can leave the
� sources for smokey behind.  I turned my amiga on for the first time since
� marriage ceremony madness overtook my life early this year.
� I am sure that having SSU hooks in smokey would really seal this off
� from being released to the outside world :-)
    
    My terminal emulator is already 100% private.  You should not let
    non DEC employees know about it.
    
    As far as implementing TD/SMP:  Since the Amiga is a multitasking
    machine, it would be much better to implement TD/SMP in the serial
    driver (serial.device).  If you do it in the driver, then you won't
    be limited to Smokey to multisessions.  You will be able to run
    ANY terminal emulator and have multiple sessions (providing you
    have enough memory).  I have made an attempt to put TD/SMP in Smokey,
    but I gave up after to days of trying to make the code re-entrant.
    Dave Weckers VT100 program used almost 100% global variables, thus
    making the code almost impossible to convert.
    
    I have asked again and again for sources or help with the serial
    driver, but no one has been able to help.  Therefore, I also think
    it would be very hard to rewrite the driver.  There is no documentation
    describing the internals of the serial driver.  If I was to make
    a compatible driver, I would have to do much guesswork.
    
    So, If I don't write a new driver, and I don't change Smokey, what
    is left?  Here is an idea:  How about making a seperate interface
    to the same driver.  When Smokey starts up, it will talk to the
    driver normally.  WHen the user (or host) tries to enable sessions,
    Smokey will automatically look for the other interface.  If it exists,
    it will start doing IO through the second interface.  Now, if the
    user wants a new session, all he has to do is start another Smokey
    task from CLI or from Workbench.  The Second Smokey before trying
    to open the terminal driver will search the system for a port called
    "SMOKEY TD/SMP."  If it finds the port, it will try and do IO through
    that port.  The interface at the other end of the port will then
    attempt to establish the new session.  If everything works ok, then
    the new smokey will be allowed to continue.  Otherwise it will be
    sent a reply saying "Can't handle another session."  If I implement
    it in this fashion, you should be able to get about 3 or 4 sessions
    on a 512K machine.  I estimate I will be able to get about 12 sessions
    on my 1.5M machine.
    
    Now that I've got that out of the way, I can tell you for sure that
    I won't have this completed before I go.  So, unless someone else
    is willing to put all of this effort in, it won't get done until
    next summer.
    
    I cannot release the sources of Smokey to this notesfile because there are
    non full-time employees and contracters who read this stuff.  Sorry.
    
    Look forward to a bastard version of TEK4014 in V1.0 coming soon
    to a network near you :->   (Anybody have any specs on Alpha mode?
    There doesn't seem to be a sufficient alpha mode.  Only line mode
    and point mode.)
    
    
    	--Mike

-dave

My VT220 implementaiton for the Atari ST includes support for multiple
sessions (10) in multiple windows (7) using SSU.  Mike has access to my
sources, but for various (good) reasons found starting with Dave's VT100
to be easier than working around the assumptions I made about the Atari's
GEM windowing system.  However, "Whack" stands as an existence proof that
TD/SMP is entirely practical over modem lines.

    New version (V1.0) in VIDEO::USER$7:[LEIBOW.VT200]VT200.ARC
    		      and VIDEO::USER$7:[LEIBOW.VT200]VT200EXE.ARC
    
    installation:
    * You MUST copy my program (if you want to) before Friday of next
    	week (Nov 20).  AFter that date, my account will no longer exist.
    
    *	If you use the VT200EXE.ARC file, then you will need to install
    the font "smokey" manually.
    	rename smokey.font FONTS:smokey.font
    	makedir FONTS:smokey
    	rename smokey_8 FONTS:smokey/8
    
    *  	if you use the VT200.ARC file, read an earlier note.
    
    Extras:
    	There is a half-assed version of Tektronix 4010 emulation included.
    Since I didn't have time to "SMOKEYIZE" it, you must open the screen
    manually from the menu bar.  (TEK401X-SCREEN-ON).  You can also
    set the paramaters from the menu.  (DEPTH, INTERLACE, and stuff).
    NExt year when I come back, unless somebody else has done it, I
    will have added ALPHA mode and the proper fonts.  I will also support
    "morerows", "PAL", and overscan graphics.  Thus, you will be able
    to have 25x84 displays and also have 132 column displays.  I will
    put the 132 colomn mode on a INIT switch so that if you don't want
    it, you won't have to load 9 more fonts.
    
    bugs:
    	DO NOT ICONIFY with the TEK screen open.  You must turn TEK
    off (OFF) before you iconify.

    	The SERIAL.DEVICE driver does real wierd things at 19200 baud
    and sometimes 9600 buad.  It will send 4 Xoff's   but never send
    an XON.  So, you might have to type CTRL Q when going at 19200 baud
    if things seem to lock up.
    
    fixes:
    	I emulate a "soft terminal reset" in a conforming way now. 
    A reset will not clear your screen like it used to.  It will, however,
    reset your parser and set your terminal to "a known state."  If
    you want to restore your terminal to the way it was when you first
    invoked it then you can do a HARD RESET from the UTILITY menu. 
    Also, DEC non-conforming software which sends an "ESC c" will do
    this hard reset instead of a soft reset.  If you are unfamiliar
    with a hard reset try this:  Take any DEC terminal and VMS system,
    and use your favorite editor to put an "ESC c" in a file.  Leave
    the editor and type the file using $ TYPE.  Your terminal will "spaz
    out" for a few moments while it resets.  Smokey now also "spazes
    out."  As noted in some manual somewhere, a hard reset (RIS) may
    cause a line drop.  So, if your modem senses DTR, then this will
    hang up your phone.  (I've used DEC software for three years, and
    have never seen a program send an "ESC c")
    
    MY DIRECTORY WILL BE WASTED NEXT WEEK.  If you want V1.0, you must
    get it from me before Friday 20.
    
    If you have problems or questions, after friday, I can be mailed
    to at DECWRL::"pyramid!ritcv!msl5864" or on BITNET at MSL5864@RITVAXC.
    
    I think I will start again next summer (June 1).  Thanks for being
    there to share my hobby :->.
    
    	--MIke

    Mike,
    
    Thanks for all of your work.  I understand your concern about releasing
    the sources.  Is there someone in your group at work who could hold
    them and be authorized to release them to certified DEC employees?
    (Perhaps Lomica.  Even though an atari freak, maybe we could trust him
    not to put bombs in the source.) 

	Paul

    Hi,
    
    I am going to delete everything in my account tomorrow 11/19/87.
    So, if you don't have V1.0 of Smokey, copy it.
    
    	--Mike

	Does someone have a copy of SMOKEY that they could
	upload for me; is it available somewhere on the
	net ?

	Thanks bunches,
	 Art

	"Bounded chaotic mixing produces strange stabilities..."

    PAULY"AMIGA"::VT200.ARC
    

>    PAULY"AMIGA"::VT200.ARC

	I ran a batch job last night to COPY this little sucker, and 
	it just sat -- no CPU's, no I/O's, no error msg's -- nothing...
	Is there a network problem over there or something ?

	-puzzled.

    I didn't see you on the LOG. I would guess something failed at your
    end. People download from PAULY"AMIGA":: every day.
    
    Paul

    Does anyone know what it would take to modify Smokey VT200 to map
    the new A500/2000 keyboard so that the keypad may be used like
    at VT style keyboard?    I guess its kind of hard to get used to
    pressing F1-4 instead of PF1-4.
    
    Thanks,
    Ira
    

I think my ignorance is showing....Could someone explain what a "sixel"
    file is?  
    
    Thanks in advance.
    Bob
     

SIXEL is a method of displaying/storing graphics.

A single SIXEL is actually 6 vertical Pixels on the screen. Thats why
when you type a SIXEL file (ie, a file containing SIXEL data) it gets painted
a thick line at a time (six pixels high).

I believe SIXEL mode is invoked via a REGIS command. Anyway, you can edit
a SIXEL file and look at the data. (although not very interesting) The
first few characters are actually an escape sequence to couse the terminal
to go into SIXEL mode. Then there are other escape sequences embedded
to set screen positions, next bit planes etc..


This si not a very technical description, but in general, thats what they are.

    
    
    	Sixel is the data format DEC printers use for graphic data in
    the  LA50/LA100/LN03...
    
    			Steve Peters
    

Sixel protocl and Regis protocol are both "Device Control Strings"
that are understood by some DEC terminals and printers.

Both are ways of transmitting graphical information to a device.  The Sixel
protocol is a way of sending raw bitmaps.  Data is presented as six vertical
pixels, to coincide with the orientation of a dot-matrix print head.  A sixel
pattern may be preceeded by a repeat count, which makes large areas of white
or black transmit quickly.  The data stream is encoded into printable
characters, so that it can be transmitted over lines that subject control
characters to other interpretations.

Regis is an almost-human-readable way of constructing a drawing out of lines,
curves, text, and filled areas.

No, you don't invoke Sixel mode with a Regis command, but one way in which
the two are related is that Regis contains a command that
will cause the contents of the screen to be transmitted to the host or
a printer as Sixels.

    
    Since this topic has come up...
    
    Anyone know where can I find a specification for color sixel?
    How many colors does it support?
    
    - steve mcafee

Color sixel can support a wide range of colors.

Sixels are defined, in some detail, in section 9 of DEC STD 70.  This chapter
of DEC STD 70 has just been elevated from yellow( preliminary) status to
full-fledged white paper.

You can obtain any DEC standard by calling "SMC" (Standards and Methods
Control) at 226-2482.

Section 9.8.1.3 covers color selection in Sixel protocol.  A conforming
implementation will allow a minimum of 255 color indicies.  If the device
cannot display 255 colors, it must fall-back colors that are out of range
into one of the colors that is has.  A device may support more than 255
colors.  A conforming application will assign color indicies starting
from 0 with no gaps.  You may assign a color to a color index in either
HLS or RGB coordinates.

RE: .83

>    Does anyone know what it would take to modify Smokey VT200 to map
>    the new A500/2000 keyboard so that the keypad may be used like
>    a VT style keyboard? 

	Yes, I know exactly what it would take, since I've just done it.

	AGNESI"AMIGA"::FOGGY.ARC  - The compleat kit, including all the files
				    from Smokey that are necessary, Mike's
				    doc file, my modified executable, and the
				    Read.Me file below.

	AGNESI"AMIGA"::FOGGYEXE.ARC - For current users of Smokey X1.0.
				      Includes the modified executable, and
				      the Read.Me file below.

Mark

-------------------------------------------------------------------------------
                        DIGITAL INTERNAL USE ONLY

     This file is a version of Mike Liebow's Smokey VT200 terminal emulator
that has been modified to work 'better' with the A500/A2000.  This is only
the executable, you will still need the fonts and documentation from his
original kit.  DO NOT USE THIS FILE ON AN A1000.  Several of the important
keys that you need are now mapped to keys that aren't on the A1000 keyboard.
Except as noted below, the documentation supplied in the original kit remains
in force.  I made these changes for my convienience, and decided others may
want them as well.  I am not taking over support for Smokey in general, and
will support these changes only on a time permitting basis.  Use this software
entirely at your own risk.  As with the original, this software is DIGITAL
INTERNAL USE ONLY.

Mark Eklof
26 January 1988

Changes:

The following keys have new meanings.

A500/A2000  VT200       Comments
==========  =====       ========
Keypad (    PF1         Formerly unmapped
Keypad )    PF2         Formerly unmapped
Keypad /    PF3         Formerly unmapped
Keypad *    PF4         Formerly unmapped
Keypad -    KP-         Used to be KP,
Keypad +    KP,         Formerly unmapped
Help        Help        Used to be KP-
Del         Do          Used to be Delete or Backspace.  Swap BS<->DEL no
                        longer has any effect.  (Use ^H for BS)
Backspace   Del         Used to be Backspace or Delete.
F1          Find        Used to be PF1
F2          Insert      Used to be PF2
F3          Remove      Used to be PF3
F4          Select      Used to be PF4
F5          Prev Scrn   Formerly unmapped
F6          Next Scrn   Used to be F 6
^F1         unmapped    Used to be Find
^F2         unmapped    Used to be Insert
^F3         unmapped    Used to be Remove
^F4         unmapped    Used to be Select
^F5         unmapped    Used to be Prev Screen
^F6         F 6         Used to be Next Screen
ESC         Hold Scrn   Used to be ESC (Use ^[ for escape).  This key still
                        should work to abort file transfers.  Pressing this
                        key once will stop scrolling, pressing it again will
                        continue.

	Let me be the first to thank and commend you for providing this
    modification to Smokey. I've had my fingers crossed (so to speak)
    since July.

    I'm using it now and it works *great*!
    
    Truely another asset for the DEC Amiga(2000/500) user community.
    
    Thanks again
    
    -bw
   
    

    Yo baby thats what I like!!!!
    
    ...ahem!  Sorry! I meant to say thanks ever so muchly!
    
    
    

Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
 Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
   Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
    Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
     Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
      Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
       Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
        Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
         Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!
          Thank you!  Thank you!  Thank you!  Thank you!  Thank you!  Thank you!

I can't wait to get home and try it out!!!
							...richard  

Re: .91-.93

	No problem, glad you like it.

	If anyone has comments or suggestions, please send them to me (or post
if you prefer).  I'm not making any promises, but if the idea sounds good, and
I can figure out how to do it, I may make the change.

Mark

I will add my thanks.  I have been dying for this.

Question:  Is there a way to send a BREAK from the keyboard?  I know I could
define one of the function keys to execute a script which contains an SB, but
that seems kind of extreme.  I normally use break to pop back to the LAT, rather
than giving up another real character for that function.

	Paul

Re: .95

	You're welcome.

>Question:  Is there a way to send a BREAK from the keyboard?

	Right-Amiga Dot (period), just like it says next to the Send Break
menu item.

Mark

    ...How about the source code????? Pretty please with whipped cream
    on top!!!!! 
    
    Whatayasay?
    

Re: .97

>    ...How about the source code????? Pretty please with whipped cream
>    on top!!!!! 

>    Whatayasay?

	My changes are fairly minor.  Most of the code is just as Mike left it.
	back in .74 Mike said...
    
>    I cannot release the sources of Smokey to this notesfile because there are
>    non full-time employees and contracters who read this stuff.  Sorry.

	I'm not entirely sure I follow the logic of this, however, I will honor
	Mike's wishes in the matter.  I really am sorry to have to say no.  If
	it's any solace, I do plan more improvements to (Smokey as well as)
	Foggy.

Mark

    Just a suggestion...
    
    Instead of spawning yet another editor version (Smokey, Foggy,
    whatever), why not just transform Foggy into  Smokey V1.1?  The
    changes/features you added were what most were looking for anyway.
    
    One product is a lot easier to control/maintain than two 8^) !!!
    
    -john-
    

    
    re: .99
    
    I think the reason he renamed it, is due to the fact that we
    A1000 owners don't have those numeric keypad keys.
    
    To be consistent I think you might want to add a startup switch:
    
      FKEYS	OLD/NEW		!  OLD for F1-F4.  NEW for Numeric
				!  keypad keys.
    
    regards,
    
    steve mcafee

    

All Right!  GOLD, Next Unseen at the touch of a key...




>      FKEYS	OLD/NEW		!  OLD for F1-F4.  NEW for Numeric
				!  keypad keys.

There ya go!

Re: last few...

	I don't consider it to be a separate entity from Smokey.  I hadn't
planned on changing the name at all.  I then visualised a note from a novice
in which Smokey wasn't working correctly ('the keys don't seem right').  I
wanted an easy way to tell the difference, so a change in the title bar was
called for.  I do plan to take my changes and incorporate them into the
original code using compile time conditionals.  This way, anything I add which
isn't system specific will be available to everyone.  One of the things planned
for RSN implementation is a compose key.  I've also got some changes to one of
the fonts to fix a few things.

>      FKEYS	OLD/NEW		!  OLD for F1-F4.  NEW for Numeric
				!  keypad keys.

	Well, the code isn't as nice as I'd like it in this area, and short of
a total re-write, there's a few things that have to be worked around.  I can
add that switch, and it would affect the funtion keys (F1-F10).  I can restore
them to their old values.  This is all it could affect though.  The keypad
would be unchanged.  Is there interest in this?

Mark
 

Re: .96

I thought I had seen it described somewhere!

I particularly like your conversion of the ESC key into Hold Screen.  Ctrl S/Q
just aren't reasonable in their raw form.  And I don't miss the ESC key at all.

As for additional suggestions, could you please add a few more keys to my
keyboard, to make it fully compatible with the LK201? :-)

	Paul

Re: .103

>I particularly like your conversion of the ESC key into Hold Screen.  Ctrl S/Q
>just aren't reasonable in their raw form.  And I don't miss the ESC key at all.

Unfortunately this feature will keep me from ever being able to use Foggy.
I use the escape key is very frequently (I use Emacs as my editor).  How
about some sort of init file switch that specifies to leave the escape
key alone?

Re: .104

>I use the escape key is very frequently (I use Emacs as my editor).  How
>about some sort of init file switch that specifies to leave the escape
>key alone?

	But...but...but...  :-)

	Actually, the VT200 doesn't have an escape key.  I figured (apparently
incorrectly) that nobody would miss it for that reason (I only use escape in
TECO, and then I find ^[ no problem).  Still, I suppose an init option (with
maybe a menu switch) would be the easiest way to make everyone happy.

Mark

Re: .105

>	But...but...but...  :-)
>
>	Actually, the VT200 doesn't have an escape key.  I figured (apparently
>incorrectly) that nobody would miss it for that reason ...

Before reply .104 goaded me to action, I had planned to enter a reply
asking, "Must you be bug-for-bug compatible with the real VT200?" :-)

    I find using the escape key for Hold Screen to be very convenient.
    I vote to keep it in.

    all of this should be CONFIGURABLE !!!  Why force many versions,
    etc.  The beauty of the script language/parser is that its EASY
    to allow flexability!  How would you like to be forced to have an
    interlace screen, or 300 baud!  Why not just extend the concept
    and make it more powerfull, not more restrictive!
    
    sorry for shouting, but I'm tired of seeing software that is
    closed-minded! 
    
    scott.
    

How do you get the 19200 and 38400 BAUD menu options to work?

Re: .109 

	What's wrong with them?

Not re: any particular note.


    Hi all.  At the bottom I've appended the read.me file from

    	AGNESI"AMIGA"::SMOKEY11.ARC .

    As you will soon see, Smokey and Foggy are now one in the same.  Since
there is now only one program, we only NEED one name.  I had, however,
become attached to the name Foggy.  Yet, Smokey has a stronger historical
claim.  I have therefore decided, quite capriciously, that odd numbered
releases will be called Smokey, and even numbered releases will be called 
Foggy.  I know this makes no sense, so if you feel you must argue the point,
please don't try to appeal to logic.  If I were inclined to listen to logical
arguments, I'd never have decided to do it this way in the first place.  But
then, my world view might be somewhat different after I've caught up on my
sleep.

    One thing I want to stress is that this arc does NOT contain the complete
package.  For now, you'll have to get that elsewhere if you don't have it
(if you're running X1.0 of either Smokey or Foggy, you've got everything that's
not in this ARC).  I'm also revising the documentation file, and will include
that in some future release (probably formatted for printing by your favourite
preferences printer).  Also, as mentioned elsewhere, a compose key is on the
list of things to do.

    Don't look for these things too soon.  I do have to get some real work
done.

Mark
-------------------------------------------------------------------------------

    This is X1.1 of the Smokey VT2xx terminal emulator.  It supersedes both
Smokey X1.0 and Foggy X1.0.  This archive contains the new executable, and
a new version of the Smokey font.  The new Smokey font is fully compatible
with the DEC Mulit-national character set, unlike the old version.  To
replace the old version, copy SMOKEY.FONT to FONTS:, and copy SMOKEY_8 to
8 in the font directory Smokey.

    The changes to the executable are summarised below.  As always, this is
for DIGITAL INTERNAL USE ONLY.

X1.1

Three new script/init commands have been added, along with corresponding
menu items.  They are...

A1000   ON/OFF  (default on)

    This tells Smokey if you have an A1000 keyboard, or (if off) and A500/
    A2000 keyboard.  If A1000 is ON, the keypad, function and help keys are
    the same as in Smokey X1.0.  If A1000 is OFF, the keypad and function
    and help keys function in a fashion simmilar to Foggy X1.0.  The
    differences are as follows:  VT2xx F11-F13 (used by VMS line editing)
    are now Amiga F7-F9.  I've moved VT2xx F7-F9 to SHIFT(F1-F3)  (where
    the keys that replaced them came from).

ESCAPE  ON/OFF  (default off)

    If this is OFF, the escape key acts as a HOLD SCREEN key.  That is to
    say that pressing it once pauses the output, and pressing it again
    releases the output.  If ON, the escape key sends an ESC (ascii 27.).

DOKEY   ON/OFF  (default on)

    If this is ON, the DEL key sends the escape sequence corresponding with
    the DO key on an LK201.  At this point, the SWAP BS<>DEL function makes
    no difference, and the BS key sends a DEL.  If OFF, however, DEL and BS
    send either DEL or BS depending on the state SWAP BS<>DEL.

    re: .110, fonts
    
    What was the change you made to the font files?  The Amiga (and the DEC
    VT300) uses the ISO Latin-1 character set.  If the old font file
    was Latin-1, and you changed it to DEC Multinational, I'd rather use
    the old font file.
        John Sauter

Re: .111

	Then you'd rather use the old one.  The old one was a standard
Amiga font, with the non-printables changed from boxes to backwards question
marks.  There are about ten characters that are different from the DEC
Multinational set, and I changed those to match.  I guess it's just part
of my continuing drive to be "bug for bug compatible" with the VT200. :-)
I've never used a VT300, so was not aware that the character set had changed.
I just knew that some of the characters I saw on my VT240 weren't the same
as the ones I saw on Smokey, so I 'fixed' it.

	In any event, don't sweat it.  If you want to use the new font, fine,
if not, that's fine too.  If you have a font you prefer, you can use that
instead.  As long as it finds a font called Smokey with an eight point file
on startup, the program doesn't care.

Mark

P. S.  After much sleep I've decided the changing the name between Smokey
and Foggy every release was a real dumb idea.

re .-1

> P. S.  After much sleep I've decided the changing the name between Smokey
> and Foggy every release was a real dumb idea.

See -- sleep IS important every now and then.  (Though it is hard when you
both work for DEC and own an Amiga!!)  Glad it's staying "Smokey" and even
gladder for the revisions.

What would you think about an option to make the title bar invisible?  Would
anybody use it?
						Thanks,

						  ...richard

 Folks:

	For some as-yet-undetermined reason, it's impossible for me
	to access successfully anything over DECnet using explicit
	acces-control strings.  Any COPY operations using things
	like AGNESI"AMIGA":: simply freeze up after a few I/O's;
	this has happened when I've tried to get at AGNESI and also
	at PAULY.  Oddly enough, DIRECTORY commands work just fine;
	so I can look, but I can't touch.

	If there's a DECnet whiz-kid out there who recognizes what's
	going on and knows how to fix it, I'd appreciate some VMSmail.

	BUT, much more importantly, can someone point me at a copy of
	SMOKEY11.ARC that I can get to by means of a full path-name ?
	I'm sitting here drooling at the prospect of my A2000 keypad
	acting like it should, and it's frustrating no to be able to
	get ahold of the program.

	Thanks,
	 Art

Will 19200 and 38400 baud ever work? (If I missed something in the
documentation, please yell)

John

    You could call it 'Smoggy' or 'Fogey', no?
    
    ;{)
    

    I use 19.2 Kbaud frequently to exchange files between my Amiga and
    Toshiba T1000. No probs.

>    I use 19.2 Kbaud frequently to exchange files between my Amiga and
>    Toshiba T1000. No probs.


Hmmm, I have Foggy x1.0. When I select 19.2K or 38.4K, Then look back at the
menu, it has 2400 checked off... I wonder if It just *says* 2400 but is really
19 or 38... I'll check tonight.

John

Re: -.1

>Hmmm, I have Foggy x1.0. When I select 19.2K or 38.4K, Then look back at the
>menu, it has 2400 checked off... I wonder if It just *says* 2400 but is really
>19 or 38... I'll check tonight.

	What is your serial port baud set to in preferences?  Set it for the
19.2K before going into Foggy, and it should work fine.

Mark

> 	What is your serial port baud set to in preferences?  Set it for the
> 19.2K before going into Foggy, and it should work fine.

Now that makes sense!   Thanks!


John

    I use "Smokey V1.0." Actually I prefer to call it Liebow's VT200
    Emulator.

    Does anybody have a copy of VT200.DOC (0.6) lying around on a VAX?
    I want to print it but don't feel like uploading it from my Amiga.

    CANCEL THE REQUEST ON .122   -----
    However, I am experiencing some novice type peculiarities in Smokey.
    I took Smokey and put it on a separate disk.(is this what most people
    do?  I couldn't seem to make enough room on WB)  But I digress.....
    
    I put Smokey in df1: and started it up.  At the same time, I started
    up a cli and set my default to RAM:.  Then I ran Kermit on the VAX
    side and :
    	Kermit32> set file type binary
    	Kermit32> send ZOING.ARC
    After getting some gibberish from Kermit (which I assume is the
    startup signal), I took my mouse, set the XFER mode to image and
    then clicked on Kermit Receive on the menu.  This is where I get
    confused.  The download began to take place, BUT it tried to put
    ZOING.ARC on drive DF1: (where I had Smokey safely write locked).
    I assumed the download was going to go to RAM: but it sure didn't
    happen that way!  Can anybody clue me in on what I might have done
    wrong?

    
    I type one command to kermit on the VAX when I'm downloading to
    my Amiga with smokey:
    
    Kermit> Server
    
    Setting "Xfer Mode" in smokey is sufficient for getting the file type
    correct in this mode!  Then do a "Kermit Get" from Smokey.  The
    two kermits will discuss the file name and the VAX version will
    then go look for the file(s) you requested.
    
    When the files have all been transmitted, click on the terminal
    window and type two Ctrl-Y's, this will return you to the Kermit>
    prompt.

    re: WB space
    
    I've got smokey, dme, and shell all on my workbench.  If you use
    shell you can delete quite a few of the c: commands.  Be careful
    though shell uses several of them (e.g. Date and Run).
    
    Some other things you might want to delete if you haven't already:
       unnecessary printer drivers, 
       unnecessary keymaps (devs:keymaps/ keep us*),
       notepad (too slow to be useful),
       calculator (comes in handy sometimes though),
       iconed,
       libs:translator.library (unless you like Say),
       Preferences (even I didn't delete this one, but I've been tempted...)
       
    regards,
    
    steve mcafee

    
    
    	I to0 have found that putting the VAX in "server" and controlling
    the transfer from the AMIGA works best. I both uploading and
    downloadingthe kermit get and send from the AMIGA is easiest.
    
    			Steve
    

But XMODEM is *MUCH* faster than KERMIT. Although slightly more involved to
use. Here's what I do:


	Log into VAX via "Foggy Smoke"
	Select UTILITIES and CHANGE DIR from smokey menu to point to
	   where I want files to go/come from
	On VAX type (example here is download .ARC (ie image) file)

		$ XMODEM :== $device:[directory]XMODEM
		$ XMODEM -IS filename.ARC

    	Then select XMODEM RECIEVE from smokey file menu and type in
	the same "filename.ARC" you gave VAX XMODEM.

	And watch the bits fly...

	One nice feature about XMODEM on the VAX side is that it will
	tell you how many record to be sent, and how long at your
	current BAUD rate...

	Uploading is basically the same. Get the VAX side ready
	with $ XMODEM -IR filename.ARC  then select XMODEM SEND
	from smoket menu. Give it the same name as the VAX side.

	Smokey doesn't tell you how long -- or even how many records (hint
	hint :-))

John

    re the default dir...remember the amiga is MULTITASKING..;-)
    
    the cli and smokey had nothing in common...use the cd command in
    the vt200.ini file or the menu option to change smokeys default,
    or just specify the device on the file name given to kermit...
    
    scott.

Re: .123

I'll bet you did this:

1>cd df1:
1>run vt200
1>cd ram:

That doesn't work.  Every process on the Amiga has its own default directory.
When a CLI creates a process, it initializes the new process to have the
same default directory, prompt, and command path as the parent.  So, when
the RUN command created a new CLI process to run VT200, VT200 inherited
the default directory DF1:.

The second CD then changed the default directory of your CLI. However, the
VT200 process had become independent of the CLI by that point.  The
child process and the parent process were now distinct.  (Wow!  Apple
may be able to claim that they brought the "desk top" metaphor to the
masses, but Commodore can assert they popularized the "life cycle"
metaphor!)

    Before Foggy, Smokey used the Fastfont font I had been using. The
    latest version (Smokey 1.1) uses the default Amiga font. Is there
    a place I should put a fonts file to get the new Smokey to use the
    font I'd prefer? Will this adversely affect anything Smokey will
    want to do? Thanks for the new version.
    
      mitch

Re: .129

>    Before Foggy, Smokey used the Fastfont font I had been using.

	Don't blame me.  This was one of Mike's changes, and has been in
Smokey since X1.0 (which is the source I had to work from).  I would've
ripped this out, had I been a bit more comfortable with the code (Foggy, and
then Smokey X1.1 were the first time I'd touched C in four years).  I still
may a bit later on.  Anyway, to answer your question, they both look for a
font called Smokey, with an 8 point file.  If you have a font you like, copy
it there.  The difference, as we discussed back about eighteen replies ago,
is that the Smokey font in the X1.1 archive is DEC MCS, while the the one in
the X1.0 and Foggy arc is standard Amiga (ISO Latin-1) with the non-printables
changed from boxes to backwards question marks.

	One general question I have.  It seems many people were running X0.6
of Smokey until very recently.  Does this mean that nobody uses the Tektronix
emulation that only went in in X1.0?  If so, that's another thing I'd like to
rip out of there, to get back some space.

Mark

    I vote to rip out the TEK emulation...
    
    and...
    
    add 132 Col support (a la  VT100)
    
    
    my .02 worth...
    
    
    john
    

    	I don't use TEK emulation either ...
    
    M. Alvarez
    

On purpose you'll notice that I've stayed real quiet about terminal emulators
for quite awhile, however a suggestion might be in order here:

I have my own version of VT100 that has COMPILE TIME options for whether or
not you want:

	XMODEM
	YMODEM
	KERMIT
	TCP/IP
	132 cols
	TEK emulation
	SCRIPTS
	CUSTOM FONTS

You may want to consider this. All you have to do is leave a stub for each
item that you want to omit. Then each user can customize his/her own system.

Just a thought...
dave

    	Dave (re.134) gave me an excellent idea, and since wishes don't
    cost anything, I'll say it. 
    	I just have a mere 512K and running VT200, shell and mach doesn't
    leaves enough memory for some things I would like to do while running
    VT200. I wish for a bare-bones Smokey (I have a 1000), with as little
    memory requirements as possible. I could live without Xmodem and
    with only the VT200 7-bit parser. 
    
    Miguel A. Alvarez

    Help!!!
    
    When using Smokey 1.1 on my A500, the parser seems to reset itself
    from  VT100 to VT200_8 spontaneously.  This is with both VT100
    in the .init file and after changing it from the menu.
    
    Am I doing something wrong?  Where should I look for problems? 
    
    I'm no emulation guru, please keep any explainations fairly simple.
    

re: .136

	Does this change occur after a particular program?  Is there any
consistancy to when it occurs?

Mark

    Funny, I noticed a similar occurance... I set the mode to VT200_8
    bit in the .init file, and when I dial into our LAT and log in,
    the menu reflects the 8 bit setting.  However, when I type NOTES,
    the terminal kicks into VT200_7 mode.  In this mode, the NOTES
    screen comes up a bit brain-damaged, with lots of 'h's on the screen.
    
    So far, all I've been doing is re-selecting 8 bit mode from the
    drop down menu, and then the NOTES screen repaints itself properly.
    
    Ed.

        Has  anyone  had  a problem using either the arrows keys or the
        keypad?  I can't hold down the arrow key without either getting
        garbage on the screen, the bell sounding repeatedly, or getting
        dumped  to  the  LAT.   The same thing will happen if I use the
        keypad while reading notes.  It doesn't happen all the time, so
        I'm not sure what is causing it.

        I'm using a Scholar modem.  Could it be defective?

    re: .138 and a few previous
    
    VMS, and some programs, sometimes send a "set conformance level"
    escape sequence to the terminal.  Usually it is "set conformance
    level 2, 7-bit controls".  Smokey may be misinterpreting this to
    mean that it is supposed to _receive_ only 7 bits.  The sequence
    actually means that the terminal is supposed to _transmit_ control
    characters (not graphic characters) in 7-bit.  Terminals are supposed
    to receive control characters in both 7- and 8-bit forms, no matter
    what they transmit.
    
    TPU (upon which NOTES is based) sends both 7- and 8-bit controls,
    but (last I heard) can receive only 7-bit controls.  EDT sends
    only 7-bit controls (VT100 legacy) but can receive both 7- and
    8-bit controls.
        John Sauter

    Re: .7 & .8
    
    It seems to happen when I log on to the ALL-IN-1 system that we
    use.  And, lo and behold, it seems to happen when I enter Notes
    (from A-1).  I'm dialed-in to  a local Tymnet node, which in-turn
    connects me to the LAT in Waltham, from whence I get at NEMAIL,
    a VAXcluster which is used solely for A-1.  Could something generated
    by notes or A-1 cause Smokey to "adapt" to another  terminal protocol?
    It doesn't seem likely,  *real* terminals don't do this, do they?
    
    Tim :^]

    Re: .140
    
    I just tried some moving around the system and I believe that it
    only happens when I get into Notes.  And everytime I get into Notes.
    
    Tim.

I've been using smokey (foggy) x1.0 since it was posted. I've never
seen any problems. I use notes, TPU,  and the keypad.

John

    re. last few
    
    I have an A500 and smokey v1.1. I use notes all the time through
    a scholar modem with no problems.
    
    another problem.
    
    I bind my dialwork script to f10 but it will only work if I
    turn the A1000 switch on. In 500/2000 mode it won't do anything.
    Is this a bug in Smokey?
    
    tom
    

Re: -.1

>    I bind my dialwork script to f10 but it will only work if I
>    turn the A1000 switch on. In 500/2000 mode it won't do anything.
>    Is this a bug in Smokey?

	It's very likely a bug in my code.  I'll look into it.

Mark

	In fact, I think I know where the problem is and if so it'll be a
trivial fix.  It'll have to wait 'till after vacation, though.

    Smokey will give you problems with notes if your account has
    TERM/DEV=VT300. To get around the problem, just change your TERM/DEV
    setting.

	AGNESI"AMIGA"::S11A.ARC contains a new executable, and the following
readme file.

Mark
-------------------------------------------------------------------------------


          This is the executable for Smokey X1.1a.  This file contains
     a list of differences from the  previous version,  X1.1.   To run
     this,   you   will   need   the  fonts  (and  probably  want  the
     documentation)  from  the  Smokey  X1.0  kit.    As  always, this
     software is for DIGITAL INTERNAL USE ONLY.

                                Differences

     1)   A bug  in the  assignment of commands to function keys,
          introduced in version X1.1, has been  fixed.   In X1.1,
          it would only work with A1000 mode on, now it will work
          with A1000 mode off, as well.

     2)   Now, if you select the VT100 parser from the menu, or a
          script file  (including INIT),  the program will behave
          more like a VT100.  It  will answer  a SET TERM/INQUIRE
          as a VT100, and will resist attempts to be put in VT200
          mode by remote command.   If  the change  to VT100 mode
          occurs by  remote command,  there is no change from the
          X1.1 behaviour, and a remote command to change  back to
          VT200 mode will be unimpeded.

    I used the xmodem part this evening and noticed that xmodem is
    xmodem checksum...Any chance of a future version having xmodem
    CRC?  Just curious.  Thanks.
    
    brad

    I've just started using VT200 emulator. It is a fine piece of software!
    But I have a serious problem. Living in this side of 'the pond'
    (in Europe, actually Finland), we use different keymaps. Actually
    I use german keypad, since I bought my A500 from Germany last
    summer.
    
    The real VT200 has a menu to choose 'Finnish keyboard', 'German
    keyboard',... But the emulator hasn't got one. The CLI command
    Setmap D (for German keymap) doesn't seem to be effective in
    emulator. Are the keys mapped using RAWKEY? Or am I missing
    something trivial?
    
    Anyway, all help is appreciated. 
    
    	Tuomo

Re: .149

> Are the keys mapped using RAWKEY?

	Yep, 'fraid so.  I had considered changing this to use keymaps
properly, but it would be a non-trivial task the way the code is.  What
keys specifically give you problems?

Mark

    RE: .150
    
    > What keys specifically give you problems? 
    
    The letters are OK, except the minor difference that Y and Z have
    changed their places in German keyboard. The problem is in punctuation
    characters: they map almost totally differently. Here's a description
    how the most important punctuation keys differ between US and German 
    keyboards:
    		       USA    German
                  
                   	@	"
    			#	�
    			^	&
    			&	/
    			*	(
    			(	)
    			)	=
    			_	?
                        +	\
                        -	beta
                        =	/
                        {       U with umlaut (dots above)
                        }       *
                        [       u with umlaut
                        ]       +
                        :       �
                        ;       �
                        "       �
                        '       �
                        <       ;
                        >       :
                        ?       _ (underscore)
                        /       - (minus)
                        
    German keyboard has the braces and brackets as follows:
    (using VT200 terminology):
    
       			PF1	[	
                        PF2	]
                Shifted PF1     {
                Shifted PF2     }
    
    These are the real problem, because PF-keys have special meaning
    in VT200. I suggest these should be mapped e.g. to ALT-(, ALT-) and  
    Amiga-(, Amiga-) keys.
    
    I realize that these differences are rather big, but I think I'm
    not the only one who would benefit an european style keymaps.
    
    Regards,
    		Tuomo

    I have an interesting observation that I wonder if anyone else has
    seen.  I started up Smokey and then exited out of Smokey without
    downloading any files to RAM:.  However, my free memory didn't go
    back up to where it was before I ran Smokey.  It was about 30000
    bytes short.  Anyone know why this happens?  It could be sort of
    a handicap if you're trying to do dearc something right after
    downloading and run out of space (if you have 512K like I do). 
    
    The obvious workaround is to copy the downloaded file to disk, reboot
    and then copy the file back to RAM: before dearcing, but is there
    and easier way to recover the lost memory or getting Smokey to be
    more cooperative on releasing resources at exit?

    
    I would guess that the extra memory you are seeing is due to fonts
    which have been loaded by Smokey.  Don't worry though, as long as
    Smokey has notified the system that it is through with the fonts.
    When you need memory the system will notice that no-one is using
    them and it will free that space.
    
    - steve mcafee

Re: .151

	I'm not disputing the usefulness of translating keymaps.  Were I to
write software from scratch, I would almost certainly translate anything I
didn't get already translated.  The changes necessary to make Smokey do this
are extensive, however, and, from my perspective, not worth the effort.  As
I said some time ago, I'm not supporting this thing in general, as it is, for
the most part, not my code.  I know there are other people out there with
sources.  If one of them wishes to do that kind of work, and doesn't want to
loose the extensions I've added, I'll give them the changes I've made.
You should be able to get [,] and {,} using the two keys to the right of the
letter P.

Re: .152  

	.153 is correct

Mark

    one more comment of the function keys F!, etc...they are programable,
    so you could remap the PF1 strings, etc to other function keys...
    

	Searching for fonts ...
    Can somebody tell me were I can find the fonts required by Smokey?
    I have just copied version 1.1a but the fonts were not in the archive.
    
    TKS

Is there any way, once you have received the raw key data to call a system
routine to return the keymap equivalents? The documentation tells you
the format of the keymap, and you can call a routine that will load the
keymap data for you, but it seems like a major pain to have to do this
to get the translation. I am working on porting SEDT to the Amiga, and
must get the raw keyboard data, but I don't want to have a builtin
translation table. Any ideas?

Frank

    re: 156 and the fonts...they are in the plain 1.0 version...look
    for a bigger arc file...I also believe this was mentioned a few
    notes back re the release of the new arc file....in anycase, the
    latest version on mvcad3::user0:[amiga.arc]vt200.arc has them...
    
    scott.

    
    Mark,
    
    	In the sources for smokey, is the serial port code intertwined
    with other parts of smokey, or is it in its own module?  Would it
    be possible for me to just get the sources for that module if that's
    the case?  
    
    thanks,
    
    brad

Brad,

	I looked, and it seems just about everybody prangs on the serial port.
(That is, that the code is intertwined through many modules.)

Mark

    From the USENET Kermit Distribution.
     
    Does anyone suppose that this could be included in the next release
    of SMOKEY  (The finest T.E. around)
    
Date: Tue, 29 Mar 88 14:38:49 PST
From: RCKG01M%[email protected]  (Stephen Walton)
Subject: Announcing C-Kermit 4E(070) for the Amiga
Keywords: Amiga Kermit, C-Kermit
X-Ref: Commodore Amiga, See Amiga
 
Enclosed is a shell archive containing the following files:
 
    ckiker.bwr--A new version, with my comments on the end.
    ckiker.boo--A BOO file for C Kermit on the Amiga.
    Makefile--A makefile for the Amiga under Aztec C.
    diffs--The context diffs to convert CKI*.C to the new versions.
    msb_diffs--Context diffs which I applied to make msbpct.c and
           msbmkb.c work on the Amiga.
 
I hope all of this is useful to somebody.
 
                Steve Walton, 29-Mar-88
                Dept. of Physics & Astronomy
                Cal State, Northridge
                18111 Nordhoff St.
                Northridge, CA 91330
 
Email to: [email protected] (will forward)
 
[Ed. - Thanks, Steve!  The entire shell archive has been added, for now,
to CKIKER.UPD, and the changes will be applied to the next release of
C-Kermit.  In case you're wondering what this does for Amiga users, the
major change since the last Amiga release is the addition of long packets.]
                                                             ^^^^^^^^^^^^^
-----------------------------------------------------------------------------

    
    
    Bob.
    

    Which key on the 1000 is the BREAK key during use of Smokey?  I want
    to get back down to the terminal server level for multiple logins to
    the VAX without using a $SET HOST.

    since its built on vt100, i think its the R-Amiga "."  (ie period
    with the R-amiga key...isn't it also in the menu??
    
    scott

    What is the latest version of Smokey and where is the location of
    the full kit?

    
    You don't have to use break if you don't want to. I always set up
    an alternate local key by doing a SET LOCAL ` and a SET FORWARD
    ^`. 

    RE: .164
    
    To be more specific, is the latest release of Smokey at level 1.1
    or level 1.1A?

    A silly question, but...do any of the incarnations of Smokey speak
    the SSU protocol?  Do any terminal emulators?
    
    BobW

    I downloaded VT200.ARC from MVCAD3 but I'm not sure which version it 
    is.  The documentation says nothing about the escape key or 2000 keyboard
    after I dearc it.  On the other hand, I downloaded Smokey11.arc
    from AGNESI but was unable to find Smokey11a.arc as previously
    mentioned in this topic.  It was 122 blocks as opposed to the version
    on MVCAD3.  Where oh where is the newest version of Smokey? (fonts
    and all....)

    Hmmmm ... the ESC key scroll feature doesn't work on my A2000
    (new keyboard with fat function keys and Left-Amiga key (black ink).
    
    Paul

    re 168, and the versions on mvcad3...Sorry, but all that I've kept
    up with was the v1.0 release from mike...If I can. I'll look for
    a more recent version to put there...but fonts, and such are there,
    only the exe is the v1.0 version.
    
    scott

	The latest version is 1.1a which is at AGNESI"AMIGA"::S11A.ARC
(executable only - use other stuff from 1.0).

Re: .169

	If Escape key is turned ON, it should work as a normal escape key.
With Escape key turned OFF, it should act like hold screen.

Mark

    The ESC key functionality sounds good, but it does not work. Perhaps
    the new A2000 keyboards work differently?
    
    Paul

	I doubt it.  I have one of the new keyboards, and it works fine.
What other options do you have set?  Maybe there's a dependency I'm not
aware of.

Mark

    Hmmm ... I will upload my init file tonight if I have a chance.
    
    I have the keyboard with the fat function keys, and the black
    left-Amiga and right-Amiga keys.
    
    Paul

    Dunno what I did, but the ESC key no scroll feature is working now.
    
    Paul

    GOOD AFTERNOON    GOOD AFTERNOON    GOOD AFTERNOON    GOOD AFTERNOON
    GOOD AFTERNOON    GOOD AFTERNOON    GOOD AFTERNOON    GOOD AFTERNOON
    GOOD AFTERNOON    GOOD AFTERNOON    GOOD AFTERNOON    GOOD AFTERNOON
                                                                        
    
    I needed a lot of greetings at the top to make up for 6 months.
    
    I blazed over the last 178 replies that I've missed and noticed
    that my code was taken over.  Thank you very much for not sharing
    the code over the wire.  The reason I could not  release it is because
    parts of the code are taken from an existing DEC terminal (sixel).
    
    NEWS:  When I went back to school, I had given up smokey.  After
    I was there for about a week, I realized that I just needed a better
    terminal then the old VT100 2.4 which Smokey was based on.  So,
    not having the executable or sources for Smokey, I started a new
    terminal from scratch.  I now have V1.0 of "Meshugena."  Meshugena
    is a much much much better VT220 emulator then Smokey ever was.
    The main reason it is better is because the code is re-entrant and
    can do multiple sessions with the "Unix Windows" protocol developed
    for the macintosh circa ?1985?.  It also does some of the more bizarre
    modes correctly (origin mode).  I have a public domain version
    that I will post here when I can get my machine hooked up to a phone
    line again.
    
    Meshugena in many instances is better than Smokey, but is a step
    back in others.  It has no graphic protocols (regis, sixels, tek,
    etc).  It also has a cruddy keyboard driver.  I am working on an
    emacs style keyboard driver where you will be able to redefine keys
    whenever you wish.  Some of the improvements are: Multiple session,
    I/O control from another process, transcript buffer, scroll bars,
    cursor coupling, and the startup file is pretty complete.  Some features
    that need to be added : completely redefinable keyboard in terms
    of an LK201, SSU compatibility, cut-and-paste (clipboard), file
    transfer, script control, photo sessions, whatever else you can
    think of.
    
    The I/O control mechanism is probably underdeveloped but I think
    it is a good start.  When Meshugena starts up, A command port is
    created.  Another process can do a "findport()" to get the address
    of this port.  This process then starts the conversation with Meshugena
    by sending an INIT command.  After that, the process becomes the
    control process.  All Meshugena I/O (keyboard, serial) must go through
    the controlling process' reply port before it can get displayed
    or sent over the serial line.
    
    You may ask, "why did he do this?"
    
    Because:
    This is an excellent way to do file transfer and script control
    without wasting tons of memory.  Most programs have all of the code
    sitting in memory.  My attempt was to free space by doing it from
    a different process.  So, when you need to do a file transfer, you
    can start another process from workbench that has your favorite
    file xfer protocol.  Also, I don't have to write all of the code.
    If I leave again (3 months), now you can write your own extra features
    without changing the original code.  If someone can send me the
    source code for kermit (the real one with a command line interface)
    I will make it work as a controlling process for Meshugena.  Then,
    you would start meshugena and then kermit.  The session would like
    something like this:
    	KERMIT-Meshugena> set session 1
    	KERMIT-Meshugena> connect
    
    and then you could use session one.  WHen you have the remote kermit
    in server mode, you would hit some gadget that would bring the local
    kermit back into command mode:
    	KERMIT-Meshugena> put file1
    
    And while the transfer is taking place, you could start another
    session and do something else.
    
    Another thing you can do with the I/O control is emulate other
    terminals.  All you have to do is write a parser which translates
    the non-dec stuff into dec-stuff.  I have already written a televideo
    925 translator for a crappy machine at school.  It worked great.
    
    ideas anyone?
    
    	--Mike Leibow (glad to be back)
    
    PS: Cross posted a new topic: Meshugena Terminal Emulator
    

    I have read the replies on this note ooff and on, so I do not know
    if any body else has mentioned this but it here it is:  I need to
    be able to turn the printer on and off while in session.  I do realize
    about the different fonts but still if I can print straight ASCII
    it would be great.
    
    Other wise I thing the sixel and the other graphics things are
    important. I DO enjoy the Smokey good job ....
    
    ...gss...:-)
    

    Two requests .... XON XOFF does not appear to be a feature of Smokey.
    Guess its not needed on VMS systems. I would like to see it added.
    
    Also, NAG crashes the Amiga when it attempts to burst forth a window
    while running Vt200.
    
    

    what's NAG?
    

   Nag is great stuff. My A500/1-meg also crashes if nag goes off while
   I'm running Foggy X1.0.

	Here is a description of NAG, You can find it on MVCAD3:: or PAULY::.
-bw 

P.S.  Welcome back Michael :')

   Nag is an Shareware Appointment Calendar with it's own editor and an
 unique 'nagging' feature utilizing the Amiga's voice and audio devices.

   - ******* -            - Nag  Features -            - ******* -

 -> Be Nagged (reminded) by Flash, Beep, Sample, and/or Voice.
 -> Set times, and types of nags for each individual event.
 -> Plays ANY file as SOUND data. Will set Period from IFF format file.
 -> Simple, 'intuitive', gadget-driven menus follow WORKBENCH conventions.
 -> Configuration file sets Nag to YOUR preferences. AM/PM or 2400 format.
 -> Up to 2 years of 99 events per day. Buffer size 2 K to 2 MEGS.
 -> FAST gadget-driven editor with COPY & RECALL. 'Special Date' flags.
 -> Calendar gadget quickly shows any day of any month of any year.
 -> Print Routine. (Assignment sheets, printout of personal Diary, etc.)
 -> Search Routine.  'Missed Nags' Routine.  'SingleShot' Nag Switch.
 -> The Ultimate Reminder!!!  SHAREWARE:  User = $10  -*-  & Disk = $15
 Address Insect Sightings to: RLStockton on PLink or Genie. Thanks! :-)

    

Re: .177

	You can get printouts of what's being sent to the terminal.  Select
the ASCII capture option, and when it asks for a file, tell it PRT: .  This
will cause text to be sent to your printer and terminal at the same time.  Of
course, you need a parallel printer for this to work.

Re: .178

	Who's Eric?  Is someone else making changes? :-)

Re: .179

	^S and ^Q send XON/XOFF controls.  If that's not what you're talking
about, please explain.

Mark

    Sorry Mark.
    
        I got my head screwed on backwards.
    
    ----------------------------------------------------------------------
    
    Mark Eklof is doing changes to Smokey.
    
    ----------------------------------------------------------------------
    
    RE: NAG stuff,
    
    I checked it out, and NAG is at fault.  If it can't get an Audio
    channel, it will GURU.  I tried it with SONIX playing a song, and
    at NAG time, a GURU appeared.  Neat thing was that during the GURU,
    the SONIX song continued to play.
    
    	--Mike
    

    .183
    
    "An audio channel?"
    
    Do Smokey and Foggy hog the audio channels the way OnLine! used
    to hog the printer device? Why can't they share?
    
    I will send mail to Richard Lee Stockton (author of NAG).

    That's funny; I once had MACH clobber SONIX by taking an audio channel.
    MACH kept on running.  I think it was an older version of MACH.
    I just turned off the 15 minute beeper.
    
    Could multitasking be spawning a new type of Darwinian life?  Only
    the strongest software survives!
    
    Ed.
    

    Hmmm... I run Mach with the 15 minute timer enabled. It runs and
    beeps even while running the terminal emulator (Smokey/Foggy).
    
    Why can MACH gain (shared?) access to the audio channel and NAG cannot?
    

    When you do an OpenDevice() on an AudioChannel, you have to specify
    which channel you want, and give a priority to it.  If somebody
    else tries to gain access to the device with a higher priority,
    he will get it.  A warning bell should get the device at a High
    priority.
    
    Smokey gets the channel when the code starts up and frees it when
    the program exits.  This should be changed so that the OpenDevice
    is called at the time the bell is supposed to ring.  Smokey should
    also ask for the bell with a very high priority to make sure the
    sound makes it out.  Then, Smokey should free the device immediately
    after using it.
    
    	--Mike
    
    

    Mach 2.0 doesn't bother Smokey at all.

                      -< Smokey VT200 Terminal Emulator >-

Can anyone tell me how to set up the VT200.INIT file so that I can map all of 
the keys in the keypad to emulate the keys on a VT220? I find it very difficult
to edit using EDT from the A-500 since I'm used to using the special keys in the
keypad. In particular, I'm talking about the top row and the right column of 
keys. The numeric keys seem to work OK.

Dave

RE: .189

	Turn A1000 OFF.  Either do this in your startup script, or from the
keyboard menu.

Mark

    Will the hogging of the audio channels in VT200 Smokey ever be
    corrected?
    

RE: .190

<	Turn A1000 OFF.  Either do this in your startup script, or from the
<	keyboard menu.

How do I do this, either in the .INIT or the menu? I couldn't find any reference
to "A1000" in my documentation. Do you mean "APPCUR"?

Dave

Re:.192

>How do I do this, either in the .INIT or the menu? I couldn't find any
>reference to "A1000" in my documentation. Do you mean "APPCUR"?

	No I mean A1000.  In your script file, you say "A1000 OFF".  On the
menu, you make sure A1000 doesn't have a check mark beside it.

	If you're running X1.0 or earlier, the thing you need to adjust is
the version number.  The new keypad is supported in X1.1 and later (X1.1a
is current).

Re:.191

	There will be no changes to Smokey until I can compile it again.
I have Lattice C, it compiles under Aztec C.  I used to carry the sources
over to someone who had Aztec and compile it on his machine, but he moved.
It mostly compiles under Lattice (though it comes out much larger), but
there is one construct I don't know how to convert.  So, I've either got 
to find a way to convert it (and live with a much larger executable) or find
someone close by with Aztec, or buy it myself.

Mark

     Re: .193

     So tell us where you are.  Someone with Aztec C must be close to you.

	Paul

Re: .193

>It mostly compiles under Lattice (though it comes out much larger), but
>there is one construct I don't know how to convert.

Out of curiosity, what is the construct you don't know how to convert.

Re:.195
       
>Out of curiosity, what is the construct you don't know how to convert.

	int_start();
	  .
	  .
	  .
	int_end();

These routines are apparently part of the Manx OTS, since they aren't
defined anywhere in the Smokey sources.  They are used around the code
that handles the bell.  If I leave them in, BLINK complains that they
are undefined.  If I remember correctly (it's been a few months since
I looked at this), whether or not I take them out, Smokey seems to work
fine until the first bell, at which point it hangs.

Mark

    Hi,
    
    I am sorry I haven't replied to this much earlier.
    
    int_start() and int_end() are library routines which save and restore
    certain registers.  They let a C programmer write interrupt handlers
    without having to worry about assembly code.
    
    I guess a small module could be put together that does the same
    thing as int_start() and int_end():
    
    	small_module.s
    
    	public _int_start
    	public _int_end
    
    	_ins_start:
    		movem.l		everything,(sp)-
    		rts
    
    	_int_end:
    		movem.l		+(sp),everything
    		rts
    
    	--MIke
    
    PS: I don't remember 68000 assembly very well, so the syntax above
    is probably very wrong.  ALso, I don't know exactly how to make
    symbols pulic and global, but I remember seeing the assembler
    directive "public" and "CDEF".  They might be the right ones....
    anybody have a comment?
    
    

Re: .197

>    	_ins_start:
>    		movem.l		everything,(sp)-
>    		rts
>    

Gak.  You may be a wiz at terminal emulators Mike, but I don't think
I'll put you in charge of my stack.  :-)

Two bugs in the code:  First the return instruction is going to pop
the last register off the stack as the return address.  Second, if
by some accident flow of control ever got back to the calling function,
all of its references to automatic data would be off.

I recommend that the registers be saved and restored to a static
buffer (assuming interrupts don't nest).

    RE: .gak.
    
    	I haven't had much sleep lately.
    
    	--Mike
    

    
    I love the new stuff I read about s11a, however I can't seem to
    get at it.  
    
    I type;
    
    DIR AGNESI"AMIGA"::S11A.ARC
    
    And I get;
    
    SYSTEM-F-INVLOGIN, Login information invalid at remote node
    
    
    What am I doing wrong?
    
    Harry Arendt
    DTN 238-4313
    MAIL CAM::ARENDT
    
    
    Thank you for your support
    

	AGNESI isn't a PRO anymore, at least for now.  The file isn't there
anymore.  I believe it's on PAULY.  You might check there.

Mark

Sorry if the answer to this is in here already, but there are quite a few 
replies to wade through and I may have missed the right one.

I'm using Smokey at home to log into the office. Now my son is taking the
Amiga-500 to college with him (it's HIS graduation present, rats!) and he will
need some form of terminal emulator. He will be logging onto a VAX at U-Mass,
Amherst, but, since Smokey is for DEC internal use only, we've got to get
another program, preferably one which has up/down-load capabilities. Any
suggestions? Where would the program be found on the network? 

Thanks in advance, Dave 

    See note 1450 for details on Meshugena, written by the same author
    but using no DEC proprietary stuff.  There is also a proprietary
    replacement called Wheat -- look in notes around 1450 vintage.
    
    Wes

    
    Handshake is an outstanding VT102 terminal.  Features XMODEM and
    KERMIT protocols, 132 column support, 24 or 48 lines, capture buffers,
    macros, blah blah...
    
    It's online in LEDS3::USER6:[ACCIARDI.AMIGA]
    
    Ed.

    also look into the original...dave wecker special...vt100...not
    in release 2.8 (2.7, and 2.8 were not daves)...this is what vt200
    came from....
    
    see mvcad3::user0:
    
    Directory USER0:[AMIGA.USENET]
    
    VT100.BUG;1         VT10028SRC.SH1;1    VT10028SRC.SH2;1
    VT10028SRC.SH3;1   
    VT10028SRC.SH4;1    
    
    Total of 5 files.
    pccad7::baeder > dir [amiga.arc]vt1*
    
    Directory USER0:[AMIGA.ARC]
    
    VT10028.ARC;1       VT100_26.ARC;1      
    
    Total of 2 files.
    
    
    scott.
    

I just started using Smokey.

I'm having trouble getting a script to auto log
me in to work.  When I do the  "send" command it
appears that the modem is receiving every other
character.  I am using a DF112.  The command looks
like this

	SEND "T8413800#"

The echo to the terminal screen is

	T430#

	Any suggestions?

			Dean Cromack

    Re .206

    Is is working ok without the script file?  (In other words, can you
    dial the modem manually and get things to work for you?)  Don't even try
    the script file until you have tried the whole process manually.

    If you get it to work manually, then start over, type control-B and try
    conversing with the modem.

    Is Smokey's baud rate set the same as the modem's?

	Paul

    P.S. Under the best of circumstances Scholars are touchy.  It took me a
         LONG time to get mine to autodial.  Take a look at the MODEM
         notefile sometime.  I had to put "W"s at two different places in
         the phone number before I could get it to work thru my exchange.

The baud rate is correct.  I am able to go through the whole
thing manually.  Your reply does give me an idea however.  Maybe
I should put some null's in between the characters I want to send.


			Dean Cromack

    I've noticed that Smokey doesn't echo right for my Scholar 224 either.
    About half the time when I execute my script, I get "eady" in response
    to the first Ctrl-B.  It doesn't seem to affect the execution, though.
    Smokey still dials in fine.  I get the rest of the replies okay.
    
    Do you have a 'Send "^B"' as the first thing in your script, and
    then a 'Wait "Ready>"?  That'll insure that the modem gets reset 
    properly whenever the script file runs.  
    
    Reply .-1 said Scholars were funny.  I can testify that DF112's
    are kinda funny too.  (Don't I remember you saying you had a DF112?)
    We've got one set up off of a terminal server acting as a dial-out 
    service.  For some reason, the DF112 "Attached" message doesn't get 
    returned do the terminal through the terminal server connection.  
    
    
    
    				John 

Re: .206

Rather than:

	SEND "T8413800#"

try:

	SEND "T"
	SEND "8"
	SEND "4"
	SEND "1"
	SEND "3"
	SEND "8"
	SEND "0"
	SEND "0"
	SEND "#"

The problem could be that the modem cannot keep up with a high speed
burst of characters.  Using separate send commands will keep the Amiga
from gagging the modem.

I changed the command to

	SEND "T 8 4 1 3 8 0 0 #"

and it worked.

Next problem.

I got the script file to work if I run it from the menu option
"Execute File."  I named the script vt200.init and put it in the
top directory on the disk.  When I run vt200 it say that it doesn't
recognize any of the commands.  It goes through the whole file listing
each statement and says it does not recognize the command.  The commands
come out in lowercase in the error message.  This appears to be a file
format error. I used microemacs to create the file and the very same file
as I said works fine after the program is up and running.


		Any suggestions?
			thanks, 
				Dean Cromack

    re.-1
    
    Have you read the documentation? If I remember correctly some commands
    work only in script and others only in .init. So I guess you should
    take a look at the docs and compare!
    

I wrote my script from the example script in the documentation.

			Dean Cromack    

Re: .11, .12, .13

There are two separate command languages (more or less).  Init file
commands can not appear in script files and script file commands
can no appear in init file commands.

The net effect is that you can not use the menu option to execute
a new init file, only script files.

    I have an A2000.  How can I set my init file to set the emulator
    to turn off the A1000 keyboard setting in my startup?  There is
    no mention of this in the documentation.  I do not like having to
    do it myself every time I use Smokey.
    
    Randy
    

Re: .215

     It's described in a previous reply, but once again...

A1000  On/Off

Mark

    Re -.2
    
    	Don't do it, otherwise, the function keys will not work!
    
    Jean
    

Re: .217

     What are you talking about?  The function keys work just fine.
They work differently, but they work fine.  There's a reply in here
somewhere (I wrote it), which describes the changes.

Mark

    Well, I could not get my function keys to work unless smokey was
    in "A1000" mode.  I checked the login file and no changes were made
    from my old set-up that I used with my 1000, except what the function
    keys meant, and everything worked well.  The keys were the same
    as an LK201.  Please point me to the right note and if possible
    list your startup file so that we can learn from your experience.
    
    Jean
    

I'm using SMOKEY to download an IFF file to the office where it will be 
converted to sixel format using CSIX. Occasionally it works OK but either there 
is a bug in CSIX or I am doing something to corrupt the IFF file while 
transmitting it. What I'm doing is:

	1. Enter KERMIT on VMS
	2. Set file type binary
	3. Set KERMIT SERVER
	4. Send <file>
	5. When done, do BYE, and then type exit.

Is there any special mode that SMOKEY should be set to to send an IFF file? I 
need this urgently since I'm trying to print some transparencies for a 
presentation which I have to give tomorrow. I've got the IFF files on line and 
if anybody has an Amiga and an LJ250 in the office I'd appreciate it if they 
could print the two files out for me directly (in the Marlboro area, call me at 
291-7107). Any other help would be greatly appreciated. Thanks. 

Dave

    
    Kermit isn't 100% guaranteed to transfer the file intact.  Line
    noise can corrupt packets in such a way that they look valid to
    Kermit.
    
    I use ARC on VMS and Amiga before/after a file transfer to make
    sure that a file wasn't corrupted (arc t arcfilename).
    
    try ARC, that should also reduce the upload time.
    
    -dave

    Re .149 and European keymaps...
    
    Is anybody working on keymapizing one of the VT... emulators?  As
    a happy user I would be even happier if I could remove all those
    rather unsightly little sticky labels I had to put all over my A500.
    
    If not, is there any way to help?
    
    
    D

    Hello, I'm relatively new to the AMIGA domain and I've encountered
    some difficulties when attempting to run my VT200 TE. I aquired a copy
    from a friend who has a multi-sync monitor, I'm using a 1084S when 
    I attempt to run VT200 it bombs with " can't open dispctrl/8 fon !
    Any suggestions ?
    
    Thanx,
    
    Todd
    

    Re .223:                                                      
    
>   Hello, I'm relatively new to the AMIGA domain and I've encountered
>   some difficulties when attempting to run my VT200 TE. I aquired a copy
>   from a friend who has a multi-sync monitor, I'm using a 1084S when 
>   I attempt to run VT200 it bombs with " can't open dispctrl/8 fon !
>   Any suggestions ?
    
    Smokey and several other terminal emulators use special fonts to
    display the VT200 graphics characters.  Using the CLI/Shell, look in
    the FONTS directory on the diskette on which you received your
    emulator.  Copy the missing font sub-directories to SYS:FONTS on your
    boot disk and try again.

    If you're like most people, the software you got from a friend will
    be missing the fonts directory. I suggest that you track down the
    ENET copy of it -- perhaps in TAPE:: or WJG::
    
    Keith

    Thanx everyone. You're right Keith that the fonts directory on the
    diskette is non-existant. Unfortunately , I can't down load off the
    net to my Ami until I get this terminal emulator working. I'm having
    my friend compress his fonts dir. for me.
    
    Thanks again,
    
    Todd
    

	How do you get Smokey to use a bigger font?
        The default one is so tiny I can hardly see the characters.
        
	(I have a small TV, not a monitor)

        Dave

    You've probably got it set up in Interlace mode (If Smokey does such a
    thing).

    Lindsay

Ah... thats what it was. Thanks. (I cut/pasted the .init example in the user 
doc)

Dave

Does anyone out there know if the sources to Smokey are available?

I'd like to have a go at multiple sessions (a la WHEAT, but it's is to guruey).

One alternative is to go back to the original VT100 code (which comes with
sources), but then we miss out on lots of Smokey's good features.

I've found several references to Smokey sources throughout this conference,
but no real pointers to them, and no real indication if the original author is
happy for them to be shared around within DEC.

Does anyone know?

I am quite sure the author was unwilling to make the sources available.
The reason was that he was a coop working in the terminals group.  He used
proprietary knowledge in implementing Smokey which was not be be released.
As far as I know he is no longer with Digital.  So I think smokey (and
wheat) are deadends.

I liked smokey, but finally switched to VLT in order to get zmodem support.
Except for that I would still prefer smokey - I find VLT to be buggy - it
just doesn't accurately implement the protocol.  I would really like to
have an up-to-date emulator on the order of the decwindows vt3xx emulation,
but I have neither the time nor the necessary information to implement it.

Meanwhile I suffer with VLT.

	Paul