Best practices for terminal cursor control

datajerk

unread,

Jul 15, 2011, 1:05:20 PM7/15/11

to

In the Unix/Linux world we have ncurses as the way to manipulate the
cursor position and other terminal properties. I have been unable to
find something similar for CP/M. Is there such an abstraction layer?

Thanks.

Bruce Morgen

unread,

Jul 15, 2011, 1:41:48 PM7/15/11

to

datajerk <data...@gmail.com> wrote:

ZCPR3 and later includes
a 128 "TCAP" segment that
provides that in a
somewhat primitive manner
-- all the screen-
oriented Z-System tools
use it, and back in the
day I was even able to
patch WordStar 3.3 to be
be terminal independent
by some interpretation
code that hot-patched
the terminal-specific
area of WordStar
(normally altered
permanently by the
WINSTALL.COM utility) in
memory at runtime.

Mr Emmanuel Roche, France

unread,

Jul 15, 2011, 2:20:28 PM7/15/11

to

datajerk wrote:

Hum...

1) "Datajerk", I am afraid that I must tell you that I don't like your
nickname. I don't know why, people using e-mail have a strong tendency
to chose a totally stupid name. Me, after using 2 nicknames, I came to
"square one": using my real name. Since 98% of Americans don't know
how to spell my first name (as evidenced, once again, a few days ago,
by John Monahan), I am obliged to spell it in full. Since the Internet
is world-wide, I end by my country.

2) I hope that you will understand that I am getting tired of seeing
again and again the same (endless) discussions. However, you are a
Newbit in this group, so I must not treat you too harshly. So, below,
find something relevant for your question. As for references, please
do a search using this program name in the messages published over the
years in the comp.os.cpm Newsgroup. You might be surprised.

3) Over.

Yours Sincerely,
Mr. Emmanuel Roche, France

DM80.WS4 (= Display Manager-80 version 1.0 article)
--------

- "Display Manager from DRI"
Alan Simpson
"Microsystems", February 1984, p.96

(Retyped by Emmanuel ROCHE.)

Most professional programmers wince a bit when they hear the
term "I/O code." Not because writing code for data entry screens
and reports is difficult, but rather because it is a boring and
tedious task. Typically, the programmer designs displays on
graph paper, then laboriously writes line after line of code to
format displays on the screen and printer. The process becomes
even more unpleasant if the program is to be used with many
different terminals. The programmer then needs to take into
consideration the control codes for various CRTs. This is a very
time-consuming process, particularly if one plans on making
one's software compatible with 50 different terminals. Most
professional programmers get around some of the tedium by
writing general-purpose I/O routines, and storing displays and
terminal codes on data files.

Digital Research has come up with an even better method. You,
the programmer, buy Display Manager, then you "draw" your input
and output displays directly on the screen, exactly as you wish
them to appear at run-time. Display Manager then takes care of
writing the I/O functions, storing displays on a data file, and
providing control codes for a variety of terminals. Sounded good
to me, so I thought I would give it a try.

Display Manager (DM-80) is one of Digital Research
Incorporated's ("DRI") "Productivity Tools" (ROCHE> The other
one is "Access Manager", providing ISAM (Indexed Sequential
Access Method) to DRI's compiled languages.), and works with any
of their 8-bit programming languages (CB-80, Pascal/MT+, or
PL/1-80), and 16-bit languages, including Pascal/MT+86, CB-86,
PL/1-86, and DRC. Version 1.0 of DM-80, the one I used for this
review, supports 55 different terminals, and allows the
programmer to include extra terminals. Display Manager also
includes a program written in CB-80 (CBASIC Compiler Version 2)
that allows the end user to install the program to his
particular terminal. DM-80 requires that you use CP/M, CP/NET,
or MP/M, and have at least 40 Kilobytes available in the
Transient Program Area of your main memory. Display Manager will
also run under PC DOS with any of the DRI 16-bit programming
language.

Using Display Manager
---------------------

