ZXpand / Atari ST mouse driver
ZXpand / Atari ST mouse driver
I've managed to put together a fairly simple driver for the Atari ST mouse. With a simple little tweak it can be adapted to use an Amiga mouse too. The mouse coordinates are maintained on the ZXpand MCU, and polled by the zeddy. It seems to work quite well except there are a couple of issues.
1. There is no room for the driver in the standard ZXpand micro-controller.
2. I didn't wire the second joystick button/right mouse button to the DB9 on the AY board.
Issue 1 can be overcome very simply in the short term for those desperate to get this functionality. I can supply a more powerful PIC chip which is a drop-in replacement. Simples. In the longer term I have a plan to re-write the boot-loader in assembler. At the moment it occupies 4K which, at the time of the start of the project, didn't seem too bad. But now that I need an extra 300 odd bytes... Well it't the age-old problem all over, isn't it
Issue 2 is a little trickier - there are no other options apart from soldering a wire & pull-up resistor. There are 2 free pins on the PIC which could be used. They are actually the serial connections but there's no serial support in the firmware so that doesn't matter.
I'm also wondering whether it would be better to maintain and report a delta movement instead of or as well as the absolute position.
All comments welcomed!
Charlie
1. There is no room for the driver in the standard ZXpand micro-controller.
2. I didn't wire the second joystick button/right mouse button to the DB9 on the AY board.
Issue 1 can be overcome very simply in the short term for those desperate to get this functionality. I can supply a more powerful PIC chip which is a drop-in replacement. Simples. In the longer term I have a plan to re-write the boot-loader in assembler. At the moment it occupies 4K which, at the time of the start of the project, didn't seem too bad. But now that I need an extra 300 odd bytes... Well it't the age-old problem all over, isn't it
Issue 2 is a little trickier - there are no other options apart from soldering a wire & pull-up resistor. There are 2 free pins on the PIC which could be used. They are actually the serial connections but there's no serial support in the firmware so that doesn't matter.
I'm also wondering whether it would be better to maintain and report a delta movement instead of or as well as the absolute position.
All comments welcomed!
Charlie
Last edited by sirmorris on Mon Feb 27, 2012 9:53 pm, edited 2 times in total.
Re: ZXpand / Atari ST mouse driver
Congratulations. As I also have an Atari ST mouse it would be great if you could bring me a big pic with the mouse driver to our meeting. Oops, there is a serial port in your pic? Then maybe a serial mouse would be better?
Just kidding. Wiring the second button should be no problem. Absolute positions are ok for me. What would be the advantage of delta positions?
Just kidding. Wiring the second button should be no problem. Absolute positions are ok for me. What would be the advantage of delta positions?
In theory, there is no difference between theory and practice. But, in practice, there is.
Re: ZXpand / Atari ST mouse driver
Delta positioning is better for some games - on the PC at least
Re: ZXpand / Atari ST mouse driver
Excellent stuff as always Charlie, if there's room in the new PIC and it's easy enough to code you might as well code in absolute and delta and then have a way in the software of the program choosing which it reads.
Andy
Andy
what's that Smell.... smells like fresh flux and solder fumes...
Re: ZXpand / Atari ST mouse driver
Matthias agreed to have a go at the HRG mouse mode with onClick event
On our meeting. Will be a very interesting meeting. It's another three weeks and three days until then.
On our meeting. Will be a very interesting meeting. It's another three weeks and three days until then.
In theory, there is no difference between theory and practice. But, in practice, there is.
Re: ZXpand / Atari ST mouse driver
Delta measurement was trivial, so I added it to the report sent to the zeddy, it's a couple of extra INs but it shouldn't hurt.
Next up is using fixed point maths for the position; 8:8 should do it. That would make the whole thing very flexible. It would limit the max xpos to 255 but seeing as that's the maximum resolution anyway...
Next up is using fixed point maths for the position; 8:8 should do it. That would make the whole thing very flexible. It would limit the max xpos to 255 but seeing as that's the maximum resolution anyway...
Re: ZXpand / Atari ST mouse driver
There are rumours that given "natural" limitations won't last very long. Maybe there is a overscan ZX81 running at 28Mhz on our meeting? Having 512x384 resolution? Or 1024x768?`Do you think anything of this may be impossible?sirmorris wrote:It would limit the max xpos to 255 but seeing as that's the maximum resolution anyway...
I think nothing is impossible on a ZX81. But in that case we could use the delta with max delta being 255, right?
In theory, there is no difference between theory and practice. But, in practice, there is.
Re: ZXpand / Atari ST mouse driver
OK, internally it will use 16:8 fixed point. I'll expose the coordinates as words and allow setting of the maximum x,y
Re: ZXpand / Atari ST mouse driver
That is potentially quite interesting, as I have an Atari ST mouse (and an ST for that matter).
Re: ZXpand / Atari ST mouse driver
This feature has proved most tricky!
I won't bore you with details but essentially the interrupt-based processing of the mouse signals was interfering with the client software's ability to read the position data. This led to corrupt packets which in turn led to glitches. I've solved the issue by adding a serial number to the start and end of the mouse data packet so I can tell if it's likely to be corrupt. It's now working well.
I'll try to put a video up later.
In the mean time - Angus:- do you want to give it a go??
C
I won't bore you with details but essentially the interrupt-based processing of the mouse signals was interfering with the client software's ability to read the position data. This led to corrupt packets which in turn led to glitches. I've solved the issue by adding a serial number to the start and end of the mouse data packet so I can tell if it's likely to be corrupt. It's now working well.
I'll try to put a video up later.
In the mean time - Angus:- do you want to give it a go??
C