Here's how it could work:
null terminated command string + 3 bytes data size + data, eg.
msx1palette\0, 00 00 30, ....
If an emulator doesn't know this command, it should discard the 48 bytes data.
We could add a "supports" command too, like this:
supports msx1palette\0, 00 00 00, then read the port for an answer
@wolf_
The problem is not that the emulator would not interpret the command. The problem is that the emulator might interpret it differently than the MSX software programmer intended, or two software programmers want it to be interpreted differently. For example for palette change, one programmer might assume the new palette will be applied next frame, send the command halfway through the previous frame and would not expect to see any glitches. A second programmer might assume the new palette will be applied immediately and rely on that to do a palette split. There is no way an emulator could run both these titles with a single implementation of the palette change feature.
There are many other things that should be handled in a specification of a high-resolution palette:
- to which screen modes does it apply?
- what happens on a partial palette write? (say 8 instead of 16 entries)
- on V9938/58, do writes to the MSX2 palette overwrite the high-resolution palette entries?
- is the component order RBG (like V9938), RGB or BGR?
Another problem that could arise is that the feature might be specified in a bad way if the specification is driven only by a single new software title. The feature might be too specific for that particular software, while a slightly different specification might be useful for a lot more software. The feature might be specified in a way that is very hard to implement, while a slightly different specification might allow the same effects and be easy to implement.
@hap
That is a decent design for a super-device, but you haven't convinced me yet that a super-device would be preferable over extending existing devices and adding new devices with one purpose each.
In the case of the MSX1 palette, the first thing I wonder is why limit it to MSX1? MSX2 has a palette, but it suffers from a low r/g/b resolution, so the ability to use 32-bit palette entries would help there as well. What about setting the palette index using a new VDP register and using port 0x9E for 32-bit palette writes?
Note: 32-bit palette means ARGB; the alpha might become useful if we want Laser Disc style overlays to look good. Or overlay the output of multiple V9958-like chips.
Basically, what I'm trying to say is that I would prefer to design new features as if they are a new generation of MSX hardware, even if they were never actually implemented in hardware. With FPGA, it might even be feasible to implement them in hardware at some point, either as part of an integrated ESE-style system or as a cartridge containing an FPGA chip.
The problem with adjusting the MSX2 palette is that a game or utility can change these colors to something else, and generally the programmer has already tweaked the palette using the VDP. It's different for MSX1, where the colors are fixed, and a tad bright. An MSX1 game could benefit from a slightly modified (and often: darker) palette, and it'd be a fixed palette for the whole game.
The features wolf_ are suggesting are quite interesting. Especially useful I think is the PSG waveform, so this is certainly something to consider implementing support for.
When it comes to actual implementation I think it could be done as a new "hardware" instead, so someone comes up with a nice hardware interface, like hap suggested for the palette, and then emus can emulate the hardware.
We done so in the past, e.g. the Joyrex PSG module. Its a piece of hardware that integrates the Coleco PSG to allow us to use MSX trackers for Coleco development. Another "hardware" I've been planning to add is a GigaCartridge, which would be an ASCII cart with a second level bank switching to do either a multi game cart or make it big enough for large videos.
So for the PSG waveforms, you could make an extension to the PSG to allow it to set waveform. I think its better to do it on a per feature basis so that it stays well defined, and who knows, someone may even make a real hardware implementation of some of the features.
Screw waveforms and palettes, how about "Tell emu to insert disk 2" or "Tell emu to connect a mouse to port 1". Those are even hipper features which could be implemented with near 0% effort on the MSX side of things. They'd also make life a heck of a lot easier. I can already envision an IPS patches which would eliminate the need for endless disk swapping and running mouse cursors.
Cool stuff indeed 
@wolf_
If all you want is a fixed palette for the entire game, it could be implemented without changes to the game code. If the game is in "game.rom", put a file named "game.plt" in the same directory. The emulator can scan the directory for palette files when it inserts the game cartridge, similar to media players picking up subtitle files automatically.
@Sonic
Good ideas.
For the mouse using programs, probably a new PSG register would be useful, to which is written what type of input device that the program wants to use.
By the way, an alternative way to support this is have the emulator monitor the strobe pin. If a program is alternating the state of that pin between every read, it is trying to control a mouse. Programs reading a joystick will just leave the strobe on all the time. This algorithm might fail for paddles and JoyNet, but those are rare enough that users could just insert those devices explicitly.
For the disk switching, I'm not sure what the best option would be. Since it's about disk access, I think the cleanest way to do it is to add a new disk ROM call for this purpose or extends an existing disk ROM call. That way, the same call that controls emulators can control Nowind as well. A modified disk ROM would then write to a new FDC register to set the number of the disk to select.
We would also need a naming convention for which disk images are considered part of the disk set and which numbers are assigned to them, because it will only be compatible across emulators if we all use the same algorithm for building the disk set. For example, all disk images that have identical names except for the last character before the first dot (or just last character if file name contains no dot) would be considered part of the same set. Numbering would occur in alphabetical order, starting from 0. Both comparison and sorting would be done case insensitive.
Also here it might be possible to support some kind of auto-detection of this situation without changing anything in the game code itself. If a program attempts to read the same sector twice in succession, the second read could trigger a switch to the next disk in the set. That way, you would have to hit the "any key" a couple of times until the right disk is inserted. Might be more convenient than trying to remember which shortcut key cycles through the disk images in the set.
Tanni, indeed, what you are suggesting can be fully done with dir-as-disk.
Even if it's a little off topic, consider this from blueMSX website:
Insert Directory
Only for MSX games or applications
Allows to insert a Windows directory as Disk in drive A or drive B. This directory must contain files of a MSX game.
The emulator will build with these files a virtual disk image (including a normal MSX boot sector) and run this virtual disk image.
If you have inserted the directory in drive A and come only to MSX-BASIC, it means that there is no "AUTOEXEC.BAS" file. Search for the loader file and use the following command : RUN"GAME.LDR" (if the loader file is "GAME.LDR") and press on RETURN (the ENTER key of your PC) .
This is the Dir as Dsk feature, that works only in reading mode for security reasons : you can make changes on the virtual disk image, but these changes are not transferred to the Windows source directory.
This feature has also specific MSX limitations : no more than 112 files in a directory and you can't exceed a total size of 720 Kb (including the boot sector that will be added automatically on the virtual disk image). It can't work with MSX subdirectories and with special boot sectors.
I intended something different:
The emulated software should be able to access the file system of the host computer (the one running the emulator) without building a virtual disk with the limitation of MSX disks or dsk-files.
So the emulator would access the host file system on behalf of the the MSX software running in it. It's essential to overcome the MSX disk limitations concerning the amount of files per directory, filename format (so you should be able to have long filenames) etc. The emulated software should be able to do essentially everything you can do in the host filesystem, including creating, reading, writing, renaming and deleting files.
The MSX program could create the file variables, and selecting the operation to be performed is done by communication with the emulator similar to the normal ways of dealing with files. You even need not passing the actual data through the emulator port, just the pointer to the file variable -- and maybe its length -- and the operation to be performed. The emulator can then take the data and write it to the associated file of the host's filesystem.
This would make an emulator more useful for certain applications and more convenient to use, too.
Of course, such a feature (as every feature concerning the communication of the emulated program with the emulator) should require to be enabled, for downwards compatibility's reasons.
So an MSX program could work on very large files which wouldn't fit in a single dsk-file.
I have four files with some of them are more than 400 KB being the parts of a story. Together, they are more than 1 MB and the associated .dvi-file is over 900KB. They contain the story text in LaTeX and lot's of comments of various kinds. There are % comments for earlier versions of lines or paragraphs of the story. There are %! comments for comments why some line or paragraph got comment by %, there are %? comments reminding me for doing some ''research'' on orthography (classical, pre 1996 orthography, of cource) or other things. There may be further types of comments as well. I started to make a program where I -- besides other things -- can delete all or just certain types of comments. I want to keep the source code files and the output of that program within one directory. This should be a WINDOWS directory, so that I can use the Windows editor without extracting the relevant files form a dsk-file.
I'd go for 2 bytes with that, one for emu ID, one for version, or would you rather have multiple bytes (2,8,1), and/or a string ("blueMSX\0", "meisei\0")?
As emulation will become more and more important for every retrocomputersystem, we should reserve at least 8 or 16 ports dedicated to emulator communication purposes.
As different programming languages have different conventions about data representation, the emulator should meet the needs of the various programming languages and offer different data passing formats:
Here I'll give an exemple for strings:
- sequence of characters, $-terminated (MSXDOS)
- sequence of characters, zero-terminated (MC)
- lenght byte, sequence of characters (Pascal)
- length byte & pointer (BASIC)
You may want to pass this data at least by using a pointer to the respective data field reserved by your program or by stack.
So the interface to the emulator needs to specify the format of the data and the mechanism to pass it to the emulator or to the program.
What do other MSX Software developers think about the "hi are you an emulator?" "oh yes sir I am!", useful? useless? Chance it'd be abused? (if (is_emu) { give mean message and lock up(); }
Definitly very useful. Should have already been done!
MSX software shouldn't know about emulators at all. It will be hell if some software doesn't run on real machines or other emulators (or newer versions of the same emulator), because of some MSX code assuming emulator presence...
The one's hell is the other's heaven.
Even on the real thing there are different versions, as we all know. So a software using special MSX2 features does not work on MSX1. Do you consider that ''hell''? As long as the software is able to detect what it needs, and gives an errormessage if it's not present, it's ok. And why not take advantage of the additional possibilities that emulators offer? This will be the chance to sustain and develop the MSX system by the community, regardless whoever now owns the standard -- and obviously neglects it once more.