When I first received DM-80, I read the manual from cover to
cover. Like most software manuals, the DM-80 manual tends to be
more descriptive than tutorial. The first thought that came to
mind after reading the manual was "What?" The manual is about
100 pages in length, with the usual addenda that tell you what
the manual forgot to mention, as well as changes that have been
made since the printing of the manual (yes, even though this is
Version 1.0). At first, I was dubious as to whether or not this
product was truly going to help increase my productivity. Since
I have already developed a number of my own canned functions to
handle I/O screens, it seemed unlikely that learning this new
and seemingly complex tool would be worth the effort. When I
actually sat down and used DM-80, I found it much easier to use
than expected, and well worth learning.

Using DM-80 is essentially a 3-step process: 1) Install DM-80 to
your particular terminal; 2) Create and edit displays using the
DM-80 editor; and 3) Write the application programs that access
the displays. I will discuss my experiences with each step in
the process.

1. Installation
---------------

Installing DM-80 to your particular CRT is a simple process,
unless you happen to be using 5 1/4" disks. DM-80 is delivered
on two 8" disks, and one needs to do quite a bit of wading
through the manual to determine exactly which files must be
resident on disk during the various phases of designing screens.
I managed to get DM-80 up and running on a single-sided double-
density (180K) disk through a little trial and error. Once you
have the correct files on disk, the rest is easy. DM-80 is menu-
driven, and the program itself is somewhat tutorial.

If you are using one of the DM-80 supported terminals,
installing the program is as simple as selecting that terminal
from a menu of choices. Of the 55 terminals that DM-80 supports,
many are different models from the same manufacturer. For
purposes of brevity, I will just list the manufacturers here:

A.B.M.
A.D.D.S.
Apple
Beehive
Control Data
Cromemco
Digital Equipment Corporation (DEC)
Direct
Hazeltine
Heath
Hewlett-Packard
I.S.C.
Lear-Siegler
Microterm
Osborne
Radio Shack (Tandy)
Soroc
Teleray
Televideo
Toshiba
Vector Graphic
Visual Technology
Xerox
Zenith

If you are not using one of the supported terminals, you will
have to provide the control codes for a custom terminal. This is
not difficult, provided that the custom terminal has enough
documentation to supply the appropriate codes. The DM-80 manual
has a simple questionnaire to fill out about custom terminal
characteristics. Then, the install program asks the same
questions that the questionnaire did, and you fill in the
blanks. The installation program has a very convenient test
capability that allows you to check, to make sure you have
installed a custom terminal properly. It does so by trying each
function (clear screen, position cursor, reverse video, etc.) on
the screen, and asking if the function worked correctly. If you
discover a mistake during the test phase, you can edit the
terminal codes using a reinstall option. Once you have DM-80
installed for your system, you can begin creating displays.

2. Creating displays
--------------------

I never thought I would see the day I would actually enjoy
creating I/O screens. DM-80 changed that, by allowing me to draw
and edit displays on the screen in an interactive, visual
manner.

When you call up Display Manager's editor, it asks if you want
to edit an existing display, or create a new one. If you create
a new one, it must have a unique number, as this number is used
by the application program for finding the display. When you are
ready to create your display, the editor presents a blank screen
with the cursor in the upper left-hand corner, and you can just
start drawing your display on the screen as you wish it to
appear to the user at run-time.

The manual tends to make this process more difficult than it is.
There are well over 40 distinct control-key commands (some 3
characters long!) that the editor uses. Personally, my brain's
RAM space for storing control-key sequences is just about full,
but DRI was quite considerate in making memorization a bit
easier. For instance, many of the control-key sequences are
identical to those used in other software packages (^V toggles
insert mode, ^OC centers, while ^A, ^S, ^E, ^D, ^X, ^S, ^F move
the cursor about on the screen, etc.). DRI also provides
abbreviated reference cards, kindly laminated in clear plastic,
for quick reference. When you first start designing displays,
however, be prepared to do a good deal of wading through the
manual. Control-key definitions are interspersed throughout the
text, and the reference cards are too brief for first-time use.

