@Wuerfel_21 said:
Aaand I just noticed that it now suffers from having horrible update rate with the neo geo mini controller. I could've sworn it didn't do this yesterday, maybe I was just thick.
Be careful with any cheap cabling and other local interference sources. I used to encounter lots of USB issues with a dirt simple USB to RS232 adapter and it would occur when the USB cable was draped near other HF noise sources such as Ethernet and video cables coming from PCs that seemed to give me strange results over the serial port and other weird slowdowns etc. This was happening at the lower 1.5 / 12Mbps USB1.1 bit rates which wasn't really expected in my opinion. I'd normally have thought that should be pretty solid but it wasn't.
@Wuerfel_21 said:
Next obnoxious issue: macca converted the whole thing into a standalone ASM blob, but I want it to be a Spin object again.
Of course it stops working once I replace the ASM start stub
That's because, with the Spin interpreder, it needs the loc instruction to get the absolute position of buffers and labels when switching from cog/lut to hub addresses and at some point I got tired of always remember how to use (because the usage differs if invoked from cog/lut vs. hub code...) and stopped using it.
Anyway, I checked in some changes that should have fixed the Spin usage.
@Wuerfel_21 said:
Aaand I just noticed that it now suffers from having horrible update rate with the neo geo mini controller. I could've sworn it didn't do this yesterday, maybe I was just thick.
Be careful with any cheap cabling and other local interference sources. I used to encounter lots of USB issues with a dirt simple USB to RS232 adapter and it would occur when the USB cable was draped near other HF noise sources such as Ethernet and video cables coming from PCs that seemed to give me strange results over the serial port and other weird slowdowns etc. This was happening at the lower 1.5 / 12Mbps USB1.1 bit rates which wasn't really expected in my opinion. I'd normally have thought that should be pretty solid but it wasn't.
Oh wow. I've figured the poll rate thing to be a 100% software issue though (appears and disappears by loading different binaries FROM THE SAME SOURCE CODE AAAA)
Might get me into some issues once I build the wiretap device. Will have to try to keep the D+/D- fly wires as short as possible.
@macca said:
@Wuerfel_21 said:
Next obnoxious issue: macca converted the whole thing into a standalone ASM blob, but I want it to be a Spin object again.
Of course it stops working once I replace the ASM start stub
That's because, with the Spin interpreder, it needs the loc instruction to get the absolute position of buffers and labels when switching from cog/lut to hub addresses and at some point I got tired of always remember how to use (because the usage differs if invoked from cog/lut vs. hub code...) and stopped using it.
Anyway, I checked in some changes that should have fixed the Spin usage.
I did a comparison of the binaries produced by flexspin and my tool and are substantially the same, flexspin forces the absolute address on call and jmp even when jumping from/to cog/lut code (which AFAIK is not needed). The @ operator seems to work as expected in pasm-only mode. In Spin-mode however seems different, can't make a direct comparison, but the flexspin listing looks like this:
Doesn't look right, 21AB, 21B3 are in the middle of the hpad_xinput code.
I think there's some sort of issue with axis normalization?
An interesting thing I found with the code comparison: hpad_normalize ends with adds retval, ##$8000 signx 15, seems that flexspin produces a different value:
Some bits are already in place, so yes, I'll add conditional compile instructions, however I would like to add C-style preprocessor conditionals #ifdef/#else, etc. even in assembly sections to keep them consistent.
I did a comparison of the binaries produced by flexspin and my tool and are substantially the same, flexspin forces the absolute address on call and jmp even when jumping from/to cog/lut code (which AFAIK is not needed). The @ operator seems to work as expected in pasm-only mode. In Spin-mode however seems different, can't make a direct comparison, but the flexspin listing looks like this:
Doesn't look right, 21AB, 21B3 are in the middle of the hpad_xinput code.
I guess it's busted then? Oh noes.
Regarding the poll rate issue, I know it only affects NeoGeo mini gamepads in particular and doesn't happen when assembling with PropTool. Can you compare against Proptool?
(If you want to buy such a controller for debug purposes, don't forget to get a USB A to C socket adapter)
I think there's some sort of issue with axis normalization?
An interesting thing I found with the code comparison: hpad_normalize ends with adds retval, ##$8000 signx 15, seems that flexspin produces a different value:
Some bits are already in place, so yes, I'll add conditional compile instructions, however I would like to add C-style preprocessor conditionals #ifdef/#else, etc. even in assembly sections to keep them consistent.
Flexspin has both. And yes, they're redundant to some extent. The main difference is that CON symbols != preprocessor defines. (And I think flexspin's spin preprocessor doesn't have expression #if, only #ifdef). CON symbols are nice because they can be overridden using the new OBJ syntax.
@Wuerfel_21 said:
Regarding the poll rate issue, I know it only affects NeoGeo mini gamepads in particular and doesn't happen when assembling with PropTool. Can you compare against Proptool?
My tool produces the exact same binary as Proptool, so the differences are the same as described above.
SIGNX was broken on 64 bit builds of flexspin (was doing 64 bit arithmetic ). That should be fixed now. I've also changed the jmp instruction calculation so that branches from COG to LUT can be relative, as in PNut.
@Wuerfel_21 : The part of the documentation about @ operators in Spin2 DAT sections is out of date . At some point I had to change it to match the official compiler, probably because some code relied on the official behavior. To get the absolute address you have to use @@@.
Okay, back home, work will start back up tomorrow, hopefully full-force.
Meanwhile, I found a controller that violates the "Button 10 = Start" convention and it also happens to be adorably ugly (main reason I bought one lol):
This one doesn't declare any extraneous buttons that don't physically exist, so the two middle buttons end up on slots 7 and 8.
Yea, my appreciation of beige electronics is only half-ironic.
You know, I was about to say that I wouldn't put much faith into the direction pad (the diagonals are awful and need a very specific amount of force to register), like, it just doesn't feel good, but then I immediately no-continue cleared Mountain of Faith on it (which I've been trying to for a while...), so maybe it is blessed and you should infact put all your faith into it immediately.
It still felt awful all the way through though. Shoulder buttons are nice and clicky though.
Also, for I haven't mentioned it, it does work no problem with the P2 USB driver, which I will now get to I guess.
New features:
- Supports two-player gameplay using a USB hub!
- Should support any HID standard game controller now instead of a limited selection only.
Limitations:
- Game controllers need to plugged into port 1 and 2 of the USB hub to control the respective player. (Most hubs don't have their ports labeled! Trial and error is required!)
- A keyboard is always Player 1 (but does not conflict with a gamepad on port 1, either can be used, inputs are logically OR-ed)
- Button mapping is currently hardcoded and the same for all devices. I have set it to fit the NeoGeo mini USB controller. Any other controller might have bonkered mappings for the ABCD buttons.
- I fumbled the keyboard map and you need to press backspace to start...
Further update:
- Slight bugfixes (including the gank keyboard map)
- Hub port to players mapping is now slightly smarter. The order of players still depends on the order of the USB ports, but empty ports / other devices now don't take up a player slot. So you could, for example have Port 1 empty, Ports 2 and 4 as gamepads and Port 3 as a keyboard and have it work (keyboard is still always player 1, as described above)
Update: I have added proper button mapping support. All the previously supported gamepads have built-in support, others can be configured using a PADMAP.TXT file on your SD card, as described in the other thread. (You can also over-ride the built-in maps if you really want). Though many gamepads should just have an ok layout out of the box.
@Wuerfel_21,
Just tried your new NeoYume USB test branch latest top of tree from today - built with flexspin 6.1.1. Was unable to get any of my devices recognised even though they worked with your USB driver in the other thread. This version of NeoYume hangs on its own menu screen and doesn't let me start the MS game from its presented menu item even though it is not dimmed out and should allow startup. The "D" credits key doesn't work either. Pressed the different keyboard keys, USB gamepad buttons, no response. Tried with and without a hub, no apparent difference.
Here's my config.spin2 diff from your defaults. I fitted my own PSRAM board on P0-P15 plus P20,P21 is the CE and P22+P23 is the CLK. VGA/AV breakout is on P32, and the USB breakout on P48.
Not sure what's wrong, or how to fix this. Am noticing that no LEDs on the USB board are turned on if that gives a hint...? 5V ACC jumper is fitted. I also tried in it P24-P31 as well just in case my EVAL board had somehow gone bad at pin 48 or the driver had some port A/B dependence.
Aha yeah that helps Ada...am getting further now. Hangs now after game load and NeoGeo display+startup sound, after this is no gfx (blank screen). Probably could be PSRAM timing...
Yeah I think my board should work, but it's been a while left in a drawer. I might have used the P2-Edge last time I messed with this stuff. I just tried delays from 13-19. The default delay (14) does play the startup music and the animation then hangs before the game starts. Other delays stop the startup completely so I think the timing is actually good. Maybe you changed the ROM format or something since I used it last or require other utilities to process the files?
@Wuerfel_21 said:
(If in further doubt, try with the known-good master branch version)
Yeah I may need to back track to an older version from my other machine...could try that later tonight hopefully.
EDIT: plugged in another PSRAM PCB of mine and ran it instead, and it's now working, plus I have your two player controller stuff operating too via the USB hub.
@rogloh said:
EDIT: plugged in another PSRAM PCB of mine and ran it instead, and it's now working, plus I have your two player controller stuff operating too via the USB hub.
??? Does your PSRAM have a stuck bit or something?
Also, the next MegaYume version will pass through controller connection status. This isn't very useful, but some games gray out the multiplayer option when a second controller isn't connected and it's cool to watch it update that when you plug/unplug the USB controllers.
Ok, got multitap support working. Obnoxiously, not all games properly declare multitap support, so we need some special casing, ugh. Currently only tested Gauntlet 4 (needs special case, I detect by ROM serial GM T-48216 -00) and the SEGA I/O test program (correct declaration).
This is now live on github, etc, etc. Do note that the USB driver still only supports 4 devices full-stop (not sure what even happens with a larger hub?), so no keyboard can be attached while doing 4-player. (3 players + keyboard works though)
Gauntlet 4: works, as seen above (needs special case)
Yuu Yuu Hakusho: Makyou Toitsusen: Actually just works
Mega Bomberman: Also works.
NBA Jam: Actually just crashes (regardless of multitap)
Micro Machines 2 / Micro Machines 96: Needs extra stupid Smile hack (breaks on 6 button controllers. WHAT? HOW? WHY?)
The Lost Vikings: works, needs special case
Xeno Crisis: Advertises multitap support, doesn't actually support it (fixed by special case)
Columns 3: Needs multitap on port 2, too lazy
99% of the multitap games are Sportsball (evene excluding the EA-specific ones, which won't work because I only emulate the SEGA multitap), not sure if I have the energy to try them all. Seems thankless.
Comments
Be careful with any cheap cabling and other local interference sources. I used to encounter lots of USB issues with a dirt simple USB to RS232 adapter and it would occur when the USB cable was draped near other HF noise sources such as Ethernet and video cables coming from PCs that seemed to give me strange results over the serial port and other weird slowdowns etc. This was happening at the lower 1.5 / 12Mbps USB1.1 bit rates which wasn't really expected in my opinion. I'd normally have thought that should be pretty solid but it wasn't.
That's because, with the Spin interpreder, it needs the loc instruction to get the absolute position of buffers and labels when switching from cog/lut to hub addresses and at some point I got tired of always remember how to use (because the usage differs if invoked from cog/lut vs. hub code...) and stopped using it.
Anyway, I checked in some changes that should have fixed the Spin usage.
Oh wow. I've figured the poll rate thing to be a 100% software issue though (appears and disappears by loading different binaries FROM THE SAME SOURCE CODE AAAA)
Might get me into some issues once I build the wiretap device. Will have to try to keep the D+/D- fly wires as short as possible.
In flexspin, that shouldn't have been an issue, since in Spin2 mode it should always produce absolute addresses in DAT data. Maybe that broke at some point and no one noticed?
Eitherhow, while I have you, care to add the conditional assembly extension to your tool? I think it's very useful.
I did a comparison of the binaries produced by flexspin and my tool and are substantially the same, flexspin forces the absolute address on call and jmp even when jumping from/to cog/lut code (which AFAIK is not needed). The @ operator seems to work as expected in pasm-only mode. In Spin-mode however seems different, can't make a direct comparison, but the flexspin listing looks like this:
Doesn't look right, 21AB, 21B3 are in the middle of the hpad_xinput code.
An interesting thing I found with the code comparison: hpad_normalize ends with
adds retval, ##$8000 signx 15, seems that flexspin produces a different value:Looks like signx doesn't work (or I'm missing something ?).
This with Version 6.1.1-beta-v6.1.0-4-gbeed4ecb.
Some bits are already in place, so yes, I'll add conditional compile instructions, however I would like to add C-style preprocessor conditionals #ifdef/#else, etc. even in assembly sections to keep them consistent.
Responding on phone, excuse brevity.
I guess it's busted then? Oh noes.
Regarding the poll rate issue, I know it only affects NeoGeo mini gamepads in particular and doesn't happen when assembling with PropTool. Can you compare against Proptool?
(If you want to buy such a controller for debug purposes, don't forget to get a USB A to C socket adapter)
Oh, that seems busted as well. @ermsith
Flexspin has both. And yes, they're redundant to some extent. The main difference is that CON symbols != preprocessor defines. (And I think flexspin's spin preprocessor doesn't have expression #if, only #ifdef). CON symbols are nice because they can be overridden using the new OBJ syntax.
My tool produces the exact same binary as Proptool, so the differences are the same as described above.
SIGNX was broken on 64 bit builds of flexspin (was doing 64 bit arithmetic
). That should be fixed now. I've also changed the jmp instruction calculation so that branches from COG to LUT can be relative, as in PNut.
@Wuerfel_21 : The part of the documentation about
. At some point I had to change it to match the official compiler, probably because some code relied on the official behavior. To get the absolute address you have to use
@operators in Spin2 DAT sections is out of date@@@.All that is broken will be mended...
Okay, back home, work will start back up tomorrow, hopefully full-force.
Meanwhile, I found a controller that violates the "Button 10 = Start" convention and it also happens to be adorably ugly (main reason I bought one lol):
This one doesn't declare any extraneous buttons that don't physically exist, so the two middle buttons end up on slots 7 and 8.
LOL. The colour itself is so 90's retro.
I'd take beige over black any day. And don't get me started on LED bling!
Yea, my appreciation of beige electronics is only half-ironic.
You know, I was about to say that I wouldn't put much faith into the direction pad (the diagonals are awful and need a very specific amount of force to register), like, it just doesn't feel good, but then I immediately no-continue cleared Mountain of Faith on it (which I've been trying to for a while...), so maybe it is blessed and you should infact put all your faith into it immediately.
It still felt awful all the way through though. Shoulder buttons are nice and clicky though.
Also, for I haven't mentioned it, it does work no problem with the P2 USB driver, which I will now get to I guess.
Further discussion of the USB topic should be here: https://forums.parallax.com/discussion/175311/usb-driver-re-development-thread
Also, if you really want to know how it feels to chew 5GUM, here's a replay of Stage 6 of the MoF playthrough mentioned above...
You may now find an preview version of NeoYume with improved USB support in the
usbnewbranch on GitHub: https://github.com/IRQsome/NeoYume/tree/usbnewNew features:
- Supports two-player gameplay using a USB hub!
- Should support any HID standard game controller now instead of a limited selection only.
Limitations:
- Game controllers need to plugged into port 1 and 2 of the USB hub to control the respective player. (Most hubs don't have their ports labeled! Trial and error is required!)
- A keyboard is always Player 1 (but does not conflict with a gamepad on port 1, either can be used, inputs are logically OR-ed)
- Button mapping is currently hardcoded and the same for all devices. I have set it to fit the NeoGeo mini USB controller. Any other controller might have bonkered mappings for the ABCD buttons.
- I fumbled the keyboard map and you need to press backspace to start...
Further update:
- Slight bugfixes (including the gank keyboard map)
- Hub port to players mapping is now slightly smarter. The order of players still depends on the order of the USB ports, but empty ports / other devices now don't take up a player slot. So you could, for example have Port 1 empty, Ports 2 and 4 as gamepads and Port 3 as a keyboard and have it work (keyboard is still always player 1, as described above)
Update: I have added proper button mapping support. All the previously supported gamepads have built-in support, others can be configured using a PADMAP.TXT file on your SD card, as described in the other thread. (You can also over-ride the built-in maps if you really want). Though many gamepads should just have an ok layout out of the box.
Please test a bit if you can: https://github.com/IRQsome/NeoYume/tree/usbnew
@Wuerfel_21,
Just tried your new NeoYume USB test branch latest top of tree from today - built with flexspin 6.1.1. Was unable to get any of my devices recognised even though they worked with your USB driver in the other thread. This version of NeoYume hangs on its own menu screen and doesn't let me start the MS game from its presented menu item even though it is not dimmed out and should allow startup. The "D" credits key doesn't work either. Pressed the different keyboard keys, USB gamepad buttons, no response. Tried with and without a hub, no apparent difference.
Here's my config.spin2 diff from your defaults. I fitted my own PSRAM board on P0-P15 plus P20,P21 is the CE and P22+P23 is the CLK. VGA/AV breakout is on P32, and the USB breakout on P48.
Not sure what's wrong, or how to fix this. Am noticing that no LEDs on the USB board are turned on if that gives a hint...? 5V ACC jumper is fitted. I also tried in it P24-P31 as well just in case my EVAL board had somehow gone bad at pin 48 or the driver had some port A/B dependence.
I may have forgotten to properly hook up the USB pin config. Try changing it at the top of usbnew.spin2
Aha yeah that helps Ada...am getting further now. Hangs now after game load and NeoGeo display+startup sound, after this is no gfx (blank screen). Probably could be PSRAM timing...
You had this board working before? If not, do infact tweak the timing values, you should know how that works
Yeah I think my board should work, but it's been a while left in a drawer. I might have used the P2-Edge last time I messed with this stuff. I just tried delays from 13-19. The default delay (14) does play the startup music and the animation then hangs before the game starts. Other delays stop the startup completely so I think the timing is actually good. Maybe you changed the ROM format or something since I used it last or require other utilities to process the files?
No, I haven't really changed anything related to the memory if or the emulation core in a long while...
Though if it consistently crashes after the startup, you may have a corrupted P1 ROM or something
(If in further doubt, try with the known-good master branch version)
Yeah I may need to back track to an older version from my other machine...could try that later tonight hopefully.
EDIT: plugged in another PSRAM PCB of mine and ran it instead, and it's now working, plus I have your two player controller stuff operating too via the USB hub.
??? Does your PSRAM have a stuck bit or something?
I've put the new driver to work in MegaYume now, too, available on its very own
usbnewbranch: https://github.com/IRQsome/MegaYume/tree/usbnewHas all the same features and limitations. Oh, and I've fixed the basepin issue in both. (Note that the other USB config vars DO NOTHING RIGHT NOW)
Next, I want to implement multitap support into MegaYume's emulation core. 4-player Gauntlet, anyone?
Also, the next MegaYume version will pass through controller connection status. This isn't very useful, but some games gray out the multiplayer option when a second controller isn't connected and it's cool to watch it update that when you plug/unplug the USB controllers.
Ok, got multitap support working. Obnoxiously, not all games properly declare multitap support, so we need some special casing, ugh. Currently only tested Gauntlet 4 (needs special case, I detect by ROM serial
GM T-48216 -00) and the SEGA I/O test program (correct declaration).This is now live on github, etc, etc. Do note that the USB driver still only supports 4 devices full-stop (not sure what even happens with a larger hub?), so no keyboard can be attached while doing 4-player. (3 players + keyboard works though)
Shitpost status:
99% of the multitap games are Sportsball (evene excluding the EA-specific ones, which won't work because I only emulate the SEGA multitap), not sure if I have the energy to try them all. Seems thankless.