[Coco] Webpage Update - Hires Mouse

Thu Oct 29 07:57:20 EDT 2015

Nick & Art, yeah, I understand that the interrupts will need to go off. That's not a problem.
People have the wrong idea about OS9's interrupt rules. The idea is for user software not to mess with "system" interrupts. The mouse routine IS a system interrupt. The current mouse routine wouldn't work if it was interrupted in the midst of a read and the same could be said for serial transfers, disk reads, etc. When you write a driver such as the mouse driver, it get's it's own slice of the pie. Another thing that helps determine how fast it can cycle to the next read in OS9 is the number of processes running that have high priority functions going at the same time. Since I doubt anyone in the Coco community is using OS9 for an office network with 10 users on one server, I think we'll be OK.
Now with that said, I don't know how many reads can be done before it has to give up and allow something else to have it's slice. I would think this routine is fast enough to get an accurate reading before things need attention or it wouldn't be useful in ANY loop under ANY OS...
All we can do is try.

My biggest concern is not if the routine will work in OS9, but is in the initialization portion of the loop. The current OS9 routine sets up the DAC and inits everything right before it splits off to either the "normal" read, or the "high res" read. I need to know if this routine is sufficiant for what's needed for the "newres" routine or if it will need to be changed. If it needs to be changed, then a new, separate driver will probably be needed which ONLY uses the new routine or maybe adapts the old one's to it's loop (??). This could work but it inhibits the user to only programs written for that routine (unless we adapt the old) or rather the "normal" mouse as any software accessing the mouse in OS9 should expect a proper resolution result for the resolution they are using as OS9 auto scales the results for each running window to the current resolution of that window on request of the mouse packet (this is done "outside" the read loop). When you turn the mouse on in OS9, it is always running in the background and the packet is always being updated. When you request a packet, you get the last current read.
The mouse packet contains all info for the mouse... current X/Y, current state of BOTH buttons, how long the buttons have been down, the X/Y from when the buttons went down, etc. It's not like RSDOS where all you get is X/Y and button up or down and you have to do all the extras yourself... it's already done, all you have to do is ask for it. The timeouts and delays are all software selectable. If I'm not mistaken and I'm reading the sources right, you can have the mouse reading the Tandy hires interface on the left port in one window, and the normal mouse reading the right port in another.

As for the interrupts, I don't think the current serial mouse driver would work if that was a problem as I imagine that's a pretty tight loop keeping the mouse updated from an RS-232 pak. We're talking about the old IBM style serial mouse, and yes, it works and works well. Gene uses one of these. I think the same would go for the Tandy HiRes interface, that would have to be a tight loop as well to read the mouse and do the comparisons between the mouse port and cassette port.

Again... all we can do is try :-)

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Nick Marentes <nickma at optusnet.com.au>
To: CoCoList <coco at maltedmedia.com>
Sent: Thu, Oct 29, 2015 4:14 am
Subject: Re: [Coco] Webpage Update - Hires Mouse

The new mouse driver is certainly cycle-sensitive as Art stated.

It samples the
area between two DAC positions. The change from one DAC 
position to the next
happens very fast but we manage to obtain 5 samples 
during that transition
period and another 5 in the opposite. The minimum 
timing we obtain with a stock
6809 is 4 cycles from the moment we set 
the second DAC point. Oversampling is
timed to the clock cycle and the 
routine needs full access during that time to
get the most accurate 
reads possible.

So, interrupts do need to be turned off.
It may work under Nitros9 
without but you may get "mouse jiggle" due to the
interrupts. That's 
what interrupts do, they interrupt the current flow of
processing.

So turn off interrupt first and you should be fine.

Oh, and the
current code is designed for 6809 timings. Putting a 6309 
into the 6309 timings
mode may add post processing errors unless the 
sample weights are
re-adjusted.

The code presented is also not relocatable so it would need to be

modified to suit Nitros9's requirements. This is not impossible, it's 
just
that RS-DOS apps have fixed loading points normally.

So, it's quite possible
but as Art said, it will need a bit more work to 
make it Nitros-9
friendly.

Note also, that this routine, with all the post processing happening,
is 
faster than the hardware hires mouse driver method. It too ideally wants

the IRQ's off to obtains the most accurate results to avoid "mouse
jitter".

Nick

On 29/10/2015 2:27 PM, Arthur Flexser wrote:
> Bill, I think you
might be underestimating the difficulty of adapting the
> new joystick routine
to NOS9.  As I see it, the problem is not so much
> getting it to run under
NOS9, which you seem to be focusing on.  The
> problem is doing so without
affecting the accuracy of the joystick
> reading.  After reading Nick's
description at
>
http://www.members.optusnet.com.au/nickma/ProjectArchive/hires.html
> I have the
impression that the coding is quite cycle-sensitive.  As I
> understand it, you
need to get a reading exactly 4 cycles after you set a
> new DAC voltage value.
To accomplish this, at the least, you'd need to
> disable interrupt servicing
during joystick reading, which I hope doesn't
> mess up too much stuff going on
in other processes, particularly with
> respect to communications.  (Note the
ORCC #$50 as the first instruction of
> the source Nick has posted.)  Also,
rewriting the code to make it
> position-independent may play havoc with
critical cycle counts.
>
> I'm certainly no authority on NOS9, but it strikes me
that there may be
> significant problems involved that you haven't
considered.
>
> Art

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