When you are developing a display, you simply type out the
prompts, headings, and borders where you want them to appear on
the screen. You can also enter a control key command to specify
that either an input or output field be displayed. You can
easily move text and fields about the screen, as you zero in on
just the format you wish. You can also include template
characters in input fields, such as "(___) ___-____" for phone
numbers. Then, you can determine visual characteristics for the
various fields in a simple and pleasant manner. To do so, simply
position the cursor at the beginning of a field, and enter a
control key command to call up the status window. The following
then appears on the screen.

+----------------------------------------------------+
| Field No. Row Col Len Posts Type-OUTPUT |
| 000 000 000 000 YY *rr,cc*nnn |
+----------------------------------------------------+
| Validate :X: X,A,C,D,F,I,U Beep :N: N,Y |
| Format :L: L,R,N,0-9,C,M AutoRet :N: N,Y |
| |
| End input---Cursor :N: BadC :N: FKey :N: N,Y |
| Video :N: :N: :N: :N: :N: :N: :N: :N: N,Y |
| Invs Half Invr Flsh Undl Usr1 Usr2 Usr3 |
+----------------------------------------------------+

This window presents the DM-80 default characteristics for a
single input field on the screen display. You can use the
default characteristics for this field, or change them by simply
moving the cursor about the status window. Of course, you can
change default characteristics also.

The top line of the status window presents the field number
(automatically assigned as the display is being designed), the
row, column, and length of the field, whether or not it is
surrounded by blank spaces (posts), and the type of field (INPUT
or OUTPUT). The letters rr and cc are the row and column numbers
of the cursor's present position on the screen, and nnn is the
number of fields in the display.

The Validate prompt allows the programmer to provide error
checking with the simple press of a key. The options are X
(accepts any printable character), A (accepts only alpha
characters), C (all characters, including control characters), D
(decimal numbers only), F (allows Function keys only), I
(integer only), and U (same as X, but input is changed to
uppercase). Beep determines whether or not an illegal entry by
the user causes the terminal's bell to ring (Y/N).

Format for the fields can be L (left-justify), R (right-
justify), N (numeric output), 0-9 (number of digits to the left
of the decimal point), C (send control keys to the screen), and
M (money fields with leading dollar [or other currency] sign and
2 digits to the right of the decimal point).

The AutoRet option determines whether data entry terminates when
the field's capacity is full (Y/N). The End-Input options allow
the programmer to specify various methods for terminating data
entry. If cursor is selected (Y), then the terminal's up/down
arrow keys terminate data entry for the field. If BadC is Y, any
illegal character for the field terminates entry for that field.
FKey terminates entry if a Function key is entered.

The remaining options Invs, Half, Invr, Flsh, Undl, Usr1, Usr2,
Usr3 allow the programmer to specify visual attributes for a
field. By filling in a Y above an option, the programmer can
cause the field to be invisible, half intensity, inverse video,
underlined, or flashing. The programmer can also define up to 3
user-defined visual attributes, and include these in various
fields.

The whole procedure is simple and fast. You just draw the
display as you want it to appear to the end user at run-time,
then set the cursor to the beginning of each input and output
field, and use the status window to determine the basic
characteristics and visual attributes of the individual field.
Any programmer who has ever written I/O code to include as many
options as Display Manager provides will probably see that this
is a far quicker and easier method. I was certainly convinced.

As if this were not enough, Digital Research took it a step
further, and made Display Manager self-documenting. Once the
display is created, the programmer can store a print-image ASCII
file of the display on a disk file. This image file can be
pulled directly into most word-processing systems, to ease the
development of a user's manual. Also, the disk file contains
detailed documentation for each field in the display, which
helps with the technical documentation, as well as with
debugging and modification. The final step in the process is to
link your displays with your application program.

3. Write the application program
--------------------------------

Once the displays have been designed, you need to write the
actual programs that will use the displays. Display Manager adds
the following functions to the programmer's present language:

INITDM
Initializes the application program to use a specific terminal's
control codes and capabilities.

OPENDIS
Opens a DM-80 display file.

