openMSX 0.14.0 released

openMSX 0.14.0 released

by Manuel on 04-08-2017, 00:50
Topic: Emulation
Tags: openMSX
Languages:

Today, the openMSX Team released openMSX 0.14.0.

openMSX 0.14.0—Blasphemy— is another mix of some new features and additions and a lot of smaller fixes and improvements. This release adds support for Konami Ultimate Collection and basic emulation for the Spectravideo SVI-318 and SVI-328 pre-MSX computers, increases FDC accuracy in such a way that the makers think all copy protections (captured in a DMK file) should now run in openMSX.
Moreover, the SDLGL-PP renderer has been put as the default, so let them know how that works for you. You can of course always set the old default setting for your system if you don't like SDLGL-PP. But then the openMSX team would really like to know why.
The Windows DirectX sound driver was removed as well, as it was buggy and caused a lot of complaints. And finally, a button in the top left corner was added to easily invoke the OSD menu.
Together with openMSX an updated version of Catapult, the user-friendly GUI, was released. Again a small amount of improvements were made:

  • added noise control to Video Control Page
  • fixed the browse extension for the openMSX executable
  • some build support improvements.

Please read the release notes on github for details of the openMSX changes.

Relevant link: openMSX

Comments (46)

By Louthrax

Paragon (1518)

Louthrax's picture

04-08-2017, 01:58

Cool, time to update my PC MSX setup Smile

Why is that release labeled "Blasphemy"?

By Gradius2

Hero (563)

Gradius2's picture

04-08-2017, 03:31

Simple.

Because of "Spectravideo SVI-318 and SVI-328".

Or perhaps the copy protection thing.

By Pencioner

Master (158)

Pencioner's picture

04-08-2017, 13:54

Kudos! Great job.

By ren

Paladin (670)

ren's picture

04-08-2017, 16:16

+ perhaps the vgm logging stuff by niek is worth mentioning. Interesting thing for the .VGM community to be aware of perhaps. There are quite some packs done (just recently as well) with ValleyBell's openMSX 0.8.0 VGM mod. That's a pretty old version of course, have there been any fixes/changes to the (sound) emu between that version & current that might effect the .vgm output?

Don't know if it's possible with (the) Tcl (implementation), but would vgm_rec <action> be possible as well, instead of having 3 separate commands to control logging?

Quote:

[...] the SDLGL-PP renderer has been put as the default, so let them know how that works for you.

I mentioned this before, will do it again: enabling blur from 0 to 1 is already a huge difference, and I would really like it if this change could be more subtle/gradual if possible. Is it like that on Linux as well? I prefer the SDL renderer blurring (because of it).

Quote:

The Windows DirectX sound driver was removed as well, as it was buggy and caused a lot of complaints.

Being? Performance should be the same? I was running with DirectX all this time.

I'll try if I can spot a difference between DirectX & SDL (so basically if I can spot a difference when I set a certain samples size).

Quote:

performance improvements:
- reverse feature
- hq resampler

