Re: user-written interrupt handlers

[Juergen Lock <nox@jelal.north.de>]

finally got around answering this one, sorry... :)

itschere@TechFak.Uni-Bielefeld.DE writes:
> Juergen Lock writes:
> 
> > > It's too bad there weren't a couple more DMA channels in the regular ST;
> > > like one for the 68901 USART. Running that chip in sync mode would let you
> > > do some really mean high-speed internetworking...
> >
> > btw anyone using the TT's SCC DMA yet? its too bad mega STe don't have it :)
> > (and have all this SCC problems too.)
> 
>  Regarding that it has a 3 byte fifo one should think it would be worth a
> closer look at, so to say: Well I've missed one interrupt... hmmm... never
> mind, next time, I'll fetch two chars.

 sure 3 bytes are better than one (btw all drivers except ataris(?) more
or less support that), and there also is a pin-compatible chip that
buffers 8 bytes...  (compare PC solution: they replace the 8xxx chip
with a 16550AFN, buffers 16 bytes.)

>  You could start calculating a
> probability for missing three interrupts after another...

 just stay at level >= 5 three times as long as before :)  or 1.5 times
if running the port @ 38400 (compared to 19200 on modem1) or the same
time @ 57600...
> 
>  But then: What's about the MSTE problems with it? Have heard about them,
> but nothing concrete.

 ok... two kinds of problems: 1. SCC IO (interrupts, access 0xffff8c8x)
interferes with disk DMA causing flipped bits on the way to disk and/or
SCC (for example receive megabytes of gzip'd news batches without one
protocol error and then unbatching finds corrupted files!  nearly made
me crazy while porting uucp...) and 2. a bugged PAL (UA03, checksum $5613)
that makes the 2nd SCC port (serial2/`appletalk') lose chars no end.

 some people never notice the 1st one, i don't know if there are board
revisions that really don't have it or if it just happens less often
(or maybe the people never run multitasking and rarely have disk and
SCC IO happen at the same time...)  a fix (patched GAL) for the 2nd one
is described in fser096* (should be on a.a); the 1st one, at least the
corrupted disk problems can be reduced from (in my case) `happens every
2nd file' to maybe `once every 1000 files' by replacing the Z85C30 SCC
with a Z85230 (both Zilog here, Am85C230A might also help), described
in fser* too. (the extra clock stuff is not essential, original 8MHz
still works.)

>  And what about the falcon? Have only heard it doesn't
> use a MFP for serial communication. Don't know what it uses.

 SCC.  i don't know if it has the same problems but i remember reading
one horror story about a falcon crashing in the middle of a disk
defragmentation just when the phone rang and the modem sent `RING'...
(i also heared of newer(?) falcons having AMD SCCs, maybe theres a
connection?)

 btw anyone know how to set 38400 bps on falcons modem port?  seems the
clock input is different or something...
> 
>  Looks like there'll never be a kernel with new device drivers, because
> you would have to write three of them for all existing hardware... :-(

 hmm i just looked at the *txt in hsmoda02*...  are these drivers
stable on all different machines?  maybe, and if he adds a few things
we could do something on top of those...  anyone on good terms with
our friend Harun? :)  my last mail got unanswered...  (ok could have
been mail/gateway problems too, given that those PC networks apparently
never bounce back stuff they can't deliver.)

 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA