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

[Paul Koning]

> On Jul 13, 2015, at 8:35 AM, Jay Jaeger  wrote:
> 
> Another alternative would be to build a machine up from a Field
> Programmable Gate Array (e.g., the Digilent Nexys2 FPGA development
> board).  I recently completed an effort doing that for a 12 bit machine
> we designed and built in a logic/computer design class from racks of
> logic interconnected using IBM unit record plug boards in 1972.
> 
> I am going to attempt to do the same for IBM's 1410 computer - a really
> big effort.

That’s been done for all sorts of machines, of course; the PDP-11 comes to mind.

One question would be what design approach you’re using.  A behavioral model is 
one option; that’s roughly SIMH in an FPGA.  And just like SIMH, the model is 
only as accurate as your knowledge of the obscure details of the original 
design.  Depending on the quality of available manuals, this accuracy may be 
rather low.  (For example, building a PDP-11 model if all you have is a 
Processor Handbook may not be accurate enough.)

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 accurate.

I’ve done a partial gate level model of the CDC 6600, working from the wiring 
lists and module schematics.  It accurately reproduces (and explains) quite 
obscure properties of the peripheral processors, things that aren’t documented 
anywhere I know of other than in programmer lore.  It also yields a large model 
that simulates very slowly...

paul

Re: PDP-12 at the RICM (Michael Thompson)

[Michael Thompson]

>
> Date: Mon, 13 Jul 2015 01:52:09 -0400
> From: "Kip Koon" 
> Subject: RE: PDP-12 at the RICM
>
> Hi Michael,
> I would be most interested in finding out more about this effort.  Do you
> have ongoing pictures documenting this effort?  I'd love to have a PDP 8,
> 11, 12 someday, but I don't have the space for something like that much
> less the cost involved so I'll have to be satisfied with emulators on my PC
> or eventually building one or more of these systems with current technology
> like the SBC6120 if memory serves.  Are there other possible alternatives?
> I used a PDP-8/E in high school and college and have been quite interested
> in the high capability PDPs like the PDP-11 Series for starters.  I didn't
> know there were PDP 12 Series computers.  Are there other PDP series
> computers as well?  Congratulations on your restoration efforts!  I wish I
> could see what all you guys have been and are up to!  Take care my friends.
>
> Kip Koon
> computer...@sc.rr.com
> http://www.cocopedia.com/wiki/index.php/Kip_Koon
>

Kip,

I don't think that there is an emulator for the PDP-12 so you will need to
find a real one.
Details on the PDP-12 are here:
http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12
A running blog on the restoration is here:
http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12/dec-pdp-12-restoration


Michael Thompson

Re: PDP-12 at the RICM (Michael Thompson)

[Michael Thompson]

>
> Date: Sun, 12 Jul 2015 16:10:10 -0500
> From: Jay Jaeger 
> Subject: Re: PDP-12 at the RICM
>
> BTW, if there are particular cards you need / are bad, in addition to
> the actual PDP-12, I have the backplanes and cards for a 2nd one, so if
> you need something, we could probably work something out.
>
> JRJ
>

Jay,

We will keep you in mind if we can't repair a flip-chip.

-- 
Michael Thompson

Re: Linear Power Supply (Conversion Equipment Corp) from a basic four 510

[Armin Diehl]

Thanks, yes you are right. And it is fixed now. Would have been more 
easy with the schematics on hand.


But the 510 does not seem to start, may be the mini test program i have 
(to boot from terminal) only works with the model 210 and not with the 
510. (http://basicfour.de/cpu/small/index.html)


Would really like to have the cpu documentation, than it may be possible 
to write some test code. (1300 CPU Technical Manual and/or M1300 Series 
CPU Organisation and Description Reference Manual)





On 07/10/2015 08:19 PM, dwight wrote:



Date: Fri, 10 Jul 2015 11:03:14 +0200
From: a...@ardiehl.de
To: General@lnx.armin.d; lnx.armin.d:On-Topic and Off-Topic Posts 
cctalk@classiccmp.org
Subject: Linear Power Supply (Conversion Equipment Corp) from a basic four 510

The one from my 510 does not supply the main +5V, all the other voltages
are present. Does someone have a schematic for that one, would me more
easy.
I have uploaded pictures here: http://basicfour.de/mai510-PSU/small/

Thanks a lot

Armin

Linear supplies are the easiest to fix. Most of the circuits use 723 that
are straight forward regulators. The MC3302 ( LM339 ) is most likely
an over voltage detector or such.
Get a data sheet for the 723 and I suspect you'll be able to trouble
shoot with just that and no actual schematic. I think places like Jamco
still have these chips.
Locate the one used for the +5 and measure the voltages on
the pins. It will most likely tell you the issue.
Dwight






--


Grüsse
Armin Diehl
a...@ardiehl.de

Available: HP3000 serie 52 parts

[Anders Sandahl]

Hi,

I have a bunch of PCB's from a HP3000 series 52 computer. Is some one
interested in those?

The machine itself was still working when it was taken out of service in
the late 1990's. No guaranties are given though.

The location is in south of Sweden, but I'll guess I can pack them and
send them elsewhere.

There is also a power supply available. A disk station and some kind of a
tape drive, each sitting in a cabinet of their own. Free for pickup.

Don't know more than this, but I can find out more details if anyone is
interested.

/Anders

RE: Linear Power Supply (Conversion Equipment Corp) from a basic four 510

[dwight]

I'm not even sure what the machine is. Can you give
a little more information on what it is?
Dwight

 
> Subject: Re: Linear Power Supply (Conversion Equipment Corp) from a basic 
> four 510
> To: cct...@classiccmp.org
> From: a...@ardiehl.de
> Date: Mon, 13 Jul 2015 18:28:56 +0200
> 
> Thanks, yes you are right. And it is fixed now. Would have been more 
> easy with the schematics on hand.
> 
> But the 510 does not seem to start, may be the mini test program i have 
> (to boot from terminal) only works with the model 210 and not with the 
> 510. (http://basicfour.de/cpu/small/index.html)
> 
> Would really like to have the cpu documentation, than it may be possible 
> to write some test code. (1300 CPU Technical Manual and/or M1300 Series 
> CPU Organisation and Description Reference Manual)
> 
> 
> 
> 
> On 07/10/2015 08:19 PM, dwight wrote:
> >
> >> Date: Fri, 10 Jul 2015 11:03:14 +0200
> >> From: a...@ardiehl.de
> >> To: General@lnx.armin.d; lnx.armin.d:On-Topic and Off-Topic Posts 
> >> cctalk@classiccmp.org
> >> Subject: Linear Power Supply (Conversion Equipment Corp) from a basic four 
> >> 510
> >>
> >> The one from my 510 does not supply the main +5V, all the other voltages
> >> are present. Does someone have a schematic for that one, would me more
> >> easy.
> >> I have uploaded pictures here: http://basicfour.de/mai510-PSU/small/
> >>
> >> Thanks a lot
> >>
> >> Armin
> > Linear supplies are the easiest to fix. Most of the circuits use 723 that
> > are straight forward regulators. The MC3302 ( LM339 ) is most likely
> > an over voltage detector or such.
> > Get a data sheet for the 723 and I suspect you'll be able to trouble
> > shoot with just that and no actual schematic. I think places like Jamco
> > still have these chips.
> > Locate the one used for the +5 and measure the voltages on
> > the pins. It will most likely tell you the issue.
> > Dwight
> >
> >
> > 
> 
> 
> -- 
> 
> 
> Grüsse
> Armin Diehl
> a...@ardiehl.de
> 
  

Re: PDP-12 at the RICM (Michael Thompson)

[wulfman]

On 7/13/2015 4:59 PM, Michael Thompson wrote:
>> Date: Mon, 13 Jul 2015 01:52:09 -0400
>> From: "Kip Koon" 
>> Subject: RE: PDP-12 at the RICM
>>
>> Hi Michael,
>> I would be most interested in finding out more about this effort.  Do you
>> have ongoing pictures documenting this effort?  I'd love to have a PDP 8,
>> 11, 12 someday, but I don't have the space for something like that much
>> less the cost involved so I'll have to be satisfied with emulators on my PC
>> or eventually building one or more of these systems with current technology
>> like the SBC6120 if memory serves.  Are there other possible alternatives?
>> I used a PDP-8/E in high school and college and have been quite interested
>> in the high capability PDPs like the PDP-11 Series for starters.  I didn't
>> know there were PDP 12 Series computers.  Are there other PDP series
>> computers as well?  Congratulations on your restoration efforts!  I wish I
>> could see what all you guys have been and are up to!  Take care my friends.
>>
>> Kip Koon
>> computer...@sc.rr.com
>> http://www.cocopedia.com/wiki/index.php/Kip_Koon
>>
> Kip,
>
> I don't think that there is an emulator for the PDP-12 so you will need to
> find a real one.
> Details on the PDP-12 are here:
> http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12
> A running blog on the restoration is here:
> http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12/dec-pdp-12-restoration
>
>
> Michael Thompson
>
https://github.com/andysan/greenpea

-- 
The contents of this e-mail and any attachments are intended solely for the use 
of the named
addressee(s) and may contain confidential and/or privileged information. Any 
unauthorized use,
copying, disclosure, or distribution of the contents of this e-mail is strictly 
prohibited by
the sender and may be unlawful. If you are not the intended recipient, please 
notify the sender
immediately and delete this e-mail.

Re: Linear Power Supply (Conversion Equipment Corp) from a basic four 510

[jwsmobile]

It is the follow on to the Microdata 1600 that Basic four used in its 
first business machines.


He has two machines and at least a disk for the system, I think.

Basic Four became MAI.  They were noted for having a multi user basic 
system for business very early on.


Also it survive(s) today with a lot of installations in the Hospitality 
industry.  Many of the fleabags you check into will have MAI systems if 
they have terminal type systems.


These systems were probably very near the 1600 hardware wise.  They 
appear to have the 130pin 1600 backplane connector.  I think Basic four 
took slow steps away from Microdata's hardware, but eventually 
progressed with all their own manufacturing, as well as moving on thru 
bit slice designs, and eventually microprocessor based systems.  I had a 
friend who worked there in the very early stages of their 68000 
systems.  All while maintaining the Business Basic compatibility.


It is quite interesting to see the photos of the boards, and I am still 
studying them trying to figure out how much they changed in this design.


thanks
Jim

On 7/13/2015 9:22 PM, dwight wrote:

I'm not even sure what the machine is. Can you give
a little more information on what it is?
Dwight

  

>Subject: Re: Linear Power Supply (Conversion Equipment Corp) from a basic four 
510
>To:cct...@classiccmp.org
>From:a...@ardiehl.de
>Date: Mon, 13 Jul 2015 18:28:56 +0200
>
>Thanks, yes you are right. And it is fixed now. Would have been more
>easy with the schematics on hand.
>
>But the 510 does not seem to start, may be the mini test program i have
>(to boot from terminal) only works with the model 210 and not with the
>510. (http://basicfour.de/cpu/small/index.html)
>
>Would really like to have the cpu documentation, than it may be possible
>to write some test code. (1300 CPU Technical Manual and/or M1300 Series
>CPU Organisation and Description Reference Manual)
>

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

[Dave G4UGM]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Paul
> Koning
> 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:
> >
> > Another alternative would be to build a machine up from a Field
> > Programmable Gate Array (e.g., the Digilent Nexys2 FPGA development
> > board).  I recently completed an effort doing that for a 12 bit
> > machine we designed and built in a logic/computer design class from
> > racks of logic interconnected using IBM unit record plug boards in 1972.
> >
> > I am going to attempt to do the same for IBM's 1410 computer - a
> > really big effort.
> 
> That’s been done for all sorts of machines, of course; the PDP-11 comes to
> mind.
> 
> One question would be what design approach you’re using.  A behavioral
> model is one option; that’s roughly SIMH in an FPGA.  And just like SIMH, the
> model is only as accurate as your knowledge of the obscure details of the
> original design.  Depending on the quality of available manuals, this accuracy
> may be rather low.  (For example, building a PDP-11 model if all you have is a
> Processor Handbook may not be accurate enough.)
> 
> 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 accurate.
> 
> I’ve done a partial gate level model of the CDC 6600, working from the wiring
> lists and module schematics.  It accurately reproduces (and explains) quite
> obscure properties of the peripheral processors, things that aren’t
> documented anywhere I know of other than in programmer lore.  It also
> yields a large model that simulates very slowly...
> 
>   paul

I think there are a several options for the degree of authenticity with FPGA 
re-implementations. At the simplest of levels my Baby Baby runs at the same 
speed as the full sized Baby, but it currently uses a 32 bit parallel logic in 
many places as I built a 32 bit wide store and it keeps much of the HDL "code"  
simple.  I do intend to try a full serial machine at some point, but its low on 
my list. I have only really use the Xilinx ISE in anger, but I note it is 
possible to see the generated gates generated from the HDL or simulated HDL 
from a gate level diagram. I believe you can also mix and match gates and HDL 
(I have not tried, too many other things to do.) 

My next project is likely to be the Ferranti Pegasus which is several orders of 
magnitude more complex than the Baby and will need a proper plan. 

Dave

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

[ANDY HOLT]

- 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 technology (Re: PDP-12 at the 
RICM)
...
My next project is likely to be the Ferranti Pegasus which is several orders of 
magnitude more complex than the Baby and will need a proper plan. 


"There may be troubles ahead" …
I had plans for doing something similar for the ICT1905 (FP6000) and discovered 
two catches in translating the logic diagrams:

FPGAs are designed around the modern concept of a single clock that is widely 
distributed and having flipflop control by gating the input signals whereas 
early Ferranti machines (1900, at least pre "A" series, Atlas*, and presumably 
Pegasus) used "strobes" which are hard and inefficient to do in a FPGA.

Maybe less likely to be the case in the Pegasus is the widespread use of 
"wired-or" which can be hard to recognise in the logic diagrams (and, again, 
requires translating into "real" gates in an FPGA)
Obviously a register transfer model wouldn't have those problems compared to a 
gate-level model and would be considerably simpler to implement but then risks 
losing some of the (possibly undocumented) edge cases.

* Atlas would, presumably, be even trickier due to the use of asynchronous 
logic. 

Good luck, should be an "interesting" exercise.

Andy

Re: Reproducing old machines with newer technology

[Noel Chiappa]

> 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) should _really_ do is the IBM Stretch
(7030); although judged a commercial failure at the time, in retrospect it's
clearly one of the most ground-breaking designs of all time. (In fact, 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?)

Noel

Re: PDP-12 at the RICM

[Noel Chiappa]

> From: Rich Alderson

> Changing from PDP-8 operation to LINC operation was a matter of a
> physical switch.

Err, not according to the "Small Computer Handbook" (1967 Edition), which
covers the LINC-8 in detail - at least, as I understand it? See, for instance,
pg. 307 "A LINC HALT instruction will also stop the LINC and return control to
the PDP-8." And see also the "Operational Summary", pp. 308-309, and Chapter
7, "LINC - PDP-8 Intercommunication".

Reading the handbook, it _seems_ like, in theory at least, the two machines
could run simultaneously (albeit contending for memory bandwidth), although
the canonical programming approach was to have one pause while the other
ran. Or perhaps that supposition is incorrect, and the two couldn't correctly
deal with contention for memory (although the LINC used the standard PDP-8
'data break' mechanism for access to memory, which was used by DMA devices
such as disks, so the -8 should have been able to deal with it; perhaps the
LINC couldn't); or perhaps there was some vital piece of circuitry shared by
both?

I wonder if any LINC-8's still exist?


> "PDP-8/i + LINC hybrid"

The bone I have with that description (which may be technically correct) is
that it implies that prior to the PDP-12, there were only the two separate
machines (PDP-8 and LINC).

But I know I'm a stickler for small details... :-)

Noel

Re: PDP-12 at the RICM

[Sean Caron]

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 Anderson  wrote:

> Thanks Al
>
> On Tue, Jul 14, 2015 at 12:00 AM, Al Kossow  wrote:
>
> >
> >
> > On 7/13/15 9:54 PM, Paul Anderson wrote:
> >
> >> Hi Rich,
> >>
> >> Which one was possibility built for NSA? I missed the [1] footnote. Do
> you
> >> know more about the story?
> >>
> >>
> > this is the source for the wikipedia entry on the PDP-3
> >
> > http://www.decconnection.org/announcements.htm
> >
> >  February 14, 2007 ***
> >
> > *Anyone seen a PDP-3 lately?*
> >
> > I'm trying to discover what became of the PDP-3. It was originally built
> > at the Scientific Engineering Institute (SEI) in Waltham, MA, and later
> > transferred to someone at MIT. Gordon Bell wrote in 1978 that it was
> > running at an unspecified location in Oregon, but yesterday he told me
> that
> > he doesn't remember where that was. I am working on a book on the history
> > of stealth and the Lockheed Blackbird. The PDP-3 was used at SEI to
> process
> > radar data for the A-12 Blackbird. Thanks very much, Paul Suhler (949)
> > 856-1450 or paul.suh...@quantum.com
> >
> >
> >
>

Re: Reproducing old machines with newer technology

[Paul Koning]

> On Jul 14, 2015, at 7: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) should _really_ do is the IBM Stretch
> (7030); although judged a commercial failure at the time, in retrospect it's
> clearly one of the most ground-breaking designs of all time. (In fact, 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.

paul

Re: PDP-12 at the RICM

[Paul Koning]

> 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.
> 
> ??? What segments??? The PDP-11 have a plain simple page table. No segments 
> anywhere in sight. And each page is 8K.

To me, “segment” means a chunk of memory.  It doesn’t refer to separate page 
tables, or page tables broken into pieces.  And as I recall, the terms 
“instruction and data segments” were in common use to describe the feature.

The PDP-11 is a bit unusual in that each page is *up to* 8k, the actual size 
(and whether it’s the lower or the upper part that is accessible) is specified 
by the page description register for that page.  Also in that the physical 
address of the page isn’t constrained to a multiple of the (max) page size.

paul

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

[Dave G4UGM]

> -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-12 at
> the RICM)
> 
> 
> - 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 technology (Re: PDP-12 at
> the RICM) ...
> My next project is likely to be the Ferranti Pegasus which is several orders 
> of
> magnitude more complex than the Baby and will need a proper plan.
> 
> 
> "There may be troubles ahead" …
> I had plans for doing something similar for the ICT1905 (FP6000) and
> discovered two catches in translating the logic diagrams:
> 
> FPGAs are designed around the modern concept of a single clock that is widely
> distributed and having flipflop control by gating the input signals whereas 
> early
> Ferranti machines (1900, at least pre "A" series, Atlas*, and presumably
> Pegasus) used "strobes" which are hard and inefficient to do in a FPGA.

Actually the Pegasus "should" be relatively easy to implement in FPGA. It is 
all locked to 333Khz clock track derived from the drum. As all storage elements 
are delay lines which also run at the same speed as the drum, so you can 
transfer data between the two without using buffers almost everything is 
tightly coupled to the 333Khz clock. It was also one of the first machines to 
use standard replicable modules. According to Simon Lavington's book (which I 
don't trust 100%)  there are 20 types of package in a  basic Pegasus I, and you 
need 444 to build the machine. Out of these 314 are used to build the CPU but 
there are only 5 types of standard module.  So in practice its built a bit like 
a large PDP/8S but with Valves.

Charles Owen who Lavington credits with coming up with the Module Concept went 
to work for IBM in 1956 and was later made an IBM fellow.

https://books.google.co.uk/books?id=Dhk9wHXfQMkC&pg=PA165&lpg=PA165&dq=charles+owen+IBM+pegasus&source=bl&ots=JSvHMLa1V8&sig=SA2HBed4zErpjcKRSpVZ854HS8Y&hl=en&sa=X&redir_esc=y#v=onepage&q=charles%20owen%20IBM%20pegasus&f=false

> 
> Maybe less likely to be the case in the Pegasus is the widespread use of 
> "wired-
> or" which can be hard to recognise in the logic diagrams (and, again, requires
> translating into "real" gates in an FPGA) Obviously a register transfer model
> wouldn't have those problems compared to a gate-level model and would be
> considerably simpler to implement but then risks losing some of the (possibly
> undocumented) edge cases.
> 

It has germanium diodes so few wired OR's as far as I know.

> * Atlas would, presumably, be even trickier due to the use of asynchronous
> logic.

Altas would be great fun. I suspect you could do it by using multiple 
independent clocks and complex handshaking...

> 
> Good luck, should be an "interesting" exercise.
> 
> Andy

Thanks,
Dave.

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

[Jay Jaeger]

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 actually individual
gates/chunks of DTL chips) get little behavioral models.  As I
mentioned, so far what I have done is reproduce and test a 12 bit
computer designed in an electrical engineering course on logic/computer
design.  In August I plan on publishing my experience on a website.

