Digital Group and Greg Peterson

In mid-2012, I corresponded with Greg "Pete" Peterson, a former Digital Group tech and designer. He described some of his experiences while working for "the Digital Group", an early microcomputer company. He also described his current collection of DG docs, software and hardware. In Aug 2013, he provided some scans and reassembled Z80 code for the early dg Z80 board. I've edited his remarks on this and related pages, with his permission. Please note, Greg expresses his own opinions. Greg comments on some of my Digital Group 2010 acquisitions, on my DG "home" Web page.

As edited, these remarks are copyrighted by me, Herb Johnson. The most recent revision date of this page is Sept 2 2013.

1970's Digital Group experiences of Greg Peterson, May 2012

I stumbled across your site through a link referencing "The Digital Group". It brought back memories. I was there when the DG was formed, though I did not start working there for awhile. This was some 30 + years ago now, in Denver Colorado. - Greg

Hardware and design at DG

The digital group boards were designed by Dr. Robert Suding. He was a bit [proud], but his designs worked. A major DG selling point was the interchangability of their CPU boards. DG offered a Z80, 6800, and a 6502 board. So the customer could pick the processor of their choice, DG was not about picking the winning chip. DG also offered a nice (and expensive) aluminum cabinet during a time when a lot of companies expected the customer to enclose the logic. The color was a chocolate brown, and not un-appealing when grouped with their keyboard and monitor.

The DG system could take up to 64K of ram boards at 8k per board. I remember that they used 2102 ram chips (1 k x 1 as I remember), and fast at around 250 ns. Software was traditionally loaded from an audio cassette deck into a cassette reader board. DG also offered "phi-deck" cassette transports under control of the CPU. This was very similar to the larger mag-tape storage units mainframes used, just implemented with cassette transports. There was a nice search algorithm that allowed the CPU to control the transport and actually find the file on the tape.

I never had the phi-decks, but DG did give me a development system without a cabinet. It was a Z80 with 64K of ram. I built a floppy disk controller for 8 inch drives that I used to bring up CP/M 2.2. It was point to point wiring on a proto board, but it worked very well. I used a 1771 FDC chip as I remember.

DG had their own floppy controller board. I helped implement the design. It was built around a usart chip, not an FDC chip. The usart design worked well, but was proprietary in a time when the IBM standard for floppy disks was winning. 8 inch disks were also in the process of losing out to 5.25 inch media. I missed seeing that one coming. I thought 8 inch would live forever. How naive I was.

I also designed a printer interface for them that used a very inexpensive receipt printer mechanism. It was basically a driver board that used a bit from the 8 bit bus for each pin in the printhead, driving them through a transistor driver. All the rest of the control was in the software the processor ran. This included looking up the font dot layout, firing the pins, and controlling the motors. Timing was critical, and every cpu cycle was accounted for in all program branches so the characters came out undistorted.

The printer was a heavy drain on the CPU, nothing else could happen while printing was going on, but multiple tasks were not a factor at this point in system evolution. The printer was dirt cheap though, at a time when others were trying to get solenoids to press the keys of IBM selectric typewriters to get a printed output. The printer was a pretty popular option at the time.

Robert Suding never liked me very much. I think Richard Bemis, the founder, kept me around in case Robert left him high and dry for a designer. He threw me some designs that Robert considered beneath him, which was fine with me. I am not sure I could have improved much on Robert's designs, given the parts available at the time. Robert was a pretty good processor designer. - Greg Peterson

