Discovering APL/Z on CP/M

354 views
Skip to first unread message

Mark Cummings

unread,
Mar 26, 2021, 9:25:51 AM3/26/21
to IMSAI 8080esp
I was rather surprised to find that there is a version of APL (A Programming Language) that runs on CP/M, called APL/Z or APL-Z80 or similar titles.

APL is one of those hard to read programming languages that use a lot of special glyphs that normally require a special terminal and keyboard to operate. It's difficult to interpret a program listing without a good understanding of the language, and even harder to interpret on the CP/M version without the glyphs or much information available.

I downloaded it, I think from a Z80 pack if I recall correctly. The file is APLZ11.zip.
I've set up the drives on the IMSAI as follows:
A: DSK: = “cpm22b01.dsk”
B:DSK: = “C2_APL.dsk”
C:DSK: = “C2B_APL.dsk”

After booting CPM 2.2 on the A: drive, I then log onto the B: drive and run C:APL. This gives me room to save programs (aka workspaces) on B: drive.

Anyway the biggest issue I have run into, is not having much documentation and trying to figure out what each key is on the keyboard (including overtyped glyphs) and what character is displayed.
I did find one document that gives a pretty good overview of everything that it should be able to do and I've attached that for anyone interested. This is by far the best document I've found but it is missing a few things and uses the APL font in it as though it isn't even an issue. maybe not on the system it was written on, but definitely on an ASCII keyboard and ASCII display like I have on the IMSAI.

I have used various versions of APL since I first learned it back in the late 70's on an IBM mainframe computer (360 or 1130 as far as I recall on an 3278 or similar video terminal). I've run APL Plus in a DOS environment previously, and more recently Dialog APL on a linux box and APLX on Windows. Every version has it's own version of the language support, it's own code page for the character set and even different keyboard layouts, so it's a mine field to navigate.

I am working through the document and making notes to check it's integrity and learn the specific features of this CP/M version of APL/Z.
Ultimately I would like to get this version to display proper APL glyphs and document it's use for others to enjoy. I've briefly discussed this with Dave so that the character set might be incorporated into the VT132, but I don't want him to waste any time on it until I can figure out what is needed. However to do that I have to take baby steps.

Within the APL language there is a command to display all the 256 APL characters (QUAD-AV command). some of those are control characters like ASCII. One problem I've run into is displaying more than 128 different characters from either the TTY: screen in the IMSAI GUI, or using PuTTY: on Linux. It appears as though the higher 128 bytes are identical to the lower 128 bytes (maybe except for control characters). At this stage I can't figure out if this is a limitation of one of the following:
1) CP/M 2.2 O.S. or APL.COM language program truncating the set to 7 bits.
2) The TTY: GUI terminal only using 7 bits or the upper 128 characters matching the lower 128 characters.
3) The PuTTY: session using only 7 bits or the upper 128 characters matching the lower 128 characters.

I've just received my VT132 kit and plan to duplicate those tests to see if there is more than 128 distinct characters that the terminal can display and progress with the task.

Can anyone give me a clue on how I might be able to display more than 128 characters (visually) on any of their setups, either TTY: or VT132, or PuTTY. It doesn't necessarily have to be APL application. just something so I can progress with my investigation.

thanks,

Mark.
APL-Z80.pdf

Mark Cummings

unread,
Mar 26, 2021, 12:45:31 PM3/26/21
to IMSAI 8080esp
I thought it might be handy to demonstrate the problem running APL/Z in CP/M on the IMSAI so you can see the scope of the problem. That is not being able to display any of the APL glyphs, not seeing some substitute ASCII characters during a listing, and characters being displayed during keyboard entry differing from the same characters during output listing.

I will list the problems using UTF-8 fonts below but I am not sure if Google Groups or your browser/computer will display the fonts/characters correctly, so I will also attach a screen grab of each LISTING.

This is an APL/Z program listing for a simple base conversion program. this is a slightly modified listing from the APL360 user manual (page 3.29).


LISTING 1: what it should look like when entering program using the correct APL glyphs:

      ∇Z←B BASE N

[10]  Z←⍳0

[20]  Z←(B|N),Z

[30]  N←⌊N÷B

[40]  →20×N>0

[50]  ∇


LISTING 2: what it actually looks like while entering program in APL/Z:

      Gz`b base n

[10] z`I0

[20] z`(bMn),z

[30] n`Dn%b

[40] @20*n>0

[50] G


LISTING 3: what it looks like when listing the same program in APL/Z:

      Gbase[L]G

      @b base n

[10] i0

[20] (b|n),z

[30] Ln%b

[40] @20n>0

      @


RUNNING: this is the program running correctly in APL/Z:

      10 base 1776

