Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!decwrl!elroy.jpl.nasa.gov!jarthur!spectre.ccsf.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple
Subject: Re: MNP level 5 (really: handling 9600 baud at 1 Mhz)
Message-ID: <1990Mar1.103507.13022@spectre.ccsf.caltech.edu>
Date: 1 Mar 90 10:35:07 GMT
References: <9002281406.AA15912@masig2.ocean.fsu.edu> <2671@uwm.edu>
Sender: news@spectre.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 30

jeffd@csd4.csd.uwm.edu (Jeffrey Alan Ding) writes:

>  At 9600 baud, the computer chokes.  I send
>it an AT command and I don't even get the OK signal back.  I tried
>several term programs including Kermit, Talk is Cheap, Zlink, and Mousetalk.
>Talk is Cheap was the fastest in scrolling.  No program worked at 9600 baud.

>My computer is only running at 1 MHz.

So was my ][+ when it ran 9600 for months without missing a character.

I wrote my own term program and interrupt routines, but any good terminal
program should handle 9600. Kermit on my ][+ runs at 19200 without losing
characters either.

Chances are it is the interrupt overhead of the //c firmware and ProDOS.
ProDOS has horrendous interrupt overhead (worst case 400 microseconds)
because it has to save all the memory state softswitches and provide
a 'standard memory state' to the interrupt handler. (My term program ran
under DOS and in much less than 48K so I just hooked directly into the
interrupt vector. Total interrupt processing time was about 100 microseconds
or 10% of the CPU at full speed 9600 baud reception. Worked like a charm.)

Still, you should be able to handle 9600 baud because even at full rate
reception over half of the //c's CPU time is left over -unless- your
term program sucks and it's interrupt handler takes forever, which I
really doubt. It's probably the //c's firmware.

Todd Whitesel
toddpw @ tybalt.caltech.edu