[In later discusssion, Greg added:] DG created a separate company called "Peripheral Vision" to make some of the peripherals for DG systems as well as other systems. I did a parallel I/O board for them, which you may have an example of [as that I/O board with 74100's]. I don't have one myself. I named the company, BTW. Unfortunately, Richard Bemis chose one of his best childhood buddies to run PV. His choice was a likeable enough guy, but much more a college professor type with a background in sociology as I remember. He came in most days in a sweater with leather elbow patches, smoking a pipe. Clearly he was not the business driver that PV needed, and the company languished. - greg

Software, shipping at DG

Software at the time was always a problem. People would wait breathlessly for each issue of Dr Dobbs Journal, and dutifully poke in the software they found there. I found a software engineer named Will Gasser that wanted to write for the DG machines. He wrote what I remember was an outstanding assember for the DG machines. I would put it right up there with MBASIC at the time. The software edge the machines had was squandered as well.

Shipping was run by a founding employee named Patrice, and her husband. Patrice was the queen bee of shipping, with no particular expertise in logistics or purchasing. She was a very nice person, a hippy chick wannabee, but not up to walking into Dick's (R. Bemis) office and demanding he take an interest in what was funding his company, shipped product.

While the company atmosphere was tense, and at the end very tense, I think most immature growing companies have a similar tenor about them.

Diagnosis & repair

One gets used to [today's] GUI's and mice and point and click, all things we didn't have back then. To compensate, [back then] you could hook a scope to a Z80 system if you got desperate. Just think about trying to scope a modern motherboard and make sense of what you are looking at. It reminds me, one popular troubleshooting method for systems back then was to put a transistor radio next to a malfunctioning computer. The radio would "sing" to you as the computer ran diagnostic routines. With experience, you could tell very quickly if there was a problem and where it was located. DG produced kits for customer assembly. The worst return I saw was a customer that tried to assemble his kit with "liquid solder" epoxy, and angrily returned it complaining of faulty design. DG occasionally assumed too much customer expertise, but we had no "qualification to assemble" criteria. It was not usually a problem though.

What happened to DG?

So what happened [to DG]? Why didn't DG continue growing and become an Oracle or a Microsoft? There were probably a lot of reasons. Shipping, especially at the end, became a very hap-hazzard affair. Short shipping kits to customers became common as parts shortages became a continuous headache. I attribute the shortages to lack of cash to buy sufficient inventory. I attribute the lack of cash to over population of employees. It seemed, at the end, that there were new faces every week. Of course all the new faces were drawing a paycheck too. Customers eventually grew tired of scrounging up the parts to complete their kits on their own, and moved to competitors that could supply complete, if not quite as nice kits.

It started as a nice business model, the customers paid up front for the kits and DG rode that wave of cash to buy the parts for fulfillment. It began to fall apart when Peter was continually robbed to pay Paul, and customers found alternatives as they will do. I don't keep in touch with any of the DG people, we parted on a sour note at the end. -Greg

Greg on his point of view

Boards [in Greg's system]:

one 8080 board DG-1001A w/1702A ROM
one Z80 board DG-1010A w/MMI 1702A0 ROM
3 or 4 Parallel I/O boards DG-1002-A
8 times 8K memory boards DG-0011A
floppy controller, 8-inch, [hard sectored] UART driven DG-0012-A

...the DG Floppy board was only ever intended to handle 8" drives. The big white 40 pin chip is a USART... not a floppy controller. [It's an AMI brand S2350 - Herb] I don't remember, but I can say with some certainty that this did not follow the IBM data format. [Right, it's hard-sectored formatting. - Herb]

So there you have pictures of my boards; I haven't tried to assemble the system yet. [Greg later said he's working on a Z80 system from scratch. - Herb]

Docs, Cassettes

I guess more important than the boards themselves, I have original DG documentation, including parts lists, assembly instructions, and troubleshooting for (I believe) all the boards that I sent you images of. I have a 3 inch binder filled to overflowing with DG info., maybe a thousand pages (a rough estimate). [A list of those docs is at this Web link. - Herb]

I also stumbled across my collection of cassette tapes from that era while cleaning out the garage. I have had to re-build 2 tapes so far, but I am recovering the data on them and will save it eventually on a CD rom.

[As of late May 2012] I am maybe half way through the cassettes at this point. I have roughly 2 dozen or so. So maybe another long night of copying tapes or so to go. It is pretty boring listening to the two tone audio streams. You can tell the DG and Tarbell tapes apart, they sound different.

Greg completed his digitizing work by Sept 2012. Details about the DG cassette format, and how Greg has digitized then, are described in the text document at this Web link. A list of the digitized cassettes is in this text document at this Web link. The tapes were sampled at 44.4KHz, 16 bit, into PCM format WAV files. I'll make the DVD available by postal mail within the USA, for $5 sent to me. Contact me for details.- Herb

I also thought about taking out the EPROMS on the CPU boards and dumping them to hex files. Haven't done it yet though. They are something like 1702's, not sure I have a programmer that can read them. These were very, very early eproms. Hard as heck to program as I recall.

The system was good, and far more complete than competitors of the time. It is a strange feeling to look at notes you made 35 years ago. The perspective is entirely different from what existed when I made the notes. - Greg Peterson

Z80 EROM code and cassette OS - Aug 2013

In Aug 2013, Greg Peterson provided some scans and assembly-language files, of digital group octal ROM and OS listings, which came with the Z80 board he obtained in the early days of "the digital group"; and scans of OS source-code update patches he obtained later. He converted the octal listings with scant comments, into Zilog Z80 assembly language with more commentary. And he converted the later Z80 patches, into macro assembler conditional "IF/END IF" statements into the previous source which he reconstructed. He believes this later "patched" OS version is represented in a program file on one of the audio data cassettes, which he digitized in 2012, as described above in this Web page.

On the earlier OS and EROM octal listings, he says: "I believe I got the original Z-80 CPU board & doc somewhere between 1976 and 1977." These were hand assembled, presumably by Dr. Suding, as octal code. They consist of the Z80 "EROM" or ROM monitor source; and the cassette-based OS source. Greg has not dumped his physical ROM or loaded the Z80 cassette to verify they match these listings.

EROM

Greg marked up the listings, both in the 1970's and recently. So Greg read off the octal, converted to hex, and wrote the Zilog mnemonics for the ROM statup code; and added his own comments. I've reduced and enhanced Greg's images of his scanned sources:
EROM listing 1
EROM listing 2
EROM listing 3
EROM listing 4
EROM listing 5
EROM listing 6
Here's the Zilog assembly of the EROM and here's the assembled EROM listing. Again, Greg has not compared these to his Z80 ROM. As for a date: he says "I believe I got the original Z-80 CPU board & doc somewhere between 1976 and 1977."

Z80 cassette OS, unpatched octal listings

Likewise, Greg has also imaged the dg OS listings, and disassembled them into Zilog mnemonics and reassembling the result. here's the first page of those scanned documents.. The JPEG files are too big to put on-line; I'll be glad to provide the original or enhanced scans to anyone who asks.

Here's the Zilog assembly and here's the assembled listing.

Z80 cassette OS "patches", patched source

Greg says the patch assembly-language listings and cassette came to him "between 1976 and 1977". Later, he sent me JPEG scans of the four page document> The document is titled "New DG OP/SYS Format with Cursor for Z-80 System"; the pages have a footer note which says "Z-O/S w C 77-4". That tells me it's related to dg's Z-O/S documents and it is dated April 1977. My guess is that "w C" means "with changes". Greg took the trouble to merge the patches into the octal-to-assembly source he previously created above. He did so as a conditional assembly, to make or unmake the patches by changing a "PATCH" value to true or false.

Here's the conditionally-patch Z80 source created by Greg, and here's the assembled listing. Due to the large size of the JPEG document files, I reprocessed them into 1-bit TIFF files packed in a PDF document. Here is the patch listings Greg worked from. Greg says:

"If you read the first page of the patch listing I worked from, you will note that it makes reference to a new screen format, and describes it. The patch makes no changes to this part of the code. Based on the description, [this patched version] makes changes to the screen menu format when the "patch1" variable is true, to make it match what the 1st page of the patch listing describes. The late 70's were full of very hectic days, and documentation invariably lagged production, sometimes considerably.

"In summary, there are basically 3 changes to the code that patch makes. The first is rather long and consumes the lion's share of the patch listing. It adds cursor movement via keyboard control characters. [Second,] tucked in at the very end of the listing is a tiny patch, it is easy to overlook. I drew a horizontal line on my listing to make it more obvious.

"The third patch is in the instructions on the 1st page, to move code xxxx to yyyy. The "patch1" variable [in my source] just re-ORG's the assembler and lets it do the work of putting the code there. For a fourth, [unprovided-for] patch, I "reverse engineered" the menu code to make it match the description when the "patch1" variable is true. That changes the display format of the user menu to what is described on the 1st page of the patch's listing." - Greg

Greg explains

Here's how Greg describes his work, and puts some of the DG code releases into context. I've edited his comments. Text I've added is in []'s. - Herb

"The scans [of the EROM and OS listings] were the original source code listings distributed with the DG Z-80 CPU board. I believe I got the original Z-80 CPU board & doc somewhere between 1976 and 1977. I"ve NOT verified [the EROM listing] against the EPROM itself (I don't have a 1702 EPROM reader). [The OS code was provided on an audio cassette.] The added pencil markings are mine as I tried to understand what the octal code was doing. Some were added in the 70's by me, some recently. I believe these were hand-assembled by Dr. Robert Suding of the Digital Group (they precede the 1st assembler that DG issued). Also, the code, examined closely, indicates hand assembly. The code could be better, but hey, it is a pretty good 1st attempt for the time. Cudos to Dr. Bob."

"The code listings are my translation of the source code listings from DG. They are converted to standard Zilog mnemonics and heavily commented. I believe I understand what the code is doing and have commented it so. It is possible I have included incorrect comments, but with the originals, someone else will be on at least an equal footing with me for decoding it."

"Comment errors I accept as being mine, there were precious little comments provided with the original listings. Inspect the original listings for what Dr. Bob thought, then look at my commented listings for what I thought was going on in the code. [In the OS code,] I think Dr. Bob had to get pretty creative in an effort to keep some code addresses fixed and yet evolve the code too. A jump table would have been the solution, but he seems to have broken things up strangely in a couple of places. I am assuming it was to preserve pre-existing addresses, I can see no other reason for it. I am leaving it as is for now. I would probably just break it if I were to fix something that is technically not broken. It is pretty amazing what you can tell from the code people write.

"....It does take awhile to "grock" what is going on in the code. I would say I am hand disassembling the code, but I have the source. I am really trying to understand the code and comment it for others to use. You really can't do that with a computer." - Greg

[After Greg turned the patches into an update of the Z80 source he recreated, he said:]

"I did get an OS update. It was released around April 1977 I believe. It is not another complete listing [of the OS]. It is a patch. 'Replace the code from xxxx to yyyy with this: zzzz.' As I said, [this patch] is a poor [paper] copy. You can [also] find that version on the audio [cassette digitized] recordings I sent to you some time ago. What is on that recording should correspond to what I have sent you in hard listings. A good check would be to [convert the audio file back to binary data and] dis-assemble the audio and check it against [both of] the listings. I suspect there are changes I have not caught."

[And why create an "updated" source via conditional assembly?] "Does it make sense for me to send you 2 files that are 95% identical? A few minutes with an editor can make that happen, but there is value is seeing the two code versions together so you can see what changed."

I asked Greg about "version" identification for the Z-80 OS. He said: "Herb, DG was never very rigorous about versions of their software. The patches were published in a newsletter as I recall. If you got a copy of the new OS cassette, you just loaded it in and ran with it. It was not like you assembled a new OS with patches & put it on a cassette."

Related work

Greg also has some manuals and code for the digital group's 6800 and 6502, which he says he may get to "in the fullness of time". and he has some other projects related to microcomputer monitor programs. For example, "HEXMON: A monitor to dump, load, and verify Intel hex checksum paper tapes with tape label for leadin header. This code is from: '8080 / Z80 assembly language, Techniques for improved programming' by Alan R. Miller, Copyright 1981" Here's the HEXMON source which Greg has processed and assembled. - Greg

Copyright © 2012 Herb Johnson