> On Jul 19, 2015, at 12:06 AM, Mike Stein wrote:
>
> ...
> I always wondered which was more efficient, multiplexing among essentially
> complete 'computers per user' sharing a common I/O 'channel' or swapping
> processes and memory banks…
If you’re talking about switching a single resource (
On Wed, Jul 15, 2015 at 7:05 AM, Jay Jaeger wrote:
> ...though I have not actually checked. The B5000 had IO processors as well.
Not quite, the B5000 and B5500 arguably had DMA channels (up to 4 of
them), but not independent IO processors (with their own machine code)
that were seen on the later
On 07/18/2015 09:06 PM, Mike Stein wrote:
I always wondered which was more efficient, multiplexing among
essentially complete 'computers per user' sharing a common I/O 'channel'
or swapping processes and memory banks...
Well, the multiplexing (via hardware) memory among a single processor
did
On 7/18/2015 10:06 PM, Mike Stein wrote:
I always wondered which was more efficient, multiplexing among
essentially complete 'computers per user' sharing a common I/O 'channel'
or swapping processes and memory banks...
m
I can't think of any system for the average user that runs
efficient.
Be
- Original Message -
From: "Chuck Guzis"
To: ;
"discuss...@classiccmp.org:On-Topic and Off-Topic
Posts"
Sent: Friday, July 17, 2015 12:21 PM
Subject: Re: Reproducing old machines with newer
technology
On 07/16/2015 11:45 AM, Mike Stein wrote:
Not the same
> That wasn't all that uncommon in the microprocessor world--once the
> price dropped sufficiently, doing multiuser applications by giving each
> user their own CPU was practical. Molecular was another outfit that did
> practically the same thing.
>
> Dual-CPU setups, where the "weaker" of the t
On 07/16/2015 11:45 AM, Mike Stein wrote:
Not the same thing of course but remotely on-topic, and I never miss an
opportunity to put in a plug for Cromemco:
By comparison, Cromemco used semi-autonomous 4MHz Z80A SBCs for their
I/O processors, with 16KB of local RAM and up to 32KB of ROM;
commu
- Original Message -
From: "Chuck Guzis"
To: ;
"discuss...@classiccmp.org:On-Topic and Off-Topic
Posts"
Sent: Tuesday, July 14, 2015 5:47 PM
Subject: Re: Reproducing old machines with newer
technology
On 07/14/2015 02:05 PM, Jay Jaeger wrote:
Going all the
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
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
> Guzis
> Sent: 15 July 2015 19:03
> To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and Off-
> Topic Posts
> Subject: Re: Reproducing old machines with newe
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
> 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
On 07/15/2015 07:16 AM, Paul Koning wrote:
I just found it, in the old (rev B) version of the System
Programmer’s Instant. It’s the 6411/6414 “Augmented I/O Buffer and
Controller”. And yes, it has its own ECS instructions, which use
what would normally be NOP opcodes. Interesting, given that
Two sets of ALDs survive at CHM. There was someone working on a simulator who
was retyping the
diagnostics, but I haven't heard anything about that in a LONG time (2011-2012)
On 7/14/15 4:47 PM, Eric Smith wrote:
On Tue, Jul 14, 2015 at 9:58 AM, Jay Jaeger wrote:
I wonder if there is anywhere
> On Jul 14, 2015, at 11:36 PM, Chuck Guzis wrote:
>
> On 07/14/2015 07:11 PM, William Donzelli wrote:
>>> I suppose you could view it that way. There were CPU-less 6000 boxes, but
>>> no PPU-less ones.
>>
>> Were the CPU-less 6000 boxes at least connected to "normal" 6000s with
>> CPUs using
> 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
> >
On Tue, Jul 14, 2015 at 9:58 AM, Jay Jaeger wrote:
> I wonder if there is anywhere near enough information available to do a
> Stretch.
There's enough information to develop a architecturally equivalent
system, either in software or hardware, but AFAIK not anywhere near
enough to build a microarc
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
> yes, but the only software that survives are diagnostic listings.
> I tried and gave up trying to get the software from the person who saved the
> Livermore Stretch
Is he a typical "hoarder"? He can do a better job saving the stuff
than a museum?
--
Will
yes, but the only software that survives are diagnostic listings.
I tried and gave up trying to get the software from the person who saved
the Livermore Stretch
On 7/14/15 8:58 AM, Jay Jaeger wrote:
I wonder if there is anywhere near enough information available to do a
Stretch.
JRJ
On 7/14/
I have a document that describes how to convert 709 Fortran to
7090-compatible Fortran. Might help imply what you'd need generally when
compared to a 709, using that as a starting point.
On Tue, Jul 14, 2015 at 12:21 PM, Al Kossow wrote:
> yes, but the only software that survives are diagnostic
Buchholz's 'Planning a Computer System: Project Stretch' is a good start,
but I'd be interested in hearing about any other technical sources that
folks know about. -C
amturing.acm.org/Buchholz_102636426.pdf
On Tue, Jul 14, 2015 at 10:58 AM, Jay Jaeger wrote:
> I wonder if there is anywhere near
I wonder if there is anywhere near enough information available to do a
Stretch.
JRJ
On 7/14/2015 6:53 AM, Noel Chiappa wrote:
> > From: Jay Jaeger
>
> > I am going to attempt to do the same for IBM's 1410 computer - a really
> > big effort.
>
> Now, the IBM machine you (or someone)
> > 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 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
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
On 07/14/2015 07:11 PM, William Donzelli wrote:
I suppose you could view it that way. There were CPU-less 6000 boxes, but
no PPU-less ones.
Were the CPU-less 6000 boxes at least connected to "normal" 6000s with
CPUs using shared ECS, or could they really be completely independent
units using t
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
> I suppose you could view it that way. There were CPU-less 6000 boxes, but
> no PPU-less ones.
Were the CPU-less 6000 boxes at least connected to "normal" 6000s with
CPUs using shared ECS, or could they really be completely independent
units using their own ECS?
--
Will
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 06:10 PM, Jay Jaeger wrote:
Almost sounds like the CPU was kind of an "attached processor" - similar
to the way vector processors have been implemented by IBM and others.
I suppose you could view it that way. There were CPU-less 6000 boxes,
but no PPU-less ones.
--Chuck
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
Almost sounds like the CPU was kind of an "attached processor" - similar
to the way vector processors have been implemented by IBM and others.
On 7/14/2015 5:28 PM, Chuck Guzis wrote:
> On 07/14/2015 02:53 PM, William Donzelli wrote:
>>> Again, you're missing the point.
>>
>> This was a fairly spe
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 07/14/2015 03:42 PM, William Donzelli wrote:
That's true--but at the time, CDC's design made a huge amount of sense. The
CPU was left to do what it did best--crunch numbers without the burden of
managing the I/O activity and responding to interrupts. In that sense, the
CPU was treated as mor
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
> That's true--but at the time, CDC's design made a huge amount of sense. The
> CPU was left to do what it did best--crunch numbers without the burden of
> managing the I/O activity and responding to interrupts. In that sense, the
> CPU was treated as more of a peripheral device. In fact, you co
On 07/14/2015 02:53 PM, William Donzelli wrote:
Again, you're missing the point.
This was a fairly specific CDC Cyber thing - not a widely adopted idea
in the industry, as was originally asked for.
The channel controller/director idea, on the other hand, was very
widely adopted.
That's true-
> Again, you're missing the point.
This was a fairly specific CDC Cyber thing - not a widely adopted idea
in the industry, as was originally asked for.
The channel controller/director idea, on the other hand, was very
widely adopted.
--
Will
On 07/14/2015 02:05 PM, Jay Jaeger wrote:
Going all the way back to at least the IBM 7090, and presumably the 709,
though I have not actually checked. The B5000 had IO processors as well.
Again, you're missing the point. The system *starts* with a PPU and
loads the CPU up to run. OS was pre
Hi
Oscar Vermeulen managed to get an 8/I replica going using a
Raspberry Pi and Bob's code.
You do have to hook into the code of course. I want to do an 8/e the
same way.
Regards Rod
On 14/07/2015 20:25, Paul Koning wrote:
On Jul 14, 2015, at 2:42 PM, Rod Smallwood
wrote:
Back at a m
> > 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
Going all the way back to at least the IBM 7090, and presumably the 709,
though I have not actually checked. The B5000 had IO processors as well.
On 7/14/2015 2:55 PM, William Donzelli wrote:
>> ...I/O processors.
>
> I do not think you can claim that the 6600 I/O processors were all
> that new.
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
> Sure, but channel controllers and PPUs are very different beasts. You can’t
> run your OS on a channel controller, which is exactly what Cray did on the
> 6600. Nor can you implement the entire operator user interface on a channel
> controller, as was done in the DSD PPU program.
Yes, I rea
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
On 07/14/2015 12:55 PM, William Donzelli wrote:
...I/O processors.
I do not think you can claim that the 6600 I/O processors were all
that new. Many (most?) of the 1960s mainframes before the 6600 had
channel controllers.
Perhaps not, but they were unique in their implementation (one "logic
> On Jul 14, 2015, at 3:55 PM, William Donzelli wrote:
>
>> ...I/O processors.
>
> I do not think you can claim that the 6600 I/O processors were all
> that new. Many (most?) of the 1960s mainframes before the 6600 had
> channel controllers.
Sure, but channel controllers and PPUs are very diff
>
> 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
> ...I/O processors.
I do not think you can claim that the 6600 I/O processors were all
that new. Many (most?) of the 1960s mainframes before the 6600 had
channel controllers.
--
Will
> 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 Jul 14, 2015, at 2:42 PM, Rod Smallwood
> wrote:
>
> Back at a more general level. To my way of thinking what Bob Supnik did in
> software can be extended by producing a hardware replica vehicle for his code
> to give the illusion that the original system has been recreated. A sort of
>
Back at a more general level. To my way of thinking what Bob Supnik did
in software can be extended by producing a hardware replica vehicle for
his code to give the illusion that the original system has been
recreated. A sort of machine Turing test if you will.
Rod Smallwood
/
/
/On 14/07/20
> On Jul 14, 2015, at 1:55 PM, Noel Chiappa wrote:
>
>> From: Paul Koning
>
>>> I have a hard time coming up with other machines with the same level
>>> of impact/influence, in terms of CPU internal architecture. Maybe
>>> Atlas, or the 801?
>
>> CDC 6600, of course.
>
> I guess I don't know
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,
On 07/14/2015 10:55 AM, Noel Chiappa wrote:
I guess I don't know the 6600 that well (I have the book, and have skimmed it
in the past). What are the novel features in the 6600 that were widely
adopted by other machines? (I listed the Atlas because of paging, and the 801
because of RISC.)
There
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
1 - 100 of 121 matches
Mail list logo
