Eye catcher, and possible emulation?

I noticed during development that the so-called eye-catcher graphics (the spinning NEO-GEO graphics and SNK logo) had completely random tiles on my Donkey Kong demo. This piqued my curiosity so I decided to look into how it is actually rendered.

The standard eye-catcher graphic

Turns out that the animated graphics can be either rendered by the BIOS, or the game itself (or not at all), depending on a flag set in the cartridge header. Either way, the actual tile data must be supplied by the cartridge - there is no graphic data in the BIOS itself!

The official documentation mentions as much, but doesn't give a lot of detail on exactly what is required. So I did some more digging in the BIOS disassembly, together with some experimentation with my demo. I discovered that the spinning logo is - not surprisingly - rendered as a series of sprites, and it uses a bank of (somewhat less than 256) tiles whose MSB is read from the cartridge header. As for the remaining text and copyright symbol; these are rendered from the FIX layer ROM on the cartridge and comprises various tiles interspersed with the more commonly-used ASCII characters.

So in order to clean-up my demo, I injected 256 sprite tiles from Baseball Starts Professional (surprisingly, NGH-001 - aka, NAM-1975 - renders its own eye-catcher) and set my cartridge header appropriately. Then I simply replaced the entire FIX ROM with that from the same and viola - a nice clean eye-catcher animation! Nothing exciting, but at least it's one more mystery solved for me.

In the mean-time I've been slowly plodding through the Donkey Kong disassembly, since the version I received - whilst extremely helpful - isn't quite as complete as I'd like. And since I'm using IDAPro to produce a Z80 source file as a starting point (I'd like to re-assemble it at a different address and see if it still runs in MAME), I'd like to ensure that it's as complete as possible since once I start adding 68K code to it, there's no going back.

It is a daunting task but I can see how, in some cases, a brute force approach - for some areas of the code - is sufficient. And that's no doubt what has happened with the 6809 conversion. But perfectly valid, obviously, as it runs beautifully on the Coco!

However, I'm starting to wonder whether an emulation might actually be possible on the Neo Geo. No doubt it would have to be hand-crafted in 68K assembler, as compiled C-code is just not going to cut the mustard on a 12MHz 68K. But maybe, just maybe, an assembler core with hand-patched graphics routines will do the job!?! I'm not sure, but I'm hoping to find out, as I'm now aware of possibly two (2) Z80 cores written in 68K assembler; one in a TRS-80 emulator on the Amiga, and another (yet to be confirmed) on a WIP Phoenix emulator on the Neo Geo.

A Z80 core would make life a little easier for sure, and open up the possibility for more arcade ports on the Neo Geo. Or maybe a TRS-80 emulator for it??? ;)

Neo Kong - rendered

I've managed to put together a C program to render the Donkey Kong tilemap on the Neo Geo display, with the correct palette!

I started with the Neo Thunder source code, and after a hiccup with displaying sprites, I've got some rather hastily hacked-together source code that does the job. The stumbling blocks were defining palettes and tilemaps in the source code, as opposed to having the graphics tools create them for you automatically. But the upshot is, once everything is setup properly, the entire screen can be rendered as a single sprite.

The demo has two (2) modes of display; one shows 1:1 pixels and can be scrolled up/down to see the entire screen, the other scales the screen to the Neo Geo display. It looks a little less than awesome, but it's still playable. It should be possible to tweak the sprite graphics to have it looking as good as Sockmaster's Donkey Kong on the Coco, as in theory the scaling algorithm is deterministic and well documented.

Scaled display on the Neo Geo under MAME

