We've featured a lot of specials on Indie Retro News, from the Arcade like conversion of Puzzle Bubble to the fabulous Supremacy 30th Anniversary Edition on the C64. Well here we are with another big hitter, as if you remember the classic Mastertronic game of 'Amaurote'; a game which was originally released on the Amstrad CPC, Atari 8-bit, C64, MSX, ZX Spectrum and Electronika BK 0011M in 1987. Then you'll be overjoyed to learn that as of today, Elysium has released their own C64 conversion of the game which as you'll read below, takes the best bits of the Atari 8bit version and more!
New icon colours too? Nice!
As you can see from the screenshot above, already the C64 conversion is vastly different to its top down view point that many were subjected to when the game was released all those years ago on the C64. Unlike the Atari 8bit version which this is a conversion of, in the Atari one you were able to play the game in an isometric viewpoint which was far more enjoyable! Hell, even Crash magazine said the ZX Spectrum version was better which was graphically impressive, well designed and fun to play. It was given a 92% overall compared to the C64 version with just 39% overall! ( Can't fault that awesome soundtrack by David Whittaker though!)
And while I could rattle on about the game and how it could be another GOTY contender towards the end of the year, we've also been provided the story of its development which can be read below by Krzysztof Dabrowski! ( If you want to just download the game, visit the link at the bottom of the page )
"It all started with my visit to the atari.online.pl forum back in late 2014. I don't remember why I looked there anymore, but I read a thread about Jakub Husak accelerating Amaurote. This game has always fascinated me in some way. A long time ago, when I had an Atari (before I switched to Commodore) this game always attracted me. It had a "magic" vibe like no other game on Atari. Plus, I didn't know how to play it :) Which didn't change the fact that it attracted me and I still remembered it very well. There was no good conversion on the C64 (the original version was made on the ZX Spectrum) because the original authors decided that it was not feasible."
Check out those ZX Spectrum graphics, nice!
"It was a completely different looking game (not isometric) roughly "based on" the Amaurote concept and the only thing it had in common with the original was the music by David Whittaker, which, unfortunately, also did not use SID's capabilities.
In the forum discussion, of course, there were a few traditional sentences such as that "probably can't be sped up on Atari" and that "this game can't be ported to C64 FOR SURE". As Kuba allowed himself to be "provoked" by the first sentence and sped up the game on Atari - there was a real possibility to transfer it to the C64 as well. The Atari 800 has a processor clocked 70% faster so - considering that Kuba sped up the game by 50% - I could count on the conversion to the C64 to be only slightly slower than the original Amaurote on Atari; which means it will be fairly playable. Of course, I took it as a "for myself" project, initially without the goal of actually releasing anything, to learn what it takes to make such a port between platforms.
I realized that this is not a game that hundreds of players in the Commodore community are impatiently waiting for. :) Amaurote on one hand was also quite a "nasty" game to port because it relied heavily on raw CPU power; but on the other hand, because it did not use too many unique hardware features of the Atari 800 - it was certainly not “impossible” (to give an example the other way around: C64 games that use intensive colour attributes and multiplexed sprites would be rather poorly suited for portability to Atari)."
This is what the original C64 version looked like..... What the!?!
"I started all the fun in December 2014 by learning the A8 platform, which I knew very little about (back in the days when I had an Atari, I was just taking my first steps in programming, so I remembered a bit - but I didn't know modern tools, nor did I have a memory map in my head). I work on a Mac daily, but for the exercise, I set up a virtual machine with Windows and the Altirra emulator (https://www.virtualdub.org/altirra.html) about which I heard only good things. After a few hours of fun, I had some kind of "field orientation" - I managed to unpack Amaurote+ by Kuba, strip it from the intro and all the depack routines and save it as a binary memory dump just before the game itself started. So, I had a "clean" unpacked version which I converted to a .xex file that I could run in the emulator.
My first goal was to reassemble the game and generate sources that I could assemble with Kick Assembler but still run on Atari. Some quite tedious work began with Regenerator (https://csdb.dk/release/?id=149429) which is, for me, the best re-assembler to work with 6502/6510 code at the moment. Regenerator generates source code that is compatible with Turbo Assembler (this is the most popular native C64 assembler, which also has a cross-version: http://singularcrew.hu/64tass/). Since 64tasm did not support A8 (back then), I had to add my script that converted the C64 binary to Atari .xex - and at that point I had an assembler that could emit binaries on either C64 or Atari, depending on how I started it. The job was to mark memory blocks, decide what is code, what is data, what is lookup tables with addresses etc., I generated sources and then assembled the resulting code, generated .xex and binary compared it with my reference Atari file - to be sure at all times that I have not spoiled anything. After a week or so (I'm using the git repository history to refresh my memory because some time has passed) I had a version that I was initially happy with.
On the Commodore 64, I normally use excellent KickAssembler cross-assembler (http://www.theweb.dk/KickAssembler/) and at this stage, I converted the sources to its syntax (and of course verified if the still generated .xex is binary identical to the Atari version).
Since then I have been working on this version of the code. I started a more advanced "beautification" of the sources so that I could work with them meaningfully - a lot of work went into discovering what each block of memory and code were for and replacing the labels generated automatically by Regenerator ("a47bc", "j6724" with a homelier sounding "play_music" etc.). While analysing the code, I also found the DisplayList, which allowed me to start to get an idea of how the graphic data is arranged - and start to plan how I will arrange it on the C64."
After another week, I finally managed to get in touch with Jakub Husak, who was so kind that he shared his sources for Amaurote, but for the Atari 130 version - on one hand, I couldn't use them directly, but on the other hand, they were an invaluable source of information about the memory locations. Put simply - where Kuba determined what a piece of code or data did and assigned it some human-readable label - I could copy it and change my sources accordingly. While working on Amaurote on-and-off until May, I moved the labels from Jakub’s to my sources plus worked hard to convert as many different tables with addresses from binary versions to references, so that I could have the most relocatable code possible. At this point, I had to "unfasten my seat belts" which is my binary comparison with the Atari version, use the “chainsaw” and start reworking the game to run on Commodore.
The most important decision I had to make was which graphics mode I would use. Amaurote on Atari uses the dream-mode - hires with a horizontal resolution of 256 pixels. For the coders - a fairy tale. Linear addressing, regular line start addresses every $20 and it takes less memory than a standard 320px wide screen. Of course, there is no such mode on the C64, and if I used standard hires, I would have a lot of free, unused space, but unfortunately discontinuous - I would have such "cupcakes" of $40 bytes scattered around with which it would be difficult to do something meaningful. In addition, I knew that I could not afford to waste memory - because even though I had a bit more memory available than on Atari (on Commodore 64, after disabling the ROM and IO registers, we have access to the entire 64kB RAM).
The initial code analysis showed me that I would need as much free memory as possible for Commodore-specific code. So, I decided to use the text mode with properly defined character generators and thus get exactly the same resolution as on the Atari, but without the waste of memory. I converted the graphics from the Atari version to Art Studio files to be able to process them sensibly and in the code created KickAssembler macros which, during assembly, loaded images, cut out the appropriate areas of the graphics and converted them into character generators on the fly. At this point, I knew that one piece of code would be very difficult to transfer directly to the C64 - it was the music.
I figured I would fix this later, but by (temporarily) throwing the music away, I got a piece of contiguous memory that I could use to write my code snippets for conversion. Even though 99% of the code looked relocatable - I didn't want to take any unnecessary risks, so all modifications to the old code kept the addresses of the procedures etc. and - if necessary - just jumped to my code instead. And if any old code was unnecessary, I either replaced it with NOPs or cut it; but so that the next routine in memory was still assembled to the original address and a small empty space was created in the code (potentially to be used later when I had to stuff new code somewhere to make room again for the music for example).
In the beginning, I wrote a C64 version of the interrupt handlers, with which I could construct the screen (on C64, we have to switch the addresses of character generators at the right moment of the screen, which on Atari is done through DisplayList). I deleted all access to the Atari hardware registers (they would not do anything sensible on C64 anyway, but rather guarantee problems). The entire start code of the game was removed because, in the original, it rearranged the data in the memory, cleared the buffers, etc. - which I already properly arranged in the source code. Finally, I injected my setup code - and it was time to start the game for the first time.
Relatively quickly, I managed to get the title page to run. I've also tweaked the joystick routines so that I could try to launch and play the game. At that moment I had "something" that I could start with the joystick button, the entire screen was trashed without mercy (my screen organization was only dimensionally the same as on Atari - the memory layout was completely different) and sometimes it even crashed (which was caused by the fact that it overwrote various data structures and the code went crazy). I adopted a strategy of disabling as many functional pieces of code as possible by inserting RTS at the beginning of the procedure (to bring me to a state where the game starts without all the beautifiers, transitions, animations, deleting sprites and with the panel at the bottom turned off) and step by step I got to a point where I had a game that might not look good - but it didn't freeze or trash the memory (too much :). Of course, it was impossible to play, but it was the first step.
At this point, the story ceases to be romantic and becomes tedious and long. It took me 7 years to work on getting Amaurote to work properly :) (of course, not continuous work). I've had activity-bursts where I “invested” a few hours a day for a few weeks, but I also had breaks for over a year. I have to admit I got stuck at the end of the "last mile". 90% of the game was working fine, but I had some pretty nasty bugs that I couldn't track down. For the last 3 years, the work was like that, after the New Year, I was going back to the game, telling myself that this time it would work - I worked in January/February - I was moving my work forward, then life wrote me a different script and the game ended up in the archive again.
C64 conversion screenshot
But as you can see, I didn't give up and in 2022 I made a breakthrough: I fixed all the serious bugs, and even spent a week trying to fix a bug that turned out to be in the original Atari code as well (it sometimes caused graphic glitches - only the Atari had an unused piece of RAM and the bug was trashing the memory there, but you couldn't see its effects, but in my version on the C64 there was graphic data there, so the result was quite spectacular). After a week I gave up and sacrificed $200 of RAM, rearranged the data to also have free space where the object drawing routine likes to mess up sometimes, and this is how I got to the point where I had a fully working game with one bug not interfering in the game (if, when entering a new district, the game draws a fly on the first screen, it will leave a trace when it moves, this trace disappears when we go further with Arachnus) and I turned off the explosion effect when a fly or an object is hit by a bomb. The original explosion procedure is complicated and slow and would force me to convert addresses on the fly to C64 screen organizations - which would make it even slower; so, I decided that it was not worth the effort (and I did not want to take the risk that the game would end up in the archives again for a year, as soon as my New Year's enthusiasm ran out).
Finally, I rearranged the data a little more to get the largest continuous memory areas possible since I had to fit the music back in. Instead of the original, a new soundtrack was written by Michał Hoffmann (Randall/Elysium) - and apart from being great, it also uses a player that is using less rastertime than the original, which in the case of Amaurote is critical - as much CPU time as possible must be available for drawing graphics. There is also a new title image in the C64 version, which was painted by James Svärd (Joe/Wrath Design) - similar to the music - this is a high-quality graphic that takes full advantage of the Commodore 64 capabilities, but at the same time is stylistically reminiscent of the original.
As an additional "bonus" I prepared 2 special speed-ups of the game: If we run Amaurote on Commodore 128 (in C64 mode), the game uses the 2MHz mode of the processor (off-screen), which provides a 30% increase in game speed and everything starts to be really smooth. The game disk also has a version for SCPU, Turbo Chameleon and Ultimate64 accelerators - all in 20mhz mode. In this case, I had to slow the game down a bit to make it playable and rewrite the interrupt routine to construct the screen so that everything was displayed correctly. This is the only version of Amaurote for 8-bit platforms with no slowdowns. :)
In the end, I would like to thank Jakub Husak, first of all, because it was thanks to his work on speeding up Amaurote on Atari that this port was possible at all. To paraphrase Isaac Newton, "If I can see further, it is only because I am standing on the shoulders of a giant"! Thank you, Randall, for writing the soundtrack first, then waiting 7 years, and finally writing one more when I found out that I have not enough memory to fit the first (but I did not let good music go to waste, however, and you will hear it is shown in the title picture and the file with the manual for the game) - I love you, master. Bows to Joe for the title picture, graphics for the game manual, testing and the idea for the only sensible trainer for the game - slowing down the flies.
Working with you on any production is pure pleasure, and your professionalism and pace of work constantly embarrasses me. :) And finally, greetings to everyone from Elysium, who probably still do not understand why I was spending my time porting this game and especially to Digger, who regularly told me to "make a demo instead". :) Also deep thanks to Slammer/Camelot for Kick Assembler, Tom-Cat/Nostalgia for Regenerator, Avery Lee for Altirra, 64tass Team, Slajerek for C64Debugger, VICE Team for VICE and all other smaller tools authors that I’ve been using.
Links :1) AVAILABLE FOR DOWNLOAD HERE
No comments:
Post a Comment
Please read before commenting : Constructive criticism allowed, but nasty comments will be removed and IP banned! Banned users will not show up in my comment feed - Play nice, ((ENGLISH ONLY)) and enjoy IndieRetroNews! :)