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:

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

  2. The technical reference for the V9938 (The MSX2 videochip) has some errors and the explenation of the internal commands is verry unclear on many points.
  3. 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.
  4. 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: