Subject: Re: retry -- my RX01 now works

From: Ronald Copley <[email-masked]>
Date: Thu, 10 Nov 1994 12:03:03 -0400 (EDT)

On Wed, 9 Nov 1994, Douglas W. Jones wrote:

> Anyone who wants a copy of my emulator is welcome to take one from
> ftp.cs.uiowa.edu:/pub/jones/pdp8/  (get README first to see what's there).
> 

And it works fine. Linux definately needs a -DTERMIOS, a link to the bsd 
library and a change to #include <bsd/sgtty.h> in ttyaccess.c

I need some c source for Mr. Lasner's ENCODE programme, so that I can 
undo some binaries to run underneath the PDP-8 emulator. Help?

--
Informatiks                       |
Ronald Copley, owner              |  Buying and selling small to medium
1010 Township RD 78W              |  quantities of used Pyramid, Sun, 
Scottown OH  45678-9051           |  DEC (PDPs) and Data General computer
+1.614.643.1340                   |  equipment.
(evenings, please)                |
--

---

From: Charles Lasner <[email-masked]>
Date: Fri, 11 Nov 1994 21:20:23 -0500 (EST)

> undo some binaries to run underneath the PDP-8 emulator. Help?

It's only been done in PDP-8 assembler.  Sources are available in the 
Kermit-12 collection.  However, there is also a .doc file available on 
the file format in the same collection, available at finer PDP-8 archives 
everywhere, as well as everywhere Kermit isn't sold, but rather given 
away for free!

Please note also, that there is another format supported in the same 
collection, known as .IPL format.  This is actually a variant on binary 
paper-tape, but with a different agenda:

Basically, the format is printable characters with all white space, CR, 
LF, etc. ignored.  The printable characters form loadable PDP-8 
half-words (six-bit bytes) with an implied loading address of 0000 ending 
with a trailer.

Leader can contain lower-case letters for commenting on the contents of 
the file.  Any essentially lower-case character also ends the file, thus 
the trailer is practically any free-form input you want, etc.

The purpose is to allow a minimal loader almost as primitive as the 
original .RIM loader to be used for moving paper-tape binaries around, 
but allowing the file to be stored as a text file in most file systems, etc.

You must supply the loading field, as well as the designated program to 
accomplish the loading.

Kermit-12 includes two example files, one runs in field 1 to load field 
0, the other runs in field 0 to load field 1.  This allows each to load 
an unrestricted amount of binary up to an entire field.

Note that a shorter load could allow the loader to reside in the same 
field as the loaded data, or alternatively, the loaded program could be 
designed to interact with the loader itself!  There are versions of BASIC 
that assume they are being loaded by the standard .BIN loader, and they 
overlay the loader itself to make the attempt at loading become a 
self-starting operation.  Something similar could be contrived for the 
.IPL loading operation, etc.

In the specific case of Kermit-12, the image of Kermit-12 Version 10g is 
split into two .IPL files, one being the image of field 0, the other 
field 1.  The two .IPL loaders are used to load the files into memory 
directly, then exit back to the OS/8 monitor allowing .SAVE commands to 
be executed to save the memory image, etc.  Later, PIP commands can be 
used to combine the "halves" of the program to form a provisional copy of 
Kermit-12, which can then be used for a more "trustworthy" download of 
files, etc.

Note that .IPL loading assumes an error-free connection to another serial 
device, but doesn't require a start/stop protocol such as ^S/^Q because 
loading is direct to memory only, etc.  This allows connections such as 
connecting a DECmate printer port to a PC com1: port.  Using an MS-DOS 
COPY filename COM1: or similar command allows for an error-free load of a 
program segment, thus quickly allowing Kermit-12 to become available 
where no other comm program yet exists, etc.  (This method has been 
successfully used in several sites to acquire Kermit-12, etc.)

The only known problem with .IPL loading as the ability to load 
inadvertently into the wrong field.  Kermit-12's parts are 
field-specific, but files such as FOCAL, 1969 can be loaded into any 
field, as long as the DF and IF are both started as the loading field, etc.

.IPL utilities and ENCODE/DECODE utilities should be made available for 
as many machines as possible, etc.

In the meantime, OS/8 ENBOO and DEBOO handle the Kermit-popular .BOO 
format that is often used to distribute MS-DOS-type binaries, etc.  Using 
.BOO format, TECO macroes can be exchanged between OS/8 and MS-DOS!

Thus, using .BOO format as an intermediary, it is possible to move any 
arbitrary file format, as long as the transmission path is good enough to 
not mangle .BOO format, which is not known for being particularly robust, 
etc.  (Basically as lame as uuencode, only with compression, but no 
checksum.)

The best format is ENCODE with its extra-long checksums, white-space 
ignoring, compression, embedded comment capability including OS/8 and 
file creation date information, 5-bit character encoding for maximum 
robustness even through EBCDIC systems, etc.  ENCODE will even survive 
being sent as a WPS document with DX!  Thus, we welcome any 
implementations of these formats on other systems, etc.

cjl

---

From: "Douglas W. Jones" <[email-masked]>
Date: Wed, 9 Nov 94 11:50:43 CST

I don't know if my last note got through (it never came back to me),
but my PDP-8 emulator now boots OS/8 from the RX01 diskette images
John Wilson sent me.  Both were bootable OS/8 Version 3Q disks, and
between them, they include quite a bit.  I haven't tried it all, but
I see BASIC, PAL8, SABR, TECO, EDIT, RALF, and F4, as well as the
usual utilities such as BUILD, BOOT, PIP, ETC.  It took me a moment
to figure out that PIP had been split, so that the directory listing
functions were moved to DIRECT, while the peripheral interchange
functions were in PIP.

				Doug Jones
				[email-masked]

---

From: Charles Lasner <[email-masked]>
Date: Fri, 25 Nov 1994 11:40:22 -0500 (EST)

> functions were moved to DIRECT, while the peripheral interchange

Yes, when DIRECT was written, they removed (hastily!) the /E, /F, /L code 
and replaced it with a stub that just prints out "USE DIRECT" instead :-(.
Additionally, PIP can't handle any wildcard filenames, thus FOTP was 
additionally created.

Additionally unfortunately, this created a debacle:

The original PIP supported the /E (Extended), /F (Fast), and /L 
(directory Listing normal) options up until the date extensions (which 
btw run out as currently defined in 2001!) were added which required 
additional code to support the 8-year group bits, etc.  Management felt 
that the additional work was too much, etc. and the DIRECT program was 
created to deal with an acceptable variation of the directory listing option.

However, many users felt cheated due to the overhead in switching 
programs, since you often want a quick directory listing to help 
formulate a PIP command to accomplish some utility file transfer, etc.

At the same time as this, DEC's released copy of PIP not only deleted the 
support of /E, /F, /L, but there was also an inadvertant serious bug 
regarding the /Y switch to copy images of system heads, etc.

A user (can anyone name this person?) created a set of fixes for the 
*entire* situation:

1)	Fixed the /Y bug.

2)	Restored the /E, /F, /L switches with complete support for the 
	date year group bits through 1999.  (Note: there are a whole lot
	of OS/8 bugs waiting to happen whereby the routines cannot handle
	past 1999 even though the date format itself runs out at the end
	of 2001, etc.)
	
3)	Added a new /N switch that changes the behavior of the /E, /F, /L
	switches so that the output conforms to the so-called "New" date
	format.  (The old format was such as 11/25/94 while the new format
	is 25-NOV-94.)

It would have been very nice if this version of the fix to PIP were 
distributed.  However, instead of this, the user contacted DEC's PDP-8 
programming manager and received the following misinformation:

The manager informed the user that DEC had "other ideas" about how to fix 
the /Y bug, and that they were "reserving" the space taken up by the (now 
former) /E, /F, /L code.  Thus, what DEC wanted to happen was that this 
code only be distributed unofficially.

This might have been fine, but an additional problem occurred.  DEC 
supplied the user with alternate code claiming to fix the /Y bug.  In 
point of fact, the user's code had fixed the bug while the new 
DEC-supplied code was buggy itself!

Still circulating around the PDP-8 world is a file usually known as 
PIPEFL which is named after the PIP /E, /F, /L switches that it restores 
(as it also addes /N).  This file contains DEC's incorrect fix to the /Y 
problem.

Thus, there are three options:

1)	Use the old PIP with the /Y bug.

2)	Use the old PIP patched with PIPEFL and you get the date 
	enhancements complete with the /N switch and you still have the /Y
	bug. 

3)	Use the new PIP where /E, /F, /L are non-functional thus 
	requiring using DIRECT where needed.  The /Y code is functional in
	all versions since the removal of /E, /F, /L (in all official
	release versions). 

