[Coco] Webpage Update - Hires Mouse

Arthur Flexser flexser at fiu.edu
Thu Oct 29 00:27:38 EDT 2015


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

On Wed, Oct 28, 2015 at 12:31 PM, Bill Pierce via Coco <coco at maltedmedia.com
> wrote:

> David, I stated in my post, the "newres" could be an alternate sub-module
> just as the serial mouse sub-module, but I was looking at the
> "joydrv_joy.asm" code (normal Tandy mouse) last night, and I think there's
> a possibility that the new hires code could be added as an option just as
> "normal" and "hires interface" are, and be software selectable (just as
> those are).
>
> The driver does "normal" setup for the joyport (activating PIAs), then
> splits one of two ways... normal or hires. This is determined by the
> resolution flag in the mouse packet; 0=lores 1=hires. We would add another
> flag for 2=newres (or whatever). So this code would have to be
> added/altered in a couple of other modules as well (?? VTIO, CoWin,
> CoGrf,??) to add the new flag value to the existing. The more I look at the
> existing code, the easier it looks.
> I'm not quite sure from looking at Nick's code if the joyport setup
> portion is "normal" or has anything special being done. I need to look
> closer at this part of the code and compare it to what NOS9 is doing there
> which is slightly different due to NOS9's interrupt (multitasking)
> handling. I think once it splits off to the actual X/Y reading, it can be
> left pretty much as is with the exception of converting it to position
> independant code (not a problem).
> In the end, the X/Y coordinates will be the same as the hi-res interface
> as NOS9 ALWAYS expects a 640x192 read, converting it later for lower res
> (40x24, 80x24, 320x192, etc). Normal mouse reads are multiplied to make it
> 640(x10) and 192(x3) during the read state, so the existing code for "mouse
> VS window and pixel" operations would remain the same as the expected
> values would be the same.
>
> I really don't think it would take much added code to make it work. The
> BIG question would be if the new size of "joydrv_joy.asm" would break any
> "boundries" in the os9boot. I'm not sure, but I don't think it would.
> Someone with a little more intimate knowledge of all the system modules
> would know where any changes would need to be made in other modules.
>
> As an afterthought, Multi-Vue (actually Control) would need to have the
> option for the newres added to the settings. I haven't looked at that code,
> so I'm not sure if it could be added or not. It would just be a 3rd option
> to set either "hires", "lores", or "newres". The drivers handle the rest
> (above). All the code for MV's "menu areas" and "scroll bars" is handled by
> the NOS9 drivers, not by MV. So again, all would remain the same.
> Any program that expects the hires interface, should work with the newres
> as long as it doesn't actually "set" the mouse res. If so, then it would
> most likely be a one-byte patch to change (without sources). If sources for
> the software are available (MV is in the repo), then adding the extra
> choice should be trivial. I know in "Ultimuse3", I could add this choice in
> just a few lines of code and one more menu choice.
>
>
>
>
>
>
> 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: David Ladd <davidwladd at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Wed, Oct 28, 2015 11:25 am
> Subject: Re: [Coco] Webpage Update - Hires Mouse
>
>
> On Tuesday, October 27, 2015, Bill Pierce via Coco
> <coco at maltedmedia.com>
> wrote:
>
> > What would be nice is to incorporate this into
> the NitrOS9 joystick/mouse
> > routines.
> > We already have sub-modules for the
> Tandy original, serial mouse (2
> > versions), so to add a sub-module for the new
> hi-res should be simple.
> > Model it after the Tandy original and add the new
> loops. Since the Tandy
> > supports the hi-res interface, that code could be
> removed and there would
> > be plenty of room for the additional code.
> >
> >
> >
> Good
> idea adding this code to the NitrOS-9 project if author allows it :)
>
> Well I
> probably wouldn't delete the old Hi-Res code cause of those who are
> purists and
> want to still be able to use their original hardware.
>
> I would probably build in
> a extra build option that would build both
> versions, but that's my 2
> cents.
>
>
>
>
> --
> Sent from Gmail Mobile on iOS.
>
> --
> 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
>


More information about the Coco mailing list