A Description of the Mac emulation in MESS
Moderators: Cat_7, Ronald P. Regensburg
A Description of the Mac emulation in MESS
Here's a long description of MESS posted over on the 68kmla forum. Very informative:
"MESS has the same goal as MAME, which is to emulate as accurately as possible *the hardware* of a given computer or video game system. This goal is fundamentally incompatible with the philosophy of emulators such as BasiliskII (and to a slightly lesser extent, vMac) which use "hacks" to simplify the emulator or increase performance.
Essentially what the MESS/MAME people do is reverse engineer the behavior of the integrated circuits which make up computer systems and virtually put them together into complete "machines". This makes the MESS/MAME code base a great resource for authors working on their own emulators, since many of the ICs that exist in MAME/MESS are found in machines from multiple manufacturers and MESS/MAME's code might provide better insight in the working of the chips than even the original data sheets might. However, unless a given emulator is similarly built to emulate the "hardware" of a machine rather than the "behavior" it's less easy to import a complete emulator back *into* MESS.
Comparing vMac to the MESS driver is instructive. Essentially vMac emulates a 68k CPU, a hunk of RAM, and just enough hardware stubs to trick the ROM into booting. The ROM itself is patched so it no longer attempts to access the hardware disk controller, and instead transacts all disk I/O through a driver which links directly to a system able to handle virtual disk images of arbitrary sizes. By contrast, MESS's mac.c emulator assembles a complete virtual Macintosh from a library of IC definitions, some of which work more completely then others, and then boots a completely unmodified ROM. Which means that MESS has to emulate the IWM controller well enough to fool the ROM into thinking it's getting data from real 400/800k disks, it has to emulate enough of the NEC SCSI controller to allow the system to believe it has a real hard drive attached, etc, etc.
Anyway, the end result is that MESS burns a lot more CPU than vMac and is clunkier and far less friendly to use. However it *does* emulate a "real Macintosh", not simply a "Macintosh-like environment" which depends on ROM patches. Of course, last I checked MESS still couldn't boot System 7 because of unresolved issues with various individual components, but... someday, perhaps, it will be able to run things that vMac or BasiliskII won't be able to. A/UX on the MacII/SE 30 emulation, for instance. You just can't hold your breath. If there's any one thing true about MESS it's that the "bigger" the machine the longer it takes for reverse engineering to take place. They've pretty much nailed most 8-bit platforms you can think of, but beyond that things tend to be perpetually "in progress". Things "could" be better... after all, MAME is much further along in supporting 16/32 bit game platforms, but that can largely be attributed to greater developer/public interest in arcade vs. computer emulation. A lot more people want to play "Metal Slug" than care about running obscure bare-metal OSes from twenty years ago."
http://68kmla.org/forums/viewtopic.php?f=2&t=14242
"MESS has the same goal as MAME, which is to emulate as accurately as possible *the hardware* of a given computer or video game system. This goal is fundamentally incompatible with the philosophy of emulators such as BasiliskII (and to a slightly lesser extent, vMac) which use "hacks" to simplify the emulator or increase performance.
Essentially what the MESS/MAME people do is reverse engineer the behavior of the integrated circuits which make up computer systems and virtually put them together into complete "machines". This makes the MESS/MAME code base a great resource for authors working on their own emulators, since many of the ICs that exist in MAME/MESS are found in machines from multiple manufacturers and MESS/MAME's code might provide better insight in the working of the chips than even the original data sheets might. However, unless a given emulator is similarly built to emulate the "hardware" of a machine rather than the "behavior" it's less easy to import a complete emulator back *into* MESS.
Comparing vMac to the MESS driver is instructive. Essentially vMac emulates a 68k CPU, a hunk of RAM, and just enough hardware stubs to trick the ROM into booting. The ROM itself is patched so it no longer attempts to access the hardware disk controller, and instead transacts all disk I/O through a driver which links directly to a system able to handle virtual disk images of arbitrary sizes. By contrast, MESS's mac.c emulator assembles a complete virtual Macintosh from a library of IC definitions, some of which work more completely then others, and then boots a completely unmodified ROM. Which means that MESS has to emulate the IWM controller well enough to fool the ROM into thinking it's getting data from real 400/800k disks, it has to emulate enough of the NEC SCSI controller to allow the system to believe it has a real hard drive attached, etc, etc.
Anyway, the end result is that MESS burns a lot more CPU than vMac and is clunkier and far less friendly to use. However it *does* emulate a "real Macintosh", not simply a "Macintosh-like environment" which depends on ROM patches. Of course, last I checked MESS still couldn't boot System 7 because of unresolved issues with various individual components, but... someday, perhaps, it will be able to run things that vMac or BasiliskII won't be able to. A/UX on the MacII/SE 30 emulation, for instance. You just can't hold your breath. If there's any one thing true about MESS it's that the "bigger" the machine the longer it takes for reverse engineering to take place. They've pretty much nailed most 8-bit platforms you can think of, but beyond that things tend to be perpetually "in progress". Things "could" be better... after all, MAME is much further along in supporting 16/32 bit game platforms, but that can largely be attributed to greater developer/public interest in arcade vs. computer emulation. A lot more people want to play "Metal Slug" than care about running obscure bare-metal OSes from twenty years ago."
http://68kmla.org/forums/viewtopic.php?f=2&t=14242
.hd
Hi ClockWise,
that sounds interesting. Do you know how the .hd files for MESS should be created?
Did you manage to run the LC emulation?
Best wishes!
that sounds interesting. Do you know how the .hd files for MESS should be created?
Did you manage to run the LC emulation?
Best wishes!
24bit,
I haven't done it yet myself (soon), but does this guide help:
http://mamedev.emulab.it/etabeta/?p=155
It has some info about the .hd files I think.
I haven't done it yet myself (soon), but does this guide help:
http://mamedev.emulab.it/etabeta/?p=155
It has some info about the .hd files I think.
I got permission to use that quote as the basis for a wiki article:
http://emaculation.com/doku.php/mess
Some day I might try to write some setup notes of our own for the wiki.
http://emaculation.com/doku.php/mess
Some day I might try to write some setup notes of our own for the wiki.
OK
Pretty discriptive, but I seem to miss the DOS commands like CHDMAN and even MESS, don't know why.
I'll take a look at the downloadable files.
Anyway one needs PATIENCE to run a Mac emulation with MESS.
Best wishes!
I'll take a look at the downloadable files.
Anyway one needs PATIENCE to run a Mac emulation with MESS.
Best wishes!
Re: A Description of the Mac emulation in MESS
I thought I'd try to clarify how Mini vMac operates, if anyone is interested.
Mini vMac is somewhere in between Basilisk II and MESS. It is true that the floppy disk drive hardware isn't emulated at all, with the ROM patched to replace the driver. But other hardware is emulated, as needed for specific Macintosh software to run. There is fairly detailed emulation of parts of the VIA, and the RTC. There is very limited emulation of the SCC, just enough to emulate it when nothing is attached to the port. The same ought to apply to SCSI, but work needs to be done there.
When software tries something that hasn't been emulated yet, an error message is displayed. This is done, instead of trying to implement everything to start with, not just because of laziness and lack of time. I feel that code that hasn't been tested isn't worth much. So instead of having an emulated program reach code that hasn't been tried before, and just mysteriously misbehave because the emulation isn't quite right, it will indicate what needs to implemented. If after implementing that area, the emulated program still doesn't work, then you know the problem is likely to be in the area you just implemented.
This is less of an issue for the MESS emulator, because it emulates multiple computers. If one emulated computer doesn't use part of the emulated hardware, another emulated computer may. The trade off is that emulating multiple computers is of course far more work.
I believe that is more a reasonable description of how Basilisk II operates. No other hardware is emulated, and the the ROM is patched so as not to try to use the hardware. This gives reasonable compatibility and efficiency. But less than perfect compatibility.Essentially vMac emulates a 68k CPU, a hunk of RAM, and just enough hardware stubs to trick the ROM into booting.
Mini vMac is somewhere in between Basilisk II and MESS. It is true that the floppy disk drive hardware isn't emulated at all, with the ROM patched to replace the driver. But other hardware is emulated, as needed for specific Macintosh software to run. There is fairly detailed emulation of parts of the VIA, and the RTC. There is very limited emulation of the SCC, just enough to emulate it when nothing is attached to the port. The same ought to apply to SCSI, but work needs to be done there.
When software tries something that hasn't been emulated yet, an error message is displayed. This is done, instead of trying to implement everything to start with, not just because of laziness and lack of time. I feel that code that hasn't been tested isn't worth much. So instead of having an emulated program reach code that hasn't been tried before, and just mysteriously misbehave because the emulation isn't quite right, it will indicate what needs to implemented. If after implementing that area, the emulated program still doesn't work, then you know the problem is likely to be in the area you just implemented.
This is less of an issue for the MESS emulator, because it emulates multiple computers. If one emulated computer doesn't use part of the emulated hardware, another emulated computer may. The trade off is that emulating multiple computers is of course far more work.
MESS now can boot the Mac IIci in addition to the earlier Mac IIs. This required implementing a lot more of the MMU (notably the translation cache), and the "RBV" on-board video chip is also emulated (I need to add a config option for which monitor is connected - right now it defaults to the 640x480 13" RGB). This gets us into 32-bit clean land and thus wider application compatibility (and hopefully System 7.6, but since it's not available for free that's harder to test).
These changes will land in SVN later today for bleeding-edge types. Otherwise wait for the 0.140 release.
These changes will land in SVN later today for bleeding-edge types. Otherwise wait for the 0.140 release.
Hi,
I compiled Mess on OSX, but somehow it refuses to understand my mess.ini file or command line. The rompath looks OK with -showconfig, but Mess says it can't find the files it requires (listing 3 rom/bin files) for ./mess maciix. All files mentioned are taken from http://psy.trapd00r.se/dump/MESS/
What to do?
Best,
Cat_7
I compiled Mess on OSX, but somehow it refuses to understand my mess.ini file or command line. The rompath looks OK with -showconfig, but Mess says it can't find the files it requires (listing 3 rom/bin files) for ./mess maciix. All files mentioned are taken from http://psy.trapd00r.se/dump/MESS/
What to do?
Best,
Cat_7
Does this help?
http://mamedev.emulab.it/etabeta/?p=155
It is the go-to guide for the Mac part of MESS.
http://mamedev.emulab.it/etabeta/?p=155
It is the go-to guide for the Mac part of MESS.
When that guide was written, 800k floppies didn't work with the IIcx driver. That's now been fixed, so you don't need to use the Plus driver to install if you don't want to.
You can get blank formatted Mac harddisk images for MESS in several sizes here:
http://depositfiles.com/en/files/0praijrpa
That helps cut out some of the steps.
You can get blank formatted Mac harddisk images for MESS in several sizes here:
http://depositfiles.com/en/files/0praijrpa
That helps cut out some of the steps.
Hi,
It seems the svn repository I downloaded yesterday didn't contain the new maciicx files yet. The current repository doesn't build, due to some error in firefox.c
Compiling src/mame/drivers/firefox.c...
src/mame/drivers/firefox.c: In function ‘void nvram_w(address_space*, offs_t, UINT8)’:
src/mame/drivers/firefox.c:354: error: ‘x2212_write’ was not declared in this scope
src/mame/drivers/firefox.c: In function ‘UINT8 nvram_r(address_space*, offs_t)’:
src/mame/drivers/firefox.c:360: error: ‘x2212_read’ was not declared in this scope
src/mame/drivers/firefox.c: In function ‘void novram_recall_w(address_space*, offs_t, UINT8)’:
src/mame/drivers/firefox.c:365: error: ‘x2212_array_recall’ was not declared in this scope
src/mame/drivers/firefox.c: In function ‘void novram_store_w(address_space*, offs_t, UINT8)’:
src/mame/drivers/firefox.c:371: error: ‘x2212_store’ was not declared in this scope
make: *** [obj/sdl/mame/mame/drivers/firefox.o] Error 1
I will try at a later moment.
Best,
Cat_7
It seems the svn repository I downloaded yesterday didn't contain the new maciicx files yet. The current repository doesn't build, due to some error in firefox.c
Compiling src/mame/drivers/firefox.c...
src/mame/drivers/firefox.c: In function ‘void nvram_w(address_space*, offs_t, UINT8)’:
src/mame/drivers/firefox.c:354: error: ‘x2212_write’ was not declared in this scope
src/mame/drivers/firefox.c: In function ‘UINT8 nvram_r(address_space*, offs_t)’:
src/mame/drivers/firefox.c:360: error: ‘x2212_read’ was not declared in this scope
src/mame/drivers/firefox.c: In function ‘void novram_recall_w(address_space*, offs_t, UINT8)’:
src/mame/drivers/firefox.c:365: error: ‘x2212_array_recall’ was not declared in this scope
src/mame/drivers/firefox.c: In function ‘void novram_store_w(address_space*, offs_t, UINT8)’:
src/mame/drivers/firefox.c:371: error: ‘x2212_store’ was not declared in this scope
make: *** [obj/sdl/mame/mame/drivers/firefox.o] Error 1
I will try at a later moment.
Best,
Cat_7
Oops,
I remember making that change in the makefile, but not in the recent outtake from SVN. My bad....
The Maciicx emulation now seems to work. But I can't find a working floppy image. I see a happy mac for a split second and then the rasterops image appear and have an ? mark mac.
I tried with 4 different boot floppy images.
ps: the link to the blank mess HD images doesn't work.
Best,
Cat_7
I remember making that change in the makefile, but not in the recent outtake from SVN. My bad....
The Maciicx emulation now seems to work. But I can't find a working floppy image. I see a happy mac for a split second and then the rasterops image appear and have an ? mark mac.
I tried with 4 different boot floppy images.
ps: the link to the blank mess HD images doesn't work.
Best,
Cat_7
We're working on posting a selection of blank HDDs on the MESS wiki now ( http://mess.redump.net/ ).
Regarding the floppy drive, I've seen some issues as well. One of my top testers indicates that the IIcx with default RAM size works for them, but they get problems in other configurations (see http://www.bannister.org/forums/ubbthre ... #Post64749 ). When in doubt you might try the "old reliable" Mac Plus driver - you can install a universal System on the Plus and then boot the HDD image on the IIcx and IIci.
Regarding the floppy drive, I've seen some issues as well. One of my top testers indicates that the IIcx with default RAM size works for them, but they get problems in other configurations (see http://www.bannister.org/forums/ubbthre ... #Post64749 ). When in doubt you might try the "old reliable" Mac Plus driver - you can install a universal System on the Plus and then boot the HDD image on the IIcx and IIci.
As a bit of an update, I recently had good luck improving the Apple Sound Chip emulation so e.g. SoundTrecker now plays music flawlessly on MESS's Mac IIcx support, and games generally work well too (although I suck at Crystal Quest). Sound is less happy in the IIci emulation because of the different semantics in the RBV chip, but it's being worked on. vMac should be able to fix their remaining ASC issues looking at how I did it, hopefully.
The IIci emulation now lets you pick which of the 3 supported Apple monitors are connected (12" RGB, 13" RGB, or 15" Portrait Display).
Gryphel wrote me a working Egret/Caboose/Cuda dumper (he's awesome, if nobody's mentioned it lately) and we're now collecting dumps of the various versions of each of those chips (I think there's only one Caboose version). This will enable emulation of the remaining 68030 desktop Macs as well as the 040s and even 601s eventually.
The IIci emulation now lets you pick which of the 3 supported Apple monitors are connected (12" RGB, 13" RGB, or 15" Portrait Display).
Gryphel wrote me a working Egret/Caboose/Cuda dumper (he's awesome, if nobody's mentioned it lately) and we're now collecting dumps of the various versions of each of those chips (I think there's only one Caboose version). This will enable emulation of the remaining 68030 desktop Macs as well as the 040s and even 601s eventually.
Wow! That's the most encouraging Macintosh emulation news for a long time, IMHO.Arbee wrote:Gryphel wrote me a working Egret/Caboose/Cuda dumper (he's awesome, if nobody's mentioned it lately) and we're now collecting dumps of the various versions of each of those chips (I think there's only one Caboose version). This will enable emulation of the remaining 68030 desktop Macs as well as the 040s and even 601s eventually.
-
- Apple Corer
- Posts: 203
- Joined: Thu Oct 16, 2008 10:09 pm
- Location: Canada
- Contact:
Ambassador: The license is GPL incompatible, but the projects have very different coding styles and structures anyway so it's unlikely code would be easy to share. Most contributors (myself included) do dual-license stuff on request - DOSBox is using our 3Dfx emulation, and one of the MSX emulators uses a sound chip emulation I wrote, among other things. And of course there's nothing illegal about my looking at the vMac code or Gryphel looking at mine if no copy/pasting occurs.
Incidentally, the IIcx support is now pretty good for Mac II software needing color/sound (ie, games). It's not perfect, but it's getting there.
Quadra 700 will probably be the next unique model supported (including '040 support and thus OS 8 ), unless I can figure out why the Portable/PB100 hate me. CD-ROM support is also in progress, and SWIM/FDHD looms on the todo list as well.
Incidentally, the IIcx support is now pretty good for Mac II software needing color/sound (ie, games). It's not perfect, but it's getting there.
Quadra 700 will probably be the next unique model supported (including '040 support and thus OS 8 ), unless I can figure out why the Portable/PB100 hate me. CD-ROM support is also in progress, and SWIM/FDHD looms on the todo list as well.
-
- Apple Corer
- Posts: 203
- Joined: Thu Oct 16, 2008 10:09 pm
- Location: Canada
- Contact:
@Arbee: Ah, thanks for clearing that up.
Would it be reasonable to think that the relationship between M.E.S.S. and Basilisk II will be similar to Bochs and QEMU/VirtualBox/etc.? I.E., an emulator with a greater emphasis on precise hardware emulation?Indeed that IS some very encouraging news! We're well on our way to a Basilisk II replacement/substitute!