Virtual mouse

[earok]

This is a side project for JOTD's CD32Load utility.


What I've got currently working at the moment is, if you have a joystick plugged into the mouse port, you can move the cursor around (tested in emulator, not on real hardware just yet).

This is achieved by simply writing to JOYTEST ($DFF036), which sets the top six bits of both bytes for both JOY0DAT and JOY1DAT. Since the bottom two bits are ignored, it doesn't necessarily interfere with joystick control.

But there are a number of caveats, I figured the requests below were impossible but I thought I should ask:

- You can move the cursor on gamepad two but I haven't worked out a way to set the left/right mouse button states. Is there a way this could be done?
- Since the bottom two bits can't be set, precision is limited (minimum move of four pixels?). Are there alternatives to JOYTEST that could be used?

[ReadOnlyCat]

If I am not mistaken, you are trying to poke the hardware registers live in order to fool the currently running program (OS, or else) that what is connected in the mouse port is really a mouse even though it is actually a digital joystick. Is this correct?

This would be why you are resetting the mouse counters to 0, because joystick data generally causes them to behave completely randomly.

But I still do not understand what you mean by "move the cursor on gamepad two".

Also, setting the left/right mouse button states forcefully implies to set these two lines (6 and 9 respectively) as output and that is definitely not something you want to be doing while a joystick or mouse is plugged in the port.

I am not too sure what you are trying to do but I would think that you would be better off intercepting the data at a higher level.

[earok]

Originally Posted by ReadOnlyCat

If I am not mistaken, you are trying to poke the hardware registers live in order to fool the currently running program (OS, or else) that what is connected in the mouse port is really a mouse even though it is actually a digital joystick. Is this correct?

Correct

Originally Posted by ReadOnlyCat

This would be why you are resetting the mouse counters to 0, because joystick data generally causes them to behave completely randomly.

That's not exactly what I'm doing - rather than resetting them to zero, I'm nudging either the upper byte or lower byte by 4 in either direction, depending on what the current joystick input is. In rough pseudocode, stuff like - "if joystickright then mousecounter + 4"

Originally Posted by ReadOnlyCat

But I still do not understand what you mean by "move the cursor on gamepad two".

Essentially I can use the Port 2 gamepad to move the cursor position (Port 1 direction register). The problem is I can't use the buttons on the port 2 gamepad to simulate the buttons on a port 1 mouse.

Originally Posted by ReadOnlyCat

Also, setting the left/right mouse button states forcefully implies to set these two lines (6 and 9 respectively) as output and that is definitely not something you want to be doing while a joystick or mouse is plugged in the port.

I see.. I'll make sure to avoid doing that then!

Originally Posted by ReadOnlyCat

I am not too sure what you are trying to do but I would think that you would be better off intercepting the data at a higher level.

It's for the CD32Load utility, which basically simulates WHDLoad (except that it has some CD32 specific functions, such as using lowlevel CD reads). I was after a way of fooling the underlying hardware so mouse only games/slaves are playable with a regular joystick, without modification to the games themselves (which I've achieved to some extent, but not perfectly)



