Re: Paradox concerning CP/M-86

Still, I learned a heck of a lot about the IEEE488 protocol.

I never got to handle that,
but it looks really well defined on the bus level.
I never even found surplus equipment with that interface.

You have my sympathies. I once did the on-board firmware and device driver
for a VAXBI quad IEEE-488 interface. It was a Z80 with four NEC 7210s.
It 'bout killed me.

But it sounds like a rather worthy challenge where you succeeded

Merging slightly towards topical, development was done on the CP/M side
of a DECmate II using M80 and L80. When things got a bit big for L80 to
deal with, I gave SLRNK+ a try, but it kept making mistakes linking the
system so I wound up arguing with L80 to make it link. I don't recall
the details of the mistake, but I've not trusted SLRNK since.

Wow, that brings back bad memories of severe compiler and
disk space limitations.

The source code was large enough that the DECmate II didn't have enough
directory entries on the hard disk to hold the sources, listings, and all
the object files. I kept the sources on six RX50s and would cycle through
them on assembly (I could keep the listings and object files on the hard
drive, just not them all *and* the sources). As M80 was assembling from
one drive, I'd change the disks in the next. I had a big SUBMIT file that
orchestrated the assembly and had to write a little program to reset the
disks when it changed drives.

Clever workaround for such a tedious task!
My frustration was the immense gap between Z80 compilers
and the Unix tools of the time (late 70s).
After using Unix, it was tedious (at best)
going back to anything "less".
But at one job I had to use a cross-development environment
since the target CPU was execute-only.
No self supporting development (or debugging) tools.
It was preparing me for embedded processing :-/

That's one appeal CP/M has for me:
the Z80 system can work totally stand-alone for development
even if it's a single board embedded system when running just the app.

In addition to the four 7210s, the VAXBI board had a couple of UARTS and
an STD bus. For debugging, I booted CP/M on it and used ZSID. For a
large part of the debug effort, I used a second board to generate VAXBI
traffic.

Wow, what memories. I barely touched
STD bus and salvaged some bits and pieces.
It looked nice on paper but I'm unsure how to resurrect it.

Which means that I had a VAXBI CP/M system.

During some of my previous work, I had fallen in love with the DR780, so
I designed the firmware such that the on-board Z80 would look things up
in the VAX page table to perform virtual-to-physical translations. That
worked until they changed the page table format to allow VAXen to have
more than 512MB of RAM. But by that time, the hardware was no longer
being built, so I never had to update the firmware to support the new
page table format.

The Z80 also used self-relative doubly-linked queues (supported by VAX
instructions) to communicate with the VAX.

That sounds EXTREMELY clever.
It must've been very nice to use once completed.

I wrote a Unix & Solaris sync serial device driver
but the device driver did all the
virtual-to-physical address translation.
Concurrent Computer Corp's Real Time Unix had a lot of support
for direct interfacing to peripherals
such as giving it the physical memory addresses,
allocating contiguous memory and disk sectors.

Good times. But, like I said, it 'bout killed me.

It sounds like the Unix DKI/DDI (device kernel interface)
was developed later to preserve others' sanity.

And I still think the DR780 was cool.

It sounds it.

roger ivie

-- Jeffrey Jonas
jeffj@panix(dot)com
The original Dr. JCL and Mr .hide
.

Relevant Pages

  • Re: JOP as SOPC component
    ... order of six lines of code per interface for a point to point connection, ... I think that this is actually the power of SOPC builder. ... When you have a latency aware master and a slave then there is the one ... aware master/slaves to ones that are not, multiple bus masters, etc. ...
    (comp.arch.fpga)
  • Re: Sarahs very sad...
    ... There is a core of a Unix OS in the foundations, ... It is a considerable wrench going from a GUI to a program whose interface ... Linux or Unix system without ever seeing a command line or a config file ...
    (uk.people.support.depression)
  • Re: Computer
    ... All the Unix commands are there. ... I don't care about the base operating system. ... I like the Mac interface better than the Windows interface. ... I rather suspect that some would still be using the old DOS and command lines, ...
    (rec.photo.digital)
  • Re: Bigboard 1
    ... Taylor Electric Company provided the "Better Board", including floppy disk ... drive interface enhancements, enhancements to PFM, and corrections to the ... including JBW and Andy Bakkers sold SASI interface ... The GIDE interface would work with an original BBI to add a hard disk ...
    (comp.os.cpm)
  • Re: Computer
    ... All the Unix commands are there. ... I don't care about the base operating system. ... I like the Mac interface better than the Windows ... businesses using old DOS programs in a DOS box, ...
    (rec.photo.digital)
Loading