A new year, a new promise... yada yada...

It has been several months since I posted that I was getting interested in picking up my retro projects again, yet there has been next-to-no updates since then. And not the first time I have posted with some optimism about resuming and/or finishing some project only to have it all grind to a halt again within days.

My last post in this vein was in good faith but then work suddenly got really, really busy; I was even working some nights to get through it all. Then of course holiday season was upon us and I had family visiting from inter-city and overseas and then finally went away on holidays myself. And here we are, months later.

So, where do I sit now?

Work is a bit more sane now, although I can't say for certain that it will stay that way for long. I'm also trying to allocate more time to physical activities, so that isn't conducive to sitting at a keyboard either. And, almost on a whim, I've decided to study up for my HAM licence, so that will also eat into my spare time. However, I am slowly drifting back into my retro gaming hobbies, possibly spurred on by the fact that I picked up a Nintendo Switch for Xmas.

[An aside: I've been playing Lode Runner Legacy on the Switch and was disappointed to see the "classic" mode game graphics weren't from the Apple II. In fact the animation of the player and guards is absolutely horrid!]

I should also note that one of my New Year's resolutions was to simply "get things done"; things that have been on my to-do list for, in some case, several years. Those 'things' comprise projects around the house (including my man cave / games room), things I need to build like my rocker plate (if you don't know, it won't interest you), and of course my retro ports.

So now that the year is starting to settle into a routine again (school is back next week) I can sit down and formulate some sort of plan.

As far as retro ports are concerned, I'm determined to finish off Asteroids on the Coco3 first and then revisit it on the Apple II/IIc/IIGS. I also have another target in mind. Also languishing are Space Invaders for the Coco3, Lode Runner for the Coco3 and Neo Geo, Knight Lore for the Amiga and Neo Geo and, finally, Donkey Kong for the Neo Geo.

To top it all off, I've decided on my next retro port - after the above are done of course. It's an arcade game suited only for 16-bit targets, and is going to be a mammoth task to reverse-engineer in the first place. It was originally further down on my to-do list (after, for example, Karateka and Prince Of Persia), but I've decided to attack a more ambitious project. Go big or go home!

To be continued in my next post... the 2019 wrap-up! ;)

Still a bug, and circular wipe again

First task tonight was to try to understand why the Apple II Lode Runner attract screens were non-deterministic. I think I've found the answer, and it was even semi-documented in the 6809 source code. However there are still inconsistencies between the Apple and C versions I can't explain at this point so it would appear I still have a bug somewhere, perhaps not even in the AI as such. It needs further investigation.

Second task was to determine if the "circular wipe" that was part of the Apple II version (and very few other ports) is feasible on the Neo Geo. I had the idea to employ the sprite shrinking capabilities of the Neo Geo hardware in order to "get it for free".

However the "free" solution requires setting sprite positions outside the visible display, which is not possible unfortunately. So I set about trying to devise another, necessarily more complex, scheme that would be workable.

I think I have worked something out - on paper at least. It's not too complex and doesn't require much in the way of run-time calculations and does employ sprite shrinking. The only caveat is that I'm not sure how it's going to look when it's actually animated.

There are two ways forward from here. One is of course to simply implement what I have devised and run it. The down side is that I have to re-learn everything I have forgotten about sprite formats and sprite manipulation, and then write code to create the requisite sprite tiles and the code to assemble and control them properly. And if that looks naff, it's all a wasted effort.

The other is to simply "emulate" the Neo Geo's sprite shrinking in a suitable development environment (my go-to has always been Allegro on the PC) and code a pre-canned animation. There is I believe sufficient information on the NeoDev Wiki to do exactly this. It's probably less work, and requires less mental effort on my part, until it comes time to implement it on the Neo Geo itself. The only caveat is that it may look different on Neo Geo hardware if I get something wrong.

