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! ;)

There was movement at the (Fremont) station...

Chris has finally started looking at the power supplies - yah!

He has asked me to estimate the core power consumption for the Cyclone V... and of course at this stage I have no idea. So my immediate task is to instantiate enough logic to fill the device and run a power estimator on it... exactly how I'm going to do this is undecided atm, since Quartus will happily optimise out all the unused logic.

One option is to instantiate a bunch of 68K processor cores and hook them up in such a way as to avoid them being optimised out. If nothing else it'll be a fun exercise to see how many I can fit in the device. I'm sure I'll come up with something in the next few days...

EDIT: Apparently I can fit 32x TG68 cores at 82% logic utilisation!