path: root/README.txt

Taipan for Atari 800

This is a work in progress. It's a port of the C version for Linux and
curses, modified to look and play more like the original Apple II version.

Currently the game is playable and complete, but has a few known bugs
(see "Bugs" section below) and probably a few unknown ones too.

The latest version of the source can be found here:
http://urchlay.naptime.net/repos/taipan/

A binary of the game can be found here:

http://urchlay.naptime.net/~urchlay/src/taipan.xex

...though it might be outdated.

Linux/curses port can be found here:
http://www.ibiblio.org/pub/linux/games/textrpg/

Original Apple II BASIC source, plus a browser version of the game,
can be found here: http://www.taipangame.com/

What's missing:

- Large integer (or floating point) support. Cash, Bank, and Debt
  amounts will roll over to 0 if they exceed the max value for a 32-bit
  unsigned integer (around 4 billion). I'm not sure if this is a real
  problem for anyone (it takes a *long* time to get over a billion
  in this game). As a side effect of this, the "negative interest"
  bug/feature is missing.

Build Requirements:

- make. I use GNU make 3.82, and occasionally test with an old
  version of BSD make (which works).

- cc65. Originally I used version 2.13.3, and part way through I
  upgraded to a git snapshot dated December 29, 2015. Building with
  cc65-2.3.13 is probably broken right now, but it will be supported
  again.

- gcc. I use version 4.8.2. Probably any version will do. It's only
  needed for convfont.c (and there's nothing gcc-specific about it,
  so really you just need any C compiler, see HOSTCC in the Makefile).

- perl. I use version 5.18.1, probably any 5.x version will work.

- A UNIX/POSIX environment. At least, you need a 'cat' command and
  a shell that does I/O redirection. Linux, BSD, and Mac OS X should
  be fine. If you're on Windows, try Cygwin.

If you plan to edit the port status scrren, you'll need the Atari800
emulator. It's also handy for actually playing the game, whether you
build it or use the provided binary.

If you plan to edit the title screen, you'll need the ImageMagick library
and its perl module (Image::Magick). Also you'll need something that
can edit PNG images (I use the gimp, anything will do).

Building:

Hopefully you can just type "make" to create the binary. If it doesn't
work, you're likely missing one or more of the requirements listed above.

Running:

The game binary is called "taipan.xex". It's a standard Atari DOS
'binary load' file, which expects to be run with BASIC disabled and no
cartridges inserted.

You can run it on a real Atari computer: any 400/800/XL/XE model should
be fine, so long as it has at least 48K of RAM. Use a SIO2PC cable and
software like Atariserver (Linux) or APE (Windows) to serve the game to
the Atari. If you can come up with a way to actually copy it to a real
floppy disk, you probably want a bootable DOS disk with Taipan renamed
to AUTORUN.SYS.

It's also possible to run Taipan in an emulator, such as Atari800,
Atari++, or Altirra. For Atari800, you should be able to do this:

atari800 -nobasic taipan.xex

Even though the title screen says to press Escape to start, you can
really press any key to start the game.

License:

The legal status of this is quite murky. The original game is still
copyrighted, though quite a few clones of it have been made for various
platforms over the years with no complaints from the copyright holder.

This Atari port includes font and graphics data ripped straight from
the original Apple game, plus more font data ripped from the Atari 800's
OS ROM.

The Linux port of taipan, according to its .lsm file, is GPL. My C code is
definitely a derivative work, so it's GPL also. The assembly code and ship
graphics are my own work, and I release them under the GPL (version 2).

Notes:

The Atari executable file format allows for concatenating executables.
The result is still a valid executable. I use this to load the splash
screen and custom font directly into memory before the main program loads.
The Makefile documents how all this works, but it might seem pretty
hairy if you're new to the Atari, Makefiles, and/or Perl.

