Monday, 29 October 2018

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.

Thursday, 11 October 2018

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...

Monday, 25 June 2018

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?!?

Monday, 13 November 2017

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.

Friday, 27 October 2017

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
LDD #0x5678

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

Tuesday, 24 October 2017

A progress report on lack of progress.

Today I had the chance to review the collision-detection code. The bad news is that I couldn't see anything amiss. I did find a few minor issues to do with ADC/ADD but they don't appear to be the cause of the bug. I also managed to effect a few minor optimisations.

I'm still hanging my hat on an issue with the core code, rather than the display mapping. I say that because a lot of the time the shots and objects are spot-on - even the small asteroids and small saucer - but then a shot will pass right through the middle of the large saucer. That's not just a few pixels off... more like a logic bug.

Aside from revisiting the collision-detection code again, I don't have any further theories on the matter. This might turn out to be a tough one.

I've been holding off on the optimisations up until now for a few reasons. One, it's simply nice to have the rest of the porting 100% complete. Two, it's easier to tweak things like display mapping with brain-dead code. And finally, I didn't want to find myself in the situation where I had to re-optimise certain routines because something fundamental wasn't quite right.

Having said all that, I'm wondering whether it is actually safe to press on with the optimisations now and revisit this issue down the track - assuming it doesn't have anything to do with display mapping. I don't want to get bogged down debugging this and lose momentum (again).

At least part of the optimisation - double buffering - won't be affected either way and should be relatively straight-forward. From there it gets more involved with compiled sprites, but I could get a start on objects such as text and the copyright message.

Have to think about it...

Monday, 23 October 2017

Even more display tweaks, looks even better. Still not perfect...

More tweaks to the display mapping, and it's improved even more. There was an offset added in the core (arcade) code when adding the CUR command to the DVG display list that must be peculiar to the vector hardware; I needed to remove that offset to enable objects to use the entire 192 lines of the display. Norbert didn't have this issue because he all-but ignores the display list, except for rendering text and his seemingly arbitrary offset (after scaling) accounts for it - and now makes sense of course.

I've also added clipping to the screen for all objects except the exploding ship. My explosion rendering code differs quite a bit from Norbert's; he uses a generic pixel-plot routine that handles the clipping (it'll render pixels outside the visible display on line 191, which is odd). I will probably not bother with clipping until I optimise the graphics for the Coco3.

After a few more hours of coding and comparing the Atari and Coco3 versions, I'm convinced there's still an issue with collision-detection (apparent in the video below). I'm reasonably sure it's not the display mapping now as sometimes the shots go straight through the middle of the large saucer, and occasionally you can't seem to hit the smallest asteroids. I simply cannot reproduce either bug on Norbert's emulator.

So now I need to go back and review the collision code which is not altogether surprising since it pretty much "worked" straight away. In fact I'm hoping that is the issue because otherwise everything else seems spot-on now, and I can definitely move on to Coco3 optimisations once this issue is sorted - something I've been itching to do for some time now.