[Coco] Update: os9gen on 128k coco3, rs323 pack

[Gene Heskett]

On Sunday 15 February 2009, Steven Hirsch wrote:
>On Sun, 15 Feb 2009, Gene Heskett wrote:
>> On Sunday 15 February 2009, Steven Hirsch wrote:
>>> On Sun, 15 Feb 2009, Michael Furman wrote:
>>>> I tried using the rs232 pak ROM and it seems to hang occasionally.
>>>
>>> There's an obscure problem with interrupt handling that might be behind
>>> the hangs.  I have no personal experience with it, but it's written up in
>>> "Tandy's Little Wonder" (Farna Systems?).  IIRC, interrupts are not
>>> properly shared between the cartridge slot and the GIME with the end
>>> result being that SIO interrupts can be lost.  Again, just speculation
>>> that this is the issue!
>>
>> There is about a 100/1 chance that is correct.  The fix is to remove three
>> of the 4 pullup r's tied to each card socket pin 8, and then jumper all
>> sockets pin 8's together.  This allows the IRQ to get through to the coco
>> and be serviced regardless of where the slot switch is, or what slot was
>> last selected by the software.
>
>Gene,
>
>I don't think he's using an MPI.  The problem I'm referring to is internal
>to the computer and has to do with how the cart interrupt is routed to the
>CPU.

That part isn't something I've checked as I've had an mpi since forever.  With 
my fix the mpi's internal slot selection can be set to any slot, and 
something like the incoming character buffer is full, which becomes the /IRQ, 
does get through to the cpu regardless of the present state of the slot 
selector, which responds by invoking an IRQ scan to find the source and then 
service it.  Each registered IRQ routine also sets the slot the device is in, 
and the slot selector is then switched to each of the possible sources it 
knows about before reading the chip register to see if this chip is the 
source of the /IRQ.  If it is as indicated by the flag, then that drivers IRQ 
routine is invoked to service the chips request.

This generally, for the rs232 pack, takes about 15 microseconds unless the 
system is reading or writing to non-volatile storage.  If it occurs during 
that operation, the response time stretches out to about 150 microseconds 
because the disk has priority.  But at 9600 baud, I haven't ever lost a 
character because of that.  Those timings were obtained using a disto no-halt 
controller and could be much worse without the no-halt.

Besides that, I don't believe /CART is the same as an /IRQ, which is what my 
method fixes.  Somebody correct me on this if I'm wrong, please.

In either event, if the service routine is unknown to the cpu, then I believe 
either a FIRQ or an IRQ will lock the cpu up in the scan cuz it never finds 
the interrupt to exit the scan.  Registering that interrupt service routine 
IS (or should be) part of the individual drivers init routine at boot time.

-- 
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)
You will always find something in the last place you look.