Contents | < Browse | Browse >
FURTHER COMMENTS: fMSX AMIGA 0.4
A Letter to AR - Hans Guijt, of fMSX Amiga
[In response to the AR 3.10 review of fMSX Amiga 0.4, the porting-author,
Hans Guijt, wrote a letter clarifying and expanding on some points,
particularly on MSX machine specifics, where my information was admittedly
[Bracketed quotes are from AR 3.10's review.]
>Everyone has their own reasons for using emulators. Some need the
>compatibility for business purposes. Some just like screwing around with
>software that would otherwise take up desk space for a separate computer.
>And then there are programs such as the Spectrum emulators and fMSX, that
>make machines that didn't quite have worldwide markets widely usable.
There is another reason as well - I believe that there are several games
available for the MSX2 (not MSX1) that make a significant addition to the
Amiga games market. I have a whole stack of Zelda-clones here (actually I
would call Zelda a Xak- or Ys-clone ;-) ) as well as a series of shoot'em
ups that really have no equivalent on the Amiga. These games are very
different from the 16/32Kb cartridges you have seen so far: Dragonslayer 6
(Legend of Heroes) comes on 4 disks, as does Wanderers from Ys, Princess
Maker comes on 8 floppies, etc. This means that both graphics and sound
are spectacularly improved over the old MSX1 games. One problem: many of
these games (especially the Zelda-clones) require knowledge of the Japanese
language. Oh, and I still have to make them work as well...
My HD is filled with games. 1500 Spectrum games, 150 MSX games, 40 PC
games (the Infocom collection) and even a few Amiga games!
>The MSX OS has a copyright date of 1983 (so you'd better hope MicroSoft
>doesn't beat down your door for it), and while I don't have the machine's
>specs handy, it seems to have pixel resolution similar to the Spectrum, but
>with a greater availability of colors (16, I believe.) To run, the
That's correct. There is a list of specs in the docs, in the section
called 'about MSX'. The restriction for screen 2 (the screenmode used for
most MSX1 games) is that 8 consecutive pixels can only have two colors.
This differs from the Spectrum where a whole 8*8 block can only have two
colors (just like some new AAA modes!). And of course there are sprites,
which the Spectrum does not have.
The MSX2 ROMs boot in screen 6. This is a 512*212 screen with 4 colors.
In v0.4 this is the only supported MSX2 screenmode, with very minimal
support as well. No sprites, no vertical scroll, etc. Normally the MSX
logo would scroll smoothly upwards rather than drop down in three big
>software requires an 020+ and OS 3.0 or above, although the author is open
>to consideration of support for 2.04 and above (but 68000 is out of the
>question, for speed reasons)
It will be easy enough to go through the code searching for v39 calls, and
I have no way to test my work as I don't know a single person with v36 and
68020+. This is one of the primary reasons for the current situation,
although I admit that memory pools helped a lot as well ;-) .
The reason for the 68020+ requirement is that I need many of the special
68020+ instructions and addressing modes. Especially the bitfield
instructions proved invaluable when doing MSX emulation (these are only
available with 68020 and upwards).
>So, why bother? Well, there are an awful lot of games available.
>Certainly nothing of epic proportions, but sometimes it's nice to just kick
>back and play a round of Konami Ping-Pong and take one's mind off of the
>"AAA vs. 3DRISC" question. The system is multitasking, so you can leave
>Ping-Pong running in case you're hit with a stress panic over AAA vs.
>3DRISC after a grueling session on Usenet or IRC. This has happened to me
>more than once.
The big problem with support for the bigger games is the way memory is laid
out inside the MSX. It works like this:
The z80 can address only 64Kb of memory. This 64Kb is split into four
pages of 16Kb. A page can be switched into any of four slots. Thus,
standard memory looks like this:
SLOT: | 0 1 2 3
0x0000-0x3FFF | BIOS reserved reserved RAM EXAMPLE
0x4000-0x7FFF | BASIC1 for for RAM SETUP
0x8000-0xBFFF | (empty) cartridges cartridges RAM
0xC000-0xFFFF | (empty) RAM
Currently the emulation works with a 64Kb RAM buffer. This has several
disadvantages: every time a page is switched a 16Kb block is copied to (and
possibly from) the buffer; and every write must be monitored to make sure
that ROM isn't accidentally overwritten.
This is the reason why MSX2 basic takes such an incredibly long time to
start: the MSX2 ROMs bankswitch over 9000 times during the boot sequence,
and copying all that memory takes a long time.
I am working on a new version of the CPU emulation that does away with the
64Kb buffer. This has the big disadvantage that every memory read or write
must go through a translation sequence (causing slowdown) but there is no
more need for ROM protection or block copying (causing speedup). Naturally
I am hoping to get more speedup than slowdown!
A big problem is that the new CPU emulation is *very* complicated.
Currently I have not been able to get it up and running, despite the fact
that I have been working on it for several weeks. My greatest success so
far is actually getting it to compile! To complicate matters further I
have included several optimizations (which would also have worked in the
old code), most notably delayed calculation of the H flag, the bane of all
So, this is a short timeline of what to expect in the future:
Disk emulation requires MSX2 basic to be running (at least for my version
of the disk ROMs). However, MSX2 basic really needs the new CPU emulation
for speed. So, expect to see the new CPU first, better MSX2 support and
diskbasic next. In the meantime I'll do interim releases like v0.5 just to
keep things going and remove bugs.
With the new CPU emulation it will be easy (and totally free in terms of
performance) to add support for the so-called memory mapper. This device
allows an extra measure of bankswitching to be added to the MSX, so that a
maximum of 256 16Kb blocks can be controlled in one slot.
Unfortunately this still does not mean that the MegaROMs from the web page
can be played, as these require yet another kind of bankswitching: expanded
slots. Fortunately almost every MegaROM out there has been revised to use
the memory mapper instead of expanded slots (a more common term would be
'hacked' ;-) ), so this is only a minor problem.
You will have noticed that by now I have support for two layers of
bankswitching: slots and memory mapping. Why not add support for the third
layer as well (expanded slots)? The answer lies in the hardware
implementation of these techniques. Slots and the memory mapper are
controlled through Z80 OUT instructions; these can easily be trapped by the
emulation. However, expanded slots are controlled by writing to certain
memory addresses, and checking *every single write* means a lot of overhead
and a great deal of slowdown.
Note that the UNIX version does this regardless of the effect. This is
Marat's choice; he can count on 100MHz RISC monsters, while I am aiming for
something like a1200+fastram if at all possible.
In due time I will need to rewrite the disk ROMs, in order to interface
directly to the Amiga, probably through mfm.device although I am open to
suggestions (I am looking into fms.device as well so that people can keep
MSX disk images on their HD's).
Because I am currently sick of the CPU emulation, and because I think too
much time has passed since the last release, I decided to stick some new
stuff into the v0.4 code. I wanted to make a hardware hitting video
emulation for some time now (it is possible to use the copper to control
the blitter which automatically redraws the screen every frame, but I see
no method of doing this inside the normal intuition screen context.
Instead I build my own display with my own copperlist, and so far
everything works fine even though it isn't quite finished.) I will release
v0.5 once I have this running, and if I have time I may add some extra MSX2
screenmodes (these are quite easy if I leave out some features like
sprites). Of course the use of the MSX2 screenmodes is limited when you
have no games to run on them.
Other new stuff in v0.5:
- There was a bug in v0.4 that caused the emulation to run a lot
slower than necessary. Fixed.
- A simple change to the bankswitching code caused some speedup,
especially notable when starting with MSX2 ROMs.
- If one of the libraries could not be opened the general shut-down
routines would still call functions from that library. Fixed.
- No longer hangs when it cannot allocate soundchannels.
>What sort of speed do you get? Well...the author of the Amiga version
>claims that his 030/25 machine is just short of 100%. Based on my
>experiences on an 040/25 machine, I'm not so sure-then again, I've never
>seen a real MSX machine. I know that by playing with the included timing
>settings (only two sliders that can be changed while running the emulator),
>very nice speeds can be achieved on an 040/25. On the 030, well, I'd
>rather use the 040, but it is tolerable to a point.
And you are right, v0.4 is a lot slower than v0.3 (in which I did the
timing). The reason is that I placed an important buffer in CHIP ram, in
preparation for the new video-update scheme. I made sure that the user
could not access the new 'features' (which leads to hard crashes unless you
know *exactly* what you are doing) but I forgot to take out the MEMF_CHIP.
>Promised for future support are MSX disks and the MSX2 specification, which
>I presume includes MegaROMs.
As stated, only hacked MegaROMs.
>I've always admitted it-I'm someone that enjoys using emulators, so fMSX is
>a goldmine for me. For others, who need a good reason to use them, I point
>to the dozens (if not hundreds) of games readily available for diversion.
>Some 8-bit classics are even available, including Loderunner, Raid on
>Bungling Bay, Pastfinder, and Thexder. It's worth a look.
My internet connection is a 14k4 line, and I pay for every hour I use it,
but once I have something uploaded I can send it to lots of people for
free. For this reason I have a list of users that will automatically get a
new version once it is available. To get on (or off) the list all you need
to do is send mail to
stating what you want. Also welcome: talk about MSX/fMSX, bug reports,
verbal encouragement, suggestions, etc.