Shop Learn P1 Docs P2 Docs Events
Console Emulation - Page 42 — Parallax Forums

Console Emulation

1363738394042»

Comments

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

  • RaymanRayman Posts: 12,968

    I tried several values, all seem to behave the same, no effect on the flashing...

  • Oh well, USB make brain hurt

  • @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)

    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:

  • evanhevanh Posts: 14,027

    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.

  • RaymanRayman Posts: 12,968
    edited 2022-10-14 21:04

    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

  • Wuerfel_21Wuerfel_21 Posts: 3,401
    edited 2022-10-14 22:10

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

    (SNES fails on all of these, lol)

  • RaymanRayman Posts: 12,968

    Does one need to edit MegaYume to try a homemade game?

  • Wuerfel_21Wuerfel_21 Posts: 3,401
    edited 2022-10-14 22:55

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

  • TonyB_TonyB_ Posts: 2,044
    edited 2022-11-10 17:48

    How many games would run with a single 16Mb * 4 PSRAM?
    Same device as 32MB Edge.

  • @TonyB_ said:
    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 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.

  • RaymanRayman Posts: 12,968

    Hmm. I was using stat too for Wiznet ftp code. This does look like a better way...

  • Wuerfel_21Wuerfel_21 Posts: 3,401
    edited 2023-01-17 00:48

    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.

  • Wuerfel_21Wuerfel_21 Posts: 3,401
    edited 2023-01-30 20:03

    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 :

    • Faster directory scan
    • Hopefully fixed SRAM saves once and for all (major headaches were had for all the wrong reasons)
    • Fixed broken music in Panorama Cotton when launched after quitting another game (clear Z80 RAM on startup)
    • Fixed detection of 6 button controller in SGDK games
    • Fixed nibble LUT for 8 bit PSRAM (could cause conflict with other pins)
    • Fixed hard crash when trying to hot-reset Gauntlet IV (properly disable IRQs on reset)

    Notable NeoYume changes since V1.0:

    • Fixed minor visual issues in multiple games (including Crossed Swords, Kabuki Klash and probably others) by changing VBlank IRQ timing.
    • Added Neo Mr. Do! to gamedb
    • Fixed King of Fighters 2002 being mistakenly marked as having issues.

    Note that due to some API cleanup, flexspin 5.9.26 is now the minimum compiler version.

Sign In or Register to comment.