• Please review our updated Terms and Rules here

Bit7 in CP/M characters.

No I'm not. EBCDIC or ASCII representation is hard-coded into the S/360 and later machine microcode.

As a very simple example, consider S/360 packed decimal representation. In particular look at Pinciples of Operation, PDF page 35, second paragraph. In the following sections, note that in the case of ED, EDMK and UNPK instructions different codes are generated, depending on the setting of the PSW "A" bit.

As another example, consider the Unpack to Zoned instruction on the CDC STAR manual here. Starting on page 288, note the discussion about coding of signs and digits, depending on the ASCII or EBCDIC bit setting in the applicable instruction.

The coding has nothing to do with peripheral function---it's hard-coded into the CPU firmware. The user is not free to use his own representations and expect the hardware to function correctly.
 
FWIW, dug around a little more and it looks like I was mistaken, or at least mislead, in thinking the Displaywriter has (much) ASCII support. The keyboard driver apparently supports the generation of ASCII-standard control characters, apparently for use in telecommunication type apps?, but the video hardware is all in on EBCDIC. There's very little documentation about how CP/M-86 (or MS-DOS, for that matter) was actually implemented on the machine, seems like both OSes were little more than vaporware (although there are is at least a video of someone booting MS-DOS 1.25 on it), but it appears they probably both dealt with the differences by using translation in their BIOS/BDOS interfaces.
 
No I'm not. EBCDIC or ASCII representation is hard-coded into the S/360 and later machine microcode.
...
These examples are all data conversion instructions, which of course are limited to (targeted at) specific encodings. The presence of these instructions only means that the CPU has *support* for ASCII or EBCDIC, not that the CPU can only represent data in ASCII/EBCDIC. The CPU is character-code agnostic, but has helper instructions for dealing with ASCII/EBCDIC peripherals. In addition, character encodings for ASCII or EBCDIC have no special meaning to the CPU - the CPU does not do *arithmetic* in ASCII, does it? - only having meaning to the peripherals and programmers.
 
The instructions are an integral part of the CPUs repertoire. By saying that they're used for conversion, aren't you employing the "no true Scotsman" defense? None comes to mind, but I'm not denying the possibility that there is a CPU architecture out there that actually does arithmetic in ASCII. Packed decimal is simply more efficient.
 
That doesn't jibe with the DW floppies I process. All EBCDIC. I suppose that the firmware could translate all of that ASCII to EBCDIC for the disk and printer, but seems silly.
All of Textpack, and CED, is written in EBCDIC (except for the ASC and BSC broadcasts, which are then translated back to EBCDIC).

However, everything I've seen points toward the Displaywriter hardware supporting the ASCII code set.

The way CP/M and DOS for Displaywriter works is that the initial few sectors are EBCDIC but the Displaywriter is instructed to go into ASCII mode before IPL, and the file system is in ASCII. If I recall from when I looked at the CP/M hex, even the loading text prior to the splash screen is ASCII. Displaywriter keyboard ID 102 and 103 use ASCII (as opposed to the EBCDIC options shown above). Keyboard ID 103 is what is selected by CP/M-86 rev 1.03 and above, as well as by ASC and BSC during teleprocessing. DOS and CP/M rev 1.02 and below, manually map the ASCII characters in a character table. The DOS character map is located at sector 41 of the disk. Additionally, accessing the ASCII control characters is outlined on page 5-13 of the Product Support Manual. If I'm missing something here, please let me know, but everything I've seen points towards the system supporting both. I don't believe it would have been possible to easily port MP/M, CP/M, DOS and p-System to the Displaywriter if it was EBCDIC only.

1689434568900.png
1689434808402.png
 
Last edited:
As far as the control codes in the 0/ and 1/ rows, they're very close in EBCDIC and ASCII.


Supporting ASCII on an EBCDIC terminal interface (display/keyboard) is mostly a matter of translation. It's convenient that the DW supports both, but not strictly necessary. For a few years, I used an EBCDIC keyboard (from a Spectrola 70) on my S100 system. Other than the characters present in one set but not the other (e.g. "cents" and "not" in EBCIDIC), it's not a big problem. But every native DW WP disk that I've seen has been exclusively EBCDIC, which makes sense, since there were options for a DW to connect to a IBM mainframe).
To the programmer, coding in EBCDIC, when you're used to ASCII that things collate differently (e.g. backslash falls between R and S) and that numbers collate higher than letters.

The thing to remember is that EBCDIC is an 8 bit code, based on a 6 bit (BCDIC) code, while ASCII is essentially a 7 bit code.

It's also noteworthy that the DW support for ASCII might be a popular topic in the vintage area today, had the keyboard hackers not scavenged most of the keyboards and rendered them useless for their original purpose.
 
The displaywriter being an actual computer means it could support any sort of mainframe host desired. Regardless of what the display and keyboard were, the data exchanged with the host could be anything. Do you have evidence that the keyboard and video were using EBCDIC internally (instead of ASCII)? Seems more likely that the displaywriter was a fairly-normal micro (using ASCII) and that EBCDIC was just a product of the software being run when communicating with the remote system. Machine code (object code) is neither ASCII nor EBCDIC, but that code uses whatever binary data patterns are desired to communicate with peripherals (including the remote system). It that sense, whatever machine code is booted determines what the system will do.
 
