Emulation

An angel or a devil in disguisse ?

I like emulators. Most of the time I use them without any moral objections.
If you are interested in some CD covers I once made for some rom collections you can follow this link
However I would recommend everybody to read the EmuFAQ. You can find a local copy here if the official isn't available for the moment.

I would however like to add my comments on them from my MSX-point of view.

Emulating an MSX

Everybody in the Dutch/Belgium MSX scene does know the point of view of the former MCCM publisher Wammes Witkop regarding copying. He is very clear about this : NO COPYING WHITOUT PERMISION . For all who have read the EmuFAQ by now, will probably agree that the fact of emulating itself isn't illegal but the copyrighted roms are problematic. The MSX part of the story is verry ambigous.

A big problem for us MSX nowadays is braking hardware. A lot of "Critical Components" in the current MSX machines are inreplacible. Ofcourse if we talk about computers the entire world imediatly thinks about the CPU. And yes, the Z80 of MSX1, MSX2 and MSX2+ machines is still to be found in the shops. Heck it still is the most used 8 bits CPU in the world. The big problems are however the MSX-ENGINE, the controlling chip who regulates the communication between CPU, memory and VDP. This is a custom chip who isn't used in any other device. The VDP is a Yamaha chip that also isn't produced anymore. So if you're MSX breaks and you don't have an other spare somewhere stocked away... So for a lot of people (Hi Patrick Van Der Veken) emulation is the only way to re-experience some of there old games.

The problem is that for an emulation of an MSX you not need to emulate all it's parts (this seems to be completely legal), but the hardware itself is useless without the thing that makes a MSX a real MSX compatible computer. The MSX standard describes BIOS calls and some hardware levels that have to be respected (and used) in order to be an MSX. The hardware is emulated, however there is no free BIOS nor free implementation of the MSX-BASIC (Copyrighted by Microsoft). So for the emulation of an MSX we have only the hardware(emulation) but not the software at our disposel. I'm pretty sure that MS doesn't care anymore for the 16Kb rom they once made. And probably Sony, Philips and the other compagny's are probably forgotten that they have even written a BIOS for there once produced MSX machines.However, remember the GIF affair ? No ? In short, there once was this firm who had the copyright on the compression algoritm used in GIF pictures. GIF was widly spread and suddenly this firm starts charging money from all other compagnies who make programs to produce images in the GIF format. So the some could happen once one starts to spread the ROMimages of the bios or the MSX-BASIC. Nintendo and Sega also do persuit ROM sites who contain their old, out of stock and we don't earn anything whit them anymore productions

There isn't any complete MSX emulator out there neither. Emulating old arcades in an emulator like MAME is in comparison relatively easy. Such devices have a very specific reason-d-etre. The hardware serves one purpose, that one game. There is in most cases no need to emulate the hardware in its full detail. The arcade machines are commercial things so the programmers use the specs of the hardware as guidelines for what can be done and what shouldn't be done. So writting an emulator in such case can be considered complete once the chips are implemented in a fully spec-compliant way.
Emulating a MSX could also be done on such a spec-compliant way, and hec, the most emulators out there can be considered to be written this way. However there are some problems with this approach:

The specs for some of the hardware are verry unclear or even contain errors.

In old arcades you have one active component (CPU) and the rest is rather passif circuitery. Or the other actif components have a rather limited function, like an extra CPU who only handles background music. And to make it easy to program they are build using the master/slave prinicipal.
The games ever hardly ever scratch the bare bones metal of the hardware, meaning that most of the time the hardware is more powerfull than the game itself requires. MSX products however have the tendencie to get the last droplet of performance out of the hardware meaning that timing between CPU and VDP has become rather important in order to asure a correct working of the program. Especially demos suffer from bad emulation. A lot of them have been written using the strategy: "If it works it's fine"

