openMSX 0.10.0

Paladin (765)

06-01-2014, 16:03

Great to see MSX emulator that still being actively developed! I am starting using it more and more than blueMSX, but still I want openMSX to be more user friendly.

PS: Any plans to add Padials SDMMC card to the emulated hardware extensions?

By Manuel

Ascended (20070)

06-01-2014, 17:01

max: thanks, what's the biggest user friendliness issue? Did you try the OSD menu?

(We won't have a new GUI soon, but some things can be easily solved in the OSD menu for now...)

By max_iwamoto

Paladin (765)

06-01-2014, 17:13

@ Manuel: I already get used to OSD quite a lot. But, for example, I needed to replay the omr file and I was unable to do it from OSD, or find it in command line help.

And another thing, would be nice to have more features added to the debugger. Some of them can be triggered from command line, but would be better to have it in debugger menus. For example, ability to trigger events when some RAM addresses or registers change. And some times you need it to do it on special time, so also have a list of them with checkbox to be able easy enable/disable them.

By ray2day

Paladin (787)

06-01-2014, 17:22

Super@! Keep up the good work folks!

By AxelF

Champion (398)

06-01-2014, 18:07

Yaaaay great work

Only now OpenMSX-Debugger miniGW32-rev13131 Crashes when i push the connect button
[ERROR]
Unhandleed exeption at 0x6fafb1db in openmsx-debugger.exe 0xC000005
Access violation writing location 0x01000033

This application has requested the runtime to terminate in an unusual way.

ARGGGGGGTG

By Manuel

Ascended (20070)

06-01-2014, 19:13

For command line help: try the about command. E.g. about replay gives as first candidate the reverse command. Then you can do help reverse and you know more.

I'll point Edwin, our main debugger guy, to this thread. For what it's worth: it works fine for me... (on Linux).

By AxelF

Champion (398)

06-01-2014, 19:19

Manuel wrote:

I'll point Edwin, our main debugger guy, to this thread. For what it's worth: it works fine for me... (on Linux).

Thanks for your reply, problem allready solved.
One of the QT***.DLL files was a bit corrupted, all works perfect now

/ME very happy thanks OpenMSX Team

By Jorito

Mr. Ambassadors (1842)

06-01-2014, 19:30

I'm playing the SD Snatcher translation on my 40" TV using OpenMSX right now, and also played a bit with the OSD (didn't know about it until the demo @ TYME). It's a marked improvement over the console for usability. I'll check out the new release and play the game on that

If you can take the OSD a bit further, you might not even need a new GUI or launcher for most common use cases. Especially if you can find a graphics/UI designer to help streamline things and make it look a bit less like designed-by-and-for-coders

Thinking of basic stuff like:

Add a button (bottom left or bottom right would work) that users can click to bring up the OSD. Now you really have to read the manual and know the shortcut to use it. If you make it visible and clear button it's instantly discoverable and usable.
Show the name of the currently inserted dsk/rom/tape image so you know what image is in there and what you are ejecting.
Same goes for machines, extensions and slots. What machine am I running now? What extensions are already plugged in?
Name things consequently (just do insert rom, insert disk, insert tape in stead of load rom, insert disk, set tape, to name an example)
The menu navigation is a bit unclear; sometimes you have to press enter to dive into a submenu (or file browser), sometimes you have to use cursor left/right to change a value (volume, speed). Easily solved by adding a '>' marker at the end of the menu if you have to press enter to dive in further and use a different laid out widget for the cursor controlled parts (like a volume bar on TVs for example). Would at least work better for me than the '...' indication at the end of the menu items.
And in general have a good look at the current menu structure and labels, relabel complex ones, etc.
The toys are cute, as are the minimum and max frameskip options, but should these advanced options really be in the OSD?
And I have no clue what 'Manage running machines' does. Wouldn't miss it if you threw it out

Just my $0.02. Get a graphics designer to pimp it and make it usable and add (some of) the stuff listed above and you'd have a n00b usable emu that doesn't need a GUI imho.

Having said that, great job on the new release, I'll check it out

By Vampier