RETDM
Returns visual attributes supported by a given CRT, so the
programmer knows which of DM-80's options are readily available
for a particular CRT.

CLRSCR
Clear-the-screen command.

CURS
Set cursor to visible or invisible.

DISPD
Places a display from the display file onto the screen.

CLSDIS
Closes a display file.

For managing the actual fields in the display from the
application program, DM-80 provides the following functions:

POSF
Positions the cursor to a given field.

NXTF
Positions the cursor to the next field.

SETF
Modifies the visual attributes of a field during run-time.

RETF
Returns the field position, length, and type.

PUTF
Outputs data to the current field.

GETF
Accepts and validates data entered to a field by the end user.

UPDF
Updates and validates data entered for a field.

ENDF
Determines how user ends data entry.

RESF
Resumes operation at last field.

The syntax for using most of DM-80's functions (using CB-80 as
an example) is:

integer variable = FUNCTION (integer expression)

Since DM-80 uses functions rather than commands, it is the
programmer's responsibility to determine whether or not a
function is successful, and to return an error message
describing the problem to the user, should an error occur. This
adds a bit of bulk to an application program, but then again, it
does provide the programmer with some flexibility in handling
errors.

There are some minor annoying inconsistencies among the
functions that the programmer must deal with. For example, some
functions return a zero when the function is successful (Boolean
false?), and negative value when the function is unsuccessful
(Boolean true?). Some functions, like the CURS function, allow
various numeric arguments (e.g., 0-3), but the value must be
expressed as a string. Other functions do not use strings for
numeric arguments. Until you get used to the exact syntax of the
various functions, plan on doing a bit of debugging. You may
find some of the syntax awkward and counter-intuitive at first.

The final step is to write the program in the language of your
choice, and use the various DM-80 routines to access displays
and manage field data. In your source program, you need to
include DM-80's prewritten functions. For example, in CB-80, you
need to include the command:

%INCLUDE dm80extr.bas

Digital Research provides external functions for all the
supported languages. Then, when you link the compiled code, you
need to include the DM-80 relocatable library as an overlay. In
CB-80, the command to do so is:

A>LK80 testprog,dm80cb80.irl

Digital Research provides run-time libraries for each of the
supported languages. The manual provides sample programs written
in CB-80, Pascal/MT+, and PL/1-80 as useful examples of
programming techniques.

Incidentally, once the source code is written and is capable of
putting displays on screen, the end-user can use control keys or
arrow keys to move the cursor about on the screen. DM-80
defaults to both the ANSI standard keys for moving the cursor
about (^H, ^J, ^K, ^L), as well as the more popular ^S, ^X, ^E,
^D keys. The programmer needs not write any code to provide
these capabilities.

Mr Emmanuel Roche, France

unread,

Jul 17, 2011, 2:46:36 AM7/17/11

to

Hum...

2 days without reaction.

Some people must suffer from "Information Overload".

So, let us try to help them.

Let us do a Google search: (4680 "Display Manager").

The first 7 answers are relevant. 5 of them are PDF files.

The first PDF is titled "Display Manager User's Guide".

It seems relevant: let us click on it. The PDF file opens.

Page 14 of 90, we see: "December 1987".

A Google search tells us that, in 1986, IBM bought a version of
Concurrent DOS from Digital Research.

So, IBM reformatted the manuals, and this is what we are seeing. There
seems to be very little difference from the CP/M manual of 1983.

One thing to note is that the only Programming Language supported by
IBM is something called "IBM OS 4680/4690 BASIC". However, when you
run the compiler, it displays... the sign-on message of Digital
Research's CBASIC Compiler!

Apparently, IBM don't know what the initial "C" means, in CBASIC...

Let us continue searching. We arrive at a FAQ.

"The attachment contains a 4690 OS dictionary of file names,
extensions, and directories where files are located."

http://www-01.ibm.com/support/docview.wss?uid=pos1R1004280

Interesting. Let us search for "DM".

DMED.286
Display Manager editor for a monochrome monitor.

DMEDCOL.286
Display Manager editor for a color monitor.

DMEDHLP.OVR
Display Manager editor help overlay.

