Polymorphics 88 work of Dwight Elvey

Copyright (c) 2011 Herb Johnson all rights reserved. last edit June 18 2011, update Oct 3 2016.

Introduction by Herb Johnson

I acquired my Polymorphic 88 system from David Director in May 2011. Here's a Web page about his history, and his history with the Poly 88. I got it just in time to take it to the Vintage Computer Festival - East 7.0, where it was examined and compared to Bill Degnan's Poly 88 system.

That Web page was found by Dwight Elvey, who used his restored Poly 88 system and PC software to recover Poly tape files. Dwight contacted me and also Bill Degnan. My discussions with Dwight and Bill about Dwight's work are on this page. Dwight's ZIP file of his files and programs are linked here, and there's discussion below about them. Here's a directory listing of the ZIP file. Here's a list of my (herb's) tapes.

As Dwight told me: "As in the past, what ever information or data that I give you, you may do with as you please. You may pass it on to other at a fee or free. I offer you the contents on my collection in the hopes that it will be spread to others by what ever means you wish."

In Oct 2016, another Poly 88 owner Piero Todorovich contacted me, to describe some errors Piero found in Dwight's archive. See the details below.

As I work on restoring this system, I'll show the work on this linked Web page. Look there for details and further Web links to other S-100 systems and other vintage restorations. - Herb

Why is this cassette-based mass storage of interest today?

There was a lot of effort in the mid-1970's to use digital logic and software for mass storage, in the absence of cheap commercial mass storage - until both floppy drives and floppy chip LSI parts made the task simpler and standardized. It won't be long before floppy drives and diskettes will become "lost art".....I've preserved what I can about that. In this page, Dwight et al discuss the Polymorphic 88 and its cassette tape mass storage schemes. - Herb JOhnson

Discussions with Dwight Elvey

tape formats, handling

Herb Said: My plan was to record the [Poly 88] tapes as MPEG audio files,
so I don't have to
play the tapes more than a few times. Dwight, do you have any procedures
to play the tapes and record the audio? 

Dwight said: The tapes come in two forms. One is the more standard
Byte Format. This is the well known two tone recording.
For these, I believe you'll have no issue recording as MPEGs.
This has been proved on other Byte format machines with
similar and simpler frequency shift decoders.
 
The other form is what is called PolyPhase. This is a simple
cycle by cycle phase reversal. The detection method is
quite sensitive and requires good to excelant fidelity.
MPEG is a lossy format an may not meet the phase accuracy
needed to record these tapes.

As for which tapes are poly vrs. Byte format, a quick listen
on a play will tell. The bocks of the poly data are only about
one second and the Byte blocks are quite a bit longer.

The PolyPhase is even sensitive to the polarity of the signal
from the recorder ( I have a switch on mine to deal with this
as some tapes are recorded on different recorders ).
 I have not experimented with MPEG on the PolyPhase but
knowing the method used, I don't have much hope for it
being used for these tapes.

This is why I felt it was important to preserve the data in
a binary format. It also allows one to directly analyze the
code or data as well, outside of requiring a Poly88 to
run it.

Dwight later added:
 
Before trying to read the tapes, do a little preconditioning.
I recommend hand winding them from one end to make sure
there are no stuck layers. Also watch for folded tapes. Don't
give up on these, just yet. I have been able to recover tapes
like these quite often. Some of the ones in my library were
recovered from damaged tapes.
 
Once you've manually run them once, run them through
the play once and then let them sit for about 1 week.
This will smooth out any edge creases caused by fast
rewinding.

Bill Degnan added:

I am an experienced studio musician I have access to equipment
for precision adjustment if need be. I will be able to make a copy
of a demo tape(s) if you (Herb) want me to do this. 

I'll lend Bill one of the old copied Poly tapes I have. 
Later he can look at original Poly tapes. It'll be interesting to see the results. - Herb

Poly hardware

Dwight discussed operation of the boards and the system:

 There is something ese I forgot to mention. The Poly88 processor
board will not work, without some modifications, with DRAM.
The processor board was designed before the S100 specs were
tightened down. I'm relatively sure there is something in the manual
showing how to patch it for DRAM boards.
 I use a DRAM my self for my first machine. I've configured
it for 48K starting at 2000H.

Most 16K boards will not easily configure to 2000H as a starting
address without modifications or lossing the first 2000H space,
shadowed by the processor boards ROMs and RAM.

Most all of the code that I have images for requires at least 16K.
Still, it is best to get the system up and running first with just
the processor and video board only.  The processor board has a 
small chunk of RAM that the monitor
uses for stack and storage. Getting it working alone with the
video board is important. Once at that level, expanding to the main system RAM will be
much easier.

 The processor board should have ROM version 4.0 for the code that I
have. It may work with other revs but I've never tested it.
 The monitor uses just one single 2708. For the power of the monitor,
I've always considered it quite compact. It the zip file I'm sending,
there is a hex dump of the monitor.

 The other two 2708 slots can be used for other things. I have a
Palo Alto Tiny BASIC that runs in these two slots. It also expects
RAM starting at 2000H. There is a dump of that as well.

 Once you have a system up and running with RAM, cassette interface
and poly serial type interface, you can start transferring the images
I have onto tape or as Herb is interested in MPEGs.

Dwight said:
I noticed that neither of Herb's or Bill's machines have serial [interface] cards. The
board is trivial and can be easily created. One can even modify it with
things like the MAXIM chips.

It looks like Bill's CPU board is just missing the CPU. The two sockets
are for cassette and serial are in the corner.

Building a RS232 interface is easy. It wouldn't take much to modify the
Monitor ROM to think it was loading from tape while really loading from the RS232.
The images might have to be modified to have check sums or a program written
to add them on the fly. Of course, on could modify the monitor to ignore the check sum
as well.

Bill doesn't have the cassette board. Those as I mentioned are a little
tougher. There is one part that might be hard to find, [it's obsolete].

 Have you gotten something to replace the character ROM? I can do a dump of
mine that could be put on a regular EPROM. You could then make up an adapter.
[I told Dwight I have a 5V version of that character ROM for Bill, but I'd also like
that dump too. - Herb]

Dwight's tapes, my tapes

Dwight sent me his Poly files by email; I later sent him a list of the tapes I have. A list of my tapes and manuals is on my "restoration" Web page. Dwight's ZIP file is linked here. Dwight's discussion is below. Here's a directory listing file of the ZIP file. Here's a list of my (herb's) tapes. - Herb

I am attaching my files as a zip file. Please let me know if it gets
through to you. Some mail tools are fussy about zip files.
 I suspect that when you get ready to use these, you'll have questions.

I should also note that the img files I have of the tapes are the
same format as would be on the tapes, but without sync bits and
check sums. This is so one can read them if they like. Also,
one may want to modify auto start records at the ends of the
tape images. A binary editor can do this.

The SMD image is the same binary as the dump program listing in the manuals.

I find that once I have something I've saved onto a tape,
I use TPERR to make copies and to allow me to edit things
with the Poly88 monitor.

All of the *.PRN files are for the 8080 although, I may have
changed the image name. Originally I had names the same
for the DOS end and the Poly88 end. This became confusing
as are some of the names. These were generated on my
IMSAI using the CP/M 2.2 assembler.

The DOS programs POLYUP.COM and POLYWR.COM, are used on the 
PC end to handle the image transfers. - Dwight

Dwight's tapes vs Herb's tapes

 I believe the version of BASIC I have is the same as yours. It
shows BASIC, BPRINT 16K and rev A00.  I also have another tape
with just BASIC 16K and rev 9V27. I've not explored it to see what is different.
There was another smaller memory model BASIC. I forget
if it was 8K or 12K but 12K seems to stick out in my mind.
I don't have a copy of the smaller one, I just know it
existed.

It looks like the games are repeats of what I have, except
MCHESS. I don't have that. The Chase, VIDP and STARS look interesting.

 I'm not sure what the monitor source files are. The source
for the 4.0 is in the manual. It might be intersting to see
what the 3 differed from the 4.

 I don't have DISASMV1. It might be something that was provided
by Polymophic of something that the previous person wote.
On one of my tapes there is a disassembler that I wrote. It
was real simple and was intended to be connected to a serial
printer and just printed the instruction and any address/data.
 
I forget if the Poly88 saved BASIC tapes with it byte-coded
or the commands spelled out. It seems like I recall it was
byte-coded to compact the source.

Dwight

Dwight's MS-DOS support software

HErb said: OK, the MS-DOS programs are POLYUP.COM and POLYWR.COM.
 I also see you have two files POLYUP.SEQ and POLYWR.SEQ. These look like FORTH. So I'm
guessing you wrote POLYUP and POLYWR in FORTH, these are the sources,
and the .COM are "compiled" versions. So what version of FORTH were you
running under MSDOS for these programs? OR....are these are FORTH
programs used by the .COM programs of the same name?
 
Dwight replies: Yes, the programs were written in Forth using FPC. I test and debug
at the FPC level to get the bugs out. I then use a program ( also written
in FPC by Tom Zimmer ) called TCOM. It creates small .COM files
from the code written for FPC. It usually needs minor modifications to
deal with things like command lines and such.

The source files are the *.SEQ files. For someone that reads Forth, they
should be easily converted to something like C or such.

Herb: Let's see...you have a text file POLYUP.TXT. It's informative but not
completely clear. I'm guessing that the serial port on the Poly 88 is
connected to a serial port on the MS-DOS PC. (probably COM 1?).
 
Dwight: I'm relatively sure one can select the COM port from the command line.
Run the command without parameters and it should give a command line
help.

Herb:  Then you run some programs on the Poly 88 through its keyboard and video
display to command the Poly ROM monitor. At some point, you run
"POLYUP.COM" or "POLYWR.COM" on the PC side to upload (save) or download
(write) your .IMG files to/from the PC side, through of course the
serial link. YOur POLYUP.TXT describes the sequence of what to run when,
between the Poly 88 and the PC.
 
 Yes, that is it. The images are first loaded into RAM with all the tape header.
At this point, they are not ready to save to tape. One needs to use a program
that will properly write the headers and blocks in the format that the monitor
will be able to read. As I recall, TPERR has a part that reads the serial data
into RAM and then there is an entry point to cause TPERR to write the data
back onto a tape.

 TPERR is what I used to rebuild tapes that don't read well and have a few
bits lost. Unlike the monitor, it can read as best it can and still read the
data. Most times only one or two bits are missing so one needs to partition
the bytes after the error and then use the checksum to fix the error.
In more complicated errors on has to look at the context of the errors.

 It is all a little more complicated than I could easily write up how to do each
step. Still, TPERR is useful to copy tapes or in the case of the serial down
loading to write the information, downloaded to RAM, onto RAM.

 The part of the code that does that down loading can be boot strapped
by the hex code at the end of one of the *.txt file ( I'll have to look ).
One you have that in the RAM, I recommend that one download TPERR next
as it also has this piece of code as well as the rest.

(Dwight later said: "My code requires there to be more real RAM starting at 2000H.")

There is something here that doesn't make sense in my head. I'll have to
go back and look at things. I know I bootstrapped things once but I think
I'm missing a step.  Wait until I have time to look at my notes...... 

I was also looking at POLYUP.TXT. It is a confusing document
and most likely should be rewritten.  It is still useable but there
is soem confusing info in themiddle about POLYWR operations.
[Meanwhile,] here is a document "TAPEIMAGES.TXT" that I hope will tie
things together. I hope
it will clerify things for handling the various part of the process. 

Later....I modified several of the text files. I've not actually
run through the procedures to see if things work as expected.
 Still, I think things should be clearer than what I had written.
I'd written those files about 15 or so years ago. Please replace the files
with these new ones. [POLYWR.TXT, TAPEIMAGES.TXT and POLYUP.TXT] - Dwight

Herb says: OK, it looks like a good start. Neither Bill nor I will
 be running our machines immediately, so there's time to refine this.
 Thanks for making this effort quickly. [Dwight also provided additional
files for TBASIC and TPERR. All are added to my verson of his ZIP file. - Herb]

ROM monitor

Herb: 
I think this accounts for all the transfer-related files in the ZIP. To
understand the POLYWR and POLYUP I'll have to know how to operate the
Poly 88 and its ROM monitor, and of course read the Poly 88 docs in more
detail. That's fair.
 
Dwight: 

Yes, read up on the monitor. Also try to write and read some files. You'll
need to maually enter SMD ( in the manual ) to write files. The monitor
just didn't have room enough to handle both read and write while also
giving the nice screen monitor. SMD fits in the RAM on the processor board
so for this level, you can run with just the CPU card and the video monitor.

[By the way] my code requires there to be more real RAM starting at 2000H.
 
[Also see Dwight's hareware comments, about modifying the ROM monitor
while building a serial interface. - Herb]

Errors in Polymorphic files found by Piero Todorovich

In Oct 2016, another Poly 88 owner Piero Todorovich contacted me, to describe some errors Piero found in Dwight's archive. - Herb

Oct 2016: Hi Herb how are you? I made a lot of progress with my Poly88 thanks to you. The restoring project is going foward and I was able to show a working Poly 88 in a retrocomputing event in Italy. I was able to load machine code and the Basic interpreter from my Teensy++ (Arduino) keyboard interface.

Investigating a secondary problem (a strange scroll behaviour) I found two errors in the file POLYMON4.HEX (Monitor 4.0 hex dump) inside the POLYTAPE.ZIP archive. I found errors checking the code with the printed listing in the Poly 88 Software Guide.

I suspect also some problems in the Tiny Basic dumps in the same archive POLYTAPE.ZIP (I was unable to run the interpreter after burning the two Eprom) but I cannot do any check without printed code.

I think my experience may help someone. I send you in attach a rtf file POLYMON4.HEX with colored errors (also the final checksum need to be correct). Probably I will be able to send you soon the new checked HEX file from my EPROM reader. - Best Regards, Piero Todorovich

Corrections to POLYMON4.HEX are below. I computed the checksum with an assembler. - Herb

:1000C0002A1E0C7C95542E401E004D47CD00010B7E  (0B at 00CF)=2B, new checksum is 5E
                                       ^^ 
:10032000C013030DC21E032A670C3A660C4F3A69CC  (03 at 0322)=23, new checksum is AC 
             ^^