I don't know which one started it, openMSX and blueMSX mention which features are unique among MSX emulators, and which were 1st (features that were unique until they were implemented in another one). I understand the use of "unique", it's what makes an emulator distinct to another, but (in the case of most of these features) it feels to me like saying this feature was invented by the emulator developers, instead of an obviously borrowed idea from another home computer/console emulator or happening to be the first to translate a newly scanned datasheet of an MSX device to emulation. As for the "1st", it's like saying the next emulator that implemented this feature borrowed the idea from the MSX emulator that implemented it first.

Any comments from openMSX/blueMSX developers on the reasoning behind "unique" and "1st"?

The openMSX feature table looks to be correct, and unlike blueMSX nicely tells "unique" and "1st" is among MSX emulators only (not emulators in general).
The one from blueMSX contains a few errors:
- "1st - PAL video emulation": 50hz and extra lines? It's very common, I don't think blueMSX was first.
- "1st - Run time insertion and removal of cartridges and other extensions": NLMSX.
- "1st - Speed setting (in percent)": NLMSX, sure it's not in percent on NLMSX, but is that so special?
- "1st - Change of multiple disks with a single key click": Come on, that's been available since fMSX-DOS.

It was openMSX that started it and there were quite a few 'errors' to begin with. Not sure if its a good or bad thing to follow but we did. Sometimes its a bit hard to tell if a feature is unique enough to call it unique. Good that you're checking it and have feedback. Here are some explanations to the ones you mentioned

* PAL video I suppose mean the fuzzy monitor emulation, not 50Hz 313 scanlines

* Didn't know NLMSX supported runtime insertion of carts.

* NLMSX does not support running the entire emulation at say 10x faster than normal. This does not mean that you can configure the Z80 speed because thats different

* fMSX-DOS does it I guess but you need those concatenated files, right? No switch between multiple dsk files

Indeed, fMSX-DOS used it differently, you mean the unique v-DRIVE feature?:

Quote:

Virtual Drive (aka blue v-DRIVE) -What's blue v-DRIVE? v-DRIVE is an blueMSX unique function introduced in v1.3.0. So what does it do? Well it's a simple yet powerful hotkey for users to swap disk without going the file selection window. v-DRIVE hotkey will let users toggle between available contiguous dsk file of your choice. (Works similar to ' ALT+TAB' task switcher in your Windows.) Users will find it quite handy when playing games with massive disk exchange!

Check out this message, posted by me on the NLMSX beta mailinglist, dated May 26th 2002:

Quote:

Subject: [NLMSX Beta] disk image idea hi, i've got an idea regarding changing of disk images. many games have multiple disks, almost everyone has them named: name of game - disk a name of game - disk 1 nameofgameA nameofgame1 so a system could be implemented to increment and decrement the disk number with the push of a button, without having to change the disk manually: eg. disk increment key=f7, disk decrement key=f6 (yes, i know these buttons are in use right now ;p ) user places Alese2A.dsk and runs it and watches the demo, aleste 2 asks for disk 2, user presses f7, nlmsx looks at the last char of the filename of Aleste2A.dsk (no extension). it then should easily increment the character number; b comes after a, B comes after A, 2 comes after 1. if it can find Aleste2B.dsk, it will insert that disk, if it can't it will give an error and leave the A disk. decrementation would go the same way.

Afterwards, it's been posted to the online NLMSX to-do list (that's been deleted when NLMSX got inactive). I guess the person who submitted the idea as their own actually got it from that list, since the v-DRIVE feature is exactly as I suggested it .. Can you understand why I think this "unique" and "1st" is a bad idea? (PS, not blaming you personally dvik, nor am I upset by this, I just don't think it's a good idea)

Hum. Another useful thread

Both "big" emulators are improving and I think it is good for the whole community to have this "fairplay" competition going on between them.

If you want to make it interesting, do not try to learn which one was first to do something. I think it would be better to state clearly what they do and is unique/special. For example, openMSX supports direct loading of WAV files. BlueMSX includes a built-in debugger with some powerful tools.

Yeah, the competition's great. In return, it creates more motivation to work on their emulators. And I agree mentioning unique features is meaningful, though it could be worded differently than the way it is now.

Or for some added humour, openMSX should think about adding "1st - "unique" and "1st" in the featurelist" to their featurelist

I introduced it to make clear what is unique about openMSX. But when some other emu also implements the unique feature, I degrade the Unique to 1st. It shows something about if your emulator is an innovative project or just a follower.

Note that speed in percentage has been in openMSX since 2002 as well, so it can't have been 1st in blueMSX indeed
About run time insertion/removal: did NLMSX also support it at emulation run time, not emulator run time? So plugging in a cart while the MSX is on. (Just curious about this.)

