8-bit issue - MYZ80 and non-US keyboards - CP/M

This is a discussion on 8-bit issue - MYZ80 and non-US keyboards - CP/M ; 8-bit issue - MYZ80 and non-US keyboards Kim Sparre, Uwe Nass and I have been working on making MYZ80 "more international" recently by building .key files. MYZ80 can read .key files to define what character to return when you press ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: 8-bit issue - MYZ80 and non-US keyboards

  1. 8-bit issue - MYZ80 and non-US keyboards


    8-bit issue - MYZ80 and non-US keyboards

    Kim Sparre, Uwe Nass and I have been working on making MYZ80 "more
    international" recently by building .key files. MYZ80 can read .key
    files to define what character to return when you press keys on your
    keyboard. You do this naming your .key file MYZ80.KEY and putting it
    in
    the DOS directory that contains the emulator.

    The emphasis now is to figure out how to fix a problem involving
    keyboards that require all 8 bits for their character set. Right now
    we're working on the German and Danish keyboards. We have two .key
    files that work, but it seems currently only under CPM3, not CPM 2.2
    (MYZ80 lets you boot up in either of these environments). There's a
    STRIP7 MYZ80 utility in the MYZ80 1.21 and above distributions that
    needs to be run at startup to turn bit 7 stripping off (bits are
    numbered right to left starting at 0). But even after running it,
    certain keys on the German keyboard, for example, don't echo the
    correct character (under CPM 2.2).

    Here's a useful table (from Uwe):

    1. the wanted German "Umlaut"
    2. the corresponding IBM hex character
    3. what you get, if I use the original MYZ80
    4. what I get with your KBD129-8.KEY file (under CPM3 only)
    5. the corresponding hex character

    81 } ^A 01

    94 | ^T 14

    84 { ^D 04

    9A ] ^Z 1A

    99 \ ^Y 19

    8E [ ^N 0E

    E1 ~ a 61

    We've reached the point where we think there are two things that need
    to be investigated.

    1. The CP/M 2.2 BIOS supplied under the MYZ80 emulator may need to be
    looked at to see if it's doing something with the high order bit.

    2. It may be that CP/M editors, like ZDE and VDE, are doing something
    with the high order bit. Their source may need to be changed or
    another editor needs to be found that works. We've tested the CP/M
    version of VEDIT and it didn't help. WordStar uses the high bit for
    its own purposes.

    A separate but somewhat related issue is the "DOS code page" used by
    the Windows command interpreter when running MYZ80 in a DOS window. We
    have found that code page 437 (the original IBM PC character set) is
    being used on Lee's system and code page 850 is being used on Kim's
    system. Lee gets cent signs where Kim gets ""-s and Yen-signs instead
    of ""-s. If you EXPORT a text-file, it must be converted in order to
    show the usual "Windows Western" or ISO 8859-1 (Latin 1) characters.
    Writing such a converter is being considered.

    We're wondering if anyone has or used to have a CP/M machine that uses
    an extended 8-bit character set. If so, do you have or know of an
    editor that accepts 8-bit characters (preferably with source)?

    We're looking for testers for other languages. What keyboard layout
    are they using and what code page?

    Here's a link to an archive that has the German and Danish 8-bit .key
    files.

    http://primepuzzle.com/mouse/8BIT-KBD.zip

    Thanks,

    Lee, Kim and Uwe

  2. Re: 8-bit issue - MYZ80 and non-US keyboards

    On Mon, 25 Feb 2008 04:59:01 -0800 (PST), Lee
    wrote:

    >
    >8-bit issue - MYZ80 and non-US keyboards
    >
    >Kim Sparre, Uwe Nass and I have been working on making MYZ80 "more
    >international" recently by building .key files. MYZ80 can read .key
    >files to define what character to return when you press keys on your
    >keyboard. You do this naming your .key file MYZ80.KEY and putting it
    >in
    >the DOS directory that contains the emulator.
    >
    >The emphasis now is to figure out how to fix a problem involving
    >keyboards that require all 8 bits for their character set. Right now
    >we're working on the German and Danish keyboards. We have two .key
    >files that work, but it seems currently only under CPM3, not CPM 2.2
    >(MYZ80 lets you boot up in either of these environments). There's a
    >STRIP7 MYZ80 utility in the MYZ80 1.21 and above distributions that
    >needs to be run at startup to turn bit 7 stripping off (bits are
    >numbered right to left starting at 0). But even after running it,
    >certain keys on the German keyboard, for example, don't echo the
    >correct character (under CPM 2.2).
    >
    >Here's a useful table (from Uwe):
    >
    >1. the wanted German "Umlaut"
    >2. the corresponding IBM hex character
    >3. what you get, if I use the original MYZ80
    >4. what I get with your KBD129-8.KEY file (under CPM3 only)
    >5. the corresponding hex character
    >
    > 81 } ^A 01
    >
    > 94 | ^T 14
    >
    > 84 { ^D 04
    >
    > 9A ] ^Z 1A
    >
    > 99 \ ^Y 19
    >
    > 8E [ ^N 0E
    >
    > E1 ~ a 61
    >
    >We've reached the point where we think there are two things that need
    >to be investigated.
    >
    >1. The CP/M 2.2 BIOS supplied under the MYZ80 emulator may need to be
    >looked at to see if it's doing something with the high order bit.
    >
    >2. It may be that CP/M editors, like ZDE and VDE, are doing something
    >with the high order bit. Their source may need to be changed or
    >another editor needs to be found that works. We've tested the CP/M
    >version of VEDIT and it didn't help. WordStar uses the high bit for
    >its own purposes.
    >
    >A separate but somewhat related issue is the "DOS code page" used by
    >the Windows command interpreter when running MYZ80 in a DOS window. We
    >have found that code page 437 (the original IBM PC character set) is
    >being used on Lee's system and code page 850 is being used on Kim's
    >system. Lee gets cent signs where Kim gets ""-s and Yen-signs instead
    >of ""-s. If you EXPORT a text-file, it must be converted in order to
    >show the usual "Windows Western" or ISO 8859-1 (Latin 1) characters.
    >Writing such a converter is being considered.


    Not surpizing as most CP/M programs use US ASCII 7bit as character
    mapping. DOS does a remapping of those with the code page so
    a specific 7bit value in ASCII is has a mapping in the larger IBM
    US english code page that has limited coropondence in a foreign
    code page. This is an old problem that plagued those that would try
    to internationalize non-PC systems that were US or English based.

    So if you want to se the same thing and have it match the original
    code all of the users must use the same IBM code page (it can be
    switched in and out).

    >
    >We're wondering if anyone has or used to have a CP/M machine that uses
    >an extended 8-bit character set. If so, do you have or know of an
    >editor that accepts 8-bit characters (preferably with source)?


    You are going to have to take something like VDO or VDE editors
    are rewrite it.

    CP/M and the world lived by the 7Bit ASCII character set and the PC is
    a different world created by itself for itself. A better place to
    look at is the 7bit sets used for VT100, VT220 and similar terminals
    that were dominent from about 1980 to a 1990 for guidence. Actaully
    CP/M itself in dome cases cannot use 8bit chars as file names as
    stored the upper bit is reserved or actually used for such things as
    R/O, System, and Hidden files. There are 11such bits (Bit 7) in the
    potential file name (FILENAME.FOO).

    Also old databooks from Motorola, SMC, and other vendors of character
    roms used in the late 70s through 90s.

    I do beliefve the Robin (DEC VT180) was exported. It would use the
    VT100 series terminal localizations. Since VT100 was fairly popular
    and widely copied that should give a clue.

    >We're looking for testers for other languages. What keyboard layout
    >are they using and what code page?


    CP/M had no idea or concept of "code page" as that was both character
    map and pixel map for PCs (key to char, Char to CRT bitmaps).

    CP/M Sims and emulators on PCs are mostly prone to the issue.
    CP/M systems of the day were either localized or default US ASCII.
    If it was localized there were limited exposure, IE: not seen out of
    that area as localization included power cords, power supplies,
    Docs and other language and country specific items.

    Allison

    >
    >Here's a link to an archive that has the German and Danish 8-bit .key
    >files.
    >
    >http://primepuzzle.com/mouse/8BIT-KBD.zip
    >
    >Thanks,
    >
    >Lee, Kim and Uwe



  3. Re: 8-bit issue - MYZ80 and non-US keyboards

    Lee wrote:
    > 8-bit issue - MYZ80 and non-US keyboards
    >
    > Kim Sparre, Uwe Nass and I have been working on making MYZ80 "more
    > international" recently by building .key files. MYZ80 can read .key
    > files to define what character to return when you press keys on your
    > keyboard. You do this naming your .key file MYZ80.KEY and putting it
    > in the DOS directory that contains the emulator.
    >
    > The emphasis now is to figure out how to fix a problem involving
    > keyboards that require all 8 bits for their character set.
    > [...]
    > Here's a useful table (from Uwe):
    >
    > 1. the wanted German "Umlaut"
    > [...]


    I do not get the point. On www.z80.de/downl.htm there is already a
    MYZ80.ZIP (v1.24) with a KEY.COM and a GERMAN.KEY inside (on the
    emulated disk A), which works perfectly.
    For sure there is only one way to use german special characters - like
    you already described: Ue = ], ue = } ... and so on.
    All CP/M computers used a 7 bit character set, so the 'umlauts' were
    *always* mapped to other 7 bit ASCII chars.
    I see no necessity for getting 'Ue' and ']' at the same time.

    Regards
    Peter
    --
    * Try http://www.z80.eu for CP/M computer and software infos.

+ Reply to Thread