vt4-develop

Re: [vt4] Results of running James's slow-motion test

[Nathan C. <pre...@gm...>]

>  EDT repaints the entire screen in insert mode?  Really?  VT6 problems not withstanding, that seems like a dumb thing for it to do.

Let me clarify using a test scenario: Say I run EDT on a big file.
Using the CHANGE command, I enter full-screen mode. Then I press the
left-arrow twice (we have already determined that this causes EDT to
put the VT220 into insert mode). Then I press PF1 + keypad 7. This
causes EDT to display a command prompt ("Command:") at the bottom of
the screen in reverse video. We are running in "slow mode" at this
point. Now, I issue the command TYPE WHOLE. It takes forever, in a
manner of speaking, to finish the listing.

So no, it doesn't repaint the screen in insert mode. It just writes
the output of the command to the bottom of the screen, as if it were
in line mode (which it is, but only for a single command). Whatever
was on the screen before gets scrolled off.

The point is that EDT is a real-world example of where you run into
the slow mode. But in most cases it's just a minor annoyance.

Nathan

Re: [vt4] Results of running James's slow-motion test

[Bob A. <bo...@jf...>]

>In EDT, the only times I've seen this issue are when I issue a command
>that results in output while the terminal happens to be in insert
>mode.

  Another workaround is to tell EDT that you have a VT100.  VT100s don't have an insert function if I remember correctly.

> For example, if I press the left-arrow twice (causing the
>terminal to go into insert mode), then run a "TYPE WHOLE" command, the
>entire contents of the buffer are then written to screen in "slow
>mode".

  EDT repaints the entire screen in insert mode?  Really?  VT6 problems not withstanding, that seems like a dumb thing for it to do.

Bob

[vt4] Results of running James's slow-motion test

[Nathan C. <pre...@gm...>]

> Yes, that was option 1.  Option 2 is to peek ahead at the input buffer
> and do one big shift, instead of a bunch of little shifts.  I am actually
> leaning toward option 1.5: when doing an insert, do a quick scan of
> the remainder of the line to see if there are any characters.  That
> won't be as fast for this insert case, but will be 32x faster than today's
> insert case and will not impact any of the non-insert performance.  The
> main reason is that this will fit very nicely into the code with little
> risk of bad side-effects (i.e. introducing bugs).

In EDT, the only times I've seen this issue are when I issue a command
that results in output while the terminal happens to be in insert
mode. For example, if I press the left-arrow twice (causing the
terminal to go into insert mode), then run a "TYPE WHOLE" command, the
entire contents of the buffer are then written to screen in "slow
mode". This could conceivable take hours for the VT6 to complete and
be a major headache. Option 1.5 seems like a good fix for this case:
since there are no other characters on the line, only one iteration of
the scan loop would be necessary per character.

Nathan

P.S. Sorry James for the duplication - I keep forgetting that I have
to change the address so my reply goes to the list.

Re: [vt4] Results of running James's slow-motion test

[James A. M. <ja...@ma...>]

>   Have we (the royal "we" in this case, of course :-) considered setting
> aside an extra byte per character row to keep track of the rightmost
> non-blank character on that line?  It'd be zeroed when the screen or line is
> erased, and you'd have to update it every a character is written to the
> display.  That'd add some overhead to all characters, of course, which might
> negate the beneficial effect.  OTOH, it'd allow you to optimize the insert
> case.

Yes, that was option 1.  Option 2 is to peek ahead at the input buffer
and do one big shift, instead of a bunch of little shifts.  I am actually
leaning toward option 1.5: when doing an insert, do a quick scan of
the remainder of the line to see if there are any characters.  That
won't be as fast for this insert case, but will be 32x faster than today's
insert case and will not impact any of the non-insert performance.  The
main reason is that this will fit very nicely into the code with little
risk of bad side-effects (i.e. introducing bugs).

>   Also, didn't I write a fast BLT operation in assembly that used the
> special hardware of the DS89C400?  Did that get integrated into the code?

Yes, that was integrated in.

James Markevitch

Re: [vt4] Results of running James's slow-motion test

[Bob A. <bo...@jf...>]

>Yes.  The reason for this is that the VT6 needs to work correctly
>regardless of what characters are already to the right of the cursor,
>whether they are all blank, there is just one character, or there are 79
>characters.

  Have we (the royal "we" in this case, of course :-) considered setting
aside an extra byte per character row to keep track of the rightmost
non-blank character on that line?  It'd be zeroed when the screen or line is
erased, and you'd have to update it every a character is written to the
display.  That'd add some overhead to all characters, of course, which might
negate the beneficial effect.  OTOH, it'd allow you to optimize the insert
case.

  Also, didn't I write a fast BLT operation in assembly that used the