I would note that I also see value in the behavioral approach, which
really would be considerably more detailed than what you get form SimH.
 The IBM 1410 cycle-level simulator I have written is closer to what one
might get from a behavioral model, but even that is not quite so detailed.

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, including the latch getting folded into the
look up tables for gates which use the signal, and issues when one
brings such a signal out to an I/O pin to feed to a logic analyzer,
which can cause problems to appear and disappear.  My experience is that
one can add a D flip flop after the RS latch.  This typically works
because at 50 Mhz, it adds only 20 ns delay, which is comparable to gate
delays these old machines typically had.

2)  One-shots.  I haven't had to address this one yet, but I am sure
that I will.  I expect that one can simply use a counter to handle it -
no big deal at all.

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 a counter.  Since the counter
flip flops did not all change at exactly the same time, that signal
could glitch during the simulated machines master clock edge.  They
respond well to the same general solution as #1 - stick a D flip flop
between the combinatorial output and the clock input.  In the case I
mentioned, that gave the signal an entire 50 Mhz clock period to settle
down.

And of course, getting the detailed information one needs to develop
such a model can be a challenge.  Fortunately for the older IBM
machines, IBM produced ALDs - Automated Logic Diagrams - which I hope
will generally have enough information.

My experience on FPGA forums during the development of my 12 bit
computer implementation was mixed.  I got some helpful comments, but the
majority of folks were not helpful, and instead preferred to bash me for
not redoing the entire machine design using FPGA's the way these
particular folks felt was "the only right way" to use them.  Bah.

JRJ


On 7/14/2015 2:58 AM, Dave G4UGM wrote:
>> -Original Message-
>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Paul
>> Koning
>> 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:
>>>
>>> Another alternative would be to build a machine up from a Field
>>> Programmable Gate Array (e.g., the Digilent Nexys2 FPGA development
>>> board).  I recently completed an effort doing that for a 12 bit
>>> machine we designed and built in a logic/computer design class from
>>> racks of logic interconnected using IBM unit record plug boards in 1972.
>>>
>>> I am going to attempt to do the same for IBM's 1410 computer - a
>>> really big effort.
>>
>> That’s been done for all sorts of machines, of course; the PDP-11 comes to
>> mind.
>>
>> One question would be what design approach you’re using.  A behavioral
>> model is one option; that’s roughly SIMH in an FPGA.  And just like SIMH, the
>> model is only as accurate as your knowledge of the obscure details of the
>> original design.  Depending on the quality of available manuals, this 
>> accuracy
>> may be rather low.  (For example, building a PDP-11 model if all you have is 
>> a
>> Processor Handbook may not be accurate enough.)
>>
>> 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 accurate.
>>
>> I’ve done a partial gate level model of the CDC 6600, working from the wiring
>> lists and module schematics.  It accurately reproduces (and explains) quite
>> obscure properties of the peripheral processors, things that aren’t
>> documented anywhere I know of other than in programmer lore.  It also
>> yields a large model that simulates very slowly...
>>
>>  paul
> 
> I think there are a several options for the degree of authenticity with FPGA 
> re-implementations. At the simplest of levels my Baby Baby runs at the s

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

[Jay Jaeger]

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

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

JRJ

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

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

[ben]

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 actually individual
gates/chunks of DTL chips) get little behavioral models.  As I
mentioned, so far what I have done is reproduce and test a 12 bit
computer designed in an electrical engineering course on logic/computer
design.  In August I plan on publishing my experience on a website.

I would note that I also see value in the behavioral approach, which
really would be considerably more detailed than what you get form SimH.
  The IBM 1410 cycle-level simulator I have written is closer to what one
might get from a behavioral model, but even that is not quite so detailed.

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, including the latch getting folded into the
look up tables for gates which use the signal, and issues when one
brings such a signal out to an I/O pin to feed to a logic analyzer,
which can cause problems to appear and disappear.  My experience is that
one can add a D flip flop after the RS latch.  This typically works
because at 50 Mhz, it adds only 20 ns delay, which is comparable to gate
delays these old machines typically had.

2)  One-shots.  I haven't had to address this one yet, but I am sure
that I will.  I expect that one can simply use a counter to handle it -
no big deal at all.

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 a counter.  Since the counter
flip flops did not all change at exactly the same time, that signal
could glitch during the simulated machines master clock edge.  They
respond well to the same general solution as #1 - stick a D flip flop
between the combinatorial output and the clock input.  In the case I
mentioned, that gave the signal an entire 50 Mhz clock period to settle
down.

And of course, getting the detailed information one needs to develop
such a model can be a challenge.  Fortunately for the older IBM
machines, IBM produced ALDs - Automated Logic Diagrams - which I hope
will generally have enough information.

My experience on FPGA forums during the development of my 12 bit
computer implementation was mixed.  I got some helpful comments, but the
majority of folks were not helpful, and instead preferred to bash me for
not redoing the entire machine design using FPGA's the way these
particular folks felt was "the only right way" to use them.  Bah.

JRJ


I have felt the right way is NOT to use VHDL or VERLOG  sadly. I use 
altera and using AHDL is the best for me as it cleanest language so far. 
FPGA's have never been standard logic, so why force standards, if you 
can not even agree on gates latches and flipflops in fpgas.


Here is the link you have been waiting for, IBM 1130 in FPGA and in the 
FLESH.

http://ibm1130.blogspot.ca/

Ben.
PS: Don't use blog format for the web site, they are a pain to read
or search if what you want is more than few years old.

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