1 7 7 6

      8 base 1776

3 6 6 0


As you can see, even without any APL programming experience, there is very little resemblance between what the program should look like vs. what it looks like while entering vs. listing the program.

1. None of the special APL glyphs are displayed during program entry, listing or running.

2. Characters used during program entry differ from those when listing the program.

3. some characters are dropped (possibly being treated as a control character) during program listing.

4. not shown, but overstruck characters are also not displayed during entry, but they seem to work if they are valid characters. An overstruck character is one that uses two simple glyphs in order to enter one of the keyboard characters that might not have been supported by direct keyboard entry on this version of APL. For example QUAD QUOTE character is a box ( ⎕ ) and a single quote ( ' ) overstruck to create QUAD-QUOTE ( ⍞ ).


Anyway, hopefully this demonstrates the scope of the problem that I am trying to solve.


Mark.

RUNNING.png
LISTING1.png
LISTING3.png
LISTING2.png

Tony Nicholson

unread,
Mar 27, 2021, 5:08:50 PM3/27/21
to IMSAI 8080esp
On Saturday, March 27, 2021 at 12:25:51 AM UTC+11 Mark Cummings wrote:
I was rather surprised to find that there is a version of APL (A Programming Language) that runs on CP/M, called APL/Z or APL-Z80 or similar titles.

[snip]
 
I've just received my VT132 kit and plan to duplicate those tests to see if there is more than 128 distinct characters that the terminal can display and progress with the task.

Can anyone give me a clue on how I might be able to display more than 128 characters (visually) on any of their setups, either TTY: or VT132, or PuTTY. It doesn't necessarily have to be APL application. just something so I can progress with my investigation.

Mark,

This should be do-able by making sure the BIOS can output 8-bit characters, and via a downloadable font.

There's a youtube video of a similar ressurection of VAX/VMS APL on a VT320 terminal at


Tony

udo....@freenet.de

unread,
Mar 28, 2021, 12:59:07 AM3/28/21
to IMSAI 8080esp
The BIOS's are 8-bit clean and won't strip the parity bit.

Fred Weigel

unread,
Mar 31, 2021, 8:55:58 AM3/31/21
to IMSAI 8080esp
As indicated in file APL.DOC, there are two character translation tables at 700h (ascii->apl internal) and 0f00h (apl internal->ascii)
Note that these addresses are DDT patch addresses -- file addresses are, of course, 100h lower.

You may wish to find/modify your terminal to use an APL font (KAPL.TTF attached as a starting point). You will need to map
internal APL <-> ascii.

Below, find an APL keyboard/layout I use for my editor when I do apl  Note that the APL symbols here are in UTF-8,
so have a chance of being displayed correctly . The keyboard layout is a "typical" apl layout. (works best in monospace)
This also (if you copy and paste it) will give you the APL <->UTF-8 mapping.

╔════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦════╦═══════╗
║ ~  ║ !⌶ ║ @⍫ ║ #⍒ ║ $⍋ ║ %⌽ ║ ^⍉ ║ &⊖ ║ *⍟ ║ (⍱ ║ )⍲ ║ _! ║ +⌹ ║       ║
║ `◊ ║ 1¨ ║ 2¯ ║ 3< ║ 4≤ ║ 5= ║ 6≥ ║ 7> ║ 8≠ ║ 9∨ ║ 0∧ ║ -× ║ =÷ ║ BACKSP║
╠════╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦═╩══╦════╣
║       ║ Q  ║ W⍹ ║ E⋸ ║ R  ║ T⍨ ║ Y¥ ║ U€ ║ I⍸ ║ O⍥ ║ P⍣ ║ {⍞ ║ }⍬ ║ |⊣ ║
║  TAB  ║ q? ║ w⍵ ║ e∈ ║ r⍴ ║ t∼ ║ y↑ ║ u↓ ║ i⍳ ║ o○ ║ p⋆ ║ [← ║ ]→ ║ \⊢ ║
╠═══════╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩═╦══╩════╣
║  CAPS   ║ A⍶ ║ S  ║ D◊ ║ F  ║ G  ║ H  ║ J⍤ ║ K  ║ L⌷ ║ :≡ ║ "≢ ║       ║
║  LOCK   ║ a⍺ ║ s⌈ ║ d⌊ ║ f_ ║ g∇ ║ h∆ ║ j∘ ║ k' ║ l⎕ ║ ;⍎ ║ '⍕ ║ RETURN║
╠═══════╦═╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══╦╩═══════╣
║       ║     ║ Z  ║ Xχ ║ C¢ ║ V_ ║ B£ ║ N  ║ Mλ ║ <⍪ ║ >⍙ ║ ?⍠ ║        ║
║ SHIFT ║ ALT ║ z⊂ ║ x⊃ ║ c∩ ║ v∪ ║ b⊥ ║ n⊤ ║ m| ║ ,⍝ ║ .⍀ ║ /⌿ ║  SHIFT ║
╚═══════╩═════╩════╩════╩════╩════╩════╩════╩════╩════╩════╩════╩════════╝

FredW

KAPL.TTF

Fred Weigel

unread,
Mar 31, 2021, 3:01:35 PM3/31/21
to IMSAI 8080esp
Ok, I cannot answer for your DEC terminal implementation. The 340 should have soft character set. But XTERM doesn't support that.
Given that I do not have that terminal, I went with XTERM, as it is the closest to a VT-100, and the emulator I use as my daily driver.
I normally use APL with UTF-8 and that works fine. APLZ11 doesn't want that, it want 8 bit characters in and out. So, I settled on
APLCODE.FON (a Windows bitmap font) It can be downloaded from http://www.sigapl.org/fonts/FontsIndex.php
I used fontforge to convert that to BDF, and bdftopcf to compile, and then gzip to compress. That gives the three font files attached.
Copy these (on Linux) to ~/.fonts and run mkfontdir in that directory. Restart the X server (log out and in or reboot).

I then launch XTERM with the command

xterm -fn -fontforge-aplcode-normal-r-*-*-20-*-*-*-*-*-*-* \
      -xrm "XTerm*eightBitControl: true" \
      -xrm "XTerm*eightBitInput: true" \
      -xrm "XTerm*eightBitOutput: true" \
      -xrm "XTerm*eightBitMeta: true" \
      -xrm "XTerm*allowC1Printable: true" \
      -xrm "XTerm*font1: -fontforge-aplcode-normal-r-*-*-16-*-*-*-*-*-*-*" \
      -xrm "XTerm*font2: -fontforge-aplcode-normal-r-*-*-16-*-*-*-*-*-*-*" \
      -xrm "XTerm*font3: -fontforge-aplcode-normal-r-*-*-20-*-*-*-*-*-*-*" \
      -xrm "XTerm*font4: -fontforge-aplcode-normal-r-*-*-20-*-*-*-*-*-*-*" \
      -xrm "XTerm*font5: -fontforge-aplcode-normal-r-*-*-32-*-*-*-*-*-*-*" \
      -xrm "XTerm*font6: -fontforge-aplcode-normal-r-*-*-32-*-*-*-*-*-*-*"

And that gives me three sizes of APL font. Each of these has the mapping per the screen shot (we have to do it that way because the characters are NOT UTF-8)... As we see, we have enough APL characters to cover... and now, the interpreter input/output tables need
patching. Bad news... NONE of this REALLY helps you, because of the VT132. What would be helpful (*if* the VT132 can have a soft character set) is to have the top 128 characters be programmable. The VT100 supports alternate sets (ESC(B ESC(0 and ESC(A commands) Later terminals support more -- I don't believe that APL was ever offered (possibly as a custom option). The VT320/340 offered sixel graphics, and soft characters (XTERM supports sixel, but not soft characters -- go figure).

The stuff here will get you close -- if you can reprogram the VT132 character set to the FON or PCF file (which is a bitmap font).

If you have a machine that can run XTERM, try the attached font... That will allow you to patch the APL COM file and get the experience.
I can assist, but am tied up for about two weeks...

I use an Altair-Duino and use a linux based xterm as the console (over a bluetooth serial link) at 9600 baud. I like that because xterm supports accurate vt100 (including vt52 submode), sixel graphics, regis graphics and tek 4014 graphics. xterm *can* be abused to do things like APL. The vt52 submode is important because that is the only way to use SPELSTAR (for instance).
APLCode-16.pcf.gz
Screenshot from 2021-03-31 14-39-46.png
APLCode-20.pcf.gz
APLCode-32.pcf.gz

Fred Weigel

unread,
Mar 31, 2021, 3:14:52 PM3/31/21
to IMSAI 8080esp
Mark

I am not at all surprised. The MCM\70 https://en.wikipedia.org/wiki/MCM/70 was a 8008 based system that had APL in ROM.
(16kb addressing) -- usually 8kb for your APL programs. One of the earliest (it predates the Altair 8800) and *any* z80 system.
Mers Kutt loved APL -- still had APL keyboards around when I worked with him (1986-87 https://www.youtube.com/watch?v=xgMIbo6QoM4)

On Friday, March 26, 2021 at 9:25:51 AM UTC-4 Mark Cummings wrote:
Reply all
Reply to author
Forward
0 new messages