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

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?

Monday, 30 January 2017

Knight Lore all-but-complete!

Today/tonight I fixed the RNG seeded by the ZX Spectrum FRAMES system variable, which determines starting location, amongst other things. Now, at least, the starting location is actually random.

The final fix was the sun/moon graphics glitch on the left/right sides of the frame, invisible on the ZX Spectrum because of the video attributes in use. For the Coco3 port the easiest fix turned out to be simply manually extending the frame sprites, with respective masks, which (IIRC) is what the Amstrad CPC port (and likely others) do.

No more sun/moon graphics glitch left/right of the frame!

The only thing left is to tweak the ballast code in the main loop to slow down 'empty' screens. I've made a quick attempt but will probably spend more time comparing against the ZX Spectrum version before it is finally released.

I've sent out a few copies for testing and review... so hopefully it'll appear on YouTube at some point in the near future!?!

Still undecided on release options...

Sunday, 29 January 2017

A (K)Night of Random (Number) Thoughts

It actually took a couple of more sessions but I've finally got joystick support working in Lode Runner. Thankfully there don't appear to be any key ghosting issues. I've packaged up a release which is available from the download page (link to the right).

I need to talk to a few people about cartridge hardware, but I'm leaning towards simply releasing a floppy disk version for free, rather than have it sitting on my hard disk for another 3 years! It was never about the money, but rather the satisfaction of releasing something tangible for the Coco3.

I also did some further work on Knight Lore tonight, in preparation for another release to a tester and a reviewer. I beefed up the random number generator which 'emulates' the Z80 R register. Research indicates that the register is incremented every M1 cycle, which can be once or twice per instruction fetch. That's certainly beyond software emulation, so instead I implemented a 16-bit maximal Galois LFSR which is very efficient to implement in assembler. The LFSR is clocked every 1/20th of a second, using the GIME TMR function and 6809 FIRQ, and the Z80 R register 'emulated' by reading the LSB of the LFSR value. Plenty random enough for the purposes of Knight Lore.

One more seed in the original code is read from $5C78, and is used to generate (amongst other things) a random starting location in the map. Tonight I discovered that this is in fact the LSB of the FRAME (frame counter) system variable on the ZX Spectrum - so when loading manually from disk, relatively random. Right now I don't have a good substitute, so the start location tends to be, well, not so random.

Once I fix the seed above, I need to fix the sun/moon frame glitch in the panel, which is invisible on the ZX Spectrum courtesy of the video memory attribute bytes. On the Amiga/Neo Geo C ports I used the panel graphics from the Amstrad CPC version, which overcomes this issue. However on the Coco3, the easiest solution (I think) will be to implement a hack.

Then I will be able to release for beta testing & review; and then subsequently decide whether to release it (again) for free on floppy, or have a cartridge produced. I'm leaning towards the former, with the possibility of releasing the CPC graphics version on cartridge, possibly together with Alien 8 and Pentagram!?! That's a longer term project though...

For now I just want to tick off all outstanding incomplete projects.

Tuesday, 24 January 2017

I've forgotten more than I know...

The perils of leaving a project for months - or even years - is that it takes some time to come back up to speed, and even then for a while you're subsequently discovering plenty of details that you've completely forgotten - most of which, unfortunately, result in head-scratching bugs.

A case in point is the joystick support for Lode Runner, which would have been trivial had I implemented it back when I first released it. Now, however, it has taken two sessions and I still don't have it working correctly.

I've spent the last hour or more trying to make sense of the crash I introduced when adding the joystick read routines. For at least 20 minutes nothing at all was making sense; the disassembly in MESS wasn't matching the 6809 assembler listing. Finally I figured out that I was specifying the wrong file as a cartridge image. What made it more elusive was the fact that it actually displayed the (corrupt) splash screen...

That stupid mistake finally sorted, it wasn't getting much easier as the code still crashed, albeit in a different manner. Cutting out code line-by-line I finally got it running again, and then narrowed it down to a single call to the joystick read routine. I couldn't see anything wrong there... but then noticed the length of the ROM image in the makefile output was suspiciously pushed over a 256-byte boundary when crashing. Further analysis revealed that the code was now too long and as a result I was overwriting high memory. Easily fixed by removing the 10th level from the image.

Unfortunately after all this I don't have the time or the energy to muck about with getting analogue joystick emulation to work in MESS and finalise the joystick support. I am however, reasonably confident it'll only take one more session.

I'm now leaning towards releasing both Lode Runner and Knight Lore for free as disk images. The latter could also be programmed into an EPROM or FLASH cartridge as it doesn't require any special banking support or otherwise... I simply don't have the time to dedicate to getting the cartridge productions under way.

Thursday, 19 January 2017

Joystick 'routine'

Now that our holidays are over and we are settling into the routine for the new year, I've allocated some time to working on outstanding projects that need to be finished before I start any others. The freshest in my mind is the addition of joystick support to the Coco3 port of Lode Runner.

So tonight I did exactly that, and implemented routines to read the Coco3 joystick and buttons in the same manner as the original code (as far as possible). The good news is that the joystick axes are only read in a single place in the code, and the buttons only a handful of places - which I've coded. I had it starting a game and digging left/right with the joystick buttons.

The bad news is that after configuring the PIA to read the axes, it subsequently crashes when you start a game. I haven't had a chance to look into this any further, but presumably it won't be too difficult to track down. I still suspect ghosting will be an issue though...

Then there's the '86 GIME crash issue to get to the bottom of...

I also need to reconsider holding off on a release until I design a cartridge. It's been an embarrassingly long time since I released the demo, and I have to question whether or not I will ever get around to producing a cartridge for it. If not, I need to code DOS routines so that the game will load the level data from the floppy disk and just get it out there.

Next task should be to release Knight Lore. All it requires is tweaking the speed against the Spectrum original - and confirming it runs no slower - and it's good to go. It also requires nothing more than a standard cartridge, so it could be released with minimal effort.

I suspect once I release Knight Lore on cartridge I'll be able to make up my mind on whether or not I want to release Lode Runner on cartridge as well, or simply release it for free on disk.