@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.
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.