[ben]

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 accurate.



The big assumption here, is the software will NOT change the logic model
and the details are vender specific. Altera software is BAD for doing this.
Ben.

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

[Paul Koning]

> 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, including the latch getting folded into the
> look up tables for gates which use the signal, and issues when one
> brings such a signal out to an I/O pin to feed to a logic analyzer,
> which can cause problems to appear and disappear.  My experience is that
> one can add a D flip flop after the RS latch.  This typically works
> because at 50 Mhz, it adds only 20 ns delay, which is comparable to gate
> delays these old machines typically had.

I didn’t like what happened with flops built out of gates when doing my 6600 
model.  So I replaced those by behavioral models.  The main reason was that the 
crossed-gate model would produce a mess with R and S both asserted, which that 
design would do at times, while the behavioral model was written to do 
something specific for that case.
> 
> 2)  One-shots.  I haven't had to address this one yet, but I am sure
> that I will.  I expect that one can simply use a counter to handle it -
> no big deal at all.

If you’re creating a model to run in simulation, you can just write a delay.  
But that’s not synthesizable, so if you really do need a delay then a counter, 
or a shift register, or something like that will be needed.  This is the sort 
of thing that makes a 6600 design tricky (and may also apply to some other fast 
machines): there are places where propagation delays are used for correctness, 
and if the replacement hardware is “too fast” it doesn’t work.

> 
> 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 a counter.  Since the counter
> flip flops did not all change at exactly the same time, that signal
> could glitch during the simulated machines master clock edge.  They
> respond well to the same general solution as #1 - stick a D flip flop
> between the combinatorial output and the clock input.  In the case I
> mentioned, that gave the signal an entire 50 Mhz clock period to settle
> down.

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.

paul

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

[Paul Koning]

> 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 level
>> of original design data, the result can be quite accurate.
>> 
> 
> The big assumption here, is the software will NOT change the logic model
> and the details are vender specific. Altera software is BAD for doing this.

So now I know two reasons not to use AHDL.  :-)

Yes, it does require that the synthesis software doesn’t have major bugs.  And 
of course, the model has to be sufficiently constrained that it steers the 
synthesis correctly.

In my case, I haven’t reached that point yet.  My models currently only run in 
simulation (GHDL to be specific).

paul

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

[ben]

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 if you have access to
that level of original design data, the result can be quite
accurate.



The big assumption here, is the software will NOT change the logic
model and the details are vender specific. Altera software is BAD
for doing this.


So now I know two reasons not to use AHDL.  :-)



It is more the case, of what you don't know can't hurt you. This is a
back end of the compiler problem. With FPGA logic changing every 6 
months, you have less standard logic blocks.



Yes, it does require that the synthesis software doesn’t have major
bugs.  And of course, the model has to be sufficiently constrained
that it steers the synthesis correctly.


With AHDL I know what is generated, if I can't figure out verlog or VHDL's
logic I refuse to write in it. Why do we not have a good logic language 
(RTL?) for hardware? ( I consider them to be COBOL of the digital world).




In my case, I haven’t reached that point yet.  My models currently
only run in simulation (GHDL to be specific).


I have FPGA board here, so I use Crash and burn testing.


paul

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

[Chuck Guzis]

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 could be obtained by running a software 
emulator?  Neither accurately reflects the details of the real 
thing--and there will always be the aspect of missing peripherals.


Perhaps the worst aspect of using FPGA is that this is a rapidly moving 
field, so that the part you used to do your implementation 10 years ago 
will no longer be available.I've done a few designs using 5V CPLDs 
(XC95xx series) not *that* long ago.  Now they themselves are quaint 
examples of obsolete hardware.  You can't win.


You can move software-only simulators quite easily, but I'm not as 
sanguine about FPGA designs.


And you still don't have the peripherals.  I suppose one could emulate a 
Univac Solid State machine in FPGA, but what would one do about the 
all-important drum coupled to the card reader and printer.  Has anyone 
rolled out a design for a DIY 1403 printer?


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.


--Chuck

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

[Paul Koning]

> 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 a slow old architecture, when pretty much the same 
> result could be obtained by running a software emulator?  Neither accurately 
> reflects the details of the real thing--and there will always be the aspect 
> of missing peripherals.  ...
> 
> 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.

One possible answer is “because I can”.  

As for whether it accurately reflects the details of the real thing, that 
depends.  Not the peripherals, of course.  If the peripherals are much more 
interesting than the CPU, I agree there isn’t much point.  In the case of 
machines like the CDC 6600, the CPU is very interesting, the PPUs also, some of 
the peripheral controllers to some extent, but the peripheral devices 
themselves are not interesting at all.  An FPGA model can reproduce the 
interesting parts.

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 documented and certainly not visible in a software simulator.  The 
example I like to point to is the 6000 property that you can figure out a PPU 0 
hard loop by doing a deadstart dump and looking for an unexpected zero in the 
instruction area: deadstart writes a zero where the P register points at that 
time.  But you won’t find that documented or explained anywhere.  The FPGA 
model derived from the schematics reproduces this behavior, and when you look 
at how it happens, the explanation becomes blindingly obvious.  *This* is why I 
feel there’s a point in doing this sort of work.

paul

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

[Dave G4UGM]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
> Guzis
> Sent: 14 July 2015 18:17
> To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and Off-
> Topic Posts
> Subject: Re: Reproducing old machines with newer technology (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 FPGA implementation of a slow old architecture, when pretty much
> the same result could be obtained by running a software emulator?  

I don't think this is true. Most of the software simulators don't run at 
anything like accurate speed ...

> Neither
> accurately reflects the details of the real thing--and there will always be 
> the
> aspect of missing peripherals.

I believe that you can get much closer with an FPGA...

> 
> Perhaps the worst aspect of using FPGA is that this is a rapidly moving field,
> so that the part you used to do your implementation 10 years ago
> will no longer be available.

That is very true, but there again the same can happen with Software. The 
Pegasus Simulator I use was written in TurboPascal and has kludges to get the 
speed right that just don't work on a modern PC

> I've done a few designs using 5V CPLDs
> (XC95xx series) not *that* long ago.  Now they themselves are quaint
> examples of obsolete hardware.  You can't win.
> 
> You can move software-only simulators quite easily, but I'm not as sanguine
> about FPGA designs.
> 

See Above

> And you still don't have the peripherals.  I suppose one could emulate a
> Univac Solid State machine in FPGA, but what would one do about the all-
> important drum coupled to the card reader and printer.  Has anyone rolled
> out a design for a DIY 1403 printer?

When I have finished the Calcomp Plotter

> 
> 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.

I have used Hercules with a real 3270. Its not bad but Laurence Wilkinson's 360 
in FPGA wih a real Selectric Typewrite is much better:-

http://www.ljw.me.uk/ibm360/Saga.html


> 
> --Chuck
> 
 Dave

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

[ben]

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 architecture, when
pretty much the same result could be obtained by running a software
emulator?  Neither accurately reflects the details of the real
thing--and there will always be the aspect of missing peripherals.


For the moment you can still get FPGA boards with expansion conectors.
The $39 card the trend nowadays. Hard to get real I/O of any kind as we 
know.



Perhaps the worst aspect of using FPGA is that this is a rapidly moving
field, so that the part you used to do your implementation 10 years ago
will no longer be available.I've done a few designs using 5V CPLDs
(XC95xx series) not *that* long ago.  Now they themselves are quaint
examples of obsolete hardware.  You can't win.


Since when was that new in electronics. Mind you New Electrostaic speakers
and OLD Quad II's go well together.



You can move software-only simulators quite easily, but I'm not as
sanguine about FPGA designs.

And you still don't have the peripherals.  I suppose one could emulate a
Univac Solid State machine in FPGA, but what would one do about the
all-important drum coupled to the card reader and printer.  Has anyone
rolled out a design for a DIY 1403 printer?


Don't look at me, I lost the bid some old IBM equipment years ago.


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.


--Chuck


Ben.

Re: PDP-11 pages/segments/etc (Was: PDP-12 at the RICM)

[Noel Chiappa]

> 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 variable size. (I know of a couple which offer
_two_ page sizes, but none that have a field per page which specifies the
length of the page.)

They really are more like what most machines call 'segments'. I know Unix
doesn't use them that way (because it has such a simple-minded memory model),
but other systems do - e.g. MERT.

Noel

Re: Reproducing old machines with newer technology

[Noel Chiappa]

> 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 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.)

Noel

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

[Chuck Guzis]

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?  Power off the DD60 and stuff some 
cotton in your ears and you couldn't even tell that the thing was on.


--Chuck

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

[Alan Hightower]

 

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 for a context switch right at the threshold. I might want to
emulate a vintage i7 on an i19 one day. 

In my mind, take the best of both worlds. Emulate at an RTL level to
produce as accurate of a functional model possible. Then simulate the
design in things like Verilator to create a software runable emulation. 

Not to mention it's a deeper emersion to recreate the how rather than
just the result of an instruction. 

-Alan 

On 2015-07-14 13:17, 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 architecture, when pretty much the same 
> result could be obtained by running a software emulator? Neither accurately 
> reflects the details of the real thing--and there will always be the aspect 
> of missing peripherals.
> 
> Perhaps the worst aspect of using FPGA is that this is a rapidly moving 
> field, so that the part you used to do your implementation 10 years ago will 
> no longer be available. I've done a few designs using 5V CPLDs (XC95xx 
> series) not *that* long ago. Now they themselves are quaint examples of 
> obsolete hardware. You can't win.
> 
> You can move software-only simulators quite easily, but I'm not as sanguine 
> about FPGA designs.
> 
> And you still don't have the peripherals. I suppose one could emulate a 
> Univac Solid State machine in FPGA, but what would one do about the 
> all-important drum coupled to the card reader and printer. Has anyone rolled 
> out a design for a DIY 1403 printer?
> 
> 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.
> 
> --Chuck
 

Front Panel Update

[Rod Smallwood]

Hello Everybody
 In the course of doing the artwork for 8/e 
type B I have turned up some more variations.


The list  now looks like this:

1. Switch position markings
2. Line round switch area
3. The EMA title block isolated from the other titles
4. Lines between groups of three lamps
5. lab8/e instead of pdp8/e

So far I can't find any reasons as to why these variations seem to be 
random.

The only thing that is not cosmetic is the two types of switch position.

I am minded to add all of variatons (excluding lab8/e) because they seem 
progressive:


No line round the switch areabecomes line round the switch 
area

EMA title attached  becomes EMA title detached
No lines between lamps becomes lines between lamps

Then produce two versions based on the switch position

The issue is of course small batch costs.

Comments gentlemen please

Rod

Re: Reproducing old machines with newer technology

[Chuck Guzis]

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 are more than a few folks who call the CDC 6000 one of the first 
RISC machines.  In particular, the 6600 with its instruction scheduling 
and reservation control, multiple functional units, instruction cache, 
etc. was quite noteworthy.   You could easily recognize the earmarks of 
a very different machine of the time.   The issues that arose when 
programming later RISC CPUs made me feel that I was back in familiar 
territory.


3-address architecture, 60 bit ones complement words, with separate sets 
of registers for addresses and indexing.


A typical beginning programmer's problem was to write a CPU loop to move 
non-overlapping fields of words in the shortest amount of time (ECS not 
available).  The best solution usually involved two words per iteration, 
with one instruction issue per cycle; bottom of the loop load (to 
overlap the branch) and top-of-the-loop store.


Another challenge was to write a routine that could load and store the 
values of all registers from and to memory.  Not as simple as it sounds.


For me, one distinguishing feature is that there is no condition code 
register.  You could branch on a register value being signed or zero, or 
compare and branch on the values of two index registers.  Thus, the 
result of an operation was covered by the regular register reservation 
rules.


The I/O processors (PPUs) had access to all of CPU memory and 
essentially were their own world, using a 12-bit instruction set derived 
from the 160A.  One could also say that the PPUs were only one machine 
with memory and registers being time-multiplexed to simulate 10 machines.


--Chuck

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

[Chuck Guzis]

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, that is always a moving ratio or
opportunity for a context switch right at the threshold. I might want to
emulate a vintage i7 on an i19 one day.


You might start with a CDC STAR-100 and then graduate to the i7.

Does a STAR-100 emulator (software, I'm not even going to broach the 
subject of hardware) even exist?


--Chuck

Re: Reproducing old machines with newer technology

[Paul Koning]

> 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 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.)

RISC.  I/O processors.  Multiple instructions in process at the same time.  
(Not pipelining, that came a year or two later in the 7600).  Interlocking 
machinery to handle memory ordering (“stunt box”) and register access ordering 
(“scoreboard”).  Very fast memory cycling for its day.  Extremely efficient 
context switching.

That’s a good start.

paul

Re: Reproducing old machines with newer technology

[Rod Smallwood]

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/2015 19:26, Chuck Guzis wrote://
/

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 are more than a few folks who call the CDC 6000 one of the first 
RISC machines.  In particular, the 6600 with its instruction 
scheduling and reservation control, multiple functional units, 
instruction cache, etc. was quite noteworthy.   You could easily 
recognize the earmarks of a very different machine of the time. The 
issues that arose when programming later RISC CPUs made me feel that I 
was back in familiar territory.