DMEDOVR.OVR
Display Manager editor overlay.

DMEXTR.J86
Display Manager for BASIC function definitions.

DMORDERS.DAT
Sample Display Manager screen file.

DMSAMPLE.286
Sample Display Manager program.

So, OS 4680/4690 uses 286 files, not CMD files.

Let us now make a search for 286 files distributed with it.

DREDIX.286
FDISK.286
FIND.286
FORMAT.286
LIB86.286
LINK86.286
MORE.286
PRINT.286
PRINTER.286
RENAME.286
RESTORE.286
TREE.286
TYPE.286

This is curious... Where have I already seen those programs' names?
Ha, yes! Digital Research's Concurrent DOS!

So, in 2011, a Digital Research Operating System, sold to IBM in 1986,
is still running! And they are still using CBASIC Compiler and Display
Manager!

By the way, since IBM is so big, did they made an official statement?

"Question: What support is provided for the tools used in the
development of 4690 Legacy applications?"

"Answer: IBM-Branded Tools --
4680 BASIC Compiler (BASIC.286, BASIC.EXE).
4690 Library Tool (LIB86.286, LIB86.EXE).
4690 Linker (LINK86.286, LINK86.EXE).
4690 Postlinker (POSTLINK.286, POSTLINK.EXE).
4690 Application Debugger 5799-RXD (DEBUG.286, DEBUGCDV.286,
DEBUGCDV.EXE).
4690 Display Manager (DMEDCOL.286)."

"The 286 versions of the tools listed above have been in use on
computers running IBM 4690 OS (4690) for many years and are stable on
that operating system platform."

"The EXE versions of the tools listed above have been in use on
computers running Microsoft Windows 2000 for many years and are stable
on that operating system platform. Most of the IBM-branded tools
listed above were modified in 2004 to fix known issues with Microsoft
Windows XP (...)"

"IBM has not tested these tools on a Microsoft Windows Vista platform,
or with any other operating system not specifically listed above. Do
not use Microsoft Windows Vista. (...)"

"IBM is unable to provide support for problems reported in tools that
do not have an IBM brand. One such tool is the Metaware C Compiler.
Please work directly with the company that sold you those tools."

Date: 6 December 2010

joe

unread,

Jul 17, 2011, 9:32:04 AM7/17/11

to

Mr Emmanuel Roche, France wrote:
> Hum...
>
> 2 days without reaction.
>

I won't make you wait 2 days for a reaction.

> So, in 2011, a Digital Research Operating System, sold to IBM in 1986,
> is still running! And they are still using CBASIC Compiler and Display
> Manager!
>

I'm not sure how you came to the conclusion they are still using this
SW. Any use of 20+ year old software would have to be minimal, if any. I
didn't see any statement supporting your conclusion.

> By the way, since IBM is so big, did they made an official statement?
>
> "Question: What support is provided for the tools used in the
> development of 4690 Legacy applications?"
>
> "Answer: IBM-Branded Tools --
> 4680 BASIC Compiler (BASIC.286, BASIC.EXE).
> 4690 Library Tool (LIB86.286, LIB86.EXE).
> 4690 Linker (LINK86.286, LINK86.EXE).
> 4690 Postlinker (POSTLINK.286, POSTLINK.EXE).
> 4690 Application Debugger 5799-RXD (DEBUG.286, DEBUGCDV.286,
> DEBUGCDV.EXE).
> 4690 Display Manager (DMEDCOL.286)."
>

You seem to have missed this statement.

"Most of the IBM-branded tools listed above were modified in 2004 to fix

known issues with Microsoft Windows XP (XP), but have not been tested or
used extensively on that operating system platform; there may be
additional problems found. "

Updates were made in 2004, but not extensively tested. This does not
lead one to believe it was used much at that time or since then.

You also seem to have missed this.

"IBM will not provide any fixes for problems reported with 4690 Display
Manager. Workarounds will be provided if they can be developed."

I would not expect to see that statement for a product you say "they are
still using".

