24 Oct
2017
24 Oct
'17
5:44 a.m.
Hi DEC Enthusiast's,
If I were to have to decide on just one model DEC PDP system to run in a DEC
Emulator, which one would be the most useful, versatile and has the most
software available for it?
I have only ever used a real PDP-8/e system way back in high school so I'm
not up to par on any other model of DEC PDP system and I only know BASIC on
the PDP-8/e so not much there either.
I hear a lot about the PDP-11. I found out that there were 16 major PDP
models at one time so I'm not too sure which one to pick.
I built Oscar Vermeulen's PiDP-8/I which I'm waiting on 1 part for. Other
than that project which is in a holding pattern at the moment, I have no
other PDP anything running in any form.
Back in the day when Bill Gates and company 1st started out, I had always
wondered how they developed their very 1st software program - Altair Basic.
I was pleasantly surprised one day when I saw a B/W photo of a young Bill
Gates bending over the operator at what looked like a very small computer.
Maybe it was just a terminal. I don't remember. I understand they did
software development on a DEC PDP of some sort.
Finding this out regenerated my interest in the DEC PDP line of computers.
I have many projects in the works already so I decided to setup a software
emulation of just one of the DEC PDP models. I have heard a lot about the
PDP-11 which if the information I read is correct was 16-bits. My PiDP-8/I
is 12 bits. I understand the PDP 10 was 36-bits and the PDP-15 was 18-bit.
The PDP-11 is the model I hear the most about.
I also have some experience on some version of a VAX when I was in the Air
Force so I'm thinking of getting a VAX emulation going at some point too.
So if I'm going to do this, what suggestions, pointers, experiences,
etcetera do you guys have for me. I am very interested in the DEC PDP
equipment though next to no experience so I have no basis to make a
decision. This is a serious request so I would definitely like to hear what
you all have to say. If you have read this far, thank you. Take care my
friends.
Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
24 Oct
24 Oct
12:06 p.m.
On Oct 24, 2017, at 1:44 AM, Kip Koon via cctalk
<cctalk at classiccmp.org> wrote:
Hi DEC Enthusiast's,
If I were to have to decide on just one model DEC PDP system to run in a DEC
Emulator, which one would be the most useful, versatile and has the most
software available for it?
I have only ever used a real PDP-8/e system way back in high school so I'm
not up to par on any other model of DEC PDP system and I only know BASIC on
the PDP-8/e so not much there either.
I hear a lot about the PDP-11. I found out that there were 16 major PDP
models at one time so I'm not too sure which one to pick.
I built Oscar Vermeulen's PiDP-8/I which I'm waiting on 1 part for. Other
than that project which is in a holding pattern at the moment, I have no
other PDP anything running in any form.
When you say "emulation" do you mean a software emulator like SIMH or E11? For
those, the model choice is just a startup parameter, so you can change at will.
Or do you mean an FPGA based one like PDP2011? There too the choice is a parameter, when
you build the VHDL into the actual FPGA bits.
In any case, if you want to pick a particular model, I would say 11/70 is a good choice.
While near the end of the PDP11 era the Q-bus became mainstream, for much of the time the
Unibus was either the only or at least the primary I/O bus. It has the full memory
management unit and full floating point, so any software that requires these is happy. It
has 22 bit addressing for big memory. And it is old enough that early operating systems
like DOS will work. You could even turn on CIS instructions and call it an 11/74, the
semi-mythical 11/70 variant for commercial applications (COBOL) that never shipped, some
say because it was too good compared to the VAX 11/780.
One more consideration: if by "emulator" you mean something in hardware that has
an actual DEC I/O bus coming out of it and accepts real DEC cards, then a Q-bus system may
be better, it depends on what I/O devices you can most readily find. If so, I'd go
for the 11/73.
paul
1:07 p.m.
On Tue, Oct 24, 2017 at 8:06 AM, Paul Koning via cctalk <
cctalk at classiccmp.org> wrote:
I think OS/8 is pretty good for a one user system, if that's what you're
using it for. You already kind of know it and one can run a lot of
languages on it. I'd agree about the 11/70, but only if you're running the
kinds of applications found on the disk images that are out there.
Otherwise over time you can make your own tapes/RL02/RK05.etc disk pack
sets (or whatever) to emulate in.
I have a Next Thing CHIP with as many SimH builds and images as I could
find and test to set up, DEC included, so I can switch around at will. I
have my a serial terminal for I/O. Certainly never get bored with that
kind of setup.
Bill
On Oct 24, 2017, at 1:44 AM, Kip Koon via cctalk
<cctalk at classiccmp.org>
wrote:
Hi DEC Enthusiast's,
If I were to have to decide on just one model DEC PDP system to run in a
DEC
Emulator, which one would be the most useful,
versatile and has the most
software available for it?
2:32 p.m.
On Oct 24,
2017, at 1:44 AM, Kip Koon via cctalk <cctalk at classiccmp.org> wrote:
Hi DEC Enthusiast's,
If I were to have to decide on just one model DEC PDP system to run in a DEC
Emulator, which one would be the most useful, versatile and has the most
software available for it?
I have only ever used a real PDP-8/e system way back in high school so I'm
not up to par on any other model of DEC PDP system and I only know BASIC on
the PDP-8/e so not much there either.
I hear a lot about the PDP-11. I found out that there were 16 major PDP
models at one time so I'm not too sure which one to pick.
I built Oscar Vermeulen's PiDP-8/I which I'm waiting on 1 part for. Other
than that project which is in a holding pattern at the moment, I have no
other PDP anything running in any form.
25 Oct
25 Oct
2:40 a.m.
Hi Guys,
I think I know so little of the PDP systems that I really didn't know how to
correctly phrase the question in PDP speak in my 1st email so let me try.
I was initially thinking of a strictly software only solution running on my
Windows 7 x64 laptop only since the only hardware based simulator I have is
the PiDP-8/I which is not up and running yet.
I'm primarily a Motorola Processor man so after sending that 1st email I
found a gentleman's web site who built a PDP-11 Console front panel using a
6802 on the core board at 1st then redesigned the core board to use the 6809
and an I/O board working together as the controller for the PDP-11 front
panel. The core board's serial port is connected to a PC running SimH
modified to communicate needed data to the front panel controller. The url
link to his web site is below.
< http://www.pdp-11.nl/>
Click on the "My Projects" link on the left to see a quick summary of all of
his homebrew projects of which this is only one. Now back to the core
board.
Of course the 6809 can be replaced with the 6309 as well. Well, that really
sparked my interest as I am in the middle of designing a Motorola
Multi-Processor based single board computer board. It will have the ability
to support all of the following processors however ONLY 1 CPU can be
populated on the PCB at a time as ALL address, data and control busses are
tied together using one common flash/eprom, ram, 2 serial ports and 4 -
8-bit parallel ports with 2 special control bits on each port. The
processors that will be supported are the 6802, 6809, 6309 and the following
68HC11 sub-variants A1, A8, E2, F1 & K1.
So now my software only DEC Emulation idea is splitting into 2 thought
processes.
1st, a software simulator only way yields all currently supported PDPs which
still presents a problem for me and that is which PDP do I teach myself and
set up. So far, it seems that you guys are saying that the PDP-11/70 is a
good choice whether SimH or Erzata-11 is used.
A while back I found the PDP-8/e WinEight software simulator as one choice
as well. SIMH can run them all. Still though, which one?
2nd, a hardware emulator running a simulator written in 6809 assembly
language for the PDP-8/e running on a 6809 Core & I/O board system seems
like a good choice for me as I understand the 6809 microprocessor, the 6821
Peripheral Interface Adapter and the 6850 Asynchronous Communications
Interface Adapter chips used on the core board reasonably well.
There is a PDP-11 version of this hardware emulator available with only 1
more requirement and that is SIMH is running on a PC which communicates via
serial port the data needed to control the PDP-11 front panel.
3rd, and this is a big factor in the choice of DEC PDP computer to pick for
simulation or emulation and that is the small cash flow and itty bitty
storage space I have available to me.
So with what I have to work with, my current interests and skill level of
PCB design using the Motorola 8-bit processors as well as using Windows 7
x64 for software only simulations, which PDP should I chose?
The choice so far it seems is the PDP-11/70. Remember I still have no idea
beyond some searching on the internet what boards and peripherals a
PDP-11/70 consists of. For that matter, I don't know what boards and
peripherals are in the PDP-8/e or PDP-8/I either.
I hope this helps you all understand me and my desires a little better.
Please keep your ideas, suggestions and questions coming. You have my
complete attention! I'm sitting on the edge of my seat as it were. :) I'm
beginning to see that this is going to be a very long term project. Cool!
I need something to keep my mind sharp. Take care my friends.
Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Kip Koon
via cctalk
Sent: Tuesday, October 24, 2017 1:44 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: Which Dec Emulation is the MOST useful and Versatile?
Hi DEC Enthusiast's,
If I were to have to decide on just one model DEC PDP system to run in a DEC
Emulator, which one would be the most useful, versatile and has the most
software available for it?
I have only ever used a real PDP-8/e system way back in high school so I'm
not up to par on any other model of DEC PDP system and I only know BASIC on
the PDP-8/e so not much there either.
I hear a lot about the PDP-11. I found out that there were 16 major PDP
models at one time so I'm not too sure which one to pick.
I built Oscar Vermeulen's PiDP-8/I which I'm waiting on 1 part for. Other
than that project which is in a holding pattern at the moment, I have no
other PDP anything running in any form.
Back in the day when Bill Gates and company 1st started out, I had always
wondered how they developed their very 1st software program - Altair Basic.
I was pleasantly surprised one day when I saw a B/W photo of a young Bill
Gates bending over the operator at what looked like a very small computer.
Maybe it was just a terminal. I don't remember. I understand they did
software development on a DEC PDP of some sort.
Finding this out regenerated my interest in the DEC PDP line of computers.
I have many projects in the works already so I decided to setup a software
emulation of just one of the DEC PDP models. I have heard a lot about the
PDP-11 which if the information I read is correct was 16-bits. My PiDP-8/I
is 12 bits. I understand the PDP 10 was 36-bits and the PDP-15 was 18-bit.
The PDP-11 is the model I hear the most about.
I also have some experience on some version of a VAX when I was in the Air
Force so I'm thinking of getting a VAX emulation going at some point too.
So if I'm going to do this, what suggestions, pointers, experiences,
etcetera do you guys have for me. I am very interested in the DEC PDP
equipment though next to no experience so I have no basis to make a
decision. This is a serious request so I would definitely like to hear what
you all have to say. If you have read this far, thank you. Take care my
friends.
Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
3:26 a.m.
Related to DEC emulation: is there a visual Straight-8 simulator? I'd
like to practice working the front panel and such.
12:20 p.m.
On Tue, Oct 24, 2017 at 11:26 PM, Evan Koblentz via cctalk <
cctalk at classiccmp.org> wrote:
Related to DEC emulation: is there a visual Straight-8
simulator? I'd like
to practice working the front panel and such.
I don't think there is one. The PDP 8i is the closest thing but there are
I think 26 switches at the bottom the 8i, I think only 18 at the bottom of
the straight 8. They thus can't be the same exactly but it may be that the
straight 8 is the same as the 8i, if you use only switches that appear on
both systems (no step counter on the straight 8). Dave G will know.
b
8:10 p.m.
On Wed, Oct 25, 2017 at 5:20 AM, william degnan via cctalk <
cctalk at classiccmp.org> wrote:
On Tue, Oct 24, 2017 at 11:26 PM, Evan Koblentz via
cctalk <
cctalk at classiccmp.org> wrote:
Both the 8/i and the Straight-8 have the same number of switches (26).
Their function is identical. The 8/i has a few additional lights, however.
- Josh
Related to DEC emulation: is there a visual
Straight-8 simulator? I'd
like
to practice working the front panel and such.
I don't think there is one. The PDP 8i is the closest thing but there are
I think 26 switches at the bottom the 8i, I think only 18 at the bottom of
the straight 8. They thus can't be the same exactly but it may be
that the
straight 8 is the same as the 8i, if you use only switches that appear on
both systems (no step counter on the straight 8). Dave G will know.
b
26 Oct
26 Oct
7:32 p.m.
On 10/24/17 7:40 PM, Kip Koon via cctalk wrote:
The choice so far it seems is the PDP-11/70. Remember
I still have no idea
beyond some searching on the internet what boards and peripherals a
PDP-11/70 consists of. For that matter, I don't know what boards and
peripherals are in the PDP-8/e or PDP-8/I either.
bitsavers.org/pdf/dec has details for most of the DEC processors and software
8:29 p.m.
On Oct 24, 2017, at 10:40 PM, Kip Koon via cctalk
<cctalk at classiccmp.org> wrote:
...
2nd, a hardware emulator running a simulator written in 6809 assembly
language for the PDP-8/e running on a 6809 Core & I/O board system seems
like a good choice for me as I understand the 6809 microprocessor, ...
I would call that a software emulator; the fact that it runs on some microprocessor eval
board doesn't make a difference. Running SIMH on a Beaglebone would be analogous
(though easier).
When you said "hardware emulator" I figured you meant an FPGA implementation of
a VHDL or Verilog model of the machine. There are a bunch of those for a variety of DEC
computers. One I have looked at is this one: http://pdp2011.sytse.net/wordpress/ which
incidentally is also configurable to implement a choice of PDP11 model.
paul
27 Oct
27 Oct
5:41 a.m.
Hi Paul,
Thank you for the info. I tend to get emulation and simulation a bit
confused. Just so I understand simulation correctly, hardware emulation is
when the functionality of the hardware is actually implemented in hardware
somehow like VHDL in an FGPA and hardware simulation is when a program
implements the functionality of the hardware in a software program no matter
what hardware the hardware simulator is running on. I think I got this now.
Correct? Thanks a bunch for setting me straight.
Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
-----Original Message-----
From: Paul Koning [mailto:paulkoning at comcast.net]
Sent: Thursday, October 26, 2017 4:29 PM
To: Kip Koon; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Which Dec Emulation is the MOST useful and Versatile?
On Oct 24, 2017, at 10:40 PM, Kip Koon via cctalk
<cctalk at classiccmp.org>
wrote:
...
2nd, a hardware emulator running a simulator written in 6809 assembly
language for the PDP-8/e running on a 6809 Core & I/O board system
seems like a good choice for me as I understand the 6809 microprocessor,
...
I would call that a software emulator; the fact that it runs on some
microprocessor eval board doesn't make a difference. Running SIMH on a
Beaglebone would be analogous (though easier).
When you said "hardware emulator" I figured you meant an FPGA implementation
of a VHDL or Verilog model of the machine. There are a bunch of those for a
variety of DEC computers. One I have looked at is this one:
http://pdp2011.sytse.net/wordpress/ which incidentally is also configurable
to implement a choice of PDP11 model.
paul
8:54 a.m.
Kip,
I think "emulation" and "simulation" get used pretty much
interchangeable.
SIMH is touted a simulator, Hercules/390 as an emulator yet they are both
programs that provide a "bare metal" machine via software on which an
operating system can be installed. Neither make any attempt to reproduce the
speed of the original CPU.
I am going to stick with "emulator" as I think of "simulation" as
process
whereby we can model some statistical or mathematical parameters e.g. how
long the queues are in a supermarket, what time is high tide in Boston using
only mathematics. Note this may involve a general purpose computer, or it
may use specialist machines such as the Doodson-Lege Tidal Predictor
http://www.ntslf.org/about-tides/doodson-machine
So to return to emulating other computers have at least five different
flavours...
1. Functional Software Emulation where we match the functions but not the
speed of operation using a program. SIMH and Hercules are such beasts
For much work this is fine. Most software emulators take this approach.
2. Cycle accurate Software Emulation/Simulation where we attempt to match
both function and speed of the underlying hardware. This may be necessary
for software which uses software loops to control say the speed of a UART. I
If you want to use the simulator for historical research this may help. Some
emulators can be switched to this mode when software needs it...
David Sharp's SSEM/Baby simulator is such a beast.
http://www.davidsharp.com/baby/
3. Behavioural Hardware Emulation
This is where we build a hardware implementation of a machine, but do not
attempt to duplicate the exact detail of the logic or its speed of
operation. Richard Stofer's IBM1130 in VHDL is such a project.
He doesn't have it available on the Web (I have a copy and have run it)
There is a Flash video on the IBM1130.org site
4. Cycle Accurate Behavioural Hardware Emulation
This is probably the most common approach to cycle accurate emulations.
Because FPGA's typically run several times faster than the clock on legacy
hardware, and they may contain high level function blocks, e.g. multipliers
its often "relatively easy" to match the instruction times of a legacy CPU
in an FPGA.
My BabyBaby FPGA implementation of the SSEM FPGA is such a beast. It runs at
the same speed as replica SSEM in MSI Manchester but internally it's a
parallel implementation whereas the real Baby is a serial machine.
https://hackaday.com/2016/01/06/babybaby-a-1948-computer-on-an-fpga/
5. Gate Level Hardware Emulation
It gate level hardware emulation we try and re-implement the hardware down
to the logic gate level. This is hard because FPGA's are may not be designed
to work this way, and gate level design will also have some dependencies on
propagation delays, which on an FPGA will be much smaller than on any real
hardware. A couple of examples of these are
Laurence Wilkinson's IBM 360/30 http://www.ljw.me.uk/ibm360/
Carl Claunch's IBM 1130 http://ibm1130.blogspot.co.uk/
I hope this doesn't muddy the water too much...
Dave
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Kip Koon
via cctalk
Sent: 27 October 2017 06:42
To: 'Paul Koning' <paulkoning at comcast.net>; 'General Discussion:
On-Topic
and Off-Topic Posts' <cctalk at classiccmp.org>
Subject: RE: Which Dec Emulation is the MOST useful and Versatile?
Hi Paul,
Thank you for the info. I tend to get emulation and simulation a bit
confused.
Just so I understand simulation correctly, hardware
emulation is when the
functionality of the hardware is actually implemented in hardware somehow
like VHDL in an FGPA and hardware simulation is when a program
implements the functionality of the hardware in a software program no
matter what hardware the hardware simulator is running on. I think I got
this
now.
Correct? Thanks a bunch for setting me straight.
Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
-----Original Message-----
From: Paul Koning [mailto:paulkoning at comcast.net]
Sent: Thursday, October 26, 2017 4:29 PM
To: Kip Koon; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Which Dec Emulation is the MOST useful and Versatile?
> On Oct 24, 2017, at 10:40 PM, Kip Koon via cctalk
<cctalk at
classiccmp.org>
wrote:
a
...
2nd, a hardware emulator running a simulator written in 6809 assembly
language for the PDP-8/e running on a 6809 Core & I/O board system
seems like a good choice for me as I understand the 6809 microprocessor,
...
I would call that a software emulator; the fact that it runs on some
microprocessor eval board doesn't make a difference. Running SIMH on a
Beaglebone would be analogous (though easier).
When you said "hardware emulator" I figured you meant an FPGA
implementation
of a VHDL or Verilog model of the machine. There are a bunch of those for variety of DEC computers. One I have looked at is
this one:
http://pdp2011.sytse.net/wordpress/ which incidentally is also
configurable
to implement a choice of PDP11 model.
paul
3:27 p.m.
On 10/27/2017 3:54 AM, Dave Wade via cctech wrote:
Kip,
I think "emulation" and "simulation" get used pretty much
interchangeable.
SIMH is touted a simulator, Hercules/390 as an emulator yet they are both
programs that provide a "bare metal" machine via software on which an
operating system can be installed. Neither make any attempt to reproduce the
speed of the original CPU.
I am going to stick with "emulator" as I think of "simulation" as
process
whereby we can model some statistical or mathematical parameters e.g. how
long the queues are in a supermarket, what time is high tide in Boston using
only mathematics. Note this may involve a general purpose computer, or it
may use specialist machines such as the Doodson-Lege Tidal Predictor
http://www.ntslf.org/about-tides/doodson-machine
So to return to emulating other computers have at least five different
flavours...
1. Functional Software Emulation where we match the functions but not the
speed of operation using a program. SIMH and Hercules are such beasts
For much work this is fine. Most software emulators take this approach.
2. Cycle accurate Software Emulation/Simulation where we attempt to match
both function and speed of the underlying hardware. This may be necessary
for software which uses software loops to control say the speed of a UART. I
If you want to use the simulator for historical research this may help. Some
emulators can be switched to this mode when software needs it...
David Sharp's SSEM/Baby simulator is such a beast.
http://www.davidsharp.com/baby/
3. Behavioural Hardware Emulation
This is where we build a hardware implementation of a machine, but do not
attempt to duplicate the exact detail of the logic or its speed of
operation. Richard Stofer's IBM1130 in VHDL is such a project.
He doesn't have it available on the Web (I have a copy and have run it)
There is a Flash video on the IBM1130.org site
4. Cycle Accurate Behavioural Hardware Emulation
This is probably the most common approach to cycle accurate emulations.
Because FPGA's typically run several times faster than the clock on legacy
hardware, and they may contain high level function blocks, e.g. multipliers
its often "relatively easy" to match the instruction times of a legacy CPU
in an FPGA.
My BabyBaby FPGA implementation of the SSEM FPGA is such a beast. It runs at
the same speed as replica SSEM in MSI Manchester but internally it's a
parallel implementation whereas the real Baby is a serial machine.
https://hackaday.com/2016/01/06/babybaby-a-1948-computer-on-an-fpga/
5. Gate Level Hardware Emulation
It gate level hardware emulation we try and re-implement the hardware down
to the logic gate level. This is hard because FPGA's are may not be designed
to work this way, and gate level design will also have some dependencies on
propagation delays, which on an FPGA will be much smaller than on any real
hardware. A couple of examples of these are
Laurence Wilkinson's IBM 360/30 http://www.ljw.me.uk/ibm360/
Carl Claunch's IBM 1130 http://ibm1130.blogspot.co.uk/
I hope this doesn't muddy the water too much...
Dave
Well, the waters are sufficiently muddy that I figured little harm would
be dine if I throw my weeds in too... ;)
I like that you have clearly given this some thought, and have developed
a kind of taxonomy, so your comments are valuable because they are not
just off-the cuff.
Looking online at Merriam-Webster, the conclusion one might reach is
that these are all simulators. But emulation is also a term of art when
it comes to computers, so I don't think we should shackle ourselves to M-W.
I have generally used the term emulator for software that attempts to
provide some level of functionality (up to 100%) of the original machine
such that software (including operating systems) will operate, without
worrying about HOW that is done. So, I would throw most, if not all, of
the SimH programs, and Hercules as well into that pot. I would also put
the IBM 1401 and 1410 emulators that appeared on early model IBM
System/360 machines (which was done using software with microcode
assist) into that same bag, as well as the FLEX implementation of the
IBM mainframe architectures. So, I am on the same page with you with
regards to #1.
I have generally used the term simulator for software that attempts to
replicate the actual operation of the original machine, regardless of
speed - I view speed as just one of several possible measures of the
accuracy/level of the simulation. I have written an IBM 1410 simulator
that simulates the operation of the original machine at the machine
cycle level, based on the IBM CE instructional materials - but it pays
no attention at all to the absolute cycle time, only to the relative
cycle time (so that peripherals, such as tape drives, work in about the
same relative speed to the CPU as the original - in order that
diagnostics can be run). [It is convenient that it runs faster than the
original. ;) ].
When it comes to hardware, such as FPGA or other hardware that reproduce
machine behavior, I think the judgement is different. I would agree
with your definition #3, to call these emulations for those
implementations which pay little or no attention to the original
machine. That said, however, I tend to use the word "implementation" or
"model" here. Consider, for example, that the IBM 360 and 370
architecture, and the PDP-11 and VAX architectures were implemented by
their original manufacturers (or their competitors, e.g. Amdahl), using
very different hardware approaches - some hard wired, some micro-coded,
some mixed, for different models of the architecture.
But I can see using the term "simulation" in some cases, such as your
"BabyBaby".
But I would call IBM's P390 an "implementation" of S/390 (and S/370,
depending on which firmware you load).
With respect to your #5, I have some direct experience with that, and am
working on a tricky project to implement the IBM 1410 in a FPGA at the
gate level, based on the SMS Automated Logic Diagrams (ALD's). What I
have found so far is that a rule or two can be used to deal with the
speed and design technology differences. I don't think that the issues
pointed out make it "hard", really. The hard part, to me, is
deciphering the original design from drawings or other incomplete
engineering information. ;) The rules I have developed so far:
a. If the original implementation uses cross-connected gates (or
transistors), the FPGA model can follow those with a synchronous D
flip flop. It usually works because the clock times are often 10
or more times faster or more than the original machine clock. I
have successfully used this technique to implement an original
design that was not all that great (see "b." below for details) that
actually had some race conditions in the original design.
The information on this project can be found at:
https://drive.google.com/open?id=0B2v4WRwISEQRcFpNM0o2VDJiWFk
b. I did not come across delays in the one project I completed
this way (a re-implementation of a design done for a class in
college in 1973), but my next project will, and my plan is to use a
counter (or, I suppose, a small number of cascaded D flip flops
acting as a bucket brigade) in cases where that delay is needed for
the implementation to work properly. (In cases where the delay
exists only to match propagation times along different wire/cable
lengths in the original implementation, one might be able to turn
the delay into a wire).
JRJ
6:46 p.m.
On 10/27/2017 9:27 AM, Jay Jaeger via cctech wrote:
With respect to your #5, I have some direct experience
with that, and am
working on a tricky project to implement the IBM 1410 in a FPGA at the
gate level, based on the SMS Automated Logic Diagrams (ALD's). What I
have found so far is that a rule or two can be used to deal with the
speed and design technology differences. I don't think that the issues
pointed out make it "hard", really. The hard part, to me, is
deciphering the original design from drawings or other incomplete
engineering information. ;) The rules I have developed so far:
a. If the original implementation uses cross-connected gates (or
transistors), the FPGA model can follow those with a synchronous D
flip flop. It usually works because the clock times are often 10
or more times faster or more than the original machine clock. I
have successfully used this technique to implement an original
design that was not all that great (see "b." below for details) that
actually had some race conditions in the original design.
The information on this project can be found at:
https://drive.google.com/open?id=0B2v4WRwISEQRcFpNM0o2VDJiWFk
b. I did not come across delays in the one project I completed
this way (a re-implementation of a design done for a class in
college in 1973), but my next project will, and my plan is to use a
counter (or, I suppose, a small number of cascaded D flip flops
acting as a bucket brigade) in cases where that delay is needed for
the implementation to work properly. (In cases where the delay
exists only to match propagation times along different wire/cable
lengths in the original implementation, one might be able to turn
the delay into a wire).
JRJ
With some FPGA venders you could get a TTL library components,
so you could input older designs. You may have to dig around for them
because that is not a NEW selling feature any more. Also logic
cells don't have asynchronous set and clear anymore.
Ben.
29 Oct
29 Oct
1:55 a.m.
On 10/27/2017 1:46 PM, ben via cctech wrote:
On 10/27/2017 9:27 AM, Jay Jaeger via cctech wrote:
With some FPGA venders you could get a TTL library components,
so you could input older designs. You may have to dig around for them
because that is not a NEW selling feature any more. Also logic
cells don't have asynchronous? set and clear anymore.
Ben.
I suppose, though writing a little HDL to provide the function of a TTL
gate isn't very hard. As it turns out, the design I replicated from my
college days was actually DTL, rather than TTL. The lab consisted of 4
19" racks with interconnecting, differentially driven cables. Each rack
had a card cage, and interconnections were done using re-purposed IBM
unit-record plugboards. The current project, the IBM 1410, was
originally designed using IBM SMS - discrete transistors.
5:33 p.m.
On 10/28/2017 08:55 PM, Jay Jaeger via cctalk wrote:
On 10/27/2017 1:46 PM, ben via cctech wrote:
Xilinx ise package provides a library of hundreds of 74xx
TTL parts in schematic form, with VHDL code to provide the
same functionality. So, you can make up a schematic with
74xx TTL parts, and then it instantiates the VHDL behavioral
description of the part. One could easily extract the VHDL
On 10/27/2017 9:27 AM, Jay Jaeger via cctech
wrote:
With some FPGA venders you could get a TTL library components,
so you could input older designs. You may have to dig around for them
because that is not a NEW selling feature any more. Also logic
cells don't have asynchronous set and clear anymore.
Ben.
I suppose, though writing a little HDL to provide the function of a TTL
gate isn't very hard. from their library.
Jon
27 Oct
27 Oct
5:27 p.m.
On Oct 27, 2017, at 4:54 AM, Dave Wade via cctalk
<cctalk at classiccmp.org> wrote:
Kip,
I think "emulation" and "simulation" get used pretty much
interchangeable.
SIMH is touted a simulator, Hercules/390 as an emulator yet they are both
programs that provide a "bare metal" machine via software on which an
operating system can be installed. Neither make any attempt to reproduce the
speed of the original CPU.
True. And by some argument, an FPGA implementation (from an HDL behavioral model) is also
a software implementation, just written in a different programming language.
Recently I commented to an old colleague that there are many different levels of emulation
possible, and any one of those may make sense -- it's just a question of what
you're after. So you can emulate in a conventional programming language, as SIMH
does, reproducing the programmer-visible behavior of the machine but not its timing. Bugs
from the original might appear if those bugs are known to be important, but probably not
otherwise. This kind is (nowadays) likely to run faster than the original; certainly it
won't usually mimic the original timing, neither for computation nor I/O.
You can make timing-accurate software emulators, with lots of work. SIMH, in paced mode,
and provided the I/O waits are reasonably accurately expressed in units of machine cycles,
isn't quite timing accurate but is somewhat similar.
You can build a behavioral simulator (SIMH style, basically) in an FPGA. That isn't
necessarily any more capable or accurate than a software simulator. PDP-2011 is an
example I know of, and I've see articles about other PDP emulations of this kind.
Since the design is new, created from a behavioral description (data book, functional
spec, architecture spec) it will be about as accurate as SIMH.
You can also, if the data exists, build a lower level (gate level or thereabouts) FPGA
model. Given schematics and wire lists, it should be possible to build an implementation
that's an exact copy of how the original machine worked (assuming of course the
documentation is accurate, which is not necessarily the case). Such an emulation would
replicate strange and undocumented behavior of the original -- and allow you to find out
where that came from. I've been working on such a thing for the CDC 6600, which is
surprisingly hard given that the design lives right on the hairy edge of not working at
all timing-wise. But it does accuarately model the peripheral processors right now, and
indeed it shows and explains some undocumented oddities that are part of that
machine's folklore.
So it's a question of what you're after. If you want to run the software, or
teach the machine at the programmer level, SIMH or equivalent is quite adequate. If you
want to teach FPGA skills, an FPGA behavioral model emulation is a good project,
especially for a small machine like a PDP-8. As for the gate level model, I'm not
sure what argument to make for that other than "paul is a bit crazy" and
"because the data exists to do it". :-)
paul
5:47 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Paul
Koning
via cctalk
Sent: 27 October 2017 18:28
To: Dave Wade <dave.g4ugm at gmail.com>; General Discussion: On-Topic and
Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: Which Dec Emulation is the MOST useful and Versatile?
> On Oct 27, 2017, at 4:54 AM, Dave Wade via cctalk
<cctalk at
classiccmp.org>
wrote:
>
> Kip,
> I think "emulation" and "simulation" get used pretty much
interchangeable.
SIMH is touted
a simulator, Hercules/390 as an emulator yet they are
both programs that provide a "bare metal" machine via software on
which an operating system can be installed. Neither make any attempt
to reproduce the speed of the original CPU.
True. And by some argument, an FPGA implementation (from an HDL
behavioral model) is also a software implementation, just written in a programming language.
Recently I commented to an old colleague that there are many different
levels
of emulation possible, and any one of those may make
sense -- it's just a
question of what you're after. So you can emulate in a conventional
programming language, as SIMH does, reproducing the programmer-visible
behavior of the machine but not its timing. Bugs from the original might
appear if those bugs are known to be important, but probably not
otherwise.
This kind is (nowadays) likely to run faster than the
original; certainly
it won't
usually mimic the original timing, neither for
computation nor I/O.
You can make timing-accurate software emulators, with lots of work. SIMH,
in
paced mode, and provided the I/O waits are reasonably
accurately expressed
in
units of machine cycles, isn't quite timing
accurate but is somewhat
similar.
You can build a behavioral simulator (SIMH style, basically) in an FPGA.
That
isn't necessarily any more capable or accurate
than a software simulator.
PDP-
2011 is an example I know of, and I've see
articles about other PDP
emulations
of this kind. Since the design is new, created from a
behavioral
description
(data book, functional spec, architecture spec) it
will be about as
accurate as
SIMH.
You can also, if the data exists, build a lower level (gate level or
thereabouts)
FPGA model. Given schematics and wire lists, it
should be possible to
build an
implementation that's an exact copy of how the
original machine worked
(assuming of course the documentation is accurate, which is not
necessarily the
case). Such an emulation would replicate strange and
undocumented
behavior
of the original -- and allow you to find out where
that came from. I've
been
working on such a thing for the CDC 6600, which is
surprisingly hard given
that
the design lives right on the hairy edge of not
working at all
timing-wise. But it
does accuarately model the peripheral processors right
now, and indeed it
shows and explains some undocumented oddities that are part of that
machine's folklore.
So it's a question of what you're after. If you want to run the software,
or teach
the machine at the programmer level, SIMH or
equivalent is quite adequate.
If
you want to teach FPGA skills, an FPGA behavioral
model emulation is a
good
project, especially for a small machine like a PDP-8.
As for the gate
level
model, I'm not sure what argument to make for that
other than "paul is a
bit
crazy" and "because the data exists to do
it". :-)
If I had the skill, data and time, I would always go for a gate level model.
However, I do most (sim/em)ulation in SIMH instead, like I have been doing
for MU5 where I lack the data and the time and probably the skill as well,
but I can always acquire the skill, the other two are harder to find.
Regards
Rob
6:28 p.m.
On Oct 27, 2017, at 1:47 PM, Rob Jarratt
<robert.jarratt at ntlworld.com> wrote:
If I had the skill, data and time, I would always go for a gate level model.
However, I do most (sim/em)ulation in SIMH instead, like I have been doing
for MU5 where I lack the data and the time and probably the skill as well,
but I can always acquire the skill, the other two are harder to find.
I've read some VHDL before, but my 6600 gate level model was my first VHDL project.
It's actually quite easy, easier than the level of fluency needed to do a good
behavioral model. A decent textbook helps a lot. My favorite is The Designer's Guide
to VHDL by Peter Ashenden. The point is that modeling small modules (SSI gates, or 6600
"cordwood" modules, or the like) is easy because they are small and have quite
simple behavior. Then it's just a matter of wiring them together.
Note that you don't need an FPGA to do logic level design; all you need is a VHDL
simulator. I use GHDL, which is open source, part of GCC so you can hook in C code if you
need it. For example, that allows you to make a model of the I/O channel and connect it
to a SIMH style emulation of a peripheral device.
The real issue for gate level modeling is the availability of the necessary documentation.
If you have schematics, and they includes critical detail such as microcode ROM contents,
you're all set. If all you have is functional specs, you can't even start.
It helps to have a machine built with sane design principles. Things like RS flops that
don't have both inputs active at the same time. And a properly clocked architecture.
Neither of these properties holds for the CDC 6600...
paul
6:55 p.m.
On 10/27/2017 12:28 PM, Paul Koning via cctalk wrote:
It helps to have a machine built with sane design
principles. Things like RS flops that don't have both inputs active at the same time.
And a properly clocked architecture. Neither of these properties holds for the CDC
6600...
paul
But you can still get TTL for the common stuff,and PAL/GAL chips as
well, so nothing is preventing you from doing the common logic of
the 1965 to 1985 era, if it not for production use.
Ben.
7:06 p.m.
On Oct 27, 2017, at 2:55 PM, ben via cctalk <cctalk
at classiccmp.org> wrote:
On 10/27/2017 12:28 PM, Paul Koning via cctalk wrote:
True if you have a TTL machine. 6600 is discrete transistor, and the actual transistor
specs are nowhere to be found as far as I have been able to tell.
But that doesn't directly relate to gate level emulation. If you have gate level
documentation you can of course build a copy of the machine out of actual gate-type parts,
like 7400 chips. Or you can write a gate level model in VHDL, which is not the most
popular form but certainly perfectly straightforward. Either way, though, you have to
start with a document that shows what the gates are in the original and how they connect.
And to get it to work, you need to deal with timing issues and logic abuse, if present.
In the 6600, both are very present and very critical. For example, I've been
debugging a section (the central processor branch logic) where the behavior changes quite
substantially depending on whether you favor S or R in an R/S flop, i.e., if both are
asserted at the same time, who wins? And the circuit and wire delays matter, down to the
few-nanosecond level.
Most machines are not so crazy; I would assume a PDP-11/20 gate level model would be quite
painless.
paul
It helps to have a machine built with sane design
principles. Things like RS flops that don't have both inputs active at the same time.
And a properly clocked architecture. Neither of these properties holds for the CDC
6600...
paul
But you can still get TTL for the common stuff,and PAL/GAL chips as well, so nothing is
preventing you from doing the common logic of
the 1965 to 1985 era, if it not for production use.
Ben. 
7:16 p.m.
On 10/27/2017 12:06 PM, Paul Koning via cctalk wrote:
But that doesn't directly relate to gate level
emulation. If you
have gate level documentation you can of course build a copy of the
machine out of actual gate-type parts, like 7400 chips. Or you can
write a gate level model in VHDL, which is not the most popular form
but certainly perfectly straightforward. Either way, though, you
have to start with a document that shows what the gates are in the
original and how they connect. And to get it to work, you need to
deal with timing issues and logic abuse, if present. In the 6600,
both are very present and very critical. For example, I've been
debugging a section (the central processor branch logic) where the
behavior changes quite substantially depending on whether you favor S
or R in an R/S flop, i.e., if both are asserted at the same time, who
wins? And the circuit and wire delays matter, down to the
few-nanosecond level.
This. In particular, google for a shot of the 6600 backplane. Many of
those twisted wires were cut to provide specific delays. Remember the
nanosecond-foot? A lot of the old hardware used this in the design.
I've long had a fantasy about building a core-logic CPU such as the
Univac Solid State. But heck if I know where one would get the "hard"
magnetic cores today. Another example of something you can't do with
commodity TTL.
--Chuck
7:21 p.m.
On 10/27/17 12:16 PM, Chuck Guzis via cctalk wrote:
I've long had a fantasy about building a
core-logic CPU such as the
Univac Solid State.
I have been told the behavior of Univac magnetic logic was similar to NMOS
which explains why there is an RF power amplifier for the clock driver in
the machine.
7:57 p.m.
On Oct 27, 2017, at 3:21 PM, Al Kossow via cctalk
<cctalk at classiccmp.org> wrote:
On 10/27/17 12:16 PM, Chuck Guzis via cctalk wrote:
That doesn't sound even close.
Ken Olsen did his thesis on magnetic core logic. There is some (but surprisingly little)
information on line about this technology. There are two flavors: with permanent magnetic
cores (memory cores) and with "soft" cores (transformers). Apollo
"rope" core memory ROM is an example of the former.
paul
I've long had a fantasy about building a
core-logic CPU such as the
Univac Solid State.
I have been told the behavior of Univac magnetic logic was similar to NMOS 
8:38 p.m.
On 2017-Oct-27, at 12:57 PM, Paul Koning via cctalk wrote:
It does seem like a strange statement.
I wonder if they were just trying to draw an analogy between the inherent dynamic
operation requirements of magnetic logic and the dynamic operation requirements of some
(many?) NMOS designs (not really inherent to NMOS).
On Oct 27,
2017, at 3:21 PM, Al Kossow via cctalk <cctalk at classiccmp.org> wrote:
On 10/27/17 12:16 PM, Chuck Guzis via cctalk wrote:
That doesn't sound even close. I've long had a fantasy about building a
core-logic CPU such as the
Univac Solid State.
I have been told the behavior of Univac magnetic logic was similar to NMOS Ken Olsen did his thesis on magnetic core logic.
There is some (but surprisingly little) information on line about this technology. There
are two flavors: with permanent magnetic cores (memory cores) and with "soft"
cores (transformers). Apollo "rope" core memory ROM is an example of the
former.
paul
8:42 p.m.
On 10/27/17 1:38 PM, Brent Hilpert via cctalk wrote:
I wonder if they were just trying to draw an analogy
between the inherent dynamic operation requirements of magnetic logic and the dynamic
operation requirements of some (many?) NMOS designs (not really inherent to NMOS).
this was a long time ago, and it probably was comparing it to multiphase MOS clocking
this came from Mike Albaugh, who had a SS90 at one point.
9 p.m.
On Fri, 2017-10-27 at 13:38 -0700, Brent Hilpert via cctalk wrote:
I wonder if they were just trying to draw an analogy
between the
inherent dynamic operation requirements of magnetic logic and the
dynamic operation requirements of some (many?) NMOS designs (not
really inherent to NMOS).
On the subject of NMOS dynamic logic, someone recently pointed out a
paragraph in the technical manual for a 1990s ARM2-based computer which
warned of dire consequences, including possibly destruction of the
chipset, if the circuitry was left powered with the clock stopped for
more than a second or two.
Obviously if the clock is stopped for more than a few hundred
microseconds then the logic will start to lose its marbles and the
system will need a reset to recover. But I don't think I've previously
heard any suggestion that dynamic logic ICs would actually be damaged
or destroyed under these circumstances. I can just about imagine that
there might be some situation where an invalid internal state would
result in a short circuit between power and ground, but that's just
supposition really. Anybody know of a case where something bad has
actually happened?
p.
9:09 p.m.
On 10/27/17 2:00 PM, Phil Blundell via cctalk wrote:
On the subject of NMOS dynamic logic, someone recently
pointed out a
paragraph in the technical manual for a 1990s ARM2-based computer which
warned of dire consequences, including possibly destruction of the
chipset, if the circuitry was left powered with the clock stopped for
more than a second or two.
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
ARM2 chips were manufactured by VLSI Technology and Sanyo on a 2 ?m double-level metal
CMOS process.
30 Oct
30 Oct
4:43 p.m.
On Oct 27, 2017, at 5:00 PM, Phil Blundell via cctalk
<cctalk at classiccmp.org> wrote:
On Fri, 2017-10-27 at 13:38 -0700, Brent Hilpert via cctalk wrote:
I don't understand this at all. "Dynamic logic" is not a familiar concept,
and certainly the NMOS logic I know isn't dynamic. Memory (DRAM) is dynamic, and will
forget if you don't refresh it. But DRAM doesn't mind if you stop the clock, it
just won't remember its data.
So I don't know how you might have a logic design that "loses its marbles"
if you stop the clock. And anything that is fried by clock loss is, in my view, the work
of someone who should not be allowed anywhere near a EE shop.
Incidentally, while "soft core" magnetic logic is dynamic, memory core logic is
not. You could slow that down and it would still work. The signals are pulses, not
levels, but the pulses will still happen with a 1 Hz clock.
paul
I wonder if they were just trying to draw an
analogy between the
inherent dynamic operation requirements of magnetic logic and the
dynamic operation requirements of some (many?) NMOS designs (not
really inherent to NMOS).
On the subject of NMOS dynamic logic, someone recently pointed out a
paragraph in the technical manual for a 1990s ARM2-based computer which
warned of dire consequences, including possibly destruction of the
chipset, if the circuitry was left powered with the clock stopped for
more than a second or two.
Obviously if the clock is stopped for more than a few hundred
microseconds then the logic will start to lose its marbles and the
system will need a reset to recover. But I don't think I've previously
heard any suggestion that dynamic logic ICs would actually be damaged
or destroyed under these circumstances. I can just about imagine that
there might be some situation where an invalid internal state would
result in a short circuit between power and ground, but that's just
supposition really. Anybody know of a case where something bad has
actually happened?
31 Oct
31 Oct
9:59 p.m.
On 10/30/2017 12:43 PM, Paul Koning via cctalk wrote:
NMOS dynamic logic relies on two things memory or register cells that
operate just like
Dram so they forget without refresh.? It also relies on logic nodes that
precharge to some
state and are selectively discharged by the logic.? Doing that saves
resistive pullups or
complementary logic.? This type of logic has a specified minimum clock
though you
could usually go far slower.? The 8080 was an early example.
On Oct 27,
2017, at 5:00 PM, Phil Blundell via cctalk <cctalk at classiccmp.org> wrote:
On Fri, 2017-10-27 at 13:38 -0700, Brent Hilpert via cctalk wrote:
I don't understand this at all. "Dynamic logic"
is not a familiar concept, and certainly the NMOS logic I know isn't dynamic. Memory
(DRAM) is dynamic, and will forget if you don't refresh it. But DRAM doesn't mind
if you stop the clock, it just won't remember its data.
So I don't know how you might have a logic design that "loses its marbles"
if you stop the clock. And anything that is fried by clock loss is, in my view, the work
of someone who should not be allowed anywhere near a EE shop. I wonder if they were just trying to draw an
analogy between the
inherent dynamic operation requirements of magnetic logic and the
dynamic operation requirements of some (many?) NMOS designs (not
really inherent to NMOS).
On the subject of NMOS dynamic logic, someone recently
pointed out a
paragraph in the technical manual for a 1990s ARM2-based computer which
warned of dire consequences, including possibly destruction of the
chipset, if the circuitry was left powered with the clock stopped for
more than a second or two.
Obviously if the clock is stopped for more than a few hundred
microseconds then the logic will start to lose its marbles and the
system will need a reset to recover. But I don't think I've previously
heard any suggestion that dynamic logic ICs would actually be damaged
or destroyed under these circumstances. I can just about imagine that
there might be some situation where an invalid internal state would
result in a short circuit between power and ground, but that's just
supposition really. Anybody know of a case where something bad has
actually happened? Incidentally, while "soft core" magnetic
logic is dynamic, memory core logic is not. You could slow that down and it would still
work. The signals are pulses, not levels, but the pulses will still happen with a 1 Hz
clock.
The timing of the logic in some cases where tied to the switching time
of the cores used.? Otherwise
it was hard to determine when and if the core switched.
However rope core and ferro-transformers would work at any rate so long
as the pulse waveform was
had the right rise and fall times.??? FYI rope core was basically many
transformers either with a wire
in for the bit or wire around for the not bit.? The cores for rope
didn't change magnetic state like
coincident current cores of the bistable type as that allowed read write
but was DRO (destructive
read out with re-write) which is the more familiar core and why it had a
shorter read time and a
longer cycle time between reads.
Both have a fair amount of documentation out there.? The
ferro-transformer logic were documented
well too but you have to hunt for info.? They also came in many forms as
to the logic performed
including storage.
Allison
paul
1 Nov
1 Nov
12:59 p.m.
On Oct 31, 2017, at 5:59 PM, allison via cctalk
<cctalk at classiccmp.org> wrote:
... FYI rope core was basically many
transformers either with a wire
in for the bit or wire around for the not bit. The cores for rope
didn't change magnetic state like
coincident current cores of the bistable type as that allowed read write
but was DRO (destructive
read out with re-write) which is the more familiar core and why it had a
shorter read time and a
longer cycle time between reads.
Actually, that's not accurate. Core rope memory (Apollo Computer style) does use
memory cores. You can find it described well on a web page by Brent Halpern that
discusses that and other (transformer style) memories. In core rope memory, the selected
core has its state changed by the combined select currents, and then it delivers pulses to
whichever sense lines are threaded through that core when the core is reset again.
The Electrologica X1 has a core ROM that also uses memory cores, but in a different way
than core rope.
paul
27 Oct
27 Oct
8:39 p.m.
On 10/27/17 12:57 PM, Paul Koning wrote:
That doesn't sound even close.
http://www.ussc90.nl/circ.htm
Ferractors.
While computers now are composed by many integrated circuits containing each millions of
logical units,
processing data with a speed of a few gigabits per second in a parallel-flow of 64 bits,
the USSC's CPU-logic was composed of over 1000 circuit boards with each only a few
active components.
One circuitboard contained only 4 simple logical units, the ferractors.
These circuit-boards processed the data with the theoretical speed of 700 KBits/second.
The ferractors were tiny transformers, performing one-bit operations, powered by 700 KCs
AC.
On the positive half of the cycle, the ferractor-core was magnetised or not depending on
the current through the bias-coil,
which made the total magnetic field in the core to exceed the hysteresis-threshold or
not.
In the subsequent negative half-cycle the ferractor showed on the secondairy coil a high
or a low impedance, depending
on whether it had been magnetised or not.
On low-impedance a positif bias-current was generated for the next ferractor-circuit.
Since each ferractor was set in one cycle-half and was read in the next cycle-half, an one
bit-stream of a register was
formed
by 24 ferractors in series, alternatingly fed by opposite phases.
In such a string of ferractor-circuits 12 bits cycled around, 10 bits, a sign and a
space.
The information in the registers was circling around in 4 parallel one-bit-strings.
The data in the registers cycled around with the same speed as the information on the
drum-memory.
The 200 diode-boards were used in OR and in NAND functions, depending on being located in
the positive-phase-circuitry
or the negative-one.
The bias-coil was connected in positive or negative polarity to enforce or to diminish
magnetisation during the first
half-cycle
in order to create normal or inverting logical gates.
9:05 p.m.
On 10/27/2017 01:39 PM, Al Kossow via cctalk wrote:
On 10/27/17 12:57 PM, Paul Koning wrote:
Can't forget Parametrons:
https://www.thocp.net/hardware/parametron.htm
http://museum.ipsj.or.jp/en/heritage/NEAC-1101.html
--Chuck
That doesn't sound even close.
http://www.ussc90.nl/circ.htm
Ferractors.
9:36 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck
Guzis via cctalk
Sent: 27 October 2017 22:06
To: cctalk at classiccmp.org
Subject: Re: Which Dec Emulation is the MOST useful and Versatile?
On 10/27/2017 01:39 PM, Al Kossow via cctalk wrote:
The Elliot 803 used ferrite transformers as logic elements....
https://en.wikipedia.org/wiki/Elliott_803
Dave
On 10/27/17 12:57 PM, Paul Koning wrote:
Can't forget Parametrons:
https://www.thocp.net/hardware/parametron.htm
http://museum.ipsj.or.jp/en/heritage/NEAC-1101.html
--Chuck That doesn't sound even close.
http://www.ussc90.nl/circ.htm
Ferractors.
11:55 p.m.
----- Original Message -----
From: "Chuck Guzis via cctalk" <cctalk at classiccmp.org>
To: <cctalk at classiccmp.org>
Sent: Friday, October 27, 2017 5:05 PM
Subject: Re: Which Dec Emulation is the MOST useful and Versatile?
On 10/27/2017 01:39 PM, Al Kossow via cctalk wrote:
Or Burroughs' core counters (think I still have some somewhere):
https://www.google.com/patents/US3438014
http://www.freepatentsonline.com/2995663.html
m
On 10/27/17 12:57 PM, Paul Koning wrote:
Can't forget Parametrons:
https://www.thocp.net/hardware/parametron.htm
http://museum.ipsj.or.jp/en/heritage/NEAC-1101.html
--Chuck
That doesn't sound even close.
http://www.ussc90.nl/circ.htm
Ferractors.
28 Oct
28 Oct
2:46 a.m.
On 10/27/2017 04:55 PM, Mike Stein via cctalk wrote:
Or Burroughs' core counters (think I still have
some somewhere):
https://www.google.com/patents/US3438014
http://www.freepatentsonline.com/2995663.html
We forget about all of the alternative ways of implementing digital
logic. At one time, magnetic core logic was viewed as being much more
reliable than either tube or transistor logic, although not as fast.
Probably better hardened to radiation, as well.
In some respects, core logic reminds me somewhat of the McCulloch-Pitts
TLU model described in Minsky's book on Computation:
http://www.i-programmer.info/babbages-bag/325-mcculloch-pitts-neural-networ…
--Chuck
27 Oct
27 Oct
9:03 p.m.
On 10/27/2017 1:06 PM, Paul Koning wrote:
True if you have a TTL machine. 6600 is discrete
transistor, and the actual transistor specs are nowhere to be found as far as I have been
able to tell.
Well if you can find one loose, you could allways measure it.
But that doesn't directly relate to gate level
emulation. If you have gate level documentation you can of course build a copy of the
machine out of actual gate-type parts, like 7400 chips. Or you can write a gate level
model in VHDL, which is not the most popular form but certainly perfectly straightforward.
Either way, though, you have to start with a document that shows what the gates are in
the original and how they connect. And to get it to work, you need to deal with timing
issues and logic abuse, if present. In the 6600, both are very present and very critical.
For example, I've been debugging a section (the central processor branch logic) where
the behavior changes quite substantially depending on whether you favor S or R in an R/S
flop, i.e., if both are asserted at the same time, who wins? And the circuit and wire
delays matter, down to the few-nanosecond level.
You need to find a lucky man, for help. You stand here, and look that
way. Yes it works.
Most machines are not so crazy; I would assume a PDP-11/20 gate level model would be
quite painless.
paul
I still have not figured out VHDL yet. Logic that I can figure out, but
how you use the the stupid
logic blocks I can not with all the stupid type defines. What I need is
real reference book, not a DUMMYS GUIDE TO BLA-BLA-BLA.
For my own hobby stuff I am useing WINCPUL and ALTERA's AHDL. There a D
F/F is D flip flop.
Ben.
7:04 p.m.
On 2017-Oct-27, at 11:28 AM, Paul Koning via cctalk wrote:
It helps to have a machine built with sane design
principles. Things like RS flops that don't have both inputs active at the same time.
And a properly clocked architecture. Neither of these properties holds for the CDC
6600...
True of a lot of 50s / 60s / even early-70s logic, designers took a lot of 'electronic
shortcuts' to save components, capacitive coupling for instance being popular.
Flip flops with half-a dozen options of semantically different input types which could be
combined in multiple, so every flip-flop in the system was unique with it's particular
set of (sometimes many) input options.
One logic design I encountered had a type of logic element specifically intended (from
what I could figure) to soak up glitches.
It could take in multiple inputs with edges occurring at slightly skewed times and ensured
that only one slightly-delayed edge would be propagated out.
6:28 p.m.
On 2017-Oct-27, at 10:27 AM, Paul Koning via cctalk wrote:
So it's a question of what you're after. If
you want to run the software, or teach the machine at the programmer level, SIMH or
equivalent is quite adequate. If you want to teach FPGA skills, an FPGA behavioral model
emulation is a good project, especially for a small machine like a PDP-8. As for the gate
level model, I'm not sure what argument to make for that other than "paul is a
bit crazy" and "because the data exists to do it". :-)
I would add that gate/logic level simulations in some instances can be useful if you have
to understand and repair the original hardware.
Back in the 90s I was attempting to repair a 60s-era SSI-based calculator, I
reverse-engineered it but was still stuck with issues of access
to the PC boards, understanding the design, having to hack up the PCB traces or unsolder
(unobtainable) ICs.
I resorted to writing a logic simulator (in a high-level scripting language) and entering
the 'net list' of the reverse-engineered logic to
produce a gate-level simulation.
I could then play around with the simulator, slow the clock to observable rates, monitor
any and multiple points, break connections,
force logic levels, eventually to obtain the same fault as the real hardware.
2587
days inactive
2595
days old
38 comments
16 participants
participants (16)
-
aek＠bitsavers.org -
allisonportable＠gmail.com -
bfranchuk＠jetnet.ab.ca -
bhilpert＠shaw.ca -
billdegnan＠gmail.com -
cclist＠sydex.com -
cctalk＠snarc.net -
computerdoc＠sc.rr.com -
cube1＠charter.net -
dave.g4ugm＠gmail.com -
derschjo＠gmail.com -
elson＠pico-systems.com -
mhs.stein＠gmail.com -
paulkoning＠comcast.net -
pb＠pbcl.net -
robert.jarratt＠ntlworld.com