Yesterday we started disassembling the CRT from the VR12. We picked out the
silicone that attached the metal bezel to the front of the CRT. The exposed
PVA was about 1/8" thick so we picked at the edges to remove as much as
possible. We found that the shield was actually loose and were able to
remo
Getting an old machine like this back to running is always
great news.
It is one less piece of history that is lost.
When the early computer designers made these first OS
for these machines, I don't think they'd been exposed to the
consuming effects of "Moore's Law" yet. Most felt they were
creatin
great news. hope for further success.
On Sun, Aug 2, 2015 at 10:19 AM, Michael Thompson
wrote:
> With a lot of help from Dave Gesswein and Warren Stearns we were able to
> get the MARK12 PDP-12 tape formatting program off a LINCtape and int paper
> tape format. Running it showed that a diode on
Congrats Michael!
"This is the first time in 24 years that an OS has been run on this
system."
Ed# and crew at smecc.org
In a message dated 8/2/2015 7:20:02 A.M. US Mountain Standard Time,
michael.99.thomp...@gmail.com writes:
With a lot of help from Dave Gesswein and Warren S
With a lot of help from Dave Gesswein and Warren Stearns we were able to
get the MARK12 PDP-12 tape formatting program off a LINCtape and int paper
tape format. Running it showed that a diode on the field-0 core stack had
failed during the week making memory in the range of 4000-5000 unusable.
Fort
Some progress on the PDP-12. We borrowed a TU56 tape head from the TU56 in
the warehouse and replaced the broken right head. We reran ran
MAINDEC-12-D3AE-PB PDP-12 TAPE CONTROL TEST, PART 1 OF 2. The diag runs OK,
so at least the timing track in the borrowed tape head is OK.
We reran MAINDEC-12-D3
We received more documentation from the donor last week so we were able to
run the processor LINC instruction tests. The new docs are already scanned
and on Bitsavers. The LINC diags failed, but we quickly found the bad M160
flip-chip and now both LINC diags run OK.
We continued debugging the "LGP
On 07/16/2015 01:12 AM, Dave G4UGM wrote:
Apparently the School of Medicine, Manchester University, England
were given a 7090 which they later connected to a PDP-8. A bit of
googling turned this up :-
http://www.ukuug.org/newsletter/linux-newsletter/linux@uk12/dclark.shtml
Nice article. Many
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jay Jaeger
> Sent: 16 July 2015 01:56
> To: cctalk@classiccmp.org
> Subject: Re: Reproducing old machines with newer technology (Re: PDP-12 at
> the RICM)
>
> Saul is indeed
This brings up a good point: just because a D Flip Flop is clocked by
something other than a system-wide (or subsystem-wide) clock does not
turn it into a latch. Flip flops can clocked by combinatorial inputs.
This can be a problematic thing of course, as they can cause glitch
problems - had a co
On 07/15/2015 01:24 PM, Noel Chiappa wrote:
> On 7/14/2015 7:36 PM, Jon Elson wrote:
> On the system 360 CPUs, they did not use flip-flops like we are used
> to, today. They used latches ... Since these were discrete transistor
> implementations, a real flip-flop was too expe
Saul is indeed cited in the ACM article,
http://dl.acm.org/citation.cfm?id=365671
I know that Purdue had some folks that did their own maintenance, and
sure, by the late 1960's one could certain pick them up cheap - the gold
scrappers were not quite the issue they became later. I know this
becau
On 07/15/2015 04:05 PM, Jay Jaeger wrote:
Paul adapted PUFFT (Purdue University Fast FORTRAN Translator) to do
RS-232 bit serial I/O through a sense switch, and I wrote a spooling
program that ran on a Datacraft 6024 located in the same room to do the
card reading and printing. I suppose somewh
On 7/15/2015 4:45 PM, Chuck Guzis wrote:
> On 07/15/2015 01:49 PM, Jay Jaeger wrote:
>> That would certainly be closer than any of the other examples that have
>> been thrown in the discussion. But it, of course, is much newer than
>> the 1400 series. IIRC, the discussion started when someone su
On 7/15/2015 3:54 PM, Chuck Guzis wrote:
On 07/15/2015 01:30 PM, ben wrote:
Quick look on the web ... ARG! Max segment length 64K something.
Well, even in the late 70s, 64KB was still a goodly chunk of memory in
the microprocessor world. Which reminds me...
To bore you with another STAR tal
On 07/15/2015 01:30 PM, ben wrote:
Quick look on the web ... ARG! Max segment length 64K something.
Well, even in the late 70s, 64KB was still a goodly chunk of memory in
the microprocessor world. Which reminds me...
To bore you with another STAR tale--the machine had two page sizes--the
On 07/15/2015 01:49 PM, Jay Jaeger wrote:
That would certainly be closer than any of the other examples that have
been thrown in the discussion. But it, of course, is much newer than
the 1400 series. IIRC, the discussion started when someone suggested
that there were quite a few machines that w
On 7/15/15 10:28 AM, Noel Chiappa wrote:
Speaking of lights for feedback, anyone remember the 'run bar' - or whatever
they called it, my memory fails me - on the display on the Lisp Machines?
Actually, it was a series, IIRC - one for the CPU, one for the disk, etc. The
machine didn't have LEDs,
That would certainly be closer than any of the other examples that have
been thrown in the discussion. But it, of course, is much newer than
the 1400 series. IIRC, the discussion started when someone suggested
that there were quite a few machines that were similar to the 1400
series in terms of v
On 7/15/2015 1:42 PM, Chuck Guzis wrote:
On 07/15/2015 11:29 AM, Jay Jaeger wrote:
Sigh. Again, the difference is between how OPERANDS were formatted vs.
INSTRUCTIONS. As I said, I agree that lots of machines had variable
length operands (including a couple at the bit level, which the 1400
ser
On 07/15/2015 11:29 AM, Jay Jaeger wrote:
Sigh. Again, the difference is between how OPERANDS were formatted vs.
INSTRUCTIONS. As I said, I agree that lots of machines had variable
length operands (including a couple at the bit level, which the 1400
series did not do except for an individual ch
> On Jul 15, 2015, at 2:14 PM, Chuck Guzis wrote:
>
> On 07/15/2015 10:48 AM, Jay Jaeger wrote:
>> Lots of machines supported variable length operands (like the machine
>> you reference in the link, IBM S/360, Burroughs, etc. etc. However,
>> machines with variable length instructions not split
Catalog of programs revealed the emulator you referred to:
1620-13.0.016 (also 160-13.0.018)
141 Data Processing System - An educational Computer for Instruction in
Basic Programming.
http://www.bitsavers.org/pdf/ibm/1620/GC20-1603-10_1620_Catalog_of_Programs_Jan71.pdf
JRJ
On 7/15/2015
Sigh. Again, the difference is between how OPERANDS were formatted vs.
INSTRUCTIONS. As I said, I agree that lots of machines had variable
length operands (including a couple at the bit level, which the 1400
series did not do except for an individual character). But darn few had
variable length
> On 7/14/2015 7:36 PM, Jon Elson wrote:
> On the system 360 CPUs, they did not use flip-flops like we are used
> to, today. They used latches ... Since these were discrete transistor
> implementations, a real flip-flop was too expensive, but a latch could
> be implemented in a
On Wed, 15 Jul 2015, Chuck Guzis wrote:
FWIW, Dijkstra disliked the 1620 immensely. I don't recall his opinion of
the 1401.
There was a somewhat minimal 1401 emulator that could be run on the 1620
On 07/15/2015 10:48 AM, Jay Jaeger wrote:
Lots of machines supported variable length operands (like the machine
you reference in the link, IBM S/360, Burroughs, etc. etc. However,
machines with variable length instructions not split into any kind of
word boundary are not as common.
Sure, but t
I remember when U Wisconsin ECE got their PDP-11/20 and I saw DOS
FORTRAN get stuck for the very first time. I told the more senior
student who was responsible for getting things going, preparing
documentation, etc. that the machine was in a loop, and never coming
out. He laughed at me, claiming
r technology (Re: PDP-12 at
> the RICM)
>
> On 07/15/2015 10:35 AM, Paul Koning wrote:
>
>
> > Then there was the very occasional early machine with no lights at all
> > — the CDC 6000 series is the one I can think of. But there you had
> > the real time c
1440s and 1460s were architecturally 1401s (much as the 7010 is
architecturally a 1410 - software compatible). I have not heard of a
1450 anywhere, but seem to recall hearing about at least one 1460 and
see photos of them online.
On 7/15/2015 12:26 AM, William Donzelli wrote:
>> In the 7000 seri
On 07/15/2015 10:35 AM, Paul Koning wrote:
Then there was the very occasional early machine with no lights at
all — the CDC 6000 series is the one I can think of. But there you
had the real time console status display, which was even better —
updated just as fast but with a whole lot more info
I suggest that this is really somewhere in between, but MUCH closer to
the "original design" than to "if you design a circuit for an FPGA".
After all, in an FPGA, the original SMS cards from the IBM 1400/7000
series would not be present - so in that sense, nothing is really taking
the original desi
Lots of machines supported variable length operands (like the machine
you reference in the link, IBM S/360, Burroughs, etc. etc. However,
machines with variable length instructions not split into any kind of
word boundary are not as common.
This isn't about whether a machine was good or bad / wor
The 8086 had four segment registers:
. . .
That certainly sounds reasonable, but,
have you noticed the difference in behavior of 8086/8088 V 80386?
Haven't. The SDM covers Pentium forward (and even then it attempts to
document the differences between the different models). I think
anythin
> On Jul 15, 2015, at 1:28 PM, Noel Chiappa wrote:
>
>> From: Sean Caron
>
>> Many examples of blinkenlights eye candy throughout computer history
>
> It wasn't _just_ eye candy; it was a real help in problem debugging (when the
> machine was stopped), and you could tell a lot about what the m
> From: Sean Caron
> Many examples of blinkenlights eye candy throughout computer history
It wasn't _just_ eye candy; it was a real help in problem debugging (when the
machine was stopped), and you could tell a lot about what the machine was
doing (when it was running) from the way the li
> 1450 and 1460 came even later...but I have never seen evidence of any
> of these actually being installed.
Oops, replace 1460 with 1420. 1460 did exist in reasonable numbers.
--
Will
I think a lot of things drive the popularity of the PDP-8 from nostalgia to
historicity to perhaps the relative simplicity of the CPU to understand as
a design example in computer architecture ... IMO the machine is just a bit
too limited to be much fun to program in assembly ... although maybe som
> In the 7000 series, the 1410 equivalent was the 7010 - architecturally
> compatible, ran the same software, but implemented in 7000 series
> technology. It came along in 1962. So that was really the last one to
> be introduced of its ilk.
>
> Other than clones and the like (e.g., from folks lik
As well, some early microprocessors used multiple clocks i.e. the TMS9900.
Best,
Sean
On Tue, Jul 14, 2015 at 8:04 PM, Eric Smith wrote:
> On Tue, Jul 14, 2015 at 3:28 PM, tony duell
> wrote:
> > If you mean 6 different clock sources (i.e. clocks delayed from each
> other, etc) then that
> >
That's an interesting argument against using FPGAs in this sort of
application; definitely food for thought. That said, from my (admittedly
limited hobbyist and academic exposure) to FPGAs, I would expect the bulk
of of whatever's being implemented would be fairly device-agnostic ...
certainly you
> > My experience of FPGAs is that if you design a circuit for an FPGA it will
> > work. If you take an existing design
> > feed it into a schematic capture program and compile it for an FPGA then it
> > won't.
>
> Actually, you can, and I have done so - provided that the original
> machine was
On 7/14/15 9:53 PM, Fred Cisin wrote:
The 8086 had four segment registers:
CS- Code segment, used with IP register
DS- Data segment
SS- Stack segment, used with SP and BP registers
ES- Extra segment, used with DI for string instructions as
destination
On 07/14/2015 09:16 PM, Jay Jaeger wrote:
Other than clones and the like (e.g., from folks like Honeywell), I'm
not aware of any other machines with a similar architecture to the 1401
and 1410. Name them?
Well, how about a bit-addressable, variable field length machine that
had not only your
On 7/14/2015 10:22 PM, Fred Cisin wrote:
The 8086 had four segment registers:
CS- Code segment, used with IP register
DS- Data segment
SS- Stack segment, used with SP and BP registers
ES- Extra segment, used with DI for string instructions as
destination
The 8086 had four segment registers:
CS- Code segment, used with IP register
DS- Data segment
SS- Stack segment, used with SP and BP registers
ES- Extra segment, used with DI for string instructions as
destination (DS:SI as source)
You could override ins
On 7/14/15 9:22 PM, Fred Cisin wrote:
The 8086 had four segment registers:
CS- Code segment, used with IP register
DS- Data segment
SS- Stack segment, used with SP and BP registers
ES- Extra segment, used with DI for string instructions as
destination
The 8086 had four segment registers:
CS - Code segment, used with IP register
DS - Data segment
SS - Stack segment, used with SP and BP registers
ES - Extra segment, used with DI for string instructions as
destination (DS:SI as
Yes, the S/360 had packed decimal - but much more limited in length, and
no wordmark concept.
The 7070 and 7080 were contemporary with the 1410, not after it. They
did not follow it. While data representations were somewhat similar,
the instruction formats were very different.
he 7080 (which ap
>Johnny Billquist wrote:
>On 2015-07-14 19:52, Noel Chiappa wrote:
> On Jul 13, 2015, at 8:52 PM, Johnny Billquist update.uu.se> wrote:
> ??? What segments??? The PDP-11 have a plain simple page
table. No
> segments anywhere in sight. And each page is 8K.
I know the processo
On 07/14/2015 09:42 PM, ben wrote:
I guessing ( no schematic handy) that they made the 360
register file
easy to decode and build with latches.
Not just the register file, but the entire machine. So, all
the hidden registers in the RTL description,
such as storage address register, stor
On 07/14/2015 06:55 PM, Jay Jaeger wrote:
Architecturally, it was pretty much the last of its kind: the last of
the BCD decimal arithmetic machines, which also makes it interesting.
It has also become much more obscure than the 1401, which it followed,
because not nearly as many were made and so
On 7/14/2015 7:36 PM, Jon Elson wrote:
On 07/14/2015 07:44 PM, William Donzelli wrote:
IIRC, the KB11 processors used in the DEC 11/45 and 11/70 (and other
related systems) used five "clocks delayed from each other" (more
commonly known as clock phases).
IBM used this method as well on many of
On 2015-07-15 03:13, Noel Chiappa wrote:
> From: Johnny Billquist
> While the pages are variable in length, each page starts at an 8K
> virtual address boundary.
Which is another difference between PDP-11 'pages', and real pages as used on
every other machine of the period which
On 7/14/2015 11:16 AM, ben wrote:
>
> Here is the link you have been waiting for, IBM 1130 in FPGA and in the
> FLESH.
> http://ibm1130.blogspot.ca/
>
> Ben.
Thanks for that link. It looks very interesting after a quick glance. I
am sure that I will run into many of the same issues with the SMS
Meh. You take your machines and I'll take mine. :) The IBM 1410 is a
machine I know well, so I know how it is supposed to work, and I have
detailed information in the form of the ALD's and the CE training
materials to go with it, plus software including diagnostics and
operational software I can
On 7/14/2015 7:31 PM, Chuck Guzis wrote:
Seymour Cray should have used kinetic sculptures on his machines as part
of eye candy, I guess. Or maybe more chrome...
You got a nice love seat. I could see a early cray style maching in a FPGA
but what good is number crunching if you don't have the me
On 07/14/2015 07:44 PM, William Donzelli wrote:
IIRC, the KB11 processors used in the DEC 11/45 and 11/70 (and other
related systems) used five "clocks delayed from each other" (more
commonly known as clock phases).
IBM used this method as well on many of their machines.
On the system 360 CPUs,
On 07/14/2015 04:49 PM, Jay Jaeger wrote:
Not necessarily. For example, it is impossible to find an IBM 1410, as
far as I know. But there ARE 1415 consoles I knew of a while back, and
there are certainly 729s and 1403 printers and 1402 card read/punch
units up and running.
There are plenty o
> From: Johnny Billquist
> While the pages are variable in length, each page starts at an 8K
> virtual address boundary.
Which is another difference between PDP-11 'pages', and real pages as used on
every other machine of the period which had virtual memory: normally, page
sizes were
The 12-bit computer that I "translated" originally had *independent* 1
micro-second clocks in each of four racks. The processor derived a 3
micro-second clock from that, but also a second clock that was out of
phase with the CPU master clock, used to sync. signals coming in from
the other racks (w
> IIRC, the KB11 processors used in the DEC 11/45 and 11/70 (and other
> related systems) used five "clocks delayed from each other" (more
> commonly known as clock phases).
IBM used this method as well on many of their machines.
--
Will
On Tue, Jul 14, 2015 at 3:28 PM, tony duell wrote:
> If you mean 6 different clock sources (i.e. clocks delayed from each other,
> etc) then that
> is not typical of a 1970s minicomputer in my experience.
IIRC, the KB11 processors used in the DEC 11/45 and 11/70 (and other
related systems) used
Sometimes it is fun to be a relative expert on an obscure branch of
knowledge that few people are even aware of.
I worked on one when I was a student, as an operator, programmer and
systems programmer. Tweaked its FORTRAN compiler to spit out text error
messages instead of just error codes. The
On 7/14/2015 2:56 PM, tony duell wrote:
>>
>> I would modify that: if you take an existing design created by someone who
>> doesn’t think about delay
>> differences, then the FPGA version won’t work. Consider the 6600: at the
>> speeds involved, you can’t
>> design in that sloppy fashion. S
On 7/14/2015 2:27 PM, tony duell wrote:
>
>> That sounds like a bug in the original. If you have a set of flops clocked
>> by some signal, and it matters that the
>> outputs don’t all change at the same time, then the original wasn’t reliable
>> either.
>
> It is very poor design, and not s
> On Jul 14, 2015, at 7:40 PM, Jay Jaeger wrote:
>
> On 7/14/2015 11:27 AM, Paul Koning wrote:
>> ...
>
>>>
>>> 3) Flip flops which are clocked from combinatorial signals. These tend
>>> to cause timing/glitch issues. For example, in one case the
>>> combinatorial output was a zero-check on
On 7/14/2015 12:17 PM, Chuck Guzis wrote:
> I'm missing something in this discussion, I think.
>
> HDL's (take your pick) are just programming languages like FORTRAN or C
> with different constraints. What's the point of going to all the
> trouble of doing an FPGA implementation of a slow old a
On 7/14/2015 11:27 AM, Paul Koning wrote:
>
>> On Jul 14, 2015, at 11:46 AM, Jay Jaeger wrote:
>>
>> ...
>> Using the structural / gate level techniques, one does run into some
>> issues, most of which have (or will probably have) solutions:
>>
>> 1) R/S latches composed of gates in a combinator
> The 1130 is more modern than the machines I am interested in. While
> there are still several 1401's our there in the wild I am aware of no
> IBM 1410's anywhere, unless IBM has one squirreled away somewhere.
OK, I am curious. Why the love for the 1410?
I do not know of any, either.
--
Will
> On Jul 14, 2015, at 4:41 PM, Chuck Guzis wrote:
>
> On 07/14/2015 10:29 AM, Paul Koning wrote:
>
>> The accuracy of the FPGA depends on the approach. If it’s a
>> structural (gate level) model, it is as accurate as the schematics
>> you’re working from. And as I mentioned, that accuracy is
The reason I choose to use VHDL (or Verilog), both of which really *are*
IEEE standards: future portability and broadness of access across
multiple manufacturer's devices in the future, and compatibility with
logic simulators.
The 1130 is more modern than the machines I am interested in. While
t
On 2015-07-15 01:02, Sean Conner wrote:
It was thus said that the Great Johnny Billquist once stated:
Yeah. Segment is something I usually associate with the solution done in
the 8086 family, where you essentially have a segment register which
gives the base, and then you work from there. Essen
It was thus said that the Great Johnny Billquist once stated:
>
> Yeah. Segment is something I usually associate with the solution done in
> the 8086 family, where you essentially have a segment register which
> gives the base, and then you work from there. Essentially all memory is
> one chunk
On 2015-07-14 19:52, Noel Chiappa wrote:
> On Jul 13, 2015, at 8:52 PM, Johnny Billquist
wrote:
> ??? What segments??? The PDP-11 have a plain simple page table. No
> segments anywhere in sight. And each page is 8K.
I know the processor handbook calls them 'pages', but I can't
On 2015-07-14 16:09, Paul Koning wrote:
On Jul 13, 2015, at 8:52 PM, Johnny Billquist wrote:
On 2015-07-13 21:16, Rich Alderson wrote:
...
[2] With memory management, 18 or 22, in 16-bit segments. Late models could
use separate instruction and data segments, for a total of 128KB in
> > However, such designs are very few and far between. I will guess that if
> > you took just about any of the
> > discrete transistor or TTL-baased minis or desktops and fed the design
> > straight into an FPGA compiler then
> > it will not work.
>
> What machines were you thinking of?
I wou
On 7/14/2015 1:56 PM, tony duell wrote:
You are, of course, absolutely correct...
However, such designs are very few and far between. I will guess that if you
took just about any of the
discrete transistor or TTL-baased minis or desktops and fed the design straight
into an FPGA compiler then
On 07/14/2015 10:29 AM, Paul Koning wrote:
The accuracy of the FPGA depends on the approach. If it’s a
structural (gate level) model, it is as accurate as the schematics
you’re working from. And as I mentioned, that accuracy is quite
good; it lets you see obscure details that are not documente
>
> I would modify that: if you take an existing design created by someone who
> doesn’t think about delay
> differences, then the FPGA version won’t work. Consider the 6600: at the
> speeds involved, you can’t
> design in that sloppy fashion. So there are multi phase clocks everywhere,
> w
> On Jul 14, 2015, at 3:27 PM, tony duell wrote:
>
>
>> That sounds like a bug in the original. If you have a set of flops clocked
>> by some signal, and it matters that the
>> outputs don’t all change at the same time, then the original wasn’t reliable
>> either.
>
> It is very poor desig
> That sounds like a bug in the original. If you have a set of flops clocked
> by some signal, and it matters that the
> outputs don’t all change at the same time, then the original wasn’t reliable
> either.
It is very poor design, and not something that I would do, but it certainly was
done
On 07/14/2015 11:14 AM, Alan Hightower wrote:
Determinism. Unless you run your software simulator bare-metal - which
most aren't - cycle accuracy is always a race. Before you say modern
processors are 100,000 times faster than emulated ones - so just spin
wait until the next virtual time tick,
Determinism. Unless you run your software simulator bare-metal - which
most aren't - cycle accuracy is always a race. Before you say modern
processors are 100,000 times faster than emulated ones - so just spin
wait until the next virtual time tick, that is always a moving ratio or
opportunity fo
On 07/14/2015 10:35 AM, ben wrote:
I've run the Cyber emulator as well as various SIMH emulators from time
to time, but it's just not the same as the real thing--it's not even
remotely the same.
You can still the old computer blinking lights movie props.
On a Cyber? What blinking lights? P
> On Jul 13, 2015, at 8:52 PM, Johnny Billquist wrote:
> ??? What segments??? The PDP-11 have a plain simple page table. No
> segments anywhere in sight. And each page is 8K.
I know the processor handbook calls them 'pages', but I can't think of any
other machine where pages are vari
On 7/14/2015 11:17 AM, Chuck Guzis wrote:
I'm missing something in this discussion, I think.
HDL's (take your pick) are just programming languages like FORTRAN or C
with different constraints. What's the point of going to all the
trouble of doing an FPGA implementation of a slow old architectur
echnology (Re: PDP-12 at
> the RICM)
>
> I'm missing something in this discussion, I think.
>
> HDL's (take your pick) are just programming languages like FORTRAN or C
> with different constraints. What's the point of going to all the trouble of
> doing an FP
> On Jul 14, 2015, at 1:17 PM, Chuck Guzis wrote:
>
> I'm missing something in this discussion, I think.
>
> HDL's (take your pick) are just programming languages like FORTRAN or C with
> different constraints. What's the point of going to all the trouble of doing
> an FPGA implementation of
I'm missing something in this discussion, I think.
HDL's (take your pick) are just programming languages like FORTRAN or C
with different constraints. What's the point of going to all the
trouble of doing an FPGA implementation of a slow old architecture, when
pretty much the same result coul
On 7/14/2015 10:29 AM, Paul Koning wrote:
On Jul 14, 2015, at 12:23 PM, ben wrote:
On 7/13/2015 10:02 AM, Paul Koning wrote:
A different approach is to reproduce the actual logic design.
FPGAs can be fed gate level models, though that’s not the most
common practice as I understand it. But
> On Jul 14, 2015, at 12:23 PM, ben wrote:
>
> On 7/13/2015 10:02 AM, Paul Koning wrote:
>
>> A different approach is to reproduce the actual logic design. FPGAs
>> can be fed gate level models, though that’s not the most common
>> practice as I understand it. But if you have access to that l
> On Jul 14, 2015, at 11:46 AM, Jay Jaeger wrote:
>
> ...
> Using the structural / gate level techniques, one does run into some
> issues, most of which have (or will probably have) solutions:
>
> 1) R/S latches composed of gates in a combinatorial loop. The problems
> this causes are several
On 7/13/2015 10:02 AM, Paul Koning wrote:
A different approach is to reproduce the actual logic design. FPGAs
can be fed gate level models, though that’s not the most common
practice as I understand it. But if you have access to that level
of original design data, the result can be quite accur
On 7/14/2015 9:46 AM, Jay Jaeger wrote:
My work has been using structural models, at the gate level, in VHDL
(Verilog would be fine, too, of course). Individual components (for
example, a piece of an IBM SMS card, or in my existing case, gates made
available to student engineers that were actual
15 4:20 AM, ANDY HOLT wrote:
>>>>>
> - Original Message -
> From: "Dave G4UGM"
> To: "General Discussion: On-Topic and Off-Topic Posts"
> Sent: Tuesday, 14 July, 2015 8:58:09 AM
> Subject: RE: Reproducing old machines with newer techn
ning
>> Sent: 13 July 2015 17:03
>> To: General Discussion: On-Topic Posts
>> Subject: Re: Reproducing old machines with newer technology (Re: PDP-12 at
>> the RICM)
>>
>>
>>> On Jul 13, 2015, at 8:35 AM, Jay Jaeger wrote:
>>>
>>> A
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of ANDY HOLT
> Sent: 14 July 2015 10:20
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: Reproducing old machines with newer technology (Re: PDP-1
> On Jul 13, 2015, at 8:52 PM, Johnny Billquist wrote:
>
> On 2015-07-13 21:16, Rich Alderson wrote:
>> ...
>
>> [2] With memory management, 18 or 22, in 16-bit segments. Late models could
>> use separate instruction and data segments, for a total of 128KB in use
>> at
>> one time.
>
Seconded; I was just leafing through "A DEC view of hardware systems
design" again last week and I had noticed that footnote and was wondering
myself ... the PDP-3 must be the rarest of them all :O I wonder if there
are any surviving leftovers?
Best,
Sean
On Tue, Jul 14, 2015 at 1:04 AM, Paul A
1 - 100 of 131 matches
Mail list logo