3-address architecture, 60 bit ones complement words, with separate 
sets of registers for addresses and indexing.


A typical beginning programmer's problem was to write a CPU loop to 
move non-overlapping fields of words in the shortest amount of time 
(ECS not available).  The best solution usually involved two words per 
iteration, with one instruction issue per cycle; bottom of the loop 
load (to overlap the branch) and top-of-the-loop store.


Another challenge was to write a routine that could load and store the 
values of all registers from and to memory.  Not as simple as it sounds.


For me, one distinguishing feature is that there is no condition code 
register.  You could branch on a register value being signed or zero, 
or compare and branch on the values of two index registers.  Thus, the 
result of an operation was covered by the regular register reservation 
rules.


The I/O processors (PPUs) had access to all of CPU memory and 
essentially were their own world, using a 12-bit instruction set 
derived from the 160A.  One could also say that the PPUs were only one 
machine with memory and registers being time-multiplexed to simulate 
10 machines.


--Chuck

Re: Front Panel Update

[Tom Moss]

Hi Rod,

Any chance I could commission you to do an Altair 8800 panel?
The silkscreen has almost completely worn off on mine, but I have a
high-quality scan of a good one.

-Tom

On 14 July 2015 at 19:20, Rod Smallwood 
wrote:

> Hello Everybody
>  In the course of doing the artwork for 8/e type B
> I have turned up some more variations.
>
> The list  now looks like this:
>
> 1. Switch position markings
> 2. Line round switch area
> 3. The EMA title block isolated from the other titles
> 4. Lines between groups of three lamps
> 5. lab8/e instead of pdp8/e
>
> So far I can't find any reasons as to why these variations seem to be
> random.
> The only thing that is not cosmetic is the two types of switch position.
>
> I am minded to add all of variatons (excluding lab8/e) because they seem
> progressive:
>
> No line round the switch areabecomes line round the switch area
> EMA title attached  becomes EMA title detached
> No lines between lamps becomes lines between lamps
>
> Then produce two versions based on the switch position
>
> The issue is of course small batch costs.
>
> Comments gentlemen please
>
> Rod
>
>

STSC APL*PLUS System for VAX VMS User's & Reference Manual

[Mark Wickens]

Kind reader

I have two manuals labelled STSC APL*PLUS System for VAX VMS: User's 
Manual and Reference Manual which were sent to me a number of years ago 
as paper copies - I now have the ability to easily scan these into PDF 
format.
Would these be of interest to anyone? There is a PC version archived 
here http://www.math.uwaterloo.ca/apl_archives/apl/apl-plus/ that might 
benefit from the additional documentation. I've contacted Lee about this.


I am interested if anyone has any history of this software (there are 
some general references out there about the STSC Mainframe and later PC 
versions) - and indeed if the software survived at all.


Was VAX/VMS APL based on this version?


Regards, Mark.

Seeking to buy / trade for a GRiD Compass 11xx to aid in silly project

[Ian Finder]

Hi folks,

I'm looking to buy at whatever price is fair a GRiD Compass (Not the DOS
based ones) computer of any model-- and perhaps condition- as I may be able
to repair

I recently missed an ebay auction, which was sad.

Let me know,

Thanks,

- Ian

-

Background.

About a year or so, I purchased my first GRiD compass (1129) off another
list member. I quickly gained two impressions:

1) The non MS-DOS based GRiD OS is really freakin' cool.
2) The documentation for these machines is nonexistent.

I've recently acquired an 8086 ICE. My goal is to reverse engineer the
machine and operating system to a reasonable degree, in order to glean
enough information to enable the following tasks:

1) (High priority) Build a somewhat modern toolchain for GRiD OS
2) (This might be something I never get to) Build an emulator of the GRiD.

Unfortunately, I don't want to-

A) Have to leave my main machine taken apart, or constantly
reassemble-disassemble it to attach it to the ICE.

B) Develop for a system I have no spares for.

Would love if someone who has an extra one of these they haven't used for a
while would be willing to part with it or trade for it.

In addition to whatever we work out, I'll toss in a free GRiDcase 3 to help
with separation anxiety stemming from black magnesium computers.

-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: Reproducing old machines with newer technology

[Paul Koning]

> 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 
> machine Turing test if you will.

I don’t think so, because SIMH does not (and does not aim to) deliver all the 
obscure details of the original hardware, only those that are relevant to 
ordinary software.

paul

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

[tony duell]

> 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 in production machines. 
With care you can determine the width of the glitch, and if it's small enough, 
ignore it. 

But there is a related problem with FPGAs. You learn in introductory digital 
electronic courses that there are
2 types of counter. The Asynchronous, or ripple, counter where each flip-flop 
toggles the next when it goes
from 1 to 0. Obviously those do not all change at once, so if you combine them 
with gates there can be 
quite large glitches. Then there is the synchronous counter where all 
flip-flops are clocked together. Now to a
good approximation (all the flip-flops have the same delay from clock to 
output), they do all change together.
So if you now combine the outputs (say you AND some of the Q and Q/ outputs to 
decode a particular state)
the glitches will be small. That's what is taught. That is what works with TTL, 
ECL, etc.

