wayne@fmsrl7.UUCP (12/04/87)
In article <2893@cbmvax.UUCP> hedley@cbmvax.UUCP (Hedley Davis) writes: > >Standard baud rates for amiga include: > 110,150,300,600,1200,2400,4800,9600,19200 & 31250. > >Hedley I'm probably asking for the world but... Does anyone know of a terminal emulator for the (stock, 512K, 1000) Amiga that will run at 19.2K SUSTAINED? So that I do not get 1000 replies that "foo 1.3 runs at 19.2K", I will explain "sustained". 8 hours of continuous 19.2K transmission with no ^S/^Q or any other software handshaking, no hardware handshaking, data is always being sent (no pauses at all). Dropping even a single character is devastating. Some constraints on multitasking and windowing are acceptable. Scrolling is mandatory, Tek emulation (at speed) very desirable. PD/shareware with source is preferred as this could become part of something MUCH bigger but I am willing to talk to commercial vendors. /\/\ \/\/ -- Michael R. Wayne *** TMC & Associates *** INTERNET: wayne@ford-vax.arpa uucp: {philabs | pyramid} !fmsrl7!wayne OR wayne@fmsrl7.UUCP >> If you own an MPulse, please contact me to exchange info and experiences <<
dragon@oliveb.UUCP (12/05/87)
in article <5171@fmsrl7.UUCP>, wayne@fmsrl7.UUCP (//ichael R. //ayne) says: > ... > will explain "sustained". 8 hours of continuous 19.2K transmission with no > ^S/^Q or any other software handshaking, no hardware handshaking, data is > always being sent (no pauses at all). Dropping even a single character is > devastating. Some constraints on multitasking and windowing are acceptable. > Scrolling is mandatory, Tek emulation (at speed) very desirable. PD/shareware > with source is preferred as this could become part of something MUCH bigger > but I am willing to talk to commercial vendors. _This_ I would like to see on ANY computer! Most computers won't output to a screen at 19.2K baud, let alone 9600. Most terminals won't either. Maybe the closest to this that I've seen is an 80386 machine running XENIX. If there is a term program for the Amiga that can do this, I'd sure be interested in getting it myself. Let's hear it! -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon {ucbvax,etc.}!hplabs!oliveb!dragon-oatc!dean Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ |_____ 'Such a strange girl, I think I'm falling in love' --The Cure
wolf@ssyx.UUCP (12/05/87)
In article <5171@fmsrl7.UUCP> wayne@fmsrl7.UUCP (/\/\ichael R. \/\/ayne) writes: > I'm probably asking for the world but... Does anyone know of a >terminal emulator for the (stock, 512K, 1000) Amiga that will run at 19.2K >SUSTAINED? So that I do not get 1000 replies that "foo 1.3 runs at 19.2K", I >will explain "sustained". 8 hours of continuous 19.2K transmission with no >^S/^Q or any other software handshaking, no hardware handshaking, data is >always being sent (no pauses at all). Dropping even a single character is >devastating. Some constraints on multitasking and windowing are acceptable. >Scrolling is mandatory, Tek emulation (at speed) very desirable. PD/shareware >with source is preferred as this could become part of something MUCH bigger >but I am willing to talk to commercial vendors. > >-- >Michael R. Wayne *** TMC & Associates *** INTERNET: wayne@ford-vax.arpa >uucp: {philabs | pyramid} !fmsrl7!wayne OR wayne@fmsrl7.UUCP >>> If you own an MPulse, please contact me to exchange info and experiences << I've never heard of such a program being available. You'll probably find that you have to write your own. I'm not really sure how possible a program like that would be. When you're using a bitmapped display, scrolling eats a lot of time. The Tek command parsing really slows things down, especially if you're emulating one of the new Teks that takes 3-D coordinates. Pure text ought to be possible, but I'd be impressed if someone could do sustained graphics rendering at that speed. A Tek has a lot of very CPU intensive commands, like patterned fills. You'd almost certainly have to disable multitasking, because another process might take control long enough for you to loose a character. Just what are you going to transfer for 8 hours with no handshaking? +------------------------------------+---------------------------------------+ | Michael Wolf | An old Scandinavian quote: | | BITNET: wolf@ucscj.BITNET | "You can lead a herring to water, | | ARPA: wolf@ssyx.ucsc.edu | but you have to walk real fast, | | UUCP: ...ucbvax!ucscc!ssyx!wolf | or else he'll die." | +------------------------------------+---------------------------------------+
dillon@CORY.BERKELEY.EDU.UUCP (12/05/87)
> ... > will explain "sustained". 8 hours of continuous 19.2K transmission with no > ^S/^Q or any other software handshaking, no hardware handshaking, data is > always being sent (no pauses at all). Dropping even a single character is > devastating. Some constraints on multitasking and windowing are acceptable. > Scrolling is mandatory, Tek emulation (at speed) very desirable. PD/shareware > with source is preferred as this could become part of something MUCH bigger > but I am willing to talk to commercial vendors. Don't be silly. Even Tek terminals have flow-control, and assuming all 55 Meg will get through without an error is ridiculous. The Amiga can read data at that speed, but not scroll at that speed. Sure you could dynamically buffer the data, but *any* computer would get behind... not for simple things like line drawing, but what about area fills and other advance functions? -Matt
papa@pollux.usc.edu (Marco Papa) (12/06/87)
>> ... >> will explain "sustained". 8 hours of continuous 19.2K transmission with no >> ^S/^Q or any other software handshaking, no hardware handshaking, data is >> always being sent (no pauses at all). Dropping even a single character is >> devastating. Some constraints on multitasking and windowing are acceptable. >> Scrolling is mandatory, Tek emulation (at speed) very desirable. PD/shareware >> with source is preferred as this could become part of something MUCH bigger >> but I am willing to talk to commercial vendors. Matt responds: > Don't be silly. Even Tek terminals have flow-control, and assuming >all 55 Meg will get through without an error is ridiculous. The Amiga can >read data at that speed, but not scroll at that speed. Sure you could >dynamically buffer the data, but *any* computer would get behind... not >for simple things like line drawing, but what about area fills and other >advance functions? Having written a commercial Tek emulator for the Amiga, I'd like to comment on this. The A-Talk Plus Tek 4010/4014 emulator, in GRAPHICS drawing mode, can keep up with 9600 bauds with NO loss of characters or overrruns in both 640x400, 640x200, and either 1 or 2 bitplanes [Note the 640x200 non-interlaced mode will be available in the next OXXI version]. I have tested this by sending a 1Meg plot file (made up of lots of plots, with clearscreen commands between them) between an IBM AT and the Amiga at the max IBM speed, which is 9600 bauds. I haven't tried between two directly connected Amigas, but that test is on my queue. Note that I did NOT use any handshake protocol, either Xon/Xoff or CTS. All graphics is done using the blitter, so I suppose it is possible that it will indeed keep up with 19,200. These kinds of speeds are usually not possible with real "tek" terminals, and DEC or clone emulators, which are usually controlled by 8086s and have no blitter chip in them. Most manuals will tell you that one has to use X-on/X-off at speeds higher than 1200 bauds! Note that Tek 4010/4014s (and emulators) DON'T scroll, so that is not a problem). A VT100 or similar emulator is another story. We have tested ours, and found that with input data that includes an "average" amount of scrolling, the emulator will keep up with 7000-8000 bauds. Again this is still better than most "hardware" emulators that will need Xon-Xoff to keep up with high speeds. For the purpose of speed we included a 1-bitplane screen mode, so that less data has to be moved when scrolling. I'll try similar tests on our [unreleased] Tek 4105 (8-color) emulator an see what I get. This does color pattern and area fill, though these are also done through the blitter. -- Marco
bryce@hoser.berkeley.edu (Bryce Nesbitt) (12/06/87)
In article <5171@fmsrl7.UUCP> wayne@fmsrl7.UUCP (/\/\ichael R. \/\/ayne) writes: > >Does anyone know of a >terminal emulator for the (stock, 512K, 1000) Amiga that will run at 19.2K >SUSTAINED?... >Scrolling is mandatory... To start off, no I don't know of a program that will meet your needs, however I can pass on some tips that allow a micro to operate a much higher speeds. (These techniques were used on a program for "another computer") Scrolling once per line adds significant overhead (though extra true- fast ram and the blitter compensate quite a bit on the Amiga). A slick way to reduce this is to add a 6 or more speed manual transmission: You look at the size of your buffer, depending on how far behind you are, scroll up multiple lines. *All* the data makes it on the screen. In general screen output takes much longer than just collecting bytes in a buffer. It would be very possible to have a lower priority sub-task updating the screen. (The two above suggestions apply mostly to a plain text system...) In any case some the of communications programs for the Amiga still request serial.device data a byte at a time. This is *wrong*. Allways to a query and read the number of pending bytes. |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U WARNING: hoser's spool directory eats a *lot* of mail. :-(
msl5864@ritcv.UUCP (Michael S. Leibow) (12/06/87)
>.... 8 hours of continuous 19.2K transmission with no >^S/^Q or any other software handshaking, no hardware handshaking, data is >always being sent (no pauses at all). Dropping even a single character is >devastating. Good Luck. I wrote a VT220 terminal emulator while I was working at DEC as a COOP student. It has TEK and Sixels (no regis). I have worked quite a bit on performance, and never got it to go 19200. It will go faster then 9600, but not as fast as 19200. If you find something that is JUST tek, with nothing else, you might be able to reach 19200. Maybe, if enough people are interested, I will write a TEK emulator with performance as a first goal. --Mike Leibow PS. Don't even ask about getting a copy of the VT220... I cannot give it away because of the employment agreement I signed while working at DEC.
wayne@fmsrl7.UUCP (12/07/87)
Observant readers will note that I prefaced my remark with a
pessamistic prediction... Anyway, for the curious, I was looking to do some
real-time data acquisition from a device that does not support flow control.
Note also that I mentioned that tek emulation was "desireable". This is
actually for another project with similar specs (simple vector drawing only).
Anyway, I have seen terminals that will keep up with continuous 9600 without
flow control, I had hoped that the Amiga could be convinced to do a bit
better and go 19.2K. Looks like I'll have to look elsewhere.
/\/\ \/\/
--
Michael R. Wayne *** TMC & Associates *** INTERNET: wayne@ford-vax.arpa
uucp: {philabs | pyramid} !fmsrl7!wayne OR wayne@fmsrl7.UUCP
>> If you own an MPulse, please contact me to exchange info and experiences <<mp1u+@andrew.cmu.edu (Michael Portuesi) (12/07/87)
dillon@CORY.BERKELEY.EDU (Matt Dillon) writes; > The Amiga can > read data at that speed, but not scroll at that speed. [speed = 19.2Kb] Sure it can. If you set up a circular buffer in memory and set up a copper list to point the hardware at each display line, performing a scroll operation is as easy as updating a few pointers and clearing a line's worth of memory. Of course, this has to be on a custom screen, and you can forget about using any of the system software to do your text rendering and/or your interface stuff, but it *is* possible. I thought about writing such an emulator on the Atari 800, which also has the display hardware to pull off such "tricks," but doesn't have a large complement of system software whose functionality would have to be duplicated for the project. The folks writing software for the Amiga haven't even begun to investigate the kinds of things you can do with "dirty tricks." (which is probably good, since it probably wouldn't stand a chance of running on a future Amiga). The ST people are; witness the recent paint program the ST community has been raving about which displays all 512 colors on the screen with a tight 68000 loop. --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "little things remind me of you...cheap cologne and that damn song too!" --The Flirts, "Jukebox"
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/08/87)
> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes; > >> The Amiga can >> read data at that speed, but not scroll at that speed. > >[speed = 19.2Kb] > >Sure it can. If you set up a circular buffer in memory and set up a copper >list to point the hardware at each display line, performing a scroll operation You didn't reprint enough of my message..... I took buffering into account. The keyword was "sustained", and the original poster also gave a figure on the number of hours (quite a few... forgot the exact number) that it would have to remain sustained without a single lost character... In that case you would need such a huge buffer that it would make more sense to pursue a different solution. :The folks writing software for the Amiga haven't even begun to investigate the :kinds of things you can do with "dirty tricks." (which is probably good, :since it probably wouldn't stand a chance of running on a future Amiga). The :ST people are; witness the recent paint program the ST community has been :raving about which displays all 512 colors on the screen with a tight 68000 :loop. : : --M Your joking, right? (A) it uses 100% of the CPU, (B) it has been done before.... ON A COMMODORE PET!! That's right, in a tight 6502 loop you could create custom characters on the screen. There are more dirty tricks on the Amiga than you can shake a stick at! Look at RainBench, WaveBench, Viacom, etc.... try doing that on an Atari. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/08/87)
: Observant readers will note that I prefaced my remark with a
:pessamistic prediction... Anyway, for the curious, I was looking to do some
:real-time data acquisition from a device that does not support flow control.
:Note also that I mentioned that tek emulation was "desireable". This is
:actually for another project with similar specs (simple vector drawing only).
:Anyway, I have seen terminals that will keep up with continuous 9600 without
:flow control, I had hoped that the Amiga could be convinced to do a bit
:better and go 19.2K. Looks like I'll have to look elsewhere.
You wanted to be able to output to the screen at that speed...
including scrolling.
If you don't include scrolling (or there is very little scrolling)
the Amiga can handle it no-problem. If you want to simply dump to a file
you can go even faster. A tek 4125, for instance, cannot keep at
19.2KBaud for simple pen-settings, move/draw sequences, and that is no
simple workstation.
-Mattewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (12/09/87)
In article <8712080543.AA20025@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Your [sic] joking, right? (A) it uses 100% of the CPU, (B) it has been >done before.... ON A COMMODORE PET!! That's right, in a tight 6502 loop >you could create custom characters on the screen. You remember that program, too? Gee, that was many moons ago. It came on a Cursor tape, as I recall. I disassembled to try and find out what was going on. After about an hour, it dawned on me what he was up to. What a hack! The neatest part about it was that, when you were listing a program on the screen, and it was scrolling away, the "hi-res" window remained in place. First-generation layers :-). >There are more >dirty tricks on the Amiga than you can shake a stick at! Look at RainBench, >WaveBench, Viacom, etc.... try doing that on an Atari. > Your prejudice is showing.... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
lphillips@lpami.van-bc.UUCP (Larry Phillips) (12/13/87)
In article<5279@fmsrl7.UUCP> wayne@fmsrl7.UUCP (//ichael R. //ayne) writes: >Anyway, for the curious, I was looking to do some real-time data >acquisition from a device that does not support flow control. Note also >that I mentioned that tek emulation was "desireable". and ... > Anyway, I have seen terminals that will keep up with continuous 9600 without >flow control, I had hoped that the Amiga could be convinced to do a bit >better and go 19.2K. Looks like I'll have to look elsewhere. Fascinating. My first thought upon reading the previous request for a terminal that would support both Tek emulation and 19.2K baud was that the two criteria don't seem to have much relation to one another. I suppose it's just possible that someone would sit in front of a screen for 8 hours, reading (or watching) data stream in at 19.2K baud, but I somehow think that it's unlikely. Data acquisition is one thing, reading a sustained high data rate is quite another. It should be trivial to capture data at sustained 19.2K baud if one does not need to display it while capturing. Look elsewhere if you want, but I think you'll find that the Amiga can handle it quite well, and possibly better than many other systems that don't have separate tasks taking care of I/O. -- The transistor is a curiosity, and will never amount to much. -- Mr. Stringer, Basic Electronic Instructor, RCAF, 1962. +--------------------------------------------------------------------+ | // Larry Phillips UUCP: lphillips@lpami.van-bc.UUCP | | \X/ or: {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +--------------------------------------------------------------------+
peter@sugar.UUCP (Peter da Silva) (12/14/87)
In article <5568@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > >> will explain "sustained". 8 hours of continuous 19.2K transmission with no > >> ... > >> Scrolling is mandatory... > > Matt responds: > > Don't be silly. Even Tek terminals have flow-control, and assuming > >all 55 Meg will get through without an error is ridiculous. True. > >The Amiga can > >read data at that speed, but not scroll at that speed. Sure it can. It'd take some smarts, but it can. DTerm already does multicharacter reads from the serial.device. Now all you need to do is multiline scrolling. You don't scroll every line, instead if you feel yourself getting behind you jump-scroll 3 or 4 lines at a time. It doesn't take any more time to scroll 4 lines than to scroll one (a blit is a blit, the world around), so if you can scroll at 9600 normally you can jump-scroll at 19.2 by skipping every other scroll when the heat's on. The rest of the problems (like doing area fills at 19.2) are probably real, but this is a paper tiger. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
papa@pollux.usc.edu (Marco Papa) (12/17/87)
In article <1253@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <5568@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> will explain "sustained". 8 hours of continuous 19.2K transmission with no >> >> ... >> >> Scrolling is mandatory... Sorry Peter, but the quote is from the original poster, which both Matt and I responded to. Better check the source next time. Were you sleeping at the time ? :-) >> >> Matt responds: >> > Don't be silly. Even Tek terminals have flow-control, and assuming >> >all 55 Meg will get through without an error is ridiculous. > -- Marco
grr@cbmvax.UUCP (George Robbins) (12/28/87)
In article <1253@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > In article <5568@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: > > >> will explain "sustained". 8 hours of continuous 19.2K transmission with no > > >> ... > > >> Scrolling is mandatory... > > > > Matt responds: > > > Don't be silly. Even Tek terminals have flow-control, and assuming > > >all 55 Meg will get through without an error is ridiculous. > > True. > > > >The Amiga can > > >read data at that speed, but not scroll at that speed. > > Sure it can. It'd take some smarts, but it can. > > DTerm already does multicharacter reads from the serial.device. Now all you > need to do is multiline scrolling. You don't scroll every line, instead if you > feel yourself getting behind you jump-scroll 3 or 4 lines at a time. It doesn't > take any more time to scroll 4 lines than to scroll one (a blit is a blit, > the world around), so if you can scroll at 9600 normally you can jump-scroll > at 19.2 by skipping every other scroll when the heat's on. > > The rest of the problems (like doing area fills at 19.2) are probably real, > but this is a paper tiger. This "can't scroll" is a little silly. It depends somewhat on whether you want your emulator to run on a screen or in a window. If you're in a window, then scrolling basically requires a fair amount of data movement. You can either optimize or cheat to obtain the level of performance you want, although most of the emulator's I've tried aren't as fast as I'd like. If you use a screen, or take over the system, then scrolling is a different matter entirely. You can either play games with the display start pointers or even implement a display list architecture using the copper to reload the pointer for every line. This quickly gets you back to the character rendering time as being the major performance contstraint, and there you can do the traditional simplifications involving byte-wide aligned characters to speed things up. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)