[Coco] MPI

[Gene Heskett]

On Wednesday 11 July 2007, Robert Gault wrote:
>Gene Heskett wrote:
>> On Tuesday 10 July 2007, Robert Gault wrote:
>>>Chester A Patterson wrote:
>>>>Hi. Through the years I've read that in the MultiPac Interface, in order
>>>>to work better with OS9, needed to have all four of the pin X jumpered
>>>>for some reason. I never did it. Silly me. What pin/signal was it and
>>>>what was the reason? Thanks. /Chester
>>>
>>>I believe that problem has been bypassed by the new clock modules. There
>>>was a discussion of this in Rainbow and it was found that the Coco GIME
>>>can store interrupts which can be "released" by toggling the GIME IRQ
>>> lines.
>>
>> That, unforch, is a separate, unrelated fix.  Both are valid fixes for IRQ
>> related problems, but this I think is more related to the BLOB, boot list
>> order bug.  Before that was found, I used to keep 4 different init modules
>> around, using the one that would boot, now we don't have to.
>
>That's not how I read it as it starts by saying it replaces the M.
>Goodman hardware MPI modification for lost CART interrupts and "This
>article describes a software technique that also eliminates the
>lost-interrupt problem and doesn't require any hardware modifications."
>
>Here is the reference so you can read it again and decide.
>"Coco3 GIME CART IRQs Explained" by Bruce Isted, The Rainbow, Aug. 1990,
>p20.

I just re-read it.  And FWIW, any clock module I touched after that did 
incorporate Bruce's ideas, (thanks Bruce) and like Eddie Kuhn, I think I 
visited them all at one time or another, particularly as our version of the 
y2k problem was approaching, but I also put other features into the level 2 
clocks before that, such as the alarm clock function that went missing in the 
L1/L2 transition.

But let me repeat, the IRQ (other than from the floppy controller because that 
is where the switch is defaulted to if you want DECB when you powerup) never 
gets out of the MPI because its blocked by the slot switching logic as 
shipped by the shack and without this mod.  If there isn't an IRQ pending at 
the GIME's input, no amount of toggling the GIME's enable is going to 
magically generate an interrupt that doesn't exist because it never got out 
of the MPI.

When the driver, such as the sacia or aciapak, registers its IRQ service 
routine with the os as part of its init routine, it sets the priority that 
this IRQ needs to be serviced as.  Sacia/Dacia and aciapak both set this byte 
such that the msb is set, and the IRQ service routine goes through this list 
in an msb to lsb order, calling each of the drivers service routines, and 
they in turn setup the slot switching at $FF7F and read the status byte of 
that slots IRQ register.  If that slot initiated the IRQ, the drivers IRQ 
service routine than proceeds to service the reason for the IRQ.  If it 
didn't, then it returns to the scanning, sets $FF7F to point at the next 
slot, and jumps to that drivers IRQ service routine, which repeats the status 
register read of the cart in that slot, repeat till either the IRQ is 
cleared, or there are no more slots to check.  Since there are more positions 
in the priority table (8 bits) than there are slots(4) I have no idea what 
the system would do if it reached the end of the priority table without 
finding the source of the IRQ, but I assume (I don't have that code in front 
of me now) that it would re-iterate over the table and find and service the 
reason there is still an IRQ asserted.  That would occur silently by the 
response when the IRQ's were re-enabled and there was still one pending. 

IRQ response times for the highest priority bit can be as low as 12 
microseconds, with a very very occasional 150 microseconds maximum if the 
system was busy doing something else.  This of course is with the no-halt 
controller.  Without a no-halt, serial com protocols spend a lot of time 
doing error corrections because of the data over-runs the halting controller 
causes.  With a halting controller, one should always download to a ramdisk 
where the write doesn't cause a halt, then save it to the medias surface 
after the download is completed.

Yes, I have toured the clock module code, all of them, extensively.  And even 
though its much more correct now (if you are using one of my newest clocks 
from rtsi) than in 1986, the MPI mod is still a defacto requirement if you 
want to use hardware serial comm stuff in the mpi.

You can test the alarm functions directly from multiview if you have my 
patched gclock installed, which gives you the facility's to set and clear an 
alarm function & ISTR even have it do something usefull in the manner of a 
cron utility.  Unforch, a lot of that seems to be missing from the nitros9 
distributions.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Money is its own reward.