So, while they was some maintenance in 2004, there is no evidence to say
that the 286 version of the software has seen any use since then.

I suspect the original poster was looking for something for CP/M 2.2 not
a 286 version.

Peter Dassow

unread,

Jul 17, 2011, 10:45:37 AM7/17/11

to

I fully agree with you, with ZCPR or Z-System the usage of a TCAP file
(loaded by ZCCP in Z-System) would be the answer - similar to ncurses in
Unix.
Unfortunately native CP/M 2.2 or CP/M 3.0 does not really provide a
generic approach for using terminal control sequences.
That's the obvious reason most of the popular CP/M applications provide
an own configuration program to "patch" the necessary terminal codes
into the program itself.

Usually any good CP/M programmer used a table with
placeholders/variables for the appropriate escape sequences.
So it was quite easy to adapt it to another terminal type.
Think about Wordstar or Turbo PASCAL, for me a typical example how it
was done.

Regards
Peter

Bruce Morgen

unread,

Jul 17, 2011, 3:55:10 PM7/17/11

to

Peter Dassow <z8...@arcor.de> wrote:

Now that the expertly coded
NZCOM (for CP/M 2.2) and Z3PLUS
(for CP/M 3.*) are available as
de facto freeware, the
advantages of the Z3 TCAP are
available to all. There's even
a subroutine library called
VLIB to facilitate writing
screen-oriented code in
assembler without having to
think about how to locate and
utilize the TCAP directly.

Henk Siewert

unread,

Jul 20, 2011, 8:25:16 AM7/20/11

to

Hallo datajerk, (Can you do something about that name? I thing you have a
more 'normal' name?)

Ok, I think you are looking for a way to control your screen and cursor in
your programs.
In another post you are referring to Z80mu.
So lets go from there.
If you start Z80mu, I am using Z80mu from XP, and hit the space button you
have a clean screen with prompt.
Type HELP, you get the help screen.
Look for SET_TERM.
Type this and hit the Return or Enter key.
You will see the options for the terminals you can use in Z80mu.
I use H19, but this is up to you.
You can type SET_TERM H19 from the Z80mu prompt to set the terminal
emulation to H19.
If you want to use H19 every time you start Z80mu put this line in the
AUTOEXEC.Z80 file.
Below is my AUTOEXEC.Z80 file. It sets the terminal to H19, sets the colors
to something useful and clears the screen.

;
; SWT AUTOEXEC.Z80 file.
;
set_bdos min
set_cpmecho off
set_cpmlist lpt1
set_cpmpun com1
set_cpmrdr com1
set_cpu z80
set_fake off
set_illop fault
set_iobase 400
set_mask on
set_source z80
set_term h19
set_vars on
set_colors 07 07 07 07
coldboot
CLS

If you want to use the H19 terminal emulation in your programs you have to
use the ESC-control codes.
Example in Microsoft BASIC-80 (I use the BASCOM compiler):
For setting the cursor to a specific location on the screen you first make a
function:
DEF FNC$(X,Y)=CHR$(27)+"Y"+CHR$(X+31)+CHR$(Y+31)
You can use this function by coding:
PRINT FNC$(15,40);
This sets the cursor to row 15 column 40.

If you want to clear the screen. you have to use:
PRINT CHR$(27);"E";
But there is a snake in the grass, as we say in The Netherlands.
After every CLS command MBASIC-80 go's to a new line. So you lose the first
row.
Better is to use an Assembler routine.

