Pentagram

I've started disassembling the third and last game using the filmation engine.

I must say it does look a bit different. The rumours that the Stamper brothers passed it on to someone else to write may well be substantiated. There's no doubt that they had the original source code though. Very early days yet... will be interesting to see how it compares.

So far the rooms seems to have less objects on average. Means the rendering is probably quicker than Alien 8, which I noticed appeared to be a bit slower than Knight Lore.

And the TRS-80 gets another game...

I've taken the Alien 8 disassembly about as far as I need to for the moment. It should be fully relocatable and identifies most of the subroutines. More than enough to get it running on the TRS-80.

Main menu on the TRS-80

Starting screen on the TRS-80

I've play-tested it for about 30 seconds, so it should be good to go - right?

UPDATE: I've released a preliminary disassembly and alpha TRS-80 binary. See link to Project List in the pane to the right.

Alien 8 vs Knight Lore

I've done a first-pass through the source and labelled all of the subroutines. The code is in roughly the same order as Knight Lore, which suggests they started with the original source file as a basis. A lot of the lower-level routines are identical and a few have minor enhancements. The game-specific routines have the same structure. There are certainly no surprises.

There's no evidence of any significant enhancements to the engine that I've seen. In particular, the maths for the rendering appear almost - if not actually - identical. There are a couple of routines that have unrolled loops, but that's really the only enhancement to the core that I've seen.

There's no appreciable difference in the size of the code, although Alien 8 has (reportedly, I haven't counted) more rooms but (as evidenced in the source) less sprites. Many magazine reviews at the time praised the "improved graphics" but given the above, that's obviously a ludicrous statement.

I'll spend another few sessions taking a closer look at the code but I think it's safe to say that it would make little difference whether I ported Knight Lore or Alien 8 (first) to the Coco3. Taking a quick look at the Pentagram video on YouTube though, it's interesting to see a new mechanic added to the game play - shooting! I might have to take a look at that as well before I start the Coco3 port...

I'm in two minds atm as to what to do with the Alien 8 disassembly. I don't really see the point in commenting 10,000 lines of Z80 when half of them are the same as Knight Lore. I'll probably mark all the identical routines and comment only the differences.

Ditto for a C port - it would probably make sense to have a 'filmation library' with common code.

It wouldn't take much work to make the Alien 8 code relocatable and do another TRS-80 port. Hopefully there'll be some enhancements that can squeeze a bit more performance out of the TRS-80 hardware, although it is at least playable as-is.

Alien 8

I've done a bit more reverse-engineering on Alien 8 and there's no surprises so far. There are less sprites but (seemingly) more code so I expect the objects have more complex behaviour. That aside, a lot of the routines are either identical, or very close. And a lot of the variables are the same too.

It should only take a few days to get all the "generic" code identified and bashed into shape for relocation; longer if I were to comment every aspect like Knight Lore.

And just because it only took 2 mins...

Alien 8 title screen - Coco 3 (MESS)

The palette is pretty rough, especially the cyan...

UPDATES 1,2 & 3: fixed up the colours a little bit

Knight Lore title - Coco3 RGB palette

Alien 8 - Coco3 RGB palette

Pentagram - Coco3 RGB palette

Knight Lore (title) make its Coco3 debut

I still need to give the disassembly a once-over and play-test the C version but I thought I'd get started on a few new things just to keep me interested.

Here's the title screen as displayed on the CoCo3; it uses the original spectrum video and attribute memory dump data, first displaying it in monochrome and then colourising it. Just a quick 'n' dirty hack and the palette could do with some improvement.

Title screen - displayed on the Coco3 (MESS)

The other thing I did was take a look at the disassembly of Alien 8, the next game to use the same engine. It looks very, very similar and I don't think it will be a lot of work to reverse-engineer that as well. I've already defined all the code and data spaces.

I wanted to take a look at Alien 8 before getting too far into the Coco3 port because by all reports the engine was improved in some areas, and there's a chance I might be able to incorporate those improvements into Knight Lore (as well).

Not sure yet when I will start on the Coco3 port of Knight Lore proper, but I still have a few things to do with the source and Z80 version first.

I also have some ambitious (and exciting?) plans for the engine on the Coco3 - but that's quite a long while off yet!

Knight Lore disassembly released

I've released RC1 of the ZX Spectrum disassembly listing on the Project List page (see frame to the right), or directly  here.

I still need to give it a once-over and I'll probably add more comments/descriptions.

Next release will be the Z80 source (.ASM) file.

C implementation of Knight Lore complete!

As the new year kicks into gear it has been difficult to find much time to work on Knight Lore. Whilst I admit the subtleties of the Z-order algorithm continue to elude me, I have managed to port it to C and have what is now a complete, if not fully debugged, C implementation.

No Z-ordering implemented

Z-ordering fully implemented

 

I decided that implementing the algorithm in C would only assist in my understanding of it; and it was definitely true to an extent. Whilst the algorithm is somewhat recursive, ultimately the entire scene is re-processed from the start each time a sprite is ordered and rendered.

 

Surprisingly I managed to implement the algorithm itself correctly pretty much on the initial attempt. However, a few graphics glitches remained and hunting them down has taken longer than the above-mentioned implementation. Two of those glitches were the result not of bugs per se, but rather code that I hadn't yet implemented. Most difficult to track down - I implemented the sprite flip routines quite early on in the piece (as they are used on the main menu screen) and had at the time neglected to flip the sprite mask data as I wasn't using it.