special hardware of the DS89C400?  Did that get integrated into the code?

Bob

Re: [vt4] Results of running James's slow-motion test

[James A. M. <ja...@ma...>]

> If I understand the issue correctly, when a character is written to
> the screen when the VT6 is in insert mode, the firmware moves the
> whole line one character to the right *even if the line is blank*. So,
> for example, if the VT6 is in insert mode and my program writes
> "Command:" to a blank line on the screen, the firmware moves 79 blank
> spaces to the right for the "C", 78 characters to the right for the
> "o", etc.
> 
> Do I have that right?

Yes.  The reason for this is that the VT6 needs to work correctly
regardless of what characters are already to the right of the cursor,
whether they are all blank, there is just one character, or there are 79
characters.

Since this doesn't seem to be urgent, it will likely be another week
or so before I consider any code changes.  The question will be which
cases to optimize for, since each optimization adds a slight performance
penalty to some other cases.

Please let me know if you encounter any other cases where you see a
"slow mode" or, of course, if you find any other bugs.

James Markevitch

[vt4] Results of running James's slow-motion test

[Nathan C. <pre...@gm...>]

>> Try this:
>>
>> main()
>> {
>>        int i;
>>
>>        for (i = 0; i < 10; ++i)
>>        {
>>                printf("This should print quickly\r\n");
>>                printf("\033[4h");
>>                printf("This should print much more slowly\r\n");
>>                printf("\033[4l");
>>        }
>> }

OK, I got my new power supply today and tested this program. It does
exactly what you said it would.

If I understand the issue correctly, when a character is written to
the screen when the VT6 is in insert mode, the firmware moves the
whole line one character to the right *even if the line is blank*. So,
for example, if the VT6 is in insert mode and my program writes
"Command:" to a blank line on the screen, the firmware moves 79 blank
spaces to the right for the "C", 78 characters to the right for the
"o", etc.

Do I have that right?

Nathan

Re: [vt4] Fwd: Slow-motion issue

[James A. M. <ja...@ma...>]

> However, I don't think this is the problem in this case, because when
> the problem occurs, the screen is blank except for a single line of
> text with only 7 characters in it ("abcdefg"). This line is at the top
> of the screen. The rest of the screen is blank. Then, after the
> problem is triggered by pressing the left-arrow key twice, the
> reverse-video characters "Command:" appear on the bottom of the screen
> *in slow motion* (i.e. noticeably slower than 9600 baud). The
> slow-motion behavior, then, occurs *only* at the bottom of the screen.

Try this:

main()
{
        int i;

        for (i = 0; i < 10; ++i)
        {
                printf("This should print quickly\r\n");
                printf("\033[4h");
                printf("This should print much more slowly\r\n");
                printf("\033[4l");
        }
}

This alternates between insert mode and replace mode for each of the
lines.  This should demonstrate that it is a symptom of insert mode
inefficiency.

James Markevitch

Re: [vt4] Fwd: Slow-motion issue

[Bob A. <bo...@jf...>]

>However, I don't think this is the problem in this case

  That one James will have to address.

Bob

[vt4] Fwd: Slow-motion issue

[Nathan C. <pre...@gm...>]

>  If you mean the serial line from the host, then they're not of course.
> I'm not sure what James or I said that led you to this conclusion.

I was confused (obviously). Now I see James was talking about copying
the pixel descriptions in memory to redraw the line. Since the bulk of
the VT6's processing power is being used to scan the VGA, there isn't
much left to handle these memory-copy operations. Makes perfect sense
to me now.

However, I don't think this is the problem in this case, because when
the problem occurs, the screen is blank except for a single line of
text with only 7 characters in it ("abcdefg"). This line is at the top
of the screen. The rest of the screen is blank. Then, after the
problem is triggered by pressing the left-arrow key twice, the
reverse-video characters "Command:" appear on the bottom of the screen
*in slow motion* (i.e. noticeably slower than 9600 baud). The
slow-motion behavior, then, occurs *only* at the bottom of the screen.

Nathan

Re: [vt4] Slow-motion issue

[Bob A. <bo...@jf...>]

> I still don't understand
>why one entire byte is required per pixel to be redrawn (wouldn't a
>bitmap give you 8 pixels per byte?)

  The VT6 does have one bit per pixel, but I lied a little bit.  The
software doesn't actually output one pixel every 40ns - it can't; it's just
not that fast.  But it can generate one byte, containing 8 pixels, every
320ns.  The hardware in the VT6 takes care of converting each byte into
eight separate pixels.  It's a compromise between speed and hardware cost.

  I'm not sure of the context for this question, so I'm not sure this answer
