1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
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.
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:
- 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). As a side effect of this, the "negative interest"
bug/feature is missing.
- The title screen isn't as nice as the Apple version.
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).
Build Requirements:
- GNU make. I use version 3.82, but I don't use any of its special
features, so any version should do. In fact, BSD make might work.
- cc65. Originally I used version 2.13.3, and part way through I
upgraded to a git snapshot dated December 29, 2015.
- 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.
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, 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.
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.
|