Friday, 26 May 2017

Variables disclosed as I reconsider the Vectrex

After some discussion with jmk (which can be seen in the comments of the previous post) I'm now reconsidering a Vectrex port. Given there exist a few multi-carts with RAM expansions, I think there's still enough of an audience to make the port worthwhile, especially considering I'll have a 6809 core for the Coco3 - even if it is just a 'proof of concept' playable demo.

That decision aside, just as I was getting bogged down trying to determine the usage of the player data RAM blocks, I notice that much of the work has (recently?) been done for me on a well-known reverse-engineering website. It really is getting to the point where I should reveal the project...

But for now, I'll take this new information and persist with the reverse-engineering whilst the code is relatively self-explanatory. If and when I do hit another brick wall, I'll turn my hand to starting one or more of the ports. I have a deadline for the IIGS port at least...

Wednesday, 17 May 2017

No Vectrex port this time 'round.

Well, that'll teach me - again - not to get too far into a project without checking all the details for intended porting projects! Turns out the Vectrex isn't going to have enough RAM for this port, even in 1 player mode. Wondering if it's possible to design a cart with some SRAM - the connector does have a RW# signal... oh well, it was never the primary target anyway...

As I mentioned, reverse-engineering is getting to the nasty stuff (nitty gritty) and I'm considering commencing the actual porting. My targets now include Coco3 (6809) and Apple IIGS (6502/65816), so I now need to decide which avenue to take. Would be nice to have the IIGS version at least running - if not finished - for the next WOzFest, but given my limited time recently it's a tall order!

Monday, 15 May 2017

Slow going, time to start porting?

Slowly, slowly chipping away at the code; not that I've had much time to spend on it lately, but it's also slow going as all the low-hanging fruit has been... commented!

I'm starting to think that it's time to start on the port, and perhaps work in parallel with the rest of the reverse-engineering. This approach worked reasonably well with Knight Lore, and I've certainly got all the hardware figured out to a point to allow me to do so.

If so, then I'll start with the 6809 port - but not for the Coco3!

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