will address it.


> nor do I understand why these
>pixel-descriptions are being sent, at 9600 baud, over the serial line.

  If you mean the serial line from the host, then they're not of course.
I'm not sure what James or I said that led you to this conclusion.

Bob

Re: [vt4] Slow-motion issue

[Nathan C. <pre...@gm...>]

Hi Bob & James:

Thanks for your patience and explanations. I still don't understand
why one entire byte is required per pixel to be redrawn (wouldn't a
bitmap give you 8 pixels per byte?), nor do I understand why these
pixel-descriptions are being sent, at 9600 baud, over the serial line.

In any case, I am content to wait and see what fix/optimization James
comes up with, or to simply live with the behavior. It's not a big
deal, as long as I take care to make sure I don't tell EDT to list the
entire buffer while it's in this state.

Nathan

Re: [vt4] CR LF insertion bug

[Bob A. <bo...@jf...>]

> Are you sure there's no chance that the computer is actually sending
> the extra CR LF characters to the terminal?  

  How about making an RS232 "T" connector, with one branch connected to the
VT6 and the other to a PC.  Run some terminal emulator (HyperTerm will do)
on the PC and log the characters received.  That'll settle the question of
"what is the host actually sending"?

  That's assuming, of course, that you don't have a protocol analyzer that
does RS232 ...

Bob

Re: [vt4] Slow-motion issue

[Bob A. <bo...@jf...>]

>>  At 9600 baud, that's 960 characters per second.
>Everything was clear to me up until that last sentence

  What James is saying is that at 9600 baud the host can send one character every millisecond (approximately - it's actually a tiny bit longer than that).  The VT6 takes longer than that to shift a line over when a character is being inserted, so the VT6 gets behind.

>Is this what is slowing it down? I don't understand what "shifted out
>serially to drive the VGA display" means, but then again I no nothing
>about how computers communicate with monitors over the VGA cable.

  VGA (and most displays in general) are scanned.  The image is generated one pixel at a time, left to right and top to bottom.  The image is refreshed (i.e. the scan is repeated) a hundred times a second (more or less, depending on the refresh rate of your display).  The VT6 is sending pixels to the display at about 25MHz, or 40ns per pixel.  

  Traditionally most of the display scanning is done with specialized hardware, but on the VT6 most of the work is done by software to reduce the amount of hardware required and the cost.  It's actually mildly amazing (at least to me, but then I'm an old school guy) that an embedded microprocessor can go that fast, but the VT6 has roughly a 25MIPs CPU.  Unfortunately, just refreshing the display takes up most of the CPU's time, so the time it has left to do other things, like receive characters from the host and shift text around, is limited.

Bob

[vt4] Slow-motion issue

[Nathan C. <pre...@gm...>]

> insert mode is much less efficient, since every new character
> requires that every other character to the right be shifted.

The difference between insert and replace mode in the VT220 is clear
to me. What I meant to say is that EDT almost certainly has lots of
clever optimizations built in for use at low baud rates. Hence I doubt
that it just plops the terminal into insert mode and leaves it there,
even though by default whatever the user types is inserted at the
cursor (characters to the right are moved over, not overwritten).

> What I meant by "long time" is that insert mode wasn't being used for
> an occasional insertion when needed, but was being used even when there
> is nothing to the right to be shifted.

This is a hypothesis, though, at this point - if I understood you correctly.

> An old terminal, such as a VT220, is a "character" display terminal.  It
> has a memory inside of it that stores each of the characters to be
> displayed on the screen. . . . The VT6 is a "graphics" display.  It has a
> big memory with a bit in it for every pixel on the screen.  In order to
> shift the characters, all of the pixels in the memory to the right of the
> cursor must be redrawn.  . . . But, for the little processor in the VT6,
> that's a lot of bytes to copy and takes a long time.  At 9600 baud, that's
> 960 characters per second.

Everything was clear to me up until that last sentence. The
communications taking place at 9600 baud are between the computer and
the VT6. Those are not pixel- or graphics-based, but rather
character-based communications. The communications that you're
referring to (pixels to be redrawn) must be taking place within the
VT6 itself. In the VT6 manual, I read:

"The  video  generation  is  done  by  a  combination  of  hardware
and  firmware.    The  hardware
generates the basic horizontal timing, and for each active scan line
it signals the software when it
is time to begin generating pixels.  The  firmware is then responsible
for transferring bytes  from
the frame buffer to the hardware video shift register, which is then
shifted out serially to drive the
VGA  display.   The  video  shift  register  hardware  contains  no
synchronization  logic,  and  the
firmware must output one byte exactly every eight clock cycles to
avoid glitching the video.   After
80  bytes  (640  pixels)  have  been  transferred,  the  firmware  is
free  to  do  whatever  it  wants  (i.e.
process keyboard and serial port input and generally act like a
terminal) until it’s time to generate
the video for the next scan line."

