Neo Kong the Movie

Firstly I wanted to know how far off the mark I was with getting the tilemap rendered every frame. So I started rendering only part of the screen and it turns out it was only missing the mark by a few lines of tiles. In fact, if I had reduced the width from 32 to the visible 28, it would have scraped in. But I wanted more headroom than that; separating the rotated and non-rotated rendering routines was the obvious start. There were also a few other very simple, very obvious optimisations.

I've no easy way to profile the rendering code that I'm running, so the next best thing is to count instructions. The original, unoptimised tilemap render routine took 20,818 instructions per frame. After the above-mentioned simple optimisations, that's now down to 11,571, an almost 50% reduction. More than enough to continue with development without further ado.

After fixing one last bug - the sprite colour for an animated Mario - I've captured a small video of the Neo Geo boot-up and straight into the game-play, with Mario running back-and-forth along the bottom girder. Even the sprite priorities are correct, as you see him run behind the oil barrel.

And so from here-on in, I'll be adding code to allow Mario to traverse the entire girder level - including jumping of course - until he can reach Pauline waiting at the top. And although I've already encountered code specifically for the girder level, I suspect when it's all said and done, I'll be able to manoeuvre Mario around all of the 4 different levels.

Slowdown

OK, so I now at least know the cause of the slowdown - the tilemap render code that is running every VBLANK (and re-renders the entire tilemap every frame), in conjunction with the sprite render code that is running every VBLANK, in conjunction with the Donkey Kong code that is running every VBLANK - takes more than 16.7ms to run!

If I eliminate the tilemap render code, it runs at the correct speed.

The tilemap render code was always a quick 'n' dirty solution; something that would ultimately be replaced by code that directly writes to the Neo Geo 'tilemap' via macros. It was also written with absolutely no regard to speed optimisation, and one option I have in the short term is to try to speed up the code just enough to get past this issue atm. I think I will have a quick go at it (I can immediately see several ways to improve it), but if it fails without too much effort I'll just bite the bullet and implement the macros that I'm using for somewhere between 50-75% of tilemap accesses. The rest I'll have to hunt down and replace with the macros one-by-one.

There was movement at the... errr... building site

In a nutshell, Mario runs left and right now.

The areas in the other listings that tend to be completely devoid of any analysis are the 'mechanics' of game-play, such as animations - and the animation of Mario himself is certainly no exception. Tonight I managed to decode the basic left-right animation logic and now Mario can run back-and-forth along the bottom girder, and even changes height correctly.

The sprite animation logic is - interesting - to put it mildly. For some inexplicable reason, rather than a simple look-up table, animation sequences are represented by bit pairs packed into hard-coded bytes strewn amongst the code and look-up requires loops of rotations, masks, compares and register copies. The same routine also (reportedly) handles barrel sprite animation (that have their own animation cell sequences) just to further complicate matters. Hmm...

Also, it's not noticeable during game-play but Mario actually 'slides' for 2 frames between sprite changes when moving left/right.

I also tried to fix the 'slow' speed, without luck, so everything is running about 50% atm. Once I find the reason and a fix for it, I'll upload a short video of Mario running across the screen.

Your name in lights

Still trying to find 10 minutes here and there to work on the port. Managed to get name registration done, although I had to hack the score handling for the moment due to the fact that you can't actually score any points - so ignore that aspect for now...

You can also start a 2-player game and it runs right through to the end game for both now. Still a few minor issues to sort, like player 2 shows the wrong height on the "How high can you climb" screen, and those pesky ladder tops, but I'm getting closer to the point where there's only game-play code that remains to be ported.

I suspect the next few weeks won't be conducive to spending any significant amount of time on Neo Kong. I've got a week up the coast coming up but will probably leave the laptop at home in favour of the tablet and drinking with my cousin!

On a different but perhaps related note; I scored the Mega Pack for my Neo Geo X for Xmas, and I'm pretty happy that I can now play Blue's Journey on it! That'll be going up the coast with me for when my wife is playing Scrabble on her tablet! Maybe one day I'll jailbreak it and be able to play Neo Kong on it!

Just Silly

Despite the fact that we're fast approaching the silly season, time to spend on 'silly' pursuits seems to be getting harder to find, not easier. And so in my spare 10 minutes here and there I'm still chipping away at the port...

And despite the fact that I had intentions of finishing off the non-gameplay sections of the code, I found myself looking for the code that ticks down the bonus timer. Interestingly, the timer on the barrel/girder level is handled differently and is inter-twined with the barrel deployment timers. Eventually I quickly gave up on that as I'm not ready to dive into that area of the code, but at least now I have the bonus timer ticking down... albeit it too quickly on the 1st level.

Bonus timer displayed and ticking down

And putting off the less interesting bits yet again, I wanted to see if I could make Mario at least move without much effort. But alas, although now it detects left/right movement and updates the sprite, the code to adjust the coordinates was too convoluted with too many unknown variables to hack quickly.

At least I have a starting point for the game-play, but for now I'll return to the high score update and name registration screens. Then I'll do one final audit of the non-gameplay code and then I can start to make the game playable!

Wading through the boring bits

Not a lot to show for it, but I've been plugging away at lunchtime again. Mario's death spin is fully animated now, and I'm slowly working my way through the sundry routines that get called during game initialisation and/or clean-up, or from the main loop. This includes the various timers and housekeeping routines that don't affect much on the display. I've still got some scoring and bonus routines to do, and the high score name registration screen. Probably a few more days before I can get into the actual game-play.

In the process of Mario's death spin I had to implement sprite flipx (I had only implemented flipy previously). That comprised about 5 extra instructions. I had previously re-ordered the sprites, thinking there'd be gaps in the sprite memory map for unused sprites, but there's a only a few. Trouble is, Mario's death routine wipes a lot of the sprite objects en masse, so I reverted all the sprites to their original indices; not too painful because I use macros to address them.

I also fixed a bug in the initialisation routines that were clobbering variables that shouldn't have been clobbered; and I haven't seen the START crash since. Fingers crossed that was the source of the issue...

Interestingly, the non-Neo Geo portion of the 68K code/data is $2B1C bytes now. Although I am optimising some of the code slightly, I suspect the end result will exceed the 16KB of the Z80 ROM. I'm loathe to estimate the percentage of code I have ported at this point, but I'm hoping by now I've hit the 50% mark. And FWIW the Neo Geo PRG ROM for Neo Kong is $3888 - a few bytes short of KOF2003!

Introductions are in order

Despite the lack of updates on this blog, I've been plugging away at Neo Kong at every opportunity.
 
I jumped the gun a bit on the game-play; I thought I'd fast-track the game initialisation and get into the actual game, but it turns out that there's too much logic dependent on the initialisation. So I stepped back and ported all the initialisation routines properly. And then I realised that I had forgotten altogether about the introduction screens...

Coin-up and watch the intro screens

So now you can coin up, start a game, watch the intro, and when the game is over (I set Mario to die immediately) it returns to the attract mode loop. All that is missing outside the game-play now is the high score registration routine - which I'll probably finish off next just to get it out of the way. Once that's complete, it should mean that the only code remaining is in-game game-play code.

I do have one intermittent bug; occasionally the Neo Geo will reset when you start a game. I suspect it's an issue with a register having non-zero high-order bits due to BIOS routines where I have forgotten to zero them first - I've already made that mistake a few times. I'll track it down at some point when it starts to get too annoying.

Although I do 99% of my testing under MAME running un-throttled, I have noticed that the game runs too slow when it is throttled. I guess that's not too surprising, given that I'm rendering the entire tilemap, plus 64 sprites, plus calling the BIOS handler every VBLANK. At some point I'll do some further analysis but right now I suspect every 2nd VBLANK is being missed and it's running at half-speed. Not an issue atm since there's plenty of display optimisation to be done.

I've also been thinking ahead about what bells 'n' whistles might be nice. I'll add a (soft) dipswitch setting to select either US/Japanese level sequence. I guess I should also look at supporting loading and saving of high scores.

Coins and dipswitches

Some more integration into Neo Geo, bugfixes and tidy-ups tonight.

I got curious about the soft dipswitches on the Neo Geo; now the Donkey Kong dipswitches are all implemented on the Neo Geo. I've replaced the cabinet upright/cocktail switch with a horizontal/vertical switch that controls the screen rotation.

I got thrown for a while because the game name wouldn't appear correctly on the setup screen. After scratching my head for a while before relenting and tracing through BIOS calls, I discovered that it is read from the backup RAM, not the dipswitch settings table in ROM! And because I had run Neo Kong previously with garbage in the table, it had saved a rubbish game name in the backup RAM (everything is keyed from the NGH number in the ROM header). Deleting the saveram file and running it again fixed the issue.

