Dungeons of Daggorath Development Blog

Daggorath is 30

Thirty years ago in August of 1983, Dungeons of Daggorath was released for sale. At the time its technical qualities far exceeded anything else available for the Coco platform. It inspired the Coco development community, resulting in a rapid increase in game quality on the platform. For the next 8 years Daggorath stayed on the shelves of Tandy Radio Shack stores. While many titles over the years displayed influences from Daggorath, it had still not been completely matched.

I had been working towards a release of the port to coincide with its anniversary, but alas, other commitments have taken priority.

Font Licensing Folley

Part of wrapping Daggorath in a modern app involves creating menus. Example usage would be for changing options such as audio settings or over-clocking the virtual hardware*. I want the menu buttons to mimic the style of original Coco keys and part of that means matching a font I didn't recognise.

In order to identify the font, I first removed they keyboard from a Coco 1, scanned it on a scanner bed and then manipulated the scan to show the font more clearly. I uploaded the scan to WhatTheFont which correctly identified the font as Microgramma. I mentioned earlier that this work has involved unique development experiences and this is certainly an example.

Coco 1 Keyboard Scan
Above: Original scan of the Coco 1 keyboard.

Coco 1 Keyboard Font
Above: Keyboard scan after maniuplation.

With the font identified, I found that it was cheap to license, only US$20 for web or document usage. I could not find an app license online, but I did find that the going online store rate for app licenses for other fonts seemed to be around 10x the web price. That seemed like it might be OK so I contacted the three licensors of Microgramma. I heard back from two, the first with a quote of 1000 Euros for mobile only, and the second with a quote of US$4000 for mobile and desktop. Say what? I can't say that I quite understand why a license for one app costs 200 times more than a license for unlimited web sites accessible by every device on the planet. In any case, I shall pass and make do with Orbitron instead.

* It was/is possible to over-clock the Coco hardware to double speed with a software command. However, if is done while running from RAM, the video will go all haywire. Cartridge software, being ROM, is therefore special. All that needs to be done for extra challenging gameplay is to carefully place tape over the auto-start pin on the cartridge, insert the modified cartridge, power on, and enter a number of special commands. Oh yeah, and hope that nothing goes bang. I plan to replicate the double-speed mode, sans all the taping, typing and anxiety.

Work in Progress Screenshots

Above are current work in progress screenshots showing the state of Daggorath's graphics.

Before going with the implementation shown, I looked a lot into how to take the frame buffer pixels and convert to something that looks authentic. There is a large body of existing work on processing emulator frame buffers but no existing work I found looked promising. For many games with iconic pixel art, the best bet seems to be to just display square pixels, completely unfiltered. That is not the case for Daggorath however, lines are the iconic element in its graphics.

I decided to try starting with line primitives and work from there to reproduce the original look of the game. I have kept what worked out well: maintaining the same line width the as original; rounding the corners to match the rounding caused by the CRT beam; and, a lot of fiddly work to get the dotted lines to have correct screen area and positioning. I am very happy with how the first person view looks, it feels correct to me and it meets my goal of avoiding distracting artifacts never present in the original.

Overall though, things feel wrong if the display is just black and white. On original hardware everything displayed is subject to considerable color artifacting due to limitations of the video hardware. The text is most affected, almost solid in color. To mimic this I have colored the text in my reproduction to match. Sort of. It does not look right, but overall the coloring is represented. I am not really happy with it but don't have any ideas on how to improve it either.

Time permitting I will experiment with a mild phosphor glow effect but otherwise this may be as good as I can get it.

Deciphering the MC6847 Video Display Generator Datasheet

Other than the CPU, only one other component in the TRS-80 Color Computer contributes important timing: Motorola's MC6847 Video Display Generator. Just two signals from the VDG are important: /HS (horizontal sync) and /FS (field sync, also referred to as vertical sync). Both connect to CPU interrupts and so affect program execution. Each signal is a simple high/low, constant, cycle. Just these 5 pieces of information are required:

  • Number of cycles the /HS line is high and low
  • Number of cycles the /FS line is high and low
  • How /FS timing relates to /HS

All of that information is contained within the MC6847 datasheet although I found it quite a challenge to figure out. In fact it would have been much quicker to hook up a logic analyzer and measure the timing, but not nearly as fun. Not wanting to deprive others of the same challenge, I'll just share a (mostly) readable copy of the MC6847 datasheet. If you can figure out the three pieces of information above, post your results to the comments below and I'll let you know if you are right.

Emulating the 6809 CPU

Coco CPU and ROM
Above: Motorola 6809 CPU and Microsoft/Tandy Color Basic 1.0 ROM, both in ceramic packaging.

Daggorath, like many games of its era, is very sensitive to any changes to timing. Very slight changes in timing result in surprisingly different speed and movement of the enemy creatures. Not only does the existing PC port not match the timing of the original, but nor do most emulators (XRoar is the exception). Even running on a real Coco 3 does not perfectly match the Coco 1 or 2. PAL Cocos from Europe and Australia have very different video timing and surely do not run Daggorath the way the original developers intended. To meet my goals for this port the original CPU and video timing must be emulated exactly.

CPU emulation seems is mostly straightforward - implement a state machine to track the virtual CPU's internal state, execute each instruction according to the CPU specification and count the number of clock cycles each instruction takes. On some systems the interactions between multiple processors can be tricky to deal with but the Coco hardware and Daggorath's specific needs are very simple. The main challenges for this project are that even the 6809 has a lot of instruction variations to implement and it is important to validate each one. Bugs caused by errors in the CPU emulation often manifest in subtle ways that can be very difficult to debug.

CPU implementations create their numerous instruction variations by mixing common implementation elements together; for example several different arithmetic operations mixed with several different addressing modes. I took advantage of this in my implementation by using templates to combine inline functions. This not only reduced the amount of time needed to implement the full instruction set, it minimized the number of places I might make an implementation error. Performance is slightly worse than the more commonly used macro expansion technique but it has been completely worth it to have easier to debug code.

I also validated my CPU emulation in an existing emulator, comparing execution against the emulator's original CPU emulation. This involved quite a bit of work hacking up my emulation to match the emulator's, however it caught enough errors to be absolutely worth the effort. Knowing that the CPU was solid made implementing and debugging the rest of the Coco emulation much more enjoyable.