Unfortunatly after this update, something broke and now my USB keyboard, mouse and gamepads are not detected anymore. I also updated to the latest flexspin (v 6.2) in case running an older variant was the reason for this problem. But it still didn't fix it. I was previously working with the older usbnew version in commit bce6e7f70d4c8a3f1c26a4f5f003439454152ec1 and that was working with my devices, so something since broke it...trying to figure it out.
Update: Getting closer to pinpointing - build from Jun 9 (83318b3) still works, but top of master does not...
Update2: found it! Looks like you are overriding the USB base pin now from the parent as of two days ago (checkin 3c80dd3) . I wasn't using this default pin and always overriding in the child, but the parent object now has priority. Glad I finally figured it out and it works again.
In terms of controller compatibility, I just tried a Logitech F710 and it works, but strangely not on the root port, only on a hub. P2 board is currently doing standalone neoyume duty, so can't get more diagnostics currently. Switch on the back should be set to "X" for automatically correct layout.
Perhaps useful to know if you want to use a P2 to control your DIY submarine.
I reported the DB9 joystick interface as supported. However, there are limits:
if connected to the root port, OK
if connected to the USB HUB it has to be connected before the P2 (or maybe rather driver) starts. Then it works. If connected, or reconnected after, it does not work.
I am now trying to add a joystick support to the retro interpreter, so it seems I will test more toys. I have also (somewhere in the drawer) a C64 old style USB joystick. My cheap pad didn't work with the usbnew, but this was several versions ago, so maybe it is worth to try if something changed.
if connected to the USB HUB it has to be connected before the P2 (or maybe rather driver) starts. Then it works. If connected, or reconnected after, it does not work.
Does it work if you re-connect the hub with the thing already plugged in?
The joystick interface cannot be read via hidpad_axis(dev,axnum). up, or down, left, or right, it is always $FFFF8000
However, there are useful data somewhere. At position 226,227,228 beginning from @hidpad_report I have horizontal axis (81,7f or 0), vertical axis (the same) and button. The "position"/ ID of the device is now 2 , but the data are on the same place if the device=3 or 1 too (the keyboard is hardwired to #0)
... edit: and these positions are simply raw report buffer as I can also see a keyboard and a mouse there
... edit 2: disabled 'hpad_normalize" procedure in usbnew. Now hidpad_axis returns useful values..
... edit 3: hpad_normalize gets good input data. lminmax is 0081007F, size=8.
Now, why signx htmp1, #15 wc ? That will fail on 8 bit data.
Idk @macca wrote that. I think the problem here is rather that the descriptor sets a min larger than the max. I think what should happen is that the axis gets reversed? Is 81 up/left or down/right?
$81 is min - this is 8bit value, so it is -127, max is $7F, +127. We have data size=8, properly reported, so we should sign extend it from 8th bit, and then all works normal, left is now -32768, right is 32767 and a side effect of this asymetry is -1 at a neutral position.
No, that's not how it works I think, the values are supposed to be unsigned. In this case range is between 127 to 129. (normal analog stick would be between 0 and 255. Non-stupid digital controls also do that)
The interface returns $81 left , 0 neutral and $7F right, so it is obvious that these are signed. There was hardcoded signx #15 in the driver, so whoever wrote that, thought about sign extending 16bit signed values. That of course failed with 8 bits.
I don't have any other working game controller now to test the changed procedure
There is more in it. This signx #15, wc tests also if we have signed or unsigned (16-bit) values. If min has its high bit set, that is signed, else it is unsigned. All is OK, only this hardcoded 15 has to be replaced by size-1
I had to add a res for this... it seems it still works...
I don't think I have any where minimum value is not zero, so uhhhh I guess your idea is right? Might have to check HID spec. You said this thing worked before? How so? Does it also report as a hat?
It worked in your test program before: it was recognized and changes values when moving. I didn't look very carefully at these values then. They were there, they changed on move. Today I tried to add "stick" command to the Basic and then I encountered the error. Left, or right, always $8000
The joystick connected to it has one button that is recognized and can be read. I have now to call getcaps and see what it returns
okay, i think what might be happening is this: the logical maximum needs to be sign extended from the length which it has in the HID descriptor. The item can be coded as 0,1,2 or 4 bytes. I have one of the 0 to 255 pads connected and it codes its logical maximum as a two-byte value:
It reports $30202, 2 buttons, 2 axes, 0 hats, all OK, the DB9 joy can have 2 independent buttons and there is no way to determine that there is only one in the connected device.
This hdr_size2 (added a res where they are) is ugly but I don't have any better ideas now to replace #15 by size-1 without destroying the rest of the procedure.
(Also, unrelatedly, instead of the mov/sub nonsense above, remember that ALTS also works on immediate values, so ALTS something,#511 will substitute something - 1 into next instruction's immediate)
For unsigned values min should be zero, and at least should have its high bit not set. Then signx will not do anything at all, carry will not be set, and retval will be not sign extended.
For signed values, the minimum is less than zero, so it has its high bit set. Then signx will set the carry flag and retval will be sign extended
Retval was already sign extended from size-1, only min was not, hardcoded at #15 instead.
As we are now sign extending from size-1, that will work for all data sizes.
The size-1 thing is just wrong. The meaning of logical minimum doesn't change based on report size. It needs to be extended at the point where it's read from the report, that appears to be the correct behaviour. Though in practice I'm not sure you'll ever find a device with a descriptor that fails with your fix.
The minimum should be reported at the same (or at least not less) size as the value. If reported as wider size, nothing bad can happen. If the min is $81, it can be reported as $FF81 or $FFFFFF81. Or maybe even $F81 or $FFF81 In all cases, when extended from #7, it will be converted to $FFFFFF81 and a carry flag will be set, to extend also the value, which is necessary when it's signed.
Comments
And now there's version 1.0.0-rc2, which fixes a regression and allows multi-report devices on the root port to be used as multiple devices.
Today's live forum outgrowth: "when you have a 7 port hub and 7 dolls..."
Unfortunatly after this update, something broke and now my USB keyboard, mouse and gamepads are not detected anymore.
I also updated to the latest flexspin (v 6.2) in case running an older variant was the reason for this problem. But it still didn't fix it. I was previously working with the older usbnew version in commit bce6e7f70d4c8a3f1c26a4f5f003439454152ec1 and that was working with my devices, so something since broke it...trying to figure it out.
Update: Getting closer to pinpointing - build from Jun 9 (83318b3) still works, but top of master does not...
Update2: found it! Looks like you are overriding the USB base pin now from the parent as of two days ago (checkin 3c80dd3) . I wasn't using this default pin and always overriding in the child, but the parent object now has priority. Glad I finally figured it out and it works again.
I just realized I missed the Live Forum 😞
The last info about live forum on the forums is almost a year old ... I think - The year number isn't actually specified.
In terms of controller compatibility, I just tried a Logitech F710 and it works, but strangely not on the root port, only on a hub. P2 board is currently doing standalone neoyume duty, so can't get more diagnostics currently. Switch on the back should be set to "X" for automatically correct layout.
Perhaps useful to know if you want to use a P2 to control your DIY submarine.
I reported the DB9 joystick interface as supported. However, there are limits:
I am now trying to add a joystick support to the retro interpreter, so it seems I will test more toys. I have also (somewhere in the drawer) a C64 old style USB joystick. My cheap pad didn't work with the usbnew, but this was several versions ago, so maybe it is worth to try if something changed.
Does it work if you re-connect the hub with the thing already plugged in?
Yes, reconnecting the hub makes it work again.
The joystick interface cannot be read via hidpad_axis(dev,axnum). up, or down, left, or right, it is always $FFFF8000
However, there are useful data somewhere. At position 226,227,228 beginning from @hidpad_report I have horizontal axis (81,7f or 0), vertical axis (the same) and button. The "position"/ ID of the device is now 2 , but the data are on the same place if the device=3 or 1 too (the keyboard is hardwired to #0)
... edit: and these positions are simply raw report buffer as I can also see a keyboard and a mouse there
... edit 2: disabled 'hpad_normalize" procedure in usbnew. Now hidpad_axis returns useful values..
... edit 3: hpad_normalize gets good input data. lminmax is 0081007F, size=8.
Now, why signx htmp1, #15 wc ? That will fail on 8 bit data.
@pik33 can you dump the HID descriptor? Sounds like it's not correctly detecting the range of the axis.
Now, the problem was the normalize procedure. That version works for me:
That version works for me:
hpad_normalize mov htmp, hidr_lminmax wz if_z mov htmp, hidr_pminmax wz if_z ret getword htmp1, htmp, #1 ' htmp1 = min getword htmp, htmp, #0 ' htmp = max sub hidr_size,#1 signx htmp1, hidr_size wc if_c signx retval, hidr_size if_c add hidr_size, #1 subs htmp, htmp1 ' htmp = (max - min) subs retval, htmp1 ' retval = (retval - min) shl retval, #16 ' retval = (retval - min) << 16 subs retval, #1 ' retval = ((retval - min) << 16) - 1 abs htmp wc testb retval, #31 wz abs retval qdiv retval, htmp getqx retval if_c_ne_z neg retval ' retval = (((retval - min) << 16) - 1) / (max - min) adds retval, ##$8000 signx 15 rethpad_normalize gets good input data. lminmax is 0081007F, size=8.
Why there is signx htmp1, #15 wc ? That will fail on 8 bit data. Replaced by hidr_size-1
Idk @macca wrote that. I think the problem here is rather that the descriptor sets a min larger than the max. I think what should happen is that the axis gets reversed? Is 81 up/left or down/right?
$81 is min - this is 8bit value, so it is -127, max is $7F, +127. We have data size=8, properly reported, so we should sign extend it from 8th bit, and then all works normal, left is now -32768, right is 32767 and a side effect of this asymetry is -1 at a neutral position.
No, that's not how it works I think, the values are supposed to be unsigned. In this case range is between 127 to 129. (normal analog stick would be between 0 and 255. Non-stupid digital controls also do that)
The interface returns $81 left , 0 neutral and $7F right, so it is obvious that these are signed. There was hardcoded signx #15 in the driver, so whoever wrote that, thought about sign extending 16bit signed values. That of course failed with 8 bits.
I don't have any other working game controller now to test the changed procedure
There is more in it. This signx #15, wc tests also if we have signed or unsigned (16-bit) values. If min has its high bit set, that is signed, else it is unsigned. All is OK, only this hardcoded 15 has to be replaced by size-1
I had to add a res for this... it seems it still works...
I don't think I have any where minimum value is not zero, so uhhhh I guess your idea is right? Might have to check HID spec. You said this thing worked before? How so? Does it also report as a hat?
It worked in your test program before: it was recognized and changes values when moving. I didn't look very carefully at these values then. They were there, they changed on move. Today I tried to add "stick" command to the Basic and then I encountered the error. Left, or right, always $8000
The joystick connected to it has one button that is recognized and can be read. I have now to call getcaps and see what it returns
okay, i think what might be happening is this: the logical maximum needs to be sign extended from the length which it has in the HID descriptor. The item can be coded as 0,1,2 or 4 bytes. I have one of the 0 to 255 pads connected and it codes its logical maximum as a two-byte value:
It reports $30202, 2 buttons, 2 axes, 0 hats, all OK, the DB9 joy can have 2 independent buttons and there is no way to determine that there is only one in the connected device.
hpad_normalize mov htmp, hidr_lminmax wz if_z mov htmp, hidr_pminmax wz if_z ret getword htmp1, htmp, #1 ' htmp1 = min getword htmp, htmp, #0 ' htmp = max mov hidr_size2,hidr_size sub hidr_size2,#1 signx htmp1, hidr_size2 wc if_c sub hidr_size, #1 if_c signx retval, hidr_size if_c add hidr_size, #1 subs htmp, htmp1 ' htmp = (max - min) subs retval, htmp1 ' retval = (retval - min) shl retval, #16 ' retval = (retval - min) << 16 subs retval, #1 ' retval = ((retval - min) << 16) - 1 abs htmp wc testb retval, #31 wz abs retval qdiv retval, htmp getqx retval if_c_ne_z neg retval ' retval = (((retval - min) << 16) - 1) / (max - min) adds retval, ##$8000 signx 15 retThis hdr_size2 (added a res where they are) is ugly but I don't have any better ideas now to replace #15 by size-1 without destroying the rest of the procedure.
Try reverting the normalize routine and instead putting this further up at
.next.next cmps pa, #0 wcz if_be ret wcz rdbyte hpar1, ptra++ sub pa, #1 mov hpar2, #0 mov htmp, hpar1 and htmp, #$03 cmp htmp, #1 wz if_z rdbyte hpar2, ptra++ if_z signx hpar2,#7 if_z sub pa, #1 cmp htmp, #2 wz if_z rdword hpar2, ptra++ if_z signx hpar2,#15 if_z sub pa, #2 cmp htmp, #3 wz if_z rdlong hpar2, ptra++ if_z sub pa, #4(Also, unrelatedly, instead of the mov/sub nonsense above, remember that ALTS also works on immediate values, so
ALTS something,#511will substitute something - 1 into next instruction's immediate)That alts is the simplest thing that works.
But that's not really the correct fix, eitherhow.
I've put the fix on github btw.
Why?
For unsigned values min should be zero, and at least should have its high bit not set. Then signx will not do anything at all, carry will not be set, and retval will be not sign extended.
For signed values, the minimum is less than zero, so it has its high bit set. Then signx will set the carry flag and retval will be sign extended
Retval was already sign extended from size-1, only min was not, hardcoded at #15 instead.
As we are now sign extending from size-1, that will work for all data sizes.
I don't see any errors in it now.
The size-1 thing is just wrong. The meaning of logical minimum doesn't change based on report size. It needs to be extended at the point where it's read from the report, that appears to be the correct behaviour. Though in practice I'm not sure you'll ever find a device with a descriptor that fails with your fix.
The minimum should be reported at the same (or at least not less) size as the value. If reported as wider size, nothing bad can happen. If the min is $81, it can be reported as $FF81 or $FFFFFF81. Or maybe even $F81 or $FFF81
In all cases, when extended from #7, it will be converted to $FFFFFF81 and a carry flag will be set, to extend also the value, which is necessary when it's signed.