Category Archives: MAME

Pixel perfect

AKA emulating vintage displays on modern machines. I know i’m super late to the party, but that is life as they say. As you may be aware, when it comes to emulation, sometimes it simply is too perfect.

Mame 0.144 Galaxy Force II

Just look at how utterly pixel perfect it is. The thing is back in the 1980’s LCD screens were amber only with 4 shades of amber at best. Everyone else had CRT’s, and arcade machines sure were all about the CRT. But now we live in a future where CRT’s are not only expensive and rare, but it’s easier to emulate the look and feel, although today I’m looking at shaders, I’m sure at some point there will be a Physics emulation of a CRT, but not yet.

Retro Arch & CRT Shaders

So I’m using RetroArch, as it supports a vast number of both video and audio plugins, and shaders, but more importantly you can stack them to get a more intracte look to take a pixel perfect version like above, and then translate it onto how it may have looked on an aging black & white TV set:

Black and White

Or evena colour CRT look and feel:

Custom CRT

While reading on the libretro forum, I found this great package that includes the following easy presets:

480p: Nice shader suitable for 480p content like Dreamcast games

Component: High-quality signal look but not overly sharp like RGB

B&W TV: Pretty self explanatory

Vintage TV: This looks really good with low-res pixel games on systems like the Atari 2600

Vintage LCD: Looks like an early gen LCD screen complete with ghosting

Composite: Simulating a typical cheap CRT using composite cables

S-video: Much the same but better quality video signal

RGB-Shadowmask: This is more akin to a high quality CRT with RGB/SCART cables

RGB-Scanlines: Like the previous but with thick bold scanlines like you’d find on a Sony PVM or other broadcast quality monitor, nice and bright

I would HIGHLY advise using the nightly builds of RetroArch, as I had really poor performance when using some of these stacked shaders that may go as many as 12 deep, however nightly had no issues at all. It does without saying that you’ll really want a powerful machine to do this kind of thing with a real GPU. This flies in the face of the ARM stuff, but as they say that’s life.

I don’t have the youtube privleges to upload super high video, so this ended up looking like a smudgy mess, and I captured it with that Windows 10 “Game DVR”, which really isn’t that great, it clipped the bottom, and captured the menu bar.

But it got the basic job done.

If you have the CPU/GPU power, and want a more all around better looking emulation experence, I’d HIGHLY recommend it. If anything it’ll remind you why CRT’s certainly may have had awesome refresh rates, but really terrible resolutions.

While I was looking for System16 stuff, I found the first version of MAME to include the UAE 68000 core starting in release MAME 28, although System16 emulation itself didn’t appear until MAME 33b3, but not playable until MAME 33b4.

So what does it mean? Well at the time the UAE core was the way to go. However from looking at the MAME source, the UAE core that they were using from System16 was already generated, while UAE still included the build68k program to parse the tables, and generate the 68000. Instead they were editing the outputted C. UAE wasn’t GPL until version 0.7(something), 0.7.6 for sure, so I don’t know why they weren’t using it from the source.

Eventually starting in MAME 35b2, the core was replaced with MUSASHI , so Among their reasons for dumping the early UAE CPU core was this laundry list:

New 68000 C core. For testing purposes, this is also being used in the DOS
version instead of the asm core. [Karl Stenerud]
Differences:

1. Faster. This code is, barring ram fetch time, almost twice as fast as the
existing C core in MAME. I’ve done extensive speed profiling on both
engines. The only problem now is the slow memory access in MAME due to
bankswitching et al.

2. Emulation more correct. I found many bugs in the MAME engine (and many,
many more in mine for that matter) when I pitted them head-to-head.
I have run random instructions from each opcode class at least 10 million
times, comparing the resultant CPU states, and have left it running random
instructions for 1 billion iterations. In every case, I have adhered to
the specs defined in M68000PM/AD REV. 1.

3. Disassembler is correct. The current M68000 disassembler in mame has a
tendency to disassemble instructions that have an invalid EA mode.

4. Cycle counting is 99.9% correct. The only instructions which don’t have
correct cycle counts are divs, divu, muls, mulu, and they’re not worth
counting correctly. (I’m not about to waste emulation time counting 0-1 and
1-0 sequences).

5. > 32 bit friendly. I’ve taken care to ensure maximum portability without
sacrificing speed. The result is conditional compiling dependant on your
architecture. I’ve also implemented and tested a compatible solution for
architectures that lack 8, 16, or 32 bit signed storage types.