I also fixed the coin-up issue, which was a bug in the 68K port; comes from reading Z80 instructions which are <dest>,<src> and translating to 68K which is <src>,<dest>. Not the first time I've made that mistake, and it won't be the last. So I can coin-up and start a 1P or 2P game (which I've now hooked up to the actual START buttons on the Neo Geo)...

...which brings me to another Z80 Donkey Kong bug. The routine to detect 1P and 2P start buttons stores a mask in the B register, depending on whether there is one or more credits. Then the routine periodically prints the 'PRESS 1P or 2P START' message, depending on a timer value, before reading the hardware and testing the input against the mask. The bug is that if the messages are displayed, then the B register is not preserved, and is always set to 0. It doesn't matter, because invariably the button is detected on the next loop, and the message not displayed and it all works.

This in turn resulted in a related but different bug on the 68K port; the mask register wasn't being set to 0, but 0xff - meaning that pressing 2P start with only 1 credit was being accepted. Anyway, all fixed on the 68K port now.

Next session I can well and truly get into the game-play code. First order of business will be getting Mario to move on the 1st level. But I have a feeling that I won't get the opportunity tomorrow, so it'll have to wait a few days...

Do you want to play a game?

Lunchtime progress: can insert (only 1) coin and select START1P.

Not sure if the issue with it accepting only a single coin is a Neo Geo issue or a Donkey Kong porting issue. Either way, it's likely a trivial problem (I always regret saying that!)

For now I've hooked the START1P to Neo Geo BUTTONC, only because after the experience I had with the coin-ups it was always going to be quicker and easier. I'll look at what's required to hook it up properly tonight if I get the opportunity.

But the big news is - it's now executing the main game-play loop!!!

Right now I've got the loop executing the attract mode initialisation - just to see something happening - but I've also verified it in the MAME debugger. And at this point, the attract mode and game-play modes merge again, so I can test either.

But first, I've got bills to pay...

Coins and housekeeping

Last night I did a few tidy-ups; reviewed (again) any missing functionality in the execution path thus far and found a small routine that 'fixes' the moving ladders on the 2nd (cement pie) level. Still a few sundry items and sprites which I'm yet to port, but they don't seem too important atm. And for some reason, the ladder-tops have appeared again on the title screen (although the transition from demo mode to title screen is a hack atm, so I'm not too fussed).

I also decided to code the coin-up logic, and found that the Neo Geo does things very differently to other arcade games. All the title, demo, credit and start functions are handled by the BIOS. I had to fill in a few missing vector functions in the cartridge header, and also had to set the USER_MODE variable in the system work area before I could get the coin-up function working, but now I can add a credit (not sure yet how this will translate to the non-MVS platforms). That's still WIP so you can't actually start a game yet.

I also took a quick look through the rest of the code, in particular the game-play loop. It all looks fairly straight-forward, and I should be able to get Mario moving about without having to worry about porting the rest of the game logic. There's quite a bit of crank-the-handle type porting to be done, which might be a little tedious but shouldn't throw up any surprises and will hopefully be straightforward to test as I go.

 But first, I'd like to be able to start a game.

Neo Kong is not Donkey Kong

Just playing around, since 'DONKEY' contains the letters 'N', 'E' & 'O':

Now I really have to get back to work...

4 on the floor.

Managed to find the bug in the rivet level. The dangers of local labels and unfinished code...

The game's data structures are starting to become a little clearer now. Aside from the expected jumble of timers, temporary and sundry variables there's a table of objects @$6400 to the end of memory. This table keeps track of objects like fireballs, springs, elevators, hammers, barrels, etc - basically anything that moves or can be interacted with. Everything's also nicely aligned; objects are either 16 or 32 bytes depending on how much data is required to store their state.

I've also found what appear to be two bugs in the level initialisation code!

In the 2nd (cement pie) level there's a call to the routine that initialises the spring sprites from the elevator level. The sprites themselves are located off-screen so there's no visible side-effects, but none-the-less there's no reason it should be called.

In the 3rd (elevator) level the code that initialises the elevators appears to have a bug. The code to initialise the 6 elevator objects instead uses two nested loops to overwrite a byte (with the same value) in the first 3 objects twice, instead of looping through all 6. It looks like the code used to use a different value for the 4th-6th objects and was quickly patched... either way there's still a bug as the start address is initialised inside the outer loop. I don't know (yet) what this byte represents, so I don't know the effects of the bug.

So now the real fun begins!

Elevators and crashes.

Tonight I got the 3rd (elevator) level finished:

But the problem now is that the 4th (rivet) level is crashing, and for some reason I can't work out exactly where it's going wrong, or the reason (eg. BUS ERROR) for the crash. A trace shows it crashing in the middle of drawing ladder segments, but removing that logic still causes a crash. Thus far crashes have been caused by misaligned word/long reads, or word operands with only the lower byte initialised, and they've been relatively easy to fix, as the bug is invariably in code I've just added. But this one is totally unexpected, in code that was running yesterday!

It's very, very annoying and it's going to have to wait until tomorrow now.

Two down, two to go!

The results from lunchtime today:

As well as completing the initialisation routines for the 1st two levels, I've also fixed the background and sprite placements for the rotated mode. In rotated mode, there's absolutely no scaling (or clipping, on MAME at least) required so for an MVS board in a vertical cabinet, Neo Kong will be a pixel-perfect clone of Donkey Kong!

Thus far, Donkey Kong is using 41 sprites. I don't think there's many more sprites to be added, so I'd be surprised if it tops 64 of the 96 total that gets DMA'd to the registers.

The remaining two levels should be straightforward, as they'll mostly use routines that have already been ported. So I'll finish those off (possibly tonight) before things will start to get really interesting!

Hammer time!

Again, weekends aren't the most conducive to working on Neo Kong, but I have managed to get the hammers coded up.

Ignore the sprite offsets, I'll fix them soon!

Perhaps a little more work than you'd expect just to display two hammers, but now we're getting into the meat of the code; objects (such as hammers) are represented by 14-byte data structures which are initialised in several stages from different data sources.

I've been doing my own reverse-engineering at this point because thus far I've encountered a few minor errors in the other disassemblies and have been thrown a little off course by them. I should note here that you can't really fault them - it's one thing to comment a disassembly and another thing altogether to actually re-write every single instruction for another CPU! It takes me a little more time but I guess it's worth the independent verification- though it's not something I'll need to do for every instruction as once the data structures are identified, the rest of the code should fall out quite easily.

And this is way too premature, but I've also been thinking of my next porting project... and I think I've got a candidate that is perhaps a better fit to the Neo Geo than Donkey Kong.

Even more spritely!

Not a lot of time on the weekends, but a little more progress..

Fixed a bug in the tilemap render routine that was cutting off the top row when rotated. Now you see the 1UP and HIGH SCORE text, which was absent from the last screenshot. Oh and the sprites aren't scaled yet, so the placement was never going to be right, but they're approximate atm.

I've been working on the level/game-play initialisation routine, which as you can imagine is not trivial. The background renders are done, as I mentioned, in a generic routine with a 2nd level-specific routine. Then all the game-play data is initialised, including sprite positions. Here each level has its own sprite initialisation routine as well, which is where Kong's barrels, the oil barrel and hammers (not ported yet) are done. You might also notice a couple of errant ladder tiles at the top of the screen are now missing - for some unknown reason black sprites are used to cover them!?!

I'll probably spend the time now and complete all the sprite routines for the other levels, since they are tightly coupled to other in-game data structures like the fireball locations. Then at least I can see all screens in their entirety and maybe even at least start to run them in attract mode. So Mario will have to wait a little longer before he can run!

There's life, Jim!

The wife went out for dinner so I got to play some more. Still haven't sorted the sprite placement properly, but in rotated mode, at least these look right with fudge factors.

Attract mode, Kong, Pauline & Mario

I've skipped the code to draw level-specific sprites (oil barrel etc), so I'll probably go back now and do that. Maybe, just maybe, it won't be too long before Mario moves!?!

Let there be sprites! And when X=Y...

I've got the 1st sprites showing in Donkey Kong - Kong himself on the title page.

Now with added sprites - albeit in the wrong location

You will, no doubt, notice that the sprites are not in the right location - more about that later...

But first, after hooking up the palette to the sprites, I discovered that the bitplanes were reversed in the Donkey Kong sprite ROM's w.r.t. the tilemap ROM's... something that may simply be a 'bug' in MAME as the ROM's are organised in the driver arbitrarily to some extent. Either way, a simple fix to my conversion tool and I was up-and-running with correct colours just a minute or so later.

In the process I fixed a bug (which was disabled anyway) in my tilemap rendering routine and did a few minor optimisations. I'm still not convinced that a complete rendering of both tilemap and sprites every VBLANK is going to cut it on the final version, but gee it'd be nice - very nice - if it did!

So, about those sprite locations; stepping back a bit the whole X-Y issue has been somewhat clouded from the beginning, given that the display on the Donkey Kong cabinet is rotated 90 degrees. I've referred to coordinates as 'X' & 'Y' and also referred to 'rows' and 'columns' throughout my commented disassembly and, to be honest, I'm not sure I haven't been inconsistent in some areas. And whilst it's easier to think about Mario's X coordinate changing as he runs across a girder, it is in fact his sprite's Y coordinate that is changing in the hardware. And of course, a row of text spanning multiple columns is actually a single column of text on the display spanning multiple rows. So what convention do you choose, and how do you make it clear? My brain started hurting right about now.

So when mapping all this to the Neo Geo hardware, it complicates the issue. And to make matters (much) worse - at least where sprites are concerned - it's not a nice 0-N range on one/both axes on either hardware platform! The sprite rendering code in MAME, for example, looks like a veritable dog's breakfast, somehow involving the current scan line! Arrggh! And of course, supporting both orientations means I have to solve the problem twice. If my brain was hurting before, it's throbbing now!

As a result, thus far I've managed to place the sprites somewhere on the screen for now.

To be honest, I haven't decided my plan of attack from here (sprite coordinate issues aside). I'll have to take some time to study the uncommented areas of code to work out how best to proceed. Ideally, it'd be nice to get Mario running and climbing, without the distractions/complications of timers, barrels and fireballs, and possibly easier to understand the sprite coordinate issues. Having said that, I have no idea at this stage what proportion of the remaining code would need to be ported to achieve that.

To give some very vague idea of what I've done so far, the PDF listing from IDA is approximately 80 pages of code. But that can be rather verbose with comment lines between functions, and added lines for cross-references - let's say 20%, so maybe 60 pages of Z80 code. My main.68k file, which contains (mostly) non-Neo Geo specific code, is currently 8 pages of code. However, operations can be done rather more efficiently in 68K code, so I'm going to estimate that would represent at least 10 pages of Z80 code. Using these very rough figures, I might say that I've ported about 1/6th or 17% of the code; doesn't sound like much when you put it like that. But there is an awful lot of 'grunt work' code remaining - code that will simply be a matter of turning the handle. Tedious but straighforward.

Sprites

Tonight I converted the Donkey Kong sprites to Neo Geo format.

Next task is to write the sprite rendering code for the Neo Geo. In theory DK has two (2) banks of 128 sprites, although according to MAME only 16 sprites are visible on each line. Regardless, from what I've gleaned from the code thus far, nowhere near that many are actually used. For now I'll need to devise some algorithm for selectively displaying only those sprites that are actually used. Ultimately I'll probably rationalise and condense the sprites that are used on the 68K port.

Tidy-up, bug fixes and the GCW-ZERO

I decided to give my 68K code a once-over before I move onto sprites; fill in any missing functionality in the execution path of the attract mode that I've already commented but not ported.

In the process I fixed a few minor bugs; the score and high-score display routines were always showing "000000", and the palette for the conveyor/cement level was wrong.

I also decided to finish off commenting and porting the level background rendering routines, which were decidedly simpler than the girder and ladder drawing routines; each level is a mixture of generic and special-case routines, the latter being simpler to reverse-engineer. As a result, here are the four levels as rendered before any sprites are added:

All 4 screens, fully rendered before adding sprites

I really am at the stage now where I need sprites to see what is happening in the code. Again, the conversion to Neo Geo sprite format should be straightforward, and shouldn't take me more than an hour or so. Then I need to write the sprite rendering routines for the Neo Geo hardware. One interesting aspect of the Donkey Kong hardware is that the sprite registers are shadowed in ordinary RAM and then DMA'd to the hardware registers each VBLANK interrupt. That actually makes my job really easy (for the initial implementation) as I can essentially do the same (although I'll be using the CPU to move the data). It's not necessarily how I'll implement the final version, but again, makes it very easy to debug and also rotate the screen!

I do have a particular issue with sprite placement due to the fact that I'm scaling the tiles (Neo Geo sprites) to fit the entire Donkey Kong screen on the Neo Geo display, but I'm pretty sure I have a solution for that issue.

As an aside, I received my GCW-ZERO yesterday and have spent a bit of time installing emulators - including the Neo Geo of course - and playing a few things. Whilst the emulations themselves are excellent, and the screen is nice and bright, the build quality is absolute, complete and utter GARBAGE! The controls are so horribly crappy and sticky, it's almost unusable. I'm not sure what my options are given that it's a Kickstarter project, but I'm sure as hell not happy about it! Consider this a Public Service Announcement.

Every man and his dog...

It seems Donkey Kong is a ripe candidate for (commented) disassembly - I now know of possibly three (3) disassemblies which would make mine the 4th!

The first as I mentioned is Sockmaster's listing, created when he ported it to the 6809-based TRS-80 Color Computer (aka Coco). The 2nd I learned about only yesterday, Jeff Kulczycki's listing, created when he added the 5th Foundry level. AFAIK this listing hasn't been released in the public domain. The 3rd I discovered today on the Donkey Kong forums; a reasonably comprehensive disassembly from what I've seen so far.

With all these available you may wonder (as do I) why I'm bothering to do my own. You can be certain I will be using all the information from the latter, just as I have Sockmaster's, but even that is lacking in some key areas I've already encountered. For example, the code to draw the levels is relatively uncommented (save for rather pointless comments such as 'subtract 10 from A'). So I will be taking everything available, verifying it to my own satisfaction, and merging it into my own IDAPro disassembly. Ultimately I aim to have the most comprehensive disassembly, and I should be able to generate fully-relocatable Z80 code (alongside my 68K port of course).

For instance, tonight I have been working on the aforementioned code that draws the levels, and thus far have deciphered the routines for drawing girders and ladders. The rest of the draw routines should follow quite easily from here. I suspect Jeff has managed to do as much (as he added a 5th level) but no-one else seems to have done so before.

But enough words and more eye-candy. The attract mode now cycles through all three screens, but of course the game-play demo is currently a static, tilemap-only, rendering.

The Neo Geo cycles through all 3 in attract mode

On par with the disassembly, I have coded the girder and ladder drawing routines, and made use of the ability to specify any level for the attract mode. The results vary from level-to-level, but it's a good indication that I've got these routines working correctly.

The 4 levels, girders and ladders only

And that's about as far as I'm going to get without any sprites. So it's back to my ripping software to convert Donkey Kong's sprites to Neo Geo format; nothing too different than the tiles so I'm expecting that to be a straightforward process. Then I can get Kong rendered on the title screen, before the infinitely more daunting task of delving into the game-play (attract mode).

A title fit for a Kong

Not a lot more work required to produce the title screen (sans sprites)...

Donkey Kong (left) vs. Neo Kong (right) sans sprites

I've patched the main sequencer to skip the game-play demo and go to the title screen, which flashes for a few seconds like the real deal. Obviously Mr Kong is made from sprites - 10 to be exact. Now it's time to undo the patch and at least get the game-play demo screen rendered. Here the code gets a little more involved and again there are some sections I'm yet to reverse-engineer. However, I don't think it's going to be a huge amount of work to see the main background for level 1 (a.k.a. the barrel level).

I've also got a 'define' in the source for which level the game-play demo uses. Obviously Mario's attract-mode movements aren't going to be suited to the other levels, but at least at a later date I can have each of the levels rendered without delving into the game-play proper.

Insert Coin

Neo Kong is coming along nicely, and now it displays the 1st attract mode screen - the 'INSERT COIN' screen - in its entirety. It doesn't seem like much, but there's a decent amount of infrastructure code behind the scenes; as well as the main program flow I described last post, there's also the routines for displaying general messages, credits and scores, for example.

Donkey Kong (left) vs Neo Kong (right)

One of the more interesting areas I reversed-engineered last night was the mechanism for queuing functions to be executed in the foreground loop. Up to 32 functions can be scheduled by storing the function's jump-table offset, together with a 1-byte parameter, in a queue. Typical functions that may be queued include messages and bonus & score updates. Perhaps not surprisingly, the code for this mechanism has deviated the most from the original Z80 code.

With a reasonable amount of the infrastructure now in place, I'm hoping that there's more eye-candy to show (i.e. attract mode screens) for relatively little more effort.

And here I may have found a 'bug' in MAME. "L=00" isn't supposed to be updated in attract mode; but the code to initialise the attract-mode flag after power-on is executed from the VBLANK interrupt. In MAME the foreground loop gets executed at least once before the 1st VBLANK interrupt, which results in the level being displayed. Not so on the Neo Geo (I've fudged it for comparison). I'm wondering what the real hardware does!?!

EDIT: Seems I was a little too quick to blame MAME. Turns out that the update of "L=00" is a side-effect of the routine being called before the variables are initialised; the score is compared against the bonus life setting ('00,000') and an extra life awarded, causing the level to be displayed. I hadn't finished coding the routine that is responsible for the erroneous update.

I'll skip the game-play demo - which appears after the 'INSERT COIN' screen - and start on the title screen next (sans sprites).

Not so horrible after all!

After a few sessions of getting into the business of porting Z80 code, I must say it's not nearly as onerous as I first feared. Having said that, there's a big difference between blindly porting code instruction-for-instruction, and re-writing commented Z80 code in 68K.

The former would be unbearably tedious, not to mention horribly error-prone, and in hindsight I don't think I'd ever attempt such an exercise. The latter is almost fun!

Whilst technically I'm porting the code line-by-line, I'm striking a balance between keeping the code as congruous as possible, and taking advantage of the 68K instruction set. For the most part I'm using a one-to-one mapping between Z80 and 68K registers, but not strictly adhering to that when it's more efficient not to. I'm also taking care to keep the routines (and data) in the same order, with the intention that once it's all complete, I should be able to merge the Z80 and 68K listings to produce a side-by-side code listing.

Thus far, both the foreground (main) loop and background (NMI/IRQ1) loop structure is there and running. The hardware initialization (video h/w and dipswitches) is done as is reading the controller inputs (which happen to map nicely to the Neo Geo controller). Right now the 1st attract screen is shown (incomplete) and it then transitions to the 2nd (game-play demo, barely started) after a time delay. Here is where the code starts to get more interesting - drawing the in-game screens!

I'm also using macros for all VRAM accesses which means, in theory, I can alter the mapping at a later date by editing a few simple macros. This should allow me to, for example, rotate the screen or map the video accesses directly to non-contiguous / sparse memories such as the Neo Geo sprite tilemap memory.

I'm starting to encounter areas of the code that I haven't commented yet, which means I'll be switching back-and-forth between commenting the Z80 code and porting it to 68K. Actually it's not a bad way of doing things at all, and in some ways makes it a little easier from the reverse-engineering perspective - not to mention a little more interesting!

In the back of my mind I'm trying to think of other classic video arcade candidates for a Neo Geo port. I chose Donkey Kong only because I had access to a (partly) commented disassembly. I'd like to try my hand at a horizontal game next; something more suited to the Neo Geo screen. Unfortunately, most of my favourites are vertical shmups. In particular my all-time favourite, Xevious, which is another Z80 game. The interesting thing about Xevious is that there is already a 68K port - as part of Namco Classics Vol 1. What's perhaps even more interesting is that I wrote the MAME driver for it, and so I'm familiar with the graphics processor that is used!

I wonder if there's a market for an MVS cartridge with a compilation of classic arcade games???

Less hacky

Last night I managed to clean up the linker script and it now builds with multiple ASM files linked together, as opposed to a monolithic source file with .includes scattered throughout.

And today at lunchtime I put together a minimal header include file and linker script for the NGCD.

Have to say, the NeoCD emulator does a better job of rendering the scaled sprites than MAME does. Whether it looks that much better on real hardware - I have no idea. Unfortunately, developing for the NGCD is a more tedious process, as each build requires un-mounting the virtual CD image, burning another with ImageBurn (which I've managed to reduce to a 2-click process) and then re-mounting and launching the emulator. There's also the lack of a built-in debugger, which I've already used in MAME extensively whilst trying to solve my numerous NOOB mistakes, and I haven't even scratched the surface of the port yet!

EDIT: After proof-reading this I realised I could probably leave the image mounted and copy the PRG file directly to the virtual CD drive - DOH!

As a result I will primarily be working on the cart version, which can be up-and-running in MAME well within 2 seconds from the last edit change. Every now-and-then I'll check that I haven't broken the NGCD build.

So now it's down to the business of porting the Z80 code. My first milestone is to have the attract mode screens (minus the game-play demo) ported and cycling through. That's at least a few week's work given my time constraints, so probably not a lot to blog about (except for hardware news) until then.

Same Same But Faster

After lunchtimes and nights stumbling my way around GNU assembler and linker, Neo Geo hardware and 68K ASM, I've finally managed to replicate my Donkey Kong rendering demo in 100% assembler.

This time 'round, I've got it rendering in both horizontal and vertical orientations, the plan being to develop both variations if practical - even if it means assembling both variations in their entirety and having them side-by-side in the same PROM image (after all, it's only 16KB of Z80 code!).

100% ASM rendering - horizontal and vertical orientations

It's not perfect yet - there are obviously a few nuances of Neo Geo sprite hardware I need to tame - but it's enough to get me started on porting the code. The demo comprises a single render function for the entire screen (which handles either orientation, selected with the controller A & B buttons) and is being called from the demo VBLANK handler (after executing the BIOS handler).

I'm still yet to decide the best approach for rendering in-game graphics, so for now I'll take the 'easy' way out, and maintain a copy of Donkey Kong's 1KB VRAM in Neo Geo RAM, and render from that every VBLANK (as the demo is doing now) until the best solution becomes clearer. I figure if I use macros to address the VRAM it'll be easier to adapt them to direct Neo Geo (and other platform) hardware accesses at a later date, as well as facilitating rotation of the display.

Before I get much further though, I need to step back and configure the linker properly, and I should also set-up the CD version as well rather than wait until the end. Regardless, there's a decent amount of code to port until I get anything at all to show for it, so probably not much to blog about in the next few weeks... although I am attempting to get the NGPACE hardware moving along...

(Not Sega) Genesis

Today I spent my lunchtime setting up a new 68K ASM project that will become NeoKong (aka Neo Geo port of the arcade Donkey Kong). I've decided to stick with the GNU assembler for compatibility with C projects and the devkit, and I also figured (rightly or wrongly) that it was the de-facto standard assembler for Neo Geo development.

As it stands, my code instructs the BIOS to run the eye-catcher animation, sets the stack pointer, acknowledges interrupts and then loops kicking the watchdog. Not too exciting I admit, but it took a bit of time to convert the header files from the (ASW-based) sprite sample source from the Neo Geo Development Wiki page for GNU AS.

Now the fun begins.

No brute force for Kong?

I've been pressing ahead with the disassembly during my lunchtimes and evenings, where possible. Right now I've completed the bulk of the non-game-play portions of the code, which includes the initialisation, title and coin-screens, and the high-level program flow. I'd estimate about 25% code coverage so far, which perhaps sounds less advanced than it is, considering a lot of the data areas have been identified. These data areas appear all throughout the non-commented portions of the ROM code, giving valuable time-saving clues to their function. There's also a fair amount of drawing and animating code that has yet to be commented, which should prove more tedious and time-consuming than technically challenging.

I have to say that the code is rather well structured, and obviously well thought-out. After initialisation, the main foreground loop is responsible for mundane tasks like checking bonuses and updating scores, whilst the rest of the main logic is scheduled from the 60Hz (VBLANK) NMI. Here the inputs are read, sprites and sounds updated, and the rest of the logic dispatched via a hierarchy of function vector tables, not unlike Pacman.

The hardware is also funky; two (2) banks of up to 128 sprites (a total of 16 per scan-line) whose registers are DMA'd from CPU memory space every NMI. Not unexpectedly, Donkey Kong only uses a handful of those sprites.

As I become more familiar with the code, I'm now considering re-thinking my approach to a 68K port. A brute-force, line-by-line translation would not only be mind-numbingly tedious and error-prone, but I'm starting to think also unnecessary! Previously I was worried about implementing portions of code that weren't understood, and whose side-effects were unknown, but now I'm thinking that those incidences will be kept to an absolute minimum.

It also tends to negate the need to maintain a side-by-side Z80-68K ASM listing. I would retain the overall architecture whilst organising the code and data in the same sequence as the original Z80 code, but in a separate file. Perhaps a little more cumbersome during development, but ultimately more flexible in the long-run. For instance, it would be easier to start implementation before 100% completion of the disassembly - for example right now I could code the attract screens without the game-play portion (and I may do just that) - and easier to patch functions and/or modify program flow for debugging/development.

The end result would be cleaner, more native 68K code, and easier to maintain. I would also strive to separate the Neo Geo hardware aspects of the code, facilitating easier porting to other 68K-based platforms, such as the Amiga.

All still pie-in-the-sky atm, but I firmly believe completely achievable!

Back to Donkey Kong...

After playing around with the Phoenix emulator, and unsuccessfully trying to get it running on the MVS system, I've decided to leave that to the original author and get back on track with my Neo Geo BIOS and Donkey Kong projects.

To that end, I've now finished transcribing Sockmaster's comments into IDAPro which would mean that, technically, there should be enough information to start work on the 68K port. However, I'm loathe to leave the source half-commented (actually, considerably less than half) and have decided to press on with the reverse-engineering and comment as much of the code - aiming for 100% - as possible.

As it stands I've got a reasonable idea of the structure of the code; the program flow and the data structures involved. The code should also be almost completely re-locatable (at assembly time) now; later on in the piece I'll try moving code and data around and see if it still runs on Donkey Kong hardware! It might also be possible to port it to other, suitable, Z80-based hardware as well - any 8x8 tilemap system with 16x16 sprites should suffice. There is, for example, a port on Galaxian hardware.

Anyway, once I start the port my aim to is get the first level running, and release that as a playable demo. I'm also intending on coding both horizontal and vertical versions (selectable via soft dipswitch) - I guess it'll be the Neo Geo's 2nd ever vertical game!?!

Thinking more about the 68K port - it will perhaps be a little more work than the 6809 because of the 68K's 16-bit data bus. There will also be the temptation to simply re-write routines in 68K ASM with little regard to Z80 registers; an approach frought with danger when other routines expect certain values to be retained in certain registers. Must... resist... temptation...

So it's not going to end up as nice 68K code by any standard, unfortunately. But once it's running on the Neo Geo, other possibilities are interesting. An Amiga port almost goes without saying, but then there's also the Sega Genesis/Megadrive! Hmmm...

Phoenix Emulator (not mine)

I've been in touch with the NGCD Phoenix emulator author, and unfortunately (for me) the Z80 core he's using - Marcel de Kogel's portable Z80 emulator - is written in C. Right now the emulator itself is in its infancy, and running very slowly, although obviously there hasn't been any optimisation done to it yet.

I also volunteered to help out with the rendering; first ripping the tiles and palette from MAME and enhancing my Donkey Kong demo to work with Phoenix as well.

Neo Geo Phoenix demo

Then I started work on building the emulator, which was designed for the NGCD, for the MVS (cartridge) system. Ultimately I discovered that there isn't enough RAM on the MVS to run the emulator as-is, so I then turned to building it for the NGCD in an environment I was familiar with.

After coming to grips with the nuances of the NGCD vs MVS, such as the sprite format, it was quite straightforward to add my demo rendering to the emulator. I've still got some tweaks and clean-up before I send it back to the original author, but at least it will give him a head-start on the display - something I've had a lot of experience with whilst working with FPGA emulations!

It might also be worth my while getting Donkey Kong running with the C Z80 core, just for fun...

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

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!

More pies in the sky

Still no progress to report as work is unrelenting, but I did remind one of my colleagues and he asked about the audio codec, so at least he's still interested in doing it. We just have to get some down-time to actually be able to devote some time to it.

So in the mean-time, I've been dreaming about the add-on boards that I'd like to produce for it.

First up, the so-called CPU-socket boards. Considering whether I should put 5V level conversion on the main board, but in the end decided against it just in case I want to stick some 3V3 logic on a small daughter-board. That aside, I'll be looking to make Z80, 6502, 6309 & 68K (DIP & PLCC) adapters in the short term. Wishing I had enough I/O for an ARM250 but it's out of the question (and not sure where I'd get one of those anyway!?!).

Secondly, similar past projects like the One Chip MSX (OCM) & Minimig and more recently proposed and/or WIP project like the ill-fated Coco-X and another TRS-80 Model I expansion design have me thinking about prototyping other system board replacement projects on this hardware. The 200-pin MVS connectors with 5V level conversion should come in very handy for adding all types of peripherals such as cartridge interfaces, keyboards, floppy & hard disk drives...

...with that in mind I'd ultimately like to produce boards for TRS-80 Model I/III/4, TRS-80 Coco 1/2/3, Apple II & BBC microcomputers - roughly in that order of preference. So whilst I'll prototype them as add-on boards to NGPACE, the end result would be single boards that would be mounted inside the original casing of the target platform.

Picture a TRS-80 Model I keyboard unit, running from a modern 12/24V supply, housing a fully pimped-out 128KB (or more) Model 4 core, with a selection of legacy graphics enhancements (e.g. Grafyx Solution and/or Mikrokolor) driving DVI-I video out, internal floppy and hard disk emulation via SD card, modern joysticks and a connector for a real floppy drive accessible via the expansion interface door.

Of course you could also run it as an Apple II or Coco 3... you want one, right?

Gathering momentum again?

After a few weeks of inactivity due to very busy workload, I'm trying to get the ball rolling again while some of us (potentially) have a lighter load for the next few weeks.

I gave a quick design briefing on the whiteboard at lunch today to my colleague who volunteered to look at the analogue audio and video circuits. This afternoon I populated the project repository on our SVN server with the project schematics & PCB and all the data I have collected thus far.

Hopefully he'll be enthused enough to start looking at it. And hopefully his enthusiasm will prompt my other colleague to get started on the power supply design!

And to help get myself motivated, tonight I hooked up the AES console to my TV for the first time, and played a few games of Blues Journey and the newly-arrived Fatal Fury 2...

Flash Carts

One of the Holy Grails of Neo Geo enthusiasts' wish lists is a flash cartridge for the system. There is photographic evidence around that suggests a certain development group has developed one, but I would assume its primary purpose is to assist in development of their Neo Geo games. I'd imagine it could be programmed with a reasonable selection of legacy Neo Geo titles, but it would perhaps be safe to assume that it would not be capable of supporting every single game for the system. Regardless, they're not for sale.

I'm not making any such claims either at this stage, but the intention is there to produce some sort of programmable (flash?) cartridge to assist in the development - or more specifically, testing - of the Neo Geo IP. Unfortunately, whilst the cartridge will be programmable in-system via the FPGA on the system board, this will of course not be an option on an actual SNK system board.

Anyway, it's a long way off yet; pointless even designing it without a significant portion of the Neo Geo IP developed and running, and without some in-depth research into the protection mechanisms employed on the various cartridges. But I guess it's possible that eventually I'll have learnt enough to develop a flash cartridge that is programmable externally, and maybe even capable of running most Neo Geo titles.

The State of Play

I actually started work on this project about 6 weeks ago. But it does have to compete for time with Real Life, so it's going to be somewhat of a drawn-out process.

The easiest way to explain where it's at is just to say that I've completed the "interesting" parts of the schematics. In other words the FPGA, all the memory devices, the ARM, the video IC's and the bulk of the connectors have been done. What's missing on the schematics include the power supplies, analogue video amplifiers (for JAMMA), the analogue audio circuit, and all the really boring bits like de-coupling capacitors and sundry miscellaneous protection components on some of the I/O.

As a result, all the major IC's and the AES/MVS connectors have been selected, based primarily on their availability from Digikey. The flash devices are dirt cheap, and for simplicity I've gone with the same device for all ROM's. The SRAM can be used as either 8-bit or 16-bit mode, which is a bonus. The HDMI chip incorporates audio, is readily available and looks relatively simple to use. The video DAC I've used on another design. I've also used the STM32F2xx family before.

I should mention here that I've managed to coerce a few colleagues into assisting with the design; my business partner is handling the power supplies and related boring bits, and another colleague is designing the analogue audio & video circuits.

As for layout, I've just started to collect footprints for the various components. Fortunately a good selection of the larger IC's have footprint libraries already available. I've done the AES/MVS connectors myself. I'm envisaging the board to look similar to a 1-slot MVS board; JAMMA connector on the front, cartridge connectors at the back, additional audio/video connectors on one side, and controller connectors on the other. At least that's the plan...

I suspect there's a few more weeks, if not months, of schematic capture and review remaining before we can start layout proper. To some degree I'm at the mercy of my colleagues as well, but we're also pretty busy at work atm, let-alone the other aspects of our respective lives. Layout is going to be a massive job, and I'm inclined to sub it out else I'm afraid it'll languish for many months in the too-hard basket. Of course, that's added expense...

In the mean-time, I might re-visit the HDL I wrote a few years ago and see if that has suffered any bit-rot. And of course, I'll need to spend a bit of time on my AES console once the first of my carts turns up - you know, for science!

What else?

I'll start off my 3rd and final 'introductory' post with a brief run-down on the FPGA.

Since I'm only making a handful of the development boards, I thought I'd use the largest device that I could afford. To give you an idea of size, let me first note that the EP2C20 (20K LE's) is adequate to emulate the Amiga 500, including the 68K core and a 2nd soft-core processor for floppy emulation etc. And I figure that's about the same complexity as the Neo Geo...

I've gone with the 5CEA7, with roughly 150K LE's or, alternatively, enough logic to emulate seven (7!) complete Amiga 500's, or Neo Geo's. I figure there's enough headroom in there for SignalTap and any other debugging aids I may wish to add!?! In any case, with the cartridge connectors and digital video, the Neo Geo has some serious I/O requirements, and my wish list of features pretty much dictated a 480 user I/O device.

As I mentioned, the board is also being designed to be my PACE development platform for the foreseeable future, so there are a few more components not strictly required for the Neo Geo (but may come in handy for it anyway).

I've added an STM32F205 (ARM) micro-controller, primarily for JAMMA & AES controller I/O, but it's also a USB (OTG) host for HID gamepads, standard arcade trackball input, battery-backed RTC for the Neo Geo, and a high speed SD card slot. It's also responsible for configuring the FPGA from SD card. It connects to the FPGA via three (3) high speed SPI ports. For other PACE projects it'll be very useful for emulation of floppy and hard disk devices via FAT-formatted SD cards.

Aside from the FLASH and SRAM required for the Neo Geo, there's also an 8Mx16 SDRAM device which will be most useful for emulation of retro microcomputers like the Amiga. I've also connected a 2nd SD card directly to the FPGA to prototype designs that won't use an external micro-controller.

I've added a so-called 'CPU socket' which is actually a pair of high density dual inline sockets to accommodate various daughter-boards with a CPU. There's just enough I/O for a 68K CPU - for obvious reasons - and of course 6502, Z80 & 68(3)09 would also be possible. Aside from running designs with physical CPU's, the idea is to also accommodate development of a 6309 core - another project that I have undertaken recently.

Finally, some sundry I/O; as mentioned PS/2 x2 to the FPGA, one or two Dreamcast (Maple Bus) ports, one or two Nintendo Gamecube ports, some extra 3.3V & 5V I/O on the ARM (which can be configured as analogue or digital) and a few LED's for good measure.

So there you have it - a handy little board that can be plugged into a JAMMA cabinet, or powered from a 12-24V supply and connected to your 55" LCD via HDMI and played with a variety of controllers. And with plenty of expansion (via the MVS connector) for legacy keyboards, cartridges and 5-1/4" floppy drives, I'll be able to load Sockmaster's Donkey Kong port for the Coco 3 off floppy disk and play it with my wireless NGC Wavebird Controller!

In a perfect world there'd also be a bank of high-speed DDR3; it was originally part of the design but when I ran out of I/O I had to settle for vanilla SDRAM. I cannot think of anything I'd like to add to this board to be honest! I refrained from adding all manner of legacy 8-bit console controllers, and even removed a light gun connector, most of which I can add via the miscellaneous I/O connectors.

Next post I'll give a brief run-down on where the project is at, and speculate wildly as to how I think it's going to pan out. Because engineering projects never blow out...

What?

The penultimate goal of this project is to produce a commercially viable replacement Neo Geo system board that can be used either as an AES (a console connected to a TV) or as an MVS (installed in an arcade arcade). Beyond that, I have aspirations of enhancing the design to eliminate the need for physical game cartridges (for example load ROM's from SD card), and eventually even a miniaturized variant of the latter in a hand-held device much like what the Neo Geo X should have been.

But all this is further down the track.

The initial hardware that I'm designing is not meant to be a commercially viable product; rather it is designed to assist in the development of the IP for the FPGA. And by assist, I mean - make the job as painless as possible. It is going to be ridiculously over-specified, seriously expensive, and I only plan on ever making 4-6 of them. This board will also serve as my PACE platform of choice for the foreseeable future. I have rather broad interests in emulation aside from the Neo Geo, and this board will be designed to cater for most - if not all - of those interests.

First and foremost, I made the decision that this board would use physical AES/MVS cartridges. This alleviates the need to emulate cartridge hardware in the design, and a true replacement system board would use cartridges anyway. So this board will have one AES slot, and one MVS slot. The other plus is that I'd effectively be implementing the logic for an MVS-to-AES cartridge adapter in the FPGA, so that gives me an option for a spin-off product.

Secondly, the cartridge-based Neo Geo system boards contain no less than four (4) ROM devices; the system BIOS, the default FIX layer tile set, the sprite look-up table and the default Z80 sound driver. It has two banks of RAM; the 68K work RAM and the battery-backed RAM. These devices span four different system buses and, whilst not huge, would require a relatively large FPGA to implement using on-chip memory. To both eliminate on-chip resource requirements and provide external flash storage for other projects, I decided to use four distinct external flash devices and a single (battery-backed) SRAM device for these memories.

The flash devices are also several times larger than strictly required; there is adequate capacity, for example, to have the AES, MVS, UniBIOS and Debug BIOS images all programmed at the same time (and of course, be soft-selectable).

Analogue video output is available at both a VGA connector and the JAMMA connector, keeping in mind that the design can drive either 15kHz or 31kHz video on both interfaces. A HDMI port also provides digital video (and audio) with only a simple passive adapter required for DVI monitors.

Analogue stereo audio is available via a pair of RCA connectors. Digital stereo audio (e.g. LPCM) is available via the HDMI connector. It's also worth noting that the hardware will support 8 channels!

Controller input options include the standard JAMMA interface, plus a pair of DB15 AES controller ports. Additionally, there will be two PS/2 ports (keyboard & mouse) and a single USB port will allow devices such as HID gamepads or the Blaze-produced Neo Geo X AES Controller to be used. Finally, a select few 'legacy console ports' such as Dreamcast and Gamecube will allow the respective controllers to be used to play Neo Geo games.

I'll cover the FPGA itself and other board components not strictly required for Neo Geo emulation in my next post.

Who and Why?

I thought I'd kick off this blog with some background information on myself,  the project history and motivation behind NGPACE rather than dive straight into a technical description of the project.

I've been dabbling in emulation for well over a decade now; initially software emulation (I've authored two MAME drivers thus far - Street Fight (aka Empire City 1931) and Namco Classics Vol. 1 & 2) but in recent years I've turned my attention exclusively to hardware (FPGA) emulation.

In the process of emulating a few dozen different arcade, console and retro microcomputer platforms, I've experimented with the creation of a MAME-like framework for FPGA emulation under the guise of the PACE project. The framework itself is in dire need of a complete re-working, but it has served its purpose well over the years, expediting the addition of new emulated platforms to the project.

A year or two ago I had a stab at the Neo Geo, on hardware that I knew wasn't adequate for a fully working implementation. I managed to get the BIOS booting and with the PROGRAM and FIX layer ROM's loaded from Joy Joy Kid (aka Puzzled) I could actually coin-up and 'play' a game. The next step was to implement at least some of the sprites, however I was diverted onto other projects and, with no prospects of completing a full emulation on that hardware, I never quite got back to it.

Popularity of the Neo Geo remains remarkably strong, with a seemingly sustainable industry surrounding it supplying services such as consolisation of MVS boards, video enhancements, MVS cartridge adapters for AES consoles, and cart conversion (converting the cartridge for a less popular game to another). The platform has even seen several new games released in cartridge form in recent years. And there's the (divisive) Neo Geo X hand-held that was released recently...

I thought it high time I took a serious crack at the Neo Geo, for a number of reasons. Personally, it would represent a more challenging project than any I had attempted before; to be honest a lot of the arcade platforms were little more than exercises in cranking the handle. Also, I had been searching for a number of years for a project that just might have some commercial value (although I have others in mind as well), and I firmly believe that the Neo Geo is a good candidate - at the right price.

Although I was fortunate enough to have had access to ever more powerful FPGA's well suited to PACE in general, it was always going to be unlikely that I'd come across hardware capable of a full Neo Geo emulation. So recently I decided that I'd simply bite the bullet and design some custom hardware that would allow me to emulate the Neo Geo in its entirety. It was going to be ridiculously over-engineered, both to assist in the development and debugging of the Neo Geo, and also serve as a prototyping platform for all my other PACE projects for the foreseeable future.

And this is the story of NGPACE.