The /Y bug is rather serious:

Attempts to involve handlers other than SYS: in the use of the /Y switch 
will certainly fail.  Depending on whether the code is the original PIP 
or the DEC-patched version (as in PIPEFL) changes the severity of the 
"penalty" for using the flawed code (which could including destruction of 
part of the system!).

So, as a result of all of this, there is no single program that can be 
used as PIP ought to be :-(.

As an aside (and a suggestion towards improvement), please note that 
there is a program on TOPS10 called PIP1K.  It essentially is a vital 
subset of the PDP-10 PIP program that runs in a minimal space to 
accomplish most of the common options of PIP on that system.  When an 
option is invoked that cannot be handled, the full PIP is chained to for 
the execution of that function alone, and then PIP1K is restarted for 
further input, etc.

Using the TOPS-10 notion, a core PIP program can be created that runs in 
8K to handle as many options as can be reasonably handled.  For 
additional functions, PIP could have an overlay section.  Refinements 
could include detection of 12K or 16K leading to loading in the full 
program initially to avoid swapping, etc.

More recently, PIP has undergone additional degradation in OS/278.  It 
now requires 12K to load in all of the kludges that unnecessarily were 
added to accomplish a half-baked "solution" to parts of the DECmate 
"problem".  In point of fact, all of this code could be eliminated.  If 
any of it wants to be preserved, it could be called in as a (possibly 
DECmate-specific) overlay, etc.

DIRECT was created because the person assigned to add in the directory 
listing options of PIP to do a good enough job wasn't interested in 
plowing through the code.  (Note: PIP isn't really well-written!  There 
is a whole lot of room for improvement!)

FOTP is an additional program created as an additional kludge (I know the 
author of these two personally!) because there wasn't enough room in 
DIRECT to handle both jobs in the same 8K image.)

By applying some proper rewrite effort, one program can obsolete all 
three of these less-than-perfect programs (as it should have been 
accomplished originally!) and CCL pointers to the programs redirected to 
PIP, etc.

Another quirk of PIP is that some versions support a quirky conversion in 
ASCII text mode:

When a file is copied in ASCII mode, one would conclude that the contents 
are merely copied.  However, in some versions, horizontal tab handling 
causes the strange circumstance of including a rubout character after the 
tab!

This was done due to interference from an ignorant manager.  At the time, 
model 35 teletypes were the typical console device on PDP-8's within DEC's 
development areas.  Model 35 teletypes do require special tab handling, 
but *not* the inclusion of a rubout character!

The *correct* way to handle tabs on a model 35 teletype (as is done in 
TOPS-10) is as follows:

1)	We assume the physical stops have been setup every 8 positions.

2)	Calculate the difference between the current carriage position 
	and the final position after the tab.  Divide by 4 yielding a
	result of 0, 1, 2.  This is the count of how many non-printing
	characters need be outputted after the horizontal tab before
	attempting a printing character.  Thus print this count of nulls
	or rubouts etc. 

Note that while blindly outputting one rubout does sometimes help, at other 
times it represents a waste of time, and in still other cases it's not 
enough time!  Clearly inserting the character into the file itself is not 
the correct thing to do!  Additionally, it causes file handling to take 
longer and wastes disk space, etc.

PIP has long been a "sore point" of OS/8.  It's about time we cleaned a 
lot of its problems up.

cjl