Extended, Binary Coded, Digital Instrumentation Code

Disclaimer:

Unicode and character encoding in general is a huge complex subject area and I am only provisionally conversant with the possibilities inherent therein. I know that using UTF-8 tends to show me the least number of untranslatable characters in the text that I can actually read (IE: mostly English) and that is as far as I have studied the subject. The tables below are an example, but nowhere near a 'standard'.

Honestly, I just threw this generic table together because it illustrates how Instrumentation can subsume existing standards. These Unicode tables will provide a native way to enter text from multiple writing systems so that it can be used with Instrumentation's internal search functions. There are probably many "More Intuitive" text table formats than this direct import, but this is usable, if awkward.

Introduction

Including the Unicode tables will make Instrumentation independent of the need for any keyboard beyond the Instrumentation Chorded Keyboard for entering text in any character set covered by Unicode.

EBCDIC (actually "Extended, Binary Coded Decimal, Interchange Code") is the character table used by teletypes and the IBM System/360, which was the 8 Kilobyte mainframe computer used in the 1960s. That's right, 8K of RAM. If you needed more space than that, you had to page it in and out from the tape memory back-up.

Those old movie images of (BIG SCARY COMPUTER!) reel to reel tapes spinning madly are actually showing the computer reading and writing its 8K of RAM while it slogs through some "COmmon Business Oriented Language" sort routine. Of course, this was when magnetic core memory was used and a 'bit' occupied a chunk of ferrite that you could see without your bifocals (and still, we were happy).

This block is just one small part of the Unicode 3.1 (ISO 10646-2) standard (I think). Instrumentation can encode 24 bits in a single area, so we should be able to import the entire useful part of the UCS address space with no modification. I picked EBCDIC, because:

• It has less than 256 'characters'
• It is an important part of data processing history
• ascii is so pathetic that the acronym isn't even always capitalized
• The 'EBCDIC-DK-NO-A' character map was readily available
• I believe that this is a Danish character map
  

There will be many other single and double byte character maps within this Area of the Instrumentation address space, this just happens to be the one I used as an example.

This design uses the following eight Types:

None:

This block doesn't actually use the Types at all. The number in each cell is the "Symbolic Name" from the Linux "charmap" schema. The "Character Encoding" number might have been a better choice, but I picked the one that was easiest to scan (the HTML tables below were created by a Java program that I wrote).

This block would require the Employment lath. That would put it somewhere in the #02 Specialization area. Currently I'm planning on dedicating the entire #02 area to character translation by importing the bottom six bytes of the Unicode mapping standard directly into this area. There will probably be a block or two in the "user Interface Area" that will provide ISO character set names as an external index into these tables (because the Unicode tables, sadly, do not follow the Instrumentation standard indexing plan).

The terms are organized into four tables, each containing four sub-tables (or banks) which consist of sixteen cells. each cell contains a standard character name.  the headings before the four tables below are totally generic. the dark rows and columns within each table are also utterly generic.

I'm really only using this format out of habit. If there is any pattern to the character layout below it is purely coincidental.