Now try it in an FPGA (at least the Xilinx ones I've used). You will find 
glitches all over the place. The reason
is that the 'wires' linking the outputs of the flip-flops to the gates are not 
wires at all. They are paths on the
chip through logic multiplexers, buffers, etc that are set when the chip is 
configured. And they introduce
delays. Delays that are enough to cause glitches that are wide enough to 
trigger other flip-flops.

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.

-tony



paul

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

[Paul Koning]

> 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 design, and not something that I would do, but it certainly 
> was done in production machines. 
> With care you can determine the width of the glitch, and if it's small 
> enough, ignore it. 
> 
> But there is a related problem with FPGAs. You learn in introductory digital 
> electronic courses that there are
> 2 types of counter. The Asynchronous, or ripple, counter where each flip-flop 
> toggles the next when it goes
> from 1 to 0. Obviously those do not all change at once, so if you combine 
> them with gates there can be 
> quite large glitches. Then there is the synchronous counter where all 
> flip-flops are clocked together. Now to a
> good approximation (all the flip-flops have the same delay from clock to 
> output), they do all change together.
> So if you now combine the outputs (say you AND some of the Q and Q/ outputs 
> to decode a particular state)
> the glitches will be small. That's what is taught. That is what works with 
> TTL, ECL, etc.
> 
> Now try it in an FPGA (at least the Xilinx ones I've used). You will find 
> glitches all over the place. The reason
> is that the 'wires' linking the outputs of the flip-flops to the gates are 
> not wires at all. They are paths on the
> chip through logic multiplexers, buffers, etc that are set when the chip is 
> configured. And they introduce
> delays. Delays that are enough to cause glitches that are wide enough to 
> trigger other flip-flops.
> 
> 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.

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, with consecutive latch 
points clocked by the consecutive phases.  That means that so long as the max 
latency is < the clock phase difference, it always works.

paul

Re: Reproducing old machines with newer technology

[William Donzelli]

> ...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

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

[tony duell]

> 
> 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, 
> with consecutive latch points 
> clocked by the consecutive phases.  That means that so long as the max 
> latency is < the clock phase
> difference, it always works.

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
it will not work.

-tony

Re: Reproducing old machines with newer technology

[Paul Koning]

> 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 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.

paul

Re: Reproducing old machines with newer technology

[Chuck Guzis]

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 
core" multiplexed among 10 memories and register sets) and the 
application os same.  Prior to about 6000 SCOPE 3.4, most of the OS 
logic was present in the PPUs, not the CPU.  IIRC, in SCOPE 3.3, the 
only CP part of the OS was the storage move program.  PPs communicated 
among themselves and used numerous "overlays" to accomplish the 
supervisory funciton.  You could have the CP at a dead stop with the OS 
happily ticking along.  SCOPE 3.4 moved more of the functionality


I don't think that was ever done with earlier machines.

In contrast, almost none of SCOPE 2 for the 7600 was in the PPs, which 
had access only to pre-assigned buffers in CM (or SCM if you will). 
7000 SCOPE was implemented using an interesting system of overlapping 
field lengths, such that the user program was the innermost.


I've never heard of an operating system, handling all job supervisory 
functions and I/O in a S/360 channel.


--Chuck

Re: FS: Apple IIGS, C64, Intel OpenStep Boxes, DOS Gaming rigs & more

[Todd Goodman]

Anyone contemplating dealings with Mr. Landon should check Google and
archives of this mailing list.

He's a thief.

* drlegendre .  [150713 21:42]:
> Sent you a private email, Steve. Let me know if you don't see it..
> 
> On Mon, Jul 13, 2015 at 5:51 AM, Steven Landon  wrote:
> 
> > Clearing out more of the collection that never gets used- everything works
> > perfectly and is cosmetically in good condition. Prices are make an offer,
> > i just want to see this stuff go to a good home
> >
> > Apple IIGS ROM 03
> > 4MB RAM Card
> > CFFA 3000 Card
> > 2x 3.5inch FDDs
> > 1x  5.25inch FDD
> > AE Conserver-  Allows you to sit 2 Floppy drives under the monitor and
> > functions as a power strip
> >
> >
> > Commodore 64
> > C64NIC+
> > ZoomFloppy
> > SD2IEC Interface with 8GB SD Card
> > JiffyDOS
> > Cart Slot Expander from Jim Brain
> > 1701 Monitor
> > 2x 1541 FDDs
> >
> > Mac Performa 631CD
> > 64MB RAM
> > 500MB HDD
> > Ethernet Card
> > Matching 15inch Monitor
> >
> >
> > NeXT Mono Slab
> > 20MB RAM
> > 2GB HDD
> > Frog Monitor
> > Non ADB Keyboard & Mouse
> >
> > HP 9000/712
> > 96MB RAM 1GB HDD
> > NeXTSTEP 3.3 Installed
> >
> > Sun SparcStation 5
> > 64MB RAM
> > 36GB HDD
> > OpenStep 4.2 Installed
> >
> > 3 Intel OpenStep 4.2 Boxes
> >
> > Dell Dimension XPS T450
> > 128MB RAM
> > 10GB HDD
> > Rage 3D Video
> > SoundBlaster Awe32
> > USB Card- Supported in OpenStep 4.2
> >
> > Dell Dimension 233mhz
> > 32MB RAM
> > 4GB HDD
> > Networking
> > OpenStep 4.2 Installed
> > Needs SB 16 Card for Audio
> >
> > HP Pavilion 6630
> > Celeron 500mhz
> > 64MB RAM
> > 3C905 Network Card
> > Running OpenStep 4.2
> > Needs SB 16 Card for Audio
> >
> >
> > DOS/Win Gaming Rigs
> >
> > Dell Dimension L1000R
> > Windows 98SE
> > 256MB RAM
> > 20GB HDD
> > Rage 128 Video
> >
> > Dell Dimension L667R
> > 128MB RAM
> > 15GB HDD
> > Rage 128 Video.
> >
> > IBM AT Clone
> > 40MB HDD
> > 640K RAM
> > 5.25 and 3.5 Drives
> >
> >
> > Parts & Stuff
> >
> > 10 36GB SCA SCSI Hard Drives
> > Sun Caddy Load external SCSI CD-ROM
> > Sony External SCSI CD-ROM
> > 4x Zip Drives,  2 Parallel 2 SCSI with 20 zip disks
> > Syquest EZ135 Drive with 15 Carts
> >
> > Medium Flat rate boxes filled with DSDD 3.5inch Disks 5.25inch Disks and
> > 3.5in HD Disks
> >
> > 6 Large totes filled with SCSI Cables,  AC Adapters,  Ethernet Cables,
> > You name it
> >
> >
> > There is honestly too much to list.. Thats just a sampling of whats here
> > in parts and accessories.
> >
> > Thanks
> >
> > Steve
> >

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

[Chuck Guzis]

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 documented and
certainly not visible in a software simulator.  The example I like to
point to is the 6000 property that you can figure out a PPU 0 hard
loop by doing a deadstart dump and looking for an unexpected zero in
the instruction area: deadstart writes a zero where the P register
points at that time.  But you won’t find that documented or explained
anywhere.  The FPGA model derived from the schematics reproduces this
behavior, and when you look at how it happens, the explanation
becomes blindingly obvious.  *This* is why I feel there’s a point in
doing this sort of work.


I can agree with some points, but not others.  In the 6600, for example, 
clock distribution was a big design issue--not so in an FPGA.  You had 
racks of taper-pin mats of wiring between the cordwood moules extending 
over (by today's standards) long distances.  Cooling was a huge issue. 
In those respects, an FPGA hardly resembles a "real" 6600.


--Chuck

Re: Reproducing old machines with newer technology

[William Donzelli]

> 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 realize that a CDC PPU is a very versatile I/O processor,
compared to channel controllers from other vendors, but the PPU idea
pretty much stayed with CDC and nobody else. It fails the "novel
features in the 6600 that were widely adopted by other machines" test.

--
Will

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

[ben]

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
it will not work.


What machines were you thinking of?

Once TTL came out, 8,16,32 bits ended up being the common size.
I working on FPGA computer design, that is TTL style computer, 1975 ish 
or so. 20 bits, 74LSxx 181 alu and 4x4 ram for general registers.

I have not yet made up my mind how to do Interupts,but I got most the
logic with only about 6 or so clocks.



-tony

Re: Reproducing old machines with newer technology

[Jay Jaeger]

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. Many (most?) of the 1960s mainframes before the 6600 had
> channel controllers.
> 
> --
> Will
> 

Re: Front Panel Update

[Rod Smallwood]

Hi Tom
  I had thought somebody had done one (or it was part of a kit) 
However I cant find

anything about it. So lets have a look at  your scan.

Regards
Rod


On 14/07/2015 19:44, Tom Moss wrote:

Hi Rod,

Any chance I could commission you to do an Altair 8800 panel?
The silkscreen has almost completely worn off on mine, but I have a
high-quality scan of a good one.

-Tom

On 14 July 2015 at 19:20, Rod Smallwood 
wrote:


Hello Everybody
  In the course of doing the artwork for 8/e type B
I have turned up some more variations.

The list  now looks like this:

1. Switch position markings
2. Line round switch area
3. The EMA title block isolated from the other titles
4. Lines between groups of three lamps
5. lab8/e instead of pdp8/e

So far I can't find any reasons as to why these variations seem to be
random.
The only thing that is not cosmetic is the two types of switch position.

I am minded to add all of variatons (excluding lab8/e) because they seem
progressive:

 No line round the switch areabecomes line round the switch area
 EMA title attached  becomes EMA title detached
 No lines between lamps becomes lines between lamps

Then produce two versions based on the switch position

The issue is of course small batch costs.

Comments gentlemen please

Rod

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

[tony duell]

> > 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 would be very surprised if you took the schematics for an HP9830, PDP8/e, 
PDP11/45, Philip P850, PERQ etc
put them into a schematic capture program and had a completely working FPGA 
version of the machine.


> Once TTL came out, 8,16,32 bits ended up being the common size.
> I working on FPGA computer design, that is TTL style computer, 1975 ish
> or so. 20 bits, 74LSxx 181 alu and 4x4 ram for general registers.
> I have not yet made up my mind how to do Interupts,but I got most the
> logic with only about 6 or so clocks.

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.

-tony

Re: Reproducing old machines with newer technology

[Rod Smallwood]

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 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.

I don’t think so, because SIMH does not (and does not aim to) deliver all the 
obscure details of the original hardware, only those that are relevant to 
ordinary software.

paul

Re: Reproducing old machines with newer technology

[Chuck Guzis]

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 pretty much entirely within the PPUs. 
PPUs have autonomous access to the entire memory space of the CPU and 
use the "exchange jump" to switch it to a task.


What was the stumbling block was that this was incompatible with virtual 
memory schemes and other similar arrangements that fragmented the memory 
space of the CPU.  Transient real-time tasks, whose existence could be 
measured in a millisecond or two were also unsuited for this setup.


The point is if the PP setup had been limited to I/O, the CPU with no 
privileged mode (at the time; eventually a "monitor mode" was 
introduced) would have been useless for most purposes.  In fact, if an 
address violation or arithmetic fault occurred, the CPU would store the 
reason and just half.  To issue a request to the PP OS, a CPU program 
would store a request in word 1 of its field length and then hang.


--Chuck

Re: Reproducing old machines with newer technology

[William Donzelli]

> 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

Re: Front Panel Update

[Tom Moss]

Hi Rod,

The only kit I'm aware of is Grant Stockly's. AFAIK he's not been replying
to emails for about five years. There's also Mike Douglas's Altair Clone,
but that panel won't fit.

Here's the scan:
http://www.vintage-computer.com/images/altairfrontpanelscan.jpg

Just to be clear, I'm only looking to get my existing panel re-stenciled,
but I believe there's a couple of folks on the VCForum who are looking for
new ones. I'm in England, so postage shouldn't be a problem for me.

-Tom

On 14 July 2015 at 22:26, Rod Smallwood 
wrote:

> Hi Tom
>   I had thought somebody had done one (or it was part of a kit)
> However I cant find
> anything about it. So lets have a look at  your scan.
>
> Regards
> Rod
>
>
>
> On 14/07/2015 19:44, Tom Moss wrote:
>
>> Hi Rod,
>>
>> Any chance I could commission you to do an Altair 8800 panel?
>> The silkscreen has almost completely worn off on mine, but I have a
>> high-quality scan of a good one.
>>
>> -Tom
>>
>> On 14 July 2015 at 19:20, Rod Smallwood 
>> wrote:
>>
>>  Hello Everybody
>>>   In the course of doing the artwork for 8/e
>>> type B
>>> I have turned up some more variations.
>>>
>>> The list  now looks like this:
>>>
>>> 1. Switch position markings
>>> 2. Line round switch area
>>> 3. The EMA title block isolated from the other titles
>>> 4. Lines between groups of three lamps
>>> 5. lab8/e instead of pdp8/e
>>>
>>> So far I can't find any reasons as to why these variations seem to be
>>> random.
>>> The only thing that is not cosmetic is the two types of switch position.
>>>
>>> I am minded to add all of variatons (excluding lab8/e) because they seem
>>> progressive:
>>>
>>>  No line round the switch areabecomes line round the switch
>>> area
>>>  EMA title attached  becomes EMA title
>>> detached
>>>  No lines between lamps becomes lines between lamps
>>>
>>> Then produce two versions based on the switch position
>>>
>>> The issue is of course small batch costs.
>>>
>>> Comments gentlemen please
>>>
>>> Rod
>>>
>>>
>>>
>

Re: FS: Apple IIGS, C64, Intel OpenStep Boxes, DOS Gaming rigs & more

[Tom Moss]

Wow, Landon's still at it after 12 years?
You'd have thought he'd have a life by now...

On 14 July 2015 at 21:38, Todd Goodman  wrote:

> Anyone contemplating dealings with Mr. Landon should check Google and
> archives of this mailing list.
>
> He's a thief.
>
> * drlegendre .  [150713 21:42]:
> > Sent you a private email, Steve. Let me know if you don't see it..
> >
> > On Mon, Jul 13, 2015 at 5:51 AM, Steven Landon 
> wrote:
> >
> > > Clearing out more of the collection that never gets used- everything
> works
> > > perfectly and is cosmetically in good condition. Prices are make an
> offer,
> > > i just want to see this stuff go to a good home
> > >
> > > Apple IIGS ROM 03
> > > 4MB RAM Card
> > > CFFA 3000 Card
> > > 2x 3.5inch FDDs
> > > 1x  5.25inch FDD
> > > AE Conserver-  Allows you to sit 2 Floppy drives under the monitor and
> > > functions as a power strip
> > >
> > >
> > > Commodore 64
> > > C64NIC+
> > > ZoomFloppy
> > > SD2IEC Interface with 8GB SD Card
> > > JiffyDOS
> > > Cart Slot Expander from Jim Brain
> > > 1701 Monitor
> > > 2x 1541 FDDs
> > >
> > > Mac Performa 631CD
> > > 64MB RAM
> > > 500MB HDD
> > > Ethernet Card
> > > Matching 15inch Monitor
> > >
> > >
> > > NeXT Mono Slab
> > > 20MB RAM
> > > 2GB HDD
> > > Frog Monitor
> > > Non ADB Keyboard & Mouse
> > >
> > > HP 9000/712
> > > 96MB RAM 1GB HDD
> > > NeXTSTEP 3.3 Installed
> > >
> > > Sun SparcStation 5
> > > 64MB RAM
> > > 36GB HDD
> > > OpenStep 4.2 Installed
> > >
> > > 3 Intel OpenStep 4.2 Boxes
> > >
> > > Dell Dimension XPS T450
> > > 128MB RAM
> > > 10GB HDD
> > > Rage 3D Video
> > > SoundBlaster Awe32
> > > USB Card- Supported in OpenStep 4.2
> > >
> > > Dell Dimension 233mhz
> > > 32MB RAM
> > > 4GB HDD
> > > Networking
> > > OpenStep 4.2 Installed
> > > Needs SB 16 Card for Audio
> > >
> > > HP Pavilion 6630
> > > Celeron 500mhz
> > > 64MB RAM
> > > 3C905 Network Card
> > > Running OpenStep 4.2
> > > Needs SB 16 Card for Audio
> > >
> > >
> > > DOS/Win Gaming Rigs
> > >
> > > Dell Dimension L1000R
> > > Windows 98SE
> > > 256MB RAM
> > > 20GB HDD
> > > Rage 128 Video
> > >
> > > Dell Dimension L667R
> > > 128MB RAM
> > > 15GB HDD
> > > Rage 128 Video.
> > >
> > > IBM AT Clone
> > > 40MB HDD
> > > 640K RAM
> > > 5.25 and 3.5 Drives
> > >
> > >
> > > Parts & Stuff
> > >
> > > 10 36GB SCA SCSI Hard Drives
> > > Sun Caddy Load external SCSI CD-ROM
> > > Sony External SCSI CD-ROM
> > > 4x Zip Drives,  2 Parallel 2 SCSI with 20 zip disks
> > > Syquest EZ135 Drive with 15 Carts
> > >
> > > Medium Flat rate boxes filled with DSDD 3.5inch Disks 5.25inch Disks
> and
> > > 3.5in HD Disks
> > >
> > > 6 Large totes filled with SCSI Cables,  AC Adapters,  Ethernet Cables,
> > > You name it
> > >
> > >
> > > There is honestly too much to list.. Thats just a sampling of whats
> here
> > > in parts and accessories.
> > >
> > > Thanks
> > >
> > > Steve
> > >
>

Re: Reproducing old machines with newer technology

[Chuck Guzis]

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--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 could order a CPU-less system. (6416?)


You can still see the general scheme implemented today on the Parallax 
Probeller MPU, which, some, I'm sure will tell you, is a pretty nifty 
design.


--Chuck

Re: PDP-12 at the RICM

[Johnny Billquist]

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 use at
 one time.


??? What segments??? The PDP-11 have a plain simple page table. No segments 
anywhere in sight. And each page is 8K.


To me, “segment” means a chunk of memory.  It doesn’t refer to separate page 
tables, or page tables broken into pieces.  And as I recall, the terms 
“instruction and data segments” were in common use to describe the feature.


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.


The 8086 have both an instruction and a data segment, which just means 
that some instructions refer to data, and that uses the data segment 
register, while instructions (obviously) are addressed through the 
instruction segment register. I never worked with the 8086, but don't it 
actually also have a third segment register? Not that I can remember 
what it was used for... Oh, and all references are relative to the 
segment register (should be obvious, but I figured I should point it out.)



The PDP-11 is a bit unusual in that each page is *up to* 8k, the actual size 
(and whether it’s the lower or the upper part that is accessible) is specified 
by the page description register for that page.  Also in that the physical 
address of the page isn’t constrained to a multiple of the (max) page size.


Yes, the fact that pages on a PDP-11 do not have to be the full 8K is a 
bit special. Or, was. Machines nowadays are actually more reminding me 
of the PDP-11 than other contemporary systems. Today we are once more at 
really large page sizes, and actually variable length pages. I don't 
remember if page physical address needs to be on a multiple of the page 
size on todays machines, but since page sizes can vary I don't think so. 
So very much like the PDP-11...


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: PDP-11 pages/segments/etc (Was: PDP-12 at the RICM)

[Johnny Billquist]

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 think of any
other machine where pages are variable size. (I know of a couple which offer
_two_ page sizes, but none that have a field per page which specifies the
length of the page.)


While the pages are variable in length, each page starts at an 8K 
virtual address boundary. And each page has a page table entry.
Oh, and actually, the pages are not entirely variable in size. They can 
only go up to 8K, which is where the next page starts.


SO it's purely that the pages are not a fixed and inflexible as on some 
other machines, but each page is totally independent of the other pages, 
and each works the same way, and is strictly mapped from the virtual 
address.



They really are more like what most machines call 'segments'. I know Unix
doesn't use them that way (because it has such a simple-minded memory model),
but other systems do - e.g. MERT.


I couldn't disagree more. :-)
If you only had one page, and that page covered the full virtual address 
space, then I would agree that it was a segment model.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: Reproducing old machines with newer technology

[William Donzelli]

> 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 could order a
> CPU-less system. (6416?)

What was the point of that machine? For people doing OS development only?

--
Will

Re: PDP-12 at the RICM

[Sean Conner]

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.
> 
> The 8086 have both an instruction and a data segment, which just means 
> that some instructions refer to data, and that uses the data segment 
> register, while instructions (obviously) are addressed through the 
> instruction segment register. I never worked with the 8086, but don't it 
> actually also have a third segment register? Not that I can remember 
> what it was used for... Oh, and all references are relative to the 
> segment register (should be obvious, but I figured I should point it out.)

  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 instructions dealing with memory with any of the
segment registers:

mov ax,[foo]; load AX from memory location DS:foo
mov bx,es:[bar] ; load BX from memory location ES:bar
mov cx,cs:[baz] ; load CX from memory location CS:baz
mov dx,ss:[snafu]   ; load DX from memory locaiton SS:snafu

  On the 8086 and 80186, the contents of the segment registers are shifted 4
bits to the left then added to the offset (total 20 bit offset).  Starting
with the 80286, in protected mode, the segment registers are actually
indexes into one of two tables (the GDT (global descriptor table) or LDT
(local descriptor table)) and are not actual addresses.

  -spc (God!  I still remember this stuff?)

Re: PDP-12 at the RICM

[Johnny Billquist]

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. Essentially all memory is
one chunk.

The 8086 have both an instruction and a data segment, which just means
that some instructions refer to data, and that uses the data segment
register, while instructions (obviously) are addressed through the
instruction segment register. I never worked with the 8086, but don't it
actually also have a third segment register? Not that I can remember
what it was used for... Oh, and all references are relative to the
segment register (should be obvious, but I figured I should point it out.)


   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 instructions dealing with memory with any of the
segment registers:

mov ax,[foo]; load AX from memory location DS:foo
mov bx,es:[bar] ; load BX from memory location ES:bar
mov cx,cs:[baz] ; load CX from memory location CS:baz
mov dx,ss:[snafu]   ; load DX from memory locaiton SS:snafu

   On the 8086 and 80186, the contents of the segment registers are shifted 4
bits to the left then added to the offset (total 20 bit offset).  Starting
with the 80286, in protected mode, the segment registers are actually
indexes into one of two tables (the GDT (global descriptor table) or LDT
(local descriptor table)) and are not actual addresses.

   -spc (God!  I still remember this stuff?)


Thanks. That was way more than I actually ever wanted to know. :-) (Ok, 
I did ask...)


It should be obvious to anyone that this is very different from the MMU 
of a PDP-11... (Or at least I hope it is obvious - otherwise people are 
free to write some OS for each system and then come back with a report...)


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

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

[Jay Jaeger]

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
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.

JRJ

On 7/14/2015 11:16 AM, ben wrote:
> 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 actually individual
>> gates/chunks of DTL chips) get little behavioral models.  As I
>> mentioned, so far what I have done is reproduce and test a 12 bit
>> computer designed in an electrical engineering course on logic/computer
>> design.  In August I plan on publishing my experience on a website.
>>
>> I would note that I also see value in the behavioral approach, which
>> really would be considerably more detailed than what you get form SimH.
>>   The IBM 1410 cycle-level simulator I have written is closer to what one
>> might get from a behavioral model, but even that is not quite so
>> detailed.
>>
>> 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, including the latch getting folded into the
>> look up tables for gates which use the signal, and issues when one
>> brings such a signal out to an I/O pin to feed to a logic analyzer,
>> which can cause problems to appear and disappear.  My experience is that
>> one can add a D flip flop after the RS latch.  This typically works
>> because at 50 Mhz, it adds only 20 ns delay, which is comparable to gate
>> delays these old machines typically had.
>>
>> 2)  One-shots.  I haven't had to address this one yet, but I am sure
>> that I will.  I expect that one can simply use a counter to handle it -
>> no big deal at all.
>>
>> 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 a counter.  Since the counter
>> flip flops did not all change at exactly the same time, that signal
>> could glitch during the simulated machines master clock edge.  They
>> respond well to the same general solution as #1 - stick a D flip flop
>> between the combinatorial output and the clock input.  In the case I
>> mentioned, that gave the signal an entire 50 Mhz clock period to settle
>> down.
>>
>> And of course, getting the detailed information one needs to develop
>> such a model can be a challenge.  Fortunately for the older IBM
>> machines, IBM produced ALDs - Automated Logic Diagrams - which I hope
>> will generally have enough information.
>>
>> My experience on FPGA forums during the development of my 12 bit
>> computer implementation was mixed.  I got some helpful comments, but the
>> majority of folks were not helpful, and instead preferred to bash me for
>> not redoing the entire machine design using FPGA's the way these
>> particular folks felt was "the only right way" to use them.  Bah.
>>
>> JRJ
> 
> I have felt the right way is NOT to use VHDL or VERLOG  sadly. I use
> altera and using AHDL is the best for me as it cleanest language so far.
> FPGA's have never been standard logic, so why force standards, if you
> can not even agree on gates latches and flipflops in fpgas.
> 
> Here is the link you have been waiting for, IBM 1130 in FPGA and in the
> FLESH.
> http://ibm1130.blogspot.ca/
> 
> Ben.
> PS: Don't use blog format for the web site, they are a pain to read
> or search if what you want is more than few years old.
> 
> 
> 
> 

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