Prophet (2426)

07-01-2014, 07:30

Thanks Joritto and also thanks for the great feedback. The OSD menu was never supposed to grow into what it is today. But since almost fully functional we might as well make it better.

On a personal note: I've been with the openMSX team since 2003 and I've seen it grow from a great emulator to what it is today (even better ) my whole motivation for this project has been to preserve the platform/feeling/games. I think we're almost at the stage where emulation is just as good as the real thing... except it doesn't take up as much space on your desk ... I would say it takes up about 11×15×1 mm3?

This will be the last release where we will support Windows XP3 builds... anything previous to XP sp3 will not be supported anymore. Having that said... there probably will be a way to have pre XP sp3 builds (mingw?)

Remember you can always download the latest 'official' dev team version @ http://openmsx.fixato.net/builds/

And don't forget to give us a like on Facebook: https://www.facebook.com/pages/openMSX/129701050395970

By Manuel

Ascended (20070)

07-01-2014, 10:21

Jorito, thanks for your great feedback indeed! I'll try to comment on some things you said:

Jorito wrote:

I'm playing the SD Snatcher translation on my 40" TV using OpenMSX right now, and also played a bit with the OSD (didn't know about it until the demo @ TYME). It's a marked improvement over the console for usability. I'll check out the new release and play the game on that

Ah, so the TYME presentation was useful afterall! The new release has quite some improvements on the OSD menu, you should really check it out.

Quote:

Add a button (bottom left or bottom right would work) that users can click to bring up the OSD. Now you really have to read the manual and know the shortcut to use it. If you make it visible and clear button it's instantly discoverable and usable.

Brilliant idea, we simply hadn't thought of that. I'll certainly discuss this with the other devs. Wouldn't it be annoying to have such a button in the screen all the time?
Also, another concern is that it might interfere with other OSD widgets, but that is the case with all OSD widgets when combining them.

Quote:

Show the name of the currently inserted dsk/rom/tape image so you know what image is in there and what you are ejecting.

The currently inserted ROM for the slot you selected is visible behind the --eject-- item in the menu in 0.10.0.
Is that sufficient?
If not, what would be a good place to add that info?

Quote:

Same goes for machines, extensions and slots. What machine am I running now? What extensions are already plugged in?

The current machine is shown in the title bar of the openMSX window, but you won't see that when running full screen, of course. What would be a good place to show the machine?
Alternatives are now: enable the info_panel toy, it gives all kinds of info on the currently running stuff, including the machine and some of its properties.

About extensions: you can see the list at Hardware -> Extensions -> Remove. Perhaps not a very intuitive place, but where else do you need this list? Do you have a better idea for the menu structure?

Quote:

Name things consequently (just do insert rom, insert disk, insert tape in stead of load rom, insert disk, set tape, to name an example)

Alright, if that helps, I'll discuss it.

Quote:

The menu navigation is a bit unclear; sometimes you have to press enter to dive into a submenu (or file browser), sometimes you have to use cursor left/right to change a value (volume, speed). Easily solved by adding a '>' marker at the end of the menu if you have to press enter to dive in further and use a different laid out widget for the cursor controlled parts (like a volume bar on TVs for example). Would at least work better for me than the '...' indication at the end of the menu items.

As the menu is completely made up of OSD widgets, which have quite limited functionality, we have to deal with limits. So, indeed, the functionality is comparable with older OSD TV menus...
The "..." at the end means like in all common UI systems "opens a submenu". Why isn't that sufficient?

What kind of layout would be suitable for the cursor controlled parts? < and > symbols or something?

Quote:

And in general have a good look at the current menu structure and labels, relabel complex ones, etc.

Any suggestions?

Quote:

The toys are cute, as are the minimum and max frameskip options, but should these advanced options really be in the OSD?

That's a good question. We sacrificed one main menu entry for advanced stuff and put them under there.... frameskip can be quite useful if you have performance issues or want higher speed at full throttle.

Quote:

And I have no clue what 'Manage running machines' does. Wouldn't miss it if you threw it out

