Forum unknown
· Telecommunications
#xon/xoff
19 messages in this thread
What you _ought_ to be able to do is test the screen handling functions to
determine if they are willing to display a character RIGHT NOW. If a
direct-to-screen pipe isn't open at that moment, then shuffle the current
character into a small ring buffer and go do something else, like handle the
keyboard, the serial port, or whatever. When it's convenient, go back and
see if now is a good time for the screen — if so, squirt out the buffered
characters.
The question is, how to tell if the screen handling functions are poised to
write those characters? The VIO-X10 card I've wire wrapped into my vintage
8-banger puts up an I'm-not-ready-bit on its status port if it can't take a
character just yet; /where/ is the equivalent Amiga hook? Or is screen
handling so muffled in windows and multi-tasking that you can't tell?
It shouldn't be necessary to ask the screen if it is ready or not. All that
need be done is to always get all the characters you can from the serial
port. I'm so frustrated with trying to explain it that I am writing a
terminal of my own, but it is slow going.
Yes, but there's a lot of sleepy time between characters — how do you decide
when you've gotten all characters pending from the current burst, and it's
time to update the screen? Try this pseudo-code skeleton:
while (carrier_detect)
while (serial port has a character)
get (in_character from serial port)
send (in_character to buffer)
if (screen is ready)
send (buffer to screen)
while (keyboard has a character)
get (out_character from keyboard)
send (out_character to serial port)
there is no such thing as "screen read." try this:
while (serial has char)
put serial char in buffer
if (keyboard has char)
send keyboard char
endwhile
put serial input buffer to screen
repeat
–Scotty
Point of information. Could one have two or more tasks? One would accept
keyboard input and accept serial incoming signals and write to the buffer.
Another would constantly squirt the buffer to the screen. The screen painter
would have a lower priority. Also, if one wanted to use bursts of characters
for speed, could you not have a one line window at the bottom of the screen
which acts like a typewriter — ie always displays a stream of characters as
typed centered on the screen. The main window would show the input — either
the serial input or formatted text from a WP or whatever. Chris
Point of information. Could one have two or more tasks? One would accept
keyboard input and accept serial incoming signals and write to the buffer.
Another would constantly squirt the buffer to the screen. The screen painter
would have a lower priority. Also, if one wanted to use bursts of characters
for speed, could you not have a one line window at the bottom of the screen
which acts like a typewriter — ie always displays a stream of characters as
typed centered on the screen. The main window would show the input — either
the serial input or formatted text from a WP or whatever. Chris
there is no such thing as "screen read." try this:
while (serial has char)
put serial char in buffer
if (keyboard has char)
send keyboard char
endwhile
put serial input buffer to screen
repeat
–Scotty
Richard, the problem with that code is twofold.
1. You are still doing single character I/O, with it's unacceptable overhead
required to set up the blitter to do the transfer.
2. It runs the CPU all the time, and thus is not "friendly" to tasks with
lower priority.
I was thinking more along the following lines. Assume that we come out of our
Wait() (as does Aterm) because we have received an Intuition message telling
us that something needs our attention.
REPEAT
GET (char from serial)
PUT (char to buffer)
UNTIL (char = 0)
Write() (buffer to screen)
GoBackToSleep
This is of course very general, and assumes we were awakened by the serial
port message, but it should work fine. (This is approximately the way
recommended by someone at Amiga when asked why term progs could not keep up)
You are right about the "sleepy time" between characters, but perhaps you
aren't aware of the enormous overhead required to do single character I/O to
the screen. What the above will do is to "catch up" ever time it goes to the
serial port, no matter how long our delay was.
Larry, that's very interesting, and it's how I'm doing it in Starterm 3.0.
I'm actually doing check on the number of characters in the serial buffer..
doing a block read, and then convert the buffer and do a block write to the
console device. it works quite nicely. Jim
Hmm..For some ideas on StarTerm 3.0, you might want to contact David
Berezowski at CBM. He's the guy who did AmigaTerm, the program to be shipped
with the CBM modem (am playing with a demo of it now)…The thing is OK, but
throughput is BLINDING (I connected it with our work VAX and ran it at 19.2
KBaud on our LAN…It kept up without half trying (PM showed very little CPU
use).. ) Would LOVE to see source to this baby (It looks like it could keep
up with the 32.4 Kbaud max of the serial port) but he limited it to a top
speed of 19.2KBaud. Oh well. 😐 Anyway, you two oughta get together. If you
combined the best features of AmigaTerm (INSTANT interlace for 49 lines of
text, CIS-B and relaxed XMODEM, other things) and the best of StarTerm 2.0
(auto XMODEM pad strip, phonebook, storeable function key defs) you'd have
the BEST term program available anywhere! Only thing is..Someone should tell
CBM that menus are good, but can be carried too far.. This thing has a
Project Menu that spans the entire screen!
Hmm..For some ideas on StarTerm 3.0, you might want to contact David
Berezowski at CBM. He's the guy who did AmigaTerm, the program to be shipped
with the CBM modem (am playing with a demo of it now)…The thing is OK, but
throughput is BLINDING (I connected it with our work VAX and ran it at 19.2
KBaud on our LAN…It kept up without half trying (PM showed very little CPU
use).. ) Would LOVE to see source to this baby (It looks like it could keep
up with the 32.4 Kbaud max of the serial port) but he limited it to a top
speed of 19.2KBaud. Oh well. 😐 Anyway, you two oughta get together. If you
combined the best features of AmigaTerm (INSTANT interlace for 49 lines of
text, CIS-B and relaxed XMODEM, other things) and the best of StarTerm 2.0
(auto XMODEM pad strip, phonebook, storeable function key defs) you'd have
the BEST term program available anywhere! Only thing is..Someone should tell
CBM that menus are good, but can be carried too far.. This thing has a
Project Menu that spans the entire screen!
i've been reading this thread waiting for SOMEONE to mention SDCMD_QUERY.
before you do a CMD_READ, set io_Command to this value and DoIO(). upon
return, io_Actual contains the number of characters in the serial.device
input buffer waiting to be read. use that value (or 1 if it's 0) for
io_Length of your CMD_READ request. changing the subject slightly, i see a
lot of serial device programs doing a lot of busy waiting on CheckIO(). be
ashamed of yourselves! join the multi-tasking generation! let Exec do the
waiting for you, productively. other tasks can do useful work meanwhile. do
you really want to try to run an editor in a second window while your
download is soaking cycles waiting for a slow modem?
i've been reading this thread waiting for SOMEONE to mention SDCMD_QUERY.
before you do a CMD_READ, set io_Command to this value and DoIO(). upon
return, io_Actual contains the number of characters in the serial.device
input buffer waiting to be read. use that value (or 1 if it's 0) for
io_Length of your CMD_READ request. changing the subject slightly, i see a
lot of serial device programs doing a lot of busy waiting on CheckIO(). be
ashamed of yourselves! join the multi-tasking generation! let Exec do the
waiting for you, productively. other tasks can do useful work meanwhile. do
you really want to try to run an editor in a second window while your
download is soaking cycles waiting for a slow modem?
Larry, that's very interesting, and it's how I'm doing it in Starterm 3.0.
I'm actually doing check on the number of characters in the serial buffer..
doing a block read, and then convert the buffer and do a block write to the
console device. it works quite nicely. Jim
Richard, the problem with that code is twofold.
1. You are still doing single character I/O, with it's unacceptable overhead
required to set up the blitter to do the transfer.
2. It runs the CPU all the time, and thus is not "friendly" to tasks with
lower priority.
I was thinking more along the following lines. Assume that we come out of our
Wait() (as does Aterm) because we have received an Intuition message telling
us that something needs our attention.
REPEAT
GET (char from serial)
PUT (char to buffer)
UNTIL (char = 0)
Write() (buffer to screen)
GoBackToSleep
This is of course very general, and assumes we were awakened by the serial
port message, but it should work fine. (This is approximately the way
recommended by someone at Amiga when asked why term progs could not keep up)
You are right about the "sleepy time" between characters, but perhaps you
aren't aware of the enormous overhead required to do single character I/O to
the screen. What the above will do is to "catch up" ever time it goes to the
serial port, no matter how long our delay was.
Yes, but there's a lot of sleepy time between characters — how do you decide
when you've gotten all characters pending from the current burst, and it's
time to update the screen? Try this pseudo-code skeleton:
while (carrier_detect)
while (serial port has a character)
get (in_character from serial port)
send (in_character to buffer)
if (screen is ready)
send (buffer to screen)
while (keyboard has a character)
get (out_character from keyboard)
send (out_character to serial port)
It shouldn't be necessary to ask the screen if it is ready or not. All that
need be done is to always get all the characters you can from the serial
port. I'm so frustrated with trying to explain it that I am writing a
terminal of my own, but it is slow going.
whoah! that video card you're talking about just sits there and accepts
CHARACERS; the amiga's display is memory mapped, bit mapped graphics – the
software has to DRAW the characters, once for each bitplane (one bitplane for
each bit of color – from 1 to 5 times). just to increase the fun, it draws
characters using the blitter, which is kinda like a DMA controller that can
work on bits within words instead of being limited to byte boundaries. the
blitter is in great demand by such things as the disk drive, other
graphics/display functions, and sound, so each task has to wait in line for
the blitter. that's why character output to the display can seem so slow.
in addition, the amount of work needed to set up the blitter to write a
character is pretty large – so if you output just one character at a time
(through the character display system calls) it has to perform that setup
operation once for each character. if you were to display a 20 character
string, it would go MUCH faster if you sent all 20 characters with the same
output call instead of one at a time. –Scotty
whoah! that video card you're talking about just sits there and accepts
CHARACERS; the amiga's display is memory mapped, bit mapped graphics – the
software has to DRAW the characters, once for each bitplane (one bitplane for
each bit of color – from 1 to 5 times). just to increase the fun, it draws
characters using the blitter, which is kinda like a DMA controller that can
work on bits within words instead of being limited to byte boundaries. the
blitter is in great demand by such things as the disk drive, other
graphics/display functions, and sound, so each task has to wait in line for
the blitter. that's why character output to the display can seem so slow.
in addition, the amount of work needed to set up the blitter to write a
character is pretty large – so if you output just one character at a time
(through the character display system calls) it has to perform that setup
operation once for each character. if you were to display a 20 character
string, it would go MUCH faster if you sent all 20 characters with the same
output call instead of one at a time. –Scotty