instead; that's likely to be faster in the long run.
If you need someone to help, I'd be happy to transcribe some shit while
watching TV if you send me the docs and desired schema. I'm no stranger to
this sort of process :)
On Mon, Jun 20, 2016 at 1:35 PM, Paul Koning <paulkoning at comcast.net> wrote:
On Jun 20, 2016, at 4:22 PM, Toby Thain <toby
at telegraphics.com.au>
wrote:
On 2016-06-20 4:17 PM, Paul Koning wrote:
...A hardware model can
be used to
replicate what old hardware did; for example, I have a
partial CDC 6600 model that shows how it boots, and that model includes
propagation delays on some signals (which are critical to correct
operation in certain spots).
This is probably of great interest to more than just me.
Any more details? Going to publish?
Sure. You can see it at
svn://akdesign.dyndns.org/dtcyber/trunk; most is
in the vhdl subdirectory but it uses some pieces from the top level. Very
much work in progress.
It's derived from the 6600 wire lists on bitsavers. I OCRed them (what a
pain), wrote VHDL models (gate level structural models) of each 6000 series
module, and a Python script builds a structural model out of those elements
interconnected by the wires from the wire lists. "Sufficiently long" wires
have their delay explicitly modeled.
I currently have chassis 1 (PPUs) working, at least to the point where I
can do a deadstart, have that load from the deadstart panel, and execute
some instructions. I've used it to grok some magic related to deadstart
that's part of the lore but not documented. I also have the 6612 display
controller working, so I can see how the text display on the console tubes
works. Unfortunately I don't have a good SPICE model for the analog parts,
so I don't yet know why the character shapes are changed by the circuitry
in the manner that the photos show.
The CPU is work in progress. I'm trying to get exchange to work. It's
hard; even more than the PPUs, the CPU relies on hairy timing in certain
spots. It appears that the wire lists are not all the same rev, and there
are also some typos in them.
Some day, if things go really well, this may result in a gate level
accurate FPGA 6600. I'm thinking I'll stop trying OCR and simply type the
wire lists instead; that's likely to be faster in the long run.
paul