The Apple version of the game was expected to be run on a monochrome
monitor. Like many other ports from the Apple to the Atari, there will
be color artifacts when using a composite monitor. For best results,
use a monochrome monitor. If you can't, at least try using a color
monitor with S-Video (separate chroma/luma) inputs. If all else fails,
try turning the color knob all the way down (and the contrast as high
as you can stand it). In emulators, you can just disable artifacting.

On PAL systems, the ship explosions and sinking animations will be 20%
slower, and the prompt timeouts will be 20% longer (1 sec => 1.2 sec). I
don't think this is a real issue (it's not like Taipan is a fast-paced
arcade game).

Bugs! At least these:

- When exiting to DOS and reloading, the title screen graphics are
  messed up. The playtester who reported this was running on real
  hardware (not an emulator). I can't see how this is happening, but I
  expect it's related to this:

- The BSS can overlap the start of the title screen (it's very close
  anyway). Consequences: There is a momentary graphics glitch when the
  main game is done loading and before it shows the "name your firm"
  screen. Also, we can't go back and display the title screen (but that's
  not something really necessary anyway). The fix: make the damn code
  smaller!

- After a battle, the prices don't get reset (or, not always?) when
  entering the new port (confirm?).

- The "negative interest" bug is currently missing, due to using
  unsigned values for debt. Plus, it's cheating. It'll get added back when
  I either start using big numbers (floats or 64-bit ints or whatever),
  or just decide to live with the limits of 32-bit ints.

- Retirement score calculations are a bit off, due to using integer math.

- Not really a bug, but, the interest calculations for debt and the bank
  are slightly different, due to using integer math. Very small bank or
  debt amounts will grow much faster than they should, then stabilize
  and converge towards the correct values over time. This only happens
  when you have less than 10 in debt, or less than 200 in the bank,
  which (at least for me) are pretty rare situations.

- A few things in the screen layout are slightly off comapred to
  the Apple version. Would really like to get it exact.

- The 'Please limit your firm name to 22 characters' prompt is missing.
  The Apple version actually allows you to type all you want until you
  press Enter. This port works like the Linux version: as soon as you type
  the 22nd character, it acts like you pressed Enter after it.  A good
  compromise might be to allow up to 22 characters, then any keypress
  other than backspace or enter will show the "please limit" prompt.

- Damaged ship graphics need work. I don't have enough unused font
  characters to duplicate the Apple bitmapped graphics exactly, plus
  each damage location must fit entirely within a character cell... but a
  couple of my damaged sections are pretty hokey-looking. Also, now that
  I'm using the graphical title screen, I have a few more characters I
  can redefine as damaged ship sections.

- fancy_numbers() maybe should round when it's showing a decimal point.
  If you have e.g. 1,190,000, that should show as 1.2 million, not 1.1...
  or maybe not (need to double-check against the Apple version).

- One of my playtesters reported that, when running away from combat, it
  said 4 billion ships were attacking (number of ships must have gone
  negative). I was never able to reproduce this.

- After a fight, "Arriving at Manila" or such would sometimes appears on the
  fight screen without clearing it first (if you ran away, you can still
  see ships). I *think* this is fixed, but I don't understand what caused
  it so I'm leaving it in this list in case I'm wrong.

Differences between the Apple II original and Linux port:

