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.

False Alarm!

Heh! Before you read any further, there hasn't been any more progress on any of my projects.

I thought I'd write a quick update on the status regardless. The upside is that these projects are not far from my consciousness and I still have an interest in finishing them off.

Just a few weeks ago I bundled up the latest version of Knight Lore for the TRS-80 Color Computer 3 and sent it off to someone who is going to be releasing it on cartridge for sale. Hopefully. I thought for a brief moment that it would motivate me to resume my projects, but alas it hasn't been the case thus far. Perhaps when I see it announced for sale...

I recently sold a few retro bits 'n' pieces - mainly manuals & microcomputer software - and my favourite arcade cabinet, to fund the purchase of something else completely unrelated to retro gaming. Yes, it was my favourite cabinet but the reality of it was that it was rarely turned on, it was just too big for my (rather small) games room, and I have designs on building a Viewlix cabinet one day. I still have two (2) cabinets so I let it go for the cash I needed.

On the flip side, I've recently purchased a video demodulator, video/rgb scaler and CFFA3000 card - and have plans to buy another video demodulator - so it's not like I've lost interest in retro gaming.

So back to the projects. Usually around this time I think of another project I want to start and then focus on that instead of finishing the previous one(s). This time however, that's not the case. So first cab off the rank will be to finish optimising Asteroids for the Coco3, then back-port it to the Apple IIC+ and the IIGS. I also want to port it to another platform - TBA.

I've been thinking again about the Neo Geo, and finally picking up Donkey Kong again. Especially now that the NeoSD, and whatever DarkSoft's equivalent is, are well established in the marketplace.

Just a matter of when I get the urge again...

From beyond the grave

Well, perhaps that's a little dramatic.

Thought I might post a quick status of the project(s)...

The simple fact is that over the last 6 months or more, I just haven't felt motivated to work on any retro projects at all. And to a degree my interests in other (non-development) areas of the retro hobby have diminished as well. I can't offer any concrete explanation as to why, other than my priorities have of late moved away from the computer keyboard and into other areas of my life.

Having said that however, I haven't felt any urge to give up the hobby altogether, or even to scale back my collections or range of interests in retro video games and microcomputers. To the contrary I've actually picked up a couple of books and a few new pieces of hardware in that time, and have my eye on yet another. Not that I've read or used any of those recent acquisitions.

So I'm confident that, when the time is right, I'll resume my retro hobby and - more to the point for this blog - my porting projects. My resolve is to finish off the projects that have languished, most (but not all) incomplete, for an embarrassing length of time and just release them to the public. And although I had previously earmarked the next few projects, I'll likely reconsider those when the time comes.

For now, I can't offer any further insights nor when I'm likely to resume my porting projects. I won't really know until I'm actually ready to do so. But perhaps the very fact that I've been inclined to update this blog is a good sign?!?

On Yer Bike! (Or at least, My Bike)...

Since it has been over 2 weeks since the last update, I thought I'd better post something.

Whilst I have been focusing on life off the computer lately (namely an 82km fun/charity bicycle ride) I have managed to make some progress. What I haven't made any progress on, however, is the elusive 'pass right through some objects' bug.

As a first step towards compiled sprites, I computed the pre-shifted bitmaps for the asteroids. Still largely unoptimised, they at least eliminate the need for a pair of table look-ups for every byte rendered on the screen, and the associated set-up calculations required for that. The extra data also required that I start to use the lower 16KB of the cartridge ROM area.

Unfortunately I can't find the speed/profile numbers that I thought I'd recorded for the game before changing the asteroids. I could quite easily restore a copy from version control, but I'm too lazy to do that at the moment. FTR though, the start of the attract mode is now running about 33% too slow, keeping in mind that the I've only changed the asteroids, and they're still not compiled sprites.

One thing I did notice when counting cycles in my new code though was that there may be room for improvement in my Knight Lore sprite rendering routine. I had previously assumed the post-incrementing index instructions were the most efficient but depending on the situation, it may be faster to use a series of 5-bit constant offset instructions and then adjust the index register (LEA) afterwards.

Next step is to produce compiled sprites for the asteroids and see if that makes much difference. If my theories are correct though, it probably won't make as much difference as pre-shifting the data.

Flicker-be-gone! (mostly)

No progress on the collision-detection bug so I decided to implement the double-buffering (page flipping) since it is almost trivial and won't be affected by any other programming issue.

The arcade machine uses a pair of so-called "ping-pong" buffers to allow the DVG to render the frame whilst the CPU is building the next frame. This comes in very handy indeed on the raster ports (Apple IIGS, Coco3) when erasing the previous frame before rendering the current frame.

Of course double-buffering requires erasing the frame prior to the previous frame. The easiest way to implement this with the current architecture is to extend the 2x buffers to 4x and modify the "ping-pong" logic slightly. No more than a handful of instructions in a few strategic locations...

At this point the game is running quite slowly due to the sub-optimal (to put it mildly) erase/render code, so there's little point synchronising the page flipping to the VBLANK and therefore the video still exhibits some flicker. However it is much improved and gives a taste for things to come...

UPDATE: Tonight I thought I'd add some profiling code before starting on any more of the optimisations. When you first start a game (with 4 asteroids on-screen) it's hovering around 55fps. When things get a lot busier, it's down around 20fps, and the lowest I've encountered is 13fps. And when there's all-but-nothing to render, it hits 89fps.

Will be interesting to see where it goes from here...

UPDATE 2: I've just optimised the copyright rendering. The copyright is unique in that it is rendered every frame, in a fixed location, and therefore never needs to be erased.

After some experimentation, and without resorting to stack blasting (which I can't see being optimal in this case due to the OR'ing operation), I came up with the following for each line of 4 words (Y is the video address):

LDD #0x1234
ORA ,Y
ORB 1,Y
STD ,Y
LDD #0x5678
ORA 2,Y
ORB 3,Y
STD 2,Y
...
LEAY 32,Y


That's the best I can come up with late on a Friday night (37 -> 22/24 cycles/line). Improvements welcome!