These oldschool DB9 joystick are called "Atari type" but they were used in all home computers: Atari 8bit, Atari ST, C64, Amiga. And this is the interface for connecting such a joystick to the modern PC (and now also to the P2) USB port.
Damn, I just grabbed your latest @Wuerfel_21 after your last post here and now it doesn't respond to my keyboard in hidpad_to_vga or keyevent_to_vga. It does seem to update the keyboard boot buffer in the emupad_to_vga program however.
PS3 DualShock3 controller - already reported
ID=054C0268
All buttons, sticks & HAT reporting. Right analog Joystick Up and Down both reported in Z-AXIS?
Well that wouldn't be right - the right analog should have left/right in Z and up/down in RZ - ????? please reconfirm
Generic USB game controller (SNES style) works well, all buttons.
ID=081FE401
But what are the buttons (numbers)? The press wants to know.
Generic control board marketed as "Zero Delay Arcade USB encoder" or "ARC Controller" etc works well
ID=00790006
@rogloh said:
Damn, I just grabbed your latest @Wuerfel_21 after your last post here and now it doesn't respond to my keyboard in hidpad_to_vga or keyevent_to_vga. It does seem to update the keyboard boot buffer in the emupad_to_vga program however.
Well that's strange because right now I only really changed the buffer logic (and put in some modifier-related stuff that fell under the table a while ago)
Can you go back and tell me which commit breaks it?
PS3 DualShock3 controller - already reported
ID=054C0268
All buttons, sticks & HAT reporting. Right analog Joystick Up and Down both reported in Z-AXIS?
Well that wouldn't be right - the right analog should have left/right in Z and up/down in RZ - ????? please reconfirm
They are getting mixed together somehow. Will reconfirm exactly once I get your code downgraded back to a working version...latest broke it.
Generic USB game controller (SNES style) works well, all buttons.
ID=081FE401
But what are the buttons (numbers)? The press wants to know.
The buttons were all matching your graphical rendition on screen in emupad_to_vga for this controller. I will check the triggers to see whether it was b5 vs b7 etc.
Ok downgraded back to what I think I had yesterday (1732ec0b961324b28259df85f4398a5669b10d19) and I see the controller triggers are b4 and b5 matching left and right on-screen in emupad_to_vga.
Can't get hidpad_to_vga working (still) things are really flakey now, and I'm not sure what is going on. Still messing about.
Silly me forgot I rebooted my Mac today and I needed to re-alias "flexspin" back to the latest spin2cpp build folder! It reverted to a different version of flexspin built one day older which silently failed to work right. Damn this tool versioning!
I do see the PS3 controller working with Z and RZ axes reporting with changes to the right analog stick (L/R = Z, U/D = RZ). I think when I saw this issue before it was just very sensitive to the position but if you hold it centered and carefully move up and down or left and right you can avoid changes in the other axis.
Update: nice to see the keyboard, mouse and gamepads all working at the same time when pressing keys and game buttons simultaneously and moving the mouse. New key buffer seems to work too.
@rogloh said:
Silly me forgot I rebooted my Mac today and I needed to re-alias "flexspin" back to the latest spin2cpp build folder! It reverted to a different version of flexspin built one day older which silently failed to work right. Damn this tool versioning!
Happens to the best of us. Though I usually only update my %PATH% flexspin to proper releases and call the hot dev version explicitly with something like ../spin2cpp/build/flexspin
Don't think it ever happened that I released something that didn't require the very latest flexspin. I'm like a bug magnet.
Yeah I like to use a stable toolchain. I temporarily mapped my flexspin via an alias to the latest and greatest yesterday to test it out, but it wasn't also setup in my zshrc file to the same folder. You reboot, forget about it and then bang, broken tools.
Other good news. I tested out a Microsoft Intellimouse Explorer 2.0 and it worked - no scroll wheel though.
I also got a Microsoft Wheel Mouse Optical 1.1A mouse working too (same issue with scroll wheel)
I also got a small wireless Logitech mouse M185 with tiny USB wireless dongle working and its scroll wheel did work with this so it could be a good solution for a P2 if you want a 2.4GHz wireless mouse as these are still available cheap.
The mouse scroll wheel issue should be fixed when I get around to mouse descriptor parsing. Though maybe that'll also reduce overall compatibility, I don't know. The mouse descriptors I've seen aren't too bad.
@Wuerfel_21 said:
You can add the rule to the bottom of the emupad test to verify it (it doesn't load from file for simplicity)
Can give me that PNG, but not annotated?
@Wuerfel_21
Messing about with your code a bit I think it probably makes sense to have some way to set the existing mouse co-ordinates from the client side which I didn't see in the existing USB mouse API - I know it's still early days. This could then control where the mouse cursor is currently situated on screen, both at startup (e.g to default it in the centre of a window instead of top left), or just if you need to reposition it from some application code for any reason later. Something like a usb.mouse_set_pos(x,y) would be good for example.
If we had this functionality it would be nice:
init/detect mouse presence or reattachment
set/get mouse pos
get button states
set boundary limits
maybe in the future some API to set scaling or possible acceleration params used by the low level driver to compute co-ordinates
Now you have a basic USB mouse working I'm also considering extending my p2textdrv API to provide a few more APIs to show/hide the mouse and return where the co-ordinates are to be updated in HUB RAM so you don't have to inconveniently bypass my API layer as you discovered you needed to.
Probably I should try to add something like this to a future p2textdrv.spin2:
' mouse methods
PUB showMouse(spritedata, xhot, yhot)
video.setMouseImage(@region, spritedata, xhot, yhot) ' setup a mouse sprite and its hot spot co-ordinates
video.showMouse(@region, 0) ' enable display of a global mouse
PUB hideMouse()
video.hideMouse(@region) ' hide the mouse
PUB getMouseAddr() : addr
return @display + 28 ' returns address of x,y co-ordinate long for global mouse
You could then enable the mouse on a (4bpp text) screen with something like this:
usb.start()
usb.mouse_set_limits(640-1,480-1)
usb.mouse_set_outptr(text.getMouseAddr())
text.showMouse(@mouse4bpp, 4, 0)) ' show the mouse
In an application the button states and co-ordinates should of course be read from the USB mouse API itself. If required an on screen mouse sprite can still change its pattern dynamically by continuing to call showMouse after startup, passing the updated image data from the client. This can occur if you want to move over text boxes or other screen elements and change its style/colour etc. This is mostly needed in graphics environments, less so for pure text screens unless you have a TUI, but useful nonetheless.
Set mouse position is needed in the USB driver to avoid translation when the application itself (and not the user) needs to move the mouse pointer. Also, in this convention where we have x, y and z, it should be usb.mouse_set_pos(x,y,z) . Or usb.mouse_set_pos(x,y) and usb.mouse_set_wheel(z)
The reason position set isn't implemented is because it's tricky to do without edge cases (set ignored when it happens at the same time as polling). If you want to do funky stuff do it in the application and update the screen cursor yourself.
@Wuerfel_21 said:
The reason position set isn't implemented is because it's tricky to do without edge cases (set ignored when it happens at the same time as polling). If you want to do funky stuff do it in the application and update the screen cursor yourself.
Yeah I've been fighting this today trying to figure a way that is workable and handles corner cases. Not so simple as you mention. Here's what I was thinking:
In some SPIN2 mouse_set_xyz(x,y,z) API:
set a mouse position update "software lock" flag
small delay to account for driver's critical section timing between its HUB reads and its write back operations (probably just a couple of hundred P2 clocks or so, needs to be given a sufficiently large delay)
update HUB x,y,z accumulators to the new x,y,z values
update mouse sprite X,Y position long (if this is not done the mouse won't move on screen until the mouse is physically moved)
clear mouse position update lock flag
In the USB driver's mouse report handler code:
the mouse report occurs
read mouse position update flag from HUB
read current x,y,z accumulator values from HUB
do normal mouse processing with x,y,z increment/decrement computations, and handle button state changes
update button state to HUB RAM but only write back new x,y,z accumulators if update flag was cleared when it was read
update mouse sprite X,Y position long if update flag was clear
@Wuerfel_21 said:
The reason position set isn't implemented is because it's tricky to do without edge cases (set ignored when it happens at the same time as polling). If you want to do funky stuff do it in the application and update the screen cursor yourself.
Yeah I've been fighting this today trying to figure a way that is workable and handles corner cases. Not so simple as you mention. Here's what I was thinking:
In some SPIN2 mouse_set_xyz(x,y,z) API:
set a mouse position update "software lock" flag
small delay to account for driver's critical section timing between its HUB reads and its write back operations (probably just a couple of hundred P2 clocks or so, needs to be given a sufficiently large delay)
update HUB x,y,z accumulators to the new x,y,z values
update mouse sprite X,Y position long (if this is not done the mouse won't move on screen until the mouse is physically moved)
clear mouse position update lock flag
In the USB driver's mouse report handler code:
the mouse report occurs
read mouse position update flag from HUB
read current x,y,z accumulator values from HUB
do normal mouse processing with x,y,z increment/decrement computations, and handle button state changes
update button state to HUB RAM but only write back new x,y,z accumulators if update flag was cleared when it was read
update mouse sprite X,Y position long if update flag was clear
I think this should work but I will try it.
It can be done simpler. We need 3 variables in the driver for new x,y and z, initialized at something negative, eg $80000000. The Spin method simply sets them with given values. The asm code, while updating the mouse position, checks if these variables are positive. If yes, instead of adding deltas to positions, rewrite them with new values, then set new variables to $80000000 again.
I want now to add the driver to prop2play, so I can experiment with this.
Btw, mouse presence detection couls be easily added, but is a bad idea. A mouse interface configured != A mouse physically exists != The user wants to use the mouse.
The correct way to show/hide the cursor in a mouse-optional application is to start showing it when the mouse is moving and, if desired, hide it when it stops moving or keyboard navigation is engaged.
@Wuerfel_21 said:
A better question: why?
What's the point of yoinking the cursor position?
In general you don't need to, but maybe you want to center the mouse cursor at startup so it's immediately visible, or if you had two COGs sharing the display and each had their own cursor position state you could hit some key to flip the window and the mouse position could be retained from prior session/window etc. There are a few use cases, but admittedly not that many.
Region mice are other things possible in my driver - each region can have its own mouse sprite not just a single global one. Maybe you want to multiplex a single physical device in different window regions with different co-ordinates (but not simulataneously - that'd be crazy).
7-port hub strange behavior: 4 ports works of 7 available. I'd be less surprised if only 3 were working: that would mean the second hub in the chain is not supported.
Comments
Wow, old-school. An old Atari is it, or for something else like Commodore/Amiga?
These oldschool DB9 joystick are called "Atari type" but they were used in all home computers: Atari 8bit, Atari ST, C64, Amiga. And this is the interface for connecting such a joystick to the modern PC (and now also to the P2) USB port.
"tail' not declared
PUB peek_key() : r tail := keyq_tail if keyq_head == tail return 0 ' No event else return keyq_data[tail].. and it seems something may be wrong with get_key()
This Basic loop simply prints the received hex code
The result is: if I press a key, I got bit 31 set and the scan code of the previous pressed key. When releasing the key, the scan code is OK.
Oh yea, I never tested that method, just add the variable.
Hmm, could well be that I fumbled the ring buffer logic in a a slighty obnoxious way, will look into it.
@pik33 fixed!
Damn, I just grabbed your latest @Wuerfel_21 after your last post here and now it doesn't respond to my keyboard in hidpad_to_vga or keyevent_to_vga. It does seem to update the keyboard boot buffer in the emupad_to_vga program however.
Well that wouldn't be right - the right analog should have left/right in Z and up/down in RZ - ????? please reconfirm
But what are the buttons (numbers)? The press wants to know.
Ok.
Well that's strange because right now I only really changed the buffer logic (and put in some modifier-related stuff that fell under the table a while ago)
Can you go back and tell me which commit breaks it?
They are getting mixed together somehow. Will reconfirm exactly once I get your code downgraded back to a working version...latest broke it.
The buttons were all matching your graphical rendition on screen in emupad_to_vga for this controller. I will check the triggers to see whether it was b5 vs b7 etc.
Ok downgraded back to what I think I had yesterday (1732ec0b961324b28259df85f4398a5669b10d19) and I see the controller triggers are b4 and b5 matching left and right on-screen in emupad_to_vga.
Can't get hidpad_to_vga working (still) things are really flakey now, and I'm not sure what is going on. Still messing about.
Silly me forgot I rebooted my Mac today and I needed to re-alias "flexspin" back to the latest spin2cpp build folder! It reverted to a different version of flexspin built one day older which silently failed to work right. Damn this tool versioning!
I do see the PS3 controller working with Z and RZ axes reporting with changes to the right analog stick (L/R = Z, U/D = RZ). I think when I saw this issue before it was just very sensitive to the position but if you hold it centered and carefully move up and down or left and right you can avoid changes in the other axis.
Update: nice to see the keyboard, mouse and gamepads all working at the same time when pressing keys and game buttons simultaneously and moving the mouse. New key buffer seems to work too.
Happens to the best of us. Though I usually only update my %PATH%
flexspinto proper releases and call the hot dev version explicitly with something like../spin2cpp/build/flexspinDon't think it ever happened that I released something that didn't require the very latest flexspin. I'm like a bug magnet.
Yeah I like to use a stable toolchain. I temporarily mapped my flexspin via an alias to the latest and greatest yesterday to test it out, but it wasn't also setup in my zshrc file to the same folder. You reboot, forget about it and then bang, broken tools.
Other good news. I tested out a Microsoft Intellimouse Explorer 2.0 and it worked - no scroll wheel though.
I also got a Microsoft Wheel Mouse Optical 1.1A mouse working too (same issue with scroll wheel)
I also got a small wireless Logitech mouse M185 with tiny USB wireless dongle working and its scroll wheel did work with this
so it could be a good solution for a P2 if you want a 2.4GHz wireless mouse as these are still available cheap.
I started now to convert my toys to USB... MicroDOS converted (this uses keyboard only), Prop2play to do.
The mouse scroll wheel issue should be fixed when I get around to mouse descriptor parsing. Though maybe that'll also reduce overall compatibility, I don't know. The mouse descriptors I've seen aren't too bad.
Oh yea, and I think I cought up with all the gamepad compatibility reports.
Success with this cheap LogiTech , Model G-UG15 controller. But, the right-side buttons are switched around...
Cog2 hdev_port = 0, #hdev_id = $046D_C21A, $0000_0000, $0000_0000, $0000_0000, $0000_0000, hdev_bcd = $0004
Cog2 hconfig_base = $09, $02, $22, $00, $01, $01, $00, $80, $19, $09, $04, $00, $00, $01, $03, $00, $00, $00, $09, $21, $10, $01, $00, $01, $22, $3D, $00, $07, $05, $81, $03, $08, $00, $0A
Cog2 hdev_intf_idx = 0, hdev_class = $03, hdev_subclass = $00, hdev_protocol = $00
Cog2 hdev_ep_addr = $0040_8800, (hdev_ep_addr + 1) = $0000_0000, (hdev_ep_addr + 2) = $0000_0000, (hdev_ep_addr + 3) = $0000_0000, (hdev_ep_addr + 4) = $0000_0000, gp_interval = 10, hdev_out_addr = $0000_0000
Cog2 pb = $7B33, pb = $05, $01, $09, $04, $A1, $01, $A1, $02, $75, $08, $95, $02, $15, $00, $26, $FF, $00, $35, $00, $46, $FF, $00, $09, $30, $09, $31, $81, $02, $75, $01, $95, $0A, $25, $01, $45, $01, $05, $09, $19, $01, $29, $0A, $81, $02, $06, $00, $FF, $75, $01, $95, $06, $25, $01, $45, $01, $09, $01, $81, $02, $C0, $C0
Cog2 hdev_type = $0000_0006, (hdev_type + 1) = $0000_0000
emupad_to_vga.spin2 shows that these buttons are off:
dgately
@dgately nice
To make the button layout right, the rule should be
You can add the rule to the bottom of the emupad test to verify it (it doesn't load from file for simplicity)
Can give me that PNG, but not annotated?
Adding that rule works!
@Wuerfel_21
Messing about with your code a bit I think it probably makes sense to have some way to set the existing mouse co-ordinates from the client side which I didn't see in the existing USB mouse API - I know it's still early days. This could then control where the mouse cursor is currently situated on screen, both at startup (e.g to default it in the centre of a window instead of top left), or just if you need to reposition it from some application code for any reason later. Something like a
usb.mouse_set_pos(x,y)would be good for example.If we had this functionality it would be nice:
Now you have a basic USB mouse working I'm also considering extending my p2textdrv API to provide a few more APIs to show/hide the mouse and return where the co-ordinates are to be updated in HUB RAM so you don't have to inconveniently bypass my API layer as you discovered you needed to.
Probably I should try to add something like this to a future p2textdrv.spin2:
' mouse methods PUB showMouse(spritedata, xhot, yhot) video.setMouseImage(@region, spritedata, xhot, yhot) ' setup a mouse sprite and its hot spot co-ordinates video.showMouse(@region, 0) ' enable display of a global mouse PUB hideMouse() video.hideMouse(@region) ' hide the mouse PUB getMouseAddr() : addr return @display + 28 ' returns address of x,y co-ordinate long for global mouseYou could then enable the mouse on a (4bpp text) screen with something like this:
In an application the button states and co-ordinates should of course be read from the USB mouse API itself. If required an on screen mouse sprite can still change its pattern dynamically by continuing to call showMouse after startup, passing the updated image data from the client. This can occur if you want to move over text boxes or other screen elements and change its style/colour etc. This is mostly needed in graphics environments, less so for pure text screens unless you have a TUI, but useful nonetheless.
Set mouse position is needed in the USB driver to avoid translation when the application itself (and not the user) needs to move the mouse pointer. Also, in this convention where we have x, y and z, it should be
usb.mouse_set_pos(x,y,z). Orusb.mouse_set_pos(x,y)andusb.mouse_set_wheel(z)The reason position set isn't implemented is because it's tricky to do without edge cases (set ignored when it happens at the same time as polling). If you want to do funky stuff do it in the application and update the screen cursor yourself.
Am on the move, more later..
Yeah I've been fighting this today trying to figure a way that is workable and handles corner cases. Not so simple as you mention. Here's what I was thinking:
In some SPIN2 mouse_set_xyz(x,y,z) API:
In the USB driver's mouse report handler code:
I think this should work but I will try it.
A better question: why?
What's the point of yoinking the cursor position?
It can be done simpler. We need 3 variables in the driver for new x,y and z, initialized at something negative, eg $80000000. The Spin method simply sets them with given values. The asm code, while updating the mouse position, checks if these variables are positive. If yes, instead of adding deltas to positions, rewrite them with new values, then set new variables to $80000000 again.
I want now to add the driver to prop2play, so I can experiment with this.
Btw, mouse presence detection couls be easily added, but is a bad idea. A mouse interface configured != A mouse physically exists != The user wants to use the mouse.
The correct way to show/hide the cursor in a mouse-optional application is to start showing it when the mouse is moving and, if desired, hide it when it stops moving or keyboard navigation is engaged.
In general you don't need to, but maybe you want to center the mouse cursor at startup so it's immediately visible, or if you had two COGs sharing the display and each had their own cursor position state you could hit some key to flip the window and the mouse position could be retained from prior session/window etc. There are a few use cases, but admittedly not that many.
Region mice are other things possible in my driver - each region can have its own mouse sprite not just a single global one. Maybe you want to multiplex a single physical device in different window regions with different co-ordinates (but not simulataneously - that'd be crazy).
Yes, the app can show the cursor when mouse move detected and, for example, hide it after a timeout without moving.
7-port hub strange behavior: 4 ports works of 7 available. I'd be less surprised if only 3 were working: that would mean the second hub in the chain is not supported.