; H19.MAC******************************************************
;
; H19 screen commands
;
; Programmeur : Henk Siewert / SWT Software
; Datum : 30 juni 2011
; Programmanaam : H19.MAC
; Binair : H19.REL
; Versie : 1.00
; Besturingssys. : CP/M 2.2
; Taal : Microsoft Macro 80 assembler
; Compiler : Microsoft M80 version 3.44
; Compiler comm. : M80 =H19
; Linker : Do not link. Just make REL.
; Linker comm. : WARNING - NO ORG 100H
; Terminal : H19
;
; Compiled and tested with Z80mu emulator on Windows XP Pro SP3
;
; Web : http://www.swtrocketry.com
;
; *************************************************************
;
; Switch Assembler to Z80 mode
;
.Z80 ;(Beware of the . (dot) before Z80!)
;
; -------------------------------------------------------------------
; Set BDOS entry point
;
BDOS EQU 05H
;
; -------------------------------------------------------------------
; Set CP/M functions
;
PRTCHR EQU 02H
;
; -------------------------------------------------------------------
; Declare
;
ESC EQU 1BH
;
; -------------------------------------------------------------------
; Clear Screen
;
CLS:: ; (Beware CLS:: TWO : for making global entry point!)
LD E,ESC
LD C,PRTCHR
CALL BDOS
LD E,'E'
LD C,PRTCHR
CALL BDOS
RET
;
; -------------------------------------------------------------------
; End program
;
END

Compile this code with M80 and use the REL file to link with you code.

In BASIC-80 I use:
CALL CLS
to clear the screen.

I use this submit file to compile and link:
BASCOM =$1/Z/O/C
L80.com $1/E,H19,$1/N

To start this you type from the Z80mu prompt:
SUBMIT C MYCODE

C is the name of the submit file (I do not use the .sub extention!)
Replace MYCODE with the name of your file.

Is is handy to have the H19 ESC codes handy.
Some Googling can help...
I am using the tables in the KERMIT book for reference.
If you cannot find the H19 ESC codes I can scan them for you, just let me
know.

I hope this will help you on your way to using screen and cursor control in
you programs.
Questions? Just ask, That's what we are here for...

Gretings from The Netherlands,
Henk Siewert

"datajerk" <data...@gmail.com> schreef in bericht
news:3cbdf9bb-1e1e-4a70...@x19g2000prc.googlegroups.com...

datajerk

unread,

Jul 25, 2011, 10:55:14 AM7/25/11

to

On Jul 15, 12:20 pm, "Mr Emmanuel Roche, France"

> | Invs Half...
>
> read more »

1. Irrelevant, however your objection is noted.

2. I did search. Being new to CP/M perhaps I did not use the correct
search terms nor I did not find what I was looking for, so I asked. I
also purchased and read two CP/M books before posting. Lastly, if you
are "getting tired of seeing again and again the same (endless)
discussions", well then, ignore them. I would think that a newsgroup
with such low frequency would welcome any chance to help a "newbit" or
n00b. BTW, "endless" discussions are not always the same, and they
can at times reveal something new or an opinion by someone that did
not participate to begin with.

That all said, thank you very much for the information you presented,
as well as the others, this is precisely what I was looking for.

Thanks again.

datajerk

unread,

Jul 25, 2011, 11:00:28 AM7/25/11

to

Correct. I should have been more clear in my original post. CP/M 2.2
and Z80.

datajerk

unread,

Jul 25, 2011, 10:59:28 AM7/25/11

to

On Jul 17, 12:46 am, "Mr Emmanuel Roche, France"

"2 days without reaction."

1. I wanted time to collect as much feedback as possible and to
actually test a few things before replying.

2. Personal and professional obligations trump my retro hobbyist
activities.

3. Please do not take offense at my tardy reply. Time is a finite
resource.

Egan Ford

unread,

Jul 25, 2011, 12:30:16 PM7/25/11

to

On Jul 20, 6:25 am, "Henk Siewert" <s...@tiscali.nl> wrote:
> Hallo datajerk, (Can you do something about that name? I thing you have a
> more 'normal' name?)

Hello Henk,

Exactly what is 'normal' these days? :-)

data...@gmail.com is just an email address.

I think I understand your confusion as well as Emmanuel's. All of my
Google app (mail, calendar, Google+, etc...) accounts use
data...@gmail.com with a display name of "Egan Ford" except this
one. It took me awhile to find the setting (Edit my subscription, BTW
"preferences" did have it right), apparently it defaulted to my Google
account (login) name. After years of using Google for netnews, nobody
has objected to me using just my email address to post. I honestly do
not understand why any of this really matters.

I hope everybody is happy now.