[Paul Koning]

> 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 quite
>> good; it lets you see obscure details that are not documented and
>> certainly not visible in a software simulator.  The example I like to
>> point to is the 6000 property that you can figure out a PPU 0 hard
>> loop by doing a deadstart dump and looking for an unexpected zero in
>> the instruction area: deadstart writes a zero where the P register
>> points at that time.  But you won’t find that documented or explained
>> anywhere.  The FPGA model derived from the schematics reproduces this
>> behavior, and when you look at how it happens, the explanation
>> becomes blindingly obvious.  *This* is why I feel there’s a point in
>> doing this sort of work.
> 
> I can agree with some points, but not others.  In the 6600, for example, 
> clock distribution was a big design issue--not so in an FPGA.  You had racks 
> of taper-pin mats of wiring between the cordwood moules extending over (by 
> today's standards) long distances.  Cooling was a huge issue. In those 
> respects, an FPGA hardly resembles a "real" 6600.

Certainly, the physical aspects are completely different.  And clock 
distribution, certainly.  Not so much between chassis, interestingly enough, 
but throughout the logic within a chassis.  And wire delays in chassis to 
chassis cabling are very significant.  Wire delays within the chassis, in a few 
cases, but 99% of the  wires are short enough that their delay is not a real 
consideration in comparison with the logic circuit stage delay.

The example I gave, and others like it, are properties of the detailed logic 
design, they are not dependent on the details of the timing closure, or the 
physical design of the machine.

paul

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

[William Donzelli]

> 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

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

[Jay Jaeger]

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 combinatorial loop.  The problems
>> this causes are several, including the latch getting folded into the
>> look up tables for gates which use the signal, and issues when one
>> brings such a signal out to an I/O pin to feed to a logic analyzer,
>> which can cause problems to appear and disappear.  My experience is that
>> one can add a D flip flop after the RS latch.  This typically works
>> because at 50 Mhz, it adds only 20 ns delay, which is comparable to gate
>> delays these old machines typically had.
> 
> I didn’t like what happened with flops built out of gates when doing my 6600 
> model.  So I replaced those by behavioral models.  The main reason was that 
> the crossed-gate model would produce a mess with R and S both asserted, which 
> that design would do at times, while the behavioral model was written to do 
> something specific for that case.

The approach I have used is a compromise between the two - it isolates
the problems building flip flops out of gates, while still preserving
the original design.  That said, when I come across a flip flop on an
SMS card, I will probably build it its own behavioral model.


>>
>> 2)  One-shots.  I haven't had to address this one yet, but I am sure
>> that I will.  I expect that one can simply use a counter to handle it -
>> no big deal at all.
> 
> If you’re creating a model to run in simulation, you can just write a delay.  
> But that’s not synthesizable, so if you really do need a delay then a 
> counter, or a shift register, or something like that will be needed.  This is 
> the sort of thing that makes a 6600 design tricky (and may also apply to some 
> other fast machines): there are places where propagation delays are used for 
> correctness, and if the replacement hardware is “too fast” it doesn’t work.
> 

I am creating one to be sythesizable.

>>
>> 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 a counter.  Since the counter
>> flip flops did not all change at exactly the same time, that signal
>> could glitch during the simulated machines master clock edge.  They
>> respond well to the same general solution as #1 - stick a D flip flop
>> between the combinatorial output and the clock input.  In the case I
>> mentioned, that gave the signal an entire 50 Mhz clock period to settle
>> down.
> 
> 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.

That is just it - the combinatorial inputs were used FOR the clock on
some gates.  Right - not a good idea even back in 1972, though it
depends a little on what the rejection time / intertial delay of the
inputs are, but yes - certainly a design that would be prone to failure
(remember that this was a bunch of students trying to put together a
working 12 bit computer in about a month - ours included a cross
assembler and cross-interpreter, so we had real software running our
machine for its demo - including hangman played with the TTY keyboard
and an oscilloscope hooked to a pair of D/A converters for a display).

> 
>   paul
> 
> 

Re: Reproducing old machines with newer technology

[Chuck Guzis]

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 more of a peripheral device.  In fact, you could order a
CPU-less system. (6416?)


What was the point of that machine? For people doing OS development only?


More aimed at expanding the I/O capabilities.  You could, for example, 
hook the 6416 up to a couple million words of ECS.  Remember too, that 
CDC thrived on QSEs.


--Chuck

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

[Jay Jaeger]

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 architecture, when
> pretty much the same result could be obtained by running a software
> emulator?  Neither accurately reflects the details of the real
> thing--and there will always be the aspect of missing peripherals.

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.

And it would at least reflect how the original hardware worked.  There
is a continuum here:

Software "just make it work" emulator.  (Most of SimH stuff seems to be
at this level).

Software "make it use the same cycles" simulator.  (This is what I write
simulators to).

A logic model which has the same behavior as the original
(this would be sort of like a 360/50 does the same thing as a 360/65
kind of comparison).

A logic model which is structurally the same as the original, and thus
provides a portable and verifiable model (if you have the software) of
the original design.

> 
> Perhaps the worst aspect of using FPGA is that this is a rapidly moving
> field, so that the part you used to do your implementation 10 years ago
> will no longer be available.I've done a few designs using 5V CPLDs
> (XC95xx series) not *that* long ago.  Now they themselves are quaint
> examples of obsolete hardware.  You can't win.

That is why I use VHDL (or Verilog is fine to).  So that those models
are portable into the future.   The FPGA part doesn't matter so much,
but the model future portability does matter.

> 
> You can move software-only simulators quite easily, but I'm not as
> sanguine about FPGA designs.
> 
> And you still don't have the peripherals.  I suppose one could emulate a
> Univac Solid State machine in FPGA, but what would one do about the
> all-important drum coupled to the card reader and printer.  Has anyone
> rolled out a design for a DIY 1403 printer?

1403's and IBM 729's and 1402 card read/punch still exist.  I seem to
recall the CHM doing something like building a 729 tape drive tester, too.

> 
> 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.

But something like the SBG 6120 PDP-8 is closer, potentially with real
lights and switches.  As another I example, I can envision an FPGA
sitting inside a real IBM 1415 console, running it's lights, responding
to it's switches and interacting with it's selectric typewriter.
Probably more than I will accomplish, but it is good to have goals.

> 
> --Chuck
> 
> 
> 

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

[Paul Koning]

> 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 a counter.  Since the counter
>>> flip flops did not all change at exactly the same time, that signal
>>> could glitch during the simulated machines master clock edge.  They
>>> respond well to the same general solution as #1 - stick a D flip flop
>>> between the combinatorial output and the clock input.  In the case I
>>> mentioned, that gave the signal an entire 50 Mhz clock period to settle
>>> down.
>> 
>> 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.
> 
> That is just it - the combinatorial inputs were used FOR the clock on
> some gates.  Right - not a good idea even back in 1972, though it
> depends a little on what the rejection time / intertial delay of the
> inputs are, but yes - certainly a design that would be prone to failure
> (remember that this was a bunch of students trying to put together a
> working 12 bit computer in about a month - ours included a cross
> assembler and cross-interpreter, so we had real software running our
> machine for its demo - including hangman played with the TTY keyboard
> and an oscilloscope hooked to a pair of D/A converters for a display).

Good points.  So my conclusion is that the best answer depends on the design 
you’re trying to copy.  If it uses this sort of tricks, or this sort of “well, 
it worked once” style of design, then you’re going to have a harder time.  If 
the design is basically sound synchronous logic, as in the case of the 6600 
(once you look hard enough) then it’s not such a problem.  Not so long as you 
avoid oddities like the original clock (serial numbers 1-7 only) which is a 
ring oscillator of 4 double inverters and 4 well chosen lengths of wire.  But 
serial numbers 8 and up replace that by a proper crystal clock, so that’s the 
one I use (substituting the FPGA external clock input for the one on the ECS 
Controller).

paul

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

[Jay Jaeger]

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 something that I would do, but it certainly 
> was done in production machines. 
> With care you can determine the width of the glitch, and if it's small 
> enough, ignore it. 


Yeah, and this original design was a bunch of pre-newbie students just
trying to get the darn thing to work by hook or by crook.  ;)  Hey - at
least we did a good enough job of documenting it that it was possible to
reproduce!

