@Wuerfel_21 said:
So, what about making the second port work? The driver seems to be written to really only work with one, so I guess some major rewriting would have to occur.
I was going to comment on the Megayume thread about this.
I have already modified the PASM-only driver to run multiple instances, the sources are now on Github too https://github.com/maccasoft/P2
Examples can be found on the emulators, for example the MSX emulator allows up to 3 USB instances for keyboard and the two joystick ports, basically you need to pass a pointer to the port settings which aside from the pin numbers include the data buffers. Detecting what port is running the decoding code is easily done by comparing the pin numbers.
The Spin driver should already work with multiple instances, at least the 2xKbMObjDemo uses two instances of the same driver. It should be just a matter of listening on the correct event notification pin.
@Wuerfel_21 said:
Yeah, but that's just starting multiple instances of the driver into multiple cogs, not the driver being able to handle multiple ports.
Yes, AFAIK the driver can't handle multiple ports, not even the original, and I think it will be very difficult to make it work with multiple ports, there are a number of registers used by the routines that needs to the swapped for each port, with wrapper code and/or alts/altd instructions, and device code needs to know which port is using. Not impossible, certainly, but I think this is beyond my current interest in it.
I was however thinking of implementing the support for hubs, doesn't seems much difficult once you understand the logic, right now I don't have a spare hub to start testing so this may take a while.
@Wuerfel_21 said:
Yeah, but that's just starting multiple instances of the driver into multiple cogs, not the driver being able to handle multiple ports.
A full USB hub implementation is more complex than I had hoped when you read the spec. A little while back I was originally wondering if some type of "poor man's" USB muxing "hub" could be made to work with some subset of USB peripherals using two physical USB ports on the P2 (probably at the same speed), given the P2's ability to dynamically redirect port IO via smartpin mappings between frames. This way one USB host driver COG could then perhaps manage two devices (like keyboard and mouse). Maybe there is a way to do some of this sort of thing but it needs some real low level pin and driver hacking. And the 1ms frame sync pulses and plug in state machine stuff obviously gets complex, perhaps even unworkable this way, not sure...
@macca said:
I was however thinking of implementing the support for hubs, doesn't seems much difficult once you understand the logic, right now I don't have a spare hub to start testing so this may take a while.
It would be great to get support for hubs if you think this is reasonably doable. (That is, allowing hubs to connect to the P2 USB port, and not have the P2 USB ports behave somewhat like a hub, which is what I was mentioning above.)
For those interested, I have pushed an initial, not much tested, support for USB HUBs to the repository below.
Currently it supports only full speed devices so it is actually useful for multiple gamepad devices. It should work well with XInput and PS3 controllers, HID devices needs to be tested because I discovered that my other two HID controllers (NES and SNES replicas) are low speed so doesn't work.
Also, while it should work with 7 ports HUBs it uses only the first 4, because that's the number of ports of my test hub and because the support is very rough and needs some better devices handling.
Supporting low speed devices seems more complicated than expected.
The theory seems clear, the host needs to send a preamble sequence (SYN+PRE bytes) to tell the hub to turn on the low speed ports, switch to low speed signaling and proceed normally. Then the hub switch back to full speed on its own at the end of the packet.
In practice I have absolutely no way to verify if these things are actually working. Maybe with an USB protocol analyzer it could be fixed quickly but these things are too expensive for me.
So if somebody wants to experiment with it and can find a solution it is very welcome.
You may be able to monitor the USB pins with another COG, streaming sampled data from the two IO pins at 1.5MHz or 12MHz as required. I used this technique when developing some HDMI stuff on the P2 and could capture the encoded TMDS data at 252MHz into HUB RAM, so the much slower USB should be a bit easier. If you can't read back directly from the USB pins themselves, you might be able to map other nearby pins to take their inputs from the neighboring USB pin output state. The P2 makes a decent capture tool for stuff like this.
@macca said:
Maybe with an USB protocol analyzer it could be fixed quickly but these things are too expensive for me.
I think(tm) you can do USB analysis with a cheap logic analyzer, but I haven't tried it myself.
AFAIK, this won't decode the USB data stream, looking at the bit flips isn't of much use, at least for me. In addition logic analyzers capture just a portion of data, triggering the right time to start capture (for example by flipping an additional pin) may add more complications due to the additional instructions.
@rogloh said:
You may be able to monitor the USB pins with another COG, streaming sampled data from the two IO pins at 1.5MHz or 12MHz as required.
While this seems interesting to do as a side project, and maybe partially solves the decoding issue with a logic analyzer above, it adds another point of failure because I can't be sure the data is decoded correctly. I mean I know when I send the PREamble data but I don't know if it is sent at the right time, with the right delays and if the speed is switched at the right time. I don't even know if switching to low speed baud rate is correct, the USB documentation says that after preamble the data is sent at low speed, while some sites (and a comment in the driver itself) say that the speed is unchanged, only the signaling is changed to low speed (polarity ?). Assuming the documentation is correct, something else doesn't work correctly and something that tells me what I already know is not of much use.
@macca ,
Does your hub code support the actual USB devices or just the hub? I went to gethub and looked at the code, but I am not much good at reading P2ASM.
Jim
@RS_Jim said:
Does your hub code support the actual USB devices or just the hub? I went to gethub and looked at the code, but I am not much good at reading P2ASM.
Not sure to understand, it supports a HUB connected directly to the P2 port and the devices connected to the HUB. Aside from the full speed devices limitation, from the client perspective the HUB is totally transparent and the devices are detected and working as they were directly connected to the P2.
@RS_Jim said:
Ok, for example, if I connect a full speed mouse to the P2 via the hub, I will see the XY position data? Or do I need the USB Mouse support code?
The HUB is just a signal repeater, specific devices support still requires the appropriate code to handle the data from the device itself. This driver doesn't support mouse (I have removed the code because it isn't used in the emulators) so if you connect it to the hub, the driver will recognize it with some debug lines output but doesn't return any data, the same if you connect the mouse directly to the P2 (with this driver). But if you add back the mouse decoder support it will work.
@macca said:
Maybe with an USB protocol analyzer it could be fixed quickly but these things are too expensive for me.
I think(tm) you can do USB analysis with a cheap logic analyzer, but I haven't tried it myself.
AFAIK, this won't decode the USB data stream, looking at the bit flips isn't of much use, at least for me. In addition logic analyzers capture just a portion of data, triggering the right time to start capture (for example by flipping an additional pin) may add more complications due to the additional instructions.
The Saleae software I use on my crud-tier clone device has USB 1.1 decoding support (haven't tried if it actually works well, given the low sample rate on the device) and can record for pretty much as long as you want. I use it like this:
Reset P2
Compile/Upload code
While that is going, start logic capture
Let it run for a bit
Examine the capture
Relatedly, I examined your hub code and it looks decently clean enough to merge into my driver versions. Well, there's some kinda uggo code that has explicit cases for each device id that could be condensed, but oh well.
Good news, I finally sorted out the preamble signaling thing to enable the low speed ports and managed to get a keyboard (LS) and a PS3 controller (FS) working together.
There are still a number of things to fix in the driver before being ready for general use.
Hmm, if you're gonna a bunch of changes I might just re-base my changes (really just the device to button bitfield mapping code) on your version when you're done (instead of me merging the hub support manually). Would need some re-thinking for multiple devices, anyways. You're working with pure PASM though, idk how much muckery that'd need to make work in a Spin env again.
@macca said:
Good news, I finally sorted out the preamble signaling thing to enable the low speed ports and managed to get a keyboard (LS) and a PS3 controller (FS) working together.
There are still a number of things to fix in the driver before being ready for general use.
That is very good news. So ultimately when you are done, what combinations of mice, keyboard and/or game controllers do you think should be possible with your USB device polling logic? Is it just going to be two devices only or could it more than two (ie. up to 4 HID devices of any supported type for a 4 port hub?) It would be great to have a mouse, a keyboard and two gamepads all supported from the same driver through a HUB IMO and would save COGs.
@rogloh said:
That is very good news. So ultimately when you are done, what combinations of mice, keyboard and/or game controllers do you think should be possible with your USB device polling logic? Is it just going to be two devices only or could it more than two (ie. up to 4 HID devices of any supported type for a 4 port hub?) It would be great to have a mouse, a keyboard and two gamepads all supported from the same driver through a HUB IMO and would save COGs.
The plan is to support all combinations and even 7-ports hubs, the current limit to 4 is only because the code is a bit "patched" to support multiple devices, when properly implemented there is no reason to not support all 7 ports.
@macca said:
The plan is to support all combinations and even 7-ports hubs, the current limit to 4 is only because the code is a bit "patched" to support multiple devices, when properly implemented there is no reason to not support all 7 ports.
@pik33 said:
These 7-port hubs are 2 4-port hubs internally connected (and 1 of 8 ports is used for this connection)
Yes, I've read that too, and was a bit puzzled because, AFAIK, there aren't technical resons for that (maybe practical/economic...).
BTW, for those interested, I'm using this hub found on e-bay:
Also got this one because I tought it could be useful for a custom board
however I didn't noticed that the pins are not 2.54mm spaced (and don't even match the usb connectors I have...).
@Rayman said:
Nice work @macca !
Will this allow two players in NeoYume?
Even four if allowed...
Kizuna Encounter exists as the sole NeoGeo game with 4 player support (on one machine - some other games have a serial link to get 4 players by synchronizing two machines). Seems to be rather simple to add support for, but IDK if the game will read it in AES mode.
On the MegaYume side there's a handful of 4 player games, but there's like 3 different ways to read extra controllers (SEGA and EA made mutually incompatible multitap adapters. Also some games have extra ports on the cartridge itself)
@pik33 said:
These 7-port hubs are 2 4-port hubs internally connected (and 1 of 8 ports is used for this connection)
Yes, I've read that too, and was a bit puzzled because, AFAIK, there aren't technical resons for that (maybe practical/economic...).
There are cheap 4-port USB hub chips and that is the main reason. (=economic/practical, it is easier to connect 2 (or more, 10-port hubs exist) hub chips as it is already in the USB standard and costs nothing (except one wasted port), than developing a new, more-port chip.
@pik33 said:
These 7-port hubs are 2 4-port hubs internally connected (and 1 of 8 ports is used for this connection)
Yes, I've read that too, and was a bit puzzled because, AFAIK, there aren't technical resons for that (maybe practical/economic...).
There are cheap 4-port USB hub chips and that is the main reason. (=economic/practical, it is easier to connect 2 (or more, 10-port hubs exist) hub chips as it is already in the USB standard and costs nothing (except one wasted port), than developing a new, more-port chip.
Yeah likely same reason for 5 port vs 8 port Ethernet switches too.
Comments
I was going to comment on the Megayume thread about this.
I have already modified the PASM-only driver to run multiple instances, the sources are now on Github too https://github.com/maccasoft/P2
Examples can be found on the emulators, for example the MSX emulator allows up to 3 USB instances for keyboard and the two joystick ports, basically you need to pass a pointer to the port settings which aside from the pin numbers include the data buffers. Detecting what port is running the decoding code is easily done by comparing the pin numbers.
The Spin driver should already work with multiple instances, at least the 2xKbMObjDemo uses two instances of the same driver. It should be just a matter of listening on the correct event notification pin.
Yeah, but that's just starting multiple instances of the driver into multiple cogs, not the driver being able to handle multiple ports.
Yes, AFAIK the driver can't handle multiple ports, not even the original, and I think it will be very difficult to make it work with multiple ports, there are a number of registers used by the routines that needs to the swapped for each port, with wrapper code and/or alts/altd instructions, and device code needs to know which port is using. Not impossible, certainly, but I think this is beyond my current interest in it.
I was however thinking of implementing the support for hubs, doesn't seems much difficult once you understand the logic, right now I don't have a spare hub to start testing so this may take a while.
A full USB hub implementation is more complex than I had hoped when you read the spec. A little while back I was originally wondering if some type of "poor man's" USB muxing "hub" could be made to work with some subset of USB peripherals using two physical USB ports on the P2 (probably at the same speed), given the P2's ability to dynamically redirect port IO via smartpin mappings between frames. This way one USB host driver COG could then perhaps manage two devices (like keyboard and mouse). Maybe there is a way to do some of this sort of thing but it needs some real low level pin and driver hacking. And the 1ms frame sync pulses and plug in state machine stuff obviously gets complex, perhaps even unworkable this way, not sure...
It would be great to get support for hubs if you think this is reasonably doable. (That is, allowing hubs to connect to the P2 USB port, and not have the P2 USB ports behave somewhat like a hub, which is what I was mentioning above.)
For those interested, I have pushed an initial, not much tested, support for USB HUBs to the repository below.
Currently it supports only full speed devices so it is actually useful for multiple gamepad devices. It should work well with XInput and PS3 controllers, HID devices needs to be tested because I discovered that my other two HID controllers (NES and SNES replicas) are low speed so doesn't work.
Also, while it should work with 7 ports HUBs it uses only the first 4, because that's the number of ports of my test hub and because the support is very rough and needs some better devices handling.
Supporting low speed devices seems more complicated than expected.
The theory seems clear, the host needs to send a preamble sequence (SYN+PRE bytes) to tell the hub to turn on the low speed ports, switch to low speed signaling and proceed normally. Then the hub switch back to full speed on its own at the end of the packet.
In practice I have absolutely no way to verify if these things are actually working. Maybe with an USB protocol analyzer it could be fixed quickly but these things are too expensive for me.
So if somebody wants to experiment with it and can find a solution it is very welcome.
I think(tm) you can do USB analysis with a cheap logic analyzer, but I haven't tried it myself.
You may be able to monitor the USB pins with another COG, streaming sampled data from the two IO pins at 1.5MHz or 12MHz as required. I used this technique when developing some HDMI stuff on the P2 and could capture the encoded TMDS data at 252MHz into HUB RAM, so the much slower USB should be a bit easier. If you can't read back directly from the USB pins themselves, you might be able to map other nearby pins to take their inputs from the neighboring USB pin output state. The P2 makes a decent capture tool for stuff like this.
AFAIK, this won't decode the USB data stream, looking at the bit flips isn't of much use, at least for me. In addition logic analyzers capture just a portion of data, triggering the right time to start capture (for example by flipping an additional pin) may add more complications due to the additional instructions.
While this seems interesting to do as a side project, and maybe partially solves the decoding issue with a logic analyzer above, it adds another point of failure because I can't be sure the data is decoded correctly. I mean I know when I send the PREamble data but I don't know if it is sent at the right time, with the right delays and if the speed is switched at the right time. I don't even know if switching to low speed baud rate is correct, the USB documentation says that after preamble the data is sent at low speed, while some sites (and a comment in the driver itself) say that the speed is unchanged, only the signaling is changed to low speed (polarity ?). Assuming the documentation is correct, something else doesn't work correctly and something that tells me what I already know is not of much use.
@macca ,
Does your hub code support the actual USB devices or just the hub? I went to gethub and looked at the code, but I am not much good at reading P2ASM.
Jim
Not sure to understand, it supports a HUB connected directly to the P2 port and the devices connected to the HUB. Aside from the full speed devices limitation, from the client perspective the HUB is totally transparent and the devices are detected and working as they were directly connected to the P2.
Ok, for example, if I connect a full speed mouse to the P2 via the hub, I will see the XY position data? Or do I need the USB Mouse support code?
Jim
The HUB is just a signal repeater, specific devices support still requires the appropriate code to handle the data from the device itself. This driver doesn't support mouse (I have removed the code because it isn't used in the emulators) so if you connect it to the hub, the driver will recognize it with some debug lines output but doesn't return any data, the same if you connect the mouse directly to the P2 (with this driver). But if you add back the mouse decoder support it will work.
The Saleae software I use on my crud-tier clone device has USB 1.1 decoding support (haven't tried if it actually works well, given the low sample rate on the device) and can record for pretty much as long as you want. I use it like this:
Relatedly, I examined your hub code and it looks decently clean enough to merge into my driver versions. Well, there's some kinda uggo code that has explicit cases for each device id that could be condensed, but oh well.
...
And then I notice that your version has got some rather significant divergence as it were. Well, time to muck about I guess.
Good news, I finally sorted out the preamble signaling thing to enable the low speed ports and managed to get a keyboard (LS) and a PS3 controller (FS) working together.
There are still a number of things to fix in the driver before being ready for general use.
Hmm, if you're gonna a bunch of changes I might just re-base my changes (really just the device to button bitfield mapping code) on your version when you're done (instead of me merging the hub support manually). Would need some re-thinking for multiple devices, anyways. You're working with pure PASM though, idk how much muckery that'd need to make work in a Spin env again.
That is very good news. So ultimately when you are done, what combinations of mice, keyboard and/or game controllers do you think should be possible with your USB device polling logic? Is it just going to be two devices only or could it more than two (ie. up to 4 HID devices of any supported type for a 4 port hub?) It would be great to have a mouse, a keyboard and two gamepads all supported from the same driver through a HUB IMO and would save COGs.
The plan is to support all combinations and even 7-ports hubs, the current limit to 4 is only because the code is a bit "patched" to support multiple devices, when properly implemented there is no reason to not support all 7 ports.
These 7-port hubs are 2 4-port hubs internally connected (and 1 of 8 ports is used for this connection)
Sounds great if you are able to get it that far.
Nice work @macca !
Will this allow two players in NeoYume?
Yes, I've read that too, and was a bit puzzled because, AFAIK, there aren't technical resons for that (maybe practical/economic...).
BTW, for those interested, I'm using this hub found on e-bay:
Also got this one because I tought it could be useful for a custom board
however I didn't noticed that the pins are not 2.54mm spaced (and don't even match the usb connectors I have...).
Even four if allowed...
Kizuna Encounter exists as the sole NeoGeo game with 4 player support (on one machine - some other games have a serial link to get 4 players by synchronizing two machines). Seems to be rather simple to add support for, but IDK if the game will read it in AES mode.
On the MegaYume side there's a handful of 4 player games, but there's like 3 different ways to read extra controllers (SEGA and EA made mutually incompatible multitap adapters. Also some games have extra ports on the cartridge itself)
Can you link two P2's running NeoYume to get 4 players in these other games?
Perhaps I should have asked in another thread...
Don't think so. There's a microcontroller in those game carts that runs the bus between them (yes, you connect together the cartridges with 3.5mm cables). Also might just not work on AES to begin with to lack of DIPs.
There are cheap 4-port USB hub chips and that is the main reason. (=economic/practical, it is easier to connect 2 (or more, 10-port hubs exist) hub chips as it is already in the USB standard and costs nothing (except one wasted port), than developing a new, more-port chip.
Yeah likely same reason for 5 port vs 8 port Ethernet switches too.