Is this what is slowing it down? I don't understand what "shifted out
serially to drive the VGA display" means, but then again I no nothing
about how computers communicate with monitors over the VGA cable.
Still, it would surprise me if the communications over the VGA cable
were taking place at 9600 baud. (!)

> It's not a bug, so much as a performance limitation on what the
> terminal is capable of, without some clever optimization.  Both the
> VT6 hardware and firmware are loaded with various clever optimizations
> which is why it even works at all at 9600 baud.  One more is needed ...

OK, but I still think it would be a good idea - when you get some time
this weekend - to run the code I sent, so you can see the behavior
with your own eyes.

If I understand you correctly, what you're saying implies that the
code to trigger this performance issue could be very much simplified -
down to a single escape sequence to put the terminal into insert mode.
Everything after that will be slowed down. Correct? (This doesn't ring
true to me, but I'm willing to try it if you say it is so.)

Nathan

Re: [vt4] Reply to James

[James A. M. <ja...@ma...>]

Nathan,

> Slow-motion bug:
> 
> > My suspicion is that the terminal remains in insert mode for a long time
> > and that is what is slowing it down.
> 
> I don't follow you here. What do you mean by "a long time?" Let's
> leave EDT out of the picture for now, since you said you don't have
> it. The terminal enters and leaves the slow-motion state immediately
> upon receiving the sequences shown in the code I sent. So it's a bug
> that can be turned on and off like a light bulb.

"Insert" and "replace" are modes in the VT220 (or VT6).  When the
terminal is in replace mode, every time a printable character is
received, it is just put onto the screen at the correct place.

When the terminal is in insert mode, every time a printable character
is received, all characters to the right are shifted, then the
character is put onto the screen.

So, insert mode is much less efficient, since every new character
requires that every other character to the right be shifted.

What I meant by "long time" is that insert mode wasn't being used for
an occasional insertion when needed, but was being used even when there
is nothing to the right to be shifted.

Why it's slower on a VT6 than a VT220 (or other really old terminal):

An old terminal, such as a VT220, is a "character" display terminal.  It
has a memory inside of it that stores each of the characters to be
displayed on the screen.  When the terminal is in insert mode, it
must copy the characters (one byte each), that are to the right of the
cursor.  That's at most 79 characters (bytes) to copy when the cursor
is at the left margin.

The VT6 is a "graphics" display.  It has a big memory with a bit in it
for every pixel on the screen.  In order to shift the characters,
all of the pixels in the memory to the right of the cursor must be
redrawn.  A character on the display uses 8 pixels times 16 raster lines
on the screen, for a total of 16 bytes.  So, if a character is inserted
at the beginning of the line, then 79 characters must be moved, for a
total of 79*16 = 1264 bytes.

When you are using a modern workstation, the multi-GHz processor and
memory system can copy these pixels in an imperceptible time, which is
why someone is unlikely to notice on a workstation.  But, for the little
processor in the VT6, that's a lot of bytes to copy and takes a long
time.  At 9600 baud, that's 960 characters per second.  If the average
line is 60 bytes in length (a pure guess), then the average number
of characters to be shifted is 50 (I'm rounding the average of 79 and 20
here).  That's 960*50*16*2 = 1536000 memory accesses per second (the
extra factor of 2 is because the memory must be both read and written), not
including everything else the terminal must be doing.  The VT6 just
can't keep up.

It's not a bug, so much as a performance limitation on what the
terminal is capable of, without some clever optimization.  Both the VT6
hardware and firmware are loaded with various clever optimizations
which is why it even works at all at 9600 baud.  One more is needed ...

The good news is that the VT6 has a large input buffer that stores received
characters while it is busy painting the previous ones on the screen.  This
means that the second solution I outlined (look ahead to see how many
characters will be inserted) would substantially reduce the amount of
copying.  Again, assuming an average of 60 characters on a line, then
only a single shift of 20 characters would be required for each 60 characters
received.  The total number of memory accesses for the shifting portion
of the work would be 960/60*20*16*2 = 10240.  This is 150 times faster.
But that's still a lot of memory accesses: consider that painting the
screen with 960 characters per second requires 960*16*2 = 30720 accesses
per second.  Even with this optimization, the shifting would still be
33% additional work compared to replace mode.

The actual results will be somewhat different, since extra memory accesses
are required to look ahead in the buffer, etc.

