paul@athertn.Atherton.COM (Paul Sander) (09/11/89)
In article <8909092230.AA26919@uunet.uu.net>, king@ivory.UUCP (Steven King) writes: > Although I haven't tried it myself, I think that if properly done an interrupt > driven system wouldn't lose characters. You set up a large queue (probably > about 1 to 5 K). Whenever a character comes in from the remote system it > triggers and interrupt and is stored in the queue. Now, when the graphics > routine *finally* gets done with what it's doing the queue is searched for > incoming characters. With this kind of set up you'd only lose characters if > you had MASSIVE amounts of text coming in; enough to overflow the queue. Most > applications (say, calling the local BBS or calling into work) don't deal with > that much data at once. There's usually a prompt that will come up ahead of > time ([MORE] after a page of text, f'rinstance) that will let the graphics > routine catch up. If there was a problem of queue overflow, the computer > could possibly send an XOFF or some other sort of handshaking when the queue > started getting full, let the queue get printed, and send XON to start the > flow again. Using the double-hi-res screen probably WOULD be painfully slow, > though! Two things: A 2K buffer is all that is needed to store a single screenful of text. Most systems I've ever used that stream their output without some sort of automatic paging understand XON-XOFF protocol, so implementing the queue with high- and low-water marks and sending appropriate handshaking characters shouldn't let any characters go. Second, using hi-res graphics text doesn't have to be slow. It all depends on how you do it. I've gotten such things working on a ][ Plus, though it still wasn't fast enough to keep up with 1200 bps while scrolling. But it did run fairly fast when drawing characters (in a 7x12 grid instead of the more conventional 7x8 grid) and scrolling was quick to the eye. [Jason Blochowiak wrote:] > > The one thing I > > haven't seen yet is a transfer protocol that lets you continue with other > > things normally. As in, while the term program & BBS are (bi-directionally?) > > exchanging files, you can go on with viewing posts. > > A couple years ago in college some friends and I tried to design such a beast. [stuff about the "Houghton Terminal Protocol omitted] > > Of course, the BBS would need > > a packet interpreter as a front end to keep the BBS itself from having to deal > > with the nasty details. > > You hit upon one of our problems. This was going to be a BIG project, just > to design the specs. Then we'd have to sit down and write the end-user > programs (I was going to write the Apple version, using the double-hi-res > screen like we talked about above) and someone would have to write a BBS that > would take advantage of all of it. Most of us were trying to graduate at > the time, and it was just too much for us. > [stuff about Amigas and "Diga!" omitted] There's a guy named Asko Kauppi in Finland who's taking on this challenge. He's designed a suitable protocol, and was finding people to develop it along with a number of applications before starting his duty in The Service. I'll forward a copy of this article to him to see if he wants to begin a discussion of his progress here. -- Paul Sander (408) 734-9822 | If a machine is powerful enough paul@Atherton.COM | to have a DWIM button, why bother {decwrl,sun,pyramid}!athertn!paul | with the button? -- Eric Black
kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) (09/11/89)
In article <12526@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >[stuff about Amigas and "Diga!" omitted] > >There's a guy named Asko Kauppi in Finland who's taking on this challenge. He's >designed a suitable protocol, and was finding people to develop it along with >a number of applications before starting his duty in The Service. I'll forward >a copy of this article to him to see if he wants to begin a discussion of his >progress here. I should like to remind people that several years ago a program called Cat-fur was written. It allowed two users to chat while simultaneously sending a file (or disk). Similar programs appeared about the same time allowing a transfer to occur IN BOTH DIRECTIONS at the same time--both sides would be sending and receiving at once. Although most of these programs were designed specifically for the Apple Cat modem, the reason was simple--the Apple Cat had a special mode of half duplex 1200 baud in its 300 baud model. That is, for the price of the 300 baud model, these special programs could achieve 1200 baud transfer rates! No special tricks were invlolved--it just relied on the fact that the Apple Cat 300 baud modem was a very impressive piece of technology: It contained a 8 bit D/A converter (for creating the Touch-Tone signals), independent send/receive baud rates (along with fully adjustable carrier tones, too--you could use a 300 baud carrier during 1200 baud transmissions if you so desired...or have the receive line receiving at 1200 baud while sending data at 300 baud), an option for a touch-tone decoder chip, and option for BSR control, and option for a serial port add-on (so that an external modem or printer could be hooked up), control for an external tape drive (so that you could build your own answering machine), etc. Actually, everything but the touch-tone decoder chip was built-in--all of the other 'add-ons' were merely adapters. So, in terms of this 'chat' option being a new idea--it most certainly is not. Cat-Fur is at least 5 years old, if not more. It most certainly is older than the wide-spread acceptance on 1200 baud. Kent Dickey kadickey@phoenix.Princeton.EDU
mikes@ncsuvx.ncsu.edu (Michael Steele) (09/12/89)
In article <12526@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >[Jason Blochowiak wrote:] >>> The one thing I >>> haven't seen yet is a transfer protocol that lets you continue with other >>> things normally. As in, while the term program & BBS are (bi-directionally?) >>> exchanging files, you can go on with viewing posts. I am at a Computer Theme program here at NC State and we are working on such a Beast for UNIX. What we plan to do is write a multi-windowing interface for the Apple IIGS, IBM, Mac, Amiga, and Atari ST that will use a standard Packet switched interface to a UNIX based system. It will have the concepts of a striped down X windows: allowing multiple sessions on different computers and transparent file transfers. Michael Steele mikes@ncsuvx.ncsu.edu mikes@shumv1.ncsu.edu netoprms@ncsuvm.bitnet -- Michael Steele mikes@ncsuvx.ncsu.edu mikes@ncsuctix.ncsuvx.ncsu.edu netoprms@ncsuvm.bitnet
T8M-KAUP@FINTUVM.BITNET (Asko Kauppi) (09/24/89)
-< Sorry, it got a bit too long. Important things start on line 38... >- On September the 10th, Paul Sander wrote: > There's a guy named Asko Kauppi in Finland who's taking on this challenge. > He's designed a suitable protocol, and was finding people to develop it along > with a number of applications before starting his duty in The Service. I'll > forward a copy of this article to him to see if he wants to begin > a discussion of his progress here. Yes, that might be appropriate. There hasn't been much progress, though, as I had to start my 11 months in "The Service" in June. Still got 225 days to go... All the same, I try to get further with my idea even in the primitive army conditions. I have a Zenith CGA 8086 portable with me, so I'm not complitely tied to pure paper. I have also found that long marches are quite good situations for letting the ideas flow in my head. Try it: some 20 kilometers carrying a 30kg sack and you're bound to get a solution to your problem... ;-) So far, I have re-designed my communications protocol at least five or six times, the first ones dating as far as July 1988. During each pass, the protocol has gotten better and better, simpler and simpler. I certainly AM a perfectionist, so only the absolutely best is good enough for me. At the moment, my 'baby' is nearly finished. I still want to give it one more pass to get all the details written clearly and understandably: My current notes were of no help to anyone else but me myself. When I get the thing 'clean' enough, I'll probably send it over for public discussion. I doubt you could come up with better solutions than I have (well, I've spent a year developing it, haven't I...), but all the same you must be curious and certainly must have varying opinions on some aspects. Just wait and see (and hope I have enough spare time among my combat training). Here are SOME main points of my protocol: The goal: To give powerful remote windowing and graphics abilities at even as low a bandwidths as 1200 bps. The means: 1) Use MACROS. Often used command sequences can be stored on the terminal's (disk) storage and later on called with varying parameters. 2) Use asyncronous bitstring transfer. Long pieces of data (text, picture bitmaps, files...) are transferred at the connection's 'spare time', using various priorities. Other, more important packets are sent prior to these (files up/download at the background, pictures appear gradually when everything else is going on normally...) Comparable to multitasking vs. monotasking. 3) ALL data fields are of dynamical length. If we need sharp coordinates, we give them 16 bits each, if not, some 6 might be enough. The coordinate system is of NAPLPS type: (0,0) - (1,1) and between. 4) Use heavy, automatic compressing. Other points: - CAD-like graphics are created using AbiScript, a sort of a binary coded subset of PostScript (19 commands). - BOBs (Blitter OBjects: Amiga terminology) are included for the sake of remote arcade (and other) games. Some people will just LOVE it| - Sampled sound, of course - with multiple channels... If it sounds a bit too ambitious, I can assure you that my purpose by no means is to do it all at once. It is nice to have the total protocol defined before you start implementing any of it: you won't have to make any of those irritating 'extensions' all standards are filled with. The next thing to do after proof-reading the final(?) protocol papers will be to deside, which areas to implement first. I think I'll start with the drawing commands without any windowing, sound, fonts, BOBs or any extra. After that I'll perhaps introduce windowing and then all the rest... At some point, someone should put up a nice BBS program for my magnificient (it is|) protocol. Quite a lot of work to do, at least when you're alone and in the army... Anyway, thanks for following this far - you must be truly interested on the subject. If you want to reach me, it might be easier by conventional post (I get holidays every 2 weeks or so) sent directly to the army base. I do have other things to do on my holidays than replying KBs of electronic mail... Yours binary, / Asko / Army addr: Oppilas Kauppi AP, KrhJ/AUK/PorPr, PL 5, 27911 HRINNE, FINLAND _____________________________________________________________________ Asko Kauppi alias T8M-KAUP at FINTUVM.BITNET (BitNet MAMMUTTI.UTU.FI (InterNet Student of Physics Turku University addr: Kakskerrantie 176, 20960 Turku, FINLAND Finland tel : +358 (9)21 588 359 / 588 434
blochowi@rt5.cs.wisc.edu (Jason Blochowiak) (09/26/89)
Pardon the sarcasm, but does it come with a kitchen sink? The reason
that standards have extensions is because nobody (not even someone with a
protocol as grandio-, uh, magnificent as yours) can predict what will work well
in the real world. Perhaps defining a prioritized pseudo multi-channel mux/de-
mux would work out well, even with some form of optional automatic compression.
However, it would seem that design of the higher layers would be more efficient
if they were optimized around a _tested_ data transfer layer. This might not be
quite so important, but we are talking about micros here, and if you're worried
about low bandwidth (1200 bps) communication, you're probably not talking
about people with 50Mhz 68040 machines...
--
Jason Blochowiak - back at school (again).
blochowi@garfield.cs.wisc.edu or jason@madnix.UUCP
"What's up pruneface?" - Bugs Bunny in the year 2000