Whilst strictly speaking there's no need for me to understand the Z-order algorithm in any more detail than I do right now for the purposes of reverse-engineering or porting the game, it's gnawing at me. I won't release the source until I understand it fully.

That aside, my next tasks are to give the Z80 listing a final once-over before releasing it and spend a bit more time play-testing the port, ideally completing a game or two. It really will be the first time I'll actually sit down and play through the game just for the sake of playing it.

I've been thinking more about the Neo Geo port and I still haven't convinced myself that it's possible. Then again, the rendering may simply involve a completely different approach as there's no need to wipe and draw, but rather simply (re)assign sprites in the correct priority order. I'm sure I can get something running though as I went through a similar exercise with Lode Runner.

Of course the Amiga port beckons and I'll probably tackle that sooner rather than later as I've yet to develop anything through to completion on the Amiga. It really shouldn't take much effort now that I've laid the groundwork.

I'm also thinking of releasing a somewhat cryptic teaser for the Coco3 port...

Getting some ZZZ's... makes my brain hurt?!?

Back to the grind this week and I've started to analyse the Z-order routine in detail. My brain definitely doesn't work like it used to; it's a painstakingly slow progress. Doesn't help that I only get fleeting sessions late at night to work on it. That said, I've had some 'ah hah' moments whilst lying in bed thinking about it too!

There are 27 cases differentiated of two objects and their relative positions; 7 of those result in recursion (causing other objects to be rendered first), another one (where the 2 objects actually intersect) does something for special objects only, and the rest result in the former object being rendered next. I understand the cases but not the groupings at this point...

Double the fun

No reports of performance on real hardware yet, but certainly fun on an emulator.

Just for kicks I decided to rip the on-the-fly pixel-double code from my aborted TRS-80 Apple II Lode Runner project and insert it into Knight Lore. Some two (2) minutes later I had a full-screen Knight Lore running!

Pixel-doubled - in theory 512x192 full screen

For some reason the emulator appears to be sizing the window for 640x240 resolution, but on the real hardware it should be full-screen.

I've added the doubled .CMD file to the zip archive available for download on the Project List page.

I'm interested to know how it performs on real hardware, because there are a number of optimisations for the TRS-80 that could speed it up quite a bit, both in the original ZX Spectrum code and the quick 'n' dirty code I have added for the TRS-80. As soon as I have commented the Z-order algorithm routine I'll release the ZX Spectrum disassembly and my fully relocatable .ASM file that currently builds for both ZX Spectrum and TRS-80.

Knight Lore on the TRS-80

This is the result of, quite literally, 5 minutes coding. And it really did work first build!

The update_screen() function implemented on the TRS-80

This is the update_screen() routine, used to display the main menu and the screen after entering a new room. Here-on after, the code calls a blit() routine to update small rectangular areas of the screen. I expect that won't be a lot more work either, but right now my daughter is sitting on my lap wanting me to print another Nemo picture to colour in...

UPDATE: added the blit routine, and rudimentary keyboard input to allow me to play the game.

Looks better than my C port with proper Z-order

 It's quite playable on the emulator.  There's one glitch in the blit routine that causes certain frames to appear as white rectangles, but I'm sure I'll work that out before too long.

The really amazing thing is that I've spent about an hour on this this morning, starting with stock ZX Spectrum code. So back in the day, it would have taken the Stamper brothers about a day to produce a TRS-80 version; if the hires graphics hardware had the bandwidth to handle it.

UPDATE#2: the game is running perfectly (under emulation) on the TRS-80.

The glitches were caused by a clash between Knight Lore and the TRS-80 memory map. Knight Lore builds ~4K of look-up tables for bit-shift and bit-reverse in high memory ($F000) for the rendering routines. I simply moved them down low and the game now runs properly; I still had a couple of minor relocation issues to sort. I also coded the proper keyboard logic to support all keys supported on the Spectrum. In theory the TRS-80 port is complete now.

The game appears to run roughly the same speed as the Spectrum under emulation. The TRS-80 CPU clock (4MHz) is slightly faster than the ZX Spectrum (3.5MHz) but the graphics are likely slower.

For academic interest I'll build a pixel-doubled version next, though it'll run even slower on real hardware of course.

Location. Location. Location.

I can't ignore the lure of a quick port to the TRS-80 now that I realise how trivial it will be.

For Lode Runner I used a simple build script for the Coco3 port; this time I've opted for a makefile. The Z80 port will support ZX Spectrum, TRS-80 and possibly MSX2.

The Knight Lore .ASM file is now fully relocatable (yes, I've tried) and obviously I can build the ZX Spectrum version. Next will be the TRS-80. The TRS-80 Model 4 has two (2) hires video modes; 512x192 and 640x240. Using the former, Knight Lore (256x192) will occupy exactly half the screen. That'll be my first pass effort, then I'll produce a pixel-doubled version to fill the screen. I suspect they'll run fine under emulation where there's no contention with the CPU - the real hardware will be a different matter. I'd be especially interested to see how Ian Mavric's improved clone will perform!

Next post should have some eye candy!