@Rayman said:
Also, can verify that XBox 360 controller (by Voyee) works.
However, the green xbox button in center keeps flashing green.
I think that means it isn't configured exactly right, not assigned a player #, but works anyway.
Try changing the last byte of xinp_led_cmd byte $01, $03, $02 (as per the legend). 02 works for my nonsense, but maybe 06 is better.
@macca said:
Well... I got basic hub support working... only for full speed devices though, so it is actually useful for multiple gamepads only (no keyboards, no mouse) with the hope that none of them is low speed only.
Before getting too excited, I still need to properly support multiple hid devices, so this will require a bit more time.
So I just checked both of my USB gamepad devices and they are low speed Maybe one day...
Just figured out why the sound in Pulstar and Blazing Star doesn't work by way of spontaneous thought. It seems to be the same basic issue as the Data East games had - Z80 NMIs come in too close together due to the asynchronous nature of the 68000 emulation. That issue was fixed by adding a WAITX into the NOP implementation so that the wait loops run slow enough to give the Z80 enough time to handle the NMIs.
I can get the sound going by adding a waitx #100 into the DBcc implementation, but that's obviously stupid. Will have to check what the wait code in those games actually looks like, but I assume/hope its just a DBcc branching to itself.
Yep, that was it, DBF branching to itself. Maybe should have played around with the delay value, but 100 cycles seems to be ok. Anyways, since it's been a month since V1.0-RC1, this fix is also now the final V1.0 release for NeoYume. (Since I hope 1.1 will be USB hub support)
Just pushed final v1.0 for MegaYume as well. No change since RC2, just for consistency.
Since MegaYume doesn't principally rely on copyrighted system files (as NeoYume does) and MD is a decently popular system with hobby developers, I've added links to some freeware ROMs into the README, as reproduced below. I think Ken asked about something like this at some point.
Just fixed some issue wherein some files wouldn't load in MegaYume. Some sort of issue with alloca-ing the exmem driver parameters. This issue happened in NeoYume a long time ago, but I never backported the fix. Oh well.
@Rayman said:
Found an article about making games for MegaDrive.
Claims it is the easiest retro console to make games for:
Indeed:
- reasonably fast 68000 CPU, well-supported by GCC -> no/little ASM required
- non-insane memory map / no bankswitching
- simple graphics system (very few "mode" choices, VRAM accessible during active display, entire VRAM usable for tiles or sprites, sane graphics format)
- relatively few quirks to be aware of
- no special security/bankswitch/whatever ICs required to build a cartridge.
@Rayman said:
Does one need to edit MegaYume to try a homemade game?
No, just loads them right up. I've actually used the SGDK code examples for debugging a lot. (I've also recently fixed the I/O code such that SGDK's controller detection works properly).
EDIT: Also, perhaps important to note, MegaYume is a high-level emulator. Do not use it for game testing/debugging, it will give you strange results.
(For NeoYume, you would need to edit the gamedb file, since the memory maps are different for each game lmao)
Everything marked 8MB or 4MB should work, which is numerically a decent chunk, but excludes many of the really good ones. You really want more space (and arguably also more bandwidth) here. 48MB as 3 banks x 8 bit bus is probably the most bang-for-buck PSRAM config for NeoYume in particular. But that's 6 ICs and 12 pins, oh well.
Turns out at some point @ersmith fixed the libc readdir function to return file type (directory vs data). MegaYume previously used a workaround that involved building paths and calling stat on every file. Turns out that changing it to using the readdir result shortens the directory scan for a reasonably large directory from a few seconds to basically instant.
Since it turns out the PSRAM readback stuff in MegaYume (used for header inspection, i.e. region detect, SRAM save setup, 6 button issue mitigation) was broken again, I have decided to just get rid of it, so the upper code now only ever writes to PSRAM, never read anymore. Instead the header data is just buffered into VAR space, which is arguably more straightforward to begin with.
Work is currently in dev branch due to a prior cleanup change that requires bleeding-edge compiler builds. I've also pushed a bandaid fix to the master branch that hopefully also works.
Just noticed that the USB gamepad driver has some issues with device initialization that I've somehow not noticed before... Specifically, sometimes hotplugging makes the entire thing die and other times, XInput devices only work after being hotplugged. The behaviors seem to also differ by which application the driver is being used in. Very cool and not at all obnoxious.
Maybe it'll magically go away once I finally adopt the hub-support version.
Yeah I found that the USB joystick I built up for this would not always initialize properly first go after an initial startup, it was usually okay the second time though. Put it down to cheap HW at the time but it might well have been the SW by the looks of what you found Wuerfel_21.
I've mostly used the PS/2 keyboard adapter and the retro-bit and neogeo mini controllers, which are rock solid and always work from cold boot (and as mentioned, the hotplug issue is intermittent), so I guess that's why I never really noticed that XInput is sometimes busted (both with the StrikeFX and the Retro Receiver).
I'm going to have (an incredibly stupid) motivation to adapt @macca 's new hub-capable driver (along with multitap support in MegaYume so you can play Gauntlet, etc with 4 players) next month. Since that'll require some considerable rework, I hope that whatever the issue is just disappears (Also want to make the controller mappings table-based instead of hardcoded so it's not as obnoxious to add new ones and re-use the driver between projects).
Also might look into poll rates while doing that. I think(tm) that the current driver uses the usual 100Hz rate, which means that the control data varies between being freshly polled to being 10ms out-of-date when the actual game code reads it (at it's 60-ish Hz rate). It should be easily possible to increase it to 250 Hz, which would reduce the maximum age to 4ms. That should move everything slightly closer to the ideal of perfect responsiveness (remember, on the output side our latency is somewhere around ~200 µs, while PC based emulators are conceptually limited to no better than 16ms (run-ahead tricks notwithstanding...) )
Oh yea, and in other news, I've been adding the last couple forgotten games to NeoYume's game list. As previously exposited, each game has a semi-unique ROM layout, so they need to be individually configured to work. I guess this has the upside that it produces a full compatibility list along the way.
So there's some 20-ish new ones as of now, bringing the total to 128. Mostly boring ones (simulated horse racing, anyone? Weird mahjong variants? Unlocalized KOF-themed trivia quiz game? ... no?), but some good ones are in there, too.
Currently on the dev branch only because of the 3 games that are larger than 32 MB that I still need to test (too lazy to swap over to the EVAL board with 96MB)
Update: I have now (read: yesterday but forgot to post) added all NeoGeo games I am aware of, with the exceptions of ones that need some sort of currently unemulated hardware (Garou MOTW, KoF 2003, some other obscure ones), to NeoYume's gamedb. This all on master branch, too, with some other improvements.
Working
132
Major Issue
12
Broken
4
Total
148
Note that "Working" doesn't necessarily mean "Perfect", but good enough to where it can be played normally.
Also perhaps interesting, breakdown of required RAM Sizes (along with a favorable pick as an example from each category) :
RAM Size required
Game count
Example
4 MB
4
Puzzled
8 MB
41
Crossed Swords
16 MB
30
Sonic Wings 2 / Aero Fighters 2
24 MB
24
Twinkle Star Sprites
32 MB
9
Metal Slug
48 MB
17
Waku Waku 7
64 MB
6
The Last Blade
80 MB
4
Real Bout Fatal Fury 2
96 MB
13
Metal Slug 5
It turns out that 16 MB already gets you half the games by quantity. On the contrary, 32 MB Edge only actually misses out on 40 titles (though that's a lot of the best ones).
@Rayman said:
Be nice if there were some key combo or switch or something that could bring you out of a game and back to this main menu...
MegaYume can quit to it's own menu (Ctrl+Esc on Keyboard or holding Start+Down for 5 seconds on the controller) and this is all easily controlled from the high-level code, you can change it to reset the P2 instead (launching another binary is sadly not a thing flexspin VFS can really do). NeoYume is more prickly because the menu code and associated C runtime is kicked out of memory as soon as the game launches. If I refactor the Z80 to use the memory arbiter for high ROM (which would also fix Metal Slug 3's audio) I might(?) be able to cut free some 64k. If I could then reduce the menu code to that size (help @ersmith the nu backend is still busted), I could have menu quit in there, too.
Could there be (or is there already) a graphical front end menu that could launch any of the MegaYume and/or NeoYume games?
@pik33 has a menu that can launch P2 applications (and he just built individual emulator binaries hardcoded to launch a respective game). Making one that can launch emulated games "properly" should be easy, but there's two tricky parts: The first being to launch the emulator with some sort of parameter passed. I guess they can be passed in some format through the upper 16K (this would make this not work with debug builds, but it seems like the least hassle). Another potential tripping point with that is that I don't think flexspin can retrieve the 8.3 name for a file when LFS is enabled (as it is in pik's menu loader).
The other tricky thing is detecting the games. I guess if the LFN issue can be solved, Megadrive games are fine since you can just give the files descriptive names. The usual .BIN extension is a bit eh, since it is also used for many other things you probably don't want to launch as an MD game. You could just ask people to rename them all to .GEN or .SMD, which are more unique. Though you can also disambiguate .BIN by checking if the 4 bytes at offset $100 spell "SEGA" (all but the inital rev of actual consoles need this to boot up, so the only games that lack it are very early 3rd party ones).
NeoGeo games are harder because they have fixed paths that the emulator needs them to have. And of course being a directory rather than a single file. I guess the most straightforward way is to just list every subdirectory of /sd/neoyume/ (except /sd/neoyume/neogeo, which holds the BIOS) and just go off the romset names. Another option would be to use the actual gamedb the emulator uses. Either by copying the relevant parts into the menu program or by just ripping it at runtime straight from the installed NeoYume binary (I can add a marker string in front of the data block to help with that).
Addendum: potential parameter passing convention
Magic sequence at $FC000 : "ProP" or similar 4 letters, followed by zero-separated list of parameters. two zeroes mean end of parameter list. Emulators really only need the first parameter.
It seems that the fatfs library underlying the SD card VFS does have a concept of LFNs vs 8.3 names (and seemingly supports accessing by short name when in LFN mode? Haven't tested if it actually works), but this is not exposed to the VFS layer. I guess it can be done by probing into internal fatfs structures, since f_stat apparently does return a FILINFO that has the altname field populated with the short name. I guess all of this can just be encapsulated into one function that converts all LFNs in a given full path to short names.
Comments
Try changing the last byte of
xinp_led_cmd byte $01, $03, $02(as per the legend). 02 works for my nonsense, but maybe 06 is better.I tried several values, all seem to behave the same, no effect on the flashing...
Oh well, USB make brain hurt
So I just checked both of my USB gamepad devices and they are low speed
Maybe one day...
Just figured out why the sound in Pulstar and Blazing Star doesn't work by way of spontaneous thought. It seems to be the same basic issue as the Data East games had - Z80 NMIs come in too close together due to the asynchronous nature of the 68000 emulation. That issue was fixed by adding a WAITX into the NOP implementation so that the wait loops run slow enough to give the Z80 enough time to handle the NMIs.
I can get the sound going by adding a
waitx #100into the DBcc implementation, but that's obviously stupid. Will have to check what the wait code in those games actually looks like, but I assume/hope its just a DBcc branching to itself.Yep, that was it, DBF branching to itself. Maybe should have played around with the delay value, but 100 cycles seems to be ok. Anyways, since it's been a month since V1.0-RC1, this fix is also now the final V1.0 release for NeoYume. (Since I hope 1.1 will be USB hub support)
Get it while it's hot!
Just pushed final v1.0 for MegaYume as well. No change since RC2, just for consistency.
Since MegaYume doesn't principally rely on copyrighted system files (as NeoYume does) and MD is a decently popular system with hobby developers, I've added links to some freeware ROMs into the README, as reproduced below. I think Ken asked about something like this at some point.
here's a video capture of me running some of those:
Old Towers immediately reminded me of Nebulus. Totally different game though. Fond memories of Nebulus.
Just fixed some issue wherein some files wouldn't load in MegaYume. Some sort of issue with alloca-ing the exmem driver parameters. This issue happened in NeoYume a long time ago, but I never backported the fix. Oh well.
Found an article about making games for MegaDrive.
Claims it is the easiest retro console to make games for:
https://www.gamedeveloper.com/design/making-a-sega-mega-drive-genesis-game-in-2019
Here's the development code: https://github.com/Stephane-D/SGDK
Indeed:
- reasonably fast 68000 CPU, well-supported by GCC -> no/little ASM required
- non-insane memory map / no bankswitching
- simple graphics system (very few "mode" choices, VRAM accessible during active display, entire VRAM usable for tiles or sprites, sane graphics format)
- relatively few quirks to be aware of
- no special security/bankswitch/whatever ICs required to build a cartridge.
(SNES fails on all of these, lol)
Does one need to edit MegaYume to try a homemade game?
No, just loads them right up. I've actually used the SGDK code examples for debugging a lot. (I've also recently fixed the I/O code such that SGDK's controller detection works properly).
EDIT: Also, perhaps important to note, MegaYume is a high-level emulator. Do not use it for game testing/debugging, it will give you strange results.
(For NeoYume, you would need to edit the gamedb file, since the memory maps are different for each game lmao)
How many games would run with a single 16Mb * 4 PSRAM?
Same device as 32MB Edge.
On, the Megadrive side, all of them (compatibility issues nonwithstanding), because they only go up to 4MB. Performance is also fine.
On the NeoGeo side, refer to the handy chart: https://github.com/IRQsome/NeoYume#game-compatibility
Everything marked 8MB or 4MB should work, which is numerically a decent chunk, but excludes many of the really good ones. You really want more space (and arguably also more bandwidth) here. 48MB as 3 banks x 8 bit bus is probably the most bang-for-buck PSRAM config for NeoYume in particular. But that's 6 ICs and 12 pins, oh well.
Turns out at some point @ersmith fixed the libc
readdirfunction to return file type (directory vs data). MegaYume previously used a workaround that involved building paths and callingstaton every file. Turns out that changing it to using the readdir result shortens the directory scan for a reasonably large directory from a few seconds to basically instant.Hmm. I was using stat too for Wiznet ftp code. This does look like a better way...
Since it turns out the PSRAM readback stuff in MegaYume (used for header inspection, i.e. region detect, SRAM save setup, 6 button issue mitigation) was broken again, I have decided to just get rid of it, so the upper code now only ever writes to PSRAM, never read anymore. Instead the header data is just buffered into VAR space, which is arguably more straightforward to begin with.
Work is currently in dev branch due to a prior cleanup change that requires bleeding-edge compiler builds. I've also pushed a bandaid fix to the master branch that hopefully also works.
I just tagged V1.1 for both MegaYume and NeoYume to roll up all the random bugfixes since V1.0 in September.
Notable MegaYume changes since V1.0 :
Notable NeoYume changes since V1.0:
Note that due to some API cleanup, flexspin 5.9.26 is now the minimum compiler version.
Just noticed that the USB gamepad driver has some issues with device initialization that I've somehow not noticed before... Specifically, sometimes hotplugging makes the entire thing die and other times, XInput devices only work after being hotplugged. The behaviors seem to also differ by which application the driver is being used in. Very cool and not at all obnoxious.
Maybe it'll magically go away once I finally adopt the hub-support version.
Yeah I found that the USB joystick I built up for this would not always initialize properly first go after an initial startup, it was usually okay the second time though. Put it down to cheap HW at the time but it might well have been the SW by the looks of what you found Wuerfel_21.
Someone also reported a keyboard issue: https://github.com/IRQsome/NeoYume/issues/6
I've mostly used the PS/2 keyboard adapter and the retro-bit and neogeo mini controllers, which are rock solid and always work from cold boot (and as mentioned, the hotplug issue is intermittent), so I guess that's why I never really noticed that XInput is sometimes busted (both with the StrikeFX and the Retro Receiver).
I'm going to have (an incredibly stupid) motivation to adapt @macca 's new hub-capable driver (along with multitap support in MegaYume so you can play Gauntlet, etc with 4 players) next month. Since that'll require some considerable rework, I hope that whatever the issue is just disappears (Also want to make the controller mappings table-based instead of hardcoded so it's not as obnoxious to add new ones and re-use the driver between projects).
Also might look into poll rates while doing that. I think(tm) that the current driver uses the usual 100Hz rate, which means that the control data varies between being freshly polled to being 10ms out-of-date when the actual game code reads it (at it's 60-ish Hz rate). It should be easily possible to increase it to 250 Hz, which would reduce the maximum age to 4ms. That should move everything slightly closer to the ideal of perfect responsiveness (remember, on the output side our latency is somewhere around ~200 µs, while PC based emulators are conceptually limited to no better than 16ms (run-ahead tricks notwithstanding...) )
Oh yea, and in other news, I've been adding the last couple forgotten games to NeoYume's game list. As previously exposited, each game has a semi-unique ROM layout, so they need to be individually configured to work. I guess this has the upside that it produces a full compatibility list along the way.
So there's some 20-ish new ones as of now, bringing the total to 128. Mostly boring ones (simulated horse racing, anyone? Weird mahjong variants? Unlocalized KOF-themed trivia quiz game? ... no?), but some good ones are in there, too.
Currently on the dev branch only because of the 3 games that are larger than 32 MB that I still need to test (too lazy to swap over to the EVAL board with 96MB)
Update: I have now (read: yesterday but forgot to post) added all NeoGeo games I am aware of, with the exceptions of ones that need some sort of currently unemulated hardware (Garou MOTW, KoF 2003, some other obscure ones), to NeoYume's gamedb. This all on master branch, too, with some other improvements.
Note that "Working" doesn't necessarily mean "Perfect", but good enough to where it can be played normally.
Also perhaps interesting, breakdown of required RAM Sizes (along with a favorable pick as an example from each category) :
It turns out that 16 MB already gets you half the games by quantity. On the contrary, 32 MB Edge only actually misses out on 40 titles (though that's a lot of the best ones).
Could there be (or is there already) a graphical front end menu that could launch any of the MegaYume and/or NeoYume games?
Be nice if there were some key combo or switch or something that could bring you out of a game and back to this main menu...
Answering in LIFO order because lol:
MegaYume can quit to it's own menu (Ctrl+Esc on Keyboard or holding Start+Down for 5 seconds on the controller) and this is all easily controlled from the high-level code, you can change it to reset the P2 instead (launching another binary is sadly not a thing flexspin VFS can really do). NeoYume is more prickly because the menu code and associated C runtime is kicked out of memory as soon as the game launches. If I refactor the Z80 to use the memory arbiter for high ROM (which would also fix Metal Slug 3's audio) I might(?) be able to cut free some 64k. If I could then reduce the menu code to that size (help @ersmith the nu backend is still busted), I could have menu quit in there, too.
@pik33 has a menu that can launch P2 applications (and he just built individual emulator binaries hardcoded to launch a respective game). Making one that can launch emulated games "properly" should be easy, but there's two tricky parts: The first being to launch the emulator with some sort of parameter passed. I guess they can be passed in some format through the upper 16K (this would make this not work with debug builds, but it seems like the least hassle). Another potential tripping point with that is that I don't think flexspin can retrieve the 8.3 name for a file when LFS is enabled (as it is in pik's menu loader).
The other tricky thing is detecting the games. I guess if the LFN issue can be solved, Megadrive games are fine since you can just give the files descriptive names. The usual .BIN extension is a bit eh, since it is also used for many other things you probably don't want to launch as an MD game. You could just ask people to rename them all to .GEN or .SMD, which are more unique. Though you can also disambiguate .BIN by checking if the 4 bytes at offset $100 spell "SEGA" (all but the inital rev of actual consoles need this to boot up, so the only games that lack it are very early 3rd party ones).
NeoGeo games are harder because they have fixed paths that the emulator needs them to have. And of course being a directory rather than a single file. I guess the most straightforward way is to just list every subdirectory of
/sd/neoyume/(except/sd/neoyume/neogeo, which holds the BIOS) and just go off the romset names. Another option would be to use the actual gamedb the emulator uses. Either by copying the relevant parts into the menu program or by just ripping it at runtime straight from the installed NeoYume binary (I can add a marker string in front of the data block to help with that).Addendum: potential parameter passing convention
Magic sequence at $FC000 :
"ProP"or similar 4 letters, followed by zero-separated list of parameters. two zeroes mean end of parameter list. Emulators really only need the first parameter.EDIT: Maybe "ARGv" is a better one.
Infact, I just pushed an implementation of the parameter passing thing to a side branch for MegaYume: https://github.com/IRQsome/MegaYume/tree/argv
You need something like this at $FC000:
Hopefully that actually works and it doesn't get erased by the spin startup or something (I only tested setting it at the top of main)
Will also try adding it to neoyume, but that one will need game IDs instead of paths.
Okay, feature is now in NeoYume as well: https://github.com/IRQsome/NeoYume/tree/argv
Populate $FC000 as shown above. Additionally, you can also force which BIOS to use:
It seems that the fatfs library underlying the SD card VFS does have a concept of LFNs vs 8.3 names (and seemingly supports accessing by short name when in LFN mode? Haven't tested if it actually works), but this is not exposed to the VFS layer. I guess it can be done by probing into internal fatfs structures, since
f_statapparently does return aFILINFOthat has thealtnamefield populated with the short name. I guess all of this can just be encapsulated into one function that converts all LFNs in a given full path to short names.