One other option of course is to give up on the circular wipe altogether. As I mentioned, not many of the other Lode Runner ports include it, though I'm not convinced that the reason isn't the rather annoying pause whilst it was rendered, rather than technical reasons (on the bit-mapped platforms at least). Some ports chose a different "wipe" animation whilst some didn't bother with anything at all.

But I would like to keep the port as close to the Apple II original as possible; it serves to reinforce the origin and the accuracy of the port. So I might give the "emulation" approach a go when I next get to work on it.

When a bug is not a bug

Tonight I thought I'd see if I could find the AI bug in the C code.

[To explain, the benchmark for the AI has been to run the attract screens on the target port side-by-side with the Apple II original. If the outcome for all attract screens are exactly the same as the Apple II version, it's a pretty safe bet that the AI is spot-on, as it is likely that all execution paths are thoroughly exercised across the multiple levels.]

I started comparing the 6809 and C code side-by-side for the guard AI routines. I did find one minor discrepancy (a pair of while loops that should have been do-while loops) but that didn't make any visible difference to the outcome. Also a few red herrings which turned out not to be differences at all, but I'd obviously done some optimisations in the C code that obfuscated the transcoding somewhat.

After spending a few hours not getting anywhere, and about to wrap it all up for the night, I was watching the Apple II and Coco 3 attract modes side-by-side (again) just for a sanity check and - to my horror - noticed that they actually differed!?! This can't be right - I thoroughly tested the Coco 3 version against the Apple II version all those years ago!!!

So I fired up the Neo Geo (C) version again so that all three were running in parallel, and to my surprise it corresponded with the Apple II version - for the first time. How could it be that I fixed a bug in the C code by comparing it against inaccurate 6809 code? This warranted further experimentation, so I ran the first attract level on the Apple II over and over again until...

... I discovered that there are two possible outcomes on the first attract screen! I had never noticed this before, and right now I can't imagine how that happens, as I thought it was completely deterministic!

[UPDATE] I've noticed that on the first run you get one particular outcome, and on all subsequent runs (eg warm boot) you get the other outcome. So likely an uninitialised variable or variable corruption.

The outcome on the first run from a cold boot

The outcome on subsequent runs (eg. warm boot)

But the good news is that both the CoCo 3 version and the Neo Geo versions behave the same way as the Apple II version or rather, at this point, both the CoCo 3 version and the Neo Geo versions don't behave unlike the Apple II version; and by that I mean that I haven't confirmed at this point whether the C version results in two different outcomes. (It's late, that's for another time).

To satisfy my curiosity, I'll probably have a go at trying to find the source of the non-deterministic outcomes, and then confirm that the behaviour is faithfully reproduced in the C version.

Then I think I'll FINALLY finish off the Neo Geo port, hopefully adding the circular wipe and maybe a few bells and whistles (eg. high score save to memory card) to give it some polish and release it for MAME and the NeoSD.

From there, who knows? Maybe I should design a cart for the CoCo 3 version...

Coming full circle

Last night whilst getting ready for bed I was subconsciously pondering the circular wipe for Lode Runner on the Neo Geo, and I had a "Eureka" moment! My memory of certain Neo Geo technical details is a little hazy after a year or more of absence, but I think I have hit upon an easy way to implement it, thanks mainly to the hardware functionality of the Neo Geo sprite engine!

I'm tempted to pick up Lode Runner again and see if I can finally fix the AI bug and just knock off the project, sans sound. I did have Asteroids on the top of the to-do list, but at the end of the day, it's still another project that needed finishing off.

Watch this space...

Return to an old project (briefly)

Tonight, prompted by postings on other forums, I returned to an old porting project in part upon request and in part to satisfy my own curiosity.

The project in question was Apple II Lode Runner, and the target platform was the Neo Geo.

Quite a while back I invested in a flash cart for the Neo Geo (AES) called the NeoSD. Aside from allowing you to play any and all Neo Geo titles on the console, it also allows you to play homebrew titles; something which was hitherto impossible without building and programming your own cartridge. As you can imagine, this was quite a serious impediment to any potential Neo Geo homebrew scene.

Anyway, I had never tried programming any of my ports - or any homebrew games for that matter - into the NeoSD. And since someone had asked about Lode Runner, it prompted me to pull the console out of my unfinished games room and finally learn how to do it.

After some research (detailed information is sorely lacking) and a little experimentation, I managed to get my Lode Runner ROMs into the correct format and loaded onto the SD card.

Apple II Title Screen

Attract mode game play

Bearing in mind that I had burned a CD for the NGCD in the past, I was confident it would actually run. But it's still pretty cool to see your project running on the AES after all this time!

Apologies for the potato camera. Aside from the obvious fuzziness, the colours are pretty washed out, in particular the orange which in actuality looks pretty much how it does look on the Apple II.

To re-cap, there was one last AI bug in the C port that I hadn't tracked down. It was evident only when comparing the attract mode game play, where the second screen exhibits slightly different behaviour from the guards near the end of the demo. It's lacking the "circular wipe" transition screen (problematic to implement on the sprite-only Neo Geo) and no sound. Those issues aside, completely playable.

We will now return to our regular programming.

Baby Steps

The lack of activity after my last optimistic post has actually been due more to a hectic work schedule than anything else.

A few nights ago I started looking at Asteroids (CoCo3) again, trying to understand where I got to, and also battle a very uncooperative revision control system (which still isn't working).

And tonight I actually did a few simple optimisations to the erase routines. Nothing particularly spectacular, and partly temporary, but at least it got the juices flowing again.

Hopefully more to follow soon...

[UPDATE]

Here's a snippet of the code to erase an object. Originally I had a simple loop, which I unrolled last night. But looking at the cycle counts, I noticed that 16-bit offsets require 8/9 cycles as opposed to 5/6 for 8-bit offsets. Doing the math, I found it was quicker to adjust Y (8 cycles) so that only 8-bit offsets were required. And somewhat annoyingly, coding an instruction with a '0' offset was assembled into a (slower) 5-bit constant-offset instruction, rather than a zero-offset.

ldd #0
std     ,y
sta     2,y
std     1*32,y
sta     1*32+2,y
std     2*32,y
sta     2*32+2,y
std     3*32,y
sta     3*32+2,y
leay    4*32,y
std     ,y
sta     2,y
std     1*32,y
sta     1*32+2,y
std     2*32,y
sta     2*32+2,y
std     3*32,y
sta     3*32+2,y
leay    4*32,y
std     ,y
sta     2,y
std     1*32,y
sta     1*32+2,y
std     2*32,y
sta     2*32+2,y
std     3*32,y
sta     3*32+2,y
leay    4*32,y
std     ,y
sta     2,y
std     1*32,y
sta     1*32+2,y
std     2*32,y
sta     2*32+2,y
std     3*32,y
sta     3*32+2,y

There was movement at the station...

Well, I'm happy to report that I've been thinking increasingly about getting back to my retro projects lately. I've been motivated by a number of diverse factors, and (dangerously) a hankering to start a new project but I've promised myself that I need to finish off a few others before going down that path.

Tonight I actually took preliminary steps towards playing around with FPGA implementations again; not directly Retro Ports but at least in the sphere of retro computing. The impetus for that particular exercise was the fact that I'm back doing FPGA designs for work again. That said, I didn't get far before deciding that what I was researching wasn't feasible at this point.

Nevertheless, I'm still motivated to do something and am intending on redirecting that motivation to finishing off the CoCo3 implementation of Asteroids. It will take me a session or two to ramp up again, but from memory I was about to optimise the graphics rendering, which required some C code to generate the hand-compiled sprites. I would also like to complete the C implementation, which would allow me to port it relatively easily to the Neo Geo.

And I have further plans for Asteroids, but at this point undecided what aspect I'll work on next.

But hopefully I'll be back to regular updates soon.