The most evolved text adventure engine in the series that started with The Quill was DAAD, the engine made by Infinite Imaginations for Spanish company Aventuras AD.
Aside being a tool made for developers and not for general public, which has its cons and its pros, it was made for a company, which means decisions were sometimes taken with profit in mind. Sometimes profit comes when saving time and money, and that’s exactly what lead us to what I’m about to describe: the unnecesary (technically speaking) limits set to the Commodore Amiga interpreter.
The Spanish market
Aventuras AD was a Spanish company, with several shareholders, being Dinamic Software the one with the largest share, probably followed by Andrés Samudio, its Managing Director. Dinamic Software had created a few text adventures before, the first ones made without a proper text adventure engine, and the last ones -during the years just before Aventuras AD was created- using the Graphic Adventure Creator (GAC) .
When Samudio approached Dinamic willing to get his “Diosa de Cozumel” adventure published, he got a deal -and a challenge- instead: creating the first (and so far last) Spanish company decicated exclusively to create text adventures.
Software piracy was very common in Spain by that time, but a smart movement started by ERBE Software some months before, which was soon followed by other companies (Dinamic included), had changed the game, and sales of Spanish titles were much higher. ERBE decided to reduce prices for their 8 bit catalogue from about 2,100 pts. to 875 pts. Still, text adventures market was small, despite titles like “El Quijote” (Quixote) managed to have great sales.
Also, by the time Aventuras AD was created, the home computer market was quite fragmented: ZX Spectrum was probably the one that had more users, but there was also a large amount of users of Amstrad CPC, MSX, and Commodore 64. Amiga, Atari ST and PC compatibles were taking their share of the market as well, and their presence became wider as the years went by.
So, to be able to have enough sales of text adventures, they had to target all machines, and so they needed a tool able to target all those at once, with the less additional work possible (saving time is saving money).
There’s where Andres Samudio contacted Howard Gilberts, in order to get help from Gilsoft in that task. The legend says they managed to sign a contract in a camper area in Spain, where Howard and his family were staying for part of their holidays.
When they started working, they realized they required a more close communication than the one that was possible in the distance by that time, so that ended up with Tim Gilberts working for Aventuras AD at their offices in Valencia.
Tim worked in DAAD for Aventuras AD, improving it, but what we see today shows how important profit was for Aventuras AD, which is very different of what today, we hobbyist, do just for fun. When decisions about how to improve DAAD were taken, business reasons were sometimes over technical decisions. In fact, in the DAAD floppy disks that were recovered from Andres Samudio’s attic, there was a start database for English DAAD games -that never were created- and in that source file you can read “Everything is possible in this life ( but it all costs time and money! ) — Tim Gilberts”.
This sentence, so true, it’s what probably made the following happen.
The 16 bit interpreters
There were three 16 bit interpreters for DAAD: Amiga, Atari ST and PC. When Aventuras AD had to decide how to make graphics for those machines, they took a decision: save time. To do that they decided to use same resolution in all machines (320x200) and then use the same graphics for all of them, with minimal conversions. Graphics were made in an Atari ST machine, and then ported to Amiga (without any change) and PC (adapting the palette for the EGA and CGA versions, as VGA was not yet a common card). Atari ST (the original one) could show 16 colours in screen, from a palette of 512 (which means, 3 bits per colour). The Amiga 500 could show 32 colours, from a palette of 4096, but despite of that, as it was using the Atari ST graphics, it was artificially limited to 16 colours out of 512. Also, the PC versions, were limited to 16 EGA colours, or 4 for CGA, via some palette conversions.
When the VGA become more common, Aventuras AD games targeted VGA also, but still they were using the Atari ST graphics, so despite VGA can use up to 256 colours from a palette of 261,144, it was still using 16 out of 512, the same Atari ST colours. Also, Juanjo Muñoz, from the original AD team, have confirmed the artists at AD, were using a fixed palette for all graphics in the same game also, which limited that even more.
The evolution of Atari ST lead to AtariSTE and other machines, that could do better graphics, but AD continued limiting graphics to Atari ST limits for different reasons: the first one is they owned an Atari ST, and they stick to it, but also, because making better graphics would only lead to lose potential customers, so they made graphics for the minimum capabilities of the marketable machines, something that current game developers also have in mind today.
A few days ago…
Yes, a few days ago something happened: a new game made with DAAD was released, and his author used an tool to automatically convert the images he had for PC (DOS) — which now has a new interpreter that can do VGA 256 colours — to the format required for DAAD, a format made for Atari ST, named Degas. Also, recently, I had created myself a tool for building DAAD image databases for Amiga and AtariST, named img2daad, that allowed creating .DAT files without the original tool used by Aventura AD(a part of DAAD engine named DG).
Once released, a user in the Spanish forum “retrowiki” noticed something: the Atari ST graphics looked better than the Amiga ones, what led the author to page me via Telegram. Once my attention was on the images, I thought there were some apparent rounding in the palette data, which led very similar colours to become the same one. It also helped that the first image that showed up that issue, was a very greyish image. With 3 bit per colour you can only have 8 pure gray tones, but the Atari ST picture looked like it had more, and it had!
I then asked the one who posted the images if by any chance he was running the emulator of an Atari STE rather than an Atari ST, and yes, he was.
What a surprise! The Atari ST interpreter was actually capable of using 4 bits per pixel, although Aventuras AD, never used them. It was only in 2023, when someone unadvertedly put colour information with 4 bits per pixel in a graphics file, thanks to the new img2daad tool, that didn’t crop the extra byte, that we found the interpreter can actually show images with 16 colours out of 4096, instead of 512, if the game is run in the newer Atari ST series models.
When the test was made again but this time emulating a pure ST machine, the graphics became exactly as those in the Amiga.
So unfair…
So the ST interpreter could do better graphics, but the Amiga one couldn’t, which is clearly unfair as the Amiga interpreter was artificially limited to the Atari ST capabilities. What could we do?
Well, here is where I would probably start talking in a technical way, but there is no other way to talk about this, because what I did was… debug the Amiga interpreter step by step, looking at Motorola 68000 assembly code.
It took a while until I managed to control the debugger, and to understand enough 68000 assembly language (I had only used it for about a month around 1994), but at some point I managed to find where DAAD executed condacts, and run them one by one, until I got to PICTURE and DISPLAY.
That lead me to find that was DISPLAY condact the one changing the palette (it was expected anyway), but when I saw how the palette was being modified I saw the values sent to Amiga registers were not the ones in the graphics file!
I tried to find that file in Amiga RAM, and was unsucessful because I was looking for the palette values in RAM, but they were not there either. I was a bit disappointed until I decided not to search for the palette, but for the header of the file, and then I found the graphics file in RAM, but the palette values were different.
Wow, at some point, the Amiga interpreter was changing the values in the DAT file, and then when DISPLAY was showing the picture, there were different colours sent to Amiga registers.
After checking the original colours one by one, I could not find the logic in the change, and only when I listed them one by one in binary notation, I found what was going on: each colour component, each four bits, where shifted left one bit, but limited to 4 bits, so the most significative bit was a lost (0001->0010, 1010->0100). That means if most significative bit was a 1, it was lost.
But, who wants to lose the most significative bit? That was nonsense… until a search in the internet lead me to the reason: Atari STe palette has its bits in a strange order: instead of the usual b3 b2 b1 b0, it’s b0 b3 b2 b1. There is historical a reason for that, Atari designers were not evil people that wanted to confuse me, but they did for a while. So well, in the end shifting left and losing the 4th bit, was actually loosing the least significative bit. That made sense.
Ok, now that we knew what happens, what to do? One solution would have been finding the Amiga interpreter source code, recompile it, and make it properly run, but that was too complicated: to begin with, it’s not clear if that source code has remained until today, if it has, it has to be searched by Tim in dozens of old floppies, and even if found, and no file is missing, it’s not likely that is easy to recompile the interpreter today.
The other way was patching the binary: it took also a while until I found where it was changing the palette, but I finally found this code:
And I patched the binary to be the following:
That allowed the palette go through as is, but there was still a problem:
Sadly, the files were made for Atari ST, so the palette came in Degas format, in the strange b0 b3 b2 b1 order, so colours were a mess.
On the other hand, there was no room in the area were the patch was made to sort the bits properly, and though I could have worked on it, and found a gap in the code where to put some additional code, jump to that area and then back, I took another decision that was easier to implement: I made my graphic database tool img2daad, able to send the palette in the Amiga format, if you add the -a parameter. And yes, it worked!
The only disadvantage of this solution, is that forces the author to create separated DAT files for Atari and Amiga, but DAAD Ready users won’t have to worry about that as soon as next release is published, because the files will be made automatically for either Atari or Amiga.
And that’s all… or not
The SDI1 and EDI1 files have been patched, and by the way it was about replacing 3010 e348 0240 0eee 30c0 with 3010 4e71 0240 0fff 30c0. I have not tried SD2/EDI2 nor SD3/EDI3 but I’m sure anyone that needs can make the same patch. Also, img2DAAD is already updated in its repository, so just look for it in Github. You can find the patched interpreters at DAAD-Ready respository. They have been renamed to SDIP1 (Spanish) and EDIP1 (English) to avoid being confused with the original ones (P stands por patched, of course). Also, please notice that, in order to make possible for other interpreters to be able to run Amiga games (at the moment only NAPs), the value 0xDAAD is stored twice at the possition of the CGA palette in the DAT file. That way other interpreters can determine if the palette comes in in Degas format or standar format.
What’s next?
I should have stopped there, but once you start debugging an interpreter, and you learn how things are done, you need more, so I will soon tell you how I patched the Amiga interpreters so they can run EXTERN code in the style the 8 bits ones do, as the original procedure is apparently lost in time. Spoiler: the 8 bit way was basically shortcutted in the interpreter, and it is not anymore.
The story continues in next article: https://medium.com/@uto_dev/the-commodore-amiga-and-daad-part-2-809b14087861
Greetings
To Tim, Graeme and Huw, which brought DAAD (and its predecesors) to us. They remain the authors of Amiga interpreter despite I touched it a bit (well, four bytes)
To Jose Manuel AKA Morgul. Although I was the one working in this patch, I’ve been commenting many things with him in private chat, and his help and knowledge of DAAD databases is priceless.
To Juanjo Muñoz, for confirming how AD artists worked, we were thinking it was like that but a confirmation from someone that was there is always helpful.
The Writer
You can find me at @uto_dev in twitter.
