Eye-catching?

Haven't had much time over the last week or so; the whole family has been sick at various times and I've been trying to fit more physical exercise in which is not conducive to other non-essential activities.

Whilst sick, and not feeling up to a full assault on the Lode Runner code, I started looking at the so-called eye-catcher routine in the BIOS. This is the routine that displays the spinning NEO GEO logo and the other bits of text on the screen at power-up (or reset) before the cartridge takes full control of the system.

The routine itself can be enabled, disabled or overridden by the cartridge with a single byte in the header. Even when enabled, the BIOS routine uses tiles and sprites defined by (stored on) the cartridge itself. Since I'm not interested enough to code my own eye-catcher routine, I thought I'd see how difficult - or otherwise - it would be to produce my own custom text for the BIOS routine.

The results of my investigations have been documented on the Neo Geo Development Wiki here.

My first experiment was to replace the "MAX 330 MEGA" text. It looks pretty good, but needed something on the following line (to replace "PRO-GEAR SPEC"). There was an issue with that (see the wiki entry) but I might return to this option.

My next experiment was to replace the SNK logo. Not quite sure whether or not I like it yet!?!

Anyway, at the very least, I learnt something new.

I've also had a think about what I'll be releasing and when. I was toying with the idea of the initial release of the Coco 3 port being cartridge-only, but I've now decided that it would significantly delay the release and also further delay what should be my primary focus - NGPACE.

As a result, I'm going to finish off the C port as a matter of urgency and release the Neo Geo MVS and CD versions, then immediately move on to finishing a disk-based Coco 3 port and release that in the near future. I'll still work on the Amiga and Genesis ports, but I don't want them to delay the above-mentioned releases.

I also plan on ultimately releasing the original 6502 disassembly and the C source code, probably once the Amiga & Genesis are done. Then it's time to move on to another game.

The Genesis of another port...

I couldn't contain my curiosity, so tonight I installed the SGDK - Sega Genesis Development Kit.

A few hiccups but nothing that further study of the sample makefiles couldn't solve. There's a bit of jumping through hoops to create a ROM image, but it's all in the generic Lode Runner makefile now, which is becoming a bit of a dog's breakfast, but I don't think I'll be adding too many more targets at this point in time.

Sega Genesis Lode Runner - admittedly not very impressive yet

Not particularly exciting output, but I was pleasantly surprised to see it on the very first attempt, given the number of steps in the makefile. My blind cut-and-paste skills must be strong!

I could add targets for Atari ST, (68K) Macintosh and X68000, but I'm going to stop myself here before it gets too silly. I need to actually finish off the C core and the ports that I do have before going any further. I'm also growing a little tired of Lode Runner, and want to start on a fresh port in the not-too-distant future.

What I don't know about the Amiga...

I've been sick the last few days so instead of finishing off the Neo Geo port - which also included tackling the AI bug - when finally feeling a little better this afternoon I decided to do something a little less intense, and look at what was involved in developing Amiga software.

I knew the Amiga scene had been evolving for years after I stopped using my A500, and delving back into it in 2014 involves a whole bag of confusion. 68K vs PPC, Commodore vs new Amiga hardware, Workbench 1.3 vs 2.x vs AmigaOS 3.x vs 4.x, and AROS (still not really sure what this is)... and of course the scene assumes you already know the lay of the land. Google was my friend.

Cross-development tools seem to be thin on the ground, and those that do exist tend to be linux-based. Perhaps not surprising because a hard-disk equipped high-end Amiga is more than capable of hosting its own development toolchain. Regardless, my preference at this point was a Windows-based cross-toolchain that I could invoke from the command-line, utilising the existing makefile.

I eventually found a site that hosted the gcc (3.4.0) binaries and a bunch of libraries that ran on Windows under cygwin (not unexpected, but bleh!). After installing both and downloading a missing DLL, I could finally compile hello_world.c.

