[Coco] MPI
Gene Heskett
gene.heskett at verizon.net
Wed Jul 11 11:31:40 EDT 2007
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.
More information about the Coco
mailing list