diff options
| -rw-r--r-- | README.txt | 190 |
1 files changed, 42 insertions, 148 deletions
@@ -43,6 +43,9 @@ Build Requirements: - perl. I use version 5.18.1, probably any 5.x version will work. +- perl's Image::Magick module (which in turn requires the C ImageMagick + library). I use version 6.8.6, probably any recent version will do. + - git. You don't exactly *need* this to build the code, but if you have it, the git hash will be built into the binary and appear on the title screen. @@ -51,18 +54,20 @@ Build Requirements: 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 +If you plan to edit the port status screen, 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. +Hopefully you can just type "make" to create the taipan.xex binary. If +it doesn't work, you're likely missing one or more of the requirements +listed above. + +If you'd prefer a cartridge image, "make cart" will build both a raw image +(taipan.rom) and an image with an Atari800 CART header (taipan.cart). + Running: @@ -82,6 +87,20 @@ Atari++, or Altirra. For Atari800, you should be able to do this: atari800 -nobasic taipan.xex +The cartridge image is a 64KB XEGS bankswitched cartridge (what Atari800 +calls "type 13"). It can be run in the emulator thus: + +atari800 taipan.cart + +For burning to an EPROM, you'll need to build or scavenge a cartridge +with the correct banking logic, and burn taipan.rom to a 64KB chip. + +Unlike the .xex version, the cartridge will work on a 32KB Atari. + +Coming soon: You will also be able to purchase a Taipan cartridge from +the AtariAge store. + + License: The legal status of this is quite murky. The original game is still @@ -94,8 +113,8 @@ OS ROM. The Linux port of taipan, according to its .lsm file, is GPL (version uspecified). 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). +also. The assembly code and host tools (convfont, mkcart) are my own work, +and I release them under the GPL (version 2). Notes: @@ -120,9 +139,6 @@ arcade game). BUGS! At least these: -- After a battle, the prices don't get reset (or, not always?) when - entering the new port. - - The "negative interest" bug is currently missing, due to using unsigned values for debt. Plus, it's cheating. I'm undecided whether or not to use a bignum for debt; if I do, it will be @@ -151,34 +167,24 @@ BUGS! At least these: I'm using the graphical title screen, I have a few more characters I can redefine as damaged ship sections. -- Fixed, I think: 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). - -- Fixed, I think: After a fight, "Arriving at Manila" or such will - sometimes appear on the fight screen without clearing it first (ships - still visible). This happened when Li Yuen's pirates drove off the - first enemy fleet, then attacked the player. - Deliberate differences between the Apple II and Atari ports: -1. "Press ESC for help" rather than ESC to start. +1. "Press ESC for help" rather than ESC to start. Starting the game is + done with the space bar or return key. 2. 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. 3. 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). + 4 brightness levels, but all 16 Atari hues are available. 4. 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 an amount, cash or items (but not if you hit a for "all") + - entering an amount of cash or items (but not if you hit A for "all") 5. "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 @@ -193,12 +199,7 @@ Deliberate differences between the Apple II and Atari ports: 8. 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. - -9. 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. + they need to be. (Grammar nazi? That's a run-on sentence...) 10. Apple uses floating point, no practical limit on cash/bank/debt. Atari currently uses 32-bit unsigned longs for cash and debt, @@ -212,6 +213,12 @@ Deliberate differences between the Apple II and Atari ports: - If your debt goes above 2 billion, you die and the game is over. + Making cash a floating point value is possible, but not worth the + effort as it's a *terrible* idea to carry billions (or even millions) + of cash around, due to the possibility of getting robbed. By the time + someone plays the game long enough to earn billions in cash, he'll know + to leave most of it in the bank, not carry it around. + 11. On Apple, price of General Cargo isn't always an integer (e.g. 6.5). 12. On Apple, dead enemy ships sink one scanline at a time, and there are @@ -224,6 +231,10 @@ Deliberate differences between the Apple II and Atari ports: 14. When entering numeric amounts, pressing K or M inserts 3 or 6 zeroes. This means you can type e.g. 100,000 as 100K, and 10,000,000 as 10M. +15. When playing on an 800, the standard Atari keyclicks will be heard. + Disabling these on an 800 is non-trivial. On XL/XE machines, they are + disabled to mimic the Apple version. + Differences between the Apple II original and Linux port: @@ -253,123 +264,6 @@ 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: - -Other things that need doing to the code: - -- Decide what to do about integer overflow. Possibilities: - - - This one seems like the best solution to me. The rest of the - stuff listed here is left for reference (for now). Here we go: Keep - using unsigned long for cash and debt, and use a ROM float for the - bank only. If you try to make a sale, borrow from wu, or withdraw an - amount that would overflow 32-bit cash, "Taipan, you cannot carry so - much cash! Your ship would sink under the weight of your riches!". If - pirate booty would overflow, don't award it. If debt interest would - result in overflow, the player gets assassinated instead. Advantages - of this: less code has to be changed, and the FP stuff is limited - so we don't need a good API for it, just a few functions that can - call the ROM directly, as needed: bank_deposit(), bank_withdraw(), - bank_interest(), bank_compare(). These will need a common ul_to_fp(). - Also need a would_overflow(unsigned long value, unsigned long amount) - to return true if adding value + amount would overflow... actually it - can return MAX_LONG - value (still true, but also useful as a value). - - - 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). - - - Another hybrid idea, might be faster: one long ranging up to - 999,999,999, or 1 billion - 1, and an unsigned int for the top - bits. Existing cprintfancy() can handle the bottom part, if the - top is 0. If not, we only ever need the top digit of the bottom - (e.g. the .2 in "1.2 billion"), and then only if the top int is - less than 10. Maxes out at 65.535 trillion, meaning we'll need - to be able to print "Trillion", perhaps with no space. This is - approximately equivalent to a 46-bit int, but uses 48 bits of - storage. - - - 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 30K 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 |