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