> CR LF insertion bug:
> 
> > Is the terminal in smooth scroll mode when you do this?
> 
> I don't think so. I didn't know the VT6 had smooth-scroll capability.
> If it does have it, how do I turn it on? I don't see anything about
> smooth-scroll in the setup screen.

Smooth scrolling is enabled by a standard VT220 escape sequence.  My only
reason for asking is that there is a special optimization in the firmware
to deal with this and buffering.  Since the problem is something on the
Linux system, not the VT6, my question is no longer relevant.

James Markevitch

[vt4] Reply to James

[Nathan C. <pre...@gm...>]

Hi James, thanks for taking a look at my bug reports, and for your
initial comments. I'm not receiving emails from the list for some
reason (I've reported this to Bob Armstrong), but I read your replies
on the list archive.

Slow-motion bug:

> My suspicion is that the terminal remains in insert mode for a long time
> and that is what is slowing it down.

I don't follow you here. What do you mean by "a long time?" Let's
leave EDT out of the picture for now, since you said you don't have
it. The terminal enters and leaves the slow-motion state immediately
upon receiving the sequences shown in the code I sent. So it's a bug
that can be turned on and off like a light bulb.

> In insert mode, whenever a character
> is displayed, the entire line to the right of it must be scrolled to make
> room for the new character.  For a 1970's-era terminal, that meant copying
> 80 bytes or so.  In this case, 1280 bytes must be copied (16 times as
> many) and they are copied by a processor instead of hardware.

I understand that, in insert mode, the portion of the line to the
right of the cursor must be rewritten when a character is inserted. I
do not understand why, on the VT6, 1280 bytes must be copied? Are you
saying the VT6 is writing 1280 bytes for each character that is
written to the screen? That would take a long time - especially at
9600 baud, which is what I'm using. And in its day EDT saw heavy usage
at much lower baud rates than that.

Anyway, I hope the problem will become clearer when you run the C code
snippets I sent and you see what I'm seeing. By the way, do you have a
Linux box that you can connect your VT6 to? It would be nice if we
both had the same or a similar setup. If you like, I can convert the C
code into a shell script using "echo -e" instead of printf, so you
don't have to compile. (Although it's just a simple "gcc -o slow
slow.c" command, provided you have gcc installed.)

I have another terminal here (a CADO Systems C332, which does VT220
emulation). When I run the code on that terminal, there is no
noticeable slow-down.

CR LF insertion bug:

> Is the terminal in smooth scroll mode when you do this?

I don't think so. I didn't know the VT6 had smooth-scroll capability.
If it does have it, how do I turn it on? I don't see anything about
smooth-scroll in the setup screen.

> Does this happen every time?  Are you sure there's no chance that the
> computer is actually sending the extra CR LF characters to the terminal?

Sorry, this bug report was a red herring. The bug is not in the VT6,
because the C332 exhibits the same behavior.

It does happen every time I connect the terminal to a Linux box and
telnet from there to the VAX. Before I wrote the bug report, I should
have connect the terminal to the VAX directly. When I do that, there
is no problem.

So the bug must be elsewhere in the chain Linux serial console ->
Linux telnet -> VAX TCPIP stack -> VAX telnet. You're right, though.
It's a strange bug. If it's in the VAX TCPIP/telnet code, it's also
one that nobody's going to fix.

Nathan

Re: [vt4] Slow-motion bug revisited, no VAX or EDT required

[James A. M. <ja...@ma...>]

Nathan,

As mentioned in the previous e-mail, I likely will not get a chance to
look at anything until this weekend.

I am pretty sure I know what's causing the "slow motion" effect, and
a work-around for it, if any, might be a bunch of code.

>    /* (2) Press the left-arrow key once */
>    printf("\010\033[4h");

The sequence contains "033 [ 4 h" which sets the terminal in "insert" mode
instead of the more typical "replace" mode.

>    /* This is just the EDT initialization routine, copied from slow.c
>     * This will return the VT6 to a sane state.
>     * Presumably there's a more straightforward way of doing this. */
>    printf("\015\012\033\134\033<\233!p\233?6l");
>    printf("\233m\033)0\033[4l\033[H\033[?3l");
>    printf("\033[;22r\033[H\033=\033[J");

This sequence contains "033 [ 4 l" which sets the terminal in "replace" mode.

My suspicion is that the terminal remains in insert mode for a long time
and that is what is slowing it down.  In insert mode, whenever a character
is displayed, the entire line to the right of it must be scrolled to make
room for the new character.  For a 1970's-era terminal, that meant copying
80 bytes or so.  In this case, 1280 bytes must be copied (16 times as
many) and they are copied by a processor instead of hardware.  In the
1970's it was an inefficient mode and with the VT6, it's even less
efficient.

I suspect that EDT is being lazy and since it "knows" that the remainder
of the line is blank, it's no problem to leave the terminal in insert
mode, rather than replace mode.

Two possible ideas on how to mitigate this are: 1) have the firmware
keep track of the last used column on each row and if a character is
being inserted after that, then just draw the character instead of
scrolling the remaining blank characters; or 2) peek ahead at how
many consecutive printable characters are buffered up and scroll the
line by that many characters, rather than one at a time.