It's difficult to tell for certain from the wikipedia page whether the keyboard encoder and video character generator were actually using EBCDIC or not. It's certainly possible that IBM chose to make it all EBCDIC internally. It took a while for IBM to finally let go of EBCDIC, although one could say they still haven't dropped it completely. I worked on a lot of IBM hardware and software from 2006 onward, and that which I worked on was pure ASCII based. I'm not sure what the s390 does internally (in hardware), but I'm pretty sure the s390 Linux is all ASCII.
 
Do you have evidence that the keyboard and video were using EBCDIC internally (instead of ASCII)? Seems more likely that the displaywriter was a fairly-normal micro (using ASCII) and that EBCDIC was just a product of the software being run when communicating with the remote system

The service manual on Bitsavers has a chart showing the contents of the video character generator (FWIW, it actually had a 9 bit repertoire, with 256 “main” characters and a symbols/foreign character page) and the arrangement of the characters is EBCDIC, not ASCII. Unless it had programmable character sets or an alternate page that I couldn’t really see evidence of it looked to me that to use an ASCII OS on it you’d need to go through a translation table.

The keyboard encoding section was just confusing. It mentions being able to generate standard ASCII *control* characters, but I don’t know what that translates to in the hardware. The keyboard might just spit out positional key codes and the BIOS translates them to whatever encoding you want, it’s not exactly clear the keyboard is “inherently” EBCDIC or ASCII.
 
True, given the vintage (dawn of the IBM PC) it is likely that the keyboard generates scan codes and it is up to the OS to encode that for the programs - like the way the PC works. With an EBCDIC character generator, it is highly likely that EBCDIC is the character code used for the display. So, the CP/M-86 that DRI shipped must have had the necessary translators in the BIOS for scan codes to ASCII (input) and ASCII to EBCDIC (output) for the console. Character codes used on serial ports and any other communications hardware would have been up to the software and would align with whatever is on the other end of the communications link. Things like disk (tape, etc) don't care since their job is just to read back the same bits that were written.

It appears that "most" CP/M-86 programs would run on this system, which means the core, ASCII, CP/M-86 must have been used, and any necessary translation done at the last minute in the BIOS.
 
From WIkiP:
While the internal data stream of the Displaywriter is EBCDIC, the Displaywriter was already fully capable of translating the data stream into displayable ASCII outputs as part of the features of the Textpack software. This functionality was used to run CP/M-86 in ASCII mode.

This document hints at emulation of a number of terminals and keyboards.

Got to bow out of this; I've got about 60 Wang OIS-140 that I need to puzzle out.
 
Last edited:
The odd thing about the wikipedia page is that it calls "Textpack" an operating system, and presents it as a peer to MS-DOS and CP/M-86. So it is hard to imagine how Textpack can provide ASCII services to CP/M-86 - unless that paragraph is simply saying that CP/M-86 uses the same techniques as Textpack. But it is certainly possible that there is a ROM BIOS of some sort, that could provide the routines to do the translation for any of OSes and make the CP/M-86 BIOS fairly skinny.
 
I suppose I did a poor job of explaining myself here...
The Displaywriter internal data stream is EBCDIC, but translation to ASCII is available as an interpretation table that can be set in software OR with jumpers located on the keyboard. There are actually over 70 of these on-board tables in order to easily emulate a wide range of different terminals, languages and layouts (such as DVORAK). CP/M-86, DOS, (and likely p-System, which I do not have and insufficient documentation is available for) piggyback off of this translation in order to run on Displaywriter. I understand where the confusion came from when I said that the Displaywriter "utilizes" ASCII...but the reason I said this is because the hardware is fully capable of translating to it, rather than CP/M-86 being rewritten to support EBCDIC. The document Chuck linked is the one I used (in addition to testing with CP/M-86 & ASC/BSC) to come to this conclusion, though I couldn't locate it for my previous post. See below for examples in the documentation of the Displaywriter's capabilities and as evidence of the internal data stream being EBCDIC:
1689479080545.png
1689479119818.png
1689479173570.png
1689479610362.png
And as a full disclosure, since it keeps being referenced...I actually wrote almost the entirety of the still unfinished Wikipedia article...so perhaps it is not the best source to use as a reference in this discussion. However, the article presents Textpack on equal footing to DOS and CP/M because while it's not a full "general purpose" OS, it is still an OS and from a historical perspective, Textpack was more relevant of an operating system to the Displaywriter than any of the others. I did try to explain the limitations of Textpack in the section dedicated to it, but if you feel it could be explained better please edit the article to bring a better level of clarity. Article aside, hopefully the primary sources linked here, have been sufficiently clarifying on the matter.

Additionally, for further clarity:
Pretty much all multi-system CP/M-86 programs can run on the Displaywriter except those that require BDOS 3.0, and those which call for any graphics which aren't text, because the display card is only capable of rendering text. Programs that require BDOS 3.0 can run on the MP/M-86 port though. Programs that were localized for a specific system, such as for the NEC APC, do not run usually, for I guess obvious reasons.
The Displaywriter ROS chips, not the Textpack software, provide "ASCII services" to CP/M-86 and Textpack. CP/M-86 uses the same techniques as Textpack. "Any necessary translation done at the last minute in the BIOS" <- yes and it is done in real time on demand. I believe that it is done on the display card, but it may be done on card B.
The Displaywriter always begins IPL with EBCDIC and machine code instructions. It actually looks for a specific string to determine if the disk is bootable. I don't remember the specifics offhand, but it's very short. About eight characters.
 
Last edited:
Back
Top