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
30 NEXT 


Character set 0-255

Code with a more descriptive output

100 FOR N=1 TO 254 STEP 4
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.


  • 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..?


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?

  • 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
    Commented Dec 10, 2023 at 17:17
  • 2
    Maybe they wanted CHR$(124) (vertical bar, '|')?
    – fadden
    Commented Dec 10, 2023 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
    Commented Dec 10, 2023 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
    Commented Dec 11, 2023 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 Commented Dec 11, 2023 at 16:59

4 Answers 4


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

  • 1
    Perfect. We nearly had this answer earlier (see these comments). It is interesting, that (again), Wikipedia shows a different character set Commented Dec 12, 2023 at 1:20
  • 1
    @Greenonline: Yes, I saw that Wikipedia page but wanted to test it to be sure. Ironically, one of the references for that error-ridden character set is the website I linked to in my answer. Commented Dec 12, 2023 at 2:17

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.


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:


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):


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:


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.

  • 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
    Commented Dec 10, 2023 at 18:07
  • 3
    @Greenonline: the hi-res version extracted from a DOS disk (gist.github.com/fadden/d71f8b3adc87e3340251b556239d076e) seems to match the version at 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
    Commented Dec 10, 2023 at 18:56
  • 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
    Commented Dec 10, 2023 at 19:58
  • 1
    oops, sorry - thought it was. Two Taipan questions in the same short time ..
    – scruss
    Commented Dec 12, 2023 at 0:15
  • 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. Commented Dec 13, 2023 at 0:19

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.)

  • 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
    Commented Dec 10, 2023 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
    Commented Dec 10, 2023 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 Commented Dec 11, 2023 at 0: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). Commented Dec 11, 2023 at 21:16
  • 1
    @Greenonline The table on that Wikipedia page is incorrect. Commented Dec 12, 2023 at 16:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .