>
>Subject: Re: NEXTstep web browsers
> From: "Witchy" <witchy at binarydinosaurs.co.uk>
> Date: Thu, 16 Jun 2005 00:40:47 +0100 (BST)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>
>>>for such a modern browser.
>>
>> How slow is it? I Happen to run firefox on a P166 and also run it on
>> a P100 and its ok, slow to start but then fine.
>
>The slab contains a 25mhz 68040 and mine has a staggering 8mb of RAM. I
>think I'm asking too much of it :)
That still has to be better than my first 386/16 machine with 4mb running
Win3.1 and Netscape!
>I'm working on the last versions of OmniWeb but they require me to install
>many things from CD which I'm not about to do at half midnight since I've
>got to be up in 5 or 6 hours......curse this 'work' thing - why can't we
>be paid handsomely for preserving ye olde silicon of yore?!
That would be fine with me. Then again my last job was exactly that,
keeping 20 desktops (fastest was P166) happy.
Allison
Due to the size of these and lack of interest on my part, I have two
Xerox 6085 computers and some associated bits in need of a new home.
http://tinyurl.com/ccm3j has some pictures of this stuff
Since these are fairly heavy, they will be pickup only from 48821 (near
Lansing, Michigan).
Best offer or trade. Most interesting trades to me right now would be
IA64 or PPC gear, but I'm open to other things.
A fair bit more detailed description of what I have follows.
CPUs:
Xerox 6085
Hard drive is labelled as "XPIW 2.0"
Cards:
P/N 140K05980: LPO (printer port) >--- a half-height card
140K05560: IOP (ethernet, floppy, keyboard, serial comm, serial
printer)
140K04160: MBP (bus extender port)
140K01000: MEB (no ports on this card, extra memory perhaps?)
140K00460: DCM (display port)
Xerox 6085
Hard drive labelled as "Viewpoint 2.0"
Cards:
P/N 140K05550: PCE (PC emulator card?) \____ these are half-height
140K05980: LPO (printer port) / cards that share a slot
140K24340: IOP-2 (ethernet, floppy, keyboard, comm, printer)
140K24590: MBP-2 (no ports on this card)
<blank slot>
140K24580: DCM-2 (display port)
Other hardware:
2 Xerox mouse pads
2 mice
1 keyboard
2 floppy enclosures (one with a drive in it, one with just air)
1 extra hard drive tray (from browsing the docs, it looks like you
need an ST412/ST506 if you want to replace
a drive)
These computers do not come with monitors. I do not know if it is
possible to easily cook something up to connect standard monitors to
them.
Documentation:
1 Training and Reference: Xerox Viewpoint
2 packets of loose documentation
1 MS-DOS User's Guide for the 6085
2 Workstation Equipment and Installation
1 Xerox Viewpoint 1.1 GW BASIC by Microsoft
1 Reference: Document Editor
Media:
VP font disks (around 20 disks)
VP Spellchecker 1.1
VP Terminal Emulation of DEC VT100 1.0
VP NetCom 1.1.2 common software
VP NetCom 1.1 network install scripts
VP PC Emulation 1.1.7
6085 Xerox Viewpoint 1.1.7 (Basic Workstation #1)
Xerox PC Emulation Utilities VP 1.1.7
Xerox MS DOS 3.10
Xerox GW Basic 3.10
VP Document Editor 1.1.2 (disks 1-3)
VP Local Laser Printing 1.1
VP File Conversion of ASCII documents 1.1
VP File Conversion of Wordstar Documents 1.1
6085 VP Long Document Options
VP File Conversion of 860 Documents 1.1
VP Data-Driven Graphics (Bar, Pie, Line) 1.1
VP Local Draft Printing 1.0.1
VP RemoteCom 1.1.2 (disks 1 and 2)
-Ryan
>
>Subject: Re: PDP11/23 - prompt?
> From: Pete Turnbull <pete at dunnington.u-net.com>
> Date: Wed, 15 Jun 2005 21:53:41 +0100 (BST)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Jun 15 2005, 19:25, Philipp Hachtmann wrote:
>
>> If it is possible that I don't have the original bootstrap - can
>anyone
>> send it to me via email?
>
>You may have the original, but if so it's disabled. "two eproms with
>green labels and nothing written on them" is unlike any originals I've
>seen :-) If you do want originals, go to
> http://www.dunnington.u-net.com/public/DECROMs/ and download 23-339E2
> and 23-340E2.
>
>> > You need to carefully inventory your boards and determine what you
>> > have.
>>
>> I have:
>> - CPU (M8189)
>> - RAM (M8067), 128k*18?
>> - RAM (8059), same size?
>> - Floppy controller M8029
>> - Emulex SC02/C RK06/07 compatible SMD disk controller (for my Ampex
>> hard drive)
>> - 2 * M8043 (4 serial ports)
>> - 1 unknown Plessey interface card, P/No. 701775 (What's that ?)
>
>I can't find the Plessey list I'd bookmarked so I can't say what that
>is :-(
>
>However, that SC02/C accounts for the "$" boot prompt, and either the
>EPROMs on the KDF11 are disabled or have been replaced in order to
>support the SC02. DEC didn't support RK06/7 on QBus so none of the
>standard bootstrap ROMs support it. The SC02 has its own, however,
>although it's very simple, and that's what you're seeing. It will
>expect a simple two-letter mnemonic (DM for your emulated RK system)
>with an optional unit number (eg "DM", "DM0", or "DM1").
>
>Interesting number of serial lines on there. 8 on the DLV11-Js, and
>two on the CPU (one of which is the console, as you've clearly
>discovered). I'd guess this used to run RSX-11M.
Or uRSTS or RT11/TSX, or even RT11 and did data collection.
Allison
>
>Subject: RE: PDP 11/23 PLUS system for sale
> From: Paul Koning <pkoning at equallogic.com>
> Date: Wed, 15 Jun 2005 16:02:43 -0400
> To: cctalk at classiccmp.org
>
>>>>>> "Allison" == Allison <ajp166 at bellatlantic.net> writes:
>
> >>> From what I remember (very blurry now) DEQNAs were known to
> >>> corrupt
> >> data. That was very obvious on VAXclusters, which is why VMS
> >> eventually took them off the supported device list permanently.
> >> But it's an issue for any application (except, *maybe*, when
> >> running TCP since the TCP layer checksum may help -- or may not,
> >> it's not that strong...). That applies just as much for PDP11s.
> >>
> >> paul
>
> Allison> No they _could_ corrupt data, not they did all the time.
> Allison> The differnce was the error rate was not what DEC wanted for
> Allison> transactions. The VAX people put pressure to not have to
> Allison> test the data as LAVCs (Local Area VAX Clusters) were
> Allison> popular to a point and required a very high level of data
> Allison> (code!) integrety. The frequency of the failure was related
> Allison> to the traffic level on the local loop.
>
>"pressure not to have to test the data" -- hm. That's an interesting
>way of looking at. The way I would look at it is that ALL DEC network
>protocols put the responsibility for data integrity in the network
>devices; NONE of them had upper layer checksums the way TCP does.
>That's why DEC Ethernet bridges always had end to end CRC. And that's
>why DEC insisted on 32 bit CRC for Ethernet -- 16 bit CRC isn't good
>enough at those data rates. The expectation (and probably the
>expressly stated requirement, though I don't remember for sure) is
>that Ethernet NIC devices were required to deliver that level of data
>integrity to the host.
>
>So in fact the QNA was failing to deliver the data integrity that
>everyone expect it to deliver. The VAXcluster people were the most
>vocal and had the most pull, so they were the ones who actually had
>the power to say "we will not accept that device". But plenty of
>other people cheered when that happened. Certainly the network
>architecture group, responsible for standards, did.
>
That's about the story. One little bit was that doing a checksum
was really a CRC and the code to do that apparently was slow on uVAX.
They didn't want the impact of that in the OS driver when hardware
could do it far faster.
Allison
Hi Sellam - I've emailed a friend of mine who is not on this list who
used to work for TI as one of their Service Managers - he thinks he can
help - I've given him your email address.
++++++++++
Kevin Parker
Web Services Consultant
WorkCover Corporation
p: 08 8233 2548
m: 0418 806 166
e: kparker at workcover.com
w: www.workcover.com
++++++++++
-----Original Message-----
From: cctech-bounces at classiccmp.org
[mailto:cctech-bounces at classiccmp.org] On Behalf Of Vintage Computer
Festival
Sent: Wednesday, 15 June 2005 8:04 AM
To: Classic Computers Mailing List; Classic Computers Mailing List
Subject: New Bounties: TI Personal Consultant Plus and M1 Expert Shell
($$$)
I am currently seeking the following software for a client:
Texas Instruments Personal Consultant Plus (tm) expert shell (circa
1987).
M1 Expert Shell (circa late 1980s).
Both of these expert systems are PC-based.
If you have either of these, please contact me privately. This is a
bounty so there's a cash reward!
Thanks!
--
Sellam Ismail Vintage Computer
Festival
------------------------------------------------------------------------
------
International Man of Intrigue and Danger
http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage
Computers ]
[ and academia at www.VintageTech.com || at
http://marketplace.vintage.org ]
************************************************************************
This e-mail is intended for the use of the addressee only. It may
contain information that is protected by legislated confidentiality
and/or is legally privileged. If you are not the intended recipient you
are prohibited from disseminating, distributing or copying this e-mail.
Any opinion expressed in this e-mail may not necessarily be that of the
WorkCover Corporation of South Australia. Although precautions have
been taken, the sender cannot warrant that this e-mail or any files
transmitted with it are free of viruses or any other defect.
If you have received this e-mail in error, please notify the sender
immediately by return e-mail and destroy the original e-mail and any
copies.
************************************************************************
On Jun 15 2005, 19:25, Philipp Hachtmann wrote:
> If it is possible that I don't have the original bootstrap - can
anyone
> send it to me via email?
You may have the original, but if so it's disabled. "two eproms with
green labels and nothing written on them" is unlike any originals I've
seen :-) If you do want originals, go to
http://www.dunnington.u-net.com/public/DECROMs/ and download 23-339E2
and 23-340E2.
> > You need to carefully inventory your boards and determine what you
> > have.
>
> I have:
> - CPU (M8189)
> - RAM (M8067), 128k*18?
> - RAM (8059), same size?
> - Floppy controller M8029
> - Emulex SC02/C RK06/07 compatible SMD disk controller (for my Ampex
> hard drive)
> - 2 * M8043 (4 serial ports)
> - 1 unknown Plessey interface card, P/No. 701775 (What's that ?)
I can't find the Plessey list I'd bookmarked so I can't say what that
is :-(
However, that SC02/C accounts for the "$" boot prompt, and either the
EPROMs on the KDF11 are disabled or have been replaced in order to
support the SC02. DEC didn't support RK06/7 on QBus so none of the
standard bootstrap ROMs support it. The SC02 has its own, however,
although it's very simple, and that's what you're seeing. It will
expect a simple two-letter mnemonic (DM for your emulated RK system)
with an optional unit number (eg "DM", "DM0", or "DM1").
Interesting number of serial lines on there. 8 on the DLV11-Js, and
two on the CPU (one of which is the console, as you've clearly
discovered). I'd guess this used to run RSX-11M.
--
Pete Peter Turnbull
Network Manager
University of York
>
>Subject: Re: PDP 11/23 PLUS system for sale
> From: Ethan Dicks <ethan.dicks at gmail.com>
> Date: Wed, 15 Jun 2005 14:56:28 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 6/15/05, Allison <ajp166 at bellatlantic.net> wrote:
>> No they _could_ corrupt data, not they did all the time...
>> The frequency of the failure was related to the traffic level on the local loop.
>
>So then, in the modern era, putting a DEQNA on its own switch port
>(i.e. - a tiny collision domain) should increase data reliability?
Wouldn't hurt.
I have a few Qbus boxen here only one has a DELQA, the rest are DEQNAs
most rev-E and a few rev-J. They work. I've run a LAVC under VMS5.4
using them along with a few 3100s and nothing ever spit up or died.
Would I rather a DELQA, yes, but I'd not refuse a working DEQNA.
Allison
Patrick Finnegan <pat at computer-refuge.org> wrote:
> Uhh, registry? Yeah, right.
Well, the International Standard document clearly calls for one. It
says "a register to be established", though, and I guess that has never
been done.
> You can start your own registry, I guess.
I'm willing. But then I would need ISO to appoint me as the registrar.
Hmm, maybe I should give this a serious thought. Any idea whom to
approach? After all, the standard calls for a registry and one does not
exist. Similarly to how ISO had appointed ECMA as the registrar for ISO
2022 escape sequences (now it's some other organisation in Japan), IFCTF
could maintain the registry for DA codes.
> If there was one, it was at
> DEC and only held the codes used by terminals that DEC produced.
All DEC DA responses have the 3/15 private marker after the CSI,
indicating that all following parameters are private and have no global
significance.
ISO clearly intended, on the other hand, to have a global registry. If
you have a code assigned from the global registry, you can send it in
responses without a private marker. No one else can then legitimately
return the same response, and anyone receiving that response would have
every right to assume it's your product.
Private parameters (what DEC used) do not guarantee interoperability:
vendor A can define ?1 to identify one of its products, but another vendor B
would have every right to define ?1 to identify one of *its* products.
> You do realize, there were terminals that weren't VT100 compatible (at
> least in their native mode), like Wyse 50/60 terminals, ADM 3/5s, IBM
> 3151s, Televideo 925s, ... They didn't do the "CSI c" command; they
> might have had a "DA" method, but I'm doubtful it was the same as what
> DEC did.
DA (CSI c) is not a DECism, it's a feature of the International Standard
ISO 6429. Yes, of course there are terminals that don't care about ISO 6429
and implement their own completely different escape/control/whatever
sequences, but they are not relevant to this discussion. I'm talking about
the standard mechanism for identifying a particular implementation of ISO
6429 among all others in the Universe.
> Any reason you don't want to use the (so-called) "ANSI" vt-100 type
> sequences or those from, say, a vt525, for your 'termainal application'?
The product I'm designing follows ISO 6429, which is the successor to
ANSI X3.64 that you are referring to. VT100 is one implementation of
the standard, mine will be another. DEC is one manufacturer, HEC is
another.
My implementation of the standard will be very close to DEC's, but not
identical. I'm deliberately not writing an exact VTxxx emulator since
I want to do a few things differently. The main area of difference is
character set handling. I have made a proper implementation of ISO 2022,
whereas DEC has made some horrible kludges apparently to make it "user-
friendly" in their perverted sense. I'm talking about the horrible mess
with multinational vs. national modes, keyboard variants and typewriter
vs. data processing keys, kludges that have no place in an ISO 2022
terminal.
MS