Well, you're right, it's been a bit of a hobby thing of mine... It's used to manage tabbed MSXing. I demonstrated it at TYME. You can run multiple MSX machines at the same time and this menu helps you to add new machines or stop existing ones. It will also trigger tab-like widgets at the top of the screen (as soon as multiple machines are running).

Quote:

Just my $0.02. Get a graphics designer to pimp it and make it usable and add (some of) the stuff listed above and you'd have a n00b usable emu that doesn't need a GUI imho.

Where do we grab graphics designers these days?

Thanks again for the great feedback, I hope you will help further by following up on this discussion.

By Manuel

Ascended (20070)

07-01-2014, 10:23

@max: oh, if you don't like those help commands, just use the complete commands overview: http://openmsx.sourceforge.net/manual/commands.html
You can probably easily search there with your browser and stuff.

@AxelF: glad it all works again :)

By Jorito

Mr. Ambassadors (1842)

07-01-2014, 12:38

Manuel wrote:

Thanks again for the great feedback, I hope you will help further by following up on this discussion.

I'll get back on this later this week, after I have found some time and have given v0.10.0 a spin. Please remind me if I forget/am late.

By Manuel

Ascended (20070)

07-01-2014, 13:34

Jorito: sure thing!

For those who are interested: I've just updated the Win32 MinGW snapshot of the openMSX debugger with the latest code. Get it here: http://openmsx.sourceforge.net/temp/openmsx-debugger-win32-b... (a 32-bit Windows build of the debugger). Thanks to BiFi for building it (again).

You need it to work with openMSX 0.10.0, without it the segment view is broken.

By AxelF

Champion (398)

07-01-2014, 19:00

What has been changed in the latest code version of Debugger ?

By Manuel

Ascended (20070)

07-01-2014, 21:23

Check the debugger changes here: https://sourceforge.net/p/openmsx/debugger/ci/4bb1facce42fc0...

Not many changes, the most important one the one I talked about.

By Jorito

Mr. Ambassadors (1842)

07-01-2014, 23:24

Manuel wrote:

Quote:

Add a button (bottom left or bottom right would work) that users can click to bring up the OSD. Now you really have to read the manual and know the shortcut to use it. If you make it visible and clear button it's instantly discoverable and usable.

Brilliant idea, we simply hadn't thought of that. I'll certainly discuss this with the other devs. Wouldn't it be annoying to have such a button in the screen all the time?
Also, another concern is that it might interfere with other OSD widgets, but that is the case with all OSD widgets when combining them.

You already have the LEDs on your screen most of the time. This wouldn't be much different. Optionally you could just make the window/screen a bit taller and place the LEDs and menu button below the emu window in stead of over it.