If it helps illustrate what I'm up to, here's the main portion of my code so far (I'm extremely new to ASM, so apologies if my coding is terrible!)

JOY0DAT			EQU $DFF00A
JOY1DAT			EQU $DFF00C
JOYTEST			EQU $dff036
MOVEAMOUNT		EQU $4 ;Bottom two bits of each byte aren't recognised by JOYTEST, hence you can't make smaller moves than 4 pixels

vm_testright
	;Get the current mouse data
	move.w		JOY0DAT,D1
	move.w		D1,D2
	lsr		#8,D2

	BTST		#JPB_BTN_RIGHT,D0
	beq		vm_testleft
	add.b		#MOVEAMOUNT,D1

vm_testleft
	BTST		#JPB_BTN_LEFT,D0
	beq		vm_testup
	sub.b		#MOVEAMOUNT,D1
	
vm_testup
	BTST		#JPB_BTN_UP,D0
	beq		vm_testdown
	sub.b		#MOVEAMOUNT,D2

vm_testdown
	BTST		#JPB_BTN_DOWN,D0
	beq		vm_done
	add.b		#MOVEAMOUNT,D2
	
vm_done
	lsl		#8,D2
	move.b		D1,D2
	move.w		D2,JOYTEST

[Toni Wilen]

Originally Posted by ReadOnlyCat

This would be why you are resetting the mouse counters to 0, because joystick data generally causes them to behave completely randomly.

It is not random, it is perfectly logical and also fully emulated in UAE

Originally Posted by ReadOnlyCat

Also, setting the left/right mouse button states forcefully implies to set these two lines (6 and 9 respectively) as output and that is definitely not something you want to be doing while a joystick or mouse is plugged in the port.

No, output mode is correct mode for reading joysticks and mouse buttons. KS does it and it is explained in HRM. It is needed because normal buttons are open (floating) and closed to ground when pressed and without output mode and data=1 (it is sort of chip internal pullup mode), button state gets stuck in pressed state (or gets random) because there is nothing that pulls the signal back to high after button was released.

Not using output mode is the most common reason for 2nd button not working with some pads (those that don't have internal pullup resistor)

I haven't worked out a way to set the left/right mouse button states. Is there a way this could be done?

Setting button pin to output mode should do what you want.

Output mode should always read back same value (if nothing is connected) that was written unless someone else modifies either bit (data or direction)

Are there alternatives to JOYTEST that could be used?

No. Lowest two bits are directly connected to mouse/joystick lines and they are input-only.

[earok]

Thanks for the clarification

What bits do I write to which registers? Bit 10 on the POTGO for rmb and Bit 6 on the CIAADDRA to set to output mode?

[ReadOnlyCat]

Originally Posted by Toni Wilen

It is not random, it is perfectly logical and also fully emulated in UAE

Of course it is not random since the left/right/up/down signals control the quadrature encoded direction signals one to one. I should have said "looks random to the casual eye".

Originally Posted by Toni Wilen

No, output mode is correct mode for reading joysticks and mouse buttons. KS does it and it is explained in HRM. It is needed because normal buttons are open (floating) and closed to ground when pressed and mode and data=1 (it is sort of chip internal pullup mode), button state gets stuck in pressed state (or gets random) because there is nothing that pulls the signal back to high after button was released.

Not using output mode is the most common reason for 2nd button not working with some pads (those that don't have internal pullup resistor)

Oh, I see, thanks for clarifying.

I did indeed notice that the HRM mentioned that setting output mode would trigger pull-up or pull-down depending on the set bit value which is logical but I understood that this meant the joystick was responsible for using +5V to provide pull-up for the input lines when input mode.

I guess this was not how the Atari joystick protocol worked though so they could not expect existing joysticks to do that.
Still, it is weird to call this output mode when the Amiga is the one reading the lines. Naming it "Driven" mode would have been less confusing for my inner kitten.

[ReadOnlyCat]

Originally Posted by earok

Thanks for the clarification

What bits do I write to which registers? Bit 10 on the POTGO for rmb and Bit 6 on the CIAADDRA to set to output mode?

Yes, you should also set pin5 as output in POTGO (bit 9/8) to support the third joystick button.

[earok]

Ok, I'm embarrassed - I think I've worked it out for left mouse button (below) but I can't work it out for right mouse button. This is what I'm trying, please let me know where I've messed up


Init code:
BSET #6, CIAADDRA
BSET #11-8, POTGO

Simulate left mouse down: BCLR #6, CIAAPRA
Simulate left mouse not down: BSET #6, CIAAPRA
Simulate right mouse down: BCLR #10-8, POTGO
Simulate right mouse not down: BSET #10-8, POTGO

[earok]

Originally Posted by ReadOnlyCat

Yes, you should also set pin5 as output in POTGO (bit 9/8) to support the third joystick button.

Heh, do any games support middle mouse button though?

[ReadOnlyCat]

Originally Posted by earok

Heh, do any games support middle mouse button though?

I am sure there a few which do but mine certainly will.

The POTGO bits 11 and 9 must be set to 1 to set pins 9 and 5 (bits 10 and 8) as output.
Cf http://amigadev.elowar.com/read/ADCD.../node018B.html.

So, set bits 11 and 9 to 1, then set 10 and 8 to the value desired for the buttons.

Edit:
Aside from your original BSET 11-8, this seems to be what you are doing though.
Strange.

[earok]

Originally Posted by ReadOnlyCat

I am sure there a few which do but mine certainly will.

The POTGO bits 11 and 9 must be set to 1 to set pins 9 and 5 (bits 10 and 8) as output.
Cf http://amigadev.elowar.com/read/ADCD.../node018B.html.

So, set bits 11 and 9 to 1, then set 10 and 8 to the value desired for the buttons.

That's what I was trying with "BSET #11-8, POTGO". I can't seem to have any luck with it though, it also doesn't seem to stop right mouse button from working normally in Port 1 like I'd expect it to.

[Toni Wilen]

Originally Posted by earok

That's what I was trying with "BSET #11-8, POTGO". I can't seem to have any luck with it though, it also doesn't seem to stop right mouse button from working normally in Port 1 like I'd expect it to.

I hope POTGO is memory address, not a custom register for obvious reasons..

[jotd]

Obvious for Toni

you cannot BSET POTGO since it implies read & write.
Read POTGOR, mask and write to POTGO.

[ReadOnlyCat]

Good catch, could explain it indeed.
My brain automatically assumed that the BSET was a logical simplification and not an actual instruction.

[earok]

Whoops!

Unfortunately there's still a roadblock that I don't think I can work around. The game itself (using Lemmings to test with) sets the POTGO back to it's own value every frame, so it looks like it's not going to work thanks anyway guys

[Retro1234]

earok your onto something

[Cylon]

@earok
I don't really understand what this is all about. Do you try to move the mousepointer with a game pad in port 0 or move the mousepointer with a mouse in port 1 or all at the same time??
Anyway good luck! :-)

[Amiga1992]

Originally Posted by Cylon

o move the mousepointer with a game pad in port 0

that's what he is doing, maybe with port 1 too.
The idea is to not need a mouse.

[Cylon]

Originally Posted by Akira

that's what he is doing, maybe with port 1 too.
The idea is to not need a mouse.

Ahh, okay. And using the easy way of telling the input.device to use a stick as a mouse is not an option because the system is killed, right?

[earok]

Originally Posted by Cylon

Ahh, okay. And using the easy way of telling the input.device to use a stick as a mouse is not an option because the system is killed, right?

Yes. The problem's basically solved, except right mouse simulation doesn't work with every game (though left mouse button and cursor simulation is fine)

I later found out what I did is basically the same approach as what the CD32 ROM does to enable gamepad support on Lemmings CDTV!