Q1: Why port this archaic game in the first place?

A1: Back in 1982, I had an original TRS-80 Color Computer with 4k of memory.
    Then I acquired this game, which required 16k.  Since I wanted to use 
    Extended Color Basic with all its fancy features anyway, I went for the 16k
    upgrade.  I must have played this game for hours, but never could beat it -
    partially because the game is so difficult & partially because back then, we
    saved our data to cassette tape which wasn't very reliable.  Anyone who has
    used cassette tape for storage knows what I'm talking about.  After spending
    what seemed like hours trying to load your saved game, listening to sounds
    similar to that made by a modem, 7 out of 10 times the load would fail with
    the dreaded "CLOADM ?IOERROR".  Sometimes repeated attempts would
    successfully load the game, but more often than not it wouldn't help.  So
    that saved game you just spent 10 hours playing was lost forever.  Then 
    sometime in 1982, "cheap" ($1200) IBM XT clones began appearing on the 
    market & I traded in my my trusty CoCo for an 8088 clone, learning all about
    this new MS-DOS operating system, quickly forgetting about Madness and the 
    days of cassette storage.
 
    Fast-forward 30 years to the Internet age.  Sitting around one day, Madness 
    popped into my head for no apparent reason & I decided to google it.  Lo & 
    behold, there were a couple of links talking about how hard Madness was to
    beat.  One page, http://www.figmentfly.com/madnessandtheminotaur, even had
    the binary & information on how to run Madness in a simulator.  So I 
    downloaded it and tried some of the simulators out there, but found them too
    cumbersome to use, especially around saving and restoring the game.  One of
    the links on the figmentfly page was to a disassembled binary by Chris
    Cantrell (http://www.computerarcheology.com), complete with full commentary.
    Looking over Chris's source made me think that a port to x86 would be the 
    most beneficial thing for me to do - that way I could easily play the game
    and implement a simple save/restore mechanism myself.  So with that goal in
    mind, I set out to port Chris's commented 6809 sources to x86.  Technically,
    I originally made Chris's sources compilable & relocatable on the 6809 and 
    then used that code for the port, but in the end the result was the same -
    Madness and the Minotaur running natively on Linux.
   
Q2: Why port to assembly, and not some high-level language?

A2: Part of the attraction of the port was the chance to work with assembly 
    again & sharpen my skills.  It's not often these days that I get to use
    assembly, never mind two different assembly languages - 6809 & x86.

Q3: Why 32-bit assembly and not 64-bit?

A3: I thought 32-bit would reach the most audiences, as there are still a lot
    of 32-bit architectures out there, and the 32-bit version will run just fine
    on a 64-bit processor.  There is also nothing in the program that requires 
    anything greater than 8-bit.  I also skipped over 16-bit 8086 because it is
    obsolete & would require working with segments.  If for some reason a 64-bit
    port was needed, it would be s simple matter of changing the register names,
    taking care of overflow/underflow operations from the original 8-bit design.

Q4: Why Linux and not Windows?

A4: The author is a UNIX aficionado and since Linux is the prevalent UNIX
    derivative out there it made the most sense.  Linux and its tools are
    also free, and there is a huge Linux user base out there, which will 
    allow this code to reach a broader audience.  Also, a game such as Madness 
    falls into the same category as classic text games such as Adventure or 
    Zork, and so I believe is a natural fit for Linux.

Q5: Why GNU Assembler and not NASM?

A5: Believe it or not, I actually prefer the AT&T syntax over the Intel syntax.
    Maybe this is because, as mentioned in A4, I am a UNIX aficionado.  I also
    prefer vi over emacs, so maybe that explains it as well. :-)
    Kidding aside, porting to NASM should be a straight-forward job - there 
    is even a Linux utility named intel2gas to help do this.  Despite its name, 
    the utility also translates gas to NASM.  I also thought there may be more 
    support out there for gas than NASM, since gas has been ported to many 
    platforms.  Yes, NASM is also portable and has a pretty big following, but
    as I mentioned already, the main motivation was I prefer AT&T syntax.

Q6: Would you ever consider porting to C/C++/C#/Java?

A6: Sure, I have considered this, but would like to get the majority of the
    bugs shaken out of the assembly version before doing so.  C/C++ would be
    the logical next step - from there, porting to C#, Java or whatever
    language (other than assembly on another platform!) should be a breeze.

Q7: Would you ever consider porting to Windows?

A7: Maybe, but in doing so I'd probably port it to C# as mentioned in A6.

    Update: I've changed my mind & am currently in the process of porting to
    Windows in assembly.  Maybe some day I will still port it to C#.

Q8: Would you ever consider porting to OS X?

A8: Hmmm - an Objective-C version would be interesting ... maybe.

    Update: I changed my mind & already ported it to OS X in assembly.  Maybe
    I will still port it to Objective-C/C++ some day.

Q9: Would you ever consider porting to VMS?

A9: OK, so I lied - this is not a frequently asked question.  In fact, no 
    one but me has ever asked.  But yes, I would consider it if I could find
    someone other than myself interested in it!  Of course, porting to C first
    would be easiet, but no fun - I'd prefer to write it in VAX assembly!

Q10: Have you ever beaten the game?

A10: Not without cheating!  This was one of the dilemmas I wrestled with before
     starting the port.  As mentioned in A1, I tried using some of the simulators
     out there to play Madness, but ran into similar problems as I did back in 
     1982 when saving the game (OK, maybe not as bad, but still not easy).  So I 
     decided to forego winning the game first and instead opted to port it.  Of 
     course, porting the game revealed all its secrets to me & so I can now beat
     it, but it's still not easy.  Madness has a fair amount of randomization in 
     it that makes it diffucult to beat even if you know its secrets.  So if you 
     want to beat the game fairly, don't look at the sources!!!

Q11: How long did it take to port Madness?

A11: I didn't really keep track of the time, but according to git check-in
     comments, it took about a month to make the 6809 sources created by Chris 
     relocatable & compilable under Linux, which was the starting point for the
     Linux port.  It then took about a month to get a "working" version under
     Linux (one that could run & let you walk around the labyrinth).  Next, it
     took about 2 months to shake out the major bugs & get a truly working 
     version.  After that, I spent about a month cleaning up the sources, doing
     things such as converting jmp statments into call statements, changing
     blocks of code into subroutines, etc.  In addition, I removed most tail
     recursion calls.  I made these particular changes because eliminating jumps
     will make porting to higher level languages much easier.  I also removed
     printing by character & instead used the .asciz assembler directive.  So
     all total, it took about 5 months.  Since I did the work in my spare time,
     I do not know how many hours that encompasses.

Q12: Is there anything left to be done?

A12: Yes!  During the port, I tried to stay as "vanilla" as possible, meaning
     that I tried to port the instructions one-for-one from 6809 to x86.  This
     was done mainly for debugging reasons - I knew I would be shaking out bugs
     for quite some time & it would be easier to fix the bugs if the new code
     closely matched the original code.  A downside to doing this is that it
     also left behind a lot of optimization tricks that are no longer needed 
     for a 30+ year old game running on a modern processor.  For example, there
     is really no need for packed strings, lxi tricks, tail calls, local
     branches, printing one character at a time, etc.  These optimizations were 
     necesssary at the time, when the CoCo had a clock speed of 895KHz & only 
     16K of memory, but are hardly needed today when both processor speeds & 
     memory are in the Giga range.  Once the bugs have been shaken out of the
     port, I plan on going back & doing what I can to make the code a little more
     modern.

     Update: Note that in an effort to make porting easier to other languages
     and platforms, in the end I did remove all lxi tricks, local branches and 
     tail calls.

     Update: I recently changed all jumps to call statements and modified the 
     code to use the .asciz assembler directive instead of printing character by
     character.

Q13: How do I enable sound?

A13: Sigh - long gone are the days of opening /dev/dsp & writing to it.  These
     days, PulseAudio is the norm for playing audio on most (all?) Linux distros.
     For madness to utilize PulseAudio would require linking with the PA libs.
     I did not want to add that burden on madness, so I chose to simply emit
     tones via the PC speaker.  Since the audio needs for madness are quite 
     modest (being 33 year old technology), I think this was a good compromise.
     Also, there are many Linux distributions out there, some old, some new, 
     utilizing a variety of sound technologies (OSS, ALSA, PA), and so coding to
     the lowest common denominator (the PC speaker) seemed to make sense.

     That being said, access to the speaker is restricted under Linux & so users
     cannot access it.  To get around this, Madness will have to be setuid root
     if you want sound.  If madness cannot open the speaker, the game will still
     play, but there will be no sound.  To setuid the madness binary, execute
     commands similar to the following as root:

        chown root:audio madness
        chmod 4755 madness

     Note that your distro may have a different group than audio, so substitute
     accordingly.  If no suitable group exists, you can always use root as both
     the owner & the group.

     Due to the shear number of Linux distributions out there, it is impossible
     to know the exact reason for sound failure on each distro.  To that end, I 
     have tested the sound on a Debian 7.3 desktop, as well as an Ubuntu 12.04 
     desktop and laptop.  For Debian, sound just worked.  For Ubuntu, I needed
     to first manually load the pcspkr module (as root - modprobe pcspkr).  Then
     I had to run alsamixer (as any user), tab to the "Beep" entry, unmute it & 
     increase its volume.  For these changes to persist across reboots, you will
     need to edit the /etc/modprobe.d/blacklist.conf file (again, as root) & 
     comment/remove the "blacklist pcspkr" entry.  If none of the above works, 
     you can try to solve the problem by running the "beep" utility manually 
     (you may have to install beep - "apt-get install beep" as root).  Madness
     uses the same mechanisms beep does to produce tones, so if beep works, 
     madness should as well.  Conversely, if beep doesn't, then neither will 
     madness.

Q14: Why is your binary named "madness" when the original binary was named
     "minotaur"?

A14: Just an easy way to distinguish between the original source & the version
     I was porting - you can rename it to minotaur if you like.

Q15: What happened to the ability to scroll back a screen using the arrows?

A15: It was assumed that most people would be running Madness from within some
     sort of X terminal & so such a mechanism was not needed, as scrollbars
     could be used.  Even those running in a non-windowing environment probably
     have a terminal with scrollback capability.  This also frees the arrow
     keys for future use as a command history mechanism.