Anyway, now you know the origin. If there are mistakes in unique and 1st, please let me know. I can't follow all emulator developments closely, especially if they don't run on my OS.

So, don't think too high about 1st. As I said: it's just the obsoleteness of unique.

Note that many of the uniques and 1st in those lists are for MSX emulators. You can find many of the unique features in other emus. For example the disk change feature exists in other emus as well and has done so for quite some time. blueMSX was just the first MSX emu that implemented that particular feature.

And as manuel said, the lists are not scientific lists. I made it for blueMSX based on what I know. A few people has corrected some things but its not science and if you have other comments I'll change it too.

Its more of a fun thing and both emus have quite a few 1st's and uniques which more shows that they are taking the MSX emus to a new level of accuracy and feature richness.

And I should update the blueMSX list to reflect changes in the last openMSX release.

Quote:

It shows something about if your emulator is an innovative project or just a follower.

Is it innovative to borrow cassette emulation feature ideas from C64 emulators? Is it a follower if the next MSX emulator to implement that feature also borrowed the idea from C64 emulation, and not from the other MSX emulator?

Quote:

About run time insertion/removal: did NLMSX also support it at emulation run time, not emulator run time? So plugging in a cart while the MSX is on.

Yes.

For MSX emulator terms, it might be called innovative. But in reality, most unique/1st features were probably implemented without knowing they already existed in emulators for other systems, because the authors don't run emulators for other systems

indeed. The first version of blueMSX was quite inspired by VICE. I added some VICE features that I thought was missing in MSX emus at the time. Now both blueMSX and openMSX has those features. The trainer is also inspired from other emus and I have a vague memory I've seen graphical debuggers before I did the one in blueMSX. Also, many features, like all the OPL emulation is based on code from other emus or apps.
So the uniqueness isn't that unique I guess.

But both blueMSX and openMSX have several unique features though, especially MSX specific features and both teams are working quite hard to extend the support for various MSX hw as well as making the emus more user friendly.

Ok, it's your rule.

In my eyes an emulator is an emulator, I wouldn't call a feature unique, even if it actually is among MSX emulators. For example, my NES emulator supports changing the ROM type in the open dialog, the same way it's done in blueMSX. My rule is I don't claim uniqueness or "1st", I just give credit where I got the original idea from, in this case dvik

off-topic: manuel, the openMSX featurelist looks buggy in Internet Explorer 7, the icons on the left are shifted upward.

hap: I know about some problems with smaller or larger fonts. Does changing font size make a difference (either larger or smaller)? If so, it's the same problem, if not, it's a new problem.

No. I don't know why, but if you remove the single space between those 2 spans, the problem's solved

Um, which single space do you mean?

Ok, just went through the lists and here are my comments:


openMSX
=======

* Optional automatical speed up during disk or cassette action

blueMSX have had it since the day we added more realistic timing to the floppies (since 2004). all MSX emus has fast loading so the feature should perhaps be called optional Slow disk and cas loading

* Optional automatical loading of cassettes in CAS format

* I think fMSX and others support cas files as well. some MSX emulators including blueMSX supports a couple of different cas formats.

* XML files to specify the hardware to be emulated, so you actually emulate specific MSX machines

I would say NLMSX was the first emulator that allowed real MSX machine configuration. blueMSX also has it and both NLMSX and blueMSX has text files describing the machines, although not in XML format, but thats not really a feature.

* Debug device: write data to special I/O ports and it gets logged to stdout or a file in a format you specify. Very useful if you develop MSX assembly programs in openMSX

blueMSX has support for debug writes too and has had it for quite some time. I think No$MSX has it too and they had it for a loong time.



blueMSX
=======
* Support for Sony HBI-V1 digitizer

does fMSX-S60 support the HBI-V1?

* Autodetection of emulated video sources

Not sure if openMSX has this too. The meaning is if user first uses the V9938 and then runs an app that is using a different video chip, the emulator automatically switches and displays the output of the new video chip

* Event logging, replay and AVI rendering

no longer unique. openMSX has it now as well

* Sony Playball digitized speech

no longer unique. openMSX has it now as well

* Audio capture

Some other MSX emu must have had this feature before blueMSX, like paraMSX or something, or?

* Support for the MSX Game Reader

This is clearly neither unique or 1st. MSX PLAYer was the first one to support it

* Speed setting (in percent)

as mentioned, not 1st

* Support for XML based themes which allows users to create their own look of the emulator

same comment as xml configs in openMSX. the format is really not the key feature, so in this case it should be 1st, since MSX PLAYer also supports skins.

* Debug device: write data with special Z80 instruction sequence and it gets logged to the trace window. Very useful if you develop MSX assembly programs in blueMSX

If its not unique in openMSX, I guess its not unique in blueMSX either. This debug feature is supported in asMSX though which is really handy.