Re: IRQ problems with SSC (???)

[dempson@actrix.gen.nz (David Empson)]

In article <1994May6.040151.19543@serval.net.wsu.edu>,
Michael Kelsey - EECS (Cpts499) <mkelsey@rayshade.eecs.wsu.edu> wrote:
> 
> 	Not too long ago I finally got a ThunderClock for my Apple II, but
> for the life of me, I couldn't get a smooth transfer between my Apple II
> and my PC's COMx port!  I found this *very* frustrating since I couldn't
> discern the problem.  Finally, I removed the ThunderClock from slot 5 and
> discovered that all of my communications problems disappeared!  Amazing but
> true.  I then scanned in my //e Technical Reference and found out that slot 7
> has a higher IRQ priority than slot 6...and so forth.

In theory, yes.  In practise, it makes no difference unless you have
cards in all the intervening slots, and the interrupting cards
actually obey the IRQ priority chain (which is pretty pointless anyway).

ProDOS can cope with up to four interrupt sources, provided you have
interrupt handlers installed for each one.  Whether it can keep up
with them is a different matter.

> So, I migrated my SSC (initially in slot 1 - for printer reasons) to
> slot 2 and placed the Thunder-clock to slot 1.  When I tried out my
> theory, all communications problems ended.    

This is very strange.  The Thunderclock should not be causing
interrupts, unless you've enabled one of the periodic interrupts on the
card.  This is very unlikely.  In fact, if you didn't have an
interrupt handler installed, and any other device was causing
interrupts, the computer would hang, or ProDOS would give you an
unclaimed interrupt fatal error.

I'm not particularly familiar with the Thunderclock, but I thought it
was normally polled by the computer - I'm not aware of it using DMA or
interrupts.  The ProDOS clock driver is invoked on any ProDOS call,
and it calls the ThunderClock to copy the time into the input buffer
at $0200.  ProDOS then interprets the data in the buffer and updates
its date/time variables in the global page.

It is possible that this is taking some time, and interrupts may be
disabled.  This would cause you to lose characters on the SSC.  It
doesn't explain why the behaviour changes when you move the
Thunderclock to a different slot.

> 	Does anyone know if this is due to ProDOS getting called by the inter-
> rupt and denying the terminal program its service to the SSC? 

Keep in mind that the Apple II only has one IRQ input, and can only
process one interrupt source at a time - no nesting of interrupt
levels like on the PC.  Software often disables interrupts for varying
amounts of time.  One prime example is disk I/O to floppy disks -
interrupts are locked out for the whole time the drive is enabled.

Another example is the 80-column firmware on the original IIe.  It
locks out interrupts most of the time while the screen is scrolling.

As a matter of interest, do you have an enhanced IIe or an original
one?  The enhanced IIe's interrupt handler is rather a lot slower than
the original one (it saves the state of the machine and switches it
into a standard configuration before passing control to ProDOS, which
then passes control to the communications program's interrupt handler).

> And just recently, I snagged a Digital Research Z-80 CP/M interface
> card (which I believe goes in slot 4 - so much for the mouse) and it
> caused the same type of problem that I experienced earlier.

You can put the mouse in any slot - it doesn't have to be in slot 4.
Any software that requires the mouse to be in a particular slot is
badly written.  Most should be configurable, or should auto-detect it.

Speaking of which, the mouse is a major source of interrupts (if it is
enabled and set to an interrupting mode).

> Sure enough, after removing it from slot 4 (and leaving it out) my
> SSC conflicts stopped and the data transfered at 19200 baud
> flawlessly.  So, does the Z-80 have this same type of interrupt?

The Z-80 card shouldn't be doing anything at all unless you boot from
a CP/M disk.  It _might_ be stealing cycles from the IIe on occasion,
but I would have expected the Z-80 processor to be held reset while
the card isn't in use.  I don't know if Z-80 cards generally use
interrupts.  Most of them use DMA to access Apple II memory and I/O,
and this would slow down the Apple II processor.


Can anyone else explain these problems?
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand