15

I have been entering and debugging the Taipan1 code from TAIPAN - A historical adventure for the Apple Computer (PDF) by Art Canfil, Karl Albrecht, and Jim McClenahan, linked to from taipangame.com.

Please note that this is not the same code as the more "common" "hi-res" version of Taipan, in circulation (as shown in fadden's answer) - the book version is a low resolution, 40 column game.

The code in the book does not use high resolution graphics, nor a character generator2.

There is a line in the AppleSoft BASIC version of TAIPAN, listed on page 42, that prints ( a couple of) CHR$(133), when printing the table of goods owned:

150 FOR I = 0 TO 5: VTAB 5 + I:PRINT G$(I):VTAB 5 + I:HTAB 11:PRINT CHR$ (133);: Q=SG(I):GOSUB 1330:VTAB 5 + I:HTAB 26:PRINT CHR$ (133);: Q = GG(I):GOSUB 1330: NEXT I: INVERSE: PRINT A$: NORMAL: RETURN

The corresponding text from the book, also on page 42, refers to this CHR$(133) as a vertical bar, stating:

Then another VTAB and an "HTAB 11" put our cursor eleven columns to the right, so that it displays vertical bars, CHR$(133), to the right of the item names.

However, this character doesn't seem to be displayed on the Apple II emulator, Virtual ][ (with a IIe Enhanced ROM) - at least, I can't see it:

Taipan screenshot running in Virtual ][

Even a simple test, such as below, shows nothing on screen:

10 PRINT CHR$(133)
20 GOTO 10

Generating the character set myself:

10 FOR N = 0 TO 255
20 PRINT CHR$(N);
30 NEXT

gives

Character set 0-255

Code with a more descriptive output

100 FOR N=1 TO 254 STEP 4
110 PRINT N;:HTAB5:PRINT CHR$(N);:HTAB 10: PRINT N+1;:HTAB 15:PRINT CHR$(N+1);:HTAB 20: PRINT N+2;:HTAB 25:PRINT CHR$(N+2);:HTAB 30: PRINT N+3;:HTAB 35:PRINT CHR$(N+3)
120 NEXT

shows that nothing is shown for characters 128-160

Detail of character set from 128 to 160

I have already been burnt3 when looking up the character set for the Apple IIe, as the character set listed on Wikipedia is clearly incorrect.

The only (irrelevant) references for CHR$(133) that I could find are:

But, discounting these other platforms, I can't find any AppleSoft BASIC reference for the character code, or CHR$(133) at all... which does seem strange, especially as the book explicitly refers to the CHR$(133) in the text, so it definitely isn't a typo.

Questions

  • What does the character with the code 133 look like?
  • Does anyone have a link to this and a correct character set for the IIe?

Maybe I am missing something obvious, or there's a bug in the emulator and it can't display the character? Or maybe I need to enable a setting in the emulator to access a better character set, one that the book (maybe) assumes is being used? A more unlikely scenario is that CHR$(133) is actually a typo in the book, and it should be a different character code..?

Footnotes

1 From Help understanding TAIPAN source code for the Apple II

2 The start of chapter 19 states:

Using the Apple II in BASIC, it is very difficult to operate high- resolution graphics, especially with any kind of animation speed. So what we have here is an example of compromises: we've used your Apple's normal characters...

The pirate ships are drawn using ASCII characters (lines 4995 to 5120), like so:

5105 DATA    "/:     -------    -:-   "
5110 DATA    " :--      :      :000:  "
5111 DATA    ":   \------------/   /  "
5112 DATA    " \                  /   "

3 See this comment under How did the Apple IIe convert to upper case?

Greenonline
  • 4,296
  • 2
  • 19
  • 57
  • The Taipan in common circulation used the hi-res screen, with a custom font. The character in question might be something produced by the character generator. – fadden Dec 10 '23 at 17:17
  • 2
    Maybe they wanted CHR$(124) (vertical bar, '|')? – fadden Dec 10 '23 at 18:03
  • 3
    Your test 'for N = 0 to 255' surely shows the emulator is using a 7-bit character set rather than that 'there are no characters' from 128 to 160. i.e., it's just ASCII. The high bit (traditionally used for parity on serial lines) is ignored. – dave Dec 10 '23 at 22:03
  • Despite being AppleSoft, did the real distribution of this program load up some binary before executing the BASIC program? It could be that a character generator written in assembly was loaded and hooked up to BASIC's output, and the character over ASCII code 127 had special meaning (e.g. inverted, or a glyph). But yes, the raw BASIC running of it will just produce the same as CHR$(133-128). I'd check myself, but I've only seen/found the HiRes version which Fadden has covered. – bjb Dec 11 '23 at 16:57
  • 1
    @bjb - No character generator, nor any additional code (assembler or otherwise), is mentioned or shown in the book, apart from the BASIC listing. All BASIC code listed in the book can be seen here – Greenonline Dec 11 '23 at 16:59

4 Answers4

16

The game was originally written for the TRS-80 and ported to the Apple II.

In an online TRS-80 emulator PRINT CHR$(133) is a partial vertical line.

Screen capture from TRS-80 emulator running program to test CHR$(133).

The TRS-80 character set has other options for "full" vertical lines such as 149 and 170.

This site has some screen captures of Taipan on the TRS-80, and the vertical lines look "full", not partial. It seems further investigation is warranted in emulators or preferably on real hardware.

Screen capture of Taipan running on a TRS-80

Nick Westgate
  • 7,688
  • 1
  • 27
  • 61
7

Update: this isn't the answer to the question. The hi-res version and the text version share a common heritage but have no overlap in how they handle the display; CHR$(133) does not appear in the Applesoft code for the hi-res version.

I'll leave this here in case it helps somebody who stumbles across this while researching something else.

As you have determined, CHR$(133) isn't going to draw a vertical bar on the text screen.

The common Apple II version of Taipan! uses the hi-res screen:

screenshot

There are a couple of hi-res character sets embedded in the Tapian! binary. The first is at +$0b00, and has what looks like 192 glyphs (or is two separate 96-glyph character sets):

font1

Some of those in the bottom part look like they could be combined to form pictures of sailing ships.

The second font is at +$1600:

font2

That's the font used for most of the text in the game.

If we theorize that CHR$(133) is coming from the symbol font, it would be the 5th glyph cell, which appears to be a blank. So that's not quite right. You'd need to dig into the HRCG a bit to figure out exactly what it's doing.

jiwopene
  • 235
  • 1
  • 6
fadden
  • 9,040
  • 1
  • 30
  • 84
  • Thanks for the character sets, they are very useful indeed. However, as I have tried to clarify in the question, the version of code in the book differs from this common version and uses neither hi-res nor (apparently) the character sets that you have shown. – Greenonline Dec 10 '23 at 17:58
  • 1
    I looked through the PDF you linked. They do seem to be text-based in that code. They use CHR$(133) in multiple places and, as you noted, call out its usage in the accompanying text, but it doesn't really make sense. Using CHR$() for a vertical bar rather than the character itself makes some sense, because early Apple II models didn't have that key on the keyboard, but that's not the right value. – fadden Dec 10 '23 at 18:07
  • Yeah, I wondered if the code had been ported and maybe the 133 was a hangover from the previous platform. But it seems to be a bit of an oversight in, what is (otherwise) really, quite a polished little book (for the time). – Greenonline Dec 10 '23 at 18:10
  • 3
    @Greenonline: the hi-res version extracted from a DOS disk (https://gist.github.com/fadden/d71f8b3adc87e3340251b556239d076e) seems to match the version at https://taipangame.com/BASIC.txt . The PDF version seems to be newly created for the book, intended to work with 40 columns and upper-case only, with textified graphics. – fadden Dec 10 '23 at 18:56
  • That link is interesting, I'll give it a run. However, I really want to stick with the book version as each chapter explains the separate mechanisms/routines... plus the copy and paste from the PDF is a nightmare (due to the awful font and formatting they've used) so loads of "OCR-type" typos are introduced (via the paste), and I've spent days fixing them all, getting the code into a runnable state... so I'm just trying to nail the last few, one of which is this 133 character. :-) I'll stick each of the chapters' code, and the combined code, up on github once I've nailed all of them. – Greenonline Dec 10 '23 at 18:57
  • 2
    @Greenonline - the answer I gave to your last question about Taipan included the full source from the book in runnable form as a disk image and text gist on github: assembly - Help understanding TAIPAN source code for the Apple II - Retrocomputing Stack Exchange – scruss Dec 10 '23 at 19:58
  • @scruss - Ok, I admit that I had forgotten about that, and "typed" (copy/pasted) it in myself. Oh well... at least the debugging was fun for a few days, and I've divided it up into the various chapters as well. However, line 150 of your code also has the CHR$(133). – Greenonline Dec 10 '23 at 20:12
  • That 5th glyph looks to me like it's an underscore, not blank. – Nonny Moose Dec 11 '23 at 05:29
  • @scruss - Upon reflection, to be fair to me, that wasn't my question. Plus I don't believe that your answer had been posted at the time that I saw that question. I had only seen Nick Westgate's answer with the link to the book in the last line of that answer. That's what led me to using the code from the book. – Greenonline Dec 11 '23 at 09:41
  • 1
    oops, sorry - thought it was. Two Taipan questions in the same short time .. – scruss Dec 12 '23 at 00:15
  • @scruss - No worries. Subsequently, it's been very useful to compare your code with my code. – Greenonline Dec 12 '23 at 18:27
  • 1
    @Greenonline: It's such a visible element, I can't believe they missed it. If you change 133 to 124, it's not really necessary, but visibly quite different. If anything, the lines in the TRS-80 version are nicer. – Nick Westgate Dec 13 '23 at 00:19
7

A quirk of the Apple II Monitor ROM, which I'd guess derives from the Apple I ROM (though I've not looked at that) is that the routines that input characters always set bit 7, thus yielding values 128-255, and the routines that output text require that bit 7 be set. Because AppleSoft BASIC treats ASCII as using codes 0-127, it always sets bit 7 of any text that it outputs. Thus, outputing CHR$(133) will have the same effect as outputing CHR$(5). I don't think the "normal" I/O routines, nor the extended versions supported by the 80-column card, make use of that character code, but custom output driver routines, such as those used to draw text on the hires screen, may do so.

supercat
  • 35,993
  • 3
  • 63
  • 159
2

Could it be that this is related to the second character set (Mousetext) available starting with the IIc and the enhanced IIe?

The examples seem to be all taken in 40 character mode which does normally not activate the second charset.

  • Writing $C00F (as in POKE 49167,0) would switch to Mousetext.
  • Another way is activating the 80 column firmware (PR#3) followed by some control code ($0F?).

(Can't test it right now - using a phone right now.)

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 1
    The PDF code is deliberately upper-case only, so it seems they were going for the lowest-common-denominator hardware. The original code was written for the TRS-80, so I was wondering if it was an unintentional flashback to that character set, but that would probably be 0x95 rather than 0x85. – fadden Dec 10 '23 at 22:02
  • @fadden Not necessary, especially not when inverse is used as well, as lower case is not available when inverse is used on an enhanced IIe or IIc with mousetext. Remember, screen codes are NOT Ascii on AppleII. Regular COUT will modify character codes below $A0 according to the inverse flag (1xx=normal, 00x=invers, 01x=blinking). I don't remember BASOUT (80 char FW )workings for exp-IIe and IIc (I'm still on the road. – Raffzahn Dec 10 '23 at 23:06
  • Unfortunately not. Adapting the code from here, doing PR#3 and then INVERSE : PRINT CHR$(27);CHR$(133);CHR$(24); : NORMAL didn't seem to produce the elusive vertical bar – Greenonline Dec 11 '23 at 00:49
  • 133 is unfortunately, beyond the valid range of MouseText characters (0x40 (64) to 0x5F (95)). @fadden - Yes, that is a good point (and along the lines of what I'd been thinking). However, as you say, looking at the TRS-80 character set, 133 is for two diagonal pixels. 0x95 or 0xAA seems to be a bar (left and right respectively). – Greenonline Dec 11 '23 at 21:16
  • 1
    @Greenonline The table on that Wikipedia page is incorrect. – Russell Borogove Dec 12 '23 at 16:40
  • @RussellBorogove - see these comments – Greenonline Dec 12 '23 at 18:26