Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!ADMIN.HumberC.ON.CA!GRAY From: GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) Newsgroups: comp.sys.apple2 Subject: Re: Apple can't keep up with 2400 baud Message-ID: <90Jul6.144509edt.57370@ugw.utcs.utoronto.ca> Date: 6 Jul 90 18:27:18 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 58 Chris Wicklein writes: > In-Reply-To: message from GRAY@ADMIN.HumberC.ON.CA > Unless I read you wrong, you're saying -NO- Apple II can run an > 80-col. display @ 1200 or more bps?!?!?! Do you mean that the original > Apple II / Apple II+ can't, rather than the whole family? Allow me to clarify my original remarks. The Apple II, ANY Apple II, cannot handle 1200 baud modems without using interrupts. The only exception to this are Apples that have been accelerated by one means or another (Zip chip or Transwarp) The reason for this is very simple. In the //e, there are 80x24 memory locations to be updated each and every time the screen scrolls a line. That is 1920 memory locations. The fastest way to update that memory would be with 1920 LDA #### STA #### instructions. At eight clock cycles per memory location updated, that would take 15,360 clock cycles, or 15.36 milliseconds to complete the scroll. Most screen handling routines use a loop instead of wasting 11K+ of memory for the scrolling code, so the scrolling time is usually much worse than that. (extra time needed to update pointers etc.) At 1200 baud, a new character arrives every 8.3 milliseconds, and if the CPU is busy scrolling the screen, all but one of the two or three characters that arrive during the scrolling will be lost. Apple II+ 80 column cards like the Videx Videoterm make use of a CRT controller chip, and handle the scrolling by simply updating registers in the chip, but the screen clear function still requires the updating of those 1920 memory locations, so some (although fewer) characters will still be lost. There are several ways to solve the timing problems. One method is to write a custom screen handler that checks the serial port frequently while in the middle of screen scrolling. The main difficulty with this is the difficulty in writing a routine that can handle different combinations of 80 column hardware and serial ports, and the fact that the custom routine often can't use a lot of the features that the hardware may be capable of. The most common method of solving the problem is to use an interrupt handler to get characters from the serial port, and place them in a buffer. The main program then checks the buffer when it is ready for a new character. This has the advantage of requiring only a different interrupt handler to handle different serial ports, and it is FAST. Using interrupts, a stock 1Mhz Apple IIe can handle characters at baud rates up to 50,000 or more! BTW for those of you who may not remember, this discussion started as a result of a question from someone who, because of his particular hardware, could not use any of the available communications software, and would have a VERY difficult time of writing an interrupt handler patch to the software he did have. I saw a message to the effect that someone had already written the needed routine, so I think this has gone about as far as it needs to. Kelly Gray (GRAY@ADMIN.HUMBERC.ON.CA)