The first solution is probably less change to the firmware, but it's
still not trivial, since it's a new data structure that must be updated
whenever a new line scrolls up the screen, etc.  It also only solves
the special case where the remainder of the line is blank.

The second solution breaks some of the abstraction of the terminal, but
may not be that big a deal to implement (whenever an "insert" scroll
happens, scan the input buffer, count the number of consecutive displayable
characters, do one big scroll, and count down until those have all been
displayed, pretending to be in replace mode for that period of time).
The effect might be a little odd visually if the characters to the right
of the insertion point are not blank.  It would not be perceptible for
the case that the characters are already blank.

James Markevitch

Re: [vt4] CR LF insertion bug

[James A. M. <ja...@ma...>]

Nathan,

Thanks for continuing to report what you're seeing.

Things are busy at work this week, so there's a good chance I won't be
able to look at it until the weekend.

> Here is the "Show ctrl2" output of what happens after I enter the password,
> at which point the VT6 stops inserting CR LF:
> 
> P 015 012 a 015 012 s 015 012 s 015 012 w 015 012 o 015 012 r
> 015 012 d 015 012 : 015 012 040 015 012 040 W e l c o m e 040
> 
> (I've left the rest out because at this point the VT6 is behaving
> normally again.)
> 
> So, it appears that the sequence:
> CR LF SPACE CR LF SPACE
> causes the VT6 to stop inserting CR LF.

This is a strange one.  Is the terminal in smooth scroll mode when you
do this?  Does this happen every time?  Are you sure there's no chance
that the computer is actually sending the extra CR LF characters to
the terminal?  Can you reproduce it by typing the sequence in local
mode?

The strangest thing about this is that "Show ctrl2" is showing
what the terminal thinks it is receiving, so if it's a VT6 problem,
then it is likely related to the input buffering.  This will take
some thinking, unless it can be reproduced by just typing the sequence
in local mode.

See next e-mail for a response to the "slow motion" issue.

James Markevitch

Re: [vt4] Slow-motion bug revisited, no VAX or EDT required

[Robert A. <bo...@jf...>]

 

Nathan - 

  The VT4 developer's list does work and we (at least _I_) got your email.


  Realistically, the only person who would be able to adress this bug is
