[Coco] OS-9 Level1 Version 02.00.00 FYI

Tue Apr 21 01:16:47 EDT 2020

Yes Virq is 1/60 sec.

However I was referring the system clock. Which I (mistaking thought) was 1/100 of a second.

I checked in Nitros9 and Os9 tech manuals and it states time slice is 1/60th.

I'm not sure why (apart from old age) I have a clear recollection of seeing the original Os9 had a time slice of 1/10 sec and the later Os9 was 1/100th.

Well if 1/60th is the case I have no explanation why tstfs2.asm is not picking up the correct Virq timing in the emulators.

Since last email I wrote a little C app to access the VRN driver and test the Virq rate (like tstfs2) and that works as expected even on the emulator.

So now I'm really stumped.

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of L. Curtis Boyle
Sent: Tuesday, 21 April 2020 12:56 AM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] OS-9 Level1 Version 02.00.00 FYI

The Coco VIRQ is indeed based on 1/60th of a second, not 1/100th

Sent from my iPhone

> On Apr 20, 2020, at 8:40 AM, Walter Zambotti <zambotti at iinet.net.au> wrote:
> 
> 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
>>>> 
>>>> 
>>>> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
> 

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco