Home Page Forums MAME MAME Olivetti M20 emulation status?

Hi everybody,

I just got two M20's and was able to get one working.
The last time I checked MESS, the M20 driver froze with the "faulty CPU" sign showing on screen.
I'll get some documentation as well (although it seems that most is available on line).

I'll gladly help to find any information needed to get this driver working.

Robert

You can see the current driver here: http://git.redump.net/mess/tree/src/mess/drivers/m20.c

It says something about needing a proper Z8001 CPU core. The CPU emulation is located at: http://git.redump.net/mess/tree/src/emu/cpu/z8000/z8000.c

And says about the Z8001:

* TODO:
* - make the z8001 opcodes to be dynamic (i.e. to take segmented mode flag into account and use the non-segmented mode)
* - dissassembler doesn't work at all with the z8001

So thats likely one of the problems.

This guy P8000 emulator has created a MAME derivative with a Z8001 core that seems to address the issues you mention.

The installer comes with the sources, and the README claims that they can be distributed and changed.

It would be great if they could be incorporated into MESS.

Robert

It's based on quite ancient MAME, and he hacked in his own equivalents for a lot of things MESS provides for computers (even at that time). Plus all of his modules freely share internal state with each other (the Z8001, the driver, the video hardware, the floppy controller, they've all got their hands on each others' jocks). And there's random bits of Win32-only code sprinkled throughout the proceedings. It's still on my todo list to port the whole thing to modern MESS, but it's not a fast, easy, or pleasant task.

Ooops ;-)

One thing that puzzles me about MAME/MESS is that the "Computer" sources reside in the "drivers" directory whereas the "Components" are in "machines" ...

"machines" is a hangover from DOS 8.3. "machine components" would be a more accurate description.

Just saving that Shoutbox conversation for posterity:

R. Belmont: the issue with the M20 input ports assert is likely blowback from the input ports rewrite, it hit MESS especially hard
z8001cpg: thanks
z8001cpg: how to fix the input ports assert?
R. Belmont: I don't know, I don't have the source in front of me right now - who wrote the M20 skeleton, maybe they would know?
R. Belmont: hmm. looking at the source in the git viewer, it appears m20 doesn't have any input ports. I'm guessing that may be an edge case Aaron doesn't handle
R. Belmont: you could always try adding a bogus port and seeing if that quiets things down
AaronGiles: Lack of ports should not be fatal, but I didn't suddenly make it so (I don't think). Just add a dummy one for now.
R. Belmont: z8001: just open some other driver that does have ports defined between INPUT_PORTS_START and INPUT_PORTS_END and copy/paste them to the right place in m20.c

Ok, I found the reason for the bootstrap memory test failure.

It fails at address 0. In MESS address 0 has a mirror of the ROM BIOS which resides at segment 4 (address 0x40000).

I don't know how it works on the real machine, but on the real machine at address 0 is RAM. I think some reset circuitry does some magic, in order that the processor finds its reset vector at address 0.

To proceed I would like to mirror the ROM BIOS at address 0 as _RAM_. Is this possible? I looked at some drivers, but couldn't come up with a solution. Are these AM_RANGE, AM_MIRROR, ROM_REGION, etc. defines somewhere documented?

The easy cheat is just to copy the reset vector from ROM to RAM in the MACHINE_RESET handler.

How to handle it properly depends on how the hardware works. On m68k systems there was often a special I/O address that swapped in the RAM (e.g. the Amiga and some early Macs). Some others simply switched the RAM in automatically when the "real" address of the ROM was first accessed (most Macs are this way).

The technical manual explains how it works: