• Please review our updated Terms and Rules here

POLY-88 emulator now available (Intel 8080 based system from 1976)

V

voidstar78

Veteran Member
Joined
May 25, 2021
Messages
1,048
Location
Texas
Over this past summer, I got in contact with Bob Bybee. He is an original owner of a POLY-8813 system and highly engaged and active in the heyday of that system between 1976 and 1980. About two years ago I obtained a POLY-88 from another original owner, who passed on to me a massive collection of tapes, documents, and an "almost" working system. That system has now been restored and I'll post more information about that at some point in 2026 (it was not something I could do alone and I'm extremely grateful to several folks who helped along the way).

I promised Bob Bybee to help maintain a github repository of his POLY-88 related emulator work and image collection (which he re-opened his code again in 2025 to ensure the -88 argument enables solid POLY-88 support). That collection is now available here:

github.com

GitHub - voidstar78/POLY88_RESOURCE: Repository of PolyMorphic Systems POLY-88 related resources

Repository of PolyMorphic Systems POLY-88 related resources - voidstar78/POLY88_RESOURCE
github.com github.com


And I've prepared an initial "release" of his emulator (as a pre-compiled product and a few associated samples). That's in the "release" link on the right side in github. But savvy folks here may be interested in the Intel 8080 core emulator (all written in Borland C of around 1992 - I verified this code compiles on my 386; but presently there is no other more modern build of this code or any fancier front-end than what is available in MS-DOS).

I had hoped to have this prepared before Christmas 2025, but alas am a few days late. And I'm also still on travel - so I plan to refine and double check all this on my return, and prepare more examples and scripts of how to use the emulator (perhaps even a video). For now, the BYBEE folder in the link above has all the as-provided content.

But I am interested in contacting others who recall anything about the POLY-88 system and their recollections. I have another contact in Illinois that also has quite a collection of material, and between both of us I think we have most of the highlights of the system covered. But I'm also interested in stories from contemporary users of this system, what appealed to them, what workarounds they did for the poor case design (that caused it to be prone to overheating), etc.
 
Last edited:
Great work! Also glad to hear about more Polymorphic users out there. I have a Poly-88 as well as several Poly-8813s and 8810s.

Another hobbyist recently found a version of FDOS by iCOM for the Poly-88 using iCOM’s micro-floppy controller. In the end that version had been modified for a different computer, so it didn’t run on the Poly-88 as is, but I’ve since updated it to run on the Altair 8800 (the original target machine for FDOS) and will soon make it run on the Poly-88 as it was intended.

Mike D
 
Note, there is a POLY-88 listed in the MAME emulator - but I don't think it works. IIRC, it didn't seem like it was updated in over a decade. In any case, it is very much a different lineage of code than Bob Bybee's (which his is setup to read cassette and disk images, but I haven't yet tried creating or writing to disk images).

Also, aside from just the emulator, there is a MANUALS sub-folder that may have some PDFs of interest.
 
I'm very happy to hear that Bob was willing to share the code - I contacted him 7 years or so ago, and he seemed quite busy, and unable to talk about the emulator much.

I've also written a Poly-88 emulator in C++ - the repo is at https://github.com/powool/poly88_emulator - if you try it, please understand I wrote it starting almost 30 years ago while trying to learn C++. Now closer to retirement, so I'm re-working it using more modern coding patterns. I do all my development on Linux, but I do have interest in keeping it multi-platform.

I don't really view speed of these as an issue, but rather the user interface - Bob's uses DOS (runs well on Linux dosbox), mine is currently built using SDL as the primary window rendering for the display, but has no UI elements.

Because SDL is not really intended for general purpose UI's, I have re-written my emulator to use QT6. I'll push those commits as soon as I can.

My introduction to the Poly-88 started when my Dad bought one in early 1976, and I helped him build it - I then proceeded to learn nearly everything I know about computers from that little toaster. I still have three Poly-88's and one 8813 in storage.

Poor case design? The first round was to mount a cooling fan to the top rear of the orange case. Later, we moved all the boards to a custom built S-100 chassis with a gigantic power supply!
 
Fantastic! Bob focused mostly on 8813 emulation, but the -88 command line argument he added for POLY88 support seems to work well. I've read through many of the PolyLetter articles, seems there was a lot of love for these systems for over a decade.

QT6 sounds good. There is a nice HP9830 emulator with actual machine images, so it "looks" real - not sure what GUI libraries it is using. And MAME itself has provisions for "realistic looking" machine frontends (and it's now supporting more than just legacy arcade systems). A 64-bit build of a POLY88 emulator would be handy - I've not yet tried cross-compiling Bob's original code.
 
Last edited:
I like MAME a lot - I think I kept working on my emulator because the last time I looked (years ago), the poly emulation in MAME wasn't working or wasn't working great - I'm not sure. But it is an amazing piece of engineering.

If I'm looking at the right github project for the 9830, it looks like it is in Java. https://github.com/go9800/GO9800/tree/2.52/GO9800/emu98

I just pushed my work in progress QT6 branch to https://github.com/powool/poly88_emulator in case anyone enjoys such things.

I'm not sure where I'm going with my emulator - I'm just having fun for now. I recently got fired up to get it emulating the half carry flags correctly, which it finally does. Now BASIC works 100% properly, from what I can tell. The QT6 work is about half AI, half me doing QT6 code. I don't like doing the grunt work of UI's, so it is actually working out fine so far.
 
This is a screenshot I just took - I wanted to duplicate some of the look and feel of the poly front panel in the UI directly, because I'm interested in seeing if I can emulate other machines that wouldn't have the poly ROM monitor in them.

Also, I really, really love this concept of showing the CPU state in such detail - I learned so much from this back in the day. Now my kids are in college, and I'm hoping to preserve some of the experience for them in the distant future.


1772246830711.png
 
Looking through the PDF manual on that HP emulator, yes I believe that's the correct one - I'm not sure how they make such nice flat-image reproductions of the hardware (any photo these days tends to be slightly curved).

Bob's emulator compiled-in the ROMs into its runtime - so supporting external files on that would be nice. That's mainly what the -88 command line argument does, it switches to a different built-in ROM (since the 8813 had additional ROM support to seek out the first disk drive and start booting Exec OS). I'm not sure if anyone has successfully imaged and loaded a PolyPhase format -- I have some tapes still in the format, and I can do audio recordings into WAVs for the Byte-format ones, but just haven't got around to trying the PolyPhase ones yet.

Your QT based emu is looking very nice!
 
voidstar78 said:
Looking through the PDF manual on that HP emulator, yes I believe that's the correct one - I'm not sure how they make such nice flat-image reproductions of the hardware (any photo these days tends to be slightly curved).

Bob's emulator compiled-in the ROMs into its runtime - so supporting external files on that would be nice. That's mainly what the -88 command line argument does, it switches to a different built-in ROM (since the 8813 had additional ROM support to seek out the first disk drive and start booting Exec OS). I'm not sure if anyone has successfully imaged and loaded a PolyPhase format -- I have some tapes still in the format, and I can do audio recordings into WAVs for the Byte-format ones, but just haven't got around to trying the PolyPhase ones yet.

Your QT based emu is looking very nice!
Click to expand...
Personal thoughts on appearance - my Dad and I used the poly on an ancient black and white video monitor from the 50's(?) - it had such a distinct phosphor glow that I want to replicate that (and did in the SDL version). The other is, I love front panels, and I love my Poly's, but... the front panel is boring... :) So at the moment, I'm unsure what can be done visually to tie it into the experience, although maybe a poly shaped icon to go with the graphics app itself? hmmm...

Anyway, I didn't realize that mame had code that loaded byte phase tapes, and I wrote my own code to decode those as well - like people have mentioned, it is far easier than polyphase. I see mention that the polyphase works as well. I just compiled the current development branch of mame, and I'll see what works and what doesn't

I have C++ code that I successfully used to turn a polyphase .WAV file into mostly the right bits. The next problem I have is twofold, I think to get the right waveform might require a very high sampling rate - it's been half a year, so I don't remember the details at the moment, but the subtle phase issues are hard to represent if you get too coarse a sample (like 48K samples per second might be too coarse). Secondly, the tapes I have clearly have dropouts - half a bit in length - and these wreck my ability to convert.

I thought I read of someone manually repairing either the waveform or the lost bits, but for polyphase, once it's out of sync, the rest of the data seems to be hash. Some kind of adaptive/corrective UI would make it a lot easier to read and fix polyphase tapes. Inside of a WAV section representing a tape record, it was relatively straightforward to find the mal-formed signal, and the encoding format only has a modestly small number of choices to fix the dropout. I will say that trying to use audacity to fix the WAV file is the wrong way to do it.

I also have reel to reel tapes, with some personal polyphase data on those, but to get that working, I first had to restore an old tape deck of my Dad's. Now that's working, and I need to go back and try it with my code.
 
I thought I read of someone manually repairing either the waveform or the lost bits, but for polyphase, once it's out of sync, the rest of the data seems to be hash. Some kind of adaptive/corrective UI would make it a lot easier to read and fix polyphase tapes. Inside of a WAV section representing a tape record, it was relatively straightforward to find the mal-formed signal, and the encoding format only has a modestly small number of choices to fix the dropout. I will say that trying to use audacity to fix the WAV file is the wrong way to do it.
Click to expand...

Given that the analog audio and data should be more or less representative of each other, I assume you should be able to correct the sync problem and then reinterpret the rest of the audio?

Why was Audacity the "wrong way to do it"? Is it a lack of capability or just controls that aren't sufficiently fine grained?
 
Istarian said:
Given that the analog audio and data should be more or less representative of each other, I assume you should be able to correct the sync problem and then reinterpret the rest of the audio?

Why was Audacity the "wrong way to do it"? Is it a lack of capability or just controls that aren't sufficiently fine grained?
Click to expand...
Excellent points! I'd love to be able to look at a set of bits and say "I know that is a 0x41", then adapt the memory copy of the wav file to match that (I'm sure it can be done, but I have no idea how much work this is yet).

Audacity is a wonderful tool for audio, but I wanted to edit say 5 or 10 samples in the middle of millions of samples, and that was tough to do by hand - plus to restore the phase shift part of the signal by hand is more than I can manage.

I'm goofing around with some ideas about this - if I get any good results, I'll share them here.
 
Well, happily, I was able to finally finish another Qt6 program - this one for scanning and converting WAV files that hold Byte or Polyphase encoded data.

Tonight I finally finagled the waveform decoding to work darn near 100% (at least with my sample tape).

Here's the UI I wrote - you can see some of the records it correctly read, but there are hundreds more on that tape.

1774324054969.png
 
I wrote the UI thinking I was going to need it to repair mangled polyphase waveforms, but it turned out what I used it for was to finally fix my decoding logic. Manchester encoded signals are still confusing to me. But I can't argue with the results.

I'm really happy with this, actually - I've been goofing around with these ideas for a very very long time.

I've pushed the code to github, but want to add more help and also improve the file saving.
 
Just wanted to note some progress on resurrecting a "Game of Life" version for the original POLY-88. @abzman

There are two versions - one is a shorter version posted in early edition of DrDobbs, but the longer (570 bytes) version I found in the PolyMorphic Systems VTI manual itself (with two printed versions of that -- one "pre Monitor 4.0" and one for the final "4.0 Monitor" standard ROM). The extended version is more "interactive" (meaning you can stop/pause it, adjust pixels, then resume it).

I had to transcribe it from the manual, because the scans were rough for OCR. I did the byte-code itself. But then I did the 8080 assembly code portion, and tossed that into the AS assembler (Alfred Arnold). The only issue I had there is that the EQU statements had to start at the beginning of the line (not prefixed with tabs) - other than that, the assembler produced exactly the same object byte code (machine code) as was listed in the printing.


Now that I know it is transcribed correctly and know that it does work, I'll try it on the real hardware sometime this month.
Bob Bylee's POLY-88 emulator worked under both DOSBOXx and DOSBOX 0.74. But DOSBOX-x needed a few config changes in dosbox-x.conf:
char9 = false
output = opengl
clip_paste_speed = 600 (to make pasting hex sequencing work)

With DOSBOX 0.74, it doesn't support a paste option - but Bob reminded me his emulator has an "i" console command, specifically for loading binaries directly into the emulator RAM.



 
Somewhere I have notes from John Conway from when he visited our house and we showed him his game of life on our Poly! Around 1978, I think. We must have showed him the later, better one.
 
Gather up more precise notes on the various versions I'm aware of for the POLY-88 (plus some background on other earlier and later 8080-versions)

BACKGROUND:
LIFE "invented" by John Conway, popularized by Martin Gardiner in 1970 article of Scientific American.

The "LIFE program" is interesting since it was first done on an IBM 360,
then PDP, and so it was fun in ~1975 to show that your personal computer
could now do something those mainframes could do [ if you could afford
to build a VDM or VTI graphics card ]

--------------------------------------------------------------------

[version 0]
Dec 1975, Dr Dobbs Version of LIFE using TinyBASIC Extended (page 19)
(article by Dick Whipple and John Arnold {teacher}, but the code is attributed to
high school student David Piper of Robert E. Lee high school in Tyler, TX;
school was renamed in 2020)
(a TinyBASIC Extended {TBX} is the next article, growing from ~2KB to 2.9KB;
a part 2 of TBX continues on page 37)
As a reference demo of what this BASIC-based 1975 version likely looked like:
(this would be pre-CRT equipped micro)

TAKE AWAY: Stock TinyBASIC wasn't quite strong enough to do Game of LIFE,
a few mild extensions were necessary. But I do know the stock 2KB TinyBASIC was able
to do an a interesting version of StarTrek game.

(interesting: page 30 has a reprint of May 1975 article, describing the Altair's
debut MUSIC recital and the data values used for "FOOL ON THE HILL" and "DAISY"
by Steve Dompier; we should be able to replicate about what it sounded like)

(page 359 {Dec 1976 Vol 1 Number 10}, a version of life for 8080+VDM; done in 116 bytes; refers to
an earlier PCC Vol 4 No 2 {Spring 1975} version that required 218 bytes)
[ these would be for Altair with VDM, or SOL-20; probably adaptable to any 8080-based system ]
(Marvin R. Winzenread, author attributed to the 116 byte version)



*****************************************************************

[version 1]
1976 early version, PolyMorphic Systems VTI manual (page 57)
(author unknown - but this was a test program before the final Monitor 4.0 ROM was finished)


[version 2] [interactive control, uses 2x3 "semi-graphic" font]
1977, PolyMorphic Systems VTI Theory of Operation (page 30) [this is the version in my own video with the emulator; 570 bytes,
since the title description says "FOR MONITOR 4.0 ROM" which I have]
(BRIAN WILCOX)
(on page 35, it has the "non-Monitor ROM" version that is a repeat
of what was on page 57 in the prior Poly VTI manual from 1976; perhaps Brian did that version also, unsure )


[version 3] [smaller code, blockier life-cells]
1978 April, Dr. Dobbs (Volume 3, Issue 4, page 10)
"Interactive Life on POLY88" date on printout is August 1977 (OZNAKI)
(in the article, the dots are referred to as "NAKI"; this version is
for the VDM instead of the VTI; but the output is still F800 and it worked
on my P88 w/ VTI -- the VDM equate is at the same F800 address that
is the typical default used by VTI)
archive.org

Dr. Dobb's Journal - Vol 3 : People's Computer Company : Free Download, Borrow, and Streaming : Internet Archive

Collected issues from Volume 3 (1978) of Dr. Dobb’s Journal of COMPUTER Calisthenics & Orthodontia also known as DDJ.A Reference Journal for Users of Home...
archive.org
(Harvey A. Cohen, Australia)
IIRC, the "NAKI" were life-seeds depicted by asterisks (*).
1775797488801.png
 
Last edited:
I've continued to work on emulator and tape things, and am hoping I can help you out, @voidstar78

I wrote a set of command line tools to convert intel hex format to CAS format files, then CAS files to WAV files, so you can run your assembler, convert to CAS (load to emulator), but then output to the audio out and hopefully your poly should be able to read it!

I am curious if you guys are windows only, or if Linux is comfortable for you. I'm doing my work in Linux, but I can set up cross compiles and upload binaries for folks to use if that would be of interest.

Also, is there a chance you'd be willing to post your assembler source? I'd love to try it out at home... I did OCR on the PDF, too, and it is kinda rough.
 
I have the transcribed Game of Life code for the POLY-88 now available here:

github.com

POLY88_RESOURCE/P88LIFE at main · voidstar78/POLY88_RESOURCE

Repository of PolyMorphic Systems POLY-88 related resources - voidstar78/POLY88_RESOURCE
github.com github.com
(and in case any issue with github, I'll attach the pertinent files here also)

The longer version is fully tested and I deem it 100% correct (meaning, faithful to the original provided code); but still working on the later OZNAKI shorter version -- ran it once, but not entirely sure it was all correct, and the transcription was still missing comments.


Also in the root of that repo: https://github.com/voidstar78/POLY88_RESOURCE
There is a POLY88 CAS to WAV Python script, and an archive of the modern make TETRIS that went under that process.

What I don't have, I think is something to take a compiled binary and convert that to a CAS with some address header. Also, I've not yet successfully loaded any PolyPhase from the physical tape deck that I have (most of the tapes were written on both A and B sides, so I wonder if over time that degraded quality?). I've loaded BYTE format stuff from WAV, but not yet any PolyPhase WAVs.

NOTE: In Bybee's emulator TOOLS folder is SERLOAD and other tools (maybe something to create CAS format?). I probably won't risk attaching more cables to the physical POLY88 that I have. But frankly, its keyboard is "charmingly crummy" - very tedious to key programs in (some keys repeat too quickly, or have to hold SHIFT for A-Z but not for 0-9, etc). So being able to load in stuff via a WAV recording is very helpful.


I also have not yet successfully loaded LANDER from GameTape #1 (nor found CAS or WAV versions of that). Everything on GameTape #2 was fine, and the other items on GameTape #1 also fine. Just LANDER was only title I had trouble with so far.
 

Attachments

Last edited:
Last night, I wrote intelhex2cas - so that's covered now. I'll try and get it checked in shortly. If you're using AI to write that python, it should be pretty straightforward to write a python intelhex2cas.

I was able to get new scans of the games tape, and got the LANDER program with that.

My program also lets me get Polyphase tapes pretty well. The failures looked like they had to do with tape dropouts. My own tapes are harder, because we recorded at 4800 bps.

I'll attach LANDER.CAS as LANDER.JPG and see what happens.
 
Oh - on the tapes I have, I've always used both sides. No problems with bleeding of audio from one side to another that I can tell.

As far as I can tell, you do need higher sampling rate than 44.1Khz to be able to digitally recover polyphase. I'm using 192KHz, which gives a nice clean waveform.

My biggest audio problem now is hum on the original recording - sox or ffmpeg takes care of that.

The big life assembles and runs, but does have a problem - leave the screen blank, then hit X and the top row appears to be set, when it shouldn't. (edit: I think since my emulator puts RAM just before 0xf800, life gets confused by the bytes before the display. I could be wrong - I checked the setup code, and it looks ok).
 
Last edited:
You must log in or register to reply here.
Back
Top