Next step was configuring an Amiga environment. Normally my go-to emulator is MESS, with its integrated debugger and simple command-line launch. But in this case I opted for WinUAE due to it being reportedly significantly more advanced than MESS when it comes to Amiga emulation. So I downloaded and installed the latest version - I won't go into details but booting from ADF (floppy image) wasn't going to cut it so I had to learn how to install onto a hard disk.

I opted to mount a (PC) directory instead of a hard disk file, mainly because it simplifies the process of transferring files to/from the emulator. After installing WB3.1 and subsequently a missing library (ixemul) I finally saw the words "Hello World!" appear in the Amiga Shell!

Next step was to create the amigaos branch of the Lode Runner project, enhance the makefile and get it compiling under the new toolchain. After stubbing out all the os-dependant routines, and enabling debug messages via stderr, I was greeted with the following:

Lode Runner on the Amiga - debug output (stderr)

So Lode Runner is actually running - albeit headless - rather nicely. I'd be worried if it weren't.

Of course now comes the interesting part, though I may deny temptation and finish off the Neo Geo port (and the C core) before progressing further on the Amiga. Or whilst on a roll, I may look at setting up the toolchain for the Sega Genesis/Megadrive...

Is it Game Over for the Neo Geo? Yes!

Tonight I finished the GAME OVER animation - for colour mode at least. When I was testing monochrome on the Neo Geo the animation still appeared in colour, so I went back to check the Coco3 port and it was the same. Oops! I'll fix that in the near future.

So the bells and whistles in terms of graphics are complete. Just high score entry, special keys and game speed tuning. And fix the last guard AI bug of course. The Neo Geo port is looking good, and the speed of the C code has not been an issue at all!

As I mentioned, the NGCD version is also running in MESS, so this weekend I'll burn a CD and confirm that it runs on real hardware.

UPDATE: It runs! And looks good too!

Once the above issues are addressed, I'll do a full MVS & NGCD release. No point waiting for a cartridge release on the Neo Geo - that's a while off yet! ;)

Next? I might crank up the Amiga emulator. Ideally I'd like to use the same (cross) toolchain, so I can simply add another platform to the make file. But something tells me it's going to be easier to develop on the Amiga itself.

Then there's the Sega Megadrive/Genesis...

Quick update

Found the issue with the NGCD build not running and the palette - works now under MESS. Tomorrow I'll bring home my one-and-only Neo Geo controller from the office and burn a CD and try it out on the real console over the weekend.

Also constructed the title screen graphics. It's close but corrupt in some areas for some reason I can't fathom. Hopefully a fresh look at it tomorrow will reveal the issue!?!

EDIT: Title screen sorted! Now working on GAME OVER graphics animation.

I'll 'C' your Lode Runner, and raise you a Neo Geo port

Very good progress today! The AI isn't quite 100% correct, but it's very, very close. The demo runs most of the way through the 2nd level, so there can't be too much wrong now. That aside, the Neo Geo version is definitely playable, even more-so than the PC port in fact.

Most of the battle has been learning the nuances of the Neo Geo sprites. I'm still unsure of how the sprite size field of the SCB3 register is supposed to work. I won't bother going into the details, but I still haven't ruled out the possibility that it's not implemented 100% correctly in MAME. I have more experimentation to do...

...but the upside of all this is that it has definitely been a worthwhile exercise with respect to learning Neo Geo hardware in preparation for the NGPACE project!

FWIW you can select COLOUR or MONOCHROME (GREEN/WHITE) rendering from the soft dip settings in the BIOS. There's probably a few more settings I could add at a later date.

I'll press on with the Neo Geo implementation, fixing the AI and adding the bells and whistles such as title screen, GAME OVER animation and high score entry. And as I've done with Donkey Kong, I'll burn a CD and verify that it runs on a real NGCD console!

EDIT: I've got the NGCD target building, and it runs far enough to show the title screen (place holder) - interestingly in the wrong colour - and then hangs. No further clues at this point.

Then I might look at reverse-engineering one of the most common sound drivers so I can add sound to the game, which I need to do for Donkey Kong as well.

