initial commit

1 files changed, 234 insertions, 0 deletions

diff --git a/README.txt b/README.txt
new file mode 100644
index 0000000..b31622b
--- /dev/null
+++ b/README.txt
@@ -0,0 +1,234 @@
+Taipan for Atari 800
+
+This is a work in progress. It's a port of the C version for Linux
+and curses, with the font and screen layout from the original Apple
+II version.
+
+Currently the game is playable but incomplete, and has a few known bugs
+(see "Bugs" section below) and probably a few unknown ones too.
+
+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:
+
+- Sound. The Linux/curses port doesn't have any, but I'm planning to
+  have the Atari mimic the sounds from the Apple II version, plus
+  maybe a few more (cannon shots and explosions during combat).
+
+- 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).
+
+- The title screen and ship graphics are pretty crude compared to
+  the Apple II original (though they're nicer than the curses ones).
+
+Building:
+
+Prerequisites are GNU make, cc65 (I use version 2.13.0, any recent one
+should do), perl (any recent-ish version), and a *nix-like environment (I
+use Slackware Linux, if you're on Windows you might try Cygwin or Msys).
+
+If you plan to edit the title screen or ship graphics, you'll need
+the Atari800 emulator. It's also handy for actually playing the game,
+whether you build it or use the provided binary.
+
+Running:
+
+The game binary is called "taipan.xex". It's a standard Atari DOS
+'binary load' file. You can load 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 download 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
+or Altirra.
+
+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 build includes font 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
+title/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 a bit
+slower, and the prompt timeouts will be a bit longer. I don't think this
+is a real issue (it's not like Taipan is a fast-paced arcade game).
+
+Bugs! At least these:
+
+- Can't change orders in mid-battle. Whatever you pick for your first
+  turn, you're stuck with. Not sure why yet.
+
+- The damage calculation is messed up. You can get killed in your first
+  battle, one shot can occasionally destroy a 100% healthy ship.
+
+- When the lower-left ship get sunk, a little graphical "turd" gets
+  left behind.
+
+- This may or may not be fixed: Occasionally the font gets partly
+  corrupted in memory, by some rogue pointer or cc65 bug. The usual
+  symptom is that the vertical bars of the "box" in the port status
+  display get messed up. Still investigating this one. It ain't like
+  the Atari has valgrind :)
+
+- 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.
+
+- The retirement display still uses ASCII | and - to draw a box. They
+  should be using ATASCII line-drawing characters instead (like the port
+  status does).
+
+- 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 cursor isn't getting disabled in a few places, and at some
+  prompts it's not visible until you actually type something.
+
+- Escape key should actually work, when typing at prompts.
+
+- 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).
+
+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, 5, 7, and 9 are implemented Apple-style; and 3,
+6, 8, 10 are Linux-style. 4 is kinda halfway between (the graphics are
+6 of the enemy ships rather than a hi-res single ship).
+
+Other things that need doing to the code:
+
+- Size optimization. Right now, the executable is almost 32K 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.
+
+- 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.
+
+- The title screen could be rearranged a bit and use a custom display list
+  to put all the text on top and bottom, with a GR.8 ship in the
+  middle. The Apple version's ship is a 176x145 bitmap, 22 bytes wide,
+  or 3190 bytes total on disk. Might use a narrow playfield to display
+  it? Or use GR.15 for a greyscale (greenscale) image?
+
+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).
+
+- 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.