[Coco] OS-9 Level1 Version 02.00.00 FYI

Walter Zambotti zambotti at iinet.net.au
Mon Apr 20 10:40:12 EDT 2020


Ok guys.

I'm looking at the (o)VCC source I see how the GIME chip flags a an
interrupt in the GimeAssertVertInterupt() function.

    if (((GimeRegisters[0x92] & 8)!=0) & (EnhancedIRQFlag==1))
    {
        write(0, "I", 1);
        CPUAssertInterupt(IRQ,0); //IRQ moon patrol demo using this
        LastIrq=LastIrq | 8;
    }

This code tells me if GIME reg FF92 Bit 3 (VBORD) is enabled the CPU
asserted with an IRQ and the IRQ type saved in LastIrq is 8 or VBORD. 
So the next read from FF92 will detect a Virq.

I placed a write in the code and when I ran OVCC it output 60 'I's per
second.  So that seems good!

However when I ran tstfs2 that tests the Virq interrupts it is not
detecting all the virqs. Even though I can see they are been generated.

Looking at the source for tstfs2 i see it creates an F$IRQ & F$VIRQ for
a FAKE Virq device.

Virq is used for polling devices without real interrupts and according
to the NitrOS-9 manual the polling interval is set to the system clock.

But that makes no sense because the interval for the system clock is
meant to be 1/100 of a second and there is no relationship between 1/100
& 1/60 and so you can't use a 1/100 sec timer to simulate a 1/60 sec
interrupt.

So the next step is to determine what is used as the system clock in
Nitros-9

I'm starting to suspect the system clock interval is 1/60 and it uses
the Virq interrupt for this purpose and the author of VRN knew this and
was able to rely on using the F$Virq system call with a FAKE Virq device
for this purpose.

After all why define a fake Virq device when a real one exists? Because
the system clock is already using it so VRN is forced to ride on the
system clock's back and because only one read of the Virq interrupt flag
can be done. Everytime FF92 is read the value of the VBORD interrupt is
read but it is also cleared.  So only one routine can take ownership of
this register.

However none of this explains why tstfs2 isn't receiving all the Virq
interrupts which appear to be generated!

Walter


On 2020-04-20 17:43, Walter Zambotti wrote:
> My testing of ovcc shows that at stock 1.79mhz speed 300 Virqs which
> should does take 5 secs on a real CoCo III takes 43 seconds on OVCC.
> Worse as I change the mhz qreuency on OVCC the Virq rate changes.
>
> It should never change regardless of frequency.
>
> I'm looking through the code now to try and see how it works
>
> Walter
>
> On 2020-04-19 12:30, Walter Zambotti wrote:
>> Dave
>>
>> I too suspect the video system is being used for generating keyboard
>> interrupts in OS9 and I suspect the maximum number of interrupts per
>> seconds than becomes the Virq rate.
>>
>> Doing some testing with trapping Virqs I can trap a maximum of 60 per
>> second.  One side effect I have noticed is that when trapping Virqs at
>> the rate of 60/sec (the max) no other keyboard signal is delivered to my
>> application.  It is as if OS9 cannot queue more than one signal in that
>> time period to the same task.
>>
>> If I limit trapping the Virqs to 30/sec than I begin to receive keyboard
>> interrupts (ESC and shift-ESC) as well.
>>
>> Walter
>>
>> On 2020-04-17 23:41, Bill Pierce via Coco wrote:
>>> Dave, it seems it's something involving what OS9 L1 does immediately after a key is pressed. Programs seem to run fine up to a key press. L1 v2.0 must do something different right after the key press as opposed to L2. This difference is triggering VCC to freeze. I assume some reg is being reset and VCC is not responding properly. The object would be to trace down what happens after a keypress, step by step, in both L1 & L2. This should tell us what L1 is stomping in VCC and then we could fix VCC.
>>>
>>>
>>> -----Original Message-----
>>> From: Dave Philipsen <dave at davebiz.com>
>>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>>> Sent: Fri, Apr 17, 2020 11:10 am
>>> Subject: Re: [Coco] OS-9 Level1 Version 02.00.00 FYI
>>>
>>> Actually keyboard interrupts are not used in OS9. The keyboard is scanned at a regular interval determined by the interrupt routine but it’s actually the video system which is generating the interrupts which OS9 also uses for multitasking.
>>>
>>> Dave
>>>
>>>
>>>



More information about the Coco mailing list