6. The code is carefully laid out to be readable.

Also in MAME 35b4 added in was emulation of the NEC uPD7759 chip for speech, fleshing out the System16 emulation.

To compile these ancient versions, and inbetween I was using my Candadian cross DJGPP GCC 4.12 Win32 cross compiler. For Allegro I’ve always found it builds far easier using GCC 2.7.2.1, a vintage compiler from back in the day I could just run in DOSBox.

Alien Syndrome

Obviously with today’s machines, these ancient versions of MAME run fine on DOSBox! It’s really amazing in the scope of emulators running emulators.

A long long time ago, back when I got a Pentium 100 the wonderful world of emulation was really starting to be possible with such a high powered CPU. First was the simple Game Boy emulators, then a Commodore 64 emulator, the incredible Amiga Emulator, the beginnings of SIMH (back when it was only a PDP-11 emulator), and then I found the SEGA emulator, System 16.

It was really cool being able to play 16bit arcade games on the desktop, although rather slowly. From there everyone knows the rise of MAME. But while looking around for a small 68000 C compiler, I came across the source code to an older version of System 16, 0.53 on archive.org. Naturally it’s for MS-DOS, as was everything back in the day. Also slightly interesting is the 68000 emulation, written by Bernd Schmitd of UAE fame. So for the heck of it, I set about getting Thierry Lescot’s System 16 building again. I’ve never used allegro before, so it was a bit of a fight to get a version of it to actually build. It turns out that I should have been building version 2.11 with tools of that era (why on earth was I using GCC 4, and binutils 2.18?) and instead stick with GCC 2.7.2.2 and some much older binutils. And in no time I had build the library, and it’s examples. With that done, I was able to re-build System 16 with GCC 4.1.2 and get a binary!

Back in the day, I actually did have an Altered Beast arcade board. Sadly it died in a move, someone near and dear just saw the PCB as “garbage” and tossed it. Sigh, but I did have ROM dumps, as I did a refresh of it forever ago. Anyways I still have the ROM files, so I guess that is nice.

Anyways I fired up the emulator and got what is known as the “jail bar” effect, which is from a bad ROM.

Corrupt tiles

Notice the sprites

The System 16 splits it’s memory into a program space, a sprite memory bank, a tile memory bank, and RAM for stack and things like the palette. As you can see the program is certainly running, and the sprites are good. I did some poking around a bit later, and noticed that due to a logic bug, the texture ROMs are actually never loaded!

So a quick patch, and now we get Altered Beast up and running!

Altered Beast title screen

demo play

Well, now isn’t that great!

Not that I would imagine anyone would really care, I mean MAME is a thing, and even from the readme:

Altered Beast : No sound emulation

So it’s pretty quiet. Additionally the source is pretty restrictive:

These sources can’t be used for commercial purpose, any new version of the
emulator done with these sources must specify my name somewhere on the screen
et docs and I must be informed about any new release of the emulator.

This is follow up to a previously posted challenge to virtualize VenturComm Venix/86 so that it can be run on a modern machine under an emulator. The competition was a huge success and the rest of this post is an entry by the winner – Jim Carpenter. Enjoy!

Create a new hard drive image with “chdman createhd -chs 615,4,17 -c none -o hd.chd“. This is only 20MB. You can certainly use larger drives but make them a standard type, something that is a defined drive type in the BIOS. I’d stay away from user defined types.

Start the emulator, configure the first floppy drive to be DD and the second to be HD. Restart so it takes effect. Attach XFER.IMG to the first floppy and your hard drive image to the hard drive. Restart again. (Venix uses the BIOS for *everything*. So if you attach without rebooting, chances are the BIOS missed your hard drive which means Venix won’t see it either.)

Go into the BIOS and configured the floppy and hard disk types. The command above creates a type 2 drive:Save and exit and let it reboot.

Milanovic tells Gamasutra. “Our aim is to help legal license owners in distributing their games based on MAME platform, and to make MAME become a learning tool for developers working on development boards.”

So I guess they want to do android and embedded Linux stuff?

Does anyone know anything more concrete?

It does sound exciting, especially for MAME’s chipset emulation which, let’s face it is superior, and being able to plug them into other emulators that are ‘good enough’ or even different purpose than full system emulation is a good thing.

Also from other sources, I hear that MAME/MESS are to be fully merged, and will be shipped simply as a single executable called MAME.