Z8000 Trump Card Needs Your Help

[Smbakeryt] needs your help. He bought a 1984-vintage Z8000 coprocessor card for the PC, but the software is missing in action. Apparently, the co-processor — called a Trump Card — appeared in Byte magazine courtesy of the famous [Steve Ciarcia]. The schematics were published, and if you sent [Steve] proof that you built it, he’d send you the software. The product was later commercialized, but no one seems to have the software, so [Smbakeryt] is on the lookout for it.

The board itself was pretty amazing for its day. It added a 16-bit Zilog Z8000 CPU with 512 K of RAM. Big iron for 1984 and a good bit more performance than a stock IBM PC of the era.

We miss the days when computer gear came with big binders of documentation. These days, you are more likely to get a sticker with a URL. The Z8000 was a nice processor and could emulate the Z80, but it never became hugely popular. In addition to Zilog’s System 8000, the CPU found its way into some Unix computers including the Onyx C8002 and several Olivetti computers. Commodore planned to use the CPU in a canceled project. The Z8000 was famous for not using microcode and, thus, it fit on a relatively small die with 17,500 transistors (compared to the 8086’s 29,000 transistors).

We hope someone can help out with the software. If you want your own Z8000 system, you might be better off with Clover. Or, stick with a Z80 on the cheap.

45 thoughts on “Z8000 Trump Card Needs Your Help

  1. Orange card bad! On a more serious note beautiful piece of tech and the ring binder with instructions brings me back to a time where purchasing a product made you feel like a customer and not consumer.

    1. I have reached out to Steve a couple times on email, but without receiving a response. It’s possible that I’m using an outdated email address, or it could be that he has just tired of people asking for Trump Card disks that he does not have. If anyone has contact information, please forward and I will try.

      1. Fantastic news — I have been in contact with Steve Ciarcia who provided me some of the historical background on the Trump Card. Steve does not know if he still had a copy of the software or not, but the majority of his Circuit Cellar materials have been donated to the Computer Museum of America in Georgia. If Steve had a copy of the disks, then that’s where the disks would have ended up. It will likely be some time before the museum has time to unpack and inventory the materials. Steve recalls sending the Trump Card software to at least a hundred BYTE Magazine readers who built the cards themselves. The card, as we know, was also commercialized by Sweet Micro who sold an undisclosed number of completed cards with software. So there are still a few leads to follow in the search for the software.

    1. Could it be he was not lying but mistaken? Perhaps he doesn’t know that logo like you do.

      And why would a device like this have anything to do with Trump anyway? Does or did he ever have any connection to tech?

      Could it be the original designer of the Trump card was misusing the trademark to try to get more exposure?

    1. May and presumably June 1984. At the end of part 2, there’s the bit about not penalizing homebuilders, so software for the cost of shipping and floppies if you send a photo and $30.

      As originally intended, it was mostly a BASIC speedup, and ramdrive.

  2. A quote from the Byte article: “Trump Card is not an easy project to build. Compared to other Circuit Cellar projects, however, it’s manageable. I was surprised at the number of readers who hand -wired the 121 -chip MPX-16 PC- compatible computer that I presented last year. Their letters suggested that the motive was neither money nor masochism.” Like climbing the Everest, just because it is there :)

  3. As far as I know, the Z8000 could not emulate a Z80 in hardware, because the instruction set was completely different; the registers largely incompatible and there was no mode-switching bit in a control register that put it into a Z80 or virtual Z80 mode. Z80 incompatibility was one of the major reasons why the Z8000 failed.

    It may have been possible to translate Z80 assembler into Z8000 assembler, in much the same way that 8080 assembler could be translated into 8086 assembler. Is that what’s meant here?

      1. But that’s not special. So could the original IBM PC; there were several software emulators available. Hell, so could the Apple ][, with the right software!

        But to specifically state that “the Z8000… could emulate the Z80” makes it sound like no additional software is required – for example, the V20 can emulate the 8080 in (I guess) microcode, it’s baked right into the chip. On the Z8000, it’s not. And to try and retcon that by saying “oh, I meant software” smacks of avoiding the admission of a mistake.

        I mean, aside from anything else, the Z8000 is big-endian…

        1. The V20 and V30 emulate the Z-80. One program that switched it to Z-80 mode and setup the rest of the system was 22NICE. I had a V20 in a PCjr and it ran CP/M software faster than the real Z-80 powered Xerox 820-II I had at the time.

          22NICE could also software emulate a Z-80 on an 8088/8086 and up. Running it on a 12Mhz 286 was slower than the Xerox.

          1. No, they emulate the 8080, as the first page of their documentation¹ (and pretty much every contemporary account) makes clear. Most CP/M software was written with an eye towards 8080 compatibility, so in practice that was fine; but one well-known CP/M package that was only Z80 compatible was Turbo Pascal – and, of course, so was everything written with it.

            Moreover, 22NICE’s own documentation states, clearly, “Note that the NEC V20 and V30 microprocessors do not support the extended instruction set of the Z80 processor.”² It dealt with 8080 and Z80 emulation differently; since the 8080 emulator was faster than the Z80 emulator, if a piece of software was 8080-compatible it could use that… unless it was running on the V20, in which case it could use that processor’s 8080 mode. Anything that needed Z80 instructions had to be emulated in software.

            This is a pet peeve of mine. If you’re going to “correct” people, first make sure they are actually wrong – and that you aren’t. I could verify my assertions with two searches. What stopped you?

            ¹ https://archive.org/details/bitsavers_necV20V30U_11351331/page/n5/mode/2up
            ² p.7, 22NICE.DOC, in the v1.32 distribution at http://www.gaby.de/22nce132.zip

    1. The software was there to make it usefull. Like when I upgraded my Radio Shack Color Computer III, it came with ramdrive software. Most buyers weren’ running Microware OS9, that beneftited most from the ram upgrade.

      The CPM emulator may have been useful, but likely not to many. Running BASIC faster may have been the most useful thing. The C compiler may have been useful, but Steve Ciarcia said in the article “my programming language is solder”. Basic was useful, he knew it.

      1. I agree, both Basic and assembly language were often used by hardware guys.

        I suppose it’s because they both allow the engineer/technician to directly control the hardware in a specific order.

        Many Basic interpreters allow inline-assembly (DATA…) and peek/poke, which allows direct manipulation of the hardware.

        So they kind of feature a similar convenience like a monitor program program does.

        They’re not the same, but both allow unrestricted manipulation of the hardware.

        By contrast, high-level languages -or rather- compiler languages do often perform tasks in an unforeseeable order and like to “optimize”.

        1. In fact you could encode complied assembler binaries in Basic data statements and call those routines from Basic. I did this to create a program that read and wrote proprietary structured floppy disks where the data locations were static by controlling the floppy controller to read and write tracks and sectors directly. Bonus, this assembler code included a routine to fix up instructions that accessed absolute memory locations as the resulting program could load to different addresses due to changes in the Basic code. The entire program was compiled using the Basic Compiler. Bonus 2 the program included assembler routine to format the blank floppies proprietary track and sector layout.
          Circa ~1982. Yes Basic + assembler was cool.

  4. It’s been my experience, when trying to revive 30-40 year old computer tech, that more often than not it’s actually the RAM chips that are most likely to have perished during the long sleep. (If we’re just talking about the silicon, and excluding obvious gimmes like batteries and electrolytics)

    With that many RAM chips, would not be at all surprised if 3 or 4 were dead.

    1. Yes, but that’s mainly due to their sensitivity to electro static discharge (ESD).
      The early CMOS technology was very fragile. Shift registers based on TTL were much more rugged.

      It’s possible that they died due to a power surge/voltage spike on the power line.
      Broken caps could also be the culprit.

      Anyway, dead RAM also has something good.
      It acted like a fuse when it died and protected other ICs next to it.

  5. Fix ‘er up and write your own software!

    You’ll be faced with the issue of finding an ISA bus machine to host it. Hardly insurmountable, but becoming more of an issue all of the time.

    1. You can built them your own these days.

      There’s an GPLed PC BIOS and there are many XT motherboard projects..

      With an V20/V30 or V40+ CPU in place, they’re compatible with 80186/80286 Real-Mode DOS software (DOS).

      But strictly speaking, that’s not ISA or AT-Bus.
      The 8-Bit part of ISA was originally being called PC-Bus or XT-Bus.. :)

      PS: S100 is an alternative, too. There are modern takes on S100 based systems with 8086 to 80386 CPU cards.
      They can run MS-DOS already, their monitor programs have evolved somewhat, too.

  6. There were 2 or 3 publishers BBSes that aggregated project software, firmware and drivers for a whole whack of the hobbyist magazines from 80s to the early 90s, then when WWW caught on they vanished. They may have been available over telnet, gopher or something for a while. Anyhoo, makes a large number of projects in those back issues kinda useless, it’s PIC code, PC drivers or EPROM loads all missing. I guess some could be rewritten from scratch if you had enough clues where the author was going, some had at least a flow chart of what the programming did. But you’re SOL if something later built on something earlir.

    Sure would be nice if archives of those BBSes turn up anyway.

    1. By the way, large amount of kudos to the German magazine c’t which seems to have online archives of that period still. Some small amount of projects were repurposed from there or to there for other mags, so it’s maybe worth digging in their site to see if anything comes up.

  7. Wow, this brings back really old memories. I learned Unix on a Zilog S8000 minicomputer (used the Z8000 cpu) in 1981ish. Until then I had used punched cards on an ICL mainframe and ed on CP/M. Vi, sh and man were huge revelations. We had a printed out set of man pages which I read cover to cover. Then a consultant showed me the man command and it blew my mind!

Leave a Reply to scott_txCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.