Reproducing old machines with newer technology (Re: PDP-12 at the RICM)

Jay Jaeger cube1 at charter.net
Tue Jul 14 10:55:13 CDT 2015


Actually, the automated design tools will automatically flag wired or /
wired and, because they result in tying the outputs of multiple
"drivers" together.

BTW, my next project for this kind of thing is intended to be the IBM
1410.  Quite a challenge.   I expect it will probably take me 2-3 years
to do.  I actually intend to build a database from the Automated Logic
Diagrams [essentially trying to reverse engineer them into something
close to what IBM would have had in a tape file to actually generate the
ALDs] and then generate VHDL from that as much as possible.

JRJ

On 7/14/2015 4:20 AM, ANDY HOLT wrote:
>>>>>
> ----- Original Message -----
> From: "Dave G4UGM" <dave.g4ugm at gmail.com>
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
> Sent: Tuesday, 14 July, 2015 8:58:09 AM
> Subject: RE: Reproducing old machines with newer technology (Re: PDP-12 at the RICM)
> ...
> My next project is likely to be the Ferranti Pegasus which is several orders of magnitude more complex than the Baby and will need a proper plan. 
> <<<<
> 
> "There may be troubles ahead" …
> I had plans for doing something similar for the ICT1905 (FP6000) and discovered two catches in translating the logic diagrams:
> 
> FPGAs are designed around the modern concept of a single clock that is widely distributed and having flipflop control by gating the input signals whereas early Ferranti machines (1900, at least pre "A" series, Atlas*, and presumably Pegasus) used "strobes" which are hard and inefficient to do in a FPGA.
> 
> Maybe less likely to be the case in the Pegasus is the widespread use of "wired-or" which can be hard to recognise in the logic diagrams (and, again, requires translating into "real" gates in an FPGA)
> Obviously a register transfer model wouldn't have those problems compared to a gate-level model and would be considerably simpler to implement but then risks losing some of the (possibly undocumented) edge cases.
> 
> * Atlas would, presumably, be even trickier due to the use of asynchronous logic. 
> 
> Good luck, should be an "interesting" exercise.
> 
> Andy
> 


More information about the cctalk mailing list