1. Linux has an 80-column screen layout, Apple is 40.
2. Apple version uses a custom font (actually, two, but I'm ignoring that).
3. Apple has sound, Linux does not.
4. Apple has graphical title screen, Linux has ASCII art.
5. Apple has graphical ships during battles, Linux has ASCII art.
6. On Apple, price of General Cargo isn't always an integer (e.g. 6.5).
   As a consequence, the cash and bank amounts aren't always ints either.
7. On Apple, some Y/N prompts (like 'Do you have business with Elder Brother
   Wu') you can press Enter for No. Linux port waits until you hit Y or N.
8. On Apple, ships show damage (get holes in them) as they get shot up.
9. On Linux, you can overpay McHenry (though you get no benefit from it).
   On Apple, payment amount gets clamped to the repair price, so you can
   e.g. be asked to pay 50,000 when you have 70,000 and safely enter A
   (you'll end up 100% repaired and still have 20,000 cash).
10. On Apple, dead enemy ships sink one scanline at a time, and there are
    at least 2 sinking speeds. On Linux, it's one character at a time.

The plan for the Atari port is to mimic the Apple version as closely as
possible... except #6 above. It doesn't really add anything to the game,
and it complicates the code more than I want to deal with. Also #10
will probably not happen (to me, the slow ship-sinking of the Apple
version is annoying anyway).

Right now, items 1, 2, 3, 4, 5, 7, 8, and 9 are implemented Apple-style;
and 6, 10 are Linux-style.

Added a few features not in the Apple or Linux versions:

- I made it possible to disable the sound, since it's kinda repetitive
  and annoying, plus the game "freezes" while sounds are playing (no
  threading on Atari!) which slows down gameplay.

- Added a way to change the background color and text brightness. Only
  3 brightness levels available, and only 3 colors: green, amber, and
  black (to mimic the 3 most popular types of monitor used with Apple
  computers back in the day).

I've made a few changes to the UI, compared to the Apple version:

- Prompts that only accept one character no longer require pressing Enter.
  Gameplay is more streamlined this way. Apple and Linux are inconsistent:
  some prompts need Enter, some don't. In the Atari port, the only prompts
  that require Enter are:
  - naming your firm
  - entering a cash amount (but not if you hit a for "all")

- "We have 5 guns" is in an inverse video box. I think it looks nicer, and
  it matches the "You can afford 5" inverse video box on the trading
  screen.

- The + that indicates more ships offscreen is inverse video. I find
  that I don't notice it's there, if it's normal video.

- "You're ship is overloaded" => "Your ship is overloaded". Sorry,
  grammar nazi.

- Updating the port status screen, and text printing in general, happens
  faster and cleaner-looking, due to using C and asm rather than BASIC,
  and also because the static parts of the screen aren't redrawn unless
  they need to be.

- The title screen now has a help menu and some key commands to change the
  screen colors and enable/disable sound. The "Press 'ESC' to start"
  has been changed to "Press 'ESC' for help", and any non-command key
  starts the game.

Other things that need doing to the code:

- Decide what to do about integer overflow. Possibilities:

  - Use a "bigint" library (e.g. 64-bit ints). Would still be
    possible to overflow, but it would take a really determined
    player. Disadvantage: slow. Maxes out at:
    40-bit:   1,099,511,627,776 (1 trillion)
    48-bit: 281,474,976,710,656 (281 trillion)
    64-bit: 1.84467440737096e+19 (beaucoup!)

  - Use the ROM floating point routines. Nobody's likely to ever
    overflow them. But, would have to write wrapper code to call
    them from C and convert longs to floats and back. And it'll
    be slower than bigints even. Maxes out at 1.0e+97

  - Use packed BCD (base 100) like the FP ROM, but as an integer (no
    magnitude). Maxes out at:
    6 bytes:      1,000,000,000,000 (1 trillion)
    7 bytes:    100,000,000,000,000 (100 trillion)
    8 bytes: 10,000,000,000,000,000 (10 quadrillion)
    Advantage: as above, but more so: "1.2 million" gets even easier
    to calculate. Math would be faster than FP, slower than 64-bit ints,
    but conversion to/from longs would be slower.

  - Use a hybrid data format: one long for the bottom 5 decimal digits,
    range 0 to 99,9999 (value % 100000) and the other for the high part
    (value / 100000). Advantage: the game prints strings like "1.2
    million", this would be faster/easier than a regular bigint.
    Maxes out at 429,496,729,600,000 (429 trillion).

  - Leave it as-is. Obviously the easiest option, but not very satisfying.
    Maxes out at a measly 4.2 billion.

  Whatever format we pick, we'll run into limitations. The "Cash" area
  of the display is only so wide, we can only fill it with so many
  characters. At some point, we need artificial limits:

  - If your debt maxes out: "Taipan, you have been assassinated!" and
    the game is over.

  - If the bank maxes out, stop calculating interest. On deposit,
    "Taipan, the bank's coffers are full!"

  - If cash maxes out, forcibly retire the player. "Taipan, you are now
    so rich that you own the entire continent of Asia!" or maybe "Taipan,
    your ship has sunk under the weight of your massive fortune!"

  Tricky part about these limits is checking for overflow without
  actually overflowing. E.g. instead of "cash += amount" we have to
  write "if(cash + amount < cash) overflow(); else cash += amount".
  Also, backing out of the call tree will be a PITA. longjmp() anyone?
  cc65's implementation seems to work OK. If I use ROM floats, I
  won't worry about this at all.

  For display, "million" can become "billion" if needed... then "trillion"
  but without a space in front ("1.2trillion"). We have enough room for
  4 digits there, 9999trillion would be the max. Or, abbreviate "billion"
  as "bil", allowing 4 more digits. "99999999 bil" would be 99 quadrillion.

- Size optimization. Right now, the executable is almost 28K of code. I'd
  like it to at least fit on a 16K cartridge. A lot of the C code is
  redundant, and some things can be rewritten in asm if need be. I've
  already eliminated all uses of printf() and its ilk, which removed 2K
  of library code from the executable. Removing all other stdio.h functions
  saved another 1/2K or so.

- In aid of the above: split splash_intro(), cash_or_guns(), name_firm() into
  separate .xex segments. Have to write a linker script to generate an
  init header rather than a run header (or, write in raw asm and forget
  the linker). Use cassette buffer and/or page 6 to pass variables to the main
  program. name_firm() is 1/2K, cash_or_guns() is 1/4K, rewrite in asm and
  they may both fit in page 6.

- Another memory saver: keep some variables in page 6 and/or the tape
  buffer. Also, find out how much page zero cc65 leaves us to
  work with, maybe enough contiguous bytes for e.g. the fancy_num[]
  buffer. draw_lorcha is using FR0 at $D4, but using it for fancy numbers
  wouldn't conflict...  it looks like cc65 uses 26 bytes of ZP from
  $80-$99, so we have quite a bit free.

- A thought: if memory gets too tight, switch to a boot disk rather than a
  .xex file, and load code from disk at runtime (e.g. sea_battle() could be
  loaded on top of some other routines, then the other routines reloaded
  when the fight is over). That, or use a bankswitched cartridge.

- Temporarily add a "god mode" to allow me to test situations that would take
  a lot of regular gameplay to reach.

Future Ideas:

I may do a "Taipan Plus" at some point. The regular Taipan game will be
faithful to the original, and the Plus version could have some or all of:

- More ports to dock at, some of which might have their own warehouses,
  repair yards, etc.

- More trade goods, not all of which are available at all ports.

- Actual market trends, rather than a base price + random number. There
  might be news events that cause prices to go up/down (e.g. Arms are
  up at Saigon because there's a gang war in progress, Opium is up at
  some port but the chances of getting busted are higher). This feature
  actually exists in Art Canfil's TRS-80 Taipan "version 10".

- Ability to control a fleet of ships. Each one will either be a cargo
  ship or a warship.

- A "Turbo Combat" feature like one of the phone versions I've seen. You
  set your orders and hit Turbo, and it finishes the fight instantly,
  but you can't change your mind about your orders (fight until you win
  or die, or run until you escape or die).

- Special missions. Someone at some port needs you to transport documents
  or whatever, to some other port... you will almost certainly be attacked
  by whoever's trying to get the documents though.

- Rival trading companies. Their activities can influence prices, and
  you can fight them and possibly salvage actual cargo.

- Variable passage of time. Distant ports take longer to get to. Also,
  winds or ship damage can slow you down.

I dunno how many of the above will fit in the Atari's RAM. Probably have
to rewrite the whole game from scratch in assembly before adding features.