Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!know!samsung!xylogics!bu.edu!purdue!sage.cc.purdue.edu!ericm From: ericm@sage.cc.purdue.edu (Eric Mulholland) Newsgroups: comp.sys.apple2 Subject: Re: Apple can't keep up with 2400 baud Message-ID: <4346@sage.cc.purdue.edu> Date: 7 Jul 90 01:37:29 GMT References: <90Jul6.144509edt.57370@ugw.utcs.utoronto.ca> Reply-To: ericm@sage.cc.purdue.edu (Eric Mulholland) Organization: Purdue University Lines: 52 GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) writes: >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 Later on you explain how the Apple CAN keep up. Saying that the Apple can't keep up WHILE using the ROM of the cards plugged in would be better. But using a modem at high speeds (ok 1200 isn't high), without interupts is only asking for trouble. >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 This wouldn't be difficult to write, just keep the two routines seperate for the ease of writing and call through vectors to jump between the two. Of course this isn't going to give you the fastest code, but that is the price for writing structured code (not to mention using no interupts). >often can't use a lot of the features that the hardware may be capable of. When I was writing a video driver for a friend's Franklen 1000, I used more hardware features then its ROM did (ever see the ROM give you a 25 line display?). After experimenting with all the video registers, I discovered what most of them controlled. I found the registers while I was looking to see how the video RAM was accessed. (Those wantting this info, convince me to search through a five year stack of notes for it) > 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. Advances in technoligy are so nice to have! Interupts let you run parts of your program only when they are needed. A step in the direction towards multiproccessing. > 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 I'll agree that having odd hardware is a pain in the rear. I once had an inkjet printer connected to my //+ (r.i.p.). I was ready to shout in joy if I could find any program that knew about it. At least the controller card that I got with it had a modified ROM so that the screen dump commands would work with it. Most software is written only for commen hardware configurations because it is hard to get information on the less common hardware and knowing all what is out there. -- ____ Y_,_|[]| Eric Mulholland {|_|_|__| ericm@sage.cc.purdue.edu //oo--OO ...!pur-ee!sage.cc!ericm