Note that there will have to be some algorithm for scaling Donkey Kong sprite positions on the display. Or I could cheat and define 16 versions of each sprite (there's plenty of ROM space), and build maps that are scaled in the same way that the background is. Either way, I think that this is good enough to prove at least that Donkey Kong is viable on the Neo Geo.

Next step is to actually start on the port which will, of course, be 100% assembler.

Neo Runner?

After looking at the sprite scaling specifications yesterday, I've realised that the 10-pixel tile height of Lode Runner wouldn't be an issue at all on the Neo Geo! So a port may still be on the cards...

In the meantime, my first attempt at generating Neo Geo sprites for Donkey Kong were - recognisable - if not perfect. Hopefully at lunchtime today I'll get time to clean them up and load them into MAME...

EDIT: I've fixed the graphics and filled JoyJoy (aka Puzzled) with the tilemap from Donkey Kong. Unfortunately, the MAME graphics display <F4> does not work with Neo Geo emulation, so here's a snapshot of the game running:

Next step is to write some Neo Geo code to render a sample screen, and play around with sprite control...

Neo Kong

I managed to start on the program to convert Donkey Kong graphics to Neo Geo sprite format.

I've got the ripped arcade graphics - tiles and sprites - displaying on the screen. I'm also using the the real palette (CLUT 0) to display the tiles:

Next step is to convert them to Neo Geo MVS Sprite ROM format. I'll upscale the 8x8 tiles to 16x16. I'll also produce two versions of the arcade sprites; 16x16 and upscaled to 32x32. The latter will enable me to apply the same scaling to the tile characters as the sprite characters, if required.

Then I'll load the new sprite ROM's into one of the Neo Geo games and see if I can make out the sprites on the screen.

Any port in a storm?

To complement my BIOS disassembly, I had an idea to port an existing arcade/computer game to the NeoGeo. Ordinarily I would be tempted to emulate, but I don't think a 12MHz 68K is going to be powerful enough to emulate even a lowly 2MHz Z80.

What I had in mind rather was taking a simple arcade game, for which I had a fairly comprehensive disassembly, and then more-or-less translate it line-for-line into 68K assembler for the Neo Geo. This is exactly what Sockmaster has done for the arcade Donkey Kong on the TRS-80 Color Computer, and it's a very, very impressive piece of work too!

The disassemblies I have include (arcade) Space Invaders (Z80), (arcade) Tutankham (6809), (arcade) Donkey Kong (Z80) and (MSX) Lode Runner (Z80). Unfortunately both Space Invaders and Tutankham run on bit-mapped hardware, which the Neo Geo is incapable of supporting. That leaves the tilemap/sprite-based hardware of Donkey Kong and Lode Runner.

The FIX layer on the Neo Geo is, unfortunately, the top-layer graphic and as a result can't be used for background tilemaps. This leaves the system sprites to be used for all tilemap/sprite graphics. The Neo Geo has sprites in bucket-loads, but unfortunately they're all 16x16 pixels. Donkey Kong is 8x8 and Lode Runner is 8x10 - making it all-but-impossible to use Neo Geo sprites and still get a full-screen display.

One option is to scale 8x8 tiles to 16x16 and either use a scrolling half-screen display, or scale the sprites by 50%, as the Neo Geo has hardware sprite scaling. That's OK for Donkey Kong but not for Lode Runner with its 8x10 tiles.

So right now I need to find a candidate horizontal arcade game that I'm actually interested in with either 8x8 or 16x16 tiles and/or sprites and that can be disassembled relatively quickly/easily. But nothing is coming to mind atm...

EDIT: I've just had a brainwave!

The idea is to render the Donkey Kong tilemap in 16x16 tiles (by pixel-doubling each tile) and then have the hardware scale to the visible area of the screen. It should be possible to render the entire tilemap as a single sprite, using column sprites and chaining.

Anyway, I'd like to get a proof-of-concept up and running, by rendering a sample playfield from Donkey Kong on the Neo Geo screen. This is itself will be an interesting exercise...

From the ashes.

Real Life time demands are still preventing me from working on the hardware atm.

However I have been somewhat motivated since I recently discovered the existence of the Neopen BIOS project! With the UNIBIOS project and now this, there's evidently a few people floating around that are quite familiar with the Neo Geo BIOS; something that I think will be useful - if not required - when I get into the thick of HDL emulation of the system. It would also be cool to be able to contribute to the Neopen BIOS project!

To this end, I've started my own disassembly of the Neo Geo BIOS. Or rather the US 6-slot version - SP-E.SP1 - to be exact. Obviously I'm covering ground well-trodden by others, but the idea is to really learn about the system internals, and there's no better way than to reverse-engineer it yourself!

I'm no stranger to disassembling to reverse-engineer hardware platforms either, having all-but-completely commented Space Invaders (Z80), Tutankham (6809) and MSX Lode Runner (Z80). As for 68K, I've done a bit of work on Namco Classics Vol.1 whilst writing the MAME driver. These aside, I've also had to dig into dozens of arcade games and micro computer BIOS'es whilst attempting to emulate them in an FPGA.

The other good thing about it is that it's something I can pick up and work on whenever I've got a spare 20 minutes or so, whether it be at work or at home. So hopefully I can keep trucking along and also keep motivated about getting the hardware off the ground!

Still showing signs of life

It would seem that my colleague Chris has more interesting things on his plate than designing power supplies for NGPACE, despite his previous pledges of assistance.

The good news is that another colleague has stepped up to the plate, and registered interest in lending a hand. Hopefully this means the ball will start rolling again, and we can get to the business end of the circuit design. I've suggested he look at the power supplies as well as the analogue audio and video circuitry, which just about covers the schematic capture except for the FPGA pin assignment; something best left until layout.

I'm about to take 5 weeks (well-deserved) leave so I won't be around to shake the stick or contribute anything other than answering questions about the design, but I'm hoping my colleague - who should have some spare time up his sleeve in the next few weeks - gets onto a roll with this!

Perhaps a good sign - he modified the 14" CRT chassis in the recently refurbished office arcade cabinet to better suit the 19" monitor that is installed, and we subsequently rotated the monitor back to horizontal so I could install a Neo Geo MVS board and a Metal Slug cartridge. That should get him into the mood! ;)