Scaling new sprites

I've been working on the Neo Geo port when I've had the chance, and after a few red herrings of despair, I've managed to get it showing the 1st level with minor glitches.

Apple II Lode Runner - Neo Geo style

At one point I'd given it up as impossible, but further investigation (and a peek at the MAME source) put me onto the right path and confirmed that my initial theories were indeed correct, and I am able to implement it the way I'd originally planned.

The whole question of whether or not it could be implemented revolves around the sprite scaling on the Neo Geo; more specifically, if it is indeed consistent for each tile within a sprite. For the most part it is, although you'll notice above that the game status text at the bottom of the screen is corrupt - this shouldn't be an issue as I will ultimately be moving that text onto different sprites and the issue should resolve itself.

EDIT: Closer inspection of the MAME driver reveals the answer to the corruption; but as I mentioned it won't be an issue as I need to move the bottom 2 lines to another sprite chain for other reasons.

What I have discovered, however, is that the admittedly rudimentary video library is rather unsuited to selectively manipulating large, chained sprites and I will have to revert to programming the hardware directly. Not a big deal, but perhaps a little disappointing. Having said that, there's not a whole of lot functionality to implement in the OSD layer, and it shouldn't be too long before I have a playable, if vanilla, implementation running on the Neo Geo!

C++ --

Last night I had a few spare minutes so rather than get entrenched in debugging the C port, I thought I'd start to set up the project for the Neo Geo target.

I duly discovered that my 'C' port was, in fact, a C++ port! Doh! It's been so long since I've been restricted to pure C code that I'd inadvertently used some C99 and C++ language features. Although it is technically possible to develop in C++ for the Amiga (though a right royal PITA according to what I've read), the Neo Geo toolchain is definitely C only.

Tonight I reverted the Lode Runner core code to pure C and can finally compile and link both PC (Allegro) and Neo Geo targets, from the same makefile. In fact, the Neo Geo target will in turn support both cartridge and CD build options.

Right now running the Neo Geo build I get the hash screen. I was expecting a cheesy FIX-layer text message, so clearly something is not quite right in the build, but I've run out of time tonight. It shouldn't be too difficult to rectify, since I have successfully built the Neo Thunder homebrew project using this toolchain in the past.

EDIT: It's now running - cheesy FIX-layer message and all!

This exercise has also unexpectedly rekindled my interest in finishing off my Neo Geo Donkey Kong port!

404: Pun not found!

Sorry George, couldn't come up with one tonight. :(

What I have been able to do, however, is finish porting the guard AI logic to C. It's finished in the sense that I have no more lines to port - not in the sense that I have finished debugging. That said, it looks close and I certainly found it challenging enough to play in my 2-minute test. There's a chance I guess that the AI is actually spot-on - it's symmetric to a degree and it's much easier to see inconsistencies and certain other types of bugs in C.

In the process I actually found a (subtle) bug in the AI logic of the 6809 port. In a nutshell this bug means that the Coco 3 version is ever so slightly easier to play than the original when the player is on the very top row of the screen. I've fixed it but am yet to perform any testing on the Coco itself.

Speaking of bugs; I had to go out of my way to implement the AI bug that I documented in my blog some time back, but it's there now so the C version is still faithful to the original.

Once I've sorted any AI bugs that leaves the high score entry (trivial), the GAME OVER animation (also trivial but somewhat tedious) and the oft-maligned circular wipe effect. It turns out that I tackled the C port in pretty much the same order as the 6809 translation.

I've decided to tackle the Neo Geo port (in C) next, if only to verify my hardware abstraction and also my proposed sprite hardware extensions to the code. If all goes well, I should be able to knock this over (at least implement a playable game) in a week or so. I'm not so concerned about the bells and whistles on the Neo Geo at this point.

Depending on how that goes, I might then look at another quick C port - the Amiga!

Finally then I'll return to the Coco 3 for a full-featured release before putting Lode Runner to bed for a while and starting on another game altogether.