Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried all
the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no joy.
I believe this part was used on old S100 boards.
Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and
Harris 7602. Need this part to fix an old computer controlled RF Power
amplifier.
Thanks for any and all help.
Best regards, Steven
Just saw this on Ebay, don't think I've ever seen one before.
Digital model H7226-KC CVC, Constant Voltage Conditioner 290487489386
Wanted to remind everyone that Christmas is right around the corner
and this little stocking stuffer is perfect for that man with the Vax
750/780 in the basement.
Doug
On 2010-10-30 23:18, "Chuck Guzis"<cclist at sydex.com> wrote:
>
> On 29 Oct 2010 at 21:14, Johnny Billquist wrote:
>
>> > If your program vrites data to address 0, and reads it back, and get
>> > the same data back, and another program on the same machine, at
>> > roughly the same time, write to address 0, and reads the same data
>> > back, and that data is different than the first programs data, then
>> > I'd say you have virtual memory.
> So, your definition ties virtual memory into multi-user access?
> That's not the way I learned it.
No no no. You miss my point. It don't directory tie in to multiuser
access. It's about presenting to you a memory which in reality does not
exist as you perceive it. As a follow on benefit of this is the fact
that you can have multiple instances at the same time. But that is not
the definition.
The definition is that you appear to have a linear space of memory that
maps the whole virtual address range, and that this memory is yours
alone. It is your own private memory. Just as a virtual machine is your
own private machine. No matter the fact that in reality, this is not the
case, and your memory (or machine) is just something running under the
control of an underlying operating system, which gives you this service.
> Consider (again folks, I'm sorry for the reference) the CDC 6600
> (circa 1964). Every user is given a relocation address (called RA)
> and field length (FL) as a way of partitioning main memory. Each
> user's memory addressing space is kept isolated from every other's
> and this fits your definiton because one user's location X was
> different from every other user's location X and there was no way for
> a user to tell what his RA was; i.e. each user was safely "boxed in".
The important question here - are the programs aware of the RA register,
and can they change it? And can they address the full range of memory
addresses as perceived by the program.
> That's not virtual memory by any stretch of the definition. Over-
> committing memory meant writing/reading the entire FL of a user to
> disk ("rollout" and "rollin").
Another word for swapping in and out?
Anyway, I'm not sure if this would qualify as virtual memory or not
without knowing a few more details. But it might very well be virtual
memory, as far as I can tell.
> Now consider the STAR-100 (I think it would qualify as the first
> virtual memory machine of CDC), circa 1969.
Defined by whom? CDC? Or you guys? ;-)
> Every user got an
> addressing space of 48 bits, but the machine itself had only
> 512Kwords (64 bit) of physical storage. For production use, most of
> the time the system was run in single-user mode (kept thrashing down
> with large data sets). That fits my definition of VM because the
> user was fooled into thinking that there was more physical memory
> than there really was.
You know, my definition and yours don't necessarily disagree on all
points. Both would define the VAX as having virtual memory (well, except
for the fact that yours might not, if you have a VAX with enough
physical memory). We just disagree about what when there is more
physical memory than you have virtual memory space. For you, that means
it can't be virtual memory. but for me it can.
For me, what is relevant is whether the program is presented with his
own private memory space, which contains all addresses he can address,
and where all those addresses are valid and working. A memory space
which he don't have to share with anyone else. That's what virtual
memory is, as opposed to physical memory, which you can point at, and
which all running code on a computer needs to live on. And that means
that the OS is always there. And possibly other processes as well. Using
the same addresses you are. If that means that you cannot have your own
memory for a specific address, then it's not virtual memory. But then
you probably aren't talking about virtual memory either, but physical
memory.
> Aside from expanding program storage, the large addressing space was
> used to map file space (another type of "memory-mapped I/O"), so file
> access was actually performed through the paging hardware/software.
> That was kind of cool, as the STAR was a memory-to-memory vector
> machine, so you could use vector instructions on entire files, rather
> than have to issue reads and writes for pieces of a file.
>
> So I think we differ considerably in our definitions.
On some parts, yes. So, do the VAX not have virtual memory? After all, I
can fill a VAX with more physical memory than you can address virtually.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2010-10-30 01:12, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
>
>> > I have not seen anyone comment any of the other things I listed as
>> > possible firsts on the PDP-11.
>> > Can anyone come up with an earlier machine that used condition codes?
>> > How about general registers with addressing modes, which is totally
>> > orthogonal? How about having the PC as a general register?
> The Philips P800 series has the PC as a general register (register 0).
Could you use it like any other register?
> There are 16 registers, some instructions can only use the first 8, others
> can use all 16. Addressing modes (simpler than the PDP11, I admit) are
> pretty much orthogonal.
Sounds like the registers were atleast not as orthogonally used as on a
PDP-11. If an instruction could take a register, it could take any
register. And all addressing modes are valid (well, almost) anywhere.
The one exception that pops into my head is that you cannot do a
"JMP R0" on a PDP-11. (Well, there might be a model or two where it was
allowed, since some models actually exposed the registers in the address
space, and you could execute from those addresses, but that is kindof
weird).
One wonderful thing about the PDP-11, which unfortunately did not get
copied, was the nice things that happened because the PC was e general
register. Thus, the PDP-11 never had special versions of instructions to
implement immediate mode operands, and so on. All that was solved
because the PC was a general register.
(Well, the VAX sortof have it, but no other machine I know of.)
> I am not sure wheterh the PDP11 or P800 was first,m they both appeared in
> 1970 I beleive.
Would be interesting to find out more.
> What do you mean by condition codes here?
The four low bits of PSW.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
----- Original Message -----
From: <cctalk-request at classiccmp.org>
To: <cctalk at classiccmp.org>
Sent: Saturday, October 30, 2010 4:18 PM
Subject: cctalk Digest, Vol 86, Issue 68
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis)
> 2. Re: TTL HEX LED driver chip (Chuck Guzis)
> 3. Re: TRS-80 Model II Manuals (Fred Jan Kraan)
> 4. Re: DiscFerret: First working hardware, firmware and
> microcode! (Philip Pemberton)
> 5. Re: TRS-80 Model II Manuals (Tony Duell)
> 6. Re: TRS-80 Model II Manuals (Chuck Guzis)
> 7. Re: DiscFerret: First working hardware, firmware and
> microcode! (Dave McGuire)
> 8. Re: Happy Birthday VAX 11/780 (influence of) (Dave McGuire)
> 9. Re: DiscFerret: First working hardware, firmware and
> microcode! (Philip Pemberton)
> 10. Re: TTL HEX LED driver chip (Brent Hilpert)
> 11. Re: Happy Birthday VAX 11/780 (influence of) (Brent Hilpert)
> 12. Fall cleaning, some small machines for free (Bob Rosenbloom)
> 13. Re: DiscFerret: First working hardware, firmware and
> microcode! (Chuck Guzis)
> 14. Need to find parts 82S23 / 74S188 (alan canning)
> 15. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis)
> 16. Re: DiscFerret: First working hardware, firmware and
> microcode! (Philip Pemberton)
> 17. Re: TTL HEX LED driver chip (Tony Duell)
> 18. Re: Nuclear Data ND 6600 (Tony Duell)
> 19. Re: TRS-80 Model II Manuals (Tony Duell)
> 20. Re: TTL HEX LED driver chip (Tony Duell)
> 21. Re: TTL HEX LED driver chip (Tony Duell)
> 22. Re: Wanted : Monitor Capable of TTL RGB (Tony Duell)
> 23. Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence
> of)) (Tony Duell)
> 24. Re: Fall cleaning, some small machines for free (Brent Hilpert)
> 25. Re: Need to find parts 82S23 / 74S188 (ben)
> 26. Re: TRS-80 Model II Manuals (Geoffrey Reed)
> 27. Re: Need to find parts 82S23 / 74S188 (Tony Duell)
> 28. Re: Need to find parts 82S23 / 74S188 (Chuck Guzis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 30 Oct 2010 10:08:19 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: Happy Birthday VAX 11/780 (influence of)
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CCBEE93.7369.1A49AC at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 29 Oct 2010 at 21:14, Johnny Billquist wrote:
>
>> If your program vrites data to address 0, and reads it back, and get
>> the same data back, and another program on the same machine, at
>> roughly the same time, write to address 0, and reads the same data
>> back, and that data is different than the first programs data, then
>> I'd say you have virtual memory.
>
> So, your definition ties virtual memory into multi-user access?
> That's not the way I learned it.
>
> Consider (again folks, I'm sorry for the reference) the CDC 6600
> (circa 1964). Every user is given a relocation address (called RA)
> and field length (FL) as a way of partitioning main memory. Each
> user's memory addressing space is kept isolated from every other's
> and this fits your definiton because one user's location X was
> different from every other user's location X and there was no way for
> a user to tell what his RA was; i.e. each user was safely "boxed in".
>
> That's not virtual memory by any stretch of the definition. Over-
> committing memory meant writing/reading the entire FL of a user to
> disk ("rollout" and "rollin").
>
> Now consider the STAR-100 (I think it would qualify as the first
> virtual memory machine of CDC), circa 1969. Every user got an
> addressing space of 48 bits, but the machine itself had only
> 512Kwords (64 bit) of physical storage. For production use, most of
> the time the system was run in single-user mode (kept thrashing down
> with large data sets). That fits my definition of VM because the
> user was fooled into thinking that there was more physical memory
> than there really was.
>
> Aside from expanding program storage, the large addressing space was
> used to map file space (another type of "memory-mapped I/O"), so file
> access was actually performed through the paging hardware/software.
> That was kind of cool, as the STAR was a memory-to-memory vector
> machine, so you could use vector instructions on entire files, rather
> than have to issue reads and writes for pieces of a file.
>
> So I think we differ considerably in our definitions.
>
> --Chuck
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 30 Oct 2010 10:21:07 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: TTL HEX LED driver chip
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CCBF193.19364.2603DF at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On the same topic here, can anyone interpret the "state table" on the
> second page of the National DM74LS447 7-segment decoder datasheet?
>
> http://pdf1.alldatasheet.com/datasheet-
> pdf/view/149198/NSC/DM74LS447N.html
>
> I tend to think of state diagrams as belonging to things such as
> counters and don't have a clue as to what to make of the one
> furnished.
>
> --Chuck
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 30 Oct 2010 20:05:06 +0200
> From: Fred Jan Kraan <fjkraan at xs4all.nl>
> Subject: Re: TRS-80 Model II Manuals
> To: cctech at classiccmp.org
> Message-ID: <4CCC5E52.9000802 at xs4all.nl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS
>> disks and other application disks for my TRS-80 Model II system, which
>> is the entire setup pictured here, plus a bit more:
>>
>> http://oldcomputers.net/pics/TRS-80-II_table.JPG
>>
>> It's been sitting, covered, pretty much since I obtained it, but now I
>> can try reviving it and actually seeing what it can do. I'm going to
>> tear into it and clean the drives and so forth, document what it has,
>> etc. and then boot 'er up and see what we can see.
>>
>> I'm looking for a copy of the Technical Ref manual for it; despite
>> finding scans of the covers and so forth online, I'm unable to actually
>> locate one. In addition to that, if someone has a Shugart 8" Service
>> Manual, that might come in damned handy for making sure those are up to
>> speed as well.
>>
> See
> http://electrickery.xs4all.nl/comp/mirror/trs-80_archives/Manuals/Hardware/….
> The Shugart stuff should be included.
>
> Essential this is from a modified copy of the files that were available
> from http://www.trs-80.com/ (copied without permission).
>> Many thanks,
>>
>> Nathan
>>
>>
> Success,
>
> Fred Jan
>
> P.S. My own adventures with the Model II:
> http://www.xs4all.nl/~fjkraan/comp/trs80m2/
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 30 Oct 2010 19:35:32 +0100
> From: Philip Pemberton <classiccmp at philpem.me.uk>
> Subject: Re: DiscFerret: First working hardware, firmware and
> microcode!
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CCC6574.8010103 at philpem.me.uk>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 30/10/10 17:26, Al Kossow wrote:
>> If it's going to be an adapter, could you add holes for SA1000-style 8"
>> drives (50pin/20pin cabling)?
>
> I almost mistook that for a floppy drive until I looked it up on
> Bitsavers...!
>
> I can't see any real reason why SA1000 support couldn't be added to the
> bridge-board. Looks like the only changes required would be:
> - An oscillator to generate the 3.6866us +/- 0.1% timing clock
> (270982 to 271524Hz, nominal 271253Hz). Although I have no idea what
> standard crystal frequencies could be used to generate that signal. The
> FPGA's PLL might be persuaded to do it, though, I'll have to check.
> - Two jumpers to disconnect the Timing Clock from the ST412/506 Data
> connector when these are not in use (or maybe just a second connector?)
> - A 50-pin connector for the SA1000 control cable
>
> The extra cost probably isn't worth worrying about... though I might
> have to restrict drive selection to Drive 0 only in order to get enough
> I/O pins for head selection.
>
> Thanks,
> --
> Phil.
> classiccmp at philpem.me.uk
> http://www.philpem.me.uk/
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 30 Oct 2010 19:47:54 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: TRS-80 Model II Manuals
> To: cctalk at classiccmp.org
> Message-ID: <m1PCGTE-000J3xC at p850ug1>
> Content-Type: text/plain
>
>> locate one. In addition to that, if someone has a Shugart 8" Service
>> Manual, that might come in damned handy for making sure those are up to
>> speed as well.
>
> ...And if they;'re not, it's most likelyto be the drive belt. Yes I know
> 'up to speed' wasn't meant to be taken literally, but that seemed too
> good to miss :-)
>
> More seriously, what model of Shugart8" drive? Are there not manuals for
> them on bitsavers?
>
> -tony
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 30 Oct 2010 11:55:03 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: TRS-80 Model II Manuals
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CCC0797.19723.7C011E at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 30 Oct 2010 at 19:47, Tony Duell wrote:
>
>> ...And if they;'re not, it's most likelyto be the drive belt. Yes I
>> know 'up to speed' wasn't meant to be taken literally, but that seemed
>> too good to miss :-)
>
> Well, he could have a 220V 50Hz model and be running it on 120V 60Hz
> (the motor will develop sufficient torque to spin the disk). I've
> made that mistake once. The results from the reverse would be
> "interesting"...
>
> --Chuck
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 30 Oct 2010 15:29:06 -0400
> From: Dave McGuire <mcguire at neurotica.com>
> Subject: Re: DiscFerret: First working hardware, firmware and
> microcode!
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CCC7202.6050705 at neurotica.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 10/30/10 2:35 PM, Philip Pemberton wrote:
>> I can't see any real reason why SA1000 support couldn't be added to the
>> bridge-board. Looks like the only changes required would be:
>> - An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982
>> to 271524Hz, nominal 271253Hz). Although I have no idea what standard
>> crystal frequencies could be used to generate that signal. The FPGA's
>> PLL might be persuaded to do it, though, I'll have to check.
>
> You could stick a little AD9833 (or similar) DDS chip on there. It's
> overkill, but they're pretty cheap now, and you'll get the desired
> frequency spot-on.
>
> -Dave
>
> --
> Dave McGuire
> Port Charlotte, FL
>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 30 Oct 2010 15:34:25 -0400
> From: Dave McGuire <mcguire at neurotica.com>
> Subject: Re: Happy Birthday VAX 11/780 (influence of)
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CCC7341.1090704 at neurotica.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/30/10 1:08 PM, Chuck Guzis wrote:
>> Aside from expanding program storage, the large addressing space was
>> used to map file space (another type of "memory-mapped I/O"), so file
>> access was actually performed through the paging hardware/software.
>> That was kind of cool, as the STAR was a memory-to-memory vector
>> machine, so you could use vector instructions on entire files, rather
>> than have to issue reads and writes for pieces of a file.
>
> That functionality is in use all over the place today as mmap(),
> accessing files as if they were memory, pushing the read/write burden
> out into the VM system. It's extremely effective.
>
> I'd not consider it to be "memory-mapped I/O" at all, though, in the
> context of "a processor reading and writing I/O ports". Sure, file I/O
> is a sort of I/O, and mmap() and similar techniques map that file I/O
> into the address space, but the context of this discussion...and indeed,
> most, it not all use of the term "memory-mapped I/O" doesn't refer to
> this sort of thing.
>
> -Dave
>
> --
> Dave McGuire
> Port Charlotte, FL
>
>
> ------------------------------
>
> Message: 9
> Date: Sat, 30 Oct 2010 20:58:46 +0100
> From: Philip Pemberton <classiccmp at philpem.me.uk>
> Subject: Re: DiscFerret: First working hardware, firmware and
> microcode!
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CCC78F6.9040004 at philpem.me.uk>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 30/10/10 20:29, Dave McGuire wrote:
>> You could stick a little AD9833 (or similar) DDS chip on there. It's
>> overkill, but they're pretty cheap now, and you'll get the desired
>> frequency spot-on.
>
> ?8.25 each with no quantity discount is *not* cheap. The FPGA only costs
> a few quid more than that.
>
> Digikey have them for ?5.86, but that's still more than a crystal. I
> wonder how the host adapters for the SA1000s generated this clock
> frequency... it does seem somewhat odd.
>
> The other thing is, I'd be concerned about releasing hardware with
> SA1000 support without testing it on an actual drive. I'm willing to bet
> the chances of me finding a working SA1000 in 230V/50Hz configuration
> are somewhere between 'slim' and 'nil'.
>
> I'll guarantee ST506 support though, given that I've got an ST277R RLL
> drive and controller here. Just need an MFM controller for it, or the
> RLL code tables for the Seagate ST21R or ST22R controller (which IIRC
> uses an Adaptec AIC010 chip)...
>
> --
> Phil.
> classiccmp at philpem.me.uk
> http://www.philpem.me.uk/
>
>
> ------------------------------
>
> Message: 10
> Date: Sat, 30 Oct 2010 13:23:00 -0700
> From: Brent Hilpert <hilpert at cs.ubc.ca>
> Subject: Re: TTL HEX LED driver chip
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <8534ab06c8e0281a7fcfc54d6a70efa5 at cs.ubc.ca>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On 2010 Oct 30, at 10:21 AM, Chuck Guzis wrote:
>
>> On the same topic here, can anyone interpret the "state table" on the
>> second page of the National DM74LS447 7-segment decoder datasheet?
>>
>> http://pdf1.alldatasheet.com/datasheet-
>> pdf/view/149198/NSC/DM74LS447N.html
>>
>> I tend to think of state diagrams as belonging to things such as
>> counters and don't have a clue as to what to make of the one
>> furnished.
>
> It's obviously a state diagram for a decade counter, my guess is
> someone just screwed up making the datasheet and included the state
> diagram from some other device.
>
>
>
> ------------------------------
>
> Message: 11
> Date: Sat, 30 Oct 2010 13:36:50 -0700
> From: Brent Hilpert <hilpert at cs.ubc.ca>
> Subject: Re: Happy Birthday VAX 11/780 (influence of)
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <d40186fd9ded72a101d654d9516da0f5 at cs.ubc.ca>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote:
>
>> On 10/30/10 1:08 PM, Chuck Guzis wrote:
>>> Aside from expanding program storage, the large addressing space was
>>> used to map file space (another type of "memory-mapped I/O"), so file
>>> access was actually performed through the paging hardware/software.
>>> That was kind of cool, as the STAR was a memory-to-memory vector
>>> machine, so you could use vector instructions on entire files, rather
>>> than have to issue reads and writes for pieces of a file.
>>
>> That functionality is in use all over the place today as mmap(),
>> accessing files as if they were memory, pushing the read/write burden
>> out into the VM system. It's extremely effective.
>
> I remember in the 80's (programming primarily on BSD (and VMS))
> thinking it would nice to have that functionality, how easy it would
> make a lot of file-access programming, and that it would be easy to add
> on a VM system. Of course, I was in ignorance of the prior histories
> such as the STAR that Chuck mentions. A few years later a friend would
> tell me about the new mmap function in unix.
>
>
>> I'd not consider it to be "memory-mapped I/O" at all, though, in the
>> context of "a processor reading and writing I/O ports". Sure, file
>> I/O is a sort of I/O, and mmap() and similar techniques map that file
>> I/O into the address space, but the context of this discussion...and
>> indeed, most, it not all use of the term "memory-mapped I/O" doesn't
>> refer to this sort of thing.
>
> Well, Chuck did say "a type of". If files are a form of abstracted disk
> I/O, then mmap is a form of abstracted memory-mapped I/O.
>
>
>
> ------------------------------
>
> Message: 12
> Date: Sat, 30 Oct 2010 13:36:53 -0700 (PDT)
> From: Bob Rosenbloom <bobalan at sbcglobal.net>
> Subject: Fall cleaning, some small machines for free
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <960487.42595.qm at web80502.mail.mud.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Fall cleaning!
>
> I have a bunch of old computers and some peripherals. Most are not tested
> and I expect they may need some work to become operational, though some
> may work correctly as-is. Anyway, I'm hoping to find people interested in
> restoring these systems.
>
> There are three Burroughs B25 systems, each has a processor box, disk box,
> monitor, keyboard, and power supply. There is one box of docs and
> diskettes and one, very dirty, printer.
> http://www.anifur.com/clist/misc-b1.jpg
> http://www.anifur.com/clist/misc-b2.jpg
> http://www.anifur.com/clist/misc-b3.jpg
> http://www.anifur.com/clist/misc-b4.jpg
>
> IBM convertible, an early laptop type system.
>
> A Computer Products portable, thermal, serial terminal.
> http://www.anifur.com/clist/misc-ptr.jpg
>
> A Radio Shack TRS-80 model I with expansion chassis and monitor. I believe
> this has a bad power supply.
> http://www.anifur.com/clist/misc-rs.jpg
>
> A NEC Spinwriter terminal. This is like a Diablo daisywheel terminal
> except the print element is a cylinder. I know this one needs work but
> does power up.
> http://www.anifur.com/clist/misc-spin.jpg
>
> Some kind of cartridge tape system. I think it's SCSI interfaced. I don't
> believe this has ever been used.
> http://www.anifur.com/clist/misc-tape.jpg
>
> A large flatbed scanner that I also believe is unused. It's SCSI
> interfaced. UMAX 3000.
> http://www.anifur.com/clist/misc-scanner.jpg
>
> Digitech RS-232 analyzer with manuals. This runs CP/M 86 but I don't have
> the boot disc for it. Does power up.
> http://www.anifur.com/clist/misc-anal.jpg
>
> Kaypro 2, powers up and ask for a system disk.
> http://www.anifur.com/clist/kaypro1.jpg
>
> Hitachi pen plotter. This has a parallel interface. It powers up and works
> from the front panel. Light weight.
> http://www.anifur.com/clist/hitachi1.jpg
>
> Panasonic NV-A960 VCR editing unit.
> http://www.anifur.com/clist/a960-1.jpg
>
> Nicolet Zeta 8A pen plotter. 8 pens. Also powers up and works from the
> front panel. Serial interface.
>
> All of these are located in the Santa Cruz, CA mountains, near the Bonny
> Doon airport. I can possibly bring something into Santa Clara where I
> work. Best to come visit and check them out here. I really don't want to
> ship anything as I just don't have the time or energy.
>
> Please rescue these before I scrap them, I really need the space and these
> are now outside, but covered under a Quonset hut.
>
> Bob
>
>
> ------------------------------
>
> Message: 13
> Date: Sat, 30 Oct 2010 13:39:13 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: DiscFerret: First working hardware, firmware and
> microcode!
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CCC2001.27472.DB6112 at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 30 Oct 2010 at 15:29, Dave McGuire wrote:
>
>> On 10/30/10 2:35 PM, Philip Pemberton wrote:
>> > I can't see any real reason why SA1000 support couldn't be added to
>> > the bridge-board. Looks like the only changes required would be: -
>> > An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982
>> > to 271524Hz, nominal 271253Hz). Although I have no idea what
>> > standard crystal frequencies could be used to generate that signal.
>> > The FPGA's PLL might be persuaded to do it, though, I'll have to
>> > check.
>>
>> You could stick a little AD9833 (or similar) DDS chip on there.
>> It's
>> overkill, but they're pretty cheap now, and you'll get the desired
>> frequency spot-on.
>
> Also, aren't the read/write data signals on the SA1000 differential?
> Or do I have them confused with the ST506 interface?
>
> --Chuck
>
>
>
> ------------------------------
>
> Message: 14
> Date: Sat, 30 Oct 2010 13:52:12 -0700
> From: alan canning <scanning.cc at gmail.com>
> Subject: Need to find parts 82S23 / 74S188
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinzHd-NW1yL2LFuNG1=1q7s3hKOdxe2VLr7uXLH at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried
> all
> the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no
> joy.
> I believe this part was used on old S100 boards.
>
> Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and
> Harris 7602. Need this part to fix an old computer controlled RF Power
> amplifier.
>
> Thanks for any and all help.
>
> Best regards, Steven
>
>
> ------------------------------
>
> Message: 15
> Date: Sat, 30 Oct 2010 13:54:40 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: Happy Birthday VAX 11/780 (influence of)
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CCC23A0.9876.E985BD at cclist.sydex.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 30 Oct 2010 at 15:34, Dave McGuire wrote:
>
>> I'd not consider it to be "memory-mapped I/O" at all, though, in
>> the
>> context of "a processor reading and writing I/O ports". Sure, file
>> I/O is a sort of I/O, and mmap() and similar techniques map that file
>> I/O into the address space, but the context of this discussion...and
>> indeed, most, it not all use of the term "memory-mapped I/O" doesn't
>> refer to this sort of thing.
>
> I'm sure and I'd never seriously call it "memory-mapped I/O"--but
> sometimes our world seems akin to that of Humpty-Dumpty: "When I use
> a word it means just what I choose it to mean--neither more nor less"
>
> Uh-oh, here comes another story...
>
> After I left CDC and the STAR project in 1977, my past came back to
> haunt me in the form of doing an optimizing FORTRAN for the ETA-10 in
> about 1983. We got a leased-line linkup to ETA in St. Paul and I
> asked what text editor they were using.
>
> Much to my surprise, it turned out to be the same editor I'd written
> for a lark around 1975 when the STAR had lots of really interesting
> byte string instructions and I could exploit file-mapped I/O to use
> them. Mind you, this was in the day of 16-line 1200 bps terminals.
>
> But the ETA-10 had none of those instructions, essentially having
> evolved out of the "everything but the kitchen sink CISC" state of
> mind of the original architecture. Some programmer had been detailed
> off to replace all of those cool vector instructions with their
> scalar equivalents!
>
> I was stunned and opined that with that way of thinking, the software
> end of the ETA project was doomed.
>
> --Chuck
>
>
>
> ------------------------------
>
> Message: 16
> Date: Sat, 30 Oct 2010 21:58:20 +0100
> From: Philip Pemberton <classiccmp at philpem.me.uk>
> Subject: Re: DiscFerret: First working hardware, firmware and
> microcode!
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CCC86EC.8040906 at philpem.me.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 30/10/10 21:39, Chuck Guzis wrote:
>> Also, aren't the read/write data signals on the SA1000 differential?
>> Or do I have them confused with the ST506 interface?
>
> They're both differential. It's just that the SA1000 expects you to feed
> it a reference clock signal. It doesn't have to be locked against
> write-data, it just has to be there, and be accurate to 0.1%...
>
> Assuming the OEM manual is accurate, of course.
>
> --
> Phil.
> classiccmp at philpem.me.uk
> http://www.philpem.me.uk/
>
>
> ------------------------------
>
> Message: 17
> Date: Sat, 30 Oct 2010 21:23:40 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: TTL HEX LED driver chip
> To: cctalk at classiccmp.org
> Message-ID: <m1PCHxn-000J3xC at p850ug1>
> Content-Type: text/plain
>
>>
>> On 29 Oct 2010 at 22:10, Tony Duell wrote:
>>
>> > Anyother thought I had is to use a 7447 for the lower 8 or 10
>> > patterns (as it's designed to do!) and add logic for the higher ones.
>> > I don't know if that saves chips.
>>
>> The 7447 has a problem in that the "6" doesn't have the top crossbar,
>> so that it's indistinguishable from a "b". The '247 does include the
>> top segment when displaying '6', which is why I mentioned the 247 and
>> not 47.
>
> Yes, I should have remembered that...
>
>
>>
>> This brings to mind an ancient "fix" for the 47 "6" display--a
>> pulldown diode connected between segment "e" and segment "a"--in the
>
> Been there, done that :-)
>
>> display of 0-9 there is no time when segment "e" is active that
>> segment "a" isn't also active. The converse, however isn't true--and
>> this "fix" will mess up your display of "b" if you use the method
>> described previously to display 0-F.
>
> Of course. For 'b' you mmed the 'e' segment without the 'a' segment.
> That's what distinguishes it from '6'
>
>
>>
>> But if you allow diodes, then there's no reason not to use a 4-to-16
>> demux and a mess of diodes to do the decoding for 0-F, is there?
>
> while my original question didn't preclude the use of discrete
> components, and while I happly ageee that the odd diodes, pull-up
> resisotrs, etc can lead to interesting solutions, I do feel that such a
> diode matrix is outisde the spirit of the problem. After all, you could
> say it can be solved with no ICs at all, just lots of discrete
> transistors, etc. :-)
>
> -tony
>
>
> ------------------------------
>
> Message: 18
> Date: Sat, 30 Oct 2010 21:27:54 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: Nuclear Data ND 6600
> To: cctalk at classiccmp.org
> Message-ID: <m1PCI1t-000J3yC at p850ug1>
> Content-Type: text/plain
>
>> eons ago at a TRW a friend bought a nice box that looked much like an
>> ADM3a with nice case, integrated CRT and keyboard, and gleefully gave
>> the guy selling it about $40 for it. This was in the day of $700
>> terminals new prices.
>>
>> It was a Vector graphics console. Unfortunately he had not looked at
>> the back, or thru the cracks, but it was a plastic case with a keyboard
>> and CRT inside, no PS, electronics or anything else. I suspect when he
>
> I am suprised there wasn't the standard driver circuits for the CRT (from
> composite vidoe, say). My guess is that there should have been, and they
> were msising.
>
>> moved east some years ago it got dumpstered, but it was about the same
>> sort of thing, no brains in the "terminal" but in the box.
>
> ICL did something similar. They had 'terminals' that consisted of encoded
> keyboards and composite monitors. The case was painted a horrible orange
> colour ... I think I still have one of the keyboards somewhere, but I
> mangaged to give the monitor away some years ago (thankfully...)
>
> -tony
>
>
> ------------------------------
>
> Message: 19
> Date: Sat, 30 Oct 2010 22:07:02 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: TRS-80 Model II Manuals
> To: cctalk at classiccmp.org
> Message-ID: <m1PCIdm-000J4HC at p850ug1>
> Content-Type: text/plain
>
>>
>> On 30 Oct 2010 at 19:47, Tony Duell wrote:
>>
>> > ...And if they;'re not, it's most likelyto be the drive belt. Yes I
>> > know 'up to speed' wasn't meant to be taken literally, but that seemed
>> > too good to miss :-)
>>
>> Well, he could have a 220V 50Hz model and be running it on 120V 60Hz
>> (the motor will develop sufficient torque to spin the disk). I've
>> made that mistake once. The results from the reverse would be
>> "interesting"...
>
> Actaully, a lot of the 8" drives I have have 120V motors, but of course
> the right pulleys for 50Hz mains. They are run from an
> (auto)transformer, often the primary winding of the syatem mains
> transformer.
>
> So I suppose he could have something like that :-)
>
> -tony
>
>
> ------------------------------
>
> Message: 20
> Date: Sat, 30 Oct 2010 21:41:27 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: TTL HEX LED driver chip
> To: cctalk at classiccmp.org
> Message-ID: <m1PCIF1-000J48C at p850ug1>
> Content-Type: text/plain
>
>>
>> On 2010 Oct 29, at 2:10 PM, Tony Duell wrote:
>> >
>> > For those who are wondeirng, the 'trivial' solution I mentioned uses 7
>> > off 74150 16-input multiplexers, one for each segment. You tie the
>> > inputs
>> > high low to determine if that segment is on or off for a given set fo 4
>> > input bits.
>> >
>> > After posing that, I thought of other solutions that make no
>> > assumptions
>> > about the segment patterns -- they always work. For example 7 off
>> > 74151 8
>> > input muxes and a single inverter (1/6 of a 7404) That has the
>> > advantage
>> > of automatically providing actrive high and active low outputs.
>>
>> That only gives you 8 patterns, not 16 .. ?
>
> Err, no. That's what the extra inverter is for.
>
> You know hos to use a 2^n input mux to make an arbitrary combinartorial
> function of n signals. Feed the n signals to the select inputs of the
> multiplexer and wire the 'data' inputs high or low as the truth table
> requires.
>
> But you can also yuse a 2^(n-1) input mux and maybe a single inverte, you
> connect n-1 of the input lines to the select inputs of the mux. And then
> for each of those combinations you consider the 2 truth table lines that
> apply (the last input, the one you've not used yet, of course
> distinguishes between the 2 lines in each pair). There are 4 possibilites
> :
> a) The output of the function is 0 in both cases (it doesn't depend on
> the last input at all) --> wire that input of thr mux to ground
>
> b) It's 1 in both cases -> wire the input to Vcc
>
> c) It's 0, 1 , it follows the last input in this case -> Wire that last
> input signal to the appropraite input of the multiplexer
>
> d) It's 1,0, it's the opposite of the last input. This is when you need
> that inverter. Invert the last input signal and wire the appropriate
> multiplexer input to the ouptu of the inverter.
>
> If oyu requre several functions of the same inputs (as here), you only
> need 1 ivnerter (assumeing there are no fan-out problems), since it's
> always thge same singal (say the 2^0 data input) you need to invert.
>
> Son yes, you can use 8 input multiplexers here (and 4 input ones if you
> only want to generate 6 or 8 patterns).
>
> Now, another silly aside...
>
> If you want to use a 2^(n-2) mux, you may need any or all of the 16
> possible functions of the last 2 inputs (you split up the truth table
> into sets of 4 lines, and see which function of the last 2 inputs gives
> the right paattern, of course). This makes it less useful :-). But it's
> made me think pof a chip that AFAIK never existed... If you think of those
> 16 possible functions of 2 inputs, then 4 of them are 'trivial' in the
> sense that you can produce them with no logic at all. Namely 'always 0',
> 'always 1', 'equal to the A input' and 'equal to the B input'. Which
> leaves 12 non-rtrivial ones/ Now that means there could have been a 16
> pin IC with 2 power pins, 2 inputs and 12 outputs, the 12 non-trivial
> functions of the 2 inputs. Use that witha 74150 for an arbitrary fucntion
> of 6 inputs...
>
> -tony
>
>
>
> ------------------------------
>
> Message: 21
> Date: Sat, 30 Oct 2010 21:44:22 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: TTL HEX LED driver chip
> To: cctalk at classiccmp.org
> Message-ID: <m1PCIHq-000J49C at p850ug1>
> Content-Type: text/plain
>
>>
>> On 29 Oct 2010 at 16:13, Brent Hilpert wrote:
>>
>> > I too realised that halfway thru the exercise and went scrambling back
>> > to the databook to check on the 247.
>>
>> Another reason to lament the passing of the hardcopy databook. I
>> used to sit and read them cover-to-cover. Not really possible in
>
> Absolutely. Of cousre I've kept all my old paper databooks, and still
> read them from time to tieme.
>
> Yes, it's very useful being able to get data on just about any standard
> IC over the internet. But it's useful in a different way being able to
> flip through a data book, see what's available, etc. I've yet to find a
> manufacturer's site that lets me browse in the same way.
>
> -tony
>
>
> ------------------------------
>
> Message: 22
> Date: Sat, 30 Oct 2010 21:48:01 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: Wanted : Monitor Capable of TTL RGB
> To: cctalk at classiccmp.org
> Message-ID: <m1PCILO-000J4AC at p850ug1>
> Content-Type: text/plain
>
>>
>> On 30/10/10 03:08, Dan Williams wrote:
>> > I am on the lookout for a monitor something similar to a Phillips
>> > cm3388 does anyone near London have one they would like to sell or
>> > trade, or know of anywhere I could get one.
>>
>> Surely you mean the CM8833?
>> Those were fairly extensively re-badged -- Acorn, for instance, sold a=20
>> variant of the CM8833 Mk.II as the AKF17.
>
> Is CM8833 a TTL-input monitor? I think it was available as an option,
> but most of them take analogue RGB on the SCART socket.
>
> Most of the time the SCART inputs, for all they're supposed to be 1V will
> stand TTL (the CM8833 ones certainly will). Or since they're terminated
> to ground through a 75 ohm resistor, connect a 300 Ohm (or so) resistor
> in series with each TTL signal. Done that many times :-)
>
> Is there any reason a TV with a SCART socket isn't suitable? Most, if not
> all, LCD and plasma TVs should haev RGB inputs on the SCART socket, for
> example.
>
> -tony
>
>
>
> ------------------------------
>
> Message: 23
> Date: Sat, 30 Oct 2010 21:52:09 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence
> of))
> To: cctalk at classiccmp.org
> Message-ID: <m1PCIPM-000J4BC at p850ug1>
> Content-Type: text/plain
>
>>
>> OK, it's fair to say that there's nothing that precludes memory-mapped
>> I/O =
>> in any machine (except perhaps physical memory architecture, although I
>> can=
>> 't think of an example). But port-mapped I/O machines had specific
>> instruc=
>
> The obvious problem would be if the memroy map is already totally full.
> If you've got a Z80 systme with 64K of memory, it would be perverse to
> try memory mapped I/O (you could have some kind of MMU, but why...).
> Similarky trying to emmeroy map any kind of I/O on a 2MByte PERQ would be
> an 'interesting' exercise...
>
> -tony
>
>
>
> ------------------------------
>
> Message: 24
> Date: Sat, 30 Oct 2010 14:09:44 -0700
> From: Brent Hilpert <hilpert at cs.ubc.ca>
> Subject: Re: Fall cleaning, some small machines for free
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <981998b8f30737dece941bd3fc38a0c1 at cs.ubc.ca>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On 2010 Oct 30, at 1:36 PM, Bob Rosenbloom wrote:
>>
>> Panasonic NV-A960 VCR editing unit.
>> http://www.anifur.com/clist/a960-1.jpg
>
> I dismantled one of these a few years ago, it contained an
> (NEC-branded) 8080, a whack of NEC 8255's (PIO), half-a dozen ceramic
> Fujitsu MB8516's (2K*8 EPROMS, 2716-like), all socketed, for anyone
> that might take an interest in such stuff.
>
>
>> All of these are located in the Santa Cruz, CA mountains, near the
>> Bonny Doon airport. I can possibly bring something into Santa Clara
>> where I work. Best to come visit and check them out here. I really
>> don't want to
>> ship anything as I just don't have the time or energy.
>>
>> Please rescue these before I scrap them, I really need the space and
>> these are now outside, but covered under a Quonset hut.
>>
>> Bob
>
>
>
> ------------------------------
>
> Message: 25
> Date: Sat, 30 Oct 2010 15:11:06 -0600
> From: ben <bfranchuk at jetnet.ab.ca>
> Subject: Re: Need to find parts 82S23 / 74S188
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CCC89EA.1000405 at jetnet.ab.ca>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> looks for 74S188 with google
> http://www.futurlec.com/Memory/74S188pr.shtml
>
>
> ------------------------------
>
> Message: 26
> Date: Sat, 30 Oct 2010 14:17:16 -0700
> From: Geoffrey Reed <geoffr at zipcon.net>
> Subject: Re: TRS-80 Model II Manuals
> To: cctalk <cctalk at classiccmp.org>
> Message-ID: <C8F1D96C.2E65E%geoffr at zipcon.net>
> Content-Type: text/plain; charset="US-ASCII"
>
> Y'all are making me miss my tandy model 16 and 6000.
>
>
>
>
> ------------------------------
>
> Message: 27
> Date: Sat, 30 Oct 2010 22:21:08 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: Need to find parts 82S23 / 74S188
> To: cctalk at classiccmp.org
> Message-ID: <m1PCIrQ-000J3xC at p850ug1>
> Content-Type: text/plain
>
>>
>> Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried
>> all
>> the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no
>> joy.
>> I believe this part was used on old S100 boards.
>>
>> Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and
>> Harris 7602. Need this part to fix an old computer controlled RF Power
>> amplifier.
>
> IIRC, this is a PROM, 32*8 I think. Do you have a copy of the data to
> program into it? A blank chip is not a lot of use to you otherwise...
>
> Also while all the derives you've mentioned are I think compatible when
> being read (that is, as they are normally used in the circuit), the
> programming algorithms are different for differnet manufacturers. You need
> to get one that your programmer can handle
>
> -tony
>
>
> ------------------------------
>
> Message: 28
> Date: Sat, 30 Oct 2010 14:18:38 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: Need to find parts 82S23 / 74S188
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CCC293E.2099.FF7864 at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 30 Oct 2010 at 13:52, alan canning wrote:
>
>> Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've
>> tried all the usual suspects ( Ebay, local parts houses, Digikey, etc.
>> ) with no joy. I believe this part was used on old S100 boards.
>>
>> Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30
>> and Harris 7602. Need this part to fix an old computer controlled RF
>> Power amplifier.
>
> If you'd like something a bit closer to home, you might try ACP--
> they're listing some IM5603s on eBay for $7.95 the each.
>
> --Chuck
>
>
>
> End of cctalk Digest, Vol 86, Issue 68
> **************************************
OK, it's fair to say that there's nothing that precludes memory-mapped I/O in any machine (except perhaps physical memory architecture, although I can't think of an example). But port-mapped I/O machines had specific instructions for I/O, which might well facilitate the process beyond the simple mechanics of memory-mapped I/O (think about polling on a skip flag on a PDP-8) but also potentially limited one in either range or capability. It's also important to recognize that the PDP-11 *enforced* memory-mapped I/O in an upper region, which limited working store (and it was not the only machine to do so, e.g. Alto).
And we're discussing this because...? :-)
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of Dave McGuire [mcguire at neurotica.com]
Sent: Friday, October 29, 2010 10:31 PM
To: On-Topic and Off-Topic Posts
Subject: Re: Happy Birthday VAX 11/780 (influence of)
On 10/29/10 4:55 PM, Tony Duell wrote:
>>> Just because a CPU architecture has IO instructions doesn't mean you
>>> can't do memory-mapped I/O.
>
> I beleive Steve Ciarcia said in one of the Circuit Cellar articles in
> Byte many year ago that any processor that could access memory could have
> memory-mapped I/O.
He certainly did, I remember that article well. He started the
article by relating a conversation that he'd had with a fellow computer
guy, and they were arguing (I think) 6800 vs. Z80. He said something
like "When he said the 6800 had memory-mapped I/O and the Z80 didn't, I
knew he didn't know what it was". :)
-Dave
--
Dave McGuire
Port Charlotte, FL
On 2010-10-30 01:12, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
>>> > > Just because a CPU architecture has IO instructions doesn't mean you
>>> > > can't do memory-mapped I/O.
> I beleive Steve Ciarcia said in one of the Circuit Cellar articles in
> Byte many year ago that any processor that could access memory could have
> memory-mapped I/O.
Good point.
Was the PDP-11 the first computer that did not have dedicated I/O
instructions then? Thus relying on memory mapped I/O, instead of just
having it as a potential (as any computer do). Did anyone before the
PDP-11 actually utilize memory mapped I/O before? The fact that lots of
machines do it today (even the x86 I guess) could just be a legacy of
the PDP-11 making it popular?
(Oh, and I'm not counting the IOT instruction on the PDP-11 as an I/O
instruction... :-) )
> I would add that in the case of a system (rather than a bare processor),
> it helps if there's some spare space in the memroy map:-).
Indeed. :-)
>> > And there were other PC displays, that didn't use memory-mapped video
> if by 'PC' here you mean something descended from the IBM5150 then I am
> curious. All the IBM dipslay adapdaters that I can think of were memory
> mapped. Yes, even the PGC had a memory-mapped CGA emulation.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2010-10-28 23:02, Rich Alderson<RichA at vulcan.com> wrote:
> From: Brad Parker
> Sent: Thursday, October 28, 2010 10:12 AM
>
> On Oct 27, 2010, at 11:31 AM, William Donzelli wrote:
>
>>>> >>> You could insert a small paragraph here about the role of unix and how
>>>> >>> unix and the pdp-11 and vax interacted.
>>> >> Are you saying that the PDP-11 and VAX were the first machines where
>>> >> the hardware and software were both considered and designed together?
>>> >> Once again, I think a lot of people would not agree with that.
>> > No, I didn't say that at all. I was just saying that the it would be
>> > interesting to explore how the pdp-11 and VAX architectures influenced
>> > the design of unix, and how unix, in turn, influenced software
>> > development as a whole. I thin the two are interrelated.
> From what Thompson and Ritchie have written about the origins of Unix,
> the PDP-11's architecture had very little to do with how it was created.
> The original PDP-7 Unix (specific I/O ports addressed in I/O instructions,
> 18-bit words, word addressing) was taken up and ported to the PDP-11 with
> few or no user-visible changes.
Indeed. Well, I don't know about few or no user-visible changes, but
there is no denying that Unix started on a PDP-7, and not a PDP-11.
> Because the VAX offered a virtual memory capability (hi, Johnny!:-), it
> did change the way Unix developed, but so did other ports (Interdata, for
> example, and even the IBM Series/1).
Hi. :-)
I hope you do remember that early versions of Unix (even on the VAX) did
not do demand paging. Are you saying that they didn't have virtual
memory either, then? :-)
BSD3 anyone?
As for what PDP-11 might have innovated, we have covered the memory
mapped I/O at some length now, and it appear that the PDP-11 might
atleast have a half claim to fame there. But, as some pointed out, the
x86 do not use memory mapped I/O (and shared memory with a graphics
subsystem is not the same thing). Most RISC machines did/do use memory
mapped I/O anyway, but I digress...
I have not seen anyone comment any of the other things I listed as
possible firsts on the PDP-11.
Can anyone come up with an earlier machine that used condition codes?
How about general registers with addressing modes, which is totally
orthogonal? How about having the PC as a general register?
I don't know of any machines before the PDP-11 that had these.
Admittedly, the only one of these attributes the x86 inherited (from
wherever) is condition codes, but I think it might be interesting to
hear the collective wisdom on some more details than just memory mapped
I/O...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS
> disks and other application disks for my TRS-80 Model II system, which
> is the entire setup pictured here, plus a bit more:
>
> http://oldcomputers.net/pics/TRS-80-II_table.JPG
>
> It's been sitting, covered, pretty much since I obtained it, but now I
> can try reviving it and actually seeing what it can do. I'm going to
> tear into it and clean the drives and so forth, document what it has,
> etc. and then boot 'er up and see what we can see.
>
> I'm looking for a copy of the Technical Ref manual for it; despite
> finding scans of the covers and so forth online, I'm unable to actually
> locate one. In addition to that, if someone has a Shugart 8" Service
> Manual, that might come in damned handy for making sure those are up to
> speed as well.
>
See
http://electrickery.xs4all.nl/comp/mirror/trs-80_archives/Manuals/Hardware/….
The Shugart stuff should be included.
Essential this is from a modified copy of the files that were available
>from http://www.trs-80.com/ (copied without permission).
> Many thanks,
>
> Nathan
>
>
Success,
Fred Jan
P.S. My own adventures with the Model II:
http://www.xs4all.nl/~fjkraan/comp/trs80m2/
Hi again,
Has anyone got a spare Zorro Ethernet card I can buy/borrow?
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
Hi folks,
Anyone got some spare Kickstart ROMs for an Amiga 4000? I'm doing an
exhibition in a couple of weeks time and completely forgot my A4000 is
only on KS 3.0! I have OS3.5 ready to install.
I also picked the wrong time to give away my DEC 3000-300s since the
one I kept blew up this afternoon, fortunately we have spares for that
at work I can 'borrow' :)
Cheers!
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk
On 2010-10-30 01:12, <arcarlini at iee.org> wrote:
> Johnny Billquist [bqt at softjar.se] wrote:
>
>> > Now, I direct you all to page 4-7 of that document, which talks about
>> > physical addresses on a VAX.
>> > Notice how a physical address on a VAX can be 34 bits, while the
> virtual
>> > address is only 32 bits.
>
> VAX virtual addresses have always been 32-bits although system space S1
> (the top 1GiB) was never defined. The XVA project allowed it to be used
> (on some hardware platforms).
Yes. And the virtual address space is divided into 4 parts (as you well
know :-) ). P0, P1, S0 and S1. Only P0 and P1 is actually process local,
while S0/S1 is system wide.
> The (related) XPA project allowed the physical address space to grow
> beyond
> 1GiB but only to 4GiB (32-bits).
Well, the design allows it to grow to 34 bits. Specific implementations
might have limited it to 32 bits, but that's another story.
> DEC STD-032 does allow for a 34-bit PA implementation but I don't know
> of
> one. The VAX 6000/7000/10000 all only implemented 32-bit PA mode
> (afaik).
> I don't know (off hand) whether the chipset could do more.
Two different things here. The NVAX chip have two different formats of
the page address. 21 bits or 25 bits. With 21 bits, you can only get 30
bit physical addresses (the old VAX model). With 25 bits, you get a
total of 34 bits of physical address. Now, I don't know if the NVAX
brought all 34 address bits out of the chip, but that is the size of the
physical address created by the MMU anyway.
The actual machines, such as the VAX 7000 on the other hand, clearly
only allowed a max of 4G. Of that, 3.5G was for physical memory, and
0.5G was reserved as I/O space. But that is a design decision of a
machine, and have less bearing on the architecture.
It is a question of the bus used in the machine, as well as where I/O
adapters will be present on the bus, and so on.
I suspect all software running on a VAX7000 to always have the top two
bits of the PFN in the PTE to always be zero. But the bits are there
none the less.
Anyhow, even with only 3.5G of physical memory, it will be more physical
memory than any one process can have virtual memory on the VAX, since a
process cannot be larger than 2G (P0,P1)
> So (barring any inormation to the contrary) I think it's only a
> theoretical
> possibility:-)
Probably. It would be interesting to see the pinout of the NVAX chip, to
see if they brought all 34 bits out on that chip. All existing VAXen
restricted physical addresses to at most 32 bits, though.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I recently acquired a small truckload of DEC and Wang equipment which
I am starting to sort and inventory in my garage. The DEC is mostly
accounted for (tho will lead to later questions here) but I know far
less about the Wang stuff. It seems Google does, too. I've got a few
larger units plus a number of boards - it appears the stuff originally
came from a repair shop and/or dealer. I've photographed two pieces:
The first I'm not even sure of the make - its colors sort of suggest
DEC but I'm leaning toward it being a Wang printer stand:
http://picasaweb.google.com/Silent700/MysteryCart#
The second is a Wang Word Processor, model 5506-A. Google has much on
earlier WPs from them, but nothing on this model:
http://picasaweb.google.com/Silent700/Wang5506AWordProcessor#
What I find especially strange about this one is that it's called a
"Word Processor," suggesting it is a complete system, yet it has ports
for neither storage nor a printer. Could it be a terminal to a
networked (WangNet) system? Still, the only ports on the back are
Video and Keyboard - both of which it has built-in. They could be aux
video in or out, or an attachment for an add-on keyboard?
The 5506 is practically mint. The guy I got it from said he had the
original box but it was in such bad shape he tossed it :( There is
still shipping plastic on the space bar and the screen. Turning it
on shows a blank greenscreen - turning up the brightness shows
diagonal lines, so there may be a display problem.
Hoping for clues! More to come...
--
jht
On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at gmail.com> wrote:
> On Fri, Oct 29, 2010 at 12:31 PM, Chuck Guzis<cclist at sydex.com> wrote:
>> > On 29 Oct 2010 at 0:11, Johnny Billquist wrote:
>> >
>>> >> Next question: Does the VAX not have virtual memory any more now that
>>> >> I've pointed this out? Or do you need to redefine virtual memory in
>>> >> yet a new and strange way to exclude the PDP-11...:-D
>> >
>> > I think that using memory address spaces to qualify the "virtualness"
>> > of memory is following the wrong animal.
>> >
>> > I would define "virtual memory" as the ability to fool a program into
>> > thinking that it has more physical memory than is actually present.
> I don't think that's an essential component of the term as I learned
> it 20+ years ago.
>
> My understanding is that in a machine that supports virtual memory,
> you have virtual address space(s) and physical address space.
> Physical addresses are something you can see with a logic analyzer and
> point to a physical chip and say "my data is right*there*". If you
> have two processes running on the same CPU, they both agree where
> 0x0000 (or 0x00000000) is and it's the same place. If one process
> writes a value there, both processes would read that value back. In
> virtual space, each process*thinks* they are writing to 0x0000, and
> they can read back the value they wrote, but not each other's values.
> In fact, unless they peek under the covers, they have no idea where in
> physical memory their own virtual 0x0000 is.
Indeed. Finally someone with the correct definition of virtual memory.
You could also draw the parallel to a virtual machine. It fakes a real
machine, making you think that you have your own. Virtual memory fakes
real memory, making you think you have your own.
Exactly how this is done is not a part of the definition. Nor is the
relation between the sizes of virtual and physical memory relevant.
If you get the impression that you have the full address range available
to do with as you please, even though you are not alone on a machine,
then you are presented with virtual memory.
> In practice, quite often virtual memory_is_ used to fool programs
> about how much physical memory there is, but the PDP-11 is a specific
> counter-example to "more than is actually present". Taking the VAX
> first (since we all know "all the world's a VAX";-), you might have
> 8MB of physical memory installed in an 11/750 in a physical memory map
> of 16MB (24 address bits). So in this model, your virtual space is 32
> bits (the size of your address registers), while your physical space
> is 24 bits. From the process side, every process "sees" 4GB (32
> bits) of space with lots of holes in it (mostly holes). If your
> program keeps requesting more and more memory from the OS, at first,
> you may be given chunks of real memory mapped into your virtual space;
> eventually that will be exhausted and your OS will most likely start
> paging and reserve storage for you until that runs out (so always
> check the return of malloc() even if you think you can't possibly run
> out of virtual memory).
Yes. You could also say that demand paging is *required* in order to
fool a program that it has more memory than what is physically
available. And virtual memory is also required to make this work, but
they are two different things. You can have virtual memory without
having demand paging.
> On the PDP-11, your process's_virtual_ space is 64KB - 16 bits, the
> size of your registers, while some PDP-11s can have up to 256KB of
> physical memory (18 bits), and many can have up to 4MB (22 bits) of
> physical memory. In this case, you still have virtual space different
> from physical space (and the same scenario where two different
> processes agree on where 0x0000 is in physical space but maintain
> their own 0x0000 in their respective virtual spaces).
Exactly!
>> > So, can a PDP-11 with 16K of memory appear to a program as if there
>> > were 32K present?
> That all depends. Back in the day, what we did was not demand-paged
> virtual memory (something supported natively on the VAX and the 68010
> (but not effectively on the 68000) - some architectures have memory
> management hardware that can "tell" if a reference is about to hit a
> patch of virtual addresses that don't have physical memory mapped to
> them and invoke some OS-specific routine to either allocate or pull
> from storage what needs to be there and resume the instigating
> instruction as if nothing happened (which is part of what
> distinguishes the 68010 from the 68000 - instruction restart).
>
> On the PDP-11, we used overlays to load, say, 32K of code into 16K of
> physical memory, pulling in routines when they were needed, but it was
> done at the application level, not the instruction level. It is not
> the same thing as demand-paged virtual memory (which_is_ used to make
> it seem that there is more memory than physically installed).
Well. A PDP-11 can restart an instruction if needed, and you get a trap
when trying to reference virtual memory that isn't enabled in the MMU.
SO all the components for demand paging is there in the hardware.
Overlays solve a different problem, so it's not really meaningful to
compare them to demand paging. Even if an OS on the PDP-11 had demand
paging, you would still need to use overlays exactly the same way as
now. Overlays solves the problem that the virtual address space is only
64K. Demand paging does not solve that. Demand paging solves the problem
of not needing to have all virtual address space mapped to physical
address space at the same time, thus saving on physical address space.
You could say that demand paging makes more efficient use of physical
memory. And it is also required if you want to map more virtual memory
than you have physical memory. (But we already hashed through that :-). )
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2010-10-30 01:12, Rich Alderson<RichA at vulcan.com> wrote:
> From: Johnny Billquist
> Sent: Thursday, October 28, 2010 2:46 PM
>
>> > Why are people so hung up on physical memory size vs. virtual memory
>> > size when they need to define what virtual memory is?
>> > I just don't get it.:-)
> Perhaps because that's the way the term of art "virtual memory" (whether
> as segments or as pages) has been defined since it was first conceived?
>
> Virtual addressing is necessary for virtual memory. The converse is not
> true.
Well, it is obviously not a definition DEC agrees with, so I guess that
means there are two different schools (atleast) here.
And when talking about the VAX (which this thread started with), it
might be meaningful to use DEC's definition?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> 1. > The PDP-11 was in architectural ways more important than the VAX, if
> ? > nothing else than just because the VAX was basically just extending the
> ? > PDP-11.
Just to throw another question into the fire:
Just how important was the PDP-11 or VAX-11/780 hardware architecture
in the grand scheme of things? Did either machine really bring
anything new to the table?
Don't confuse popularity with importance - we all know that sometimes
unpopular inventions are hugely influential (Alto?).
--
Will
On 2010-10-28 23:02, Rich Alderson<RichA at vulcan.com> wrote:
> Because the VAX offered a virtual memory capability (hi, Johnny!:-), it
> did change the way Unix developed, but so did other ports (Interdata, for
> example, and even the IBM Series/1).
One more thing here. This is not directly to you, Rich, but this line is
as good an introduction for me throwing another wrench in the machinery
as any... And I do love wrenches.
It has been stipulated that the PDP-11 don't have virtual memory, but
the VAX do, and various arguments for this view.
As far as I can tell (and people, please correct me if I've gotten this
wrong) the reason for this view boils down to:
1) The physical address space is larger than the virtual on a PDP-11.
2) The PDP-11 don't load just parts of the memory and handle page faults
as a way to do demand paging.
Now, as for #2, I think I have established that some models of the
PDP-11 could in theory do this, if you just wrote the software for it.
The fact that noone have does not take away the capability. If anyone
disagree with this, I'll be happy to explain exactly how the code should
look like on the PDP-11 to do demand paging.
As for #1, I now drag out DEC STD 032 as exhibit A. It's a wonderful
document, more commonly known as the VAX Architecture Reference Manual.
More specifically, the version called EL-000 32-00.
Anyone can read it, it's on bitsavers.
http://www.bitsavers.org/pdf/dec/vax/archSpec/EL-00032-00-decStd32_Jan90.pdf
Now, I direct you all to page 4-7 of that document, which talks about
physical addresses on a VAX.
Notice how a physical address on a VAX can be 34 bits, while the virtual
address is only 32 bits.
Next question: Does the VAX not have virtual memory any more now that
I've pointed this out? Or do you need to redefine virtual memory in yet
a new and strange way to exclude the PDP-11... :-D
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2010-10-29 17:34, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
> On 2010 Oct 28, at 2:46 PM, Johnny Billquist wrote:
>> > On 2010-10-28 23:02, Brent Hilpert<hilpert at cs.ubc.ca> wrote:
>>> >> How about the notion that the PDP-11 was where several prior but
>>> >> then-topical innovations coalesced into one machine/architecture?
>> >
>> > I think that would be a very dubious, and hard to prove claim.:-)
> It may be more work than proving an individual claim of innovation, but
> it is still a plausible notion to research historically.
You're right. And it might be true. Just hard to prove.
>>> >> ...
>>> >> On the topic of memory, I would agree with Johnny about "virtual
>>> >> addresses", but differ on "virtual memory": virtual memory to me has
>>> >> always meant demand-paging where the RAM address-space seen by the
>>> >> user
>>> >> can be larger than the physical RAM, distinct from the simple mapping
>>> >> of addresses, but the use of the term is a matter of definition.
>> >
>> > Thank you.
>> > But what, pray tell, would you say a virtual address pointed to, then?
>> > Magic smoke?:-)
> Physical memory via the MMU; this is not a contradiction.
You know, a virtual address on a VAX points to physical memory via the
MMU as well. :-)
The point of virtual memory is that appears as a single, continous
memory space, even though it might be scattered all around in physical
memory, and you can have several virtual mappings for the same memory
space, which do not translate to the same physical memory.
That is what defines virtual memory, I'd say. Not how many bits there
are, or by how the OS reacts when you address memory for which you not
currently have a valid mapping.
>> > Why are people so hung up on physical memory size vs. virtual memory
>> > size when they need to define what virtual memory is?
>> > I just don't get it.:-)
> Because there is a fundamental difference between having your valid
> address space limited to available physical RAM, even if you can map a
> "virtual" address to different places in that RAM, and having a
> transparently addressable (large) address space unlimited by a lesser
> quantity of physical RAM. In the latter it*appears* (hence virtual)
> that you have more RAM than you actually do. This has always (IME) been
> the common meaning of "virtual memory".
I assume you've seen my post by now, where I point out that the physical
address space of a VAX was/is 34 bits, while the virtual address is 32
bits. So you can have the exact same scenario on a VAX that you normally
have on a PDP-11. :-)
I mean, on the PDP-11, let's pretend you had the exact same
architecture, but you limited the physical address to 12 bits, would
that then have meant that it had virtual memory? Just because you put an
arbitrary lower limit on one parameter?
> I'm too many years away from programming a PDP-11, but while it may as
> you suggest have been possible to do demand-paging in principle, how
> complex might it have been in practice? Trapping an address fault might
> be easy enough, but what about instruction restart/re-execution while
> accounting for all possible side effects that may or may not have
> occurred between the start of the instruction and the address fault.
Not complex at all. But the OS would have to keep some more data around
to be able to figure out where to page in data from when a page fault
occurred, as well as keeping track of allocated physical memory in a
different way than any current OS do. RSX (which is the OS I know best)
can keep physical memory usage tracking simpler since you always
allocate chunks of physical memory, not pages. And the executable part
of a program is just one chunk, even though it might be many pages.
And the whole chunk is moved in and out from swap.
A program can, however, have several chunks mapped in. Shared libraries
are their own chunks, and you have a lot of other kind of chunks as
well. At most, your program might be referencing around 32 chunks, I
think. (Don't remember the actual limit, or how it is enforced.)
And a chunk can be more than 64K. It's just that you cannot have more
than 64K mapped into your virtual address space at one time.
One more potential headache is that the pages on a PDP-11 are variable
in length. In addition to the page protection bits, you also have a page
length field in the MMU, so you don't need to allow just nothing, or all
8K of a page. The granularity of the length is 64 bytes. And you can
choose whether the top, or bottom part of the page is valid.
As for instruction restartability, it works just fine. DEC did think of
that. But that is also why I'm saying not all processors could do demand
paging. You need MMR3 (I think it is), which keeps a scorecard of how
much registers have been modified by the aborted instruction, so that
you can back out of it again. Older machines don't have that register,
and thus cannot undo a partially executed instruction.
> IIRC, the 68000 series ran into this problem when people started trying
> to do (demand paging) VM with it. When an address fault occurred, not
> all of the instruction state was saved and restarting the instruction
> became a problem. It was fixed in the next version but I forget where
> in the series (68010->20, 20->30, etc).
It was a problem in the original 68000. It was fixed in the 68010,
unless my memory fails me.
One more an example of how much better the PDP-11 was than the 68K. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> From: Johnny Billquist <bqt at softjar.se>
>
> I have not seen anyone comment any of the other things I listed as
> possible firsts on the PDP-11.
> Can anyone come up with an earlier machine that used condition codes?
The ICT 1301 had up to 100 'indicators' specified by two BCD digits in the instruction. All could be tested with an unconditional jump and some could be set and unset by program too. Number zero was always on to give an unconditional jump. There were ones for equal, greater and less as well as overflow, parity error, front panel switch states, as well as various peripheral statuses. Does that count?
> How about general registers with addressing modes, which is totally
> orthogonal? How about having the PC as a general register?
Not quite the same thing but IIRC the Elliott 920A used core location zero as its program counter. To be more accurate it used 0 by default when not using interrupts. When using interrupts it used 0 for level 1, 2 for level 2, 4 for level 3 and 6 for base level code. It also used those addresses plus one for its modifier (B) register. This speeded up interrupt processing as no need to save those registers.
On 2010-10-28 23:02, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
> On 2010 Oct 28, at 10:51 AM, Chuck Guzis wrote:
>> > On 28 Oct 2010 at 13:20, William Donzelli wrote:
>>> >> I was initially thinking about just the hardware architecture when the
>>> >> machines were being designed, not the software aspect, nor what the
>>> >> machines did (or influenced) after they were released. The
>>> >> aforementioned memory mapped I/O, for example.
>> >
>> > Not to be too much of a wet blanket, but how many of those DEC-unique
>> > innovations (even if you manage to assert that they originated with
>> > DEC) persist in today's hardware? Do modern PCs use memory-mapped
>> > I/O? The 68K, but for some Freescale relics, is history.
>> >
>> > Major innovations, such as virtual memory and orthogonal instruction
>> > sets and hardware-implemented stacks preceded the PDP-11.
> How about the notion that the PDP-11 was where several prior but
> then-topical innovations coalesced into one machine/architecture?
I think that would be a very dubious, and hard to prove claim. :-)
> The VAX was riding on the coattails of the market success of the -11
> and provided existing PDP-11 installations with increasing demands with
> a way forward, and it grew from there. That's a bit of a tautology, but
> it is to say it did exactly what it was designed and marketed for.
Yes. The VAX did not really innovate anything. It was more of a rather
successful merge of many things, and following in the footsteps on the
PDP-11, and building further on that foundation.
> On the topic of memory, I would agree with Johnny about "virtual
> addresses", but differ on "virtual memory": virtual memory to me has
> always meant demand-paging where the RAM address-space seen by the user
> can be larger than the physical RAM, distinct from the simple mapping
> of addresses, but the use of the term is a matter of definition.
Thank you.
But what, pray tell, would you say a virtual address pointed to, then?
Magic smoke? :-)
Why are people so hung up on physical memory size vs. virtual memory
size when they need to define what virtual memory is?
I just don't get it. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I know this is rather last minute... but if anyone has any interest
e-mail me before 5:30PM, otherwise the following go into the recycling
bin.
NEC Silentwriter 95
- postscript
- parallel interface
- worked when last used around 2002
- toner included (unknown amount remaining)
Sony? (Dell branded) 17" trinitron CRT monitor
- working, nice picture
- plastic yas yellowed some (uniformly)
Sorry for the late notice, figured there wouldn't be much interest
but I'd check.
Items are for pickup in either Sharon, MA or Cambridge, MA.
If there are parts you want from either, let me know, it could
be arranged.
-- Curt
Hi guys,
I'm pretty sure someone posted this on-list in the past (possibly
Chuck?), but I can't find it in my local archive or on the
classiccmp.org list archive...
I've got a Mitsubishi MF356C-799MA disc drive, part number 72X6101. This
is apparently a 2.88MB disc drive from an IBM PS/2, and was (near as I
can tell) also sold as an FRU under part number 64F0204. Here's where
the confusion starts: it uses a single 34-pin connector for both power
and data.
I found this site:
http://ohlandl.ipv7.net/floppy/Floppy_Pinouts.html#34-pin_MS
And another page with similar information:
http://ohlandl.ipv7.net/floppy/floppy.html).
These give the 34-pin interface pinouts, including the details for the
Electronic Eject drive (the 92F0132, aka Sony MP-F40W-07 / MFD-40W-05)
and a stern warning to leave pin 6 (+12V) open...
Catch is there's nothing about Data Rate Select on pin 2 (which appears
to be 0V for 720K and 1.44MB, or high/floating for 2.88MB), or the Media
Type ID and Drive Type ID pins.
Basically what I want to do is put this drive in a PC, format a couple
of 2.88MB discs, then wire it up to the DiscFerret and make sure the
acquisition engine and decoder can handle the higher data rate. The
timing analyser and simulator say it should work, but I'd actually like
to see it working :)
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
Hi guys,
I'm pretty sure someone posted this on-list in the past (possibly
Chuck?), but I can't find it in my local archive or on the
classiccmp.org list archive...
I've got a Mitsubishi MF356C-799MA disc drive, part number 72X6101. This
is apparently a 2.88MB disc drive from an IBM PS/2, and was (near as I
can tell) also sold as an FRU under part number 64F0204. Here's where
the confusion starts: it uses a single 34-pin connector for both power
and data.
I found this site:
http://ohlandl.ipv7.net/floppy/Floppy_Pinouts.html#34-pin_MS
And another page with similar information:
http://ohlandl.ipv7.net/floppy/floppy.html).
These give the 34-pin interface pinouts, including the details for the
Electronic Eject drive (the 92F0132, aka Sony MP-F40W-07 / MFD-40W-05)
and a stern warning to leave pin 6 (+12V) open...
Catch is there's nothing about Data Rate Select on pin 2 (which appears
to be 0V for 720K and 1.44MB, or high/floating for 2.88MB), or the Media
Type ID and Drive Type ID pins.
Basically what I want to do is put this drive in a PC, format a couple
of 2.88MB discs, then wire it up to the DiscFerret and make sure the
acquisition engine and decoder can handle the higher data rate. In
theory it should work, but I'd like to see it working :)
Thanks,
--
Phil.
philpem at philpem.me.uk
http://www.philpem.me.uk/
I'm getting into this a bit late (I was travelling last week), but I have a few comments, based on 18 years of working at the Field Museum of Natural History in Chicago.
>Message: 4
>Date: Sun, 24 Oct 2010 19:22:50 +0100 (BST)
>From: ard at p850ug1.demon.co.uk (Tony Duell)
>Subject: Re: Cataloguing in a museum setting [was Re: nonsense...]
>>
>> On Sat, 23 Oct 2010, Tony Duell wrote:
>> > Sure, but that's then 4 levels. I ahve no problem extending the
>> > heirarchical system to as many levels as are necessary, my query is why
>> > it's noramlly limitied to 3. Why not just have as many levels as are needed.
>>
>> A properly designed system should be extensible to as many levels as are
>> needed.
>
>That's _exactly_ my point. Having atbitrary limits may cause problems
>later on.
>
There could be an arbitrary limit because that is what some database programmer decided was sufficient when the collections program was written (cf. Y2K).
>>
>> > And why recorsd the year of acquisition? What importance is that? Why not
>> > just a number for each artefact starting at 1?
>>
>> It is unlikely that you nor I would care much about the year of
>> acquisition. ?But the bean-counters care.
>
>Ah no, you misnderstood me...
>
>Presumanbly there is a database of the artefacts in the museum, indexed
>by the indentification numbers. That database includes more details about
>the particular object, ?things like (I would hope), options, serial
>number (s), version, etc. All we've been discussing. I see no reason why
>the date of acquisition (full date, not just the year), source (maybe
>'anonymous donor' :-)), and the like should not be stored there as well.
>It's far better to store too much information than too little.
>
>But what I am wondering is why the year of acquisition should be a field
>in the indentifier.
>
The Anthropology collections at FMNH were numbered sequentially, which was a bit of a PIA. Having looked in the catalog ledger books, I might know that artifact 186276 is a Nazca pot collected by Alfred Kroeber in 1927, but is 186277 from the same collecting field trip or is it something from Tibet? Having a number like 1927.23.49 for that pot would make it easier to find associated artifacts.
For my field work, I used RegionSite-Feature.artifact, such as M10-5.26. In the end, though, any cataloging system is arbitrary.
<snip>
>
>-tony
I would also second the comment (Fred's?) that cataloging needs to be done by someone with knowledge of the material being cataloged.
As to cataloging individual boards within a computer, we did not have a comparable situation -- the FMNH's artifacts are usually single items. Where there were, for example, multiple panels in a carved wall, the panels could be numbered 98123.1, 98123.2, etc. The question that has been raised in regards to computers is, where do you stop dividing the artifact??Again, the decision is somewhat arbitrary. The boards might not be numbered, but presumably there is a description of the computer on record?that lists its major components.
Bob
Typically on 3.5" floppy.
Unless otherwise stated, items are boxed with manuals and 3.5"
floppies - believed complete, presumed maybe readable.
Also listed on Freegle.
THIS STUFF MUST be gone by the weekend or it's going on the tip.
If interested, please email: "Chris Comley" <ccomley at gmail.com>
MS Excel for Windows v 4 - box, manuals, floppies
MS Office 95 Standard - box, maunals CD.
Symantec "Norton" backup v3.0 - box, manuals, floppies
MS SDK for Win32 NT - floppy and CD - (1993 vintage)
MS Windows for Workgroups 3.11 - retail box, floppies
MS DOS 6.2 "UPGRADE" - retail box - floppies
Wordperfect 6.0 for Windows. unopened retail box - floppies
MS Project 4.0 - update - OEM box - floppies
MS NT Server 3.51 "step-up edition" - retail box - floppies and CDs.
Informix WINGZ 1.1 - Windows and OS2 edition. 52.5 floppies
MS Backoffice Svr 2.0 retail box - CDs
MS Windows NT "Training" - set of books, CDs, VHS tape. (Refers to ver
3.51)
After Dark screen saver for Windows - 3.0 - box, maunals, floppy
Stacker 2.0 disk comperssion s/w - box manuals dual floppies Stacker 3.0
disk compression s/w - for Windows and DOS - Upgrade pack - floppies
Apple Remote Access client for Macintosh - still sealed.
HP NewWave 3.0 for Windows - retail box, manuals, 5.25" floppies
Epson Esc/p (printer command language) reference manual
The Corporate Retreiveal - text retreival s/w - manuals, 5.25% floppies
Arcserve ver4 for Netware 2.2 (5usr) - manual, box, floppies
Sitka "10-net" networking s/w - v5.0 - for Windows and DOS - 3 user
starter pack - dual floppy
Supercalc 5 ref manual (manual only no s/w)
Wordperfect for Windows 5.2 - box, .manuals, floppies
Book - The Internet, complete reference (Osborne Books) (c) 1994
(Confused.com take note!!)
Crosstalk for Windows - dual floppy, box, mnanuals
Double DOS - multitasking for DOS - manual, floppyies.
McAfee VIrus Scan Deluxe - v4 (1998) - box, manual, dual floppies
MS "Plus" companion pack for W95. box, manual CD
Delrina Winfax Pro v 4.0 - box, manual. floppies
MS Access UPGRADE 2.0, box, manuals, floppies
Lotus Notes WIndows Client 3.0 - manual, box, flopps
MS Office UPDATE ver 4.2 box. lots of manuals, floppies
MS Office 4.2 - box of floppies only
Slackware Linux rel 1.1 - glossy box and CDs
Pinpoint "Clicknet" 2.0 Pro - Network diagram tools - box, mans, floppies
MS Excel 3.0 - white box, 5.25 Disks
MS Office UPDATE 4.2 - box, incomplete manuals - floppies
Al and everyone else,
I believe Al has had success interfacing a Diablo Model 31 with a
PC computer (I assume so, since he uploaded the Alto diskpacks up to
bitsavers.org). Al, Can you (or anyone else) please provide the steps
on how to do so?
If I can verify the disk drive is working, and the disk packs have valid
data on them, this would be yet another step completed in getting the
alto up and running =)
Thanks!
On 10/27/10, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
>> I found that octal on the PDP-11 with 16-bit words and 8 bit bytes
>> was unnecessarily confusing.
>
> Except that the many of the PDP11 instructions are easy to decode if
> written in octal (4 bit opcode, 3 bit addressing mde, 3 bit register
> select, 3 bit addressing mode, 3 bit register select). I would hate to
> have to work with PDP11 machine code in hex...
Agreed. When I first started working with PDP-11s, my supervisor
asked me for a PDP-11 program that would read the "window" register on
our product then write it back to the same address and loop (it was a
write-only register for each side - what each processor read was what
the other had previously written). I thought a second and recited,
"1000 slash 13700 lf 177300 lf 10037 lf 177300 lf 137 lf 1000 enter
1000 G" (or something substantially similar to that). He got annoyed
and told me to go sit down and write him a program. I told him to
turn around and type in what I was telling him. On the third
recitation, he started typing. Being two moves and a jump, it worked
the first time. He was gobsmacked that it was possible for a human to
spontaneously emit meaningful octal.
Given the spacing of the addressing modes, I wouldn't have wanted to
try it in hex without writing it down.
-ethan
Date: Wed, 27 Oct 2010 00:20:31 -0400
From: William Donzelli <wdonzelli at gmail.com>
Subject: Re: What are these IBM 'thingys'
> My father (NOT a computer historian) used to tell me that IBM patented the
> shape of the hole! ?That resulted in a few short-lived attempts at
> round-hole cards, etc.),
More than a few, actually. There were many, including a trinary one
(Super Bee or something. Anyone help?) that used cards with
information only on the four edges of the card, but the choices were
hole, no-hole, or hole-with-no-outside-edge.
--
Will
++++++++++++++++++++
Don't forget EPCs (Edge Punched Cards); basically an 80 column format card
with prepunched feed holes and 8-channel paper tape perforations along one
edge.
> From: Al Kossow <aek at bitsavers.org>
>
> On 10/25/10 7:26 PM, leaknoil wrote:
>> It looks to me like a punch card exactly fits in there and the contacts are what read the holes in the card.
>
> nope
>
> cards are read with 12 brushes
Or 80 brushes, I think the holes in cards were made tall and narrow to make reading them that way easier.
> From: Mr Ian Primus <ian_primus at yahoo.com>
> And glaringly so. To say that the 11/780 is the first 32 bit machine is just silly. Prime had a 32 bit machine in 1972. And I know that there were others - but the Prime is the machine that I know the best :)
I think I'm right saying the Manchester 'Baby' had a 32 bit word in 1948, actually 32 of them on one Williams tube. However as it was a serial machine the data path to memory was actually one bit wide so it depends how you define bit size, but I was taught it was the largest addressable unit of memory and by that definition it had a 32 bit word.
There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
Actually as I worked for a defence contractor I knew about the 68k before I heard of the VAX. The engineers did not believe the Motorola design was practical and we worried about a large 64 pin chip in the environment of a military helicopter's avionics bay (G forces, vibration, expansion, cooling etc) and it was decided to go with the 48pin Zilog Z8001 instead. Possibly a big mistake but at the time sample Z8001s were available to us but MC68000s were still estimated to be at best months away. When I left the company a couple of years later we had just placed an order for a VAX 11/780 to augment our GEC 4080, GEC 4070 and a Prime.
> From: Richard <legalize at xmission.com>
> Roger Holmes <roger.holmes at microspot.co.uk> writes:
>
>> ither. The 29000 processor [...]
>
> 2900, not 29000. The 29xx is a bit-slice CPU design made up of a
> bunch of chips. The 29000 is a single chip CPU that came later.
Quite right. Brain parity error, but the difference is only a 0 :-)
IIRC we used six 4 bit slices and a controller chip in one of our machines called CHLL which was a two off special, one bench prototype and one flyable prototype. I got to modify some of the microcode for the bench machine and worked on the CHLL 'compactor' which was really a compiler but the idea was that the instruction set was a Compacted High Level Language so the compiler was very simple (it wasn't) and he machine would be very efficient (it wasn't). Trouble was someone got carried away and implemented much of Algol 60 instead of the Coral 66 they had been asked to do. I just cleaned it up and got it through its acceptance test with the minimum of work. I remember telling them I could fix a bug easily (by incrementing a field for a particular instruction as it went through the back end of the code generator) but that it was not the right place to fix it. I was told to fix it in the wrong place and I did so and they closed down the project. Apparently the flyable prototype was used at the Royal Aircraft Establishment at Farnborough - as a door stop!
At the time I had neither the experience nor the confidence to tell them they were wrong, I was just a year out of University, supposedly a trainee programmer working for a huge company (4000 staff at just the one site I worked and many other sites too) and its only looking back years later I realised fully what had gone on.
I snagged a copy of the first three volumes of this set from the company
library when they were thinning the stacks.
They were published by The People's Computer Company in 1980.
They are a really cool snapshot of the microcomputer stuff that was doing on
in the late '70s. Is there an online copy?
-chuck
On 2010-10-27 00:16, Roger Holmes<roger.holmes at microspot.co.uk> wrote:
>> > From: Johnny Billquist<bqt at softjar.se>
>> > On 10/26/10 04:20, Roger Holmes<roger.holmes at microspot.co.uk> wrote:
>> >
>>>>> >>>> From: Mr Ian Primus<ian_primus at yahoo.com>
>>>>> >>>> And glaringly so. To say that the 11/780 is the first 32 bit machine is just silly. Prime had a 32 bit machine in 1972. And I know that there were others - but the Prime is the machine that I know the best:)
>>> >> I think I'm right saying the Manchester 'Baby' had a 32 bit word in 1948, actually 32 of them on one Williams tube. However as it was a serial machine the data path to memory was actually one bit wide so it depends how you define bit size, but I was taught it was the largest addressable unit of memory and by that definition it had a 32 bit word.
>> >
>> > What does "largest addressable unit of memory" means? I totally fail to
>> > understand that. Sounds like "the largest memory chip that can be
>> > utilized", but that can hardly be the meaning.
> Compare with another thing I was taught. A byte is the smallest addressable unit of memory. By this definition I have worked on machines with bytes sizes of 3, 8, 18, 24, 36 and (I think) 60. In most of the latter ones, a byte was also a word. I guess you exclude memory to memory block move instructions, then consider the instructions which can load and save data and find the one which acts on the largest number of bits. I think by this definition a 68000, a Z8000, and the Manchester Baby all had 32 bit words. The VAX may have had 32 bit of 64 bit words even if it had just a 32 bit data path. My ICT 1301 has 48 bits words and 48 bit bytes even though its mill was only 4 bits wide. The data path from core memory to the 'A' register was 50 bits in parallel (it had two parity bits), but the data path between registers was only 4 bits, or in one case two sets of 4 bits. It was a serial/parallel architecture which allowed the end user price to be kept just below 250,000 pounds
f!
> or a 5 tape deck mag tape machine with card reader, card punch, line printer, one drum and 2000 (decimal) words of core.
Hmm. Gotcha. But in that case, a VAX would be a 128 bit machine, since
the largest quantities it can operate on is 128 bits.
And a PDP-11 would, I guess, be a 32-bit machine, and a Z80 a 16-bit
machine.
Hmm, I do not think I agree with that definition.
> Sorry for rambling and thanks for all who commented on my 41 years of programming experience.
I think it's more convenient to look at what the "natural size" of the
registers are.
I say "natural", because for instance, on the Z80, you can combine
registers, but I would define that as not the natual size. So, HL is a
16-bit register, and you can do pretty much anything with the, but it's
actually the registers H and L combined together, and you can address
each register separately as well. And they are 8 bits.
And the PDP-11 have 16-bit registers, but some operations work on a
combination of two registers combined. Once again, not "natural". And
the same goes for the VAX (obviously).
On the PDP-10 the accumulaltors are 36 bits, but you have instructions
that can deal with bytes of any size between 1 and 36 bits. And they
automatically manage the manipulations on parts of accumulators. But
those smaller byte sizes aren't natural either, so it is 36 bits on that
machine. :-)
But it might have made more sense back in older days..?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Oh, yeah... One more thing...
> The VAX-11 (note that "-11" in the names of the first models!) added the
> use of demand-paged virtual memory (that is to say, disk-based storage) to
> the PDP-11, then expanded the instruction set into the new 32-bit word size.
The -11 in VAX-11 was placed there to indicate the inheritance to the
PDP-11, and the fact that it could execute PDP-11 code as well (even if
only in user mode).
The -11 moniker was dropped when PDP-11 compatibility was dropped.
(And for the person who raises his hand and asks about the VAX 86x0
machine, which do have PDP-11 compatibility, those machines were
internally referred to as VAX-11/79x, but marketing (or whoever) decided
that it would be cool to call them 8600 instead. I even once read a
rumor that 8600 was chosed as it was twice that of 4300, but I don't
know. But if you read DEC documentation on the 86x0 machine, you can
still find plenty of references to VAX-11/790.)
If you still doubt what I write, I suggest this source:
http://www.bitsavers.org/pdf/dec/vax/VAX_archHbkVol1_1977.pdf
which is the very first edition of the VAX-11/780 Architecture Handbook.
Read chapter 1.1, Introduction.
Second paragraph has this nice piece of text:
"The goals of the VAX architecture were to provide a significant
enhancement to the virtual addressing capability of the PDP-11 series
consistent with small code size, easy exploitation by higher-level
languages, and a high degree of compatibility with the PDP-11 series."
Now, if people could only read documentation, and learn to use terms the
correct way... ;-) :-D
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2010-10-27 00:16, ard at p850ug1.demon.co.uk (Tony Duell) wrote:
>> > VAX stands for "Virtual Address eXtension", note the "extension".
> I always thought that VAX-11 meant it was a PDP11 that had the
> 'eXtension' of 'Virtual Addresses'.
You obviously need to pick up any PDP-11 processor handbook as well, and
check out the memory management chapter. DEC defined the PDP-11 as
having virtual addresses already from the first day the MMU was
available for the machine. :-)
>> > Extension normally means that you modify/extend something that already
>> > exists, in this case the virtual address. On a PDP-11, the virtual
>> > address is 16 bits, the VAX extended it to 32 bits, which is a huge
>> > improvement (and the biggest bottleneck of the PDP-11, as I'm sure all
>> > people know). The physical address on a PDP-11 is 22 bits, while the
>> > physical address on a VAX varies, but on the 11/780 I only think it was
>> > something like 24 bits.
> Hmmm. I was under the impression there was a difference between virtual
> memory/addresses and an MMU. Namely that the former impliled a larger
> logical address space than the physcial address space and that if a
> program tried to access a memory page that wasn't currently mapped to a
> physcial area of memory, the OS would be given the chance to load the
> approraite data from disk (or whatever) into RAM and map the page
> appropriately.
The size of the virtual address space compared to the physical is not
really relevant. After all, on a VAX, they are actually the same. The
physical address is defined as 32 bits, and the virtual address as well.
However, no VAX actually implemented a full 32 bit physical address
space, but there were many different max physical memory limits on
different machines.
A virtual address is "virtual". It's not real. It's a fake. :-)
The MMU is what does the translation between a virtual and a physical
address. Exactly how these two domains look like have less to do with
the definition. And exactly how the translation is done is also less
relevant. As long as you can present to several programs running on the
same machine, a memory space in which they think they are the only one
playing with the memory, and they have an "unlimited" (within the size
of the address space) access to that memory in a linear fashion, it
qualified as virtual memory. (What would you call it?)
> The 11/780 logica address space is larger than the physical one, the
> (memory managed) PDP11's is not.
Yes. So what? In which way would that make the virtual address in a
program running on a PDP-11 less virtual? After all, you are totally
shielded from how the actual physical memory layout, allocation,
translation or mapping is done. You are only playing within your virtual
memory space.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hi, Rich. Thanks for broaching an interesting topic of which I'm rather
fond... :-)
On 2010-10-27 00:16, Rich Alderson<RichA at vulcan.com> wrote:
> From: Johnny Billquist
> Sent: Monday, October 25, 2010 9:08 AM
>
> 1.> The PDP-11 was in architectural ways more important than the VAX, if
> > nothing else than just because the VAX was basically just extending the
> > PDP-11.
>
> 2.> However, I also object to the discussion about "Virtual memory" as
> > something new the VAX brought to the table.
>
> 3.> Virtual memory worked just fine on a PDP-11 as well, thank you very
> > much, as it also worked fine on a bunch of other machines, and had been
> > doing for quite a while.
>
> 4.> VAX stands for "Virtual Address eXtension", note the "extension".
> > Extension normally means that you modify/extend something that already
> > exists, in this case the virtual address. On a PDP-11, the virtual
> > address is 16 bits, the VAX extended it to 32 bits, which is a huge
> > improvement (and the biggest bottleneck of the PDP-11, as I'm sure all
> > people know). The physical address on a PDP-11 is 22 bits, while the
> > physical address on a VAX varies, but on the 11/780 I only think it was
> > something like 24 bits.
>
> 5.> The VAX also introduced demand pageing, compared to the PDP-11, where
> > you normally didn't do that (and not all models could even possibly do
> > it), but demand pageing as such wasn't new either. DEC was already doing
> > it with the PDP-10 running TOPS-20 (and other companies had also done it).
>
> Addressing 1, 2, 4, and 5:
>
> The "Extension" in 'Virtual Address Extension" does not refer to extending
> the virtual address in the PDP-11, but rather to extending the PDP-11
> architecture with virtual addressing. The PDP-11's 16-bit address is real,
> not virtual in the usual definition; the use of memory management to select
> from within an 18- or 22-bit memory space does not make it virtual.
Sorry, but I'll have to totally disagree with you, and so does all the
processor handbooks for the PDP-11. :-)
Virtual addressing have nothing to do with demand paging, or even paging
(even though I know Wikipedia uses that very broken definition (or
atleast used to)).
A virtual address is... Well... Virtual. It does not match a physical
address. Instead it is an address into an imagined memory space, virtual
memory. This virtual memory space would appear as just your own in a
system. Another process in the same system have another virtual address
space, using the same virtual addresses you are, but you are not
actually referring to the same memory. It's virtual. :-)
A virtual address gets translated into a physical address by an MMU.
The "Virtual Adress eXtension" (aka. VAX) was a virtual address
extension to the PDP-11, nothing more.
The PDP-11 already have virtual addressing. Pick up any PDP-11 processor
handbook and read about it yourself. Or check
http://www.google.ch/url?sa=t&source=web&cd=2&ved=0CB4QFjAB&url=http%3A%2F%…
, for the (arguably) yucky PDP-11/40 online. Look at chapter 6 - Memory
Management.
On a PDP-11, an address can either be physical, in case the MMU is
turned off, or else virtual. The virtual address gets translated to a
physical address by the MMU, by using the page table and some simple adders.
In case you run on a PDP-11 with the MMU turned off, the 16-bit address
just gets extended to 18 (or 22) bits by using zeroes for the high bits
of the physical address. if the MMU is turned on, the virtual 16-bit
address is translated into a 18 or 22-bit physical address.
> The VAX-11 (note that "-11" in the names of the first models!) added the
> use of demand-paged virtual memory (that is to say, disk-based storage) to
> the PDP-11, then expanded the instruction set into the new 32-bit word size.
VMS added demand paged virtual memory. There is nothing preventing you
>from writing an OS on the VAX which don't use demand paging, just as
there is nothing preventing you from writing an OS for the PDP-11 which
would do demand paging (assuming you have a PDP-11 model with the
neccesary features implemented in the MMU, which not all have).
> Addressing 2 and 5:
>
> Burroughs introduced the B5000, the first computer with virtual memory
> (segmented rather than paged) in 1961; the British brought out the Atlas in
> 1962. Multics used both segmentation and paging on the GE-645, beginning
> in 1964. DEC provided a segmented memory model in the PDP-6 (1964) and
> PDP-10 (1967); BB&N created a pager for the PDP-10 and brought TENEX, with
> demand paging, to the world c. 1970. When DEC licensed TENEX and modified
> it for the KL-10 processor (born at the Stanford AI Lab as the SuperFoonly!),
> they added the working-set concept which had been discovered by (IIRC)
> Denning in his research on demand-paged memory systems, and christened the
> result "TOPS-20".
No additional comments. And you know the PDP-10 much better than I do. :-)
> Addressing 3:
>
> I don't believe that there was ever demand-paged virtual memory on the
> PDP-11, but I'm willing to be shown the error of my ways. Please point me
> at documentation for an operating system which did that.
Sorry, just as with you, I don't know of anyone who did that. But I can
tell you how you should do it, in case you'd be interested in actually
doing it. There is nothing in the hardware that prevents you.
The biggest reasons why noone did it are that:
1) The physical memory is much larger than the virtual memory on a
PDP-11, meaning that it's normally not a big problem to actually have
all virtual memory always paged in when a process is running. You will
never see working sets that are larger than what can be held in memory
at one time, thus one big reason for demand paged memory is lost.
2) The page size of the PDP-11 is 8K, which at the time was pretty big.
With that size, you actually only have eight pages for a process. Now,
why do demand paging, when you can at the most get 8 page misses before
everything is paged in? You might as well preload them, and skip the
whole demand paging mechanism.
3) Not all models of the PDP-11 MMUs support all the fancy stuff you
need. People weren't that interested in writing software that only
worked on some models (that did eventually happen in other ways anyway,
but only by slower evolution at a later stage).
So, no, I cannot point you to any system that implemented demand paging.
Maybe someone did it without us knowing about it. The fact still stands,
though. The PDP-11 allows you to do it. Is it then relevant if someone
actually did it or not?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> From: Eric Smith <eric at brouhaha.com>
>
>
>> You guys might like this one. I didn't realize AMD has been around that long.
>>
>> http://cgi.ebay.com/AMD-AM9080-INTEL-8080-CLONE-VINTAGE-COMPUTER-1978-RARE-…
>>
> What the item description doesn't say is that this is a development
> system for Am2900 series bitslice chips. The Am9080A (equivalent to
> Intel 8080A) is the only the host processor.
I will watch it with great interest. I have one too but mine also has a pair of 8 inch floppy drives attached in a separate cabinet. Never powered mine up either. The 29000 processor would have been in a unit under development not within this chassis. The unit contains emulated microprogram ROM. The 8080 loads microcode into the emulated ROM cards which were connected to the unit under development with ribbon cables.
Just picked up an nCUBE 2 from a list member, but I know almost nothing
about the machine (beyond wikipedia and my own examination of the machine
physically). I have the Sun 4/470 that front-ends it and, in theory, all
the software. But I've got no idea on how to actually _use_ it.
No one has donated nCUBE documentation to BitSavers, which pretty much
totally buggers me up. Is there anyone out there who is familiar with
these machines that, perhaps, could give me some pointers?
Muchas gracias all;
- JP
From: William Donzelli <wdonzelli at gmail.com>
>
>
>> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
>
> Big microcoded CISC was the dominant thinking in computer architecture
> at the time, so it is really hard to say that X influenced Y.
True
>
>> The engineers did not believe the Motorola design was practical and we worried about a large 64 pin chip in the environment of a military helicopter's avionics bay (G forces, vibration, expansion, cooling etc) and it was decided to go with the 48pin Zilog Z8001 instead.
>
> Why not use PGA or Flatpack?
For production the plan was for bare silicon mounted on hybrids but the silicon itself was large. Of course as production progressed die sizes would have been shrunk but not fast enough.
We also used up to 22 layer PCBs! IIRC, samples when they became available would have been DIPs, they were for the Z8001 for sure. We used our own Elliott 920ATC computers to load code into shared RAM before the microprocessor was released from reset. I also wrote a simulator (for the Z8001) for compiler, high level assembler and other utility software development.
Unfortunately working at a technical level on the leading edge does not pay very well in the UK. I was told I would not be able to progress to a higher grade without becoming a manager, so I left and became a major shareholder and director of a tiny company and have remained technical to this day. Somewhat to my surprise I found I can still out-program every other programmer we have ever employed despite now being 57 years old.
Date: Tue, 26 Oct 2010 10:28:12 +0100
From: Roger Holmes <roger.holmes at microspot.co.uk>
Subject: Re: What are these IBM 'thingys'
> From: Al Kossow <aek at bitsavers.org>
>
> On 10/25/10 7:26 PM, leaknoil wrote:
>> It looks to me like a punch card exactly fits in there and the contacts
>> are what read the holes in the card.
>
> nope
>
> cards are read with 12 brushes
Or 80 brushes, I think the holes in cards were made tall and narrow to make
reading them that way easier.
+++++++++++++++++++++++++++++++++++++++++++++
Exactly. In those electro-mechanical days cards were almost always read in
parallel, i.e. long edge first, because that's how those machines worked;
rotary selectors, type bars, sorter gates, etc., the timing of the entire
system was based on and ran in sync with the card moving through the various
digit positions 0 to 9 (and 11 & 12 for symbols and alpha).
Want to add two numbers? Take a rotary 10-position switch and connect it
mechanically through a solenoid-operated clutch so that as the card moves so
does the switch, each position corresponding to a vertical location on the
card. Starting with the switch in the 0 position, read the first card,
engage the clutch when it passes the 0 position and drop the clutch when a
brush makes contact through a hole in the card. Do the same with the second
card and the rotary switch will read the sum (with a few extra solenoids and
relays to handle carries).
Want to print it? Simple: you have a type bar with the digits in reverse
order, again synchronized to the rest of the machine. Start rotating the
switch and moving the type bar together and when the switch hits 0 fire the
type hammer.
Want to sort your invoices by client number? Take the card deck over to your
08x sorter, those machines you've all seen in old movies where the cards
move across and drop into different columns or pockets (usually flying out
and across the room for amusement - it wasn't funny when it really did
happen!). Rotate the column selector knob to the LSD column (it only had one
moveable brush) and press Start. As the card moves, it passes a set of
chutes each leading to one of those pockets and when the brush makes contact
through the hole the card is diverted to whichever chute it's under at that
exact moment. Go through all the cards, put the 10 piles back together in
sequence, repeat for each column up to the MSD and presto, they're sorted.
Ah, the good old days... I'd love to see some kind of emulation of these
systems...
When computers came along the whole paradigm shifted from parallel
processing to serial, and those card readers did indeed read the card from
left to right with only 12 brushes (more likely optical sensors) instead of
top to bottom with 80, although IIRC there were some combined serial and
parallel binary card formats.
Of course now we've seen the error of our ways and have returned to parallel
processing; a modern card reader would no doubt read cards top to bottom
again, with each column connected to its own CPU.
mike
> From: Johnny Billquist <bqt at softjar.se>
> On 10/26/10 04:20, Roger Holmes <roger.holmes at microspot.co.uk> wrote:
>
>>>> From: Mr Ian Primus<ian_primus at yahoo.com>
>>>> And glaringly so. To say that the 11/780 is the first 32 bit machine is just silly. Prime had a 32 bit machine in 1972. And I know that there were others - but the Prime is the machine that I know the best:)
>> I think I'm right saying the Manchester 'Baby' had a 32 bit word in 1948, actually 32 of them on one Williams tube. However as it was a serial machine the data path to memory was actually one bit wide so it depends how you define bit size, but I was taught it was the largest addressable unit of memory and by that definition it had a 32 bit word.
>
> What does "largest addressable unit of memory" means? I totally fail to
> understand that. Sounds like "the largest memory chip that can be
> utilized", but that can hardly be the meaning.
Compare with another thing I was taught. A byte is the smallest addressable unit of memory. By this definition I have worked on machines with bytes sizes of 3, 8, 18, 24, 36 and (I think) 60. In most of the latter ones, a byte was also a word. I guess you exclude memory to memory block move instructions, then consider the instructions which can load and save data and find the one which acts on the largest number of bits. I think by this definition a 68000, a Z8000, and the Manchester Baby all had 32 bit words. The VAX may have had 32 bit of 64 bit words even if it had just a 32 bit data path. My ICT 1301 has 48 bits words and 48 bit bytes even though its mill was only 4 bits wide. The data path from core memory to the 'A' register was 50 bits in parallel (it had two parity bits), but the data path between registers was only 4 bits, or in one case two sets of 4 bits. It was a serial/parallel architecture which allowed the end user price to be kept just below 250,000 pounds for a 5 tape deck mag tape machine with card reader, card punch, line printer, one drum and 2000 (decimal) words of core.
Sorry for rambling and thanks for all who commented on my 41 years of programming experience.
>
>> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
>
> That the PDP-11 influenced the VAX there can be no doubt about.
> The the PDP-11 influenced the 68K seems very probable when looking at
> the architectures, but that is guessing on our part.
>
> William Donzelli<wdonzelli at gmail.com> write:
>>>> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
>> Big microcoded CISC was the dominant thinking in computer architecture
>> at the time, so it is really hard to say that X influenced Y.
>
> Well, the fact that DEC explicitly stated that the VAX would be like the
> PDP-11, but extended to 32 bits seems like an obvious statement that the
> PDP-11 influenced the VAX. Not to mention the fact that they used the
> same peripherial buses, and at VMS V1, most of the applications were
> just the RSX programs moved straight over. Oh, and don't forget the
> compatibility mode in the VAX, which made it execute PDP-11 code. :-)
>
> As for the 68K, we are making more of a guess, but it seems like a
> fairly educated guess that the 68K was inspired by the PDP-11 (although
Agreed.
> I'd say the 68K is way inferior to the PDP-11...)
If you say so, I never used a PDP-11.
>
> Johnny
On 10/25/10 16:53, William Donzelli <wdonzelli at gmail.com> wrote:
>> > Also, the sentence starting "The VAX instruction set well revered would later on influence" needs restructured. The paragraph after the bullet points has more of the same error.
> You could say that the designers of the 68000 were influenced by the
> PDP-11, but I do not think you could say the same thing about the VAX.
> When the 68000 design was started, the VAX was still well under wraps.
> I can see no reason why DEC would have let the Motorola guys see the
> developing architecture.
>
> Anyway, in the mid/late 1970s, heavily microcoded very CISCy
> architectures were pretty much the design route of choice. It was
> everywhere. It is very difficult to pin down influences.
The PDP-11 was in architectural ways more important than the VAX, if
nothing else than just because the VAX was basically just extending the
PDP-11.
However, I also object to the discussion about "Virtual memory" as
something new the VAX brought to the table.
Virtual memory worked just fine on a PDP-11 as well, thank you very
much, as it also worked fine on a bunch of other machines, and had been
doing for quite a while.
VAX stands for "Virtual Address eXtension", note the "extension".
Extension normally means that you modify/extend something that already
exists, in this case the virtual address. On a PDP-11, the virtual
address is 16 bits, the VAX extended it to 32 bits, which is a huge
improvement (and the biggest bottleneck of the PDP-11, as I'm sure all
people know). The physical address on a PDP-11 is 22 bits, while the
physical address on a VAX varies, but on the 11/780 I only think it was
something like 24 bits.
The VAX also introduced demand pageing, compared to the PDP-11, where
you normally didn't do that (and not all models could even possibly do
it), but demand pageing as such wasn't new either. DEC was already doing
it with the PDP-10 running TOPS-20 (and other companies had also done it).
Johnny
I have stacks of duplicate BYTE magazines.
Would it be a sin to have them cut-up to be scanned, page-by-page?
Nothing from the 70's, I would do 80's era only.
Has anyone ever done this?
They wouldn't be posted online, it would be for personal research only.
I would certainly share the info with others if requested.
On 10/26/10 04:20, Roger Holmes <roger.holmes at microspot.co.uk> wrote:
>> > From: Mr Ian Primus<ian_primus at yahoo.com>
>> > And glaringly so. To say that the 11/780 is the first 32 bit machine is just silly. Prime had a 32 bit machine in 1972. And I know that there were others - but the Prime is the machine that I know the best:)
> I think I'm right saying the Manchester 'Baby' had a 32 bit word in 1948, actually 32 of them on one Williams tube. However as it was a serial machine the data path to memory was actually one bit wide so it depends how you define bit size, but I was taught it was the largest addressable unit of memory and by that definition it had a 32 bit word.
What does "largest addressable unit of memory" means? I totally fail to
understand that. Sounds like "the largest memory chip that can be
utilized", but that can hardly be the meaning.
> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
That the PDP-11 influenced the VAX there can be no doubt about.
The the PDP-11 influenced the 68K seems very probable when looking at
the architectures, but that is guessing on our part.
William Donzelli<wdonzelli at gmail.com> write:
>> > There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
> Big microcoded CISC was the dominant thinking in computer architecture
> at the time, so it is really hard to say that X influenced Y.
Well, the fact that DEC explicitly stated that the VAX would be like the
PDP-11, but extended to 32 bits seems like an obvious statement that the
PDP-11 influenced the VAX. Not to mention the fact that they used the
same peripherial buses, and at VMS V1, most of the applications were
just the RSX programs moved straight over. Oh, and don't forget the
compatibility mode in the VAX, which made it execute PDP-11 code. :-)
As for the 68K, we are making more of a guess, but it seems like a
fairly educated guess that the 68K was inspired by the PDP-11 (although
I'd say the 68K is way inferior to the PDP-11...)
Johnny
Hello everyone,
I would like to announce a new podcast series that I have started, and I feel really good about it's potential.
When you can, please consider giving a listen to the Retro Computing Roundtable -
http://web.me.com/dgreelish/Classic_Computing_Podcasts/RCR/RCR.html
I am currently working on its submission to iTunes. This show has Bill Degnan from M.A.R.C.H. & VCFe, Earl Evans from "The Retrobits Podcast" and Carrington Vanston from the "1MHz: The Apple ][ Podcast."
The next show is scheduled in three weeks!
Best,
David Greelish, Computer Historian
Classic Computing
The Home of Computer History Nostalgia
http://www.classiccomputing.com
Classic Computing Blog
Classic Computing Show video podcast
"Stan Veit's History of the Personal Computer" audiobook podcast
Retro Computing Roundtable podcast
Historical Computer Society meeting - first Wednesday of each month.
Classic Computing Expo 1.0 - planned for March 2011!
> From: "Tom Gardner" <thomas.gardner at sbcglobal.net>
>
> On Fri, 22 Oct 2010 11:03:10 +0200 (CEST) Christian Corti wrote:
>
>
>
>> Per definition, a magnetic drum is not random access.
>
>> A random access storage is defined by the fact that addressing
>
>> any arbitrary cell needs the same time.
>
>
> That may be today's definition but if you check the literature of the 50's
> and 60's I am sure u will find drums (along with Williams Tubes, etc)
> categorized as random access devices. Even the first disk drive was the IBM
> RAMAC 350 - as in Random Access Memory! I think IBM invented the term
> Direct Access Storage in the 1960s to distinguish devices whose assess time
> was short but variable; that is, in between core (random) and tape
> (sequential).
>
>
>
> So the historical definition may have been . needs essentially the same
> time.
>
In my ICT 1301 manuals it always uses the term Immediate Access Store (IAS) for the core store, in fact I don't think the word core is used except in the engineers maintenance manuals. My machine also has three drums for storing overlays and data as well as mag tape. The drums also have reserved bands (only writable with an engineers assistance) which hold Initial Orders, the machine's bootstrap, along with three half words which are directly wired into the machine which on pressing a button are forced into the three control registers which then load Initial Orders from drum.
P.S. I expect it was an oversight but please don't include the whole digest in your messages.
I have a low-level pdp-11 question...
I'm confused about writing to the PSW on cpu's which support user &
supervisor mode. My
read of the docs is that in user mode you should not be able to write
the "mode" bits of the PSW.
(or, perhaps more accurately, you should not be able to *clear* any mode
bits from user space)
I have a little diagnostic which doesn't work as I though it should
under simh and I thought I'd
ask what others think...
Basically, simh allows code running in "user mode" to write the PSW even
when (I claim) it
should not. I have not tried this on a real 11/44 or 11/34 yet, but I
can/will.
Should simh allow this? In the test blow the "clr @#PSW" is successful
when run
on simh and I think it should basically be a nop...
(which begs another question - should it be a nop? or a exception?)
A side question might be "the psw is not protected from writes, except
by using
the mmu" - is this true on all models? or just some? The 11/40 manual
implies
that it *is* protected. But 11/73 docs seem to say the opposite and
imply using the mmu.
diagnostic follows:
.TITLE test17
.ASECT
PSW=177776 ;processor status word
.=34
.word 200
.word 0007
.=200
mov #200, r5 ;we should be in kernel mode here
rti
.=500
clr @#PSW ;kernel mode
mov #500,sp ;sp=500 in kernel mode
mov #140000,@#PSW ;user mode
mov #700,sp ;sp=700 in user mode
trap 377 ;should move us to kernel mode
nop
clr @#PSW ;back to kernel mode
nop
halt
I'm writing a little program in H316 assembler, running it in simh
(3.8-1). The usual idiom for returning from a subroutine seems to be an
indirect jump through a pointer. But my indirect jump halts at the
location where the pointer is stored.
The code looks something like this:
...
>from jst subr call the subroutine
...
subr dac **
... do some stuff
jmp* subr
The jst is supposed to drop the address of from+1 into location subr,
and execution continues at subr+1.
The indirect jmp (jmp*) should be the return, getting the target address
>from location subr. There are even examples in some of the H316 docs
showing this kind of thing.
Best I can tell, the assembled code has all the correct bits set -- the
indirect bit is the high order bit in the word, and is set, opcode looks
correct, etc. The correct target address is indeed stored at subr by
the jst.
Obviously this isn't re-entrant, etc. Don't care about that at this
point.
What am I doing wrong?
Thanks,
De
On 10/25/10 00:46, Brad Parker <brad at heeltoe.com> wrote:
> I have a low-level pdp-11 question...
>
> I'm confused about writing to the PSW on cpu's which support user&
> supervisor mode. My
> read of the docs is that in user mode you should not be able to write
> the "mode" bits of the PSW.
>
> (or, perhaps more accurately, you should not be able to*clear* any mode
> bits from user space)
>
> I have a little diagnostic which doesn't work as I though it should
> under simh and I thought I'd
> ask what others think...
>
> Basically, simh allows code running in "user mode" to write the PSW even
> when (I claim) it
> should not. I have not tried this on a real 11/44 or 11/34 yet, but I
> can/will.
>
> Should simh allow this? In the test blow the "clr @#PSW" is successful
> when run
> on simh and I think it should basically be a nop...
>
> (which begs another question - should it be a nop? or a exception?)
>
> A side question might be "the psw is not protected from writes, except
> by using
> the mmu" - is this true on all models? or just some? The 11/40 manual
> implies
> that it*is* protected. But 11/73 docs seem to say the opposite and
> imply using the mmu.
>
> diagnostic follows:
>
> .TITLE test17
> .ASECT
> PSW=177776 ;processor status word
> .=34
> .word 200
> .word 0007
> .=200
> mov #200, r5 ;we should be in kernel mode here
> rti
> .=500
> clr @#PSW ;kernel mode
> mov #500,sp ;sp=500 in kernel mode
> mov #140000,@#PSW ;user mode
> mov #700,sp ;sp=700 in user mode
> trap 377 ;should move us to kernel mode
> nop
> clr @#PSW ;back to kernel mode
> nop
> halt
>
>
The PSW, when regarded as a memory location, is not protected at all.
How could it be?
The PSW is protected, when we talk about the MFPS/MTPS instructions, as
well as the RETI/RETN.
For an operating system, you normally protect the whole I/O page from
user access, since not only the PSW is in there, but all kind of stuff
that you do not want user programs to get access to.
Data in the I/O page follows the same rules as any other memory
essentially. If you have write access to it, you can write to those
locations. The underlying device responding to those writes have no idea
what the PSW is, and cannot enforce any protection. The special case of
the PSW itself is perhaps "odd" since it actually do know what the PSW
is (obviously) but it still follows the same rules as all other devices.
Johnny
> From: "Chuck Guzis" <cclist at sydex.com>
> On 23 Oct 2010 at 21:03, Roger Holmes wrote:
>
>> That is a great find. It even includes the first machine I ever wrote
>> a program for, the IBM 7094 (in Fortran IV using the Purdue University
>> Fast Fortran Translator).
>
> I don't know if I'd confess to using PUFFT :). ISTR that you could
> just about dump a deck of cards scavenged from the trash into it and
> get a program that ran.
>
> Was that before they got the CDC 6500? I know at one point they had
> a pair of 7094s working as I/O processors and PUFFT
> compilers/interpreters. And what, a 1401?
This was in England in 1969. I was at Dartford Grammar school and for a general studies course we took a bus to Erith Tech one afternoon a week where there were two keypunches and a lecturer who taught us programming in Fortran IV. We punched our cards and a courier took them to Imperial College (of Mines) which is part of the University of London. They were run through the 7094 which ran PUFFT through IBJOB. The following week we would get our cards back with a listing of the program and the results. My first program (calculating Pi) worked first time and I was hooked.
Most times the listings would have errors and we'd have to wait another week for our next try. I remember once the compiler printing out "FORMAT misspelled" and continuing the compilation but otherwise I don't think it was particularly user friendly.
I was told at the time the 7094 had two separate offline peripheral processors, one which copied cards to tape which was then switched to the 7094 as input and another which took the 7094's output tape and printed it to listing paper. I guess the operators had the job of putting the input cards and output listings together. I happened to live about a mile from the lecturer (Tony Newey) and walking to his house one foggy night, collecting the listings for all the chap from Dartford (which was a single sex school, there being a separate Dartford Grammar school for girls which my elder sister went to). Anyway I remember dividing up the thick listing into ones for all the separate pupils and handing them out the next day so we could all consider what we wanted to change for a while before going back to Erith. One of my friends had a Reliant three wheeler (which you could drive at 16) and we drove over at lunch time once or twice to amend our card decks mid week and resubmit them. Later another friend had a mini and after he overtook going over the crest of a hill I asked what would have happened if someone else was doing the same thing coming the other way. No reply. He was a great mathematician and later worked for Lloyds of London as an insurance risk assessor. He once scored 101% in a maths exam which rather made a mockery of the math's teachers marking scheme. Anyway I don't suppose he was ever so stupid again.
The 7094 was taken offline for several months so engineers could replace every single electrolytic capacitor and we were allowed to use the University's main CDC6600 which later got replaced with a 7600.
After leaving school I was turned down by Imperial College because I could not pass English Language 'O' level but was accepted by Queen Mary College and again used the 7600 but this time via the college's ICL1905E and later 1904S. Most work was done on the ICL mainframes but it did not support a couple of languages the 7600 did. We also had a CDC 1700 which was used to teach us assembly language. My Fortran experience was not directly helpful at QMC because they taught us Algol 60 in our first six months and most of the rest was maths (cheaper to teach) though I did show one of our lecturers my Fortran knowledge was better than his and earned me a summer holiday job in the college's own programming department doing things like testing the NAG (Nottingham Algorithms Group) library on the 1900s. One evening system time was due to start and I was still running things on the multi access system. As I was staff they did not throw me off but asked if I could finish earlier if they threw all the other users off and stopped the batch stream. I said I didn't know. They said it couldn't hurt and did so. WOW I never knew computers so could be so fast! I was again hooked after doing half an hours work in a minute or two, some of which time was the computer waiting for me to type something. First time I'd ever had a computer waiting for me, of course now its what computers do 99% of the time but back then it was unusual. A few years back in history, before multi access systems, it had been common but that was not my experience.
Hi! I have some S-100 PIC/RTC boards left over from an S-100 project. They
are $20 each plus $3 shipping in the US and $6 elsewhere for the PCB only.
The boards are priority interrupt controller (i8259) and a MM58167 real time
clock. There are diagnostics LEDs, configuration jumpers and switches, and
battery backup.
http://s100computers.com/My%20System%20Pages/PIC
<http://s100computers.com/My%20System%20Pages/PIC&RTC%20Board/My%20PIC%20Boa
rd.htm> &RTC%20Board/My%20PIC%20Board.htm
These boards will support CP/M-80 but primarily intended for the S-100 x86
boards (CP/M-86 and FreeDOS) slated for next year.
Please contact me if interested. Thanks and have a nice day!
Andrew Lynch
PS there are 11 types of S-100 boards completed (done or available) and
another four more in development.
Speaking of S/390s I wondered if anyone could help me to donate my to the
NMOC at Bletchley Park. The model number escapes me, but it's an early
air-cooled s/390 from around 1990-1992. NMOC don't currently have this
architecture in the collection, so are receptive to the donation. However
there's the small matter of getting it there from Hampshire. My MG isn't
up to lugging to cabinets worth of disk and IO chassis. The other issue is
that I have almost no cabling. I have the cabling for the system
controller workstation, but all of the bus and tag cabling used for this
model is missing. So for the moment, it sits in both the spare bedroom and
the garage.
Anyone clearing out the under floor of their data centers in southern
England? And anyone with a strong back and and white van?
Thanks,
Colin Eby
|------------>
| From: |
|------------>
>-------------------------------------------------------------------------------------------------------------------------------------------|
|cctalk-request at classiccmp.org |
>-------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>-------------------------------------------------------------------------------------------------------------------------------------------|
|cctalk at classiccmp.org |
>-------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>-------------------------------------------------------------------------------------------------------------------------------------------|
|24/10/2010 23:56 |
>-------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>-------------------------------------------------------------------------------------------------------------------------------------------|
|cctalk Digest, Vol 86, Issue 52 |
>-------------------------------------------------------------------------------------------------------------------------------------------|
Send cctalk mailing list submissions to
cctalk at classiccmp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.classiccmp.org/mailman/listinfo/cctalk
or, via email, send a message with subject or body 'help' to
cctalk-request at classiccmp.org
You can reach the person managing the list at
cctalk-owner at classiccmp.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cctalk digest..."
Today's Topics:
1. Re: IBM S/390 on ebay (Dave McGuire)
2. Re: IBM S/390 on ebay (Dave McGuire)
3. Re: IBM S/390 on ebay (Patrick Finnegan)
4. Re: Cataloguing in a museum setting [was Re: nonsense...]
(Tony Duell)
5. simh & hardware - pdp-11 psw in supervisor mode? (Brad Parker)
6. Re: IBM S/390 on ebay (St?phane Tsacas)
7. Re: IBM S/390 on ebay (Sridhar Ayengar)
8. Re: IBM S/390 on ebay (Dave McGuire)
9. Re: Test Diablo Model 31 drive and disk pack on a PC
(Operation Alto Restoration) (Nick Allen)
10. FS: 70's Vintage Computer Magazines (Byte, Kilobaud, Dr
Dobb's) & Sun-2, Sun 100U Docs (Nick Allen)
11. Re: the new manx is live (Torfinn Ingolfsen)
12. Re: IBM S/390 on ebay (jim s)
13. RE: Re: Oldest original proper computer (stored program etc)
(Tom Gardner)
14. Re: Apple IIa (Martin Goldberg)
----------------------------------------------------------------------
Message: 1
Date: Sun, 24 Oct 2010 13:18:49 -0400
From: Dave McGuire <mcguire at neurotica.com>
Subject: Re: IBM S/390 on ebay
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CC46A79.3090101 at neurotica.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/24/10 12:20 PM, Bob Bradlee wrote:
> It will be interesting to see if it sells ...
They always do. Have you guys really not seen recent IBM mainframes
sell on eBay before? They come up (and sell) maybe half a dozen times
per year. I personally have two sitting here, and I'm not even a
hardcore mainframer.
> It may have just become collectible and be tracked as the first of its
kind outside IBM's control to be sold as
> running hardware on eBay. One never knows what will make an
IBMcollectable :)
Certainly not the first, no.
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------
Message: 2
Date: Sun, 24 Oct 2010 13:18:53 -0400
From: Dave McGuire <mcguire at neurotica.com>
Subject: Re: IBM S/390 on ebay
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CC46A7D.2060903 at neurotica.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/24/10 12:14 PM, Eric Smith wrote:
> Presumably they haven't "gone after people" for running Linux on
> Hercules, so it seems unlikely that they would go after someone for
> running Linux on a z900. We can't presume to know what an eBay buyer
> would run on it.
You still need the LIC to run Linux, and the LIC is what's tightly
controlled. One can get operating systems pretty easily, but not LIC
images.
>> they will definitely go after someone with real hardware. Especially a
>> current machine. This is not some ancient retiree we are discussing,
>> this is a z900 that you can still buy brand new.
>
> I'll admit that I'm not very expert on such things, so I could be
> mistaken, but this looks to be an 8 year old model to me, not one that
> "you can still buy new".
The z900 was withdrawn from marketing three or four years ago, which
makes them pretty much "last years' model" in the mainframe world.
They're still supported.
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------
Message: 3
Date: Sun, 24 Oct 2010 14:25:29 -0400
From: Patrick Finnegan <pat at computer-refuge.org>
Subject: Re: IBM S/390 on ebay
To: cctalk at classiccmp.org
Message-ID: <201010241425.30204.pat at computer-refuge.org>
Content-Type: Text/Plain; charset="utf-8"
On Sunday, October 24, 2010, Daniel Seagraves wrote:
> On Oct 24, 2010, at 7:53 AM, St?phane Tsacas
<stephane.tsacas at gmail.com> wrote:
> > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=220685200658
> > <http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=220685200658>
> > http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP39
> > 0G1.html
>
> Do be advised that if you should obtain one of these, it is illegal
> for you to operate it in any way. The microcode, which IBM calls the
> LIC or Licensed Internal Code, is licensed only for the use of the
> original purchaser and only on the specific machine and
> configuration as IBM delivered it. Any other usage by any other
> party is unlicensed and illegal.
This isn't true at all. The last time I read the license agreement that
popped up booting my S/390's service element, it required you to
transfer the LIC with the machine. It certainly didn't allow you to
keep the LIC if you got rid of the machine, nor did it require you to
destroy the copy of the LIC if you transferred the machine to someone
else.
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
------------------------------
Message: 4
Date: Sun, 24 Oct 2010 19:22:50 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: Cataloguing in a museum setting [was Re: nonsense...]
To: cctalk at classiccmp.org
Message-ID: <m1PA5Df-000J3xC at p850ug1>
Content-Type: text/plain
>
> On Sat, 23 Oct 2010, Tony Duell wrote:
> > Sure, but that's then 4 levels. I ahve no problem extending the
> > heirarchical system to as many levels as are necessary, my query is why
> > it's noramlly limitied to 3. Why not just have as many levels as are
needed.
>
> A properly designed system should be extensible to as many levels as are
> needed.
That's _exactly_ my point. Having atbitrary limits may cause problems
later on.
>
> > And why recorsd the year of acquisition? What importance is that? Why
not
> > just a number for each artefact starting at 1?
>
> It is unlikely that you nor I would care much about the year of
> acquisition. But the bean-counters care.
Ah no, you misnderstood me...
Presumanbly there is a database of the artefacts in the museum, indexed
by the indentification numbers. That database includes more details about
the particular object, things like (I would hope), options, serial
number (s), version, etc. All we've been discussing. I see no reason why
the date of acquisition (full date, not just the year), source (maybe
'anonymous donor' :-)), and the like should not be stored there as well.
It's far better to store too much information than too little.
But what I am wondering is why the year of acquisition should be a field
in the indentifier.
> Not "exclusive", but a different attitude about what is/isn't important.
>
> If you end up with a common/stock item that was once owned by a
celebrity,
> you could sell it on eBay to one of those provenance collectors, and buy
> several that were not celebrity owned.
As an aside, maybe in principle, but not always in practice...
Suppose I did have an HP9820 (say) that had been used for some famous bit
of work. Yes, I could sell it for more than the normal 'going rate' for
such a machine. But could I be sure ot be able to buy another one?
There's not an infinite supply of old computers, and some people may well
not sell _at any price_. You could offer me a million pounds/dollars for
a machine in my collection and I would turn you down. And I'll bet there
are others like me.
>
>
> > > The depth of cataloging would depend on the subjective issue of just
how
> > > interesting/important that item is.
> > How can you possibly know how interesting/importantsomethign will later
> > turn out to be?
>
> It is a subjective evaluation. One more reason that proper cataloging
> requires expertise.
Agreed... I feel you should err on the side of recording too much
information. It's easy to ignroe it later ;-)
>
> I'm not sure that I would want to live in a world where DELLs became the
> most interesting/important computers for collecting.
Nor would I, and for the record I don't consider DELLs or other PC
clones to be the machines I want to collect. That doesn't mean I think
that nobody should collect them. Or that the PC clone has not had a very
significant impact on computing (not necessarily for the better :-)).
-tony
------------------------------
Message: 5
Date: Sun, 24 Oct 2010 14:33:42 -0400
From: Brad Parker <brad at heeltoe.com>
Subject: simh & hardware - pdp-11 psw in supervisor mode?
To: General at heeltoe.com, "Discussion at heeltoe.com":On-Topic and
Off-Topic Posts <cctalk at classiccmp.org>,
"simh at trailing-edge.com"
<simh at trailing-edge.com>
Message-ID: <4CC47C06.5020000 at heeltoe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I have a low-level pdp-11 question...
I'm confused about writing to the PSW on cpu's which support user &
supervisor mode. My
read of the docs is that in user mode you should not be able to write
the "mode" bits of the PSW.
(or, perhaps more accurately, you should not be able to *clear* any mode
bits from user space)
I have a little diagnostic which doesn't work as I though it should
under simh and I thought I'd
ask what others think...
Basically, simh allows code running in "user mode" to write the PSW even
when (I claim) it
should not. I have not tried this on a real 11/44 or 11/34 yet, but I
can/will.
Should simh allow this? In the test blow the "clr @#PSW" is successful
when run
on simh and I think it should basically be a nop...
(which begs another question - should it be a nop? or a exception?)
A side question might be "the psw is not protected from writes, except
by using
the mmu" - is this true on all models? or just some? The 11/40 manual
implies
that it *is* protected. But 11/73 docs seem to say the opposite and
imply using the mmu.
diagnostic follows:
.TITLE test17
.ASECT
PSW=177776 ;processor status word
.=34
.word 200
.word 0007
.=200
mov #200, r5 ;we should be in kernel mode here
rti
.=500
clr @#PSW ;kernel mode
mov #500,sp ;sp=500 in kernel mode
mov #140000,@#PSW ;user mode
mov #700,sp ;sp=700 in user mode
trap 377 ;should move us to kernel mode
nop
clr @#PSW ;back to kernel mode
nop
halt
------------------------------
Message: 6
Date: Sun, 24 Oct 2010 20:47:49 +0200
From: St?phane Tsacas <stephane.tsacas at gmail.com>
Subject: Re: IBM S/390 on ebay
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID:
<AANLkTinCtUkbC4gfnNad6jJ4g6-++65wXvvXoHQ7PYO3 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Oct 24, 2010 at 15:06, Dave McGuire <mcguire at neurotica.com> wrote:
> On 10/24/10 8:53 AM, St?phane Tsacas wrote:
>
>> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=220685200658
>> <http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=220685200658>
>>
>
> That's a (badly abused) z900, a 64-bit z/Series machine, nowhere near
> classiccmp material, but...I'm drooling all over my lap here.
>
>
See also
http://cgi.ebay.com/HP-DEC-AlphaServer-GS320-Scalable-Server-Complete-/3304…
;-)
--
Stephane
http://updatedoften.blogspot.com
------------------------------
Message: 7
Date: Sun, 24 Oct 2010 15:45:39 -0400
From: Sridhar Ayengar <ploopster at gmail.com>
Subject: Re: IBM S/390 on ebay
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CC48CE3.7050508 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
St?phane Tsacas wrote:
> See also
>
http://cgi.ebay.com/HP-DEC-AlphaServer-GS320-Scalable-Server-Complete-/3304…
> ;-)
*boioioioioioioing!!*
Peace... Sridhar
------------------------------
Message: 8
Date: Sun, 24 Oct 2010 15:49:27 -0400
From: Dave McGuire <mcguire at neurotica.com>
Subject: Re: IBM S/390 on ebay
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CC48DC7.9070705 at neurotica.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/24/10 3:45 PM, Sridhar Ayengar wrote:
> St?phane Tsacas wrote:
>> See also
>>
http://cgi.ebay.com/HP-DEC-AlphaServer-GS320-Scalable-Server-Complete-/3304…
>>
>> ;-)
>
> *boioioioioioioing!!*
Right there with you on that.
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------
Message: 9
Date: Fri, 22 Oct 2010 14:11:02 -0500
From: Nick Allen <nick.allen at comcast.net>
Subject: Re: Test Diablo Model 31 drive and disk pack on a PC
(Operation Alto Restoration)
To: cctech at classiccmp.org
Message-ID: <4CC1E1C6.9050709 at comcast.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sure, I will upload the photos shortly.
Did you have to build a custom cable/adapter from Diablo to the Parallel
port on the PC? Did you use any a custom drive, utility, os on the PC
side? Just looking to validate somehow that my Diablo Drive is fully
functioning, and this direction seems to be the best bet until I get the
Alto working.
------------------------------
Message: 10
Date: Fri, 22 Oct 2010 20:35:54 -0500
From: Nick Allen <nick.allen at comcast.net>
Subject: FS: 70's Vintage Computer Magazines (Byte, Kilobaud, Dr
Dobb's) & Sun-2, Sun 100U Docs
To: cctech at classiccmp.org
Message-ID: <4CC23BFA.3050409 at comcast.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Byte magazines pretty much the complete 1975-1977 years!
Kilobaud magazines: Year 1977
Dr Dobb's: Years 1977-79
Sun-2 technical overview documentation
Sun 100u Optical Mouse Docs
Mark 8 Minicomputer build plans from Radio Electronics magazine:
Here is the link to my seller profile (will display all current
auctions):
http://shop.ebay.com/sdinet/m.html?_dmd=1&_ipg=50&_sop=12&_rdc=1
Trying to clear room in the condo, and raise funds to repair the
Alto/IMSAIs/Altairs!
------------------------------
Message: 11
Date: Sat, 23 Oct 2010 04:09:42 +0200
From: Torfinn Ingolfsen <tingox at gmail.com>
Subject: Re: the new manx is live
To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
Message-ID:
<AANLkTimoQDE2XM84piiJ1QB9Lyi8LyM=3qCcKC-02NL8 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Oct 22, 2010 at 12:14 AM, Dan Roganti <ragooman at gmail.com> wrote:
> On Thu, Oct 21, 2010 at 5:18 PM, Richard <legalize at xmission.com> wrote:
>
> >
> > In article <AANLkTikFFFKKo=6Ba=6DjtK1hUkDUSciHp
+WO-gfLNyM at mail.gmail.com<6DjtK1hUkDUSciHp%2BWO-gfLNyM at mail.gmail.com>
>
<6DjtK1hUkDUSciHp%2BWO-gfLNyM at mail.gmail.com<6DjtK1hUkDUSciHp%252BWO-gfLNyM at mail.gmail.com>
> >
> > >,
> > Torfinn Ingolfsen <tingox at gmail.com> writes:
> >
> > > Is it working ok for everyone else?
> >
> > Noone else has reported problems; manx is hosted on the same group of
> > machines that serves this mailing list and several other classic
> > computing sites graciously hosted by Jay.
>
Seems there are some network problems somewhere between me and manx. I
can't
rerach bitsavers.org either:
tingo at kg-u35jc:~$ ping bitsavers.org
PING bitsavers.org (209.145.140.17) 56(84) bytes of data.
>From host50.datotel.com (208.75.82.50) icmp_seq=50 Packet filtered
>From host50.datotel.com (208.75.82.50) icmp_seq=53 Packet filtered
>From host50.datotel.com (208.75.82.50) icmp_seq=54 Packet filtered
>From host50.datotel.com (208.75.82.50) icmp_seq=55 Packet filtered
>From host50.datotel.com (208.75.82.50) icmp_seq=56 Packet filtered
^C
--- bitsavers.org ping statistics ---
91 packets transmitted, 0 received, +5 errors, 100% packet loss, time
90127ms
tingo at kg-u35jc:~$ traceroute bitsavers.org
traceroute to bitsavers.org (209.145.140.17), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
tingo at kg-u35jc:~$
>from my gateway / firewall:
tingo at kg-omni1$ traceroute bitsavers.org
traceroute to bitsavers.org (209.145.140.17), 64 hops max, 40 byte packets
1 kg-ruter (10.0.0.1) 46.484 ms 98.823 ms 99.785 ms
2 1.80-203-92.nextgentel.com (80.203.92.1) 14.068 ms 14.298 ms 13.788
ms
3 80-202-3-30.dd.nextgentel.com (80.202.3.30) 14.536 ms 15.015 ms
14.369 ms
4 217-13-0-70.dd.nextgentel.com (217.13.0.70) 14.258 ms 18.107 ms
14.183 ms
5 oso-b3-link.telia.net (80.239.193.93) 14.555 ms 14.674 ms 14.876 ms
6 kbn-bb2-link.telia.net (80.91.251.49) 27.834 ms 28.522 ms 27.609 ms
7 hbg-bb2-link.telia.net (80.91.252.114) 33.525 ms 33.542 ms 33.596 ms
8 213.248.65.121 (213.248.65.121) 43.259 ms 43.400 ms
ffm-bb2-link.telia.net (80.91.245.117) 42.396 ms
9 ffm-b12-link.telia.net (80.91.246.121) 40.698 ms
ffm-b12-link.telia.net (80.91.246.105) 43.963 ms
ffm-b12-link.telia.net (80.91.246.121) 40.340 ms
10 cogent-ic-140549-ffm-b12.c.telia.net (213.248.92.142) 43.399 ms
43.176
ms 42.901 ms
11 te0-1-0-7.ccr22.fra03.atlas.cogentco.com (130.117.49.162) 39.443 ms
te0-2-0-6.ccr21.dca01.atlas.cogentco.com (154.54.31.237) 134.206 ms
te0-1-0-7.ccr22.fra03.atlas.cogentco.com (130.117.49.162) 40.854 ms
12 te0-4-0-0.ccr22.dca01.atlas.cogentco.com (154.54.42.113) 133.907 ms
te0-1-0-4.ccr21.ord01.atlas.cogentco.com (154.54.40.190) 146.549 ms
146.957 ms
13 te0-0-0-0.ccr22.ord01.atlas.cogentco.com (154.54.31.154) 144.096 ms
146.334 ms 145.755 ms
14 te3-2.ccr01.stl03.atlas.cogentco.com (154.54.27.30) 148.954 ms
149.120
ms 149.191 ms
15 vl3508.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.166) 159.651
ms 159.613 ms 157.883 ms
16 38.104.146.10 (38.104.146.10) 151.954 ms 153.009 ms 177.673 ms
17 host42.datotel.com (208.82.151.42) 152.974 ms 153.659 ms 153.212 ms
18 stl-d1-g5-1.datotel.com (208.82.151.22) 152.006 ms 151.510 ms
150.509
ms
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * host50.datotel.com (208.75.82.50) 667.077 ms !X *
38 * * *
39 * * *
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
47 * * *
48 * * *
49 * * *
50 * * *
51 * * *
52 * * *
53 * * *
54 * * *
55 * * *
56 * * *
57 * * *
58 * host50.datotel.com (208.75.82.50) 152.356 ms !X *
59 * * *
60 * * *
61 * * *
62 * * *
63 * * *
64 * * *
tingo at kg-omni1$
--
Regards,
Torfinn Ingolfsen
------------------------------
Message: 12
Date: Sun, 24 Oct 2010 12:32:24 -0700
From: jim s <jws at jwsss.com>
Subject: Re: IBM S/390 on ebay
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CC489C8.3020702 at jwsss.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
The LIC for the r/390's and the pc/390's was at one time freely
downloadable.
It is the OS Licensed material that is not transferable to another
entity. The firmware is not a problem. Most of the peripherals have
LIC code and you only need to call IBM to get copies if you supply the
model number.
I have two 3174's that have "LIC" and IBM's support number supplied the
code at IBM's cost to fix me up. I have to say that I was impressed
with that. I also ordered 3290 support as well as the latest rev of the
Token Ring support on 2mb floppies.
I also believe that the firmware for the 9370's is not a problem to
transfer, just the OS. Linux is not a problem.
I will ask a friend who has two of these running what if any issues he
has, as he may have transferred a license I don't know about for one of
the smaller 390's he has. Based on his use, I would almost (but for
that detail) say there is no problem as long as you have the hardware.
On 10/24/2010 11:25 AM, Patrick Finnegan wrote:
> On Sunday, October 24, 2010, Daniel Seagraves wrote:
>> On Oct 24, 2010, at 7:53 AM, St?phane Tsacas
> <stephane.tsacas at gmail.com> wrote:
>>> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=220685200658
>>> <http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=220685200658>
>>> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP39
>>> 0G1.html
>> Do be advised that if you should obtain one of these, it is illegal
>> for you to operate it in any way. The microcode, which IBM calls the
>> LIC or Licensed Internal Code, is licensed only for the use of the
>> original purchaser and only on the specific machine and
>> configuration as IBM delivered it. Any other usage by any other
>> party is unlicensed and illegal.
> This isn't true at all. The last time I read the license agreement that
> popped up booting my S/390's service element, it required you to
> transfer the LIC with the machine. It certainly didn't allow you to
> keep the LIC if you got rid of the machine, nor did it require you to
> destroy the copy of the LIC if you transferred the machine to someone
> else.
>
> Pat
------------------------------
Message: 13
Date: Fri, 22 Oct 2010 10:10:21 -0700
From: "Tom Gardner" <thomas.gardner at sbcglobal.net>
Subject: RE: Re: Oldest original proper computer (stored program etc)
To: <cctalk at classiccmp.org>
Message-ID: <EE3A6EC5DBF7493E9E39C8CFA9759060 at tegp4>
Content-Type: text/plain; charset="us-ascii"
On Fri, 22 Oct 2010 11:03:10 +0200 (CEST) Christian Corti wrote:
>Per definition, a magnetic drum is not random access.
>A random access storage is defined by the fact that addressing
>any arbitrary cell needs the same time.
.
That may be today's definition but if you check the literature of the 50's
and 60's I am sure u will find drums (along with Williams Tubes, etc)
categorized as random access devices. Even the first disk drive was the
IBM
RAMAC 350 - as in Random Access Memory! I think IBM invented the term
Direct Access Storage in the 1960s to distinguish devices whose assess time
was short but variable; that is, in between core (random) and tape
(sequential).
So the historical definition may have been . needs essentially the same
time.
Tom
> -----Original Message-----
> From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org
]
> On Behalf Of cctalk-request at classiccmp.org
> Sent: Friday, October 22, 2010 7:14 AM
> To: cctalk at classiccmp.org
> Subject: cctalk Digest, Vol 86, Issue 46
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: 1986 NSA paper on computers (William Donzelli)
> 2. RE: the new manx is live (Rob Jarratt)
> 3. RE: Cataloguing in a museum setting [was Re: nonsense...]
> (Ian King)
> 4. Re: cctalk Digest, Vol 86, Issue 45 (MikeS)
> 5. Re: Moving House - Need to downsize (Dan Williams)
> 6. Re: cctalk Digest, Vol 86, Issue 45 (Al Kossow)
> 7. Re: the new manx is live (Dan Roganti)
> 8. Re: the new manx is live (Richard)
> 9. Re: cctalk Digest, Vol 86, Issue 45 (Chuck Guzis)
> 10. RE: Cataloguing in a museum setting [was Re: nonsense...]
> (Rich Alderson)
> 11. Re: HTL (Charles Dickman)
> 12. Re: Cataloguing in a museum setting [was Re: nonsense...]
> (Al Kossow)
> 13. Viper 2150S scsi tape drive (dwight elvey)
> 14. Re: Viper 2150S scsi tape drive (Chuck Guzis)
> 15. Re: Moving House - Need to downsize (Pontus Pihlgren)
> 16. Re: the new manx is live (Pontus Pihlgren)
> 17. Test Diablo Model 31 drive and disk pack on a PC (Operation
> Alto Restoration) (Nick Allen)
> 18. Re: Oldest original proper computer (stored program etc)
> (Charlie Carothers)
> 19. Re: Viper 2150S scsi tape drive (r.stricklin)
> 20. Re: Oldest original proper computer (stored program etc)
> (Jochen Kunz)
> 21. Re: Oldest original proper computer (stored program etc)
> (Christian Corti)
> 22. RE: Oldest original working proper computer (stored program
> etc) (Roger Holmes)
> 23. Re: lilith computer by wikipedia (Simon Fryer)
> 24. Re: Test Diablo Model 31 drive and disk pack on a PC
> (Operation Alto Restoration) (Al Kossow)
> 25. RE: Viper 2150S scsi tape drive (dwight elvey)
> 26. Re: Viper 2150S scsi tape drive (Dave McGuire)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Oct 2010 17:25:52 -0400
> From: William Donzelli <wdonzelli at gmail.com>
> Subject: Re: 1986 NSA paper on computers
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinUBCts0XvV0RaGH7RcJQab-Vqm5YjBrks8aQP3 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > Will, you've got a 1604; do you know anything about this?
>
> Not me.
>
> I probably have enough of the modules that I could build one, however.
>
> --
> Will
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Oct 2010 22:28:17 +0100
> From: "Rob Jarratt" <robert.jarratt at ntlworld.com>
> Subject: RE: the new manx is live
> To: "'General Discussion: On-Topic and Off-Topic Posts'"
> <cctalk at classiccmp.org>, "'General Discussion: On-Topic Posts
> Only'"
> <cctech at classiccmp.org>
> Message-ID: <015601cb7166$e49b58a0$add209e0$(a)ntlworld.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > -----Original Message-----
> > From: cctalk-bounces at classiccmp.org [mailto:cctalk-
> > bounces at classiccmp.org] On Behalf Of Torfinn Ingolfsen
> > Sent: 21 October 2010 08:10
> > To: General Discussion: On-Topic Posts Only
> > Subject: Re: the new manx is live
> >
> > On Wed, Oct 20, 2010 at 7:33 PM, Richard <legalize at xmission.com> wrote:
> >
> > > Manx is an online catalog of computer documentation.
> > >
> > > The new manx is up for beta testing here: <http://manx.classiccmp.org
>
> > >
> >
> > I seem to be having problems reaching the site.
> > Details:
> > root at kg-quiet# traceroute manx.classiccmp.org traceroute to
> classiccmp.org
> > (209.145.140.17), 64 hops max, 52 byte packets
> > 1 kg-omni1 (10.1.10.1) 0.228 ms 0.182 ms 0.158 ms
> > 2 kg-ruter (10.0.0.1) 77.819 ms 127.069 ms 86.825 ms
> > 3 1.80-203-92.nextgentel.com (80.203.92.1) 15.481 ms 14.011 ms
> 14.051
> ms
> > 4 80-202-3-30.dd.nextgentel.com (80.202.3.30) 17.763 ms * 59.706 ms
> > 5 217-13-0-70.dd.nextgentel.com (217.13.0.70) 18.365 ms 14.260 ms
> > 14.759 ms
> > 6 oso-b3-link.telia.net (80.239.193.93) 15.088 ms 14.948 ms 14.765
> ms
> > 7 kbn-bb2-link.telia.net (80.91.251.49) 34.331 ms 27.930 ms 28.293
> ms
> > 8 hbg-bb2-link.telia.net (80.91.252.114) 78.106 ms 34.255 ms
34.479
> ms
> > 9 ffm-bb2-link.telia.net (80.91.247.142) 67.265 ms
> > ffm-bb2-link.telia.net (80.91.245.123) 44.158 ms
> > ffm-bb2-link.telia.net (80.91.247.142) 50.006 ms
> > 10 ffm-b2-link.telia.net (80.91.249.103) 42.490 ms
> > ffm-b2-link.telia.net (80.91.252.174) 41.347 ms
> > ffm-b2-link.telia.net (80.91.249.103) 42.628 ms
> > 11 cogent-ic-135155-ffm-b2.c.telia.net (213.248.93.174) 51.872 ms
> 42.313 ms
> > 40.571 ms
> > 12 te0-2-0-6.ccr22.fra03.atlas.cogentco.com (154.54.36.81) 42.860 ms
> > te0-2-0-6.mpd21.dca01.atlas.cogentco.com (154.54.31.245) 132.058
ms
> > te0-4-0-0.mpd21.dca01.atlas.cogentco.com (154.54.26.101) 147.305
ms
> > 13 te0-4-0-0.ccr22.dca01.atlas.cogentco.com (154.54.42.113) 140.836
ms
> > te0-2-0-4.mpd21.ord01.atlas.cogentco.com (154.54.40.226) 152.265
ms
> > te0-2-0-6.ccr22.dca01.atlas.cogentco.com (154.54.31.241) 135.140
ms
> > 14 te0-1-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.206) 143.202
ms
> > te0-2-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.210) 157.894
ms
> > 147.097 ms
> > 15 te3-2.ccr01.stl03.atlas.cogentco.com (154.54.27.30) 150.725 ms
> 150.014
> > ms 150.329 ms
> > 16 vl3808.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.170)
> 167.084
> > ms 156.374 ms
> > vl3508.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.166)
> 158.136
> ms
> > 17 38.104.146.10 (38.104.146.10) 155.110 ms 155.902 ms 152.225 ms
> > 18 host42.datotel.com (208.82.151.42) 161.893 ms 179.548 ms 167.528
> ms
> > 19 stl-d1-g5-1.datotel.com (208.82.151.22) 157.149 ms 151.804 ms
> 151.915
> > ms
> > 20 * * *
> > 21 * * *
> > 22 * * *
> > 23 * * *
> > 24 * * *
> > 25 * * *
> > 26 * * *
> > 27 * * *
> > 28 * * *
> > 29 * * *
> > 30 * * *
> > 31 * host50.datotel.com (208.75.82.50) 156.517 ms !X *
> > 32 * * *
> > 33 * * *
> > 34 * * *
> > 35 * * *
> > 36 * * *
> > 37 * * *
> > 38 * * *
> > 39 * * *
> > 40 * * *
> > 41 * * *
> > 42 * * *
> > 43 * * *
> > 44 * * *
> > 45 * * *
> > 46 * * *
> > 47 * * *
> > 48 * * *
> > 49 * * *
> > 50 * * *
> > 51 * * *
> > 52 * * *
> > 53 * * *
> > 54 * * *
> > 55 * * *
> > 56 * * *
> > 57 * * *
> > 58 * * *
> > 59 * * *
> > 60 * * *
> > 61 * * *
> > 62 * * *
> > 63 * * *
> > 64 * * *
> > root at kg-quiet#
> >
> > Is it working ok for everyone else?
> > --
> > Regards,
> > Torfinn Ingolfsen
> > Oslo, Norway
>
> Works OK for me, here is my tracert:
>
> 1 8 ms 3 ms <1 ms JUPITER [192.168.0.1]
> 2 42 ms 22 ms 26 ms 10.236.80.1
> 3 29 ms 66 ms 9 ms oldh-cam-1a-v100.network.virginmedia.net
> [80.5.1
> 65.13]
> 4 11 ms 24 ms 12 ms
manc-core-1a-ae2-0.network.virginmedia.net
> [195.
> 182.180.37]
> 5 25 ms 23 ms 18 ms manc-bb-1a-as0-0.network.virginmedia.net
> [213.10
> 5.175.1]
> 6 22 ms 31 ms 49 ms manc-bb-1b-ae0-0.network.virginmedia.net
> [62.253
> .187.178]
> 7 34 ms 45 ms 35 ms nrth-bb-1a-as3-0.network.virginmedia.net
> [213.10
> 5.64.21]
> 8 30 ms 29 ms 15 ms nrth-tmr-1-ae1-0.network.virginmedia.net
> [213.10
> 5.159.30]
> 9 64 ms 54 ms 43 ms fran-ic-1-as0-0.network.virginmedia.net
> [62.253.
> 185.81]
> 10 76 ms 51 ms 54 ms te0-7-0-7.mpd22.fra03.atlas.cogentco.com
> [130.11
> 7.14.133]
> 11 144 ms 138 ms 120 ms te0-2-0-6.mpd22.dca01.atlas.cogentco.com
> [130.11
> 7.51.230]
> 12 138 ms 186 ms 155 ms te0-0-0-4.mpd22.ord01.atlas.cogentco.com
> [154.54
> .40.234]
> 13 137 ms 145 ms 155 ms te0-1-0-0.ccr22.ord01.atlas.cogentco.com
> [154.54
> .6.178]
> 14 184 ms 142 ms 141 ms te3-2.ccr01.stl03.atlas.cogentco.com
> [154.54.27.
> 30]
> 15 173 ms 146 ms 158 ms
> vl3808.na41.b003211-0.stl03.atlas.cogentco.com [
> 38.20.47.170]
> 16 165 ms 165 ms 180 ms 38.104.146.10
> 17 163 ms 151 ms 146 ms host42.datotel.com [208.82.151.42]
> 18 147 ms 151 ms 161 ms stl-d1-g5-1.datotel.com [208.82.151.22]
> 19 151 ms 140 ms 155 ms host50.datotel.com [208.75.82.50]
> 20 146 ms 163 ms 158 ms 209-145-130-66.accessus.net
> [209.145.130.66]
> 21 147 ms 160 ms 163 ms louie.classiccmp.org [209.145.140.17]
>
> Regards
>
> Rob
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Oct 2010 14:30:07 -0700
> From: Ian King <IanK at vulcan.com>
> Subject: RE: Cataloguing in a museum setting [was Re: nonsense...]
> To: "'General Discussion: On-Topic and Off-Topic Posts'"
> <cctalk at classiccmp.org>
> Message-ID: <FF6AB92D97A23A409701CDBF66F03FCD03DC3E70BE at 505fuji>
> Content-Type: text/plain; charset="us-ascii"
>
> > -----Original Message-----
> > From: cctalk-bounces at classiccmp.org [mailto:cctalk-
> > bounces at classiccmp.org] On Behalf Of Tony Duell
> > Sent: Thursday, October 21, 2010 12:18 PM
> > To: cctalk at classiccmp.org
> > Subject: Re: Cataloguing in a museum setting [was Re: nonsense...]
> >
> > > > I'd like to hear more about what constitutes "cataloging", as I'm a
> > > > n00b in this respect.
> > >
> > > Just what it sounds like. :-)
> > >
> > > When an item comes into the collection, it is assigned an accession
> > > number; the standard is yyyy.nnn.mmm, where nnn represents order in
> > > which the item came in in year yyyy, and mmm is the individual number
> > > of each piece that makes up the item. If a piece is made up of
> > > parts (say a tea set, for example) a letter can be suffixed to the
> > > piece number for each part to make it possible to keep them
> > associated
> > > even if physically apart. Leading zeroes should be used in the item
> > > and piece numbers.
> >
> > What do you mean by 'item','piece' and 'part' here? I can understand an
> > item being made of several pieces, but why do you need a third level
> > here?
> >
> > In the case of a classic computer, what would you label? The casing?
> > The
> > individual PCBs/modules? How would you handle the case of taking 2
> > effectively identical machines acquired at differnet times and using
> > parts from bvth to make one working example, or would a museum never do
> > that? (If the latter, then I consider the policy to be broken!).
> >
>
> Yes. :-)
>
> Seriously: we do encounter this situation. When a machine comes in, it
is
> catalogued as an entity. If we find it necessary to remove a component
> from machine A to install in machine B, the component is separately
> catalogued with a note in the record stating that it was originally part
> of machine A.
>
> I did this recently with a machine that came as a system containing an
> RK05 drive identified as non-functional. We used the RK8-E from that
> machine with another PDP-8/e that also had RK05 drives but no RK8-E.
>
> That would not be appropriate for a machine that is historically
> significant in its particular configuration (for example, our PDP-12),
but
> that's a hard argument to make for the vast majority of PDP-8/e's. And
> given the records we keep, we could restore the accession to its original
> configuration if needed.
>
> It's always a judgement call when one must balance preservation and
> restoration. -- Ian
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 Oct 2010 17:52:03 -0400
> From: "MikeS" <dm561 at torfree.net>
> Subject: Re: cctalk Digest, Vol 86, Issue 45
> To: <cctalk at classiccmp.org>
> Message-ID: <C254F6585ED7493FB620AF800A7CA4F5 at vl420mt>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> Date: Thu, 21 Oct 2010 11:03:54 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: cctalk at classiccmp.org
> Message-ID: <4CC0808A.8010108 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 10:03 AM, Chuck Guzis wrote:
> >> For example, the GI GIMINI (CP1600)
>
> > That would be fun to find. There was a version that I used in the late
> > 70's that had a DSD floppy disk interfaced to it. I think I still have
> > all of the software for it.
> ----
> And I've got some brochures and datasheets for the GIC8000 and GIMINI and
> the various cards and chips in them, so all we need is the computer ;-)
>
> mike
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 21 Oct 2010 22:53:10 +0100
> From: Dan Williams <williams.dan at gmail.com>
> Subject: Re: Moving House - Need to downsize
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinSeMiB8LqMnhemRO9Gkq56Ov5wGO6oZfeYtG0P at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 21 October 2010 20:12, Pontus Pihlgren <pontus at update.uu.se> wrote:
> > On Thu, Oct 21, 2010 at 07:12:03PM +0100, Dan Williams wrote:
> >> I'm sure these will be popular: ?I have 8x big heavy drive DSSI drive
> >> units. They have not been powered up for a few years. They have
> >> scsi-->dssi convertor cards in them. They currently have 1GB and 2GB
> >> full height drive units in them. But they can take up to 9GB.
> >> I also have cabling which I have to sort out mainly for SUN and DEC. I
> >> have all the cabling for the dssi drives and a lot of monitor and
> >> other cables for Vaxstation 3100's.
> >
> > I'm curious about that SCSI->DSSI converter. Is it used to run dssi
> > disks on a scsi controller or scsi disks on a dssi controller ?
> >
> > The latter would be interesting.
> >
> > Regards,
> > Pontus.
> >
>
> It takes scsi disks on a dssi controller. It has a front panel and you
> can connect to the controller like a normal dssi disk. It is a
> liberator 220. I have the user manual for it if anyone is interested.
>
> Dan
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 21 Oct 2010 15:08:48 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: cctalk Digest, Vol 86, Issue 45
> To: cctalk at classiccmp.org
> Message-ID: <4CC0B9F0.5000705 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 2:52 PM, MikeS wrote:
> > Date: Thu, 21 Oct 2010 11:03:54 -0700
> > From: Al Kossow <aek at bitsavers.org>
> > Subject: Re: Oldest original proper computer (stored program etc)
> > To: cctalk at classiccmp.org
> > Message-ID: <4CC0808A.8010108 at bitsavers.org>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > On 10/21/10 10:03 AM, Chuck Guzis wrote:
> >>> For example, the GI GIMINI (CP1600)
> >
> >> That would be fun to find. There was a version that I used in the late
> >> 70's that had a DSD floppy disk interfaced to it. I think I still have
> >> all of the software for it.
> > ----
> > And I've got some brochures and datasheets for the GIC8000 and GIMINI
> and the various cards and chips in them, so all we need is the
computer ;-
> )
> >
>
> I uploaded the GIMINI manuals under generalInstruments on bitsavers a
> couple of weeks ago.
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 21 Oct 2010 18:14:26 -0400
> From: Dan Roganti <ragooman at gmail.com>
> Subject: Re: the new manx is live
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinTe5iYUGDnrsygRs+4XuFwxrGweoN+rEDL6fMg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Oct 21, 2010 at 5:18 PM, Richard <legalize at xmission.com> wrote:
>
> >
> > In article <AANLkTikFFFKKo=6Ba=6DjtK1hUkDUSciHp+WO-
> gfLNyM at mail.gmail.com<6DjtK1hUkDUSciHp%2BWO-gfLNyM at mail.gmail.com>
> > >,
> > Torfinn Ingolfsen <tingox at gmail.com> writes:
> >
> > > Is it working ok for everyone else?
> >
> > Noone else has reported problems; manx is hosted on the same group of
> > machines that serves this mailing list and several other classic
> > computing sites graciously hosted by Jay.
> >
> >
>
> very nice !
>
> Can we always request to add addt'l companies ?
> SEL is on Bitsavers already but not listed on yours.
>
>
> =Dan
> --http://www.vintagecomputer.net/ragooman/
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 21 Oct 2010 16:51:54 -0600
> From: Richard <legalize at xmission.com>
> Subject: Re: the new manx is live
> To: cctalk <cctalk at classiccmp.org>
> Message-ID: <E1P93zG-0005Jz-CS at shell.xmission.com>
>
>
> In article <AANLkTinTe5iYUGDnrsygRs+4XuFwxrGweoN
+rEDL6fMg at mail.gmail.com>,
> Dan Roganti <ragooman at gmail.com> writes:
>
> > Can we always request to add addt'l companies ?
> > SEL is on Bitsavers already but not listed on yours.
>
> This first round was just to reproduce the existing manx.
>
> Next up is to add users and roles to provide for community additions.
>
> Contributions of code are welcome. The whole code base has been
> developed test-driven and is covered by unit tests.
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for
download
> <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
>
> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 21 Oct 2010 16:04:02 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: cctalk Digest, Vol 86, Issue 45
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CC06472.12811.1626E31 at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 21 Oct 2010 at 15:08, Al Kossow wrote:
>
> > I uploaded the GIMINI manuals under generalInstruments on bitsavers a
> > couple of weeks ago.
>
> Well, I've got the CP1600 CPU sitting unused in my hellbox and the
> blue manual that gives the schematics for the system. But no
> firmware listing for the monitor...
>
> BTW, did anyone notice that there's a fellow on eBay offering the
> INS8900 (PACE in NMOS) NOS CPUs for about $16 the each?
>
> --Chuck
>
>
>
> ------------------------------
>
> Message: 10
> Date: Thu, 21 Oct 2010 16:04:06 -0700
> From: Rich Alderson <RichA at vulcan.com>
> Subject: RE: Cataloguing in a museum setting [was Re: nonsense...]
> To: "'General Discussion: On-Topic and Off-Topic Posts'"
> <cctalk at classiccmp.org>
> Message-ID:
> <CC28F43ED4708D489ABCF68D06D7F556040A5CCB91 at 505DENALI.corp.vnw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> From: Tony Duell
> Sent: Thursday, October 21, 2010 12:18 PM
>
> >> When an item comes into the collection, it is assigned an accession
> >> number; the standard is yyyy.nnn.mmm, where nnn represents order in
> >> which the item came in in year yyyy, and mmm is the individual number
> >> of each piece that makes up the item. If a piece is made up of
> >> parts (say a tea set, for example) a letter can be suffixed to the
> >> piece number for each part to make it possible to keep them associated
> >> even if physically apart. Leading zeroes should be used in the item
> >> and piece numbers.
>
> > What do you mean by 'item','piece' and 'part' here? I can understand an
> > item being made of several pieces, but why do you need a third level
> here?
>
> I was trying not to re-use the same word for different levels.
>
> You donate items to a museum, let's say for simplicity's sake a horse
shoe
> and a tea service with 4 individually decorated cups and matching
saucers,
> pot, sugar and creamer.
>
> You do this in 2010. That's the first field of the accession numbers.
>
> The two items are the 75th and 76th donated to the museum this year.
> These numbers will be the second fields of the respective accession
> numbers.
>
> The horse shoe will receive accession number 2010.075.001, and be marked
> as 2010.75.1
>
> The tea pot will be 2010.076.001; the sugar, 2010.076.002; the creamer,
> 2010.076.003; the first cup-and-saucer pair, 2010.076.004A and
> 2010.076.004B;
> and so on. The reason for pairing the cup and saucer will be the
matching
> decoration on each pair.
>
> You could also simply number each piece individually, but then you lose
> information.
>
> > In the case of a classic computer, what would you label? The casing?
The
> > individual PCBs/modules? How would you handle the case of taking 2
> > effectively identical machines acquired at differnet times and using
> > parts from bvth to make one working example, or would a museum never do
> > that? (If the latter, then I consider the policy to be broken!).
>
> I'll start with the last comment. The policy will depend on the purpose
> of the museum; no two museums have identical missions, though they may be
> very close. A computer museum with a mission of making systems run will
> have a very different answer to your question than a museum dealing with
> the history of engineering laboratories, where the identical computers
> may have been used for very different purposes and be important to the
> understanding of how each lab achieved its goals. (Not every museum
tries
> to please everyone in the know about a topic--there are art museums which
> I find deadly dull, and art museums I love to visit over and over, for
> example.) Neither policy is "broken", they simply differ.
>
> Computers are more difficult to catalog than tea services. My personal
> preference would be to replicate the manufacturer's bill of materials,
> assigning accession numbers at each level down to the circuit boards (or
> equivalent, in the case of large valve-based modules, but those don't
> crop up in the time frame in which we have specialized). Since the
> catalog here was set up by someone else several years before I joined
> the team, I have to accommodate myself to what is in place--we're not in
> a position to re-catalog several thousand pieces my way.
>
> We catalog the top-level items (CPU, disk drives, tape drives, printers,
> etc.) when they come in. The low-level items (disk packs and cartridges,
> tapes, boards, etc.) are fuzzier: Loose items, like spare boards, are
> catalogued when they come in, but boards installed in larger items only
> get catalogued when they are pulled for repair or replacement.
>
> It takes discipline to catalog pieces when you would really rather be
> restoring a system to working condition, but without a catalog, you will
> very quickly lose all semblance of provenance, and your reason for being
> a museum.
>
>
> Rich Alderson
> Vintage Computing Sr. Server Engineer
> Vulcan, Inc.
> 505 5th Avenue S, Suite 900
> Seattle, WA 98104
>
> mailto:RichA at vulcan.com
> mailto:RichA at LivingComputerMuseum.org
>
> http://www.PDPplanet.org/
> http://www.LivingComputerMuseum.org/
>
>
> ------------------------------
>
> Message: 11
> Date: Thu, 21 Oct 2010 21:09:31 -0400
> From: Charles Dickman <chd at chdickman.com>
> Subject: Re: HTL
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTimgJ80NcGDTXXwhRHZFDfbzy_reGtCe65juy5Ax at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Oct 20, 2010 at 11:27 PM, William Donzelli
> <wdonzelli at gmail.com>wrote:
>
> > Maybe a retarded question, but how static sensitive are HTL chips?
> >
> > Why do you ask?
>
> I have quite a few HTL chips that I have no use for.
>
> -chuck
>
>
> ------------------------------
>
> Message: 12
> Date: Thu, 21 Oct 2010 18:23:11 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Cataloguing in a museum setting [was Re: nonsense...]
> To: cctalk at classiccmp.org
> Message-ID: <4CC0E77F.3000005 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 4:04 PM, Rich Alderson wrote:
> > The low-level items (disk packs and cartridges,
> > tapes, boards, etc.) are fuzzier
>
> But necessary.
>
> We're discovering that systems were accepted in Boston with no boards in
> them,
> for example, and there is nothing in the accession record that mentions
> that
> fact.
>
> It's absolutely necessary to know if anything that should be in an
> accessioned
> artifact is missing, and the condition.
>
> It is a huge amount of work to catalog a collection.
>
> One of the requirements for museum accreditation is having a significant
> portion of your collection cataloged.
>
> CHM has come a LONG way since I've been here. We have just under 75,000
> items
> visible in the on-line data base
>
> http://www.computerhistory.org/collections/search/
>
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Thu, 21 Oct 2010 21:37:58 -0700
> From: dwight elvey <dkelvey at hotmail.com>
> Subject: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <SNT129-W286E3F0A65E7EDCFA0F5C3A35E0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> Hi
> I just got this use drive and I was wondering if it
> is working as expected.
> When I plug in the tape, the head moves up and down
> but the tape drive motor doesn't move.
> Is this normal?
> Dwight
>
>
> ------------------------------
>
> Message: 14
> Date: Thu, 21 Oct 2010 21:50:44 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CC0B5B4.16151.2A10F67 at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 21 Oct 2010 at 21:37, dwight elvey wrote:
>
> > I just got this use drive and I was wondering if it
> > is working as expected.
> > When I plug in the tape, the head moves up and down
> > but the tape drive motor doesn't move.
> > Is this normal?
>
> My recollection of this drive is that the tape should be
> automatically positioned to BOT when inserted. (i.e., the drive
> should spin the tape a bit).
>
> --Chuck
>
>
>
>
> ------------------------------
>
> Message: 15
> Date: Fri, 22 Oct 2010 07:13:36 +0200
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> Subject: Re: Moving House - Need to downsize
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <20101022051336.GA15674 at Update.UU.SE>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Oct 21, 2010 at 10:53:10PM +0100, Dan Williams wrote:
> >
> > It takes scsi disks on a dssi controller. It has a front panel and you
> > can connect to the controller like a normal dssi disk. It is a
> > liberator 220. I have the user manual for it if anyone is interested.
>
> It would be a lovely thing to have. I live in sweden and unless you find
> someone local and wouldn't mind shipping I wouldn't mind paying for it.
> Well, it depends on the size of course, how big is this thing?
>
> /P
>
>
> ------------------------------
>
> Message: 16
> Date: Fri, 22 Oct 2010 07:16:37 +0200
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> Subject: Re: the new manx is live
> Cc: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
> Message-ID: <20101022051637.GB15674 at Update.UU.SE>
> Content-Type: text/plain; charset=us-ascii
>
> This is a semiuseful tool:
>
> http://downforeveryoneorjustme.com/http://manx.classiccmp.org/
>
> Good work everyone! Manx is an awesome tool! Many thanks.
>
> /Pontus
>
>
> On Thu, Oct 21, 2010 at 09:10:28AM +0200, Torfinn Ingolfsen wrote:
> > On Wed, Oct 20, 2010 at 7:33 PM, Richard <legalize at xmission.com> wrote:
> >
> > > Manx is an online catalog of computer documentation.
> > >
> > > The new manx is up for beta testing here: <http://manx.classiccmp.org
>
> > >
> >
> > I seem to be having problems reaching the site.
> > Details:
> > root at kg-quiet# traceroute manx.classiccmp.org
> > traceroute to classiccmp.org (209.145.140.17), 64 hops max, 52 byte
> packets
> > 1 kg-omni1 (10.1.10.1) 0.228 ms 0.182 ms 0.158 ms
> > 2 kg-ruter (10.0.0.1) 77.819 ms 127.069 ms 86.825 ms
> > 3 1.80-203-92.nextgentel.com (80.203.92.1) 15.481 ms 14.011 ms
> 14.051
> > ms
> > 4 80-202-3-30.dd.nextgentel.com (80.202.3.30) 17.763 ms * 59.706 ms
> > 5 217-13-0-70.dd.nextgentel.com (217.13.0.70) 18.365 ms 14.260 ms
> > 14.759 ms
> > 6 oso-b3-link.telia.net (80.239.193.93) 15.088 ms 14.948 ms 14.765
> ms
> > 7 kbn-bb2-link.telia.net (80.91.251.49) 34.331 ms 27.930 ms 28.293
> ms
> > 8 hbg-bb2-link.telia.net (80.91.252.114) 78.106 ms 34.255 ms
34.479
> ms
> > 9 ffm-bb2-link.telia.net (80.91.247.142) 67.265 ms
> > ffm-bb2-link.telia.net (80.91.245.123) 44.158 ms
> > ffm-bb2-link.telia.net (80.91.247.142) 50.006 ms
> > 10 ffm-b2-link.telia.net (80.91.249.103) 42.490 ms
> > ffm-b2-link.telia.net (80.91.252.174) 41.347 ms
> > ffm-b2-link.telia.net (80.91.249.103) 42.628 ms
> > 11 cogent-ic-135155-ffm-b2.c.telia.net (213.248.93.174) 51.872 ms
> 42.313
> > ms 40.571 ms
> > 12 te0-2-0-6.ccr22.fra03.atlas.cogentco.com (154.54.36.81) 42.860 ms
> > te0-2-0-6.mpd21.dca01.atlas.cogentco.com (154.54.31.245) 132.058
ms
> > te0-4-0-0.mpd21.dca01.atlas.cogentco.com (154.54.26.101) 147.305
ms
> > 13 te0-4-0-0.ccr22.dca01.atlas.cogentco.com (154.54.42.113) 140.836
ms
> > te0-2-0-4.mpd21.ord01.atlas.cogentco.com (154.54.40.226) 152.265
ms
> > te0-2-0-6.ccr22.dca01.atlas.cogentco.com (154.54.31.241) 135.140
ms
> > 14 te0-1-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.206) 143.202
ms
> > te0-2-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.210) 157.894
ms
> > 147.097 ms
> > 15 te3-2.ccr01.stl03.atlas.cogentco.com (154.54.27.30) 150.725 ms
> 150.014
> > ms 150.329 ms
> > 16 vl3808.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.170)
> 167.084
> > ms 156.374 ms
> > vl3508.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.166)
> 158.136
> > ms
> > 17 38.104.146.10 (38.104.146.10) 155.110 ms 155.902 ms 152.225 ms
> > 18 host42.datotel.com (208.82.151.42) 161.893 ms 179.548 ms 167.528
> ms
> > 19 stl-d1-g5-1.datotel.com (208.82.151.22) 157.149 ms 151.804 ms
> 151.915
> > ms
> > 20 * * *
> > 21 * * *
> > 22 * * *
> > 23 * * *
> > 24 * * *
> > 25 * * *
> > 26 * * *
> > 27 * * *
> > 28 * * *
> > 29 * * *
> > 30 * * *
> > 31 * host50.datotel.com (208.75.82.50) 156.517 ms !X *
> > 32 * * *
> > 33 * * *
> > 34 * * *
> > 35 * * *
> > 36 * * *
> > 37 * * *
> > 38 * * *
> > 39 * * *
> > 40 * * *
> > 41 * * *
> > 42 * * *
> > 43 * * *
> > 44 * * *
> > 45 * * *
> > 46 * * *
> > 47 * * *
> > 48 * * *
> > 49 * * *
> > 50 * * *
> > 51 * * *
> > 52 * * *
> > 53 * * *
> > 54 * * *
> > 55 * * *
> > 56 * * *
> > 57 * * *
> > 58 * * *
> > 59 * * *
> > 60 * * *
> > 61 * * *
> > 62 * * *
> > 63 * * *
> > 64 * * *
> > root at kg-quiet#
> >
> > Is it working ok for everyone else?
> > --
> > Regards,
> > Torfinn Ingolfsen
> > Oslo, Norway
>
>
> ------------------------------
>
> Message: 17
> Date: Thu, 21 Oct 2010 19:57:55 -0500
> From: Nick Allen <nick.allen at comcast.net>
> Subject: Test Diablo Model 31 drive and disk pack on a PC (Operation
> Alto Restoration)
> To: cctech at classiccmp.org
> Message-ID: <4CC0E193.9070101 at comcast.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Al and everyone else,
>
> I believe Al has had success interfacing a Diablo Model 31 with a
> PC computer (I assume so, since he uploaded the Alto diskpacks up to
> bitsavers.org). Al, Can you (or anyone else) please provide the steps
> on how to do so?
>
> If I can verify the disk drive is working, and the disk packs have valid
> data on them, this would be yet another step completed in getting the
> alto up and running =)
>
> Thanks!
>
>
>
> ------------------------------
>
> Message: 18
> Date: Thu, 21 Oct 2010 22:26:49 -0500
> From: Charlie Carothers <csquared3 at tx.rr.com>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org>
> Message-ID: <4CC10479.2020902 at tx.rr.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/18/2010 6:58 AM, Roger Holmes wrote:
> >> From: Christian Corti<cc at informatik.uni-stuttgart.de>
> >>
> >> On Sat, 16 Oct 2010, Roger Holmes wrote:
> >>> don't believe its true, I was told my machine is currently the oldest
> >>> original working computer. Not counting replicas or machines which
> don't
> >>> have stored programs. My machine was installed in 1962 (and designed
> in
> >>> the late 1950s).
> >>
> >> Then you've been told wrong.
> >> Several examples:
> >> - Our LGP-30 ser.no. 4, built 1958, still working with peripherals.
> Just
> >> yesterday I've had a group of visitors. It's been designed around
> 1954.
> >> - The IBM 650 of the IBM Museum in Sindelfingen (working)
> >> - The Zuse Z22 ser.no. 13 in Karlsruhe, also built around 1958
> (apparently
> >> still working, although the ZKM is not the right place for it IMHO)
> >> All are original first generation machines, and all of them are in
> >> southern Germany.
> >>
> >>> restored was first installed in 1964. Are there other? I'm not
> counting
> >>> the Zuse in Germany as its not a stored program machine, and anyway
> I'm
> >>> not sure if it is a replica or the original. It is surprising if it
> >>> survived the extensive bombing by the USAF and RAF during WW2 unless
> it
> >>> was stored in a bunker/cave/mine.
> >>
> >> What Zuse are you talking about? The Z3 has been destroyed, yes, and
> >> rebuilt by Zuse in 1962.
> >
> > Thank you, this is just the information I wanted.
> >
> > Is the Z3 stored program? Turing complete?
> >
> > If it is, then it would be useful to know when the rebuilt version
> became operational, though I'm not actually sure the actual month my
> machine went live either.
> >
> > Assuming for now that Z3 is not stored program, than my list so far is:
> >
> > 1958, LGP-30
> > 1958, Zuse Z22
> > Somewhere between 1954 and 1962, IBM 650
> > 1962 ICT 1301 serial no 6 (SO FAR the earliest surviving machine with
> random access program and data storage. i.e. Core and called Immediate
> Access Store by ICT).
> >
> > Thanks again.
> >
> > I expect the chaps in the states will tell me of several more when I
> catch up with my e-mails.
> >
> >
> >
> According to this:
> http://www-03.ibm.com/ibm/history/exhibits/650/650_ch1.html the first
> 650 was installed at a customer site in December, 1954.
>
> I thought this was pretty interesting as well:
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FT1.html
> It indicates the 701 was around in 1952. I'm not sure if you want to
> limit your list to core memory or not. It appears that the 701's
> internal memory consisted of a drum and a CRT. In any case, I need to
> waste a lot more time exploring these pages. :-)
> Later,
> Charlie C.
>
>
>
>
> ------------------------------
>
> Message: 19
> Date: Thu, 21 Oct 2010 23:23:44 -0700
> From: "r.stricklin" <bear at typewritten.org>
> Subject: Re: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
> Message-ID: <D428CDED-9195-48F5-B183-3CE5930788D1 at typewritten.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>
> On Oct 21, 2010, at 9:37 PM, dwight elvey wrote:
>
> > When I plug in the tape, the head moves up and down
> > but the tape drive motor doesn't move.
> > Is this normal?
>
> It could be, depending on firmware.
>
> ok
> bear
>
>
>
> ------------------------------
>
> Message: 20
> Date: Fri, 22 Oct 2010 08:53:46 +0200
> From: Jochen Kunz <jkunz at unixag-kl.fh-kl.de>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: cctalk at classiccmp.org
> Message-ID: <20101022085346.5c1f9ec0.jkunz at unixag-kl.fh-kl.de>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 18 Oct 2010 12:58:00 +0100
> Roger Holmes <roger.holmes at microspot.co.uk> wrote:
>
> > 1962 ICT 1301 serial no 6 (SO FAR the earliest surviving machine
> > with random access program and data storage.
> Well. The drum of the Z22 is random access program and data storage,
> just with a bit lattency...
>
> I don't know how and when the Z22 at the ZKM is operated now. When it
> moved to the ZKM there where weekly operating hours with demonstrations
> done by the former maintainers of the machine.
> --
>
>
> \end{Jochen}
>
> \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
>
>
>
> ------------------------------
>
> Message: 21
> Date: Fri, 22 Oct 2010 11:03:10 +0200 (CEST)
> From: Christian Corti <cc at informatik.uni-stuttgart.de>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <alpine.DEB.2.00.1010221057001.21272 at linuxserv.home>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Fri, 22 Oct 2010, Jochen Kunz wrote:
> > Well. The drum of the Z22 is random access program and data storage,
> > just with a bit lattency...
>
> Per definition, a magnetic drum is not random access. A random access
> storage is defined by the fact that addressing any arbitrary cell needs
> the same time.
> But the Z22 has a small amount of core memory, too, called
> "Schnellspeicher", i.e. "fast memory".
>
> Christian
>
>
> ------------------------------
>
> Message: 22
> Date: Fri, 22 Oct 2010 10:11:53 +0100
> From: Roger Holmes <roger.holmes at microspot.co.uk>
> Subject: RE: Oldest original working proper computer (stored program
> etc)
> To: cctalk at classiccmp.org
> Message-ID: <C1C3379B-1DCB-412A-B3C3-43252EF6DC0E at microspot.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> > From: "Rod Smallwood" <rodsmallwood at btconnect.com>
> >
> >
> > And we have a winner!!
> >
> >
> > The Manchester computer of 1948 (Built 1946-1948)
> > It could store 1024 bits on a cathode-ray-tube, enough to demonstrate
> the
> > stored-program principle in working electronics, the first in the world
> to
> > do so
> >
> > Built under the direction of Alan Turing and A von Neumann
> > ?
>
>
> No, sorry the ORIGINAL Manchester Baby no longer exists. Fellow members
of
> the Computer Conservation Society have built a replica, correct in almost
> every respect but it is only a few years old so does not qualify as
oldest
> original working stored program computer. I still would like to make a
> list of the top ten not just the top one.
>
>
>
> ------------------------------
>
> Message: 23
> Date: Fri, 22 Oct 2010 21:11:20 +1100
> From: Simon Fryer <fryers at gmail.com>
> Subject: Re: lilith computer by wikipedia
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinYKzyw+HKKc3FS9EAFdkrLis0n1NX-KnAO=rcx at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 22/10/2010, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
> >> Yes, and made the mistake of buying one. Couldn't believe it when it
> >> actually arrived. I left an interesting review on Amazon.
> >
> > Do you happen to remember the title (or have a URL) for this? I wonder
> > how the authors of that/those wikipedia articles feel about this? I
know
> > I'd be pretty annoyed if somedy did that with something I'd written.
>
> ISBN 10: 1155452186
> ISBN 13: 978-1155452180
> Title: ICL Mainframe Computers: Leo, English Electric Kdf8, Elliott
> 803, Ict 1900, ICL 2900 Series, English Electric Kdf9, Ict 1301
> By: Books LLC
>
> http://www.amazon.co.uk/ICL-Mainframe-Computers-English-
> Electric/dp/1155452186/ref=cm_cr_pr_product_top
>
> >> Only upside, it is in a more convenient format for reading while on
the
> >> toilet.
> >
> > And for other uses in that location?
>
> The paper isn't really too soft. It might be okay in an emergency.
>
> Simon
>
> --
> ------------------------------------------------------------------------
> "Well, an engineer is not concerned with the truth; that is left to
> philosophers and theologians: the prime concern of an engineer is
> the utility of the final product."
> Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
>
>
> ------------------------------
>
> Message: 24
> Date: Fri, 22 Oct 2010 06:27:37 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Test Diablo Model 31 drive and disk pack on a PC
> (Operation Alto Restoration)
> To: cctalk at classiccmp.org
> Message-ID: <4CC19149.5030409 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 5:57 PM, Nick Allen wrote:
> > Al and everyone else,
> >
> > I believe Al has had success interfacing a Diablo Model 31 with a PC
> computer
>
> I used a program that runs on the Alto and copies sectors across through
a
> PC parallel port.
>
> Could you take pictures of the labels on the packs? I normally supplied a
> couple of them
> with the machines that came from me, and could tell pretty quickly if
they
> need to be copied.
>
>
>
>
> ------------------------------
>
> Message: 25
> Date: Fri, 22 Oct 2010 07:07:24 -0700
> From: dwight elvey <dkelvey at hotmail.com>
> Subject: RE: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <SNT129-W644821C0BBBE562CFC5863A35E0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
>
> > From: cclist at sydex.com
> > To: cctalk at classiccmp.org
> > Date: Thu, 21 Oct 2010 21:50:44 -0700
> > Subject: Re: Viper 2150S scsi tape drive
> >
> > On 21 Oct 2010 at 21:37, dwight elvey wrote:
> >
> > > I just got this use drive and I was wondering if it
> > > is working as expected.
> > > When I plug in the tape, the head moves up and down
> > > but the tape drive motor doesn't move.
> > > Is this normal?
> >
> > My recollection of this drive is that the tape should be
> > automatically positioned to BOT when inserted. (i.e., the drive
> > should spin the tape a bit).
> >
> > --Chuck
> >
> >
> Thanks Chuck
> I was afraid of that. That was my recollection
> of similar drives. Now I have to find out why the motor
> doesn't spin.
> As I recalled, if the tape was accidentally loaded
> with the end of tape marker off the spool, it would
> unspool the hole thing and it would then be a 30
> minute job to spool it back on.
> I'll have to look at the motor drive and see what is up.
> The fact that I see the head moving gives me confidence
> that it is most likely the motor drive circuit.
> This is suppose to back up my Sparcbook. As you recall
> my 8mm drive didn't seem to work with it so I thought
> I'd try a drive that was inteneded.
> Dwight
>
> Dwight
>
>
> ------------------------------
>
> Message: 26
> Date: Fri, 22 Oct 2010 10:13:34 -0400
> From: Dave McGuire <mcguire at neurotica.com>
> Subject: Re: Viper 2150S scsi tape drive
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CC19C0E.3060509 at neurotica.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/22/10 10:07 AM, dwight elvey wrote:
> > This is suppose to back up my Sparcbook. As you recall
> > my 8mm drive didn't seem to work with it so I thought
> > I'd try a drive that was inteneded.
>
> 8mm drives were sold with early SPARCstations and SPARCservers as
> well, FYI. An 8mm drive will work fine if it's properly set up.
>
> -Dave
>
> --
> Dave McGuire
> Port Charlotte, FL
>
>
> End of cctalk Digest, Vol 86, Issue 46
> **************************************
------------------------------
Message: 14
Date: Sat, 23 Oct 2010 12:40:43 -0500
From: Martin Goldberg <wgungfu at gmail.com>
Subject: Re: Apple IIa
To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
Message-ID:
<AANLkTi=XtN6XYQQN-euZX8VmWrQUEA-6OULyovcjqYRX at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> At 9:00 AM -0700 10/23/10, Mr Ian Primus wrote:
>The IIe comes in two flavors - beige and "platinum".
It comes in more than that. There's also the IIe enhanced model
(pre-platinum), and you'll also find IIGS upgrade versions out there.
Marty
End of cctalk Digest, Vol 86, Issue 52
**************************************
Byte magazines pretty much the complete 1975-1977 years!
Kilobaud magazines: Year 1977
Dr Dobb's: Years 1977-79
Sun-2 technical overview documentation
Sun 100u Optical Mouse Docs
Mark 8 Minicomputer build plans from Radio Electronics magazine:
Here is the link to my seller profile (will display all current
auctions): http://shop.ebay.com/sdinet/m.html?_dmd=1&_ipg=50&_sop=12&_rdc=1
Trying to clear room in the condo, and raise funds to repair the
Alto/IMSAIs/Altairs!
> At 9:00 AM -0700 10/23/10, Mr Ian Primus wrote:
>The IIe comes in two flavors - beige and "platinum".
It comes in more than that. There's also the IIe enhanced model
(pre-platinum), and you'll also find IIGS upgrade versions out there.
Marty
Well, I thought I was the only one to have a Xerox Alto, appears there is another one in Chicago and it was just put on ebay:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=320602942545&ssPageName=…
Looks identical to mine (File Server, Xlto II XM), and having the same boot issues I am having (CRT warming up, but no image).
Will be interesting to see what it goes for (as there is no reserve), I just wish I could get the gentlemen selling it to assist me in getting mine repaired and working (as he mentions he has experience working on these).
Why yes, this is a repost from a few months ago. A few contacts, but no one has come through. I will recycle it in a week if there is no firm commitment to collect--gotta go.
------------------------------
Not really classic in this model,
however:
I have an AS/400e 9401-150 server and associated hardwarethat needs a new home. I obtained it last year and do not have the bandwidth to do anything with it.
I have not powered the server up, but I was told itworks. The front appears to have taken a hit in thelower left (dented grate behind and screw mountsnapped--reglued) and the face shows some scrapes. One thin horizontal molding (separator) is broken, and can be glued. Theback half-round cover is missing. I believe the previous owner obtained it 2nd hand for dev work. 2-32 meg memmodules, 2-4.x gig drives (59H7001) se scsi, CD, QIC 4/8 DL SLR5 tape drive, 90H9241 twinax card.
IBM 3477 InfoWindow terminal w/ 122 key kb. Found that thepower button needs to be pressed down a bit when released (for ON) to have it catch.
IBM 3197 terminal sans keyboard--never got it. Term powers up with 0A00 and 'k' on the bottom center.
Two lexmark 4028 AS1 laser printers. I have a note onone from last year that the pickup roller is toast.The other says OK, but I will check again.
Box of cables. Mostly T adapters or 9 and 15 pinD-subs, one twinax cable, one MAU (really), two terms, one8-port fan-out (21F5093), and second 8-port fanout (mod# ?),plus a few baluns and odd pieces. There are plenty ofTs, but you will probably need more cable to hook up more than one or two devices.
A few misc docs.
CD/Floppies: V4 OS, Client Access for 95/NT, LanStreamer, PCI diags
Images:www.flickr.com/photos/31439100 at N05/sets/72157624713623016/
I don't want to part it out if I can help it--goes as onegroup. I'll keep the printer with the toasted roller forparts if it isn't wanted. Metro-west Boston, MA.Pick-up, or I'll deliver inside the 495 area on myschedule. I will store for a while, if you are really going to collect it, or relay it.
--Jimjtp at chinalake.com
Hi,
I am moving to a smaller place and need to off-load some bits I am not
going to have space for.
An Octane (works but case in a bad shape) dual processor sse graphics
it had 1gb of memory but some was bad, I think it's 768mb
A Sun Blade 2000 Dual processors with 1gb memory and 18gb drive.
2 rack mount sparc machines with 2xmachines in each unit (Non sun) I
think they are 500mhz and 1gb memory
A Dell Itanium rack mount machine which won't run VMS. I
Vax 4000/90 with a non working PSU
A non working ex-millitary oscilloscope
I need to check but a number of vt220 terminals with keyboards.
I'm sure these will be popular: I have 8x big heavy drive DSSI drive
units. They have not been powered up for a few years. They have
scsi-->dssi convertor cards in them. They currently have 1GB and 2GB
full height drive units in them. But they can take up to 9GB.
I also have cabling which I have to sort out mainly for SUN and DEC. I
have all the cabling for the dssi drives and a lot of monitor and
other cables for Vaxstation 3100's.
I am based in Central London and all of the machines are too heavy for
me to ship. But let me know I'm sure we can work something out.
These are available for free, but as at the moment the only machines I
am keeping (or allowed to keep) are my RM machines I am interested in
any cables software and monitors for 380Z, 480Z and early PC's
I am going to be quite busy all over the weekend, so I may not get a
chance to reply until monday.
Dan
There are a couple of gaps in the documented opcodes for the 8008, namely:
0x22, 0x2a, 0x32,0x38,0x39,0x3a
Is the behavior of the 8008 CPU when executing any of these bytes
described anywhere?
There are a lot of maindec ppt images on the net, but I fail to find 8/L specific ones.
Or could I just use the 8/I maindec to check out the 8/l core stack, since they share the same stack ?
Jos
> From: Charlie Carothers <csquared3 at tx.rr.com>
> According to this:
> http://www-03.ibm.com/ibm/history/exhibits/650/650_ch1.html the first
> 650 was installed at a customer site in December, 1954.
Indeed but when was the machine which is working first? The 'Mini' car was first sold in 1959 but some are older than others, indeed a car of the same name is still in production. I'm now after the oldest ten working stored program computers. I'd also be interested in the oldest working stored program computers with core memory.
Thank you very much for your efforts.
> I thought this was pretty interesting as well:
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FT1.html
> It indicates the 701 was around in 1952. I'm not sure if you want to
> limit your list to core memory or not. It appears that the 701's
> internal memory consisted of a drum and a CRT. In any case, I need to
> waste a lot more time exploring these pages. :-)
> Later,
> Charlie C.
That is a great find. It even includes the first machine I ever wrote a program for, the IBM 7094 (in Fortran IV using the Purdue University Fast Fortran Translator).
I too will have to crawl around the tree and hopefully learn more about the early IBM machines.
A friend has found that he has an Apple IIa with two Apple disk drives. I
know nothing about Apple machines and would like to tell him if this is
something relatively rare or still quite common. I know I asked a similar
question a while ago for another friend but I have been unable to find the
email in the archives so I don't know if I am asking about the same model
again this time. Any information appreciated
Thanks
Rob
> From: Simon Fryer <fryers at gmail.com>
>>> Yes, and made the mistake of buying one. Couldn't believe it when it
>>> actually arrived. I left an interesting review on Amazon.
>>
>> Do you happen to remember the title (or have a URL) for this? I wonder
>> how the authors of that/those wikipedia articles feel about this? I know
>> I'd be pretty annoyed if somedy did that with something I'd written.
>
> ISBN 10: 1155452186
> ISBN 13: 978-1155452180
> Title: ICL Mainframe Computers: Leo, English Electric Kdf8, Elliott
> 803, Ict 1900, ICL 2900 Series, English Electric Kdf9, Ict 1301
> By: Books LLC
>
> http://www.amazon.co.uk/ICL-Mainframe-Computers-English-Electric/dp/1155452…
Thank you very much for the warning. I would have been very annoyed if I bought it and discovered the only information on the 1301 was mainly what I had written myself on Wikipedia. I knew it had been copied onto other web site but at least they were free. Every now and again I do a search on ICT 1301 and the number of hits keeps expanding. A few real gems get added sometimes and a lot of stuff about Info & Comms Technology (hence ICT) which happens to have 1301 on the page but almost every time there is a new web site or two with yet another copy of my words. Why do they bother?
Hi Gang,
I just got a Compaq lugable, and it seems that the XT IDE board is the next thing to add.
Anybody (Andrew Lynch?) have some blank boards and the rom, or a completed board, cable, drive they what to sell?
Thanks,
Randy
Hello,
Yes the tape should poition and the head seak track one. The 2150 has a puck
that pinches when the slide locks the cartridge in place. Check to be sure
that the puck is not soft with your finger. DO NOT APPLY ALCOHOL TO THE
PUCK.
The puck is driven by a belt from the drive motor.
Hope this helps.
Phil
I've got a nice, boxed and working AT&T 6300 that has to go ASAP.
I've had it on eBay (item 190454801269) but the shipping is/was
prohibative ($110ish for 3 boxes) and it's been languishing on The
VCGM for too long.
I'm brokering this for someone in the NorCal area and if it's not gone
very soon it's going back to the owner and subsequently, eventually,
to the recycler.
I'll pass any reasonable offers on to the owner for consideration.
Local pickup is preferred.
And no, "you're gonna throw it away anyway so just give it to me" is
not a "reasonable" offer. :)
--
Erik Klein
www.vintage-computer.comwww.vintage-computer.com/vcforum - The Vintage Computer Forums
marketplace.vintage-computer.com - The Vintage Computer and Gaming Marketplace
On Fri, 22 Oct 2010 11:03:10 +0200 (CEST) Christian Corti wrote:
>Per definition, a magnetic drum is not random access.
>A random access storage is defined by the fact that addressing
>any arbitrary cell needs the same time.
.
That may be today's definition but if you check the literature of the 50's
and 60's I am sure u will find drums (along with Williams Tubes, etc)
categorized as random access devices. Even the first disk drive was the IBM
RAMAC 350 - as in Random Access Memory! I think IBM invented the term
Direct Access Storage in the 1960s to distinguish devices whose assess time
was short but variable; that is, in between core (random) and tape
(sequential).
So the historical definition may have been . needs essentially the same
time.
Tom
> -----Original Message-----
> From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
> On Behalf Of cctalk-request at classiccmp.org
> Sent: Friday, October 22, 2010 7:14 AM
> To: cctalk at classiccmp.org
> Subject: cctalk Digest, Vol 86, Issue 46
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: 1986 NSA paper on computers (William Donzelli)
> 2. RE: the new manx is live (Rob Jarratt)
> 3. RE: Cataloguing in a museum setting [was Re: nonsense...]
> (Ian King)
> 4. Re: cctalk Digest, Vol 86, Issue 45 (MikeS)
> 5. Re: Moving House - Need to downsize (Dan Williams)
> 6. Re: cctalk Digest, Vol 86, Issue 45 (Al Kossow)
> 7. Re: the new manx is live (Dan Roganti)
> 8. Re: the new manx is live (Richard)
> 9. Re: cctalk Digest, Vol 86, Issue 45 (Chuck Guzis)
> 10. RE: Cataloguing in a museum setting [was Re: nonsense...]
> (Rich Alderson)
> 11. Re: HTL (Charles Dickman)
> 12. Re: Cataloguing in a museum setting [was Re: nonsense...]
> (Al Kossow)
> 13. Viper 2150S scsi tape drive (dwight elvey)
> 14. Re: Viper 2150S scsi tape drive (Chuck Guzis)
> 15. Re: Moving House - Need to downsize (Pontus Pihlgren)
> 16. Re: the new manx is live (Pontus Pihlgren)
> 17. Test Diablo Model 31 drive and disk pack on a PC (Operation
> Alto Restoration) (Nick Allen)
> 18. Re: Oldest original proper computer (stored program etc)
> (Charlie Carothers)
> 19. Re: Viper 2150S scsi tape drive (r.stricklin)
> 20. Re: Oldest original proper computer (stored program etc)
> (Jochen Kunz)
> 21. Re: Oldest original proper computer (stored program etc)
> (Christian Corti)
> 22. RE: Oldest original working proper computer (stored program
> etc) (Roger Holmes)
> 23. Re: lilith computer by wikipedia (Simon Fryer)
> 24. Re: Test Diablo Model 31 drive and disk pack on a PC
> (Operation Alto Restoration) (Al Kossow)
> 25. RE: Viper 2150S scsi tape drive (dwight elvey)
> 26. Re: Viper 2150S scsi tape drive (Dave McGuire)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Oct 2010 17:25:52 -0400
> From: William Donzelli <wdonzelli at gmail.com>
> Subject: Re: 1986 NSA paper on computers
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinUBCts0XvV0RaGH7RcJQab-Vqm5YjBrks8aQP3 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > Will, you've got a 1604; do you know anything about this?
>
> Not me.
>
> I probably have enough of the modules that I could build one, however.
>
> --
> Will
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Oct 2010 22:28:17 +0100
> From: "Rob Jarratt" <robert.jarratt at ntlworld.com>
> Subject: RE: the new manx is live
> To: "'General Discussion: On-Topic and Off-Topic Posts'"
> <cctalk at classiccmp.org>, "'General Discussion: On-Topic Posts
> Only'"
> <cctech at classiccmp.org>
> Message-ID: <015601cb7166$e49b58a0$add209e0$(a)ntlworld.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > -----Original Message-----
> > From: cctalk-bounces at classiccmp.org [mailto:cctalk-
> > bounces at classiccmp.org] On Behalf Of Torfinn Ingolfsen
> > Sent: 21 October 2010 08:10
> > To: General Discussion: On-Topic Posts Only
> > Subject: Re: the new manx is live
> >
> > On Wed, Oct 20, 2010 at 7:33 PM, Richard <legalize at xmission.com> wrote:
> >
> > > Manx is an online catalog of computer documentation.
> > >
> > > The new manx is up for beta testing here: <http://manx.classiccmp.org>
> > >
> >
> > I seem to be having problems reaching the site.
> > Details:
> > root at kg-quiet# traceroute manx.classiccmp.org traceroute to
> classiccmp.org
> > (209.145.140.17), 64 hops max, 52 byte packets
> > 1 kg-omni1 (10.1.10.1) 0.228 ms 0.182 ms 0.158 ms
> > 2 kg-ruter (10.0.0.1) 77.819 ms 127.069 ms 86.825 ms
> > 3 1.80-203-92.nextgentel.com (80.203.92.1) 15.481 ms 14.011 ms
> 14.051
> ms
> > 4 80-202-3-30.dd.nextgentel.com (80.202.3.30) 17.763 ms * 59.706 ms
> > 5 217-13-0-70.dd.nextgentel.com (217.13.0.70) 18.365 ms 14.260 ms
> > 14.759 ms
> > 6 oso-b3-link.telia.net (80.239.193.93) 15.088 ms 14.948 ms 14.765
> ms
> > 7 kbn-bb2-link.telia.net (80.91.251.49) 34.331 ms 27.930 ms 28.293
> ms
> > 8 hbg-bb2-link.telia.net (80.91.252.114) 78.106 ms 34.255 ms 34.479
> ms
> > 9 ffm-bb2-link.telia.net (80.91.247.142) 67.265 ms
> > ffm-bb2-link.telia.net (80.91.245.123) 44.158 ms
> > ffm-bb2-link.telia.net (80.91.247.142) 50.006 ms
> > 10 ffm-b2-link.telia.net (80.91.249.103) 42.490 ms
> > ffm-b2-link.telia.net (80.91.252.174) 41.347 ms
> > ffm-b2-link.telia.net (80.91.249.103) 42.628 ms
> > 11 cogent-ic-135155-ffm-b2.c.telia.net (213.248.93.174) 51.872 ms
> 42.313 ms
> > 40.571 ms
> > 12 te0-2-0-6.ccr22.fra03.atlas.cogentco.com (154.54.36.81) 42.860 ms
> > te0-2-0-6.mpd21.dca01.atlas.cogentco.com (154.54.31.245) 132.058 ms
> > te0-4-0-0.mpd21.dca01.atlas.cogentco.com (154.54.26.101) 147.305 ms
> > 13 te0-4-0-0.ccr22.dca01.atlas.cogentco.com (154.54.42.113) 140.836 ms
> > te0-2-0-4.mpd21.ord01.atlas.cogentco.com (154.54.40.226) 152.265 ms
> > te0-2-0-6.ccr22.dca01.atlas.cogentco.com (154.54.31.241) 135.140 ms
> > 14 te0-1-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.206) 143.202 ms
> > te0-2-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.210) 157.894 ms
> > 147.097 ms
> > 15 te3-2.ccr01.stl03.atlas.cogentco.com (154.54.27.30) 150.725 ms
> 150.014
> > ms 150.329 ms
> > 16 vl3808.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.170)
> 167.084
> > ms 156.374 ms
> > vl3508.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.166)
> 158.136
> ms
> > 17 38.104.146.10 (38.104.146.10) 155.110 ms 155.902 ms 152.225 ms
> > 18 host42.datotel.com (208.82.151.42) 161.893 ms 179.548 ms 167.528
> ms
> > 19 stl-d1-g5-1.datotel.com (208.82.151.22) 157.149 ms 151.804 ms
> 151.915
> > ms
> > 20 * * *
> > 21 * * *
> > 22 * * *
> > 23 * * *
> > 24 * * *
> > 25 * * *
> > 26 * * *
> > 27 * * *
> > 28 * * *
> > 29 * * *
> > 30 * * *
> > 31 * host50.datotel.com (208.75.82.50) 156.517 ms !X *
> > 32 * * *
> > 33 * * *
> > 34 * * *
> > 35 * * *
> > 36 * * *
> > 37 * * *
> > 38 * * *
> > 39 * * *
> > 40 * * *
> > 41 * * *
> > 42 * * *
> > 43 * * *
> > 44 * * *
> > 45 * * *
> > 46 * * *
> > 47 * * *
> > 48 * * *
> > 49 * * *
> > 50 * * *
> > 51 * * *
> > 52 * * *
> > 53 * * *
> > 54 * * *
> > 55 * * *
> > 56 * * *
> > 57 * * *
> > 58 * * *
> > 59 * * *
> > 60 * * *
> > 61 * * *
> > 62 * * *
> > 63 * * *
> > 64 * * *
> > root at kg-quiet#
> >
> > Is it working ok for everyone else?
> > --
> > Regards,
> > Torfinn Ingolfsen
> > Oslo, Norway
>
> Works OK for me, here is my tracert:
>
> 1 8 ms 3 ms <1 ms JUPITER [192.168.0.1]
> 2 42 ms 22 ms 26 ms 10.236.80.1
> 3 29 ms 66 ms 9 ms oldh-cam-1a-v100.network.virginmedia.net
> [80.5.1
> 65.13]
> 4 11 ms 24 ms 12 ms manc-core-1a-ae2-0.network.virginmedia.net
> [195.
> 182.180.37]
> 5 25 ms 23 ms 18 ms manc-bb-1a-as0-0.network.virginmedia.net
> [213.10
> 5.175.1]
> 6 22 ms 31 ms 49 ms manc-bb-1b-ae0-0.network.virginmedia.net
> [62.253
> .187.178]
> 7 34 ms 45 ms 35 ms nrth-bb-1a-as3-0.network.virginmedia.net
> [213.10
> 5.64.21]
> 8 30 ms 29 ms 15 ms nrth-tmr-1-ae1-0.network.virginmedia.net
> [213.10
> 5.159.30]
> 9 64 ms 54 ms 43 ms fran-ic-1-as0-0.network.virginmedia.net
> [62.253.
> 185.81]
> 10 76 ms 51 ms 54 ms te0-7-0-7.mpd22.fra03.atlas.cogentco.com
> [130.11
> 7.14.133]
> 11 144 ms 138 ms 120 ms te0-2-0-6.mpd22.dca01.atlas.cogentco.com
> [130.11
> 7.51.230]
> 12 138 ms 186 ms 155 ms te0-0-0-4.mpd22.ord01.atlas.cogentco.com
> [154.54
> .40.234]
> 13 137 ms 145 ms 155 ms te0-1-0-0.ccr22.ord01.atlas.cogentco.com
> [154.54
> .6.178]
> 14 184 ms 142 ms 141 ms te3-2.ccr01.stl03.atlas.cogentco.com
> [154.54.27.
> 30]
> 15 173 ms 146 ms 158 ms
> vl3808.na41.b003211-0.stl03.atlas.cogentco.com [
> 38.20.47.170]
> 16 165 ms 165 ms 180 ms 38.104.146.10
> 17 163 ms 151 ms 146 ms host42.datotel.com [208.82.151.42]
> 18 147 ms 151 ms 161 ms stl-d1-g5-1.datotel.com [208.82.151.22]
> 19 151 ms 140 ms 155 ms host50.datotel.com [208.75.82.50]
> 20 146 ms 163 ms 158 ms 209-145-130-66.accessus.net
> [209.145.130.66]
> 21 147 ms 160 ms 163 ms louie.classiccmp.org [209.145.140.17]
>
> Regards
>
> Rob
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Oct 2010 14:30:07 -0700
> From: Ian King <IanK at vulcan.com>
> Subject: RE: Cataloguing in a museum setting [was Re: nonsense...]
> To: "'General Discussion: On-Topic and Off-Topic Posts'"
> <cctalk at classiccmp.org>
> Message-ID: <FF6AB92D97A23A409701CDBF66F03FCD03DC3E70BE at 505fuji>
> Content-Type: text/plain; charset="us-ascii"
>
> > -----Original Message-----
> > From: cctalk-bounces at classiccmp.org [mailto:cctalk-
> > bounces at classiccmp.org] On Behalf Of Tony Duell
> > Sent: Thursday, October 21, 2010 12:18 PM
> > To: cctalk at classiccmp.org
> > Subject: Re: Cataloguing in a museum setting [was Re: nonsense...]
> >
> > > > I'd like to hear more about what constitutes "cataloging", as I'm a
> > > > n00b in this respect.
> > >
> > > Just what it sounds like. :-)
> > >
> > > When an item comes into the collection, it is assigned an accession
> > > number; the standard is yyyy.nnn.mmm, where nnn represents order in
> > > which the item came in in year yyyy, and mmm is the individual number
> > > of each piece that makes up the item. If a piece is made up of
> > > parts (say a tea set, for example) a letter can be suffixed to the
> > > piece number for each part to make it possible to keep them
> > associated
> > > even if physically apart. Leading zeroes should be used in the item
> > > and piece numbers.
> >
> > What do you mean by 'item','piece' and 'part' here? I can understand an
> > item being made of several pieces, but why do you need a third level
> > here?
> >
> > In the case of a classic computer, what would you label? The casing?
> > The
> > individual PCBs/modules? How would you handle the case of taking 2
> > effectively identical machines acquired at differnet times and using
> > parts from bvth to make one working example, or would a museum never do
> > that? (If the latter, then I consider the policy to be broken!).
> >
>
> Yes. :-)
>
> Seriously: we do encounter this situation. When a machine comes in, it is
> catalogued as an entity. If we find it necessary to remove a component
> from machine A to install in machine B, the component is separately
> catalogued with a note in the record stating that it was originally part
> of machine A.
>
> I did this recently with a machine that came as a system containing an
> RK05 drive identified as non-functional. We used the RK8-E from that
> machine with another PDP-8/e that also had RK05 drives but no RK8-E.
>
> That would not be appropriate for a machine that is historically
> significant in its particular configuration (for example, our PDP-12), but
> that's a hard argument to make for the vast majority of PDP-8/e's. And
> given the records we keep, we could restore the accession to its original
> configuration if needed.
>
> It's always a judgement call when one must balance preservation and
> restoration. -- Ian
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 Oct 2010 17:52:03 -0400
> From: "MikeS" <dm561 at torfree.net>
> Subject: Re: cctalk Digest, Vol 86, Issue 45
> To: <cctalk at classiccmp.org>
> Message-ID: <C254F6585ED7493FB620AF800A7CA4F5 at vl420mt>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> Date: Thu, 21 Oct 2010 11:03:54 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: cctalk at classiccmp.org
> Message-ID: <4CC0808A.8010108 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 10:03 AM, Chuck Guzis wrote:
> >> For example, the GI GIMINI (CP1600)
>
> > That would be fun to find. There was a version that I used in the late
> > 70's that had a DSD floppy disk interfaced to it. I think I still have
> > all of the software for it.
> ----
> And I've got some brochures and datasheets for the GIC8000 and GIMINI and
> the various cards and chips in them, so all we need is the computer ;-)
>
> mike
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 21 Oct 2010 22:53:10 +0100
> From: Dan Williams <williams.dan at gmail.com>
> Subject: Re: Moving House - Need to downsize
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinSeMiB8LqMnhemRO9Gkq56Ov5wGO6oZfeYtG0P at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 21 October 2010 20:12, Pontus Pihlgren <pontus at update.uu.se> wrote:
> > On Thu, Oct 21, 2010 at 07:12:03PM +0100, Dan Williams wrote:
> >> I'm sure these will be popular: ?I have 8x big heavy drive DSSI drive
> >> units. They have not been powered up for a few years. They have
> >> scsi-->dssi convertor cards in them. They currently have 1GB and 2GB
> >> full height drive units in them. But they can take up to 9GB.
> >> I also have cabling which I have to sort out mainly for SUN and DEC. I
> >> have all the cabling for the dssi drives and a lot of monitor and
> >> other cables for Vaxstation 3100's.
> >
> > I'm curious about that SCSI->DSSI converter. Is it used to run dssi
> > disks on a scsi controller or scsi disks on a dssi controller ?
> >
> > The latter would be interesting.
> >
> > Regards,
> > Pontus.
> >
>
> It takes scsi disks on a dssi controller. It has a front panel and you
> can connect to the controller like a normal dssi disk. It is a
> liberator 220. I have the user manual for it if anyone is interested.
>
> Dan
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 21 Oct 2010 15:08:48 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: cctalk Digest, Vol 86, Issue 45
> To: cctalk at classiccmp.org
> Message-ID: <4CC0B9F0.5000705 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 2:52 PM, MikeS wrote:
> > Date: Thu, 21 Oct 2010 11:03:54 -0700
> > From: Al Kossow <aek at bitsavers.org>
> > Subject: Re: Oldest original proper computer (stored program etc)
> > To: cctalk at classiccmp.org
> > Message-ID: <4CC0808A.8010108 at bitsavers.org>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > On 10/21/10 10:03 AM, Chuck Guzis wrote:
> >>> For example, the GI GIMINI (CP1600)
> >
> >> That would be fun to find. There was a version that I used in the late
> >> 70's that had a DSD floppy disk interfaced to it. I think I still have
> >> all of the software for it.
> > ----
> > And I've got some brochures and datasheets for the GIC8000 and GIMINI
> and the various cards and chips in them, so all we need is the computer ;-
> )
> >
>
> I uploaded the GIMINI manuals under generalInstruments on bitsavers a
> couple of weeks ago.
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 21 Oct 2010 18:14:26 -0400
> From: Dan Roganti <ragooman at gmail.com>
> Subject: Re: the new manx is live
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinTe5iYUGDnrsygRs+4XuFwxrGweoN+rEDL6fMg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Oct 21, 2010 at 5:18 PM, Richard <legalize at xmission.com> wrote:
>
> >
> > In article <AANLkTikFFFKKo=6Ba=6DjtK1hUkDUSciHp+WO-
> gfLNyM at mail.gmail.com<6DjtK1hUkDUSciHp%2BWO-gfLNyM at mail.gmail.com>
> > >,
> > Torfinn Ingolfsen <tingox at gmail.com> writes:
> >
> > > Is it working ok for everyone else?
> >
> > Noone else has reported problems; manx is hosted on the same group of
> > machines that serves this mailing list and several other classic
> > computing sites graciously hosted by Jay.
> >
> >
>
> very nice !
>
> Can we always request to add addt'l companies ?
> SEL is on Bitsavers already but not listed on yours.
>
>
> =Dan
> --http://www.vintagecomputer.net/ragooman/
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 21 Oct 2010 16:51:54 -0600
> From: Richard <legalize at xmission.com>
> Subject: Re: the new manx is live
> To: cctalk <cctalk at classiccmp.org>
> Message-ID: <E1P93zG-0005Jz-CS at shell.xmission.com>
>
>
> In article <AANLkTinTe5iYUGDnrsygRs+4XuFwxrGweoN+rEDL6fMg at mail.gmail.com>,
> Dan Roganti <ragooman at gmail.com> writes:
>
> > Can we always request to add addt'l companies ?
> > SEL is on Bitsavers already but not listed on yours.
>
> This first round was just to reproduce the existing manx.
>
> Next up is to add users and roles to provide for community additions.
>
> Contributions of code are welcome. The whole code base has been
> developed test-driven and is covered by unit tests.
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
> <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
>
> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 21 Oct 2010 16:04:02 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: cctalk Digest, Vol 86, Issue 45
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CC06472.12811.1626E31 at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 21 Oct 2010 at 15:08, Al Kossow wrote:
>
> > I uploaded the GIMINI manuals under generalInstruments on bitsavers a
> > couple of weeks ago.
>
> Well, I've got the CP1600 CPU sitting unused in my hellbox and the
> blue manual that gives the schematics for the system. But no
> firmware listing for the monitor...
>
> BTW, did anyone notice that there's a fellow on eBay offering the
> INS8900 (PACE in NMOS) NOS CPUs for about $16 the each?
>
> --Chuck
>
>
>
> ------------------------------
>
> Message: 10
> Date: Thu, 21 Oct 2010 16:04:06 -0700
> From: Rich Alderson <RichA at vulcan.com>
> Subject: RE: Cataloguing in a museum setting [was Re: nonsense...]
> To: "'General Discussion: On-Topic and Off-Topic Posts'"
> <cctalk at classiccmp.org>
> Message-ID:
> <CC28F43ED4708D489ABCF68D06D7F556040A5CCB91 at 505DENALI.corp.vnw.com>
> Content-Type: text/plain; charset="us-ascii"
>
> From: Tony Duell
> Sent: Thursday, October 21, 2010 12:18 PM
>
> >> When an item comes into the collection, it is assigned an accession
> >> number; the standard is yyyy.nnn.mmm, where nnn represents order in
> >> which the item came in in year yyyy, and mmm is the individual number
> >> of each piece that makes up the item. If a piece is made up of
> >> parts (say a tea set, for example) a letter can be suffixed to the
> >> piece number for each part to make it possible to keep them associated
> >> even if physically apart. Leading zeroes should be used in the item
> >> and piece numbers.
>
> > What do you mean by 'item','piece' and 'part' here? I can understand an
> > item being made of several pieces, but why do you need a third level
> here?
>
> I was trying not to re-use the same word for different levels.
>
> You donate items to a museum, let's say for simplicity's sake a horse shoe
> and a tea service with 4 individually decorated cups and matching saucers,
> pot, sugar and creamer.
>
> You do this in 2010. That's the first field of the accession numbers.
>
> The two items are the 75th and 76th donated to the museum this year.
> These numbers will be the second fields of the respective accession
> numbers.
>
> The horse shoe will receive accession number 2010.075.001, and be marked
> as 2010.75.1
>
> The tea pot will be 2010.076.001; the sugar, 2010.076.002; the creamer,
> 2010.076.003; the first cup-and-saucer pair, 2010.076.004A and
> 2010.076.004B;
> and so on. The reason for pairing the cup and saucer will be the matching
> decoration on each pair.
>
> You could also simply number each piece individually, but then you lose
> information.
>
> > In the case of a classic computer, what would you label? The casing? The
> > individual PCBs/modules? How would you handle the case of taking 2
> > effectively identical machines acquired at differnet times and using
> > parts from bvth to make one working example, or would a museum never do
> > that? (If the latter, then I consider the policy to be broken!).
>
> I'll start with the last comment. The policy will depend on the purpose
> of the museum; no two museums have identical missions, though they may be
> very close. A computer museum with a mission of making systems run will
> have a very different answer to your question than a museum dealing with
> the history of engineering laboratories, where the identical computers
> may have been used for very different purposes and be important to the
> understanding of how each lab achieved its goals. (Not every museum tries
> to please everyone in the know about a topic--there are art museums which
> I find deadly dull, and art museums I love to visit over and over, for
> example.) Neither policy is "broken", they simply differ.
>
> Computers are more difficult to catalog than tea services. My personal
> preference would be to replicate the manufacturer's bill of materials,
> assigning accession numbers at each level down to the circuit boards (or
> equivalent, in the case of large valve-based modules, but those don't
> crop up in the time frame in which we have specialized). Since the
> catalog here was set up by someone else several years before I joined
> the team, I have to accommodate myself to what is in place--we're not in
> a position to re-catalog several thousand pieces my way.
>
> We catalog the top-level items (CPU, disk drives, tape drives, printers,
> etc.) when they come in. The low-level items (disk packs and cartridges,
> tapes, boards, etc.) are fuzzier: Loose items, like spare boards, are
> catalogued when they come in, but boards installed in larger items only
> get catalogued when they are pulled for repair or replacement.
>
> It takes discipline to catalog pieces when you would really rather be
> restoring a system to working condition, but without a catalog, you will
> very quickly lose all semblance of provenance, and your reason for being
> a museum.
>
>
> Rich Alderson
> Vintage Computing Sr. Server Engineer
> Vulcan, Inc.
> 505 5th Avenue S, Suite 900
> Seattle, WA 98104
>
> mailto:RichA at vulcan.com
> mailto:RichA at LivingComputerMuseum.org
>
> http://www.PDPplanet.org/
> http://www.LivingComputerMuseum.org/
>
>
> ------------------------------
>
> Message: 11
> Date: Thu, 21 Oct 2010 21:09:31 -0400
> From: Charles Dickman <chd at chdickman.com>
> Subject: Re: HTL
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTimgJ80NcGDTXXwhRHZFDfbzy_reGtCe65juy5Ax at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Oct 20, 2010 at 11:27 PM, William Donzelli
> <wdonzelli at gmail.com>wrote:
>
> > Maybe a retarded question, but how static sensitive are HTL chips?
> >
> > Why do you ask?
>
> I have quite a few HTL chips that I have no use for.
>
> -chuck
>
>
> ------------------------------
>
> Message: 12
> Date: Thu, 21 Oct 2010 18:23:11 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Cataloguing in a museum setting [was Re: nonsense...]
> To: cctalk at classiccmp.org
> Message-ID: <4CC0E77F.3000005 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 4:04 PM, Rich Alderson wrote:
> > The low-level items (disk packs and cartridges,
> > tapes, boards, etc.) are fuzzier
>
> But necessary.
>
> We're discovering that systems were accepted in Boston with no boards in
> them,
> for example, and there is nothing in the accession record that mentions
> that
> fact.
>
> It's absolutely necessary to know if anything that should be in an
> accessioned
> artifact is missing, and the condition.
>
> It is a huge amount of work to catalog a collection.
>
> One of the requirements for museum accreditation is having a significant
> portion of your collection cataloged.
>
> CHM has come a LONG way since I've been here. We have just under 75,000
> items
> visible in the on-line data base
>
> http://www.computerhistory.org/collections/search/
>
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Thu, 21 Oct 2010 21:37:58 -0700
> From: dwight elvey <dkelvey at hotmail.com>
> Subject: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <SNT129-W286E3F0A65E7EDCFA0F5C3A35E0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> Hi
> I just got this use drive and I was wondering if it
> is working as expected.
> When I plug in the tape, the head moves up and down
> but the tape drive motor doesn't move.
> Is this normal?
> Dwight
>
>
> ------------------------------
>
> Message: 14
> Date: Thu, 21 Oct 2010 21:50:44 -0700
> From: "Chuck Guzis" <cclist at sydex.com>
> Subject: Re: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <4CC0B5B4.16151.2A10F67 at cclist.sydex.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On 21 Oct 2010 at 21:37, dwight elvey wrote:
>
> > I just got this use drive and I was wondering if it
> > is working as expected.
> > When I plug in the tape, the head moves up and down
> > but the tape drive motor doesn't move.
> > Is this normal?
>
> My recollection of this drive is that the tape should be
> automatically positioned to BOT when inserted. (i.e., the drive
> should spin the tape a bit).
>
> --Chuck
>
>
>
>
> ------------------------------
>
> Message: 15
> Date: Fri, 22 Oct 2010 07:13:36 +0200
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> Subject: Re: Moving House - Need to downsize
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <20101022051336.GA15674 at Update.UU.SE>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Oct 21, 2010 at 10:53:10PM +0100, Dan Williams wrote:
> >
> > It takes scsi disks on a dssi controller. It has a front panel and you
> > can connect to the controller like a normal dssi disk. It is a
> > liberator 220. I have the user manual for it if anyone is interested.
>
> It would be a lovely thing to have. I live in sweden and unless you find
> someone local and wouldn't mind shipping I wouldn't mind paying for it.
> Well, it depends on the size of course, how big is this thing?
>
> /P
>
>
> ------------------------------
>
> Message: 16
> Date: Fri, 22 Oct 2010 07:16:37 +0200
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> Subject: Re: the new manx is live
> Cc: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
> Message-ID: <20101022051637.GB15674 at Update.UU.SE>
> Content-Type: text/plain; charset=us-ascii
>
> This is a semiuseful tool:
>
> http://downforeveryoneorjustme.com/http://manx.classiccmp.org/
>
> Good work everyone! Manx is an awesome tool! Many thanks.
>
> /Pontus
>
>
> On Thu, Oct 21, 2010 at 09:10:28AM +0200, Torfinn Ingolfsen wrote:
> > On Wed, Oct 20, 2010 at 7:33 PM, Richard <legalize at xmission.com> wrote:
> >
> > > Manx is an online catalog of computer documentation.
> > >
> > > The new manx is up for beta testing here: <http://manx.classiccmp.org>
> > >
> >
> > I seem to be having problems reaching the site.
> > Details:
> > root at kg-quiet# traceroute manx.classiccmp.org
> > traceroute to classiccmp.org (209.145.140.17), 64 hops max, 52 byte
> packets
> > 1 kg-omni1 (10.1.10.1) 0.228 ms 0.182 ms 0.158 ms
> > 2 kg-ruter (10.0.0.1) 77.819 ms 127.069 ms 86.825 ms
> > 3 1.80-203-92.nextgentel.com (80.203.92.1) 15.481 ms 14.011 ms
> 14.051
> > ms
> > 4 80-202-3-30.dd.nextgentel.com (80.202.3.30) 17.763 ms * 59.706 ms
> > 5 217-13-0-70.dd.nextgentel.com (217.13.0.70) 18.365 ms 14.260 ms
> > 14.759 ms
> > 6 oso-b3-link.telia.net (80.239.193.93) 15.088 ms 14.948 ms 14.765
> ms
> > 7 kbn-bb2-link.telia.net (80.91.251.49) 34.331 ms 27.930 ms 28.293
> ms
> > 8 hbg-bb2-link.telia.net (80.91.252.114) 78.106 ms 34.255 ms 34.479
> ms
> > 9 ffm-bb2-link.telia.net (80.91.247.142) 67.265 ms
> > ffm-bb2-link.telia.net (80.91.245.123) 44.158 ms
> > ffm-bb2-link.telia.net (80.91.247.142) 50.006 ms
> > 10 ffm-b2-link.telia.net (80.91.249.103) 42.490 ms
> > ffm-b2-link.telia.net (80.91.252.174) 41.347 ms
> > ffm-b2-link.telia.net (80.91.249.103) 42.628 ms
> > 11 cogent-ic-135155-ffm-b2.c.telia.net (213.248.93.174) 51.872 ms
> 42.313
> > ms 40.571 ms
> > 12 te0-2-0-6.ccr22.fra03.atlas.cogentco.com (154.54.36.81) 42.860 ms
> > te0-2-0-6.mpd21.dca01.atlas.cogentco.com (154.54.31.245) 132.058 ms
> > te0-4-0-0.mpd21.dca01.atlas.cogentco.com (154.54.26.101) 147.305 ms
> > 13 te0-4-0-0.ccr22.dca01.atlas.cogentco.com (154.54.42.113) 140.836 ms
> > te0-2-0-4.mpd21.ord01.atlas.cogentco.com (154.54.40.226) 152.265 ms
> > te0-2-0-6.ccr22.dca01.atlas.cogentco.com (154.54.31.241) 135.140 ms
> > 14 te0-1-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.206) 143.202 ms
> > te0-2-0-4.ccr22.ord01.atlas.cogentco.com (154.54.40.210) 157.894 ms
> > 147.097 ms
> > 15 te3-2.ccr01.stl03.atlas.cogentco.com (154.54.27.30) 150.725 ms
> 150.014
> > ms 150.329 ms
> > 16 vl3808.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.170)
> 167.084
> > ms 156.374 ms
> > vl3508.na41.b003211-0.stl03.atlas.cogentco.com (38.20.47.166)
> 158.136
> > ms
> > 17 38.104.146.10 (38.104.146.10) 155.110 ms 155.902 ms 152.225 ms
> > 18 host42.datotel.com (208.82.151.42) 161.893 ms 179.548 ms 167.528
> ms
> > 19 stl-d1-g5-1.datotel.com (208.82.151.22) 157.149 ms 151.804 ms
> 151.915
> > ms
> > 20 * * *
> > 21 * * *
> > 22 * * *
> > 23 * * *
> > 24 * * *
> > 25 * * *
> > 26 * * *
> > 27 * * *
> > 28 * * *
> > 29 * * *
> > 30 * * *
> > 31 * host50.datotel.com (208.75.82.50) 156.517 ms !X *
> > 32 * * *
> > 33 * * *
> > 34 * * *
> > 35 * * *
> > 36 * * *
> > 37 * * *
> > 38 * * *
> > 39 * * *
> > 40 * * *
> > 41 * * *
> > 42 * * *
> > 43 * * *
> > 44 * * *
> > 45 * * *
> > 46 * * *
> > 47 * * *
> > 48 * * *
> > 49 * * *
> > 50 * * *
> > 51 * * *
> > 52 * * *
> > 53 * * *
> > 54 * * *
> > 55 * * *
> > 56 * * *
> > 57 * * *
> > 58 * * *
> > 59 * * *
> > 60 * * *
> > 61 * * *
> > 62 * * *
> > 63 * * *
> > 64 * * *
> > root at kg-quiet#
> >
> > Is it working ok for everyone else?
> > --
> > Regards,
> > Torfinn Ingolfsen
> > Oslo, Norway
>
>
> ------------------------------
>
> Message: 17
> Date: Thu, 21 Oct 2010 19:57:55 -0500
> From: Nick Allen <nick.allen at comcast.net>
> Subject: Test Diablo Model 31 drive and disk pack on a PC (Operation
> Alto Restoration)
> To: cctech at classiccmp.org
> Message-ID: <4CC0E193.9070101 at comcast.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Al and everyone else,
>
> I believe Al has had success interfacing a Diablo Model 31 with a
> PC computer (I assume so, since he uploaded the Alto diskpacks up to
> bitsavers.org). Al, Can you (or anyone else) please provide the steps
> on how to do so?
>
> If I can verify the disk drive is working, and the disk packs have valid
> data on them, this would be yet another step completed in getting the
> alto up and running =)
>
> Thanks!
>
>
>
> ------------------------------
>
> Message: 18
> Date: Thu, 21 Oct 2010 22:26:49 -0500
> From: Charlie Carothers <csquared3 at tx.rr.com>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org>
> Message-ID: <4CC10479.2020902 at tx.rr.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/18/2010 6:58 AM, Roger Holmes wrote:
> >> From: Christian Corti<cc at informatik.uni-stuttgart.de>
> >>
> >> On Sat, 16 Oct 2010, Roger Holmes wrote:
> >>> don't believe its true, I was told my machine is currently the oldest
> >>> original working computer. Not counting replicas or machines which
> don't
> >>> have stored programs. My machine was installed in 1962 (and designed
> in
> >>> the late 1950s).
> >>
> >> Then you've been told wrong.
> >> Several examples:
> >> - Our LGP-30 ser.no. 4, built 1958, still working with peripherals.
> Just
> >> yesterday I've had a group of visitors. It's been designed around
> 1954.
> >> - The IBM 650 of the IBM Museum in Sindelfingen (working)
> >> - The Zuse Z22 ser.no. 13 in Karlsruhe, also built around 1958
> (apparently
> >> still working, although the ZKM is not the right place for it IMHO)
> >> All are original first generation machines, and all of them are in
> >> southern Germany.
> >>
> >>> restored was first installed in 1964. Are there other? I'm not
> counting
> >>> the Zuse in Germany as its not a stored program machine, and anyway
> I'm
> >>> not sure if it is a replica or the original. It is surprising if it
> >>> survived the extensive bombing by the USAF and RAF during WW2 unless
> it
> >>> was stored in a bunker/cave/mine.
> >>
> >> What Zuse are you talking about? The Z3 has been destroyed, yes, and
> >> rebuilt by Zuse in 1962.
> >
> > Thank you, this is just the information I wanted.
> >
> > Is the Z3 stored program? Turing complete?
> >
> > If it is, then it would be useful to know when the rebuilt version
> became operational, though I'm not actually sure the actual month my
> machine went live either.
> >
> > Assuming for now that Z3 is not stored program, than my list so far is:
> >
> > 1958, LGP-30
> > 1958, Zuse Z22
> > Somewhere between 1954 and 1962, IBM 650
> > 1962 ICT 1301 serial no 6 (SO FAR the earliest surviving machine with
> random access program and data storage. i.e. Core and called Immediate
> Access Store by ICT).
> >
> > Thanks again.
> >
> > I expect the chaps in the states will tell me of several more when I
> catch up with my e-mails.
> >
> >
> >
> According to this:
> http://www-03.ibm.com/ibm/history/exhibits/650/650_ch1.html the first
> 650 was installed at a customer site in December, 1954.
>
> I thought this was pretty interesting as well:
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FT1.html
> It indicates the 701 was around in 1952. I'm not sure if you want to
> limit your list to core memory or not. It appears that the 701's
> internal memory consisted of a drum and a CRT. In any case, I need to
> waste a lot more time exploring these pages. :-)
> Later,
> Charlie C.
>
>
>
>
> ------------------------------
>
> Message: 19
> Date: Thu, 21 Oct 2010 23:23:44 -0700
> From: "r.stricklin" <bear at typewritten.org>
> Subject: Re: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
> Message-ID: <D428CDED-9195-48F5-B183-3CE5930788D1 at typewritten.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>
> On Oct 21, 2010, at 9:37 PM, dwight elvey wrote:
>
> > When I plug in the tape, the head moves up and down
> > but the tape drive motor doesn't move.
> > Is this normal?
>
> It could be, depending on firmware.
>
> ok
> bear
>
>
>
> ------------------------------
>
> Message: 20
> Date: Fri, 22 Oct 2010 08:53:46 +0200
> From: Jochen Kunz <jkunz at unixag-kl.fh-kl.de>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: cctalk at classiccmp.org
> Message-ID: <20101022085346.5c1f9ec0.jkunz at unixag-kl.fh-kl.de>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 18 Oct 2010 12:58:00 +0100
> Roger Holmes <roger.holmes at microspot.co.uk> wrote:
>
> > 1962 ICT 1301 serial no 6 (SO FAR the earliest surviving machine
> > with random access program and data storage.
> Well. The drum of the Z22 is random access program and data storage,
> just with a bit lattency...
>
> I don't know how and when the Z22 at the ZKM is operated now. When it
> moved to the ZKM there where weekly operating hours with demonstrations
> done by the former maintainers of the machine.
> --
>
>
> \end{Jochen}
>
> \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
>
>
>
> ------------------------------
>
> Message: 21
> Date: Fri, 22 Oct 2010 11:03:10 +0200 (CEST)
> From: Christian Corti <cc at informatik.uni-stuttgart.de>
> Subject: Re: Oldest original proper computer (stored program etc)
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <alpine.DEB.2.00.1010221057001.21272 at linuxserv.home>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Fri, 22 Oct 2010, Jochen Kunz wrote:
> > Well. The drum of the Z22 is random access program and data storage,
> > just with a bit lattency...
>
> Per definition, a magnetic drum is not random access. A random access
> storage is defined by the fact that addressing any arbitrary cell needs
> the same time.
> But the Z22 has a small amount of core memory, too, called
> "Schnellspeicher", i.e. "fast memory".
>
> Christian
>
>
> ------------------------------
>
> Message: 22
> Date: Fri, 22 Oct 2010 10:11:53 +0100
> From: Roger Holmes <roger.holmes at microspot.co.uk>
> Subject: RE: Oldest original working proper computer (stored program
> etc)
> To: cctalk at classiccmp.org
> Message-ID: <C1C3379B-1DCB-412A-B3C3-43252EF6DC0E at microspot.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> > From: "Rod Smallwood" <rodsmallwood at btconnect.com>
> >
> >
> > And we have a winner!!
> >
> >
> > The Manchester computer of 1948 (Built 1946-1948)
> > It could store 1024 bits on a cathode-ray-tube, enough to demonstrate
> the
> > stored-program principle in working electronics, the first in the world
> to
> > do so
> >
> > Built under the direction of Alan Turing and A von Neumann
> > ?
>
>
> No, sorry the ORIGINAL Manchester Baby no longer exists. Fellow members of
> the Computer Conservation Society have built a replica, correct in almost
> every respect but it is only a few years old so does not qualify as oldest
> original working stored program computer. I still would like to make a
> list of the top ten not just the top one.
>
>
>
> ------------------------------
>
> Message: 23
> Date: Fri, 22 Oct 2010 21:11:20 +1100
> From: Simon Fryer <fryers at gmail.com>
> Subject: Re: lilith computer by wikipedia
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID:
> <AANLkTinYKzyw+HKKc3FS9EAFdkrLis0n1NX-KnAO=rcx at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 22/10/2010, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
> >> Yes, and made the mistake of buying one. Couldn't believe it when it
> >> actually arrived. I left an interesting review on Amazon.
> >
> > Do you happen to remember the title (or have a URL) for this? I wonder
> > how the authors of that/those wikipedia articles feel about this? I know
> > I'd be pretty annoyed if somedy did that with something I'd written.
>
> ISBN 10: 1155452186
> ISBN 13: 978-1155452180
> Title: ICL Mainframe Computers: Leo, English Electric Kdf8, Elliott
> 803, Ict 1900, ICL 2900 Series, English Electric Kdf9, Ict 1301
> By: Books LLC
>
> http://www.amazon.co.uk/ICL-Mainframe-Computers-English-
> Electric/dp/1155452186/ref=cm_cr_pr_product_top
>
> >> Only upside, it is in a more convenient format for reading while on the
> >> toilet.
> >
> > And for other uses in that location?
>
> The paper isn't really too soft. It might be okay in an emergency.
>
> Simon
>
> --
> ------------------------------------------------------------------------
> "Well, an engineer is not concerned with the truth; that is left to
> philosophers and theologians: the prime concern of an engineer is
> the utility of the final product."
> Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh
>
>
> ------------------------------
>
> Message: 24
> Date: Fri, 22 Oct 2010 06:27:37 -0700
> From: Al Kossow <aek at bitsavers.org>
> Subject: Re: Test Diablo Model 31 drive and disk pack on a PC
> (Operation Alto Restoration)
> To: cctalk at classiccmp.org
> Message-ID: <4CC19149.5030409 at bitsavers.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/21/10 5:57 PM, Nick Allen wrote:
> > Al and everyone else,
> >
> > I believe Al has had success interfacing a Diablo Model 31 with a PC
> computer
>
> I used a program that runs on the Alto and copies sectors across through a
> PC parallel port.
>
> Could you take pictures of the labels on the packs? I normally supplied a
> couple of them
> with the machines that came from me, and could tell pretty quickly if they
> need to be copied.
>
>
>
>
> ------------------------------
>
> Message: 25
> Date: Fri, 22 Oct 2010 07:07:24 -0700
> From: dwight elvey <dkelvey at hotmail.com>
> Subject: RE: Viper 2150S scsi tape drive
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Message-ID: <SNT129-W644821C0BBBE562CFC5863A35E0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
>
> > From: cclist at sydex.com
> > To: cctalk at classiccmp.org
> > Date: Thu, 21 Oct 2010 21:50:44 -0700
> > Subject: Re: Viper 2150S scsi tape drive
> >
> > On 21 Oct 2010 at 21:37, dwight elvey wrote:
> >
> > > I just got this use drive and I was wondering if it
> > > is working as expected.
> > > When I plug in the tape, the head moves up and down
> > > but the tape drive motor doesn't move.
> > > Is this normal?
> >
> > My recollection of this drive is that the tape should be
> > automatically positioned to BOT when inserted. (i.e., the drive
> > should spin the tape a bit).
> >
> > --Chuck
> >
> >
> Thanks Chuck
> I was afraid of that. That was my recollection
> of similar drives. Now I have to find out why the motor
> doesn't spin.
> As I recalled, if the tape was accidentally loaded
> with the end of tape marker off the spool, it would
> unspool the hole thing and it would then be a 30
> minute job to spool it back on.
> I'll have to look at the motor drive and see what is up.
> The fact that I see the head moving gives me confidence
> that it is most likely the motor drive circuit.
> This is suppose to back up my Sparcbook. As you recall
> my 8mm drive didn't seem to work with it so I thought
> I'd try a drive that was inteneded.
> Dwight
>
> Dwight
>
>
> ------------------------------
>
> Message: 26
> Date: Fri, 22 Oct 2010 10:13:34 -0400
> From: Dave McGuire <mcguire at neurotica.com>
> Subject: Re: Viper 2150S scsi tape drive
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Message-ID: <4CC19C0E.3060509 at neurotica.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/22/10 10:07 AM, dwight elvey wrote:
> > This is suppose to back up my Sparcbook. As you recall
> > my 8mm drive didn't seem to work with it so I thought
> > I'd try a drive that was inteneded.
>
> 8mm drives were sold with early SPARCstations and SPARCservers as
> well, FYI. An 8mm drive will work fine if it's properly set up.
>
> -Dave
>
> --
> Dave McGuire
> Port Charlotte, FL
>
>
> End of cctalk Digest, Vol 86, Issue 46
> **************************************
Last call for items located in Rockville, MD, 20850.
Already taken: CCS S-100 chassis; HP 712; Fluke 8520.
Almost free: $2 (two) dollars per item, local pickup only at
this time, no photos. Offer expires 11/7/10.
1. Digital BA23 floor pedestal enclosure, complete with front +
rear covers. Very decent shape. No yellowing (painted).
2. Digital LA100 Letterprinter w/ ribbons. Tested working.
Has age yellowing (barely perceptible) but no heavy yellowing
(eg. from UV light).
3. Digital LA75 Plus Companion Printer (LA75S-A2) w/ parallel +
MMJ. Professionally refurbished and assumed working (but
untested). Clean and nice cosmetic shape. No yellowing.
4. Wyse 60 RS232C terminal with keyboard and spare analog
board. Terminal unit is in excellent shape all around, as is
spare analog board. Keyboard was taken apart and thoroughly
cleaned -- it works but 3 of the keycaps broke when it slid off
my desk. No yellowing on any of the components.
My handle on ebay is MdntTrain if anyone wishes to verify my
reputation. Email me if interested in any or all. I will
select who the items go to.
Thank you,
John Singleton
js at cimmeri.com
> From: "Rod Smallwood" <rodsmallwood at btconnect.com>
>
>
> And we have a winner!!
>
>
> The Manchester computer of 1948 (Built 1946-1948)
> It could store 1024 bits on a cathode-ray-tube, enough to demonstrate the
> stored-program principle in working electronics, the first in the world to
> do so
>
> Built under the direction of Alan Turing and A von Neumann
> ?
No, sorry the ORIGINAL Manchester Baby no longer exists. Fellow members of the Computer Conservation Society have built a replica, correct in almost every respect but it is only a few years old so does not qualify as oldest original working stored program computer. I still would like to make a list of the top ten not just the top one.
> From: Christian Corti <cc at informatik.uni-stuttgart.de>
>
> On Sat, 16 Oct 2010, Roger Holmes wrote:
>> don't believe its true, I was told my machine is currently the oldest
>> original working computer. Not counting replicas or machines which don't
>> have stored programs. My machine was installed in 1962 (and designed in
>> the late 1950s).
>
> Then you've been told wrong.
> Several examples:
> - Our LGP-30 ser.no. 4, built 1958, still working with peripherals. Just
> yesterday I've had a group of visitors. It's been designed around 1954.
> - The IBM 650 of the IBM Museum in Sindelfingen (working)
> - The Zuse Z22 ser.no. 13 in Karlsruhe, also built around 1958 (apparently
> still working, although the ZKM is not the right place for it IMHO)
> All are original first generation machines, and all of them are in
> southern Germany.
>
>> restored was first installed in 1964. Are there other? I'm not counting
>> the Zuse in Germany as its not a stored program machine, and anyway I'm
>> not sure if it is a replica or the original. It is surprising if it
>> survived the extensive bombing by the USAF and RAF during WW2 unless it
>> was stored in a bunker/cave/mine.
>
> What Zuse are you talking about? The Z3 has been destroyed, yes, and
> rebuilt by Zuse in 1962.
Thank you, this is just the information I wanted.
Is the Z3 stored program? Turing complete?
If it is, then it would be useful to know when the rebuilt version became operational, though I'm not actually sure the actual month my machine went live either.
Assuming for now that Z3 is not stored program, than my list so far is:
1958, LGP-30
1958, Zuse Z22
Somewhere between 1954 and 1962, IBM 650
1962 ICT 1301 serial no 6 (SO FAR the earliest surviving machine with random access program and data storage. i.e. Core and called Immediate Access Store by ICT).
Thanks again.
I expect the chaps in the states will tell me of several more when I catch up with my e-mails.
Date: Thu, 21 Oct 2010 11:03:54 -0700
From: Al Kossow <aek at bitsavers.org>
Subject: Re: Oldest original proper computer (stored program etc)
To: cctalk at classiccmp.org
Message-ID: <4CC0808A.8010108 at bitsavers.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/21/10 10:03 AM, Chuck Guzis wrote:
>> For example, the GI GIMINI (CP1600)
> That would be fun to find. There was a version that I used in the late
> 70's that had a DSD floppy disk interfaced to it. I think I still have
> all of the software for it.
----
And I've got some brochures and datasheets for the GIC8000 and GIMINI and
the various cards and chips in them, so all we need is the computer ;-)
mike
Something that's fun reading, in spite of the redactions is the 1986
National Security report on "General and Special-Purpose Computers: a
Historical Look and Some Lessons Learned":
http://tinyurl.com/2dt5egq (PDF)
--Chuck
Mr 1519 approval rating bid $30,100 as a snipe. At least it wasn't a
0 feedback ID that did it.
Things really took of in the last 5 minutes with the winning bidder
having a true snipe.
Anyone on the list the winner?
The other Alto thread is useless, nothing about Alto's so starting a new
thread here about this sale, also on topic to discuss what happened to
the short lived auction for the alto from DC. Was that one fraud, or
stupidity?
In advance change the thread title if you hijack it, please.
Jim
Couple updates and requests for help.
Got the CRT repaired and WORKING! The culprit was the 100k sliding pot
control on the underside of the CRT. Now that I have a working CRT, it
is on to the next step of diagnosing in which I need advice.
I noticed the cursor is a hardware cursor, does this mean if I get the
display board working (and if only the display card is working) will it
output the cursor to the CRT? If so, this is great news as I can focus
on repairing a single board. If not, do you know which boards I need to
get working at a MINIMUM to get ANY display on the CRT (either the
hardware cursor, or some sort of diagnostic boot code to output to the CRT)?
Thanks!
Nick
> Date: Wed, 20 Oct 2010 14:43:53 +1300
> From: "Terry Stewart" <terry at webweavers.co.nz>
> Subject: Introduction - Terry Stewart (tezza)
>
> Hi,
>
> I joined a few days ago and feel I should introduce myself to others on
> this
> list. Some here may know me as tezza on Eric Klein's Vintage Computer
> Forums, a handle I also use on a few other vintage computer places around
> the Net.
...
> Terry Stewart (Tez)
> http://www.classic-computers.org.nz
-------------------
Nice to see you made it; see, all you had to do was ask ;-)
Enjoy,
mike
Date: Thu, 21 Oct 2010 09:17:36 -0500
From: "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>
Subject: Re: Semi-OT: Texas Instruments calculator battery packs?
I just looked at my TI Programmer - how on earth do you even get into
the BP-8? The flex tabs that hold it together won't budge, and I'm not
interested in breaking them.
If I could get into it, I'd like to rebuild the battery pack.
Mike
----------------
Not to start one of our flamefests over here, but it should be pretty
straightforward; gently pry out the short 3 finger side with something wide
enough to catch the whole width, and it will just tilt open. Hope your
batteries aren't too corroded.
I've replaced mine several times, as well as another TI calc using a similar
pack.
I _might_ even have an inverter module for the OP; still looking.
mike
Date: Thu, 21 Oct 2010 09:17:36 -0500
From: "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>
Subject: Re: Semi-OT: Texas Instruments calculator battery packs?
I just looked at my TI Programmer - how on earth do you even get into
the BP-8? The flex tabs that hold it together won't budge, and I'm not
interested in breaking them.
If I could get into it, I'd like to rebuild the battery pack.
Mike
----------------
Not to start one of our flamefests over here, but it should be pretty
straightforward; gently pry out the short 3 finger side with something wide
enough to catch the whole width, and it will just tilt open.
I've replaced mine several times, as well as another TI calc using the same
pack; hope your batteries aren't too corroded.
I _might_ even have an inverter module for the OP; still looking.
mike
> From: William Donzelli <wdonzelli at gmail.com>
>
>> I am not interested in machines which have not been powered up for more than a year, even if they were operational when stored, the likelihood of them working when turned on again is low. Expansion and contraction, static electricity, chemical reactions especially in old electrolytic capacitors take their toll. Computers were built to be used, one which cannot be operated is no more interest to me than the hull of an old ship.
>
> Interesting you mention hulls of old ships and oldest operating
> computers. It is likely that any list of "oldest operating computers"
> would probably be dominated by special purpose digital* computers
> (fire control, navigation, crypto, etc.) on ex-US and Soviet warships
> serving in third world navies. Even in the backwaters of the US Navy
> there are still some ancient machines still going.
I have a mental picture of a mercury delay being rocked back and forth by the motion of a battleship :-)
Certainly mechanical analogue computers were common in fire control, and must have got replaced by something more modern, but I would restrict the list to stored program machines. Nickel delay lines were likely used and drums used directly for executing code would of course work on a ship too. Williams tubes maybe, and the earliest core memory machine would have been military too.
> Military computing tends to be 800 pound gorilla in the room that
> historians tend to dismiss.
Maybe because they are excluded by secrecy, as happened with the UK's WW2 German code breaking machines until the story got out and Bletchley Park was saved.
In my first job I came across several military computers, but they were for use in aircraft and so much less heavy. I worked on the Mk2 Nimrod, based on the Comet, and I've heard tell that in its first incarnation it was bright aluminium because if they painted it the weight of the paint would have stopped it from becoming airborne.
> * The submarines of Taiwan still use the Mk IV Torpedo Data Computers
> (mechanical analog), installed when the boats were still US during
> World War 2.
Interesting, but not a stored program computer.
-----Original Message-----
Date: Thursday, October 21, 2010 1:13:29 pm
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
From: "William Donzelli" <wdonzelli at gmail.com>
Subject: Re: HTL
> You'd use the same precautions, in-circuit or out, that you'd use
> with any bipolar logic chip, be it HTL, DTL, RTL or TTL. ?No special
> precautions or lack thereof because it's HTL.
Being bipolar does not mean ESD safe. ECL is somewhat static
sensitive. Also, with HTL being such an old family, I am unsure as to
its sensitivity. DTL and TTL have become more static insensitive over
time with die revisions and better processes. Did HTL, always a
low-runner, go through this process?
There's different levels of ESD protection for handling components. Whether your just storing parts for a hobby, development lab or a full production facility.
A simple static wrist strap can avoid any confusion in many situations and should be in your pocket whenever handling components, boards, etc. And if your in the sticks somewhere, without a proper grounding station, you should at least be prepared with a static bag stuffed in your toolbox to cover the cards when handling a rack full of cards. Never touch with bare hands as taught in ESD class.
You know the old adage being, don't leave home without it :)
Does anyone know where I can find a BP-8 battery pack for my TI
Programmer (calculator) that I've owned since the early 80's? It
has a small dc-dc converter and two AA nicads inside, supplying 9
volts to the snap-on connector. The board is corroded beyond
salvaging by badly leaked nicads :(
It will run on a 9 volt battery too (max drain with all digits on
is 44 ma according to this interesting German site):
http://www.christophlorenz.de/calc/ti/programmer.php?l=en
and I suppose I could just put one inside the plastic housing of
the BP-8 which of course would not be rechargeable.
I also need a pack for my otherwise clean SR-51A, a BP-1A. This
would be trivial to repair except that it's completely missing and
I have no idea where it went!
thanks
Charles
Hi
I was looking for the picture of the IBM 7010 - is it still available?
I think I used to program on this back in the late sixties at Chevrolet.
Thanks
Trina
I have a small Sequent SCSI cabinet with a 8mm tape drive in it -
untested. Any Sequent fans need this before I send it to the grinder?
It is a typical single full high SCSI box with power supply.
Cheap!
--
Will, in 10512
I haven't flogged this here in a long time, so my apologies in advance:
A new version of mTCP is available at http://www.brutman.com/mTCP .
mTCP is a collection of TCP/IP applications with the TCP/IP code built
into each application. The applications include a DHCP client, FTP
client, IRC client, Telnet client, SNTP (Simple NTP) client, Telnet,
Ping and Netcat. Static networking setup is available if you are not
inclined to use DHCP.
Requirements are a PC, clone, PCjr or whatever you have, somewhere
around 192KB of free memory, and a network device with a packet driver.
I use 'device' loosely here - this includes SLIP, PPP, Ethernet cards,
and Ethernet adapters hanging off of parallel ports. The code runs well
in DOSBox and virtual machines if you are so inclined.
Features of the stack include:
- ARP, TCP and UDP
- Automatic detection and retransmission of lost packets
- Support for multiple open sockets
- Listen/accept support for server style applications
- DNS resolving
- Zero window support
- IP fragment reassembly
The goal is to make this open source some day. Until then, you just
have to enjoy the compiled binaries. I started out with Turbo C++ 3.0
about five years ago, and recently switched to Open Watcom. IP fragment
support is the newest addition to the code.
Enjoy,
Mike
> (I often think that the downside of ebay is that an item goes to the person > with the deepest pockets, and they're not necessarily the best person to treat > an item nicely)
So eBay is precisely like every other market on the planet.
Shocking. <rolls eyes>
On 10/20/10, Vincent Slyngstad <vrs at msn.com> wrote:
> From: "Ethan Dicks": Wednesday, October 20, 2010 8:14 AM
>> On 10/20/10, Vincent Slyngstad <vrs at msn.com> wrote:
>>> Hmm. I might choose the 8/L for something like that. Possibly soup
>>> up the memory to 32K, but leave out all the option cruft of the 8/I
>>> backplane.
>>
>> And replace the 7453 and 7482 with something made with less unobtanium?
>
> Sure. We've talked about how to do that before, I think. You'd face that
> problem starting from either the 8/I or the 8/L.
Yes, but I thought it worth keeping in play.
>> The memory extension hardware to take it over 4K is obviously
>> non-trivial in size (especially considering it doesn't fit in an -8/L
>> CPU enclosure).
>
> Good point. You would definitely need some board area for that.
Considering how much of the -8/i backplane it takes up (about 1/2 as
much as the EAE), it's a noticable chunk.
>> OTOH, if you have over 32K
(*have over 4K)
>> there might as well be provisions for OS/8-compatible mass
>> storage, otherwise it's just a papertape machine with more than 4K.
>
> True, though an RF08 emulation doesn't take much board space.
Nope. That takes about 3"x5" in TTL (with a 16-bit Dallas RAM/battery
module), IIRC.
> Or one could go with an RX08 interface for extra clanking ambiance :-).
While amusing and handy for some (I would use it), unless someone
whips up a cable-compatible RX01/RX02 emulator (could be to floppy or
removable FLASH), there are only so many original drive sets running
around. Of course, one could build that RX01 emulator and include an
optional Arduino-based MP3 player to emit the whirring and clanking.
Frivolous but entertaining.
-ethan
Once, after doing something stupid (I'm not sayin'), I had a killed Alto on
my hands. To find the bug, I put a Biomation logic analyzer on the
backplane microcode address bits. Using a listing of the microcode I was
able to figure out which task was running when and that pointed out the loop
in the microcode. I was then able to work backward from the task logic to
figure the bug.
This is made possible because the Alto backplane was wirewrapped, which
meant that the signals are available for easy probing (and logic analyzer
pins).
Once upon a time I used to say "What I wouldn't give to have an Alto
again". Now, I know it's not $30,100.
>?I
> believe that preserving classic computers is VERY different from
> preserving many other types of collectibles.
For those of us that have been around from the very beginnings of the
computer collecting (which seems to be perhaps 1990 or so), or better
for those of use that have been around from before anyone gave a damn,
we see that it has grown up almost perfectly in line with how every
other branch of the antique and collectible trade has.
1) A few see potential in some unrealized common items.
2) Very loose communities form, and collection form.
3) Snowball effect of more people see the potential and interest grows.
4) Prices and values start forming, due to supply and demand.
Meanwhile, the good stuff starts getting scarce,
5) Markets grow, prices stabilize. The high end gets very high, and
the low end gets worthless.
You name the antique, and it will fit this story. Oddly enough, Ebay
probably has not changed the story much.
--
Will
Does anyone have the ECO history of the pdp-8/i available? I am looking at
http://www.bitsavers.org/pdf/dec/pdp8/pdp8i/PDP8-I_CPU_blueprints_1969.pdf.
On sheet d-bs-8i-0-6 there's a gate added at D6 in the drawing, probably in
ECO #13, #25, or #50. It uses the M113 at F32N2 to invert something called
"IO PC LOAD", and connects to a previously tied high input of the 4-input
NAND at E32E2 (which calculates "PC LOAD").
The problem is, nothing anywhere in the drawings appears to generate a
signal
called "IO PC LOAD".
I don't imagine anyone knows off the top of their head what this signal is,
how it
is generated. A look at the ECO history should help explain when this was
added
and why, though.
Also, if anyone knows of an I/O device or option for the 8/i that would load
a new
value into the PC, that might give some clues where to look.
Thanks in advance,
Vince
(I am making excellent headway on a project which translate the 8/i
schematics,
including all the options, into Verilog for an FPGA, but I currently have
this signal
tied to an input pin for lack of any information about it.)
--
o< The ASCII Ribbon Campaign Against HTML Email!
I have looked it up again and what I was referring to was CSIRAC, in Melbourne.
>
> Is your 1301 older than TNMoC's Elliot 803? I'm pretty sure that's 1962, too,
> but I'm not sure which month...
The 803 is another project of the Computer Conservation Society and the chap who told me my machine was the oldest (Rod Brown) had just come back from a committee meeting of the CCS, so I presume they think mine is older but I would not like to argue that point, I was only nine years old myself in 1962. I know my 1301 was installed in time for program development to be finalised before it went live to handle the University of London's undergraduate matriculation in 1962. The reason the University got a prototype machine was that they threatened to tell the world there would not be any new undergraduates in 1962 and that a company called ICT was responsible. A machine destined for internal software development was quickly diverted to the university. Every few weeks a team of engineers would take over the machine for few hours and implement the changes made to all the other six prototypes at GEC telephones Coventry and ICT Putney and maybe elsewhere too.
I am not interested in machines which have not been powered up for more than a year, even if they were operational when stored, the likelihood of them working when turned on again is low. Expansion and contraction, static electricity, chemical reactions especially in old electrolytic capacitors take their toll. Computers were built to be used, one which cannot be operated is no more interest to me than the hull of an old ship. I love the wonder of small children when they see how big, heavy, noisy and yes, smelly old computers used to be than the modern things they are used to. I love getting them to type their name on a Teletype, feeding the tape into the computer and have it print their name in legible tape (aka ClearWrite). Later on I hope to have it print their name on the 600lpm line printer, maybe in some fancy way with big letters made of lots of small letters or some such. Next year I might make it punch a legible card as that now works once more.
Thanks for your thoughts.
Roger.
As many of you have already know, I've cancelled the new run of P112s and
am in the process of issuing refunds to all who put money down. This
takes a while. The good news is that Professor Feedlebom recently
discovered at least six populated boards left over from the last run. Our
intent is to gather the leftover parts from the last run and assemble kit
bags. They will be offered to those who placed preorders in chronological
order -- one kit per customer -- until people on that list have had a
shot.
I'll know more about how many kits will be available when Feedle takes a
trip to his storage unit on Thursday
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
I'm in the midst of chipping away at "The Pile" and offer the following to the list prior to supporting Witman's campaign or skipping them:
Two PROM programmers: US$ 10 each + shipping -
See: <http://elipsoid.home.comcast.net/~elipsoid/PROMPrgmrs/index.html>
Data I/O Model 20B MOS Memory Programmer. I have no info on the beast, but appears to program the following:
2704 2732 764N
2708 732A 2764
2716 7320 8741
2508 7321 8748
2516 8764 8749
4816 2564 8755
2532
SPI Model 8407. PROMs are listed on the pull-out card pictured. Again no info available.
I also have five bundles of ~300 14-pin ceramic ICs that test out as 5400/7400 TTL. Assume that they are 5400s since they came from a Hughes Aircrash auction many years ago. Available for postage.
Shipping from 85704 - USA
CRC