And of course you can always make this a configurable setting (that's on by default for the n00b users). Simply add a 'hide menu button' option in the OSD menu that's easy to find is just one idea.

Manuel wrote:

Quote:

Show the name of the currently inserted dsk/rom/tape image so you know what image is in there and what you are ejecting.

The currently inserted ROM for the slot you selected is visible behind the --eject-- item in the menu in 0.10.0.
Is that sufficient?
If not, what would be a good place to add that info?

It's a lot better this way. My only issue here is that you actually have to click on 'load rom' or 'load disk' and such to see what's currently inserted in the "eject" string. It'd be nicer (IMHO) to not need an extra click here. So it might be an idea to add it after the "Load ROM" option (like "Load ROM (ATHLETIC.ROM)" or so).

Manuel wrote:

Quote:

Same goes for machines, extensions and slots. What machine am I running now? What extensions are already plugged in?

The current machine is shown in the title bar of the openMSX window, but you won't see that when running full screen, of course. What would be a good place to show the machine?
Alternatives are now: enable the info_panel toy, it gives all kinds of info on the currently running stuff, including the machine and some of its properties.
About extensions: you can see the list at Hardware -> Extensions -> Remove. Perhaps not a very intuitive place, but where else do you need this list? Do you have a better idea for the menu structure?

For the machine I have no better ideas right now than to add it directly below the OSD main title (openMSX 0.10.0) or maybe, as with the rom and disk stuff add it between brackets (like Hardware > Change machine (Philips NMS 8245)).

About having toys for this: IMHO toys are too gimmicky for the casual user. They merely should be a nice extra for advanced users and as such shouldn't be present in the OSD menu and also shouldn't be the only place where you can see crucial info. But that might be just me

For extensions... well... I have an idea here that will work but might be a bit inconsistent with my other remarks above. So some streamlining might be in order.

An obvious place to list the extensions is to just have them listed in the Extensions submenu directly. So:

Click Hardware > Extensions. The Extensions menu appears and looks more or less like this:

Konami SCC+               x
Memory Mapper (4MB)       x
Philips MSX AUDIO         x

Add extension

Where the 'x' (or a trashcan icon or so) allows you to remove the current extension. Optionally you could simply let people remove an extension by selecting it from the list of current active extensions and have them press enter.

Manuel wrote:

Quote:

The menu navigation is a bit unclear; sometimes you have to press enter to dive into a submenu (or file browser), sometimes you have to use cursor left/right to change a value (volume, speed). Easily solved by adding a '>' marker at the end of the menu if you have to press enter to dive in further and use a different laid out widget for the cursor controlled parts (like a volume bar on TVs for example). Would at least work better for me than the '...' indication at the end of the menu items.

As the menu is completely made up of OSD widgets, which have quite limited functionality, we have to deal with limits. So, indeed, the functionality is comparable with older OSD TV menus...
The "..." at the end means like in all common UI systems "opens a submenu". Why isn't that sufficient?

Personally I'm more used to (and like) the triangle right that's outlined to the right side. Don't have any real world data on which is more user-friendly and more common or if it's just a matter of taste, but this is also where a graphics designer (who usually has a good feel for which interface elements work and which don't) comes in real handy.

With regards to limitations: if the OSD supports UTF-8 there's a wealth of non-ASCII stuff you can use. For example this: http://www.fileformat.info/info/unicode/char/25b6/index.htm

Manuel wrote:

What kind of layout would be suitable for the cursor controlled parts? < and > symbols or something?

Yeah, that sounds like it would work well (if outlined to the far left and right probably). Definitely worth a shot. Also don't hesitate to stea^H borrow from existing interfaces!

Manuel wrote:

Quote:

And in general have a good look at the current menu structure and labels, relabel complex ones, etc.

Any suggestions?

Nothing more than some credos. Less is more, keep it simple stupid. So stick to the basic menu options you need (don't cram it full with the plethora of advanced options openMSX has) and label them carefully (don't confuse your users with too much nerd talk, make it accessible ;)).

Manuel wrote:

Quote:

The toys are cute, as are the minimum and max frameskip options, but should these advanced options really be in the OSD?

That's a good question. We sacrificed one main menu entry for advanced stuff and put them under there.... frameskip can be quite useful if you have performance issues or want higher speed at full throttle.

How many of the current 'normal' users use these toys, experience these slowdowns and absolutely NEED this option in the menu? If it's a large part of the audience it needs to be in the menu. If it's only 1% of the users (which I suspect) it doesn't deserve a place in the menu IMHO :)

Manuel wrote:

Quote:

And I have no clue what 'Manage running machines' does. Wouldn't miss it if you threw it out :)

Well, you're right, it's been a bit of a hobby thing of mine... It's used to manage tabbed MSXing. I demonstrated it at TYME. You can run multiple MSX machines at the same time and this menu helps you to add new machines or stop existing ones. It will also trigger tab-like widgets at the top of the screen (as soon as multiple machines are running).

Again, less is more and simple is good. Or at least for what I have in mind and what I think is what most casual users would use/need. Focus on the basic essentials (loading roms/disks, plugging extensions) and make it easy to use. Especially for the casual games that don't feel like studying manuals and spending a few hours to get up and running.

Of course if this is not one of the target audiences you can ignore my findings here. Or optionally create 2 OSD menus; a basic one with the stuff I listed here and a more advanced one for the hardcore nerds. Or go crazy and add a 3rd OSD for devs.

Manuel wrote:

Quote:

Just my $0.02. Get a graphics designer to pimp it and make it usable and add (some of) the stuff listed above and you'd have a n00b usable emu that doesn't need a GUI imho.

Where do we grab graphics designers these days? :)

