[Coco] Webpage Update - Hires Mouse

Thu Oct 29 12:16:43 EDT 2015

Re: Interrupts.

The solution is probably very simple.
The timing-sensitive portions of the scanning are only a few CPU
cycles long.   Interrupts may simply be masked for those 10 or
whatever cycles and re-enabled at all other times in-between those
points.   That way all interrupts will still be processed, only that
they may be delayed by a few CPU cycles.

As for 6309-Native VS 6809...  The reason the first 'extended scan' is
4 cycles is because that's the fastest the 6809 could manage.   For
compatibility, the code could simply be written to stay 4 cycles
regardless of native 6309 operation or 6809 operation...

Or... Somewhere down the line, a 6309 specific version may be made to
take advantage of it's potential to pull off a 3 cycle scan time,
which would improve the joystick resolution and linearity even
further.   It's just that someone would have to work out the
mathematical values of 3 cycle scans and incorporate them into the
calculation.

On 10/29/15, Bill Pierce via Coco <coco at maltedmedia.com> wrote:
> 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
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>

-- 
John Kowalski / Sock Master
http://users.aei.ca/twilight/sock