The specs thing is clear I suppose. There are many things in the MSX that are used way beond their specs. A lot of the more professional home-made soft uses all the trics in the book too get that extra bit of performance out of the hardware. Well known tricks include the illegal instructions of the Z80. talking to the high and lowbytes of the IX and IY registers is possible and often done. The specs state that you can only use these registers as full 16 bits registers.Or the infamous IN F,(C), an instruction that was a logical gap in the official instructionset. Because they were so much used they became official in the R800 !!! An other often used trick involved the fact that one officially had to write 2 values to the MSX-Music chip to set the kind of waveform one wanted to obain from it. Fact is however that with just writing one value one could obtain a sound that was inbetween the official spec values, and a lot of people actually liked this extra sounds.

The biggest emulation problem however is due to the workings of the Video Display Processor. The VDP is a rather slow processor and is a false multitasker. The MSX is one of those machines were the CPU doesn't have access to the video ram. The ramchips used for the VDP are directly attached to the VDP and every comunication between CPU and VRAM has to be done be ordering the VDP to read or write values from or to the VRAM. Luckily the VDP has some internal commands to copy large arreas of memory whitout the intervienance of the VDP. So the MSX programmer could tell the VDP to copy the for example rectangle starting at (22,45) and width 120, height 100 to destination (45,312). The VDP would use its spare time to execute this instructions, this spare time is the time that the VDP isn't actually composing the output signal or preparing itself for the next line by checking the data for its hardware sprites. The specs say to write all the values for the commands into the register of the VDP and than controlling a bit in the statusregister of the vdp to see if the command has ended. Most emulators therefore execute the VDP command directly on the moment that the execute command is written to the VDP. The real VDP however needed some time to move the actuall data around. So most emulator will have a superVDP but most scrolllers and other homemade (demo-)software use this VDP delay to control the speed of the program. A scroltext that needs to copied can use +/- 1/50ste of a second (the time of one screenrefresh of your television). After this the program waits for the vertical retrace and voila, a steady scrolltext. In the superfast emulator however this scroll will zoom by at the speed of light, now the copy doesn't take (emulated) time and during the fake horizontal retrace the scrolltext can be updatet a hundred times because of the superVDP. Most games don't suffer this fate, they don't use such a bare bones tactics.
Another thing is the screensplit. A screensplit is the trick of changing important VDP registers during the actual display of the screen. Using this technique one could change the screenmode, the display page, colors etc. to be affiched on screen.this was done by the fact that the VDP could signal the CPU when it started at a given line. You write into register 15 at which line the Horizontal Line Interrupt had to be set and when the VDP reached that line you could write the new registerdata into the registers, thus influencing the way the VDP build up the rest of the screen.Games usually just use one screensplit so that they displayed a static part with status info and the actual gaming arrea. Demos and diskmagazines use more screensplits, one could eassily rewrite register 15 several times during the build of the screen. Some demo's even go as far as to change the values during the buildup of a line itself instead of changing things inbetween lines. The Unknown Reality demo of NOP waits for the horizontal retrace and starts executing Z80 commands. After a given amount of instructions one can eassily calculate the time that passed, so at that time the vdp is somewhere coding the signal for the monitor in the middle of a horizontal line. The NOP programmers at that point change the VDP registers and the VDP while build up the second half of the line using the alternated parameters. And voila, a horizontal screensplit. This time critical operations are not yet implemented in an emulator.

When emulating a MSX Turbo-R there is even the fact that a hardware circuit pauzes the CPU so that you can't do two out instructions to the VDP with at least a pause of 8 milliseconds.

The most MSX emulators are build to play the older and more standardly programmed games. So the arcade emulator approach pays of and one can enjoy the older games again. However for the demo-lovers out there you will still need to use a real MSX if you want to see the things that were (and are) done on those lovely old machines

And since the CPU is responsible for everything in the MSX I didn't even mention the fact of hanging music during disk-access (interrupts are dissabled because all time is needed to read the floppydrive, so the music data isn't update in time making the tone last too long.), Or how about emulating the fact that one could write to fast to the CPU, or the known hardware bugs and/or shortcomings in the VDP. Things like the three-line-garbage-screensplit come to mind, or the sprite-data-has-to-be-set-at-least-four-lines-before-display-height rule. Remember that I called the VDP a false multitasker because it uses it's free time to execute his commands ? Disabeling the hardware sprites causes the VDP to have more time (no look-a-head and build sprites-on-screen-data is needed anymore), thus making the VDP commands execute faster. Sometimes demo's use this trick to gain aditional speed. The sprites are disabled for most of the time and are enabled with a screen split a few lines above the actual display region and are again disabled after the sprite region has passed. The official specs dont mention any timings for these kind of low level operations so the emulatorprogrammer is in for a hell of a job.

My list whish list for the perfect MSX emulator is verry big:

Emulation of MSX-music chip
In a first stage this would be on the well known I/O port level. So this would mean to emulate only the chip. In a later stage this could be extended to the memory mapped I/O that is used in the Panasonic FM-PAC. Even the locking bit should be emulated. I don't know if there is a program out there that uses the tick to have 2 MSX-music chips produce two different tunes, but since it is possible on the real thing, why not try to emulate it (since we want the perfect emulator...)
Emulation of the MSX-Audio chip
First the FM/AM module could be made, this would be most usefull to have alread decent music in most 'Dutch' games. Later on the ADPCM samples can be included. Since the best known device that included the MSX-Audio chip is the Philips Music Module, it should also be nice if the keyboard input could be emulated.
Emulation of Turbo-R
Enhancing the the instructionset of the Z80 with the extra commando's of the R800 is eassy. Emulating the timing becomes more difficult since the R800 is faster if the high byte of the address bus doesn't change.
The Z80 emulation uses already a pointer to the registerset so having two seperate register sets, one for the Z80 and one for the R800, should be eassy.
Emulation of V9958
Not only should the tree extra register be implemented, but also the correct chip-id must be said in the status register. If you really want to push it, you could try to emulate the behaviuor of pin8 also. For more info on these vdp register go have a look at Alex Wulms pages
Emulation of an IDE or SCSI controller
It should be verry nice to be able to emulate an HD connected to the MSX emulator. I suppose this would be best done using a large imagefile containing the HD contents, since MSX can't handle the filesystems used on the more common HD's now a days (MSX uses 12 bits FAT even on his HD's)
Correct emulation of the floppy controler
Most emulators patch the DISK rom with illegal instructions. If the emulated Z80tries to execute these instructions it will cause an error, you could call it an illegal instruction opcode error, and since the emulator knows what illegal opcode caused this; it knows which real disk read/write operation to perform and continues the emulation. If your program however talks directly to FDD controller this won't work and the program will not work. NOP used this approach to make its NOP Real Motion Player disks. So they can not be emulated.
Improved emulation of the V9938
Alex Wulms alread did a great job with his VDPCommandEngine1.0. At least the commands take up some (emulated) time now, but it still isn't perfect enough for most demo's.
Configurable I/O ports
In most MSX emulators the I/O ports are fixed. Some, like #A8, are indeed fixed in the MSX standard, others like the often used #98-#9B aren't officialy fixed. If the I/O's are dynamicly adjusted when you launch the emulator this would make it possible to emulate an MSX1 with the MSX2 extension carttridge, or the fameous SUNRISE(GENIC?) multitasking MSX2 with two VDP chips(Every VDP should have it's own window ofcourse). Also having a dynamicly created I/O port list in the memory woiuld faciliate configurable MSX set ups, one containing for example a Philips Music Module (having the I/O ports for the MSX-Audio chip) and one without.
Configuration files containing info about memory layout
Most emulators let you specify the size of the MSX Memmory Mapper, but few of them let you say things like: I want a 512 kB mapper in slot 1-0 and a 1024 kB mapper in slot 1-2, my SCC (memory mapped I/O)is connected to slot 2-0 and my FM-PAC is in slot 2-1. The FM-PAC is something special because of it's SRAM and the earlier mentioned locking of the MSX-music chip. Also the program extension for the MSX music basic commands is normally in the same port as the entire FM-PAC.

Luckely for the most Belgium/Dutch people when MCCM printed their last number they included a beautifull present for their loual abonnees. Two CD's filled with software for which they had written permission. They even succeeded in obtaining permission of Philps, Sony, Microsoft, Konami and others to include ROM dumps of their products, so those people have a legal copy of the roms needed for their emulator.