@Wuerfel_21 said:
??? Does your PSRAM have a stuck bit or something?
Possibly, though it used to work AFAIK. I think it was more likely just a poor connection. The "bad" module had some different logic analyser extension pins which can get a bit loose when plugged in. The better one I used was fully soldered.
Next, I want to implement multitap support into MegaYume's emulation core. 4-player Gauntlet, anyone?
Next, I want to implement multitap support into MegaYume's emulation core. 4-player Gauntlet, anyone?
4 player would be pretty cool.
As previously exposited, it pretty much works now, just need to actually have 4 controllers on a hub (ideally wired, wireless receivers can cause overcurrent)
@Wuerfel_21 said:
As previously exposited, it pretty much works now, just need to actually have 4 controllers on a hub (ideally wired, wireless receivers can cause overcurrent)
Yeah I think I was hitting overcurrent situations running NeoYume when powering multiple devices from the P2-EVAL itself supplied via a powered HUB port (although I was using the PC connection on P2-EVAL, not that extra 2A AUX). The software would not start up occasionally. It would if I removed the USB hub and then add in back later.
This is one issue people will likely start to see when running self-powered USB hubs off the P2-EVAL pins as all these extra peripherals will need more current.
For me having the AUX power connected is a must. I just get random crashes when it isn't. Though maybe your powered Hub supplies higher current than a normal PC port.
The hub I'm using for testing is actually a powered hub, but I misplaced the wall adapter, so it runs in bus-powered mode.
This is so the default rule 1 2 3 4 5 6 7 8 9 10 works out to something semi-sensible for controllers that follow the sorta-standard layout (including XInput/PS3 which bypass HID parsing and are hardcoded to this layout). Infact, let me visualize using this funny controller that not only fully complies with the sorta-standard, but also has the button numbers labeled:
The existence of the "also C/ also D" in NeoYume is mostly to allow for a more comfortable mapping for 6-button pads, but also can help out with a 4-button, since some games assume you can press any combination of buttons easily, as with arcade buttons (for example, upwards attack in The Last Blade is B+C). The bottom shoulders are used because they're less likely to get in the way (and also happen to be where the C/Z buttons of a retro-bit 6 button are to begin with, not that it really matters)
Also, yes, this default layout for MegaYume seems and is really uncomfortable (for games that need quick access to at least ABC), but there really isn't a better way. The MegaDrive emulator on Nintendo Switch Online forces this exact layout. GenesisPlusGX also defaults to this (when using a classic controller (=snes-like)).
Just writing this down here now because I'm too lazy to overhaul the actual READMEs yet (will do when USB driver is finalized)
@Wuerfel_21 said:
@pik33 while I got you here, can you try the new USB stuff with the RPi keyboard with built-in hub you mentioned earlier?
RPi keyboard works (hidpad to vga.spin2).
Strange: keyboard report when not active is 44 44 44 44 44 44 44 44 - why? (expected 00...)
Several keys gives wrong scancodes. F1 is 7E, F2 is 7F, but f3..f6 is always 7
A cheap hipermarket wireless game pad I have, connected to the keyboard's USB, doesn't work. HIDPAD3 fields blinked white sevewral times, then went gray
The same pad connected directly to the USB port: HIDPAD 0: ID 44BD5C5 -- 15 buttons, 4 axes, 1 hats
Buttons: 000000000000010
X: -32768 Y: 32510, Z: -7325
RX: N/A, RY: N/A RZ: -30455
Hats: 44
and that's all. No reaction on movements and buttons.
After disconnecting the pad and reconnecting the keyboard, keyboard doesn't work. Activity LED blinks.
Compiled by Version 6.1.2-beta-v6.1.0-32-gf36685e8 Compiled on: May 3 2023
OK. This helped the keyboard, now giving correct reports. The gamepad works like before, doesn't connect via the keyboard, connecting (white text) when connected directly to the P2 but no response to any activity and after disconnecting it and connecting the keyboard, the keyboard doesn't work. The first conclusion: incompatible gamepad.
That sounds like it's crashing the USB driver... Oh no. Even my "incompatible" offender (8bitdo SN30 pro USB) doesn't do that :P
Can you compile with -gbrk debug enabled, load with device already attached (to root port) and paste me the log? (The beginning bits are the most salient, so stop if it starts spewing garbage)
The pad still doesn't work, but now the keyboard worked after I disconnected the pad. Let's try again...
Edit: This time there is "a" reaction. The pad has the button called "analog". When pressing it, nothing happens, but releasing the button causes Y and Z on the screen change for a moment (a short blink, then return to previous values)
And the pad has the ID 0079181C and Hats: 00. The rest of values didn't change.
Edit 2: I now have to try and connect the keyboard with pad connected when starting the test program
Hmm, no idea why it doesn't work on hub, but there's some odd stuff here:
The pad has two (?) HID interfaces. For some reason it chooses the second(?). Also there's some funky stuff in the HID descriptor, maybe that's not handled quite right (EDIT: no, should be robust to that).
@Wuerfel_21 said:
Hmm, no idea why it doesn't work on hub, but there's some odd stuff here:
The pad has two (?) HID interfaces. For some reason it chooses the second(?). Also there's some funky stuff in the HID descriptor, maybe that's not handled quite right (EDIT: no, should be robust to that).
It picks the second because hparse_con_desc doesn't check if a gamepad interface is already set so it picks the last.
I don't quite understand the logs attached in post #1336, seems the gamepad and hub have the same PID/VID $05E3_0610 (maybe a debug log issue) ?
Is that the same gamepad ? Because that looks to have a single interface and should work, also the keyboard there, from the last lines, looks working.
@macca said:
I don't quite understand the logs attached in post #1336, seems the gamepad and hub have the same PID/VID $05E3_0610 (maybe a debug log issue) ?
Is that the same gamepad ? Because that looks to have a single interface and should work, also the keyboard there, from the last lines, looks working.
Warning, I changed the way hdev_id works, it's now an array per-port. This is so you get the current HID device id from the spin interface (which really just dumps the ID and some of the hidr_* registers to RAM for you to read). Also note that the versions checked into the emulator repos don't have this change yet
Yes, had the suspect of such a change (because of the # prefix...) but still wasn't finding the right PID/VID (and the newline break wasn't helping...).
Still the gamepad PID/VID on port 4 looks different 0079_0126 vs. 0079_181C (in post #1334).
That's right, how strange. It seems the keyboard is 04D9_0006 (Holtek RPi Keyboard), the hub is 05E3_0610 (Genesys Logic USB 2.0 Hub) and the gamepad ID is weird and changes. VID 0079 is DragonRise, which yea they make chipsets for cheap USB input. With the reconnects, maybe it's trying to do the weird "reconnect as different device until the host likes me" thing that the SN30 pro tries to do (and fails at).
I tried giving NeoYume support for the special 4 player mode in Kizuna Encounter. I think I got it going once by playing around with UniBios cheats, but I never got it to properly detect the 4 player mode. Decided to give up. It's pretty lame, anyways. Also a > 32MB game.
@Rayman said:
Gaunlet? That’s one of my favorites!
Is that Mega or Neo Yume!
It's Gauntlet 4 for MegaDrive. I've fixed some crashing issues with this game a while ago, but now it works in multiplayer. Just need MegaYume from the aforementioned special branch, a USB hub and up to four controllers.
I was blown away by the game Dandy (Gauntlet's precursor) on an Atari back in the 1980's. I liked it more than Gauntlet simply because, being a computer game rather than arcade, Dandy had no time limits.
I've updated the USB drivers again. There shouldn't really be any functional change, except maybe increased stability. You can also toggle capslock now for no reason whatsoever.
Just edited the first post of this thread to link to the GitHub repos.
Also, I updated both emulators to support 7-port USB hubs today (still on usbnew branch). Not terribly interesting, but I guess you can now leave a keyboard connected when doing 4-player in MegaYume.
Comments
Possibly, though it used to work AFAIK. I think it was more likely just a poor connection. The "bad" module had some different logic analyser extension pins which can get a bit loose when plugged in. The better one I used was fully soldered.
4 player would be pretty cool.
As previously exposited, it pretty much works now, just need to actually have 4 controllers on a hub (ideally wired, wireless receivers can cause overcurrent)
Yeah I think I was hitting overcurrent situations running NeoYume when powering multiple devices from the P2-EVAL itself supplied via a powered HUB port (although I was using the PC connection on P2-EVAL, not that extra 2A AUX). The software would not start up occasionally. It would if I removed the USB hub and then add in back later.
This is one issue people will likely start to see when running self-powered USB hubs off the P2-EVAL pins as all these extra peripherals will need more current.
For me having the AUX power connected is a must. I just get random crashes when it isn't. Though maybe your powered Hub supplies higher current than a normal PC port.
The hub I'm using for testing is actually a powered hub, but I misplaced the wall adapter, so it runs in bus-powered mode.
Yes, Eval powered with only PC is not stable at any decent clock speed.
@pik33 while I got you here, can you try the new USB stuff with the RPi keyboard with built-in hub you mentioned earlier?
Yes, I can. I wanted to do it much earlier but still no time to switch the P2 on
Renovation at home.
Also, because it may be a bit confusing, the correct PADMAP.TXT format for MegaYume would be:
For NeoYume:
This is so the default rule
1 2 3 4 5 6 7 8 9 10works out to something semi-sensible for controllers that follow the sorta-standard layout (including XInput/PS3 which bypass HID parsing and are hardcoded to this layout). Infact, let me visualize using this funny controller that not only fully complies with the sorta-standard, but also has the button numbers labeled:The existence of the "also C/ also D" in NeoYume is mostly to allow for a more comfortable mapping for 6-button pads, but also can help out with a 4-button, since some games assume you can press any combination of buttons easily, as with arcade buttons (for example, upwards attack in The Last Blade is B+C). The bottom shoulders are used because they're less likely to get in the way (and also happen to be where the C/Z buttons of a retro-bit 6 button are to begin with, not that it really matters)
Also, yes, this default layout for MegaYume seems and is really uncomfortable (for games that need quick access to at least ABC), but there really isn't a better way. The MegaDrive emulator on Nintendo Switch Online forces this exact layout. GenesisPlusGX also defaults to this (when using a classic controller (=snes-like)).
Just writing this down here now because I'm too lazy to overhaul the actual READMEs yet (will do when USB driver is finalized)
RPi keyboard works (hidpad to vga.spin2).
Strange: keyboard report when not active is 44 44 44 44 44 44 44 44 - why? (expected 00...)
Several keys gives wrong scancodes. F1 is 7E, F2 is 7F, but f3..f6 is always 7
A cheap hipermarket wireless game pad I have, connected to the keyboard's USB, doesn't work. HIDPAD3 fields blinked white sevewral times, then went gray
The same pad connected directly to the USB port: HIDPAD 0: ID 44BD5C5 -- 15 buttons, 4 axes, 1 hats
Buttons: 000000000000010
X: -32768 Y: 32510, Z: -7325
RX: N/A, RY: N/A RZ: -30455
Hats: 44
and that's all. No reaction on movements and buttons.
After disconnecting the pad and reconnecting the keyboard, keyboard doesn't work. Activity LED blinks.
Compiled by Version 6.1.2-beta-v6.1.0-32-gf36685e8 Compiled on: May 3 2023
Used P2-EC32 with USB at pin 0
USB_BASE_PIN = 0 ACTIVITY_LED = 38 ERROR_LED = 39and VGA at pin 8
Disable listing(-l flag) when compiling, currently explodes (into 44 44 44) when that's enabled for some reason.
OK. This helped the keyboard, now giving correct reports. The gamepad works like before, doesn't connect via the keyboard, connecting (white text) when connected directly to the P2 but no response to any activity and after disconnecting it and connecting the keyboard, the keyboard doesn't work. The first conclusion: incompatible gamepad.
That sounds like it's crashing the USB driver... Oh no. Even my "incompatible" offender (8bitdo SN30 pro USB) doesn't do that :P
Can you compile with -gbrk debug enabled, load with device already attached (to root port) and paste me the log? (The beginning bits are the most salient, so stop if it starts spewing garbage)
The pad still doesn't work, but now the keyboard worked after I disconnected the pad. Let's try again...
Edit: This time there is "a" reaction. The pad has the button called "analog". When pressing it, nothing happens, but releasing the button causes Y and Z on the screen change for a moment (a short blink, then return to previous values)
And the pad has the ID 0079181C and Hats: 00. The rest of values didn't change.
Edit 2: I now have to try and connect the keyboard with pad connected when starting the test program
The keyboard and pad.
Hmm, no idea why it doesn't work on hub, but there's some odd stuff here:
The pad has two (?) HID interfaces. For some reason it chooses the second(?). Also there's some funky stuff in the HID descriptor, maybe that's not handled quite right (EDIT: no, should be robust to that).
What is the best for me is a working RPi keyboard. Now, a mouse...
It picks the second because hparse_con_desc doesn't check if a gamepad interface is already set so it picks the last.
I don't quite understand the logs attached in post #1336, seems the gamepad and hub have the same PID/VID $05E3_0610 (maybe a debug log issue) ?
Is that the same gamepad ? Because that looks to have a single interface and should work, also the keyboard there, from the last lines, looks working.
Warning, I changed the way hdev_id works, it's now an array per-port. This is so you get the current HID device id from the spin interface (which really just dumps the ID and some of the hidr_* registers to RAM for you to read). Also note that the versions checked into the emulator repos don't have this change yet
Yes, had the suspect of such a change (because of the # prefix...) but still wasn't finding the right PID/VID (and the newline break wasn't helping...).
Still the gamepad PID/VID on port 4 looks different 0079_0126 vs. 0079_181C (in post #1334).
That's right, how strange. It seems the keyboard is 04D9_0006 (Holtek RPi Keyboard), the hub is 05E3_0610 (Genesys Logic USB 2.0 Hub) and the gamepad ID is weird and changes. VID 0079 is DragonRise, which yea they make chipsets for cheap USB input. With the reconnects, maybe it's trying to do the weird "reconnect as different device until the host likes me" thing that the SN30 pro tries to do (and fails at).
That was the same gamepad/ Vakoss EH01400Q, wireless gamepad model no GP-3925BK.
I tried giving NeoYume support for the special 4 player mode in Kizuna Encounter. I think I got it going once by playing around with UniBios cheats, but I never got it to properly detect the 4 player mode. Decided to give up. It's pretty lame, anyways. Also a > 32MB game.
Gaunlet? That’s one of my favorites!
Is that Mega or Neo Yume!
It's Gauntlet 4 for MegaDrive. I've fixed some crashing issues with this game a while ago, but now it works in multiplayer. Just need MegaYume from the aforementioned special branch, a USB hub and up to four controllers.
(Also, it's now broken with latest git flexspin, take care)
EDIT: Silly workaround deployed, all is safe again.
I was blown away by the game Dandy (Gauntlet's precursor) on an Atari back in the 1980's. I liked it more than Gauntlet simply because, being a computer game rather than arcade, Dandy had no time limits.
I've updated the USB drivers again. There shouldn't really be any functional change, except maybe increased stability. You can also toggle capslock now for no reason whatsoever.
Just edited the first post of this thread to link to the GitHub repos.
Also, I updated both emulators to support 7-port USB hubs today (still on usbnew branch). Not terribly interesting, but I guess you can now leave a keyboard connected when doing 4-player in MegaYume.
Here's something fun I found:
Someone made a Mega Drive port of the original Cave Story: https://github.com/andwn/cave-story-md
Of course it runs on MegaYume:
Pretty good for a freeware ROM.