But quality/outcome of hq resampling remains unchanged? Would it be possible to implement something like an 'ultra' hq resampler, for best results when recording stuff? Smile (Not sure how much of a diff. that would/could make, and if there's a nice lib. available for that..)

Btw, is there any difference in terms of performance and/or optimization between a dev build and release? One noticeable thing is the presence of 2 extra renderers: SDLGL-FB16 & SDLGL-FB32, but is the build less optimized as well, or are there perhaps extra debugging options enabled (that could slow things down)?

Any plans/wishes for the (near) future (next to moving to SDL2)?

Thanks & cheers Smile

By Philip

Master (163)

Philip's picture

04-08-2017, 19:02

Great work, the best emulator in the world got even better !

By niek

Resident (64)

niek's picture

04-08-2017, 19:31

@Ren:
- I've been hanging around in the vgmrips irc channel, ValleyBell and others are aware of the script, however I don't think everyone who should know knows.
- ValleyBell's modified version is indeed very old and also is only for Windows. I've tried to compile it for MAC, but OpenMSX 0.8.0 won't compile on the current OSX. That's actually why I started doing a real version of the TCL script, I already did some tests before that.
- VGM_REC with options to stop and record to the next file would be possible, but I don't see how it's an improvement, imho it's just different

By Giangiacomo Zaffini 2

Supporter (11)

Giangiacomo Zaffini 2's picture

04-08-2017, 20:07

I'm an openMSX lover and I compiled it from sources a couple of times on GNU/Linux Ububtu distros.
Happy to see new versions of openMSX coming.
I had some problems finding Yamaha SFG-05 roms that satisfy configuration xml files, so in the end I changed SHA1 in configuration files. However Grauw's VGMplay works with these rom images on multiple machines but Ain MXP2/MXDRV mdx player do not work, I'm a little sad. Crying
Keep MSX-ing!

By mth

Champion (455)

mth's picture

05-08-2017, 00:40

ren wrote:

+ perhaps the vgm logging stuff by niek is worth mentioning. Interesting thing for the .VGM community to be aware of perhaps. There are quite some packs done (just recently as well) with ValleyBell's openMSX 0.8.0 VGM mod. That's a pretty old version of course, have there been any fixes/changes to the (sound) emu between that version & current that might effect the .vgm output?

Since VGM logs the I/O to the sound chips rather than the synthesis result, I don't think any sound emulation improvements would make a difference to the logged data.

ren wrote:

I mentioned this before, will do it again: enabling blur from 0 to 1 is already a huge difference, and I would really like it if this change could be more subtle/gradual if possible. Is it like that on Linux as well? I prefer the SDL renderer blurring (because of it).

It seems the SDLGL-PP renderer will apply a lot of blur in the vertical direction for a non-zero blur setting. Indeed this doesn't look like what one would expect from 1% blur.

ren wrote:

But quality/outcome of hq resampling remains unchanged?

The outcome is not bit-by-bit identical, but the quality should be the same.

ren wrote:

Would it be possible to implement something like an 'ultra' hq resampler, for best results when recording stuff? Smile (Not sure how much of a diff. that would/could make, and if there's a nice lib. available for that..)

There are resampler libs, but as far as I know the best algorithms they use are similar to the current HQ resampler.

ren wrote:

Btw, is there any difference in terms of performance and/or optimization between a dev build and release? One noticeable thing is the presence of 2 extra renderers: SDLGL-FB16 & SDLGL-FB32, but is the build less optimized as well, or are there perhaps extra debugging options enabled (that could slow things down)?

How optimized the build is depends on the OPENMSX_FLAVOUR build option. By default this is set to "opt", which is also the setting used to build releases. However, for development we use the the "devel" flavour, which has asserts (internal consistency checks) enabled that cost a bit of performance, though I doubt it will be noticeable on modern PCs. When you run "openmsx --version" it reports which flavour the executable is.

ren wrote:

Any plans/wishes for the (near) future (next to moving to SDL2)?

Not really; SDL2 is at the top of my near-future wishlist.

For the far future, network play would be a very nice feature, but that will be tricky to implement. The work done for TAS is going to help there: when given the same inputs at the same emulated time, two instances of openMSX are guaranteed to be in the same state. The difficult parts for network play would be latency hiding, dealing with firewalls and creating a way for two people to find each other. Note that this feature is a wish, not something that is planned: it might be implemented years from now, or never.

By Grauw

Enlighted (5838)

Grauw's picture

05-08-2017, 01:11

niek wrote:

I've been hanging around in the vgmrips irc channel, ValleyBell and others are aware of the script, however I don't think everyone who should know knows.

Maybe post on the VGMRips forum, you can make a new topic, also spam here, and ask ValleyBell to update this topic, etc. Btw, great job, really happy with it supporting all those sound chips, and being built in and polished. I’m sure I’ll put it to good use!

Giangiacomo Zaffini 2 wrote:

I had some problems finding Yamaha SFG-05 roms that satisfy configuration xml files, so in the end I changed SHA1 in configuration files. However Grauw's VGMplay works with these rom images on multiple machines but Ain MXP2/MXDRV mdx player do not work, I'm a little sad. ;(

Hey Giangiacomo, VGMPlay does not use the ROM other than for detection, so if there’s a problem with the ROM that could explain it. I dumped my SFG-05 ROM a while back, I think it’s here.

mth wrote:

Since VGM logs the I/O to the sound chips rather than the synthesis result, I don't think any sound emulation improvements would make a difference to the logged data.

Timing improvements could possibly make some difference since VGM has a 44.1 kHz accuracy, however I doubt openMSX 0.8 had any timing inaccuracy of that magnitude, and even if it had some small deviations, it would be inaudible.

By Vampier

Prophet (2052)

Vampier's picture

05-08-2017, 08:40

don't forget to like us on facebook ;-)

https://www.facebook.com/openMSX/

By ren

Paladin (670)

ren's picture

05-08-2017, 18:38

niek wrote:

VGM_REC with options to stop and record to the next file would be possible, but I don't see how it's an improvement, imho it's just different

Well, because most stuff / programs work that way: one command/executable + I believe it prevents global namespace clutter.
But I'm not sure if I quite understand the console / scripting feature well enough anyway, as it also exposes private functions? (E.g. vgm::scc_data, vgm + tab will list them all). I'm not sure why these functions are exposed to the console / are accessible like that, aren't they supposed to be private/protected? Or does it give one some nice hacking power? Smile

@mth thanks for your answers. Regarding the SDLGL-PP blur: anything that can be done about that? Will the move to SDL2 also mean different renderers?

Network play would be a rather cool feature indeed. Personally, more toyish though, I think it would also be neat to implement some kick ass monitor emulation (issue tracker issues already exist). I already mentioned it over there: there's display_deform arcade I doubt anyone ever uses, but if you could make that tilt adjustable we gain ourselves a nice new monitor emulation feature already..? Wink

(..but enough open issues as well anyway.. Wink)

By ren

Paladin (670)

ren's picture

05-08-2017, 19:45

me wrote:

Well, because most stuff / programs work that way: one command/executable + I believe it prevents global namespace clutter.

+ it's not consistent with other/similar commands like record.

Anyway, good job!

By Manuel

Ascended (13301)

Manuel's picture

05-08-2017, 21:46

ren, thanks for all the feedback. Next time, I'd prefer to get that before a release, so we can still take it into account.

I made a ticket for the tabcompletion, getting all the internal procs listed was not the intention indeed.

By ren

Paladin (670)

ren's picture

05-08-2017, 22:14

Manuel: maybe next time you can do a pre-release to gather some feedback? I did see a rc build.

Btw, not sure why you're pointing people to the dev build page?
Your home page (which was offline > 24h earlier this week btw, were you aware?) does point to the release page.

By Manuel

Ascended (13301)

Manuel's picture

05-08-2017, 22:19

There's no need to do a pre release if you can simply download the latest build at any time right?

The website outage was unfortunate, luckily someone pointed us to it. (Thanks Pippo!)

I'm not sure what you ask why we point people to the dev build page. It's to let people run the bleeding edge and to get feedback from that.
I'm also not sure about your last remark. Didn't you expect the homepage to point to the release page? I guess I don't quite follow your point. Please elaborate.

By ren

Paladin (670)

ren's picture

05-08-2017, 23:18

(I love to elaborate, I like that word Wink)

You ask me if I couldn't have given my feedback earlier, but most of this is longstanding stuff, only the VGM logging stuff by Niek is a new subject in that regard.

Anyway, when you do a release, make an announcement, that's a nice opportunity for people to give, and for you to receive some feedback right? You didn't ask people to check out the changes before release, which could have given me (for example) the opportunity.

I figured you want regular users to download/use the release build right? (Why would you make those otherwise?) If your download direction is for advanced/experienced/'enthusiast' users, then that's perfectly fine of course ;-)
Anyway, this is about the 14.0 release, and then you're not even pointing to the release builds. I found that a bit peculiar Smile

Ps. would've mentioned site down myself eventually, it's the true Smile

By Manuel

Ascended (13301)

Manuel's picture

05-08-2017, 23:30

Sorry, I wasn't aware of the longstanding stuff, unless it is in a tracker item.

You're right: next time I will also use MSX.org to ask for pre-release testing, instead of only our Facebook followers.

What do you mean that we are not pointing to the release builds? Where are we not pointing to the release builds?? Our download section of our website is pointing to all release builds, isn't it?

By Manuel

Ascended (13301)

Manuel's picture

06-08-2017, 09:09

Aha, the news post here is pointing to fixato's site. That's incorrect indeed.

By ren

Paladin (670)

ren's picture

06-08-2017, 10:42

Yeah, that was what I was pointing at Wink

That tab-completion function listing thing is there as long I can remember.. How come you never noticed, or doesn't it occur on Linux?

Yeah, wouldn't rely on fb alone (and aren't here the more enthusiast users anyway?)
Of course you can point to both release & dev builds in newsposts like this.

Happy Sunday's!

By Samor

Paragon (1763)

Samor's picture

06-08-2017, 14:06

I'll try to run the release builds a little more often, I usually grab the latest main release.....
that said, I'm quite happy with 1.4.0.... was the directx sound driver the default on windows in previous versions? As I'm under the impression I can use a lot smaller sound buffer now than before, which is good.

By Meits

Scribe (4331)

Meits's picture

06-08-2017, 14:30

Manuel wrote:

Aha, the news post here is pointing to fixato's site. That's incorrect indeed.

That was my choice. I wanted people to be able to download it, as the only link that was submitted was the release notes.

By Manuel

Ascended (13301)

Manuel's picture

06-08-2017, 16:01

Yeah, so it's corrected now. The main place to download openMSX is simply from the website where you see a big Downloads box on the left.

Samor: I think it was indeed. Did you mean you want to run development builds more often? You're most welcome to do so.

ren: the tab-completion issue I also noticed last week, but I forgot about it. I don't know if it was like this for a long time, but I never really noticed before. Anyway, a bug ticket was created. I hope it can be fixed soonish.

ren: so, which other things should still be fixed in your opinion? What was the point on the hq remark? Hq is about the most sophisticated resampler you can thing of. It's really very good. Did you still have issues with it? Are there any other long standing issues we should be aware of (or am I skipping something you already mentioned?)?

By ren

Paladin (670)

ren's picture

06-08-2017, 17:57

Regarding the hq resampler, I tried to compare it with blip, and did notice a difference while playing Aleste (just to share my findings Wink) No problems with it, sounding good.

But now, e.g. in Reaper (DAW), you can set the resampling from Lowest (point sampling), to Extreme HQ (768pt HQ Sync) (though I do settle for HQ (512pt) Wink)
A screenshot of these options can be found here. That's from an older version though, all values have been cranked up a notch since.

I wonder how openMSX's hq/blip resampling compares to these options (if it's possible to compare anyway / to say something about that).

If one wants to record, performance is of a lesser issue, so then the resampling can be cranked up.
Perhaps the resampler you're using can be configured as well? (Which could then potentially be made user-adjustable.)

No other issues come to mind ATM. I hope Maarten will still respond to the question regarding the SDLGL-PP blur.
A while ago I did run into #78 [Feature] Default extensions [sf#54] myself though (next to you & Grauw back in 2003/2004 ;))

Another nice thing perhaps would be the possibility to export a machine config/state, that would make openMSX a lot more portable, and that way you could easily share something with another user or developer.
But this would be a new feature request though ;-)

+ oh yeah, just coming to mind: incremental quicksaves + (auto) prefixing those saves based on config/media (so e.g. when gaming, each game can increment on its own..) Feature request for that yet? :) Guess it has happened before someone accidentally overwrites his/her quicksave am I right? :murdock: (Hmm.. an option to auto-save before quickload would also be a great feature / safety measure!)

+ oh yeah(2) I did run into something regarding some auto_enable_reverse inconsistency I believe, but don't properly remember now what the issue was exactly, will report on that when I recall ;)

+ oh yeah(3) Audio reproduction I care deeply about (as you might have guessed ;), I wonder what the status of #958 [Bug] PSG envelopes are too loud [sf#567] is? (Well Beefington is (next to a cool name ;) a cool piece of music, recommended listen ;) I can confirm the issue on 0.14.0/Boosted MSX2+ JP.

Thanks!

By Manuel

Ascended (13301)

Manuel's picture

06-08-2017, 19:08

ren wrote:

I wonder how openMSX's hq/blip resampling compares to these options (if it's possible to compare anyway / to say something about that).

I don't know either, especially as I don't know how it's done in that DAW. You can see in the openMSX source code where our HQ implementation comes from and which settings it uses: https://github.com/openMSX/openMSX/blob/master/src/sound/Res...

Quote:

If one wants to record, performance is of a lesser issue, so then the resampling can be cranked up.
Perhaps the resampler you're using can be configured as well? (Which could then potentially be made user-adjustable.)

Not sure what you mean, I think when recording, the resampler setting is taken into account already. So just set it to HQ to get HQ sound quality. It's what I use always anyway. Only on slow systems blip offers some speed advantage.

Quote:

No other issues come to mind ATM. I hope Maarten will still respond to the question regarding the SDLGL-PP blur.

I created a ticket for it. What kind of response are you waiting for?
Here's the ticket: https://github.com/openMSX/openMSX/issues/1070

Quote:

Another nice thing perhaps would be the possibility to export a machine config/state, that would make openMSX a lot more portable, and that way you could easily share something with another user or developer.
But this would be a new feature request though ;-)

How is this different from making a savestate or a replay and sharing it with someone else? These files are quite portable (unless you use IPS patches).

Quote:

+ oh yeah, just coming to mind: incremental quicksaves + (auto) prefixing those saves based on config/media (so e.g. when gaming, each game can increment on its own..) Feature request for that yet? :) Guess it has happened before someone accidentally overwrites his/her quicksave am I right? :murdock: (Hmm.. an option to auto-save before quickload would also be a great feature / safety measure!)

Try the auto_save_replay setting... is that something you mean? Such things can be scripted quite easily.

The normal savestate command already is incremental, isn't it?

Quote:

+ oh yeah(3) Audio reproduction I care deeply about (as you might have guessed ;), I wonder what the status of #958 [Bug] PSG envelopes are too loud [sf#567] is? (Well Beefington is (next to a cool name ;) a cool piece of music, recommended listen ;) I can confirm the issue on 0.14.0/Boosted MSX2+ JP.

The status is in the ticket. No news, no different status. Sorry.

Quote:

Thanks!

Thank you for all the feedback!

By Samor

Paragon (1763)

Samor's picture

06-08-2017, 19:21

@Manuel yes, I meant development builds.

By wouter_

Champion (384)

wouter_'s picture

06-08-2017, 19:25

ren wrote:

... I wonder how openMSX's hq/blip resampling compares to these options (if it's possible to compare anyway / to say something about that).

The HQ resample code in openMSX is based on libsamplerate. It uses a windowed sinc pulse of 4926 points. According to the libsamplerate documentation this sinc has a stop band attenuation of -100dB (should be sufficient). From this sinc various sets of FIR filter coefficients are extracted. The length of those filters varies from about 50 to 200 points, depending on the resample-ratio. Small ratios use a shorter filter (e.g. MSX-Music to host, 49.7kHz -> 44.1kHz). Large ratios use a longer filter (e.g. SCC to host, 223.7kHz -> 44.1kHz).
I have no idea how this compares to the settings in Reaper (DAW). I don't even know if their algorithm is similar to the libsamplerate algorithm. Or if they need to handle multiple ratios (multiple sound chips) at the same time.