> 
> But there is a related problem with FPGAs. You learn in introductory digital 
> electronic courses that there are
> 2 types of counter. The Asynchronous, or ripple, counter where each flip-flop 
> toggles the next when it goes
> from 1 to 0. Obviously those do not all change at once, so if you combine 
> them with gates there can be 
> quite large glitches. Then there is the synchronous counter where all 
> flip-flops are clocked together. Now to a
> good approximation (all the flip-flops have the same delay from clock to 
> output), they do all change together.
> So if you now combine the outputs (say you AND some of the Q and Q/ outputs 
> to decode a particular state)
> the glitches will be small. That's what is taught. That is what works with 
> TTL, ECL, etc.
> 
> Now try it in an FPGA (at least the Xilinx ones I've used). You will find 
> glitches all over the place. The reason
> is that the 'wires' linking the outputs of the flip-flops to the gates are 
> not wires at all. They are paths on the
> chip through logic multiplexers, buffers, etc that are set when the chip is 
> configured. And they introduce
> delays. Delays that are enough to cause glitches that are wide enough to 
> trigger other flip-flops.
> 
> 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 slow enough.  It works, in part, because the FPGA's are
sooo much faster than the original design, that you can use the
"trailing D flip flop" approach I described to convert the former into
the latter - the glitches occur on the time scale of the FPGA logic, but
are gone by the time the next simulated machine clock arrives.

For a much faster legacy design that was not done fully synchronously,
it would be much more difficult, I agree.  But fortunately for me the
machine's I am interested in had clocks on the order of 1 to 10 Mhz and
propagation delays of 10 or more ns, such that the 50Mhz clock on my
FPGA and tiny tiny propagation delays don't cause headaches once you
learn how to deal with them.

> 
> -tony
> 
> 
> 
> paul
> 
> 

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

[Jay Jaeger]

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.  So there are multi phase clocks everywhere, 
>> with consecutive latch points 
>> clocked by the consecutive phases.  That means that so long as the max 
>> latency is < the clock phase
>> difference, it always works.
> 
> 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
> it will not work.

It will work if you modify it by applying some simple rules, such as I
have described, because I have done so.  Of course, it is possible that
I have more rules to uncover.  ;)

> 
> -tony
> 

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

[Jay Jaeger]

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 FE trusted me to swap out
Selectrics, including plugging their paddle cards into the SMS slot on
the console.  It was my first "real" job.

If it were not for me with assistance from Paul Pierce, this tape (and a
couple of others also on Paul's site) probably would not have been
recovered, and the software for this machine would be lost to most folks:

http://www.piercefuller.com/library/kpr155.html


On 7/14/2015 6:30 PM, William Donzelli wrote:
>> 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
> 

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

[Eric Smith]

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 five "clocks delayed from each other" (more
commonly known as clock phases). In my experience that was more common
in 1970s computers than a single-phase clock.

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

[William Donzelli]

> 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

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

[Jay Jaeger]

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 (which had 10 foot cables in between).

On 7/14/2015 7: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
>> 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 five "clocks delayed from each other" (more
> commonly known as clock phases). In my experience that was more common
> in 1970s computers than a single-phase clock.
> 

Re: Reproducing old machines with newer technology

[Jay Jaeger]

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 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--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 could order a CPU-less system. (6416?)
> 
> You can still see the general scheme implemented today on the Parallax
> Probeller MPU, which, some, I'm sure will tell you, is a pretty nifty
> design.
> 
> --Chuck
> 
> 
> 

Re: PDP-11 pages/segments/etc (Was: PDP-12 at the RICM)

[Noel Chiappa]

> 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 small, ranging from 512 bytes to 1K words. No other machine was
even _close_ to 8KB.

In other machines, the page was the fundamental unit of memory allocation; on
PDP-11's, that unit is the click (0100 bytes).

> If you only had one page, and that page covered the full virtual
> address space, then I would agree that it was a segment model.

That's only true in the brain-damaged x86 model, in which 'segments' were
added as a kludge to expand the address space.

If you study _real_ segmented architecture machines, like the GE645, NS32K,
etc you will discover that in them, a segment is a fixed-size chunk of the
total (much larger) address space, and they start at fixed offsets in that
space. A segment which is less than full-sized leaves a gap in the address
space before the (fixed) start of the next segment.

All of which sounds just like the 'pages' in the PDP-11...

Noel

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

[Chuck Guzis]

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 of machines that are impossible to find.  And many that 
are gone that are quite novel.  That IBM sold so many is something in 
their favor, but how about a working Saxpy box--which is quite a bit 
more recent than your 1410?  Or the STAR-65, 1B or even -100.  The only 
65 was moved from Canada and scrapped.  My department had the only two 
1Bs and I saw those go under the sledgehammer and bolt cutters. I don't 
think that there are STAR-100s of any stripe (plain, -A, -B or -C) 
left--they were just too big.  Are there any BSPs or ASC's kicking around?


There are tons of lost non-IBM peripherals.

But we do have documentation on many of these things, so at least we 
know "how" they worked.  And I submit that in the long run, that's what 
matters.  There's very little relevant to the state of the art today 
that really matters. (Boy, am I going to get flamed on that)



Software "just make it work" emulator.  (Most of SimH stuff seems to be
at this level).


Or dedicated simulators (non-SIMH).  Often, all you have is the system 
documentation that talks about the instruction set and a few binary 
files.  Reverse-engineering can be fun and valuable.



That is why I use VHDL (or Verilog is fine to).  So that those models
are portable into the future.   The FPGA part doesn't matter so much,
but the model future portability does matter.


Maybe, but I'd rather read the design documents than a pile of HDL of 
any stripe.



1403's and IBM 729's and 1402 card read/punch still exist.  I seem to
recall the CHM doing something like building a 729 tape drive tester, too.


But there were LOTS of those.  Try something non-IBM and very obscure.


But something like the SBG 6120 PDP-8 is closer, potentially with real
lights and switches.  As another I example, I can envision an FPGA
sitting inside a real IBM 1415 console, running it's lights, responding
to it's switches and interacting with it's selectric typewriter.
Probably more than I will accomplish, but it is good to have goals.


A PDP-8 is a simple CPU, probably popular because of the lights and 
switches. I see evidence that these were eye candy--the DECStations are

practically the same thing, but apparently not nearly as desirable.

Seymour Cray should have used kinetic sculptures on his machines as part 
of eye candy, I guess. Or maybe more chrome...


--Chuck

Re: Reproducing old machines with newer technology

[Chuck Guzis]

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

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

[Jon Elson]

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, they did not use flip-flops like we 
are used to, today.  They used latches, making it a 
requirement that there be at least two clock phases in most 
of the CPU, so that data into the ALU, for instance, 
remained stable when some register at the output was 
clocked.  Since these were discrete transistor 
implementations, a real flip-flop was too expensive, but a 
latch could be implemented in about 6 transistors, I think.


The 11/45 used TTL ICs, so real FFs were available in that 
technology, although they may have used latches as well.


Jon

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

[ben]

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 memory on a FPGA 
card.



--Chuck


Ben.

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

[Jay Jaeger]

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 test it with.  So I have a way to verify the
functional correctness of the reproduction.

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 sold.

Software wise, the PR-155 OS for the 1410 was pretty decent for a design
that started in the early 1960s.  It could do multi-programming, both
for I/O spooling operations and for tele-processing, with swappable
transient TP programs along side batch operations, if you had the
memory.   The machine I worked on was only 40,000 BCD characters, but
ran the full operating system (sans TP).

Dumb channels though (simple FSM's - no program-ability), which kept the
size of the machine and its cost down.

More below.

JRJ

On 7/14/2015 8:31 PM, Chuck Guzis wrote:
> 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 of machines that are impossible to find.  And many that
> are gone that are quite novel.  That IBM sold so many is something in
> their favor, but how about a working Saxpy box--which is quite a bit
> more recent than your 1410?  Or the STAR-65, 1B or even -100.  The only
> 65 was moved from Canada and scrapped.  My department had the only two
> 1Bs and I saw those go under the sledgehammer and bolt cutters. I don't
> think that there are STAR-100s of any stripe (plain, -A, -B or -C)
> left--they were just too big.  Are there any BSPs or ASC's kicking around?
> 

I am not interested in recent.  Indeed, if I did anything after the
1410, I'd probably go sideways or backwards in time.  I'll leave them to
you.  ;)

> There are tons of lost non-IBM peripherals.
> 
> But we do have documentation on many of these things, so at least we
> know "how" they worked.  And I submit that in the long run, that's what
> matters.  There's very little relevant to the state of the art today
> that really matters. (Boy, am I going to get flamed on that)
> 

No, you are correct.  This has nothing to do with the state of the art.
 This is a hobby/historical documentation effort.  But as I mentioned in
the earlier note the "how they worked" comes in levels, and my effort is
at a lower level of abstraction / higher level of detail.

>> Software "just make it work" emulator.  (Most of SimH stuff seems to be
>> at this level).
> 
> Or dedicated simulators (non-SIMH).  Often, all you have is the system
> documentation that talks about the instruction set and a few binary
> files.  Reverse-engineering can be fun and valuable.
> 
>> That is why I use VHDL (or Verilog is fine to).  So that those models
>> are portable into the future.   The FPGA part doesn't matter so much,
>> but the model future portability does matter.
> 
> Maybe, but I'd rather read the design documents than a pile of HDL of
> any stripe.
> 

To each is own.  Enjoy.

>> 1403's and IBM 729's and 1402 card read/punch still exist.  I seem to
>> recall the CHM doing something like building a 729 tape drive tester,
>> too.
> 
> But there were LOTS of those.  Try something non-IBM and very obscure.

Well, if I had more money I might have snagged a CDC-160A a few years
back (it went for over twice what I could afford at the time - I maxed
out at $2k), and I'd probably be doing that one, but, such is life.

> 
> A PDP-8 is a simple CPU, probably popular because of the lights and
> switches. I see evidence that these were eye candy--the DECStations are
> practically the same thing, but apparently not nearly as desirable.

The PDP-8 variants are popular with collectors for a number of reasons.
 Approachable physical size is one.  Ordinary TTL is another.  Speeds
that folks can deal with and lack of overall complexity is yet another
reason.  A console that can help debugging is yet another. The first
machine in my collection is a PDP-8/L for all of those reasons.

(Interestingly, the IBM 1410 console tells much more about what is going
on in the machine that might be at first apparent - the entire machine
state (aside from memory) is pretty much there, but presented in a way
that is quite different than what one sees on a PDP-8)

RE DECStaions: I think what you mean are the DECMates, but yes: they
indeed used the Intersil chip sets.

> 
> Seymour Cray should have used kinetic sculptures on his machines as part
> of eye candy, I guess. Or maybe more chrome...
> 
> --Chuck
> 
> 

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

[Jay Jaeger]

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 based
IBM 1410 as the SLT based IBM 1130 - particularly the way latches were used.

Thanks.

JRJ

Re: Reproducing old machines with newer technology

[William Donzelli]

> 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

Re: PDP-11 pages/segments/etc (Was: PDP-12 at the RICM)

[Johnny Billquist]

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 had virtual memory: normally, page
sizes were small, ranging from 512 bytes to 1K words. No other machine was
even _close_ to 8KB.


Ugh. When people start using arguments like "real pages", I see things 
going ugly real fast...


To argue more, the page size of the PDP-10 is 512 36-bit words, which is 
5KB in size. I'd say that is not so far from 8K.
And if people actually start digging around, I'm sure you'll find that 
8K was not at all extreme. 512 byte pages were way more radical when the 
VAX was introduced.



In other machines, the page was the fundamental unit of memory allocation; on
PDP-11's, that unit is the click (0100 bytes).


I fail to see the relevance in that with regards to a pages vs. a 
segmented design. And actually, the size or variable size of a page is 
also of little relevance.



 > If you only had one page, and that page covered the full virtual
 > address space, then I would agree that it was a segment model.

That's only true in the brain-damaged x86 model, in which 'segments' were
added as a kludge to expand the address space.

If you study _real_ segmented architecture machines, like the GE645, NS32K,
etc you will discover that in them, a segment is a fixed-size chunk of the
total (much larger) address space, and they start at fixed offsets in that
space. A segment which is less than full-sized leaves a gap in the address
space before the (fixed) start of the next segment.

All of which sounds just like the 'pages' in the PDP-11...


Uh? When did the NS32K become a segmented architecture???
http://cpu-ns32k.net/MMUs.html.
But I see your point. If you designate that CPU as having a segmented 
memory, then I guess I can see why also put the PDP-11 in there. But 
then I don't understand why you don't also include the VAX.


Yes, there are some things in segmented memory management that maps well 
with the PDP-11, but other parts do not. You normally do not write code 
to exist as a segment, using even the implicit reference you get from 
being in a specific page as a segment register (apart from being very 
hard to actually do on a PDP-11, it would also restrict your code to max 
8K, which is rather limited). You also do not normally have holes in 
your memory, even if it is technically possible.

That would just be an insane way to look at your memory.

On a PDP-11, you look at memory as a flat address space. Have the 16-bit 
virtual address space, and the 18/22 bit physical address space. You do 
not treat it as segments that somehow is related to, and describes, 
segments of code.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

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

[ben]

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 their machines.


On the system 360 CPUs, they did not use flip-flops like we are used to,
today.  They used latches, making it a requirement that there be at
least two clock phases in most of the CPU, so that data into the ALU,
for instance, remained stable when some register at the output was
clocked.  Since these were discrete transistor implementations, a real
flip-flop was too expensive, but a latch could be implemented in about 6
transistors, I think.



I guessing ( no schematic handy) that they made the 360 register file
easy to decode and build with latches.


The 11/45 used TTL ICs, so real FFs were available in that technology,
although they may have used latches as well.


I have seen some 11/?? schematics on bitsavers that the alu uses AOI gates
and includes a latch term.


Jon


Ben.

Re: FS: Apple IIGS, C64, Intel OpenStep Boxes, DOS Gaming rigs & more

[drlegendre .]

Ouch.. thanks for the update.

I sent him an email asking for a price on essentially all of the Commodore
stuff, less the monitor and floppy drives (have plenty of both, and too
heavy to pay for ship).

He said that he wouldn't split up the lots.. which is a little odd, as
everything else in the lot would ship for less than one 1541 drive. Oh
well, at least I didn't lose any $$.

On Tue, Jul 14, 2015 at 3:38 PM, Todd Goodman  wrote:

> Anyone contemplating dealings with Mr. Landon should check Google and
> archives of this mailing list.
>
> He's a thief.
>
> * drlegendre .  [150713 21:42]:
> > Sent you a private email, Steve. Let me know if you don't see it..
> >
> > On Mon, Jul 13, 2015 at 5:51 AM, Steven Landon 
> wrote:
> >
> > > Clearing out more of the collection that never gets used- everything
> works
> > > perfectly and is cosmetically in good condition. Prices are make an
> offer,
> > > i just want to see this stuff go to a good home
> > >
> > > Apple IIGS ROM 03
> > > 4MB RAM Card
> > > CFFA 3000 Card
> > > 2x 3.5inch FDDs
> > > 1x  5.25inch FDD
> > > AE Conserver-  Allows you to sit 2 Floppy drives under the monitor and
> > > functions as a power strip
> > >
> > >
> > > Commodore 64
> > > C64NIC+
> > > ZoomFloppy
> > > SD2IEC Interface with 8GB SD Card
> > > JiffyDOS
> > > Cart Slot Expander from Jim Brain
> > > 1701 Monitor
> > > 2x 1541 FDDs
> > >
> > > Mac Performa 631CD
> > > 64MB RAM
> > > 500MB HDD
> > > Ethernet Card
> > > Matching 15inch Monitor
> > >
> > >
> > > NeXT Mono Slab
> > > 20MB RAM
> > > 2GB HDD
> > > Frog Monitor
> > > Non ADB Keyboard & Mouse
> > >
> > > HP 9000/712
> > > 96MB RAM 1GB HDD
> > > NeXTSTEP 3.3 Installed
> > >
> > > Sun SparcStation 5
> > > 64MB RAM
> > > 36GB HDD
> > > OpenStep 4.2 Installed
> > >
> > > 3 Intel OpenStep 4.2 Boxes
> > >
> > > Dell Dimension XPS T450
> > > 128MB RAM
> > > 10GB HDD
> > > Rage 3D Video
> > > SoundBlaster Awe32
> > > USB Card- Supported in OpenStep 4.2
> > >
> > > Dell Dimension 233mhz
> > > 32MB RAM
> > > 4GB HDD
> > > Networking
> > > OpenStep 4.2 Installed
> > > Needs SB 16 Card for Audio
> > >
> > > HP Pavilion 6630
> > > Celeron 500mhz
> > > 64MB RAM
> > > 3C905 Network Card
> > > Running OpenStep 4.2
> > > Needs SB 16 Card for Audio
> > >
> > >
> > > DOS/Win Gaming Rigs
> > >
> > > Dell Dimension L1000R
> > > Windows 98SE
> > > 256MB RAM
> > > 20GB HDD
> > > Rage 128 Video
> > >
> > > Dell Dimension L667R
> > > 128MB RAM
> > > 15GB HDD
> > > Rage 128 Video.
> > >
> > > IBM AT Clone
> > > 40MB HDD
> > > 640K RAM
> > > 5.25 and 3.5 Drives
> > >
> > >
> > > Parts & Stuff
> > >
> > > 10 36GB SCA SCSI Hard Drives
> > > Sun Caddy Load external SCSI CD-ROM
> > > Sony External SCSI CD-ROM
> > > 4x Zip Drives,  2 Parallel 2 SCSI with 20 zip disks
> > > Syquest EZ135 Drive with 15 Carts
> > >
> > > Medium Flat rate boxes filled with DSDD 3.5inch Disks 5.25inch Disks
> and
> > > 3.5in HD Disks
> > >
> > > 6 Large totes filled with SCSI Cables,  AC Adapters,  Ethernet Cables,
> > > You name it
> > >
> > >
> > > There is honestly too much to list.. Thats just a sampling of whats
> here
> > > in parts and accessories.
> > >
> > > Thanks
> > >
> > > Steve
> > >
>

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

[Chuck Guzis]

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 sold.


Not by a long shot, it was followed by the 7000-series machines, namely 
the 7070 and 7080 (I have a soft spot for the 1620 myself) and 
ultimately variable length BCD was included in the S/360 and later series.


Having programmed 1401s, I'll grant that the architecture was pretty 
different from what we're used to today, but typical for a small machine 
of the time.


--Chuck

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

[Jon Elson]

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, storage data register, the 
temp registers that held the data from

a selected local store register, etc. were ALL latches.

By the way, the 360/30 through the 360/50 did not have an 
electronic register file (local store in
IBM terminology).  On the 360/30, they were implemented in a 
separately-addressed extension to
main storage.  On the 360/40 and /50, they were in a small, 
fast core memory unit.  So, on all these machines, the 
register set could only be accessed one location at a time.  
I don't know on the 360/65 whether they had dual ports to 
read the electronic registers two locations at a time, but I 
might guess not.
The 11/45 used TTL ICs, so real FFs were available in 
that technology,

although they may have used latches as well.


I have seen some 11/?? schematics on bitsavers that the 
alu uses AOI gates

and includes a latch term.

yes, the 11/45 was implemented in pretty early TTL, and the 
original 74xx family did have some 6-wide latch devices that 
used less power than the equivalent 6-wide full D FF.


Jon

Re: Reproducing old machines with newer technology

[Chuck Guzis]

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 their own ECS?


The 6416 was a special beast--I don't know that CDC ever produced any 
standard software for it. It had 16KW of CM and it's own ECS coupler, so 
I suppose that it could share ECS with other machines--but IIRC the ECS 
access was via its own special instructions.


I suspect that some 6416s just communicated with other systems using the 
6682(?) satellite coupler.  I suspect that they were largely superseded 
by the "additional PPU" machines.


I never ran into a 6416 in the flesh, but was aware of more than one 20 
PPU 6000 (there were never enough PPUs).  CDC also offered "PPU-reduced" 
models of the 6400,  with up to 3 PPUs removed, which never made any 
sense to me.


--Chuck

Re: PDP-11 pages/segments/etc (Was: PDP-12 at the RICM)

[Jerome H. Fine]

>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 processor handbook calls them 'pages', but I can't think 
of any
other machine where pages are variable size. (I know of a couple 
which offer
_two_ page sizes, but none that have a field per page which specifies 
the
length of the page.) 


While the pages are variable in length, each page starts at an 8K 
virtual address boundary. And each page has a page table entry.
Oh, and actually, the pages are not entirely variable in size. They 
can only go up to 8K, which is where the next page starts.


PLUS, as far as I remember, every page must be an exact multiple
of 64 bytes and the starting address of the page in physical memory
must be on a 64 byte boundary.  I believe that is actually a hardware
restriction since the address of a page within the MMU is the physical
address of the page divided by 64 decimal (100 octal).  In addition,
the length of the page within the MMU is the total number of bytes
again divided by 64 decimal (100 octal).  By the way, pages are
allowed to expand either upward or downward as required.

SO it's purely that the pages are not as fixed and inflexible as on 
some other machines, but each page is totally independent of the other 
pages, and each works the same way, and is strictly mapped from the 
virtual address.


It is probably possible for the hardware to support demand paging,
but I don't know of any DEC operating system for the PDP-11
which does.  The usual situation is for the job to request the memory
which it requires, then ask to operating system to MAP the physical
memory to the correct addresses as the memory is needed.  With
4 MB of physical memory in total and often only 64 KB in use at
any one time, there is usually sufficient memory to work with.

Jerome Fine

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

[Jay Jaeger]

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 apparently fixed a 7070 design which made it an orphan
pretty quick) was announced in January 1960, and the 1410 in October of
that same year.   What 7070 and 7080 actually followed were the 705 and
650.  They were also different from the 1401/1410 in that they used
fixed length instructions, rather than the variable instructions used by
the 1401/1410.

