David Haywood's Homepage
MAME work and other stuff
January 30, 2013 Haze Categories: General News. 6 Comments on Not a Complete Fluke

Brixian had been sitting in my todo list for a while, I knew it was an early Semicom game, released under the Cheil name, and was pretty sure the entire protection would involve the MCU copying 0x200 bytes of code to RAM, like all the 68k Semicom titles, even if this one was a Z80 based one running on Arkanoid-like hardware with a 68705 for the MCU instead of the usual 68K + Intel MCU setup.

Truth be told I’d simply never got around to doing it, and while Z80 is straightforward enough I’ve never been as fond of writing 8-bit Z80 code as 68k or other 16-bit CPUs.

Anyway, it came to my attention that ‘Zabanitu’ who has been assisting with both Grasspin and Planet Probe had a Z80 ‘fluke’ device, a replacement CPU device that can slot in where a Z80 would go on a PCB and give complete control over the system, including pausing the code and viewing / dumping the content of any ROM/RAM areas it can see. There are some caveats of using such a thing, clock speeds being the one of them, but after checking out the Brixian board we guessed it would be possible to use it with said board.

Of course such a device makes dumping the 0x200 bytes of RAM I believed the protection MCU uploaded code to very easy. Assuming my original theory was correct then using such a device on the board would make the emulation of the game completely trivial, it would be quicker than writing a trojan then typing in data to find out, and even if the theory was wrong it would give us easier debugging and testing capabilities with the board.

Unsurprisingly it turned out the theory was right, plugging in a simple dump of the main RAM into the MAME driver allowed the game to run through the attract loop in MAME, a few fixes to the input hookups (and disabling the coin lockouts) and I had a playable game.

Brixian Brixian
Brixian Brixian
Brixian Brixian
Brixian Brixian

As you might be able to see if you have your brightness on a normal setting and a decent monitor there are some garbage tiles in the black area of the playfield, these get erased / drawn as things move around and appear to be down to a bug in the game code. If you turn up the brightness on the original PCB shot provided by the Mame Italia guys you can see them present there too

Brixian Original hardware

The game as you can see is based on the Puzznic concept, it’s not quite as polished as the Taito original, but the code is an original piece of work, not a bootleg, and as a puzzle game it plays fine. The game gives you a choice of 2 ‘courses’ when you start, but the actual levels also seem randomized to a degree.


You can follow any responses to this entry through the RSS 2.0 feed.

nice! nice lookin game that, ps. puzznic i have always found to be great fun :))))

Great job as always;)
A little off topic: Is the MAME tagmap lookup cleaning over or there are still dirvers to clean? I’ve noticed some nice speedup. Are all the drivers affected? Thank you

There are still drivers to do, but I think most of the ones where it was causing noticeable performance drops have been sorted out.

It’s been overhyped a bit, in many sense it’s just winning back performance lost when things like input ports, data regions and devices moved from being indexed based to ‘tag’ based. If code to look up the devices was in the middle of tight loops then with the indexed based approach there was no performance cost at all, but with the tag system there was a very big cost; some drivers were doing that in inner-pixel drawing loops or on every read/write the CPU did causing some massive slowdowns post changeover.

It also better prepares MAME so that we can use a better way of hashing the tags in the future without risking any driver slowdown.

Do you have any gut feelings on whether the tagmap cleanup will have any performance effect on the SNES driver in MAME? That seems to be one of the drivers that is preventing people from embracing UME due to lack of performance.

OK,Haze,I think Phil Bennet can hook the black touch 96…

the main issue with SNES is once you enable the sub-cpus afaik and at that point you hit the MAME ‘fast CPUs with heavy sync’ kind of issues.

I’d also say the lack of compatibility in the driver was hurting things, we’ve got worse than bsnes performance, and significantly worse than bsnes or even zsnes compatibility.

I doubt SNES is tagmaps, I think we would have noticed a lot earlier if it was.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.