Robert Maas, <jaycx2.3.calrobert@spamgourmet.com.remove> wrote:
+---------------
| > From: rpw3@rpw3.org (Rob Warnock)
| > In the LGP-30, they used hex addresses, sort of[1], but the
| > opcodes (all 16 of them) had single-letter mnemonics chosen so that
| > the low 4 bits of the character codes *were* the correct nibble for
| > the opcode!  ;-}
...
| By the way, do you remember exactly all the 16 opcodes, or have a
| Web reference available?
+---------------

There are quite a few out there; here's one:

    http://www.users.nwark.com/~rcmahq/jclark/lgp30.htm

Some notes on the opcodes:

- "Bring" (B) would be called "Load" in current parlance.

- "Extract" (E) would be called "And" in current parlance.

- "Unconditional Transfer" (U) would be called "Jump" or "Branch".

- "Hold" (H) would be called "Store"; "Clear" (C) would be called
  "Store-and-Clear" (the "DCA" instruction of the DEC PDP-8).

- There are two "Multiply" ops, "M" & "N", depending on whether the
  upper or lower bits (respectively) of the product are returned.

- "Store Address" (Y) stores an address in the AC into the address
  field of the destination [yes, modifying the code in-place!! --
  it was mostly used for indexing through arrays], whereas the
  "Return Address" (R) stores the current instruction address + 2
  into the address field of the destination. The subroutine calling
  sequence is thus an "R/U" pair:

	      R foo_last
	      U foo

  where the FOO subroutine might be written as:

    foo:      ...
              ...
    foo_last: U foo_last     ; overwritten

+---------------
| > The LGP-30 character code was defined before the industry had
| > yet standardized on a common "hex" [sic, "hexadecimal", base 16
| > not base 6!!!] character set,
...
| > they used "0123456789fgjkqw".
| 
| That doesn't make sense. The low-order four bits of those letters
| aren't consecutive ascending values from 9+1 to 9+6. Did you make a
| typo, or did you explain something wrong?
+---------------

No, what I wrote is correct. The low 4 bits of "0123456789fgjkqw" 
*are* 0 through 16 (or "0123456789abcdef" in current "hex")... IN
THE *LGP-30 FLEXOWRITER* CHARACTER CODE, *not* in ASCII or EBCDIC
or Baudot or any other standard code.

Well, actually, it's a little more complex than that. The LGP-30
used a 6-bit "keyboard" code on the Flexowriter (and the paper tape
reader & punch), but the machine could be put into either 6-bit or
4-bit input mode. In the latter, only the first four bits of each code
got shifted into the accumulator. So I suppose you could say those
were the *upper* 4 bits of each character, though when read into
the accumulator in "4-bit input mode" they truly *were* the lower
4 bits. (Sorry for the confusion. It was an "interesting" machine.)

+---------------
| (map 'list #'char-code "0123456789fgjkqw")
| => (48 49 50 51 52 53 54 55 56 57 102 103 106 107 113 119)
+---------------

That's ASCII. The LGP-30 did not use ASCII. The LGP-30 used
Flexowriter keyboard code, see:

    http://ed-thelen.org/comp-hist/lgp-30-man-f002.gif


-Rob

p.s. The full programming manual for the LGP-30 can be found here:

    http://ed-thelen.org/comp-hist/lgp-30-man.html

but good luck reading its archaic style.  ;-}

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607