https://www-03.ibm.com/ibm/history/exhibits/dpd50/dpd50_chronology2.html

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 like Honeywell), I'm
not aware of any other machines with a similar architecture to the 1401
and 1410.  Name them?

By 1968 the System/360 had essentially toasted them all.

JRU

On 7/14/2015 10:10 PM, Chuck Guzis wrote:
> 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 sold.
> 
> Not by a long shot, it was followed by the 7000-series machines, namely
> the 7070 and 7080 (I have a soft spot for the 1620 myself) and
> ultimately variable length BCD was included in the S/360 and later series.
> 
> Having programmed 1401s, I'll grant that the architecture was pretty
> different from what we're used to today, but typical for a small machine
> of the time.
> 
> --Chuck
> 
> 

Re: PDP-12 at the RICM

[Fred Cisin]

 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 instructions dealing with memory with any of the
segment registers:


If you were writing an emulator, what would you have it do if an interrupt 
occurred while in a REP operation with a segment override?


Just how accurately should an emulator match the behavior of the emulated 
processor?

Re: PDP-12 at the RICM

[Guy Sotomayor]

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 (DS:SI as source)
 You could override instructions dealing with memory with any of the
segment registers:


If you were writing an emulator, what would you have it do if an 
interrupt occurred while in a REP operation with a segment override?


Just how accurately should an emulator match the behavior of the 
emulated processor?


It's actually described in the Intel SDM (Software Developer's Manual).  ;-)

The start of the instruction is actually the segment override (one of 
the things
that makes decoding x86 instructions hard).  Since the REP XXX 
instructions are
interruptible, the IP does not move to the next instruction until after 
it completes
(and the state of the REP XXX instruction is kept in various registers 
that are

updated on each iteration).

So, when an interrupt occurs, the execution is stopped (after the current
iteration completes) and is restarted when the interrupt returns.

TTFN - Guy

Re: PDP-12 at the RICM

[Fred Cisin]

 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 instructions dealing with memory with any of the
segment registers:
If you were writing an emulator, what would you have it do if an interrupt 
occurred while in a REP operation with a segment override?
Just how accurately should an emulator match the behavior of the emulated 
processor?


On Tue, 14 Jul 2015, Guy Sotomayor wrote:

It's actually described in the Intel SDM (Software Developer's Manual).  ;-)
The start of the instruction is actually the segment override (one of 
the things that makes decoding x86 instructions hard).  Since the REP 
XXX instructions are interruptible, the IP does not move to the next 
instruction until after it completes (and the state of the REP XXX 
instruction is kept in various registers that are updated on each 
iteration).

So, when an interrupt occurs, the execution is stopped (after the current
iteration completes) and is restarted when the interrupt returns.


That certainly sounds reasonable, but,
have you noticed the difference in behavior of 8086/8088 V 80386?

Microsoft multiuser Basic for the Altair 8800

[Kip Koon]

Hi Guys,

I have finally decided to restore my original Altair 8800 which has been in
storage for over 30 years.  Does anyone have a copy of Microsoft's Multiuser
Disk Extended Basic for the Altair 8800?  When I was in college in '79 to
'81, in the computer room was an ASR-33 Teletype and 3 Learseigler terminals
connected to an Altair 8800B.  An IMSAI was also there connected to one
ASR-33 Teletype.  I'd like to resurrect this multiuser Basic software
environment on my Altair someday once the restoration is complete.  Any help
in securing a copy of all the necessary software would be most appreciated.
Thanks a bunch in advance.  Take care my friends.

 

Kip Koon

  computer...@sc.rr.com

 
http://www.cocopedia.com/wiki/index.php/Kip_Koon

 

 

Re: PDP-12 at the RICM

[ben]

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 (DS:SI as source)
 You could override instructions dealing with memory with any of the
segment registers:


If you were writing an emulator, what would you have it do if an
interrupt occurred while in a REP operation with a segment override?

Just how accurately should an emulator match the behavior of the
emulated processor?


Halt and catch fire ... No that's 6800's.

Re: Microsoft multiuser Basic for the Altair 8800

[Fred Cisin]

On Wed, 15 Jul 2015, Kip Koon wrote:

Hi Guys,
I have finally decided to restore my original Altair 8800 which has been in
storage for over 30 years.  Does anyone have a copy of Microsoft's Multiuser
Disk Extended Basic for the Altair 8800?  When I was in college in '79 to
'81, in the computer room was an ASR-33 Teletype and 3 Learseigler terminals
connected to an Altair 8800B.  An IMSAI was also there connected to one
ASR-33 Teletype.  I'd like to resurrect this multiuser Basic software
environment on my Altair someday once the restoration is complete.  Any help
in securing a copy of all the necessary software would be most appreciated.
Thanks a bunch in advance.  Take care my friends.


How will Bill Gates feel about an unauthorized copy?