By ren

Paladin (670)

ren's picture

07-08-2017, 00:53

Thanks for your elaboration Wouter.

I did some quick testing regarding the PSG issue:

  • blueMSX: same issue (openMSX seems to sound somewhat more clear & closer to the original recording) (I did notice some difference in percussion/hi-hats already listening to some Starship Rendezvous);
  • fMSX: issues (rather poor audio quality btw);
  • MAME: seems unaffected (nms8250 - couldn't get hbf1xv to run MSX-DOS2 (no way to specify mapper type?)) (didn't listen to the whole song though, and for some reason really low sound output (even cranked up volume to +6)).

If it helps I can make recordings, we need to get the AY-3-8910 right of course Wink
Of course MAME profits from it's scale / large number of devs involved, so might be they fixed something there already? mame/src/devices/sound/ay8910.cpp

-edit: hmm.. after listening once more, MAME seems effected as well, but perhaps somewhat less.. Getting late ;)
And all this is based upon comparing to the provided real h/w wav.. Perhaps someone else should check on his real machine as well (who is willing? ;))

By ren

Paladin (670)

ren's picture

07-08-2017, 14:27

Recorded some stuff, MAME definitely does a better job in this regard, getting close to the original. Although the bass kick still seems to drown somewhat, the sawtooth doesn't nearly have the loudness as witnessed in openMSX.

Will update the GitHub issue, and post the recorded snippets.

By Manuel

Ascended (13301)

Manuel's picture

07-08-2017, 20:07

Please do and thanks for that.

By PAC

Guardian (4288)

PAC's picture

10-08-2017, 19:18

Well done! Until now I couldn't successfully use openMSX mainly because (as a good MSX user Tongue ) my PC hardware configuration is also quite old. I was discussing with you about it time ago and there was no solution...

The embedeed graphic card didn't help and sound was choppy permanently so the only feasible solution was to use the smallest scale window, in few words a very limited usage... Right now I've tested this new version and everything improved a lot. I can set bigger scale windows, although new renderer SDLGL-PP is not supported and sound is correct. Wink

By gdx

Paragon (1462)

gdx's picture

13-08-2017, 12:13

Can you add the JoySNES emulation in a next version?

By Grauw

Enlighted (5838)

Grauw's picture

13-08-2017, 13:14

Or JoyMega? The 8-button support, specifically.

By Manuel

Ascended (13301)

Manuel's picture

13-08-2017, 22:17

What is joySNES exactly? Where can I read the specs or technical info?
Same question for joyMega.

Feel free to submit a ticket for such things.

EDIT: I've looked up the joySNES stuff, but what is the point of it? Do you want to put a SNES controller in the PC to control MSX games? Then emulation of joySNES is not the right way. If not, what is the point in emulating it? OK, I guess the Select and Start functionality (by using the unused combinations) and auto-fire could still be useful. Which MSX software supports it?

About joyMega: which MSX software supports it, other than JoyTest?

By Grauw

Enlighted (5838)

Grauw's picture

13-08-2017, 22:16

http://frs.badcoffee.info/hardware/joymega-en.html

Pointless Fighting and SMW support it. The game experience is better with it than without.

By Manuel

Ascended (13301)

Manuel's picture

13-08-2017, 22:20

And for joyMega, the point is to map it to multiple host PC buttons, right? (Similar to that Mega Drive joystick.)

By gdx

Paragon (1462)

gdx's picture

14-08-2017, 02:25

