shawn@marilyn.UUCP (Shawn P. Stanley) (06/26/90)
In article <90Jun23.130844edt.57939@ugw.utcs.utoronto.ca> GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) writes: >I don't think that there is ANY 80 column card that the Apple can run fast >enough to keep up with even a 1200 baud modem... >...You don't say which model of Apple II you are using, but it sounds like it >might be a II+. I wrote a terminal program for the Apple II+ a long, long time ago that might be able to keep up, but I wrote it for the hi-res graphics mode (it uses 70 characters per line, and it can be read fine on a monitor). The problem is, it works with the Micromodem II alone. I know I have the S-C Assembler source code somewhere, though. What I did was poll the modem input during character output and in various stages during scrolling. I put all the incoming characters in a buffer to be processed later. This same method can be applied to non-interrupt-driven text/modem I/O on an 80-column screen, if you write your own scroll routines. -- Shawn P. Stanley shawn@marilyn.marilyn.mn.org bungia!marilyn!shawn {rosevax,crash}!orbit!marilyn!shawn
rat@deety.UUCP (David Douthitt) (06/27/90)
I'm running an Apple II+, 4 MHz Zip Chip, 6 MHz PCPI Applicard with ZCPR 3.0 (CP/M) - the serial board is the Apple Super Serial board. The switches all seem to be set appropriately. However, I don't think interrupts will help here. The patch for the CP/M programs I use for the modem talks to the 6522 port directly, using memory peeks and pokes from the CP/M side. Seems to me that there was some sort of Super Serial card support built into the BIOS of the PCPI CP/M. Does anyone know more about this? If that doesn't help, perhaps I should write a driver for the SSC which supports interrupts and get my characters from that. Anyone know how to write PCPI drivers? I thought not. :-( -- ====== David Douthitt ======== aka "The Stainless Steel Rat" ==== UUCP: uwvax!astroatc!nicmad!madnix!deety!rat InterNet: madnix!deety!rat@spool.cs.wisc.edu <<< Home of Mad Apple Forth and the Tiger Toolbox -- Apple II Forever! <<< If my next computer isn't an Apple II, it won't be a Macintosh.
m.tiernan@pro-angmar.UUCP (Michael Tiernan) (06/27/90)
In-Reply-To: message from rat@deety.UUCP
I'd stop hugging my CP/M and start looking at the problem. I'm running 2400
and have been for some time and I'll bet your disk drive that I'm not the only
one. Try turning on the interrupts on the serial port if you can't, don't
complain about the video card. Also, check to make sure that the CP/M
software doesn't lock out interrupts.
<< MCT >>
GEnie : M.Tiernan
AppleLinkPE : M Tiernan or BCS Mike
Internet : pro-angmar!m.tiernan@alphalpha.com
UUCP : ...!uunet!alphalpha!pro-angmar!m.tiernan
"And the sweating of their souls can't wash the blood from off their hands."
- Phil Ochswhitewolf@gnh-starport.cts.com (Tae Song) (06/28/90)
You can activate a 4K input/output buffer on the SSC, by typing Ctrl-A BE. BE is normal letters. You can enter it anytime you can use AT command sets. Don't for get to press RETURN after you enter it.
bchurch@oucsace.cs.OHIOU.EDU (Bob Church) (06/28/90)
In article <XX000000a8@deety.UUCP>, rat@deety.UUCP (David Douthitt) writes: > > If that doesn't help, perhaps I should write a driver for the SSC which > supports interrupts and get my characters from that. Anyone know how to > write PCPI drivers? I thought not. :-( > > -- Oh, I was going to post a copy of the one that I wrote/use but I guess it's just a figment of my imagination. ******************************************************************** * * * bob church bchurch@oucsace.cs.ohiou.edu * * * * If economics isn't an "exact" science why do computers crash * * so much more often than the stock market? * * bc * ********************************************************************
crew@pro-harvest.cts.com (Chris Wicklein) (06/29/90)
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? ARPA: crash!pro-harvest!crew@nosc.mil INET: crew@pro-harvest.cts.com BITNET: crew%pro-harvest.cts.com UUCP: crash!pro-harvest!crew "This message is strictly fact or my opinion."
cyliao@eng.umd.edu (Chun-Yao Liao) (07/02/90)
In article <PNAKADA.90Jun22182513@pnakada.oracle.com> pnakada@oracle.com (Paul Nakada) writes: >I think the problem is that the display is disabling interrupts during >the scroll, which can cause loss of characters via the serial port. >It's not so much the speed of the CPU or the card, but more of the >interrupt handling. This is all conjecture, but it is my impression >that a 4 mhz Apple ][ should have no problem keeping up with 2400 cps. > Just curious about the difference between Apple II and //c... My //c had no problem to catch up with 2400 cps at 1 MHz, and when I pumped up my //c to 8 MHz, it even keep up with HST dual 9600 baud without TSR and DSR connected. ( and my //c is actually communicating at 19200 baud with the modem!) To the guy who posted the original article, did you set your ZipChip to catch the slot where the 80 column card is located? -- cyliao@wam.umd.edu o NeXT : I put main frame power on two chips. @epsl.umd.edu o people: We put main flame power on two guys. @bagend.eng.umd.edu o :::::::::::::::::::::::::::::::::::::::::::: xxxxx@xxxxx.xxx.xxx (reserved) o RC + Apple // + Classic Music + NeXT = cyliao
rat@madnix.UUCP (David Douthitt) (07/03/90)
> To the guy who posted the original > article, did you set your ZipChip to catch the slot where the > 80 column card is located? Sigh. I thought I'd made myself clear. I'm running my Apple II+ with PCPI CP/M. Ascii Express can keep up with 2400 baud just fine (as an example). However, QTerm, running under ZCPR 3.0 (CP/M 2.2 enhancement) CANNOT. Someone said they had a driver which let them keep up ... I'll see how that turns out. As for my Zip Chip, right now, my system boots off the Sider into a DOS partition and I don't have any alternate settings. The lousy stinkin' "setup" (HAR!) is actually a BASIC program that BRUNs some binary file. All of the Zip Chip utilities (the really GOOD ones) use the 128K apple 80-cols. So the Zip uses factory defaults every time. To sum it up - ProDOS keeps up at 2400, CP/M does not, the rest doesn't matter. ][]david -- ! InterNet: deety!rat@spool.cs.wisc.edu ! David Douthitt ! UUCP: ...uwvax!astroatc!nicmad!madnix!deety!rat ! Madison, Wisconsin ! {decvax!att}! ! === Apple II Forever === ! Home of Mad Apple Forth and the Tiger Toolbox ! The Stainless Steel Rat
ung@felix.UUCP (Bill Ung) (07/04/90)
In article <9228.apple.net.info-apple@pro-harvest> crew@pro-harvest.cts.com (Chris Wicklein) writes: >In-Reply-To: message from GRAY@ADMIN.HumberC.ON.CA For once and for all, THE APPLE II CAN DO 2400 BAUD ... EASILY!!! I have an Apple //e, whether it's enhanced, or unenhanced, running at 1MHz, or 8Mhz, is in 80 columns or 40 columns, IT WORKS. If it doesn't work for you, there is something WRONG with your setup. Go read the manual and stop cluttering the net. BTW: if it works on a //e at 1 MHz, it should also work on a II+ or even a vintage II without any problems. Now for the nice guy part: Turn the interrupts on, on the Super Serial card in your Apple //. That should solve all your problems. I had the problem once but reading the manual and a little trial and error solved my problems in less than half an hour. Bill Ung ung@felix.UUCP
GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) (07/07/90)
Chris Wicklein <crew@PRO-HARVEST.CTS.COM> 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. <o_o> Kelly Gray (GRAY@ADMIN.HUMBERC.ON.CA)
ericm@sage.cc.purdue.edu (Eric Mulholland) (07/07/90)
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
shawn@marilyn.UUCP (Shawn P. Stanley) (07/11/90)
In article <9228.apple.net.info-apple@pro-harvest> crew@pro-harvest.cts.com (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? Without using interrupts or polling, the 80-column display/scrolling firmware is too slow, and during the time characters are being displayed, other characters coming in can be lost. The Apple IIgs has support for interrupt-driven serial I/O, and without modifying how the display routines work, can keep up nicely. This is also true of an Apple II using, say, a Super Serial Card with interrupt support in both the hardware and the software. Polling can be accomplished by writing display routines that check for the presence of incoming characters when performing such time-intensive tasks as scrolling the 80-column screen, possibly after moving each line of text. That's only 24 checks per scroll at the most, and that won't slow down scrolling noticeably. -- Shawn P. Stanley shawn@marilyn.marilyn.mn.org bungia!marilyn!shawn {rosevax,crash}!orbit!marilyn!shawn