I'd say don't limit yourself to the MSX scene. Look at other emus and creators of emu front ends. There's some great stuff out there and most of it is done by enthusiasts. Just contact some of them and see if they are interested into redesigning the OSD within the limits you mention for a nice prominent place in the credits :)

That's my input so far. If you'd like more, I suggest you create a forum topic here and point me to it so we can continue the discussion there in stead of 'polluting' the news post comments here :)

By Jorito

Mr. Ambassadors (1842)

07-01-2014, 23:32

Oh, a few last things.

In the 0.10.0 OSD my current MSX doesn't have a cassette port. It now says in big gray letters "No cassette port present". Maybe you shouldn't show it in the menu then? Bit undecided on this as there's a (very small) percentage of users that might have mistakenly chosen a computer without disk drive that want to load disk games, and it's not very discoverable then. OTOH, I know this MSX doesn't have a cassette port (it's a GT), so don't yell at me to say that

Also for the volume, frameskip and other cursor-adjustable fields: can you simulate something like the (HTML5) range slider here? At least my TV's OSD has sliders like this

By mth

Champion (507)

08-01-2014, 16:39

One option for an "open OSD menu" button would be to show it at startup, then fade it out, like the LEDs do. But if you hover near it with the mouse cursor, make it fade in again.

By Manuel

Ascended (20070)

08-01-2014, 17:44

Jorito, perhaps you can be so kind to move/copy this discussion to a new topic in the openMSX forum? Then everything is there and people do not have to switch between 2 pages.

By Jorito

Mr. Ambassadors (1842)

08-01-2014, 21:01

There's no good way to move discussions from news to forum and vice versa. So I had to do a bit of copy/pasting. The new forum topic is here: http://www.msx.org/forum/msx-talk/openmsx/openmsx-osd-improv...

By Manuel

Ascended (20070)

08-01-2014, 22:35

Thanks!

By sd_snatcher

Prophet (3777)

08-01-2014, 23:48

Thanks again for another release of this excellent emulator! And it's not just a mere emulator, it's a excellent developer tool also!

By gdx

Enlighted (6800)

09-01-2014, 10:56

"Mac support is now limited to Mac OS X 10.7 (so 64-bit only) and higher"
;-(

By Manuel

Ascended (20070)

09-01-2014, 13:09

gdx: sorry, Apple made it very difficult to support older systems when making use of modern C++ compiler features. It was so difficult that we had to decide to drop support for 10.6 and older (and thus 32-bit and ppc). There might be a way to get it done, if someone gets that stable, please inform us. FiXato made a good attempt, but it had some problems with NekoLauncher, IIRC.

By ren

Prophet (2075)

09-01-2014, 15:21

Great! Nice/impressive list of changes/improvements (again)!
I really dig the dedication you guys are showing towards the project, and your striving for (feature-)completeness and accuracy.

I do have some suggestions, and a bug report. I guess it's most handy for you guys to create tickets for this over @ the SF project page? (Need to dust off ye olde account then... ;-))

By Manuel

Ascended (20070)

09-01-2014, 16:24

That's the most comfortable indeed. But for general discussion on this release, please use this thread. And thanks for the compliments!

By Vampier

Prophet (2426)

11-01-2014, 08:49

it's getting harder and harder to support old platforms even though we try hard to keep everything compatible.

openMSX will run on XP sp3 for at least one more release... not sure if there will be a need to switch to VS2014 when it is released.

By AxelF

Champion (398)

23-02-2014, 23:36

Will there be MegaFlashrom SCC+ SD emulation possible on OpenMSX in the near future ?
That would be cool

By Manuel

Ascended (20070)

24-02-2014, 09:55

Is there a good source for the details on that interface?

By AxelF

Champion (398)

24-02-2014, 14:14

Maybe Manuel Pazos can help you with the details of the device.

Share

Comments (30)