Monday, 17 April 2017

Update 'tweet'

The 'new project' continues - more reverse-engineering tonight.

I'm in two minds as to whether or not I should reveal what it is. On the one hand, I don't want to preempt something that may never happen; on the other, why the big mystery?

If I haven't mentioned already, I'm thinking of porting to the Apple IIGS (as well as the Coco3).

Wednesday, 12 April 2017

Not Space Invaders

After more-or-less finishing off Invasion Force, work has kicked up another notch and I've had very little time for anything else. And unfortunately, retro ports is pretty low on the list of priorities at the best of times.

Tonight, however, I had a spare hour or so and returned to reverse-engineering the new project. Yes, I have neglected Space Invaders yet again, but the ramp-up time alone on that project exceeds my spare time atm. At least I was able to comment a few more routines (eg. scoring) and a data table.

At this point if I had to make a guess, I would say I'm about 25% of the way through the reverse-engineering process. But working haphazardly on the project isn't conducive to making quick progress, and if I continued at tonight's pace it would take me several years to get it done. To work efficiently it all needs to be fresh in your head which of course means regular sessions.

I'd like to think I can find some small amount of time each evening in the coming weeks to work on this, but I know from past experiences it's usually feast or famine... all I can do is try.

Thursday, 30 March 2017

Star Trekkin' Across The Universe...

No-one will be surprised that I've been side-tracked... again.

This time, it was Dan's fault for asking on one of the TRS-80 groups if anyone had fond memories of Invasion Force, as he was re-coding it in some modern scripting language, or something like that. And if that wasn't dangling the carrot tantalisingly enough, he even posted a screen shot of his progress!

Invasion Force was a machine language 'real-time' version of the classic Star Trek games that was sold by Tandy for the TRS-80 Model I. Although in my opinion not as good as Time Trek, I did play it back in the day and do recall enjoying it.
 
Invasion Force on the TRS-80 Model I

A bit of research yielded some surprising information; the game was first written for the SOL-20 microcomputer, and released as TREK 80. With the demise of the company Tandy somehow got hold of the source code, ported it to the TRS-80 Model I, and released it as Invasion Force.

The original SOL-20 version, TREK 80

Anyway, I decided to dig it out and, as any retro porter worth his salt would do, immediately start disassembling it. If nothing else I'd be able to provide Dan with some "inside information" should he ask.

In the end, it was a pretty straightforward task. It's not the most elegant or efficient Z80/TRS-80 code that I've ever seen either, but to be fair it was written in 1977. After completely reverse-engineering the TRS-80 version, I went back and named all the labels in the SOL-20 version. It's clear minimal changes were made to the code when porting to the TRS-80.

CORRECTION: It was, of course, 8080 code, rather than Z80.

When reverse-engineering the TRS-80 version I discovered two bugs.

The first bug has been ported from the SOL-20 version. Not worth the long-winded explanation but it's basically a table-lookup that extends beyond the table bounds during a delay routine when you run into a star - it's quite benign when all is said and done.

The second bug was introduced into the TRS-80 version. One of the experimental ray (random) outcomes is supposed to render all Jovian vessels in the quadrant invisible; instead it renders all Space Stations invisible. Because the SOL-20 and TRS-80 versions use different characters for their short-range scanner displays, the value(s) representing the Jovian vessels in the code had to change, and it was changed to the wrong value.

There are remnants of code in the TRS-80 version that isn't called that appears to be debug code. There's extra code - in the same spot - in the SOL-20 version that I haven't looked at yet. There are also some very minor tweaks to the TRS-80 version, some of which result in "dead code" from the original. And one hidden command not documented in the TRS-80 manual is the "L" command to leave the game, which jumps to the Level II BASIC entry point. Somewhat confusingly, the TRS-80 manual implies there is an "L" command for Long Range Sensors - so I expect people tried this and had the game subsequently 'crash'!?!

I now have a TRS-80 version that is fully relocatable, builds and runs. Someone suggested changing the directional controls (0-7) to more sensibly map those on the numeric keypad, which I might do. It's also tempting to convert the text to mixed-case, and fix the experimental ray bug.

And what about porting it to another platform? Aside from the Microbee, which could be done in a single afternoon, I doubt there'd be sufficient interest to warrant the effort. Every platform under the sun already has several Star Trek clones, and Invasion Force doesn't offer anything exceptional.

A fully-commented disassembly listing for the TRS-80, a fully-labelled listing for the SOL-20, plus the relocatable TRS-80 source, can be found on the Project List & Downloads page to the right.

UPDATE: I've added a few enhancements to the TRS-80 version, each of which can be individually enabled/disabled in the build. These comprise:
  • ORG $5200 for compatibility with disk systems (source is fully relocatable)
  • Mixed-case messages throughout the game
  • Fixed the Experimental Ray bug that makes Space Stations invisible instead of Jovians that was introduced in the TRS-80 port (untested)
  • Modified direction controls to map to more intuitive numeric keypad layout
Full source and binary in the zip archive.

Monday, 20 February 2017

time=950 billion ms

Well, unexpectedly I received responses from both programmers on the same day, and both were supportive and helpful which is great!

There was some confusion about which revision of the game ROMs I should be using as my starting point, but that's now sorted. Fortuitously (although not critical to my needs) both the reverse-engineering effort and the port/emulator are based on the same revision!

After the feedback I received I've officially decided on the next Coco3 port.

But back to Space Invaders for now...

Thursday, 16 February 2017

Ping timed out.

Just a quick note to say that I am still working on Space Invaders. Slow going as I'm still coming up to speed with how it all works again, but at least now the shields are in approximate position, albeit yet to be rotated.

Interestingly a thread in an Apple II programming group led to a brief discussion on Apple Invader. Now that was an impressive home conversion back in the day, and would have been a little easier to port to the Coco3 than the arcade original... but not quite as cool?


Still been thinking about the next Coco3 project. It would be fair to say that this game is an unlikely candidate for a Coco3 port due mainly to the hardware used, and that's a big part of the attraction for me. Surprisingly it has actually been ported to other 8-bit machines! I've approached two different programmers that have worked on either reverse-engineering or porting the original, but neither have deigned to respond thus far.

Never mind, I think I have the technical details worked out. Just would have been nice to compare notes and perhaps get some insight into the performance I could expect on the Coco3 without having to employ further trickery...

Tuesday, 7 February 2017

The Space (Invaders) - Time Continuum

With Lode Runner and Knight Lore in a holding pattern for very different reasons, as promised I turned my attention back to Space Invaders tonight. It wasn't easy as the temptation is there to start on a new port altogether, but I'm resolved to finishing off the existing ports before starting any more.

[On that note: not-so-good news for Coco fans is that the C port of Lode Runner (Neo Geo plus other platforms) will be next on the list and then finally I intend to return to Donkey Kong on the Neo Geo now that my NeoSD AES should soon be shipped! However I still have at least another two, and possibly more, Coco3 projects in mind that I'm keen to start!]

Nothing terribly exciting to report but tonight I have reverted all my on-the-fly rotation code and gone back to 12th May 2016. Somewhat prophetically, I last backed out these changes on... Friday 13th May 2016! I do, however, need to review some fixes I did subsequently after moving the video RAM base address.

As it stands attract mode runs (with rotated text) and the alien rack is displayed (also rotated) before the game appears to crash with small areas of corruption on the screen. Encouragingly, this is exactly what the SVN log describes!

Attract Mode (crash)

For latecomers: I should note that (behind the display) the Coco3 port is actually completely finished; you can coin up and play a game on a rotated monitor. What I'm in the process of doing now is modifying the code (and sprite data) to display in the correct orientation on the Coco3. Essentially, I'm (simply) rewriting all the rendering routines. It's a bit more complicated than that, but (hopefully) not terribly so.

No doubt it'll take a bit of time to come up to speed with where I was at and in the process I'll probably remind myself of why I opted for the on-the-fly tack... but ultimately this is unquestionably going to run fast enough (with enough headroom to add sampled sound), and the alternate wasn't looking quite so good.

Sound advice

Recently I've been looking at the Lode Runner sound issue (sound is all-but-muted when you enable the joystick) and last night I managed to solve it.

It took a bit to wrap my head around the correct configuration of the two PIAs for joystick and audio support, further muddied by the fact that the Coco has both 1-bit and 6-bit DAC sound generation. Fortunately I found a rather helpful block diagram that Tim Lindner put together that finally enabled me to visualise how all the bits work together.

I had originally assumed that my joystick sampling was inadvertently muting the sound. What should have tipped me off though was the fact that the sound was still there, just very much lower when joysticks were enabled. It turns out, however, that my problem was that I was not muting the sound; the circuit was mixing the 1-bit sound (which FTR can't be muted at all) with whatever state the joystick sampling left the DAC in and the result was barely audible sound from the game.

Once I muted the (DAC) sound during initialisation,the rather basic beeps and boops that are Lode Runner sound were perfectly audible, joystick or no (new release available on the download page linked to the right).

And since I had used the same routines for Knight Lore, it had the same issue - which has subsequently been fixed.

I have been thinking more about the release of Lode Runner (in particular) in the past week or so. When I first ported it I really wanted it to be a cartridge release; not to make any money but just to have at least one tangible Coco product to my name. My thinking was to create a flash cartridge with Lode Runner on it, that the buyer could also use for any other purpose.

However Jim Brain over at RETRO Innovations recently designed an 8MB Flash Cartridge for the Coco line of computers which also includes (and I may have suggested this) a serial EEPROM and (I definitely didn't suggest this) Orchestra 90 emulation.

Although this product is certainly overkill for Lode Runner, it's also - I feel - too expensive to sell as a game cartridge. I'd also like the Lode Runner cartridge to be housed in one of the new shells recently produced for the Coco, with its own "Lode Runner" label.

At the same time I don't want to re-invent the wheel, so in the last day or so I've had the idea to produce an EPROM-based cartridge with a small CPLD for banking and a small serial EEPROM for high score saves etc. Ideally such a cartridge would accept up to, say, 256KB EPROMs (although 1MB would be better) and would be suitable for my other current and future porting projects. The primary design objective is keeping it simple and cheap.

If that gets off the ground then Knight Lore should follow suit soon after.

Shortly I'll turn my attention back to Space Invaders, and finish off the coding for the hand-rotated version, which should have no trouble running at speed on the Coco3. I hope then to be able to add sampled sound, and I have always intended to release it - with source code - for free. Perhaps there'll even be a cartridge release for people that really want one?