On 12/27/2017 8:35 PM, Randy Dawson via cctalk wrote:
Since I know there's tons of PDP/11 geniuses here, and other gurus with a NOVA
4, and a Tektronix 4052 guy (I have the 4051):
What have you done, with microprogramming this part? In your architecture,
have you changed the microcode, create an instruction to enhance your machine?
I would be interested in any hardware projects, stories (or even in the FPGA, I
hear its a popular thing to copy);
The Ultimate Corporation licensed the Pick system to run on Honeywell
hardware (among others). Initial implementation was on a DPS6 with WCS
written for the DPS6 in a firmware extension of the DPS6 firmware that
executed Pick directly. Parts of the DPS6 instructions routines were
used, as well as using a kernel written in DPS6 assembler to run the
peripherals, disk tape, and serial ports.
Very early a co-processor which was exclusive to Pick was designed and
it was implemented with 2901 hardware. The design for that board was a
32 bit wide arithmetic and logical system. it had only handshakes with
its host system and no I/O. It used host memory for the pick system
since the pick system is a virtual architecture.
The Honeywell incarnation of the co-processor was hosted on a disk
controller derived host board modified and supplied to Ultimate by
Honeywell. Another version was implemented for the PDP 11 qbus and had
a custom host adapter to couple the co-processor to the host.
The host in either case ran a kernel for I/O and other such tasks, as
well as being the main boot processor and control in both cases.
It was required that systems boot from either half inch tape or disk
(once installed).
The 2901 firmware was implemented with the Pick assembler which is table
driven. I don't think much of it would assemble on an AMD tool, as is
the case with most Pick assemblers. It is easy to get the pick system
to do your assembler if you use the conventions of the syntax they use.
However there was generally a desire on both honeywell and dec to have
all tools resident on Pick. there were no toolchains in the released
and production product that was not completely hosted on that system.
Debugging in all cases was done with tools from Hilevel of Irvine. Bjorn
Dahlberg, founder of Hilevel came up with a concept to integrate rom
simulation and hardware simulation tools, and assembler and tools into a
product, and had a very flexible tool that could accomodate most
variations for such as bitslice designs needed. Since the designer
specified all but the basic 4 bit width, the number of slices coupled,
the micro sequencing and other features as one might put into a
microprocessor system had to be dealt with.
Hilevel tools would allow you to simulate all eproms or proms in a
system, and load them dynamically. They also had a very powerful
assembler / linker / loader tool that they would use to provide a
working environment with a support computer attached to their rom simulator.
They also would allow you to add run control to the system, to allow
stepping tracing start / stop or any other controls you needed by
routing signals out to the Hilevel box, and then assigning commands to
control the signals.
For example instead of having to flip a bunch of bits to start or step
your system, you set up a macro to do something and could name it "step"
or "run" or whatever. There were comparators to allow one to do
breakpoints. Also I know of some cases where register examinations were
done.
I think the Ultimate projects were probably a test case for them as far
as features. Mr. Dahlberg had previously worked @ Microdata as had most
of the Ultimate folks (others were Pick people), and that helped.
Thanks
Jim