Emulating both would be perfect. Smile

Manuel wrote:

I've looked up the joySNES stuff, but what is the point of it? Do you want to put a SNES controller in the PC to control MSX games? Then emulation of joySNES is not the right way. If not, what is the point in emulating it?

Some games need keyboard and joystick to play. I would try to make patches for these games to play with the JoySNES. The debugger would simplify the development and patched games would be playable also on emulator without keyboard. I like SNES controller, this is the best retro controllers in the world and the ergonomics is very good on MSX too. Big smile

About joyMega, the function of Sofarun would become usable.

By Grauw

Enlighted (5838)

Grauw's picture

14-08-2017, 11:56

@Manuel Yes, and oh god I forgot to mention Sofarun.

@gdx So JoySNES doesn’t use the same scheme as JoyMega for the additional buttons? Bit Sad

By Louthrax

Paragon (1518)

Louthrax's picture

14-08-2017, 12:01

gdx wrote:

Emulating both would be perfect. Smile
About joyMega, the function of Sofarun would become usable.

Thinking about that, the JoySNES should not be too hard to add in SofaRun (patching logic is already here).

By Manuel

Ascended (13301)

Manuel's picture

15-08-2017, 00:27

gdx: openMSX emulates MSX devices, not other devices. So, it can emulate MSX hardware. A SNES controller is not something openMSX can emulate. What openMSX can do is use the controller input of the host PC and offer that to the MSX in a specific way.

If the joySNES is only about the select and start buttons that use some of these combinations (UP+DOWN, LEFT+RIGHT), we could implement a way to bind these combinations on the MSX side to a host PC thing (e.g. a host PC joystick button or whatever you like). Would that suffice? (I would actually expect this is already possible, but I can't find how, so maybe it isn't...)

By Grauw

Enlighted (5838)

Grauw's picture

15-08-2017, 01:13

@Manuel The msx.org wiki information is incomplete. If you follow the link to the documentation at the bottom of the wiki page, you will notice that it also has a mode where it maps all 12 buttons. The joystick mode is selected by the user by holding a key pressed at boot-up.

By Manuel

Ascended (13301)

Manuel's picture

15-08-2017, 01:19

Alright, so it uses some kind of protocol similar to JoyMega... So the point is then the same as with JoyMega?

By Grauw

Enlighted (5838)

Grauw's picture

15-08-2017, 01:51

Yes. Unfortunately not the same protocol, despite having the same number of buttons. Supporting both will be a bit more hassle, but probably not too much, especially if I have an emulator to test with (I only own a JoyMega myself). From a programming point of view I like the JoyMega method a bit better, the native protocol of Sega’s joysticks matches the MSX design well.

Nice for JoySNES btw is that 8Bitdo sells wireless bluetooth receivers for the SNES. I hope someday they will also sell one for the MegaDrive… Or maybe someone here can make one with an arduino.

By gdx

Paragon (1462)

gdx's picture

15-08-2017, 12:22

Grauw, you are sure? I thought that Sega Genesis controllers have 4 or 7 buttons not 8.

By Grauw

Enlighted (5838)

Grauw's picture

15-08-2017, 12:50

3-button controller: A B C Start
6-button controller: A B C Start X Y Z Mode

By gdx

Paragon (1462)

gdx's picture

15-08-2017, 14:18

The "Mode" button is not present on several controllers or it is well hidden.
So we have to be careful when we buy a Sega controller. Is Sega Saturn Controller usable?

By Grauw

Enlighted (5838)

Grauw's picture

15-08-2017, 14:36

Yes, as I understand it many Chinese clones do not have the mode button, probably because few games ever used it, so they could save a buck by omitting it? Sega’s original 6-button controllers all have it, but they’re kinda hard to get, expensive. The Saturn controller signals are not compatible.

In a game, I probably would make sure any functions accessed via X Y Z and Mode are also accessible in another way.

My MSX profile