James, and I can't speak for his situation.  He might be busy at work or
on vacation.  Hopefully he'll speak up and let us know. 

 Bob

 On Mon 03/01/11 2:59 PM , "Nathan Cutler" pre...@gm... sent:
  I can get the VT6 to enter what I call a "slow-motion" state by
 running some snippets of code on a Linux box (while logged in using
 the VT6).

 I already reported this bug once, but got no response. I'm assuming
 this is because nobody has EDT. So, I wrote some code to reproduce the
 bug on a plain Linux box. In this email I am including (1) the
 original bug description and (2) some code to reproduce the bug in
 Linux.

 (1) Original bug description

 EDT full-screen editing mode has a keypad function, entitled
 "COMMAND", activated by pressing PF1 followed by 7 on the keypad,
 which displays a prompt ("Command: ") in reverse video on line 23 and
 accepts input from the user (this is for entering line-mode commands
 without leaving full-screen editing mode).

 By pressing the left-arrow key twice before pressing PF1-keypad 7,
 I can get VT6 to enter an undocumented "slow-motion" mode, where
 everything is displayed very slowly (like 300 baud or even less),
 even though the terminal is set to 9600 baud.

 This "slow-motion" state lasts until the next major screen redraw
 (e.g. PREV, NEXT, CTRL/W).

 (2) Code to reproduce bug on a Linux box:

 /*
 * slow.c
 *
 * An attempt to reproduce VT6 slow-motion bug in Linux
 * How to use:
 * 1. run the program
 * 2. hit several times, until VT6 enters slow-motion state
 and program exits
 * 3. when you're tired of the slow-motion state, run "reset.c"
 *
 * Nathan Cutler, 3 Jan 2011
 */

 #include 

 main()
 {
 /* (0) EDT initialization */
 printf("15123313433

[vt4] Slow-motion bug revisited, no VAX or EDT required

[Nathan C. <pre...@gm...>]

I can get the VT6 to enter what I call a "slow-motion" state by
running some snippets of code on a Linux box (while logged in using
the VT6).

I already reported this bug once, but got no response. I'm assuming
this is because nobody has EDT. So, I wrote some code to reproduce the
bug on a plain Linux box. In this email I am including (1) the
original bug description and (2) some code to reproduce the bug in
Linux.

(1) Original bug description

EDT full-screen editing mode has a keypad function, entitled
"COMMAND", activated by pressing PF1 followed by 7 on the keypad,
which displays a prompt ("Command: ") in reverse video on line 23 and
accepts input from the user (this is for entering line-mode commands
without leaving full-screen editing mode).

By pressing the left-arrow key twice before pressing PF1-keypad 7,
I can get VT6 to enter an undocumented "slow-motion" mode, where
everything is displayed very slowly (like 300 baud or even less),
even though the terminal is set to 9600 baud.

This "slow-motion" state lasts until the next major screen redraw
(e.g. PREV, NEXT, CTRL/W).

(2) Code to reproduce bug on a Linux box:

/*
 * slow.c
 *
 * An attempt to reproduce VT6 slow-motion bug in Linux
 * How to use:
 *    1. run the program
 *    2. hit <ENTER> several times, until VT6 enters slow-motion state
and program exits
 *    3. when you're tired of the slow-motion state, run "reset.c"
 *
 * Nathan Cutler, 3 Jan 2011
 */

#include <stdio.h>

main()
{
   /* (0) EDT initialization */
   printf("\015\012\033\134\033<\233!p\233?6l");
   printf("\233m\033)0\033[4l\033[H\033[?3l");
   printf("\033[;22r\033[H\033=\033[J");
   getchar();
   /* (1) type a string */
   printf("\033[Labcdef");
   getchar();
   /* (2) Press the left-arrow key once */
   printf("\010\033[4h");
   getchar();
   /* (3) Press the left-arrow key a second time */
   printf("\010");
   getchar();
   /* (4) Press PF1 and then keypad 7 */
   printf("\033[7m\033[23H\033[KCommand:\040");
   getchar();
   printf("\033[m");
}

/*
 * reset.c
 *
 * A program to return the VT6 to normal after running slow.c
 *
 * Nathan Cutler, 3 Jan 2011
 */

#include <stdio.h>

main()
{
   /* This is just the EDT initialization routine, copied from slow.c
    * This will return the VT6 to a sane state.
    * Presumably there's a more straightforward way of doing this. */
   printf("\015\012\033\134\033<\233!p\233?6l");
   printf("\233m\033)0\033[4l\033[H\033[?3l");
   printf("\033[;22r\033[H\033=\033[J");
}

Can you reproduce the bug now?

Regards,
Nathan

[vt4] New Year's division of labor

[Nathan C. <pre...@gm...>]

I'm eager to continue testing the VT6 firmware. As it is, it is quite
usable, so kudos to James and Bob Armstrong and everyone else who has
worked on this project to date.

But it still has a ways to go before we can really talk about VT220
compatibility.

I have done a fair bit of C coding, although mainly on various
database applications.
Still, if someone would like to assign me a bit of code to work on and
a "TO DO" list, I
could attempt to do more than just test.

Nathan

[vt4] CR LF insertion bug

[Nathan C. <pre...@gm...>]

I think I found another bug in the VT6 firmware.

BACKGROUND: My VT6 is connected to a Linux box as a serial console.
>From there I am telnetting to a VAX with IP address 192.168.1.1.

Here's what I'm seeing on-screen:

livingston@f216:~$ telnet 192.168.1.1


 Welcome to OpenVMS (TM) VAX Operating System, Version V7.3

U
s
e
r
n
a
m
e
:

Here is the same thing in "Show ctrl2" mode:

T r y i n g 040 1 9 2 . 1 6 8 . 1 . 1 . . . 015 012
C o n n e c t e d 040 t o 040 1 9 2 . 1 6 8 . 1 . 1 . 015 012
E s c a p e 040 c h a r a c t e r 040 i s 040 ' ^ ] ' . 015 012
015 012 015 012 040 W e l c o m e 040 t o 040 O p e n V M S 040
( T M ) 040 V A X 040 O p e r a t i n g 040 S y s t e m , 040
V e r s i o n 040 V 7 . 3 040 040 040 040 015 012 015 012
015 U 015 012 s 015 012 e 015 012 r 015 012 n 015 012 a 015 012
m 015 012 e 015 012 : 015 012 040

At this point I type my username ("system") and each letter appears on its own
line, and then the text "Password:" also appears with each letter on its own
line.

I captured what the VAX is sending to the telnet connection. Here is a hexdump:

0000000: 5472 7969 6e67 2031 3932 2e31 3638 2e31  Trying 192.168.1
0000010: 2e31 2e2e 2e0a 436f 6e6e 6563 7465 6420  .1....Connected
0000020: 746f 2031 3932 2e31 3638 2e31 2e31 2e0a  to 192.168.1.1..
0000030: 4573 6361 7065 2063 6861 7261 6374 6572  Escape character
0000040: 2069 7320 275e 5d27 2e0a 0d0a 0d0a 2057   is '^]'...... W
0000050: 656c 636f 6d65 2074 6f20 4f70 656e 564d  elcome to OpenVM
0000060: 5320 2854 4d29 2056 4158 204f 7065 7261  S (TM) VAX Opera
0000070: 7469 6e67 2053 7973 7465 6d2c 2056 6572  ting System, Ver
0000080: 7369 6f6e 2056 372e 3320 2020 200d 0a0d  sion V7.3    ...
0000090: 0a0d 5573 6572 6e61 6d65 3a20 7379 7374  ..Username: syst
00000a0: 656d 0d0a 0d50 6173 7377 6f72 643a 20    em...Password:

And here is the same thing, except this time dumped using
the Linux command "od -c":

0000000   T   r   y   i   n   g       1   9   2   .   1   6   8   .   1
0000020   .   1   .   .   .  \n   C   o   n   n   e   c   t   e   d
0000040   t   o       1   9   2   .   1   6   8   .   1   .   1   .  \n
0000060   E   s   c   a   p   e       c   h   a   r   a   c   t   e   r
0000100       i   s       '   ^   ]   '   .  \n  \r  \n  \r  \n       W
0000120   e   l   c   o   m   e       t   o       O   p   e   n   V   M
0000140   S       (   T   M   )       V   A   X       O   p   e   r   a
0000160   t   i   n   g       S   y   s   t   e   m   ,       V   e   r
0000200   s   i   o   n       V   7   .   3                  \r  \n  \r
0000220  \n  \r   U   s   e   r   n   a   m   e   :       s   y   s   t
0000240   e   m  \r  \n  \r   P   a   s   s   w   o   r   d   :

Note that there is no CR LF after each individual letter of the text
"Username:" (obviously).

Apparently, the VAX outputs the sequence CR LF CR LF CR
and at that point, the VT6 enters a state in which the VT6 sees
fit to insert a CR LF between each character.

It does not remain in this state indefinitely, however.

Here is the "Show ctrl2" output of what happens after I enter the password,
at which point the VT6 stops inserting CR LF:

P 015 012 a 015 012 s 015 012 s 015 012 w 015 012 o 015 012 r
015 012 d 015 012 : 015 012 040 015 012 040 W e l c o m e 040

(I've left the rest out because at this point the VT6 is behaving
normally again.)

So, it appears that the sequence:
CR LF SPACE CR LF SPACE
causes the VT6 to stop inserting CR LF.

Thanks,
Nathan

[vt4] Test - please reply

[Nathan C. <pre...@gm...>]

Hello James and anyone else listening on this channel.

I'm continuing to test the VT6 and found another bug. Before I post a
description, can you please reply to this test message.

Thanks,
Nathan

Re: [vt4] [sparetimegizmos] VT6 raw-mode update

[Nathan C. <pre...@gm...>]

First off, I set up an account on sourceforge.net (display name "Smith
Farm") and subscribed to vt4-develop. However, it appears this must be
approved by Bob the moderator. Bob, can you approve me?

Second, I found another bug that I'm capable of reproducing using EDT.
This bug is more subtle. I will try to describe it first, and then
reproduce the key presses and control sequences.

Description of bug:

EDT full-screen editing mode has a keypad function, entitled
"COMMAND", activated by pressing PF1 followed by 7 on the keypad,
which displays a prompt ("Command: ") in reverse video on line 23 and
accepts input from the user (this is for entering line-mode commands
without leaving full-screen editing mode).

By pressing the left-arrow key twice, I can get VT6 to enter a strange
state where it displays the string "Command: " and the output of
whatever command I enter after that prompt at a very slow rate. As if
it suddenly switched to 300 baud.

This "slow-motion" state lasts until the next major screen redraw
(e.g. PREV, NEXT, CTRL/W).

How to reproduce the bug (Show ctrl 2 output attached to each step)

In EDT full-screen editing mode:

(1) Type a string (I typed "abcdef")
ESC [ L a b c d e f

(2) Press the left-arrow key once
010 ESC [ 4 h

(3) Press the left-arrow key a second time
010

(4) Press PF1 and then keypad 7
ESC [ 7 m ESC [ 2 3 H ESC [ K C o m m a n d : 040

(The reverse-video string "Command: " appears on line 23  *in slow motion*)

Nathan