[Coco] Webpage Update - Hires Mouse

[David Ladd]

On Wed, Oct 28, 2015 at 11:31 AM, 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).
>

​Bill that is all very good news :D  A new value for the newres would be
great for sure :D  Would be a good idea for all new and future developed
apps for NitrOS-9 :D  Plus a alternate build of the drive as well for those
older apps we don't have source code too so that we could replace the HiRes
with the NewRes code :D​



>
> 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.
>

​That is interesting about the math part.  Overall I did not know that is
how all the resolution stuff worked out there :D​



>
> 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.
>

​As far as MultiView since the source code is there shouldn't be a problem
and as you stated with Ultimuse3 you can add the code in there :D

As always with all new stuff we can also build alternate driver options too
that should work with older software too just in case :D​

As always keep up the good ideas and alternate options for us :D