Another VCF is upon us ...
VCF PNW 2019 takes place March 23rd and 24th at Living
Computers:Museum+Labs in Seattle. We have 30 exhibits (up from 20 last
year) and six speakers, including Joe Decuir, IEEE Fellow. Our exhibits
include:
Josh Dersch with Three Rivers PERQ workstations
David Cooper with a VAX cluster
Vince Slyngstad demonstrating PDP-8 reapirs
Foone Turing with his collection of floppy and optical disks
Joerg Hoppe with BlinkenBone and UniBone (w/ Josh)
Oscar Vermuelen with his replicas of the PDP-8, 11, and LGP-30
Ian Finder, over-achieving with two exhibits and helping on third
Alan Perry with his SPARC clones
Some rif-raff with their 8 bit home machines. ;-0
Admission is free once you pay to get into the museum. And of course the
museum is worth checking out even without us, but we are going to make it
that much better.
We'll have a consignment room if you want to do some treasure hunting. (If
you are looking to sell some treasure, that works too - you don't have to
participate in the event to use the consignment room.)
Full details can be found at http://vcfed.org/vcf-pnw/ . Or email me
directly if you have questions.
-Mike
Today's tape recovery gem. UBC's PDP-11 UNIX tools distribution ca. 1983 which includes UBC BASIC and their RT-11
emulation. It has a couple of bad blocks, but I couldn't find another copy of this anywhere.
http://bitsavers.org/bits/UBC/
If anyone has a complete copy, it would be good to replace it, but most is better than none of it.
For your interest:
MARCH 8, 2019 ? KansasFest 2019, the 31st annual Apple II convention, is scheduled for July 16 ? 21 in Kansas City, Missouri. Mark Pelczarski of Penguin Software, well-known for numerous graphics utilities, books, and games, will join us with a keynote presentation to celebrate the Apple II.
Pelczarski began publishing graphics-related Apple II software in 1978 while in his early 20?s under the brands Penguin Software and Polarware <http://graphicsmagician.com/polarware/index.htm>. He is an entrepreneur, author, programmer, consultant, and professional educator. Mark is well known for the Graphics Magician <http://graphicsmagician.com/polarware/graphics.htm> software, a toolkit for creating graphics that includes over 50 major software publishers as customers including Random House, Sierra Online, Spinnaker, and Mattel. He wrote monthly columns for Softalk and the book Graphically Speaking. Besides pioneering computer graphics, Polarware published numerous games including Transylvania <http://graphicsmagician.com/polarware/adventures.htm>, The Coveted Mirror <http://graphicsmagician.com/polarware/adventures.htm>, and Spy?s Demise <http://graphicsmagician.com/polarware/arcade.htm>. After leaving Polarware in 1987, Mark turned his attention to computer music and to online courses. Mark once said ?I like to make computers do things,? <https://www.chicagotribune.com/news/ct-xpm-1985-03-01-8501120306-story.html> so he?ll surely fit in at KansasFest.
KansasFest is an annual convention offering Apple II users and retrocomputing enthusiasts the opportunity to engage in beginner and technical sessions, programming contests, exhibition halls, and camaraderie. KansasFest was originally hosted by Resource Central and has been brought to you by the KFest committee since 1995. Any and all Apple II users, fans, and friends are invited to attend this year's event. Registration details will be announced on the KansasFest Web site, and registration will open on March 31. For photos, videos, and presentations from past KansasFests, please visit the event's official Website <http://www.kansasfest.org/>.
CONTACT:
KansasFest 2019
http://www.kansasfest.org/
<http://www.kansasfest.org/>http://twitter.com/kansasfest/ <http://twitter.com/kansasfest/>
https://www.facebook.com/events/2286816188228271/ <https://www.facebook.com/events/2286816188228271/>
--------------------------------------------------------------
Steven Weyhrich <IX0YE>?<
I recovered several pieces of Unix media ? all of which I think made it into TUHS/PUPS collection - at UBC in the mid-1990?s while I was working at TRIUMF.
Those Unix disks and tapes came from a SERF sale (Surplus Equipment Recycling Facility) on UBC main campus, not from TRIUMF. Bill Webb was a common thread for Unix use in the biology department at UBC.
TRIUMF extensively used Data General Nova, then Eclipse (both 16 and 32 bit), computers from opening through the 1990?s for both cyclotron control systems and data acquisition for experiments. They also had a fair number of PDP-11?s and VAXen running RSX-11, RT-11, and VMS. I myself had an Alpha workstation on my desk for the two users I was at TRIUMF.
One of my favorite connections between TRIUMF and UBC, was the underground pneumatic tube used to rapidly carry short lived isotopes produced in the cyclotron to the main campus for biology and medical uses. It should not come as a surprise to anyone that I still work in moving things and people through underground tunnels ?
Tim N3QE
We interviewed TRS-80 designer Steve Leininger on the latest TRS-80 Trash Talk podcast.
http://www.trs80trashtalk.com <http://www.trs80trashtalk.com/>
Although he does not have the same recognition, Steve?s contribution to the history of personal computing is on par with Steve Wozniak (Apple I/II) at Apple and Check Peddle (PET 2001) at Commodore.
Classic Computer Fans,
I posted this to the IBM-Legacy-Hercules mailing list. I just realized it
probably wouldn't hurt to post it here too.
I'm finally in possession of a box that hopefully is capable or can be made
capable of connecting a real terminal to Hercules. It's a 3174 11L. It was
retired last year where I work. I finally got the okay to save it from
being sent to a scrapper. I love the build quality of older IBM gear,
except when I'm trying to move such gear. Between the 3174 and a 9406-520 I
also acquired, I pulled or strained something in my left arm moving them
into place.
It's currently wired to run on 220v. I think I've seen mentioned somewhere
that it can be changed to run on 110v. If that's the case, does anyone have
a pointer to documentation on what's involved?
It has dual floppy drives. At least one drive is a 2.4MB drive. But, all
the microcode disks I have are at level B 4.6. Does anyone know where I can
get a set of C 6.4 control and control extension disks. From what I've
heard those are what's needed to enable an attached terminal to connect to
other systems via telnet.
It has a token ring card. I will probably be able to get the MAU it was
connected to, and possibly the router that acted as a token ring to Ethernet
bridge.
I'm not sure how much memory it has. Does anyone have any tips on
determining the amount of memory it has, and/or identifying its boards?
These are the numbers on its boards:
9210
9351
9052 z2
9053
9501
Plus the boards for coax connections.
--
Kevin
http://www.RawFedDogs.nethttp://www.Lassie.xyzhttp://www.WacoAgilityGroup.org
Bruceville, TX
What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
------------------------------------
Posted by: Kevin Monceaux <Kevin at RawFedDogs.net>
------------------------------------
------------------------------------
Yahoo Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ibm-legacy-hercules/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ibm-legacy-hercules/join
(Yahoo! ID required)
<*> To change settings via email:
ibm-legacy-hercules-digest at yahoogroups.com
ibm-legacy-hercules-fullfeatured at yahoogroups.com
<*> To unsubscribe from this group, send an email to:
ibm-legacy-hercules-unsubscribe at yahoogroups.com
<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
--
Kevin
http://www.RawFedDogs.nethttp://www.Lassie.xyzhttp://www.WacoAgilityGroup.org
Bruceville, TX
What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
I? would? love to have? focal 11 on paper? tape? too if? anyone can punch one up!? thx? ed#
In a message dated 3/4/2019 2:52:32 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
On 3/1/2019 12:50 PM, Rich Gopstein via cctalk wrote:> I just picked up a Remex paper tape reader from eBay and will be> interfacing it to my PiDP-11/Simh PDP-11 simulator shortly.> > I've been looking for an affordable punch, but haven't found one yet.? In> the meantime, does anyone know where I could get paper tapes with the> absolute loader and standalone basic?> > I don't need originals, so if anyone has a punch and is willing to punch> them for me, that would be great!? I'd be happy to pay whatever is> reasonable.? If you have any other PDP-11 tapes too, that would be helpful.> > Thanks.> > Rich>
I have some duplicates of what you have asked for, so I could probablyaccommodate you.? But not all that many, so they aren't free.? I*believe* (but would have to double check) that these are all actualDigital paper tapes I got with various machines, which increases the price.
I'd be willing to let them go for $20 each: feel free to pick andchoose.? If I have any that are just copies and not originals, those Iwould let go for $5 each.? Plus shipping (they ought to all fit in onesmall flat-rate box, assuming you are in the US).
If others can punch copies for you, so much the better.? (I have punchesthat worked when I first got them, but they need work.? Same goes for myreaders, unfortunately).
Some of the items below (PAL, EDT, LINK) might be pretty useless withouta paper tape punch.? ;)
I have a few others (IOX).? I have FPP (floating point package) - but noduplicates.
Seehttp://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-11-XPTSA-B-D%20PDP-11%20Paper%20Tape%20Software%20Handbook.pdf
(Surprised that wasn't on the CHM bitsavers site...)
JRJ
KIND??? ID??? MACHINE??? CONTENTS??? COMMENT??? Checksum??? Checksum 2??? FILENAME??? MFGSERIAL??? TRAY??? DATE??? AVAILABILI??? ERRORS??? PREVIOUS_C
BASIC V007A
PT??? DEC-11-AJPB-PB??? PDP-11??? PDP-11 BASIC V007A??? SA=16104 RA=0??? ??? ??
Digital??? ??? 55??? 11/5/1970??? ??? ??
BASIC V008A
PT??? DEC-11-LBSUA-A-PB??? PDP-11??? BASIC.LDA V008A SINGLE USER BASICREPLACES: DEC-11-AJPB-PB??? ??? ??? ??? Digital??? ??? 44??? 12/1/1972??? ??? ??
Absolute loader
PT??? DEC-11-UABLA-A-PO??? PDP-11??? PDP-11 ABSOLUTE LOADER??? REPLACES:DEC-11-L2PC-P0??? ??? ??? uabla-a.rim??? Digital??? ??? 62??? 5/5/1977??? ??? ??
Absolute loader (no switch register)
PT??? DEC-11-UABLB-A-PO??? PDP-11??? ABSOLUTE LOADER VB07.00??? NON-SWITCHREGISTER VERSION??? ??? ??? ??? Digital??? ??? 36??? 12/5/1975??? ??? ??
PAL-11A V007A
PT??? DEC-11-UPLAA-A-PB??? PDP-11??? PAL-11A.LDA V007A??? REPLACES: DEC-11-ASXB-PBSA=1516 RA=1516??? ??? ??? ??? Digital??? ??? 39??? 11/3/1975??? ??? ??
PAL-11S V003A
PT??? DEC-11-UPLSA-A-PL??? PDP-11??? PAL-11S.LDA V003A??? REPLACES: DEC-11-ASQA-PLSA=2066 RA=2066??? ??? ??? ??? Digital??? ??? 42??? 12/1/1972??? ??? ??
EDIT-11 V005A
PT??? DEC-11-UEDPA-A-PB??? PDP-11??? ED-11 V005A??? REPLACES: DEC-11-E1PA-PB??? ??? ??
Digital??? ??? 39??? 11/10/1975??? ??? ??
LINK-11S? V002A? (SA 22714)
PT??? DEC-11-ULKSA-A-PL??? PDP-11??? LINK-11S.LDA V002A??? REPLACES:DEC-11-ZLQA-PL??? ??? ??? ??? Digital??? ??? 41??? 12/1/1972??? ??? ??
ODT-11? V005A
PT??? DEC-11-UODPA-A-PB??? PDP-11??? ODT-11.LDA V005A RE-ENTER=13032??? REPLACES:DEC-11-O1PA-PB SA=13026 RA=.30??? ??? ??? ??? Digital??? ??? 44??? 12/1/1972??
DUMPTT? V001A
PT??? DEC-11-Y1PA-PB??? PDP-11??? DUMPTT V001A??? SA=LOAD ADDRESS RA=LOADADDRESS??? ??? ??? ??? Digital??? ??? 43??? 11/10/1969??? ??
DUMPAB V001A
PT??? DEC-11-Y2PA-PO??? PDP-11??? DUMPAB V001A??? SA=XX7500 RA=XX7500??? ??? ??
Digital??? ??? 44??? 11/10/1969??? ??? ??? ??? ??? ??
I just picked up a Remex paper tape reader from eBay and will be
interfacing it to my PiDP-11/Simh PDP-11 simulator shortly.
I've been looking for an affordable punch, but haven't found one yet. In
the meantime, does anyone know where I could get paper tapes with the
absolute loader and standalone basic?
I don't need originals, so if anyone has a punch and is willing to punch
them for me, that would be great! I'd be happy to pay whatever is
reasonable. If you have any other PDP-11 tapes too, that would be helpful.
Thanks.
Rich
> From: Jay Jaeger
> I have EK-11060-OP-003: "PDP-11/60 installation and operation manual"
> and an update EK-11060-OP-C1.
Yeah, that's the one I referred to as "the general -11/60 manual"; generally,
there's one such for all the -11 models, but the exact name varies from model
to model (unlike, say, the CPU tech manuals, the name for which is pretty
predictable).
> let me know and I will scan it in and stick it on my Google drive in a
> day or two or three
That would be great; thanks very much! No rush at all...
> I also have a spare processor handbook, EB-06498-20/77
We do have that one, thanks.
BTW, looking a little more closely at the cabinet/power-supply manual
(pg. 1-7), the KD11-K TM might _only_ be available on fiche. If so, that'll be
the first time I've ever seen that. Oddly enough, further down the page, the
FP11-E TM seems to be available in printed form (EK-FP11E-TM).
> From: Ethan Dicks <ethan.dicks at gmail.com>
> I've seen Tech Manuals printed as 2-up on C-sized paper
Yeah, generally things from the -11/20 era are like that (e.g. the RK11-C
manual). Nothing later than that that I've ever seen, though.
>>> I have the two BA11 cabinets for an 11/60, the PSUs, and the front
>>> panel (I'm missing the rack).
> "the rack" is just the outer box with rails (not an H960 - whatever the
> designation is for the odd 11/60 cabinet).
I think it's the H9500 low-boy corporate cabinet, per Chapter 5 in
the cabinet/power manual.
> The backplanes are in the BA11s. I seem to have both MOS and core
> memory and, I am fairly sure, an RK611, along with the CPU. I need to
> take a module inventory.
You seem to have most of the crucial bits, although you might be missing
the power harness.
Do you have the optional WCS module (M7870)? There are also ROM modules, and
a diagnostic module, that can go in that slot - only one of the three at a
time, though.
Noel
On the off chance that someone on the list wants it and doesn't like the
idea of shipping, I'll be going to VCFMW in September and could bring it
along. My route will be Santa Barbara, Las Vegas, north to I-80, and
I-80 to the Chicago area. After that, I'll be headed to Pittsburgh, PA
and it can be dropped off along the way.
I can also head out to Goleta (basically Santa Barbara) and check out
what this person has.
Marvin
>> On Mar 3, 2019, at 10:35 AM, Ray Arachelian via cctalk <cctalk at classiccmp.org> wrote:
>>
>> On 03/03/19 12:58, Marvin Johnston via cctalk wrote:
>>> I just ran across this and while I'm not interested, someone on the
>>> list might be.
>>>
>>> https://santabarbara.craigslist.org/sys/d/apple-512k-lisa-computer-valuetec…
>>>
>>>
>>> It was posted about 14 days ago, and looks to be in Santa Barbara, CA.
>>>
>> That doesn't look like it's a Lisa, it may be a tempest hardened Mac 512.
>
> An interesting system. Someone needs to save this. Based on the description, and the way it looks, I think you?re right about it being designed for TEMPEST hardening. There were some TEMPEST versions of the Mac II.
>
> Zane
Hi all,
I recently got one of these DECtalk-PC ISA cards from eBay (
https://www.ebay.com/itm/183684666377, no affiliation with seller other
than a happy customer) and was wondering, does anyone have a schematic for
this?
Thanks!
Kyle
Hello Everyone,
We found a PDP-11 QBUS card cage with a KDF11 and some other cards (RAM,
ROM, some basic peripherals) which included a DSD-4140 card.
Unfortunately, the DSD-4140 is missing one of it's microcode PROMs for
some reason.
Does anyone else have one of these cards? It'd be really helpful if we
could get some dumps of the 4 microcode PROMs so we can compare what we
have and look into replacing what we don't have with an adapted modern
part. (and if anyone goes to the trouble to read the 4 microcode PROMs,
there's also an 82S137 that deserves to be dumped).
Here's a picture of the card in question: https://i.imgur.com/tzYjPYF.jpg
Regards,
Joe Zatarski
On Sat, Mar 2, 2019 at 3:16 PM Glen Slick via cctalk
<cctalk_at_classiccmp.org> wrote:
>On Sat, Mar 2, 2019 at 12:02 PM Joseph Zatarski via cctalk
><cctalk at classiccmp.org <http://www.classiccmp.org/mailman/listinfo/cctalk>> wrote:
>>//>>/On a somewhat related note, I don't suppose anybody knows or has />>/documentation on the pinout of the C/D interconnect on these RAM boards? />>/The pinout for the ribbon cable is in the manual, but the C/D />>/interconnect doesn't seem to be documented in any of the manuals that />>/are online. />
>650QS Field Maintenance Print Set, MP-02538-01, Rev C1
>http://www.bitsavers.org/pdf/dec/vax/650/MP02538_650QS_Sep88.pdf <http://www.bitsavers.org/pdf/dec/vax/650/MP02538_650QS_Sep88.pdf>
>
>Page 65 of the PDF, KA650 Circuit Schematics Page 23 of 40
>MA0 - MA9
>CAS0 - CAS3
>RAS0 - RAS3
>WE
>SE
>XADDR20, XADDR21
>+5
>GND
>
>Page 47 of the PDF, Page 5 of 40 is an overview block diagram of those
>signals originating at the DC357 CMCTL Memory System Controller.
OK, thanks, that's great. Now I won't have to bother tracing things out if I decide to go that route. Didn't realize there was a printset for the KA650, but I guess I didn't even bother to check.
Hello Everyone,
I've got a KA650 with a MS650-AA 8MB memory module. When we initially
started messing with this VAX, it was giving a memory error. We were
able to track down first the bad bank, and later the individual bad ZIP
RAMs with the help of my logic analyzer. For now, I kludged an SOJ DRAM
in there that seems to be working without issue. The machine no longer
gives memory errors during POST, but if you run one of the more thorough
memory tests like #48 (MEM_Addr_shrts), it fails. My initial thought was
that this RAM test checks for shorted address lines, which would cause
writing to one location to change another location perhaps. However, I
haven't been able to replicate the error with DEPOSITs and EXAMINEs on
the console.
Without having to disassemble the VAX ROM, does anybody know what this
test does? Once I know what I'm looking for, I can probably convince the
logic analyzer to see the error with some fancy triggering, and get this
board 100% fixed before I order some ZIP DRAMs.
On a somewhat related note, I don't suppose anybody knows or has
documentation on the pinout of the C/D interconnect on these RAM boards?
The pinout for the ribbon cable is in the manual, but the C/D
interconnect doesn't seem to be documented in any of the manuals that
are online. With the price of MS650's these days, it seems like the
cheaper route (albeit more work) is to build a new RAM board rather than
buy one (especially if a single 64MB board could be made). I suspect
it's not too complex anyway, and it can probably mostly be traced out,
and the rest inferred and then verified with a logic analyzer.
Thanks,
Joe Zatarski
Hello everyone,
I've got two unrelated things I'm looking for:
The first is an HP logic analyzer interposer for the emulation adapter
for an MC68332. This would have a PGA socket on it, and sort of a
reverse socket for the QFP132 package (attaches to a chip from the top,
to interface to a chip soldered onto a board). I believe the part number
would be HP E3417A. I already have the QFP160 adapter, but the chip I
want to interface to is a QFP132. This adapter supposedly exists, but
I've had no luck trying to find it through the usual channels.
The second that I'm looking for, is if there's someone out there that
owns and can dump the microcode ROMs from a DSD-4140 QBUS floppy
controller. We've got a card here that's missing one of the ROMs, and
we're also not sure if the ROMs are mixed up, so a dump of all 4 ROMs
would be appreciated. They are 82S181, but they should read in any EPROM
burner with a breadboard and some wiring to adapt the pinout. Burning
them is another story, but we'll worry about that later... Here's a
picture of the card in question: https://i.imgur.com/tzYjPYF.jpg
And if anyone has one of these and is kind enough to dump it for us,
there's also an 82S137 on the card that probably deserves a dump as well.
Thanks,
Joe Zatarski
Hi all
I have a couple of near identical Sun Enterprise M4000 servers fitted with SPARC64 VI 2.1GHz CPUs, 16GB and I think 2 x 146GB disks.
I *think* these are working but have never powered them up. I purchased them surplus a year or so ago.
Available free of charge to any Sun fans - these are collection only sorry.
I?m not too far from Cambridge location wise in the UK.
PM me if interested. First come first served.
Thanks
Ian
So, I've been having some fun playing around with V6 Unix on my 11/45 a bit after that last repair.
I've just been tripped up for a little over the fact that the C compiler barfs if there is whitespace/comentary before the first #include; the workaround seems to be to add a lone '#' at the beginning of the file. It took me a while to notice that this was done, for example, in all of the device driver sources.
I found this curious. Anybody know what the story is there?
--FritzM.
On Thu, 2/28/19, Fritz Mueller via cctalk <cctalk at classiccmp.org> wrote:
> I've just been tripped up for a little
> over the fact that the C compiler barfs if there is
> whitespace/comentary before the first #include; the
>
> I found this curious.? Anybody
> know what the story is there?
My recollection is that it's documented in the 6th
Ed C manual that # has to be in the first column.
Beyond that, I vaguely recall something to the effect
that if the first line isn't a preprocessor directive,
then it skips any preprocessing at all.
BLS
> From: Phil Budne
> I'm betting it was a speedup to not fork/exec another process if it was
> going to be a null transform!
It's worse than that! In vanilla V6, the pre-processor is built into 'cc',
not a separate command.
Here's the relevant code (from expand()):
if (getc(ibuf1) != '#') {
close(ibuf1[0]);
return(file);
}
The code to implement the directives is, ah, entertaining.
Noel
Hi, does anyone have any PDP-11/60 manuals? I went to do articles on the
-11/60 and its CPU (KD11-K), but there isn't much online.
Bitsavers has EK-KD11K-TD-PRE, but it only covers the maintenance features,
not the whole CPU; there is a tech manual - KD11K-TM-001 (I have it in fiche,
but my fiche reader has a burned out bulb which I have not yet been able to
replace, so it doesn't do me much good). There is a user manual for the
FP11-E, which has a certain amount of useful details, but it refers to the
technical manual, which is not there. And there's EK-11060-SV-01, which covers
the cabinet and power supply.
So if anyone has the general -11/60 manual, or the KD11-K tech manual, those
would be super useful. The FP11-E tech manual would be nice to have, but isn't
as important as the others.
Thanks (I hope!)!
Noel
Christian,
there is the document
"9915-TapeDuplicationAndEPROMProgrammingSoftware-09915-10011-46pages-Jul83.p
df" on the HP-.Museum web site.
I think the associated software is not available, but it also uses the
TAPDUP binary (pg. 1-2) and the same IMAGE program.
The binary itself was part of this and is not documented (it was considered
part of the whole package).
What is available via M. Craggs web site are the files from a "Hybrid ROM
Creation Pak", which includes TAPDUP. The IMAGE program (pg 2-2) contained
there is probably similar or the same. The Master/Slave programs and some
more are not in this package.
>From the "Hybrid ROM Creation Pak"
AUXROM.ASM
AUXROM.BAS
AUXSHELL.BAS
CREATEROM.BAS
DATAIO-19.BAS
DATAIO-29A.BAS
EPROM2.BAS
IMAGE.BAS --- 20 ! (program "IMAGE", 09915-90022, p.5-5...5-6) (these
page numbers do not refer to the manual 09915-10011)
MAINBASIC.BAS
RBUILD85S.ASM
RBUILD87S.ASM
ROMSHELL.ASM
TAPDUP.ASM
Martin
> From: Bill Degnan
> The 11/60 handbook doesn't have that kind of designation. It's EB06498
Yeah, that's the processor handbook, which is the paperback-sized thing which
is mostly a programmer's reference; I've got that, its the 8-1/2x11 sized
things I'm after.
> From: Ethan Dicks
> Is it by any chance EK-KD11K-TM-001?
> That part number is for a print-set
Uhh, no. Looking at the fiche version, EP-KD11K-TM-001, it has lots and lots
of text blocks (which I can't read without a fiche reader, of course).
We do seem to have the print sets:
MP00166 11/60 System (chassis, power contoller, etc)
MP00409 KD11-K CPU
MP00500 WCS (M7870)
MP00429 FP11-E
but I'm not desperate enough to learn the -11/60 by looking at them!
> I'm following the discussion because I have the two BA11 cabinets for
> an 11/60, the PSUs, and the front panel (I'm missing the rack).
And by 'the rack', I'm guessing that includes the backplane? Looking through
the prints, I think I didn't see details on it (alas).
Noel
> From: Josh Dersch
> I recently picked up a copy of the PDP-11/60 Processor Handbook, not
> sure if that's useful for your research
Yes, it almost certainly is (without seeing it, I can't be 100%, but it sounds
like it is). Is it by any chance EK-KD11K-TM-001?
Thanks!
Noel
Hi,
most people dealing seriously with older PDP-11s have found means to
monitor the UNIBUS traffic.
My latest approach is www.retrocmp.com/tools/uniprobe
UniProbe is a M9302 terminator, a LED display, a probe for logic analyzer.
It can be mounted in Standard or Modified UNIBUS sockets.
I'm ordering a batch of PCBs in a few days and will show this and other
stuff (UniBone, BlinkenBone) at VCFPNW in Seattle.
https://vcfed.org/wp/festivals/vintage-computer-festival-pacific-northwest/
best regards,
Joerg
Adrian -
ASTEC is now owned by Emerson Power (UK address below).
Emerson Power Catalog (find the 57 watt models):
https://www.mouser.com/catalog/supplier/library/pdf/Emersonpower_catalog.pdf
PowerClinic in Dallas/Fort Worth area
services a large number of Switch-Mode power supplies.
http://portal.powerclinicinc.com/web/services
Power Clinic Inc.
3732 Arapaho Rd
Addison, TX 75001
USA
==
H7881-AA (Refurbished), $177.00 USD
https://www.tamayatech.com/parts.php?g=H7881AA
H7881-AA Power Supply, 57 watt , $450.00 USD
https://www.ipsystemsinc.com/shopping/pgm-more_information.php?id=630
ASTEC - Europe (UK)
Waterfront Business Park
Merry Hill, Dudley
West Midlands, DY5 1LX
United Kingdom
Telephone: +44 (0) 1384 842 211
Facsimile: +44 (0) 1384 843 355
==
From: Adrian Graham
To: "General Discussion: On-Topic and Off-Topic Posts"
Subject: DECserver 700 PSU fix, H7881-AA
Hi folks,
My trusty DECserver has bitten the dust in a silent and non-violent way
with the fuse still intact so has anyone got tips on troubleshooting? I
know it's the PSU because I 'borrowed' another PSU from work and the unit
is running again. It's an ASTEC unit under the hood, and in my experience
of fixing the older types like the AC8151 (Memotech, TRS80 II/III, Osborne
etc) the chief culprits on an utterly dead PSU are the input caps and/or
the small 220uF or 330uF startup cap in the feedback circuit.
I haven't checked bitsavers etc for a schematic yet, does such a thing exist?
Hopefully the ASTEC board has a model number on it.
Cheers
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest private home computer
collection?
t: @binarydinosaurs
f: facebook.com/binarydinosaurs
w: www.binarydinosaurs.co.uk
Christian,
the TAPDUP binary and associated utility programs in BASIC was used to
create EPROMs with programs and data for the 9915 Series-80 box.
It can be used to read the directory record and then to read tokenized
PROGrams as data on a file-record base - not at low record level.
The package also contains programs to massage the PROG data into BASIC DATA
statements for creating EPROM burner files.
You could use it to read the tape directory and individual PROG files but
right now I am not aware of a program which would write this data back to a
tape.
You would open the directory, look up a file and then OPEN IMAGE it. Next
you would READ RECORD IMAGE$ the program record by record.
In the end you have not gained much compared to the simple COPY statement.
Except for the copy of the directory with attributes and security flags.
Alternative:
There are also READSECTOR binary programs for reading raw 256 byte
records/sectors from disks. They also work on the tape ":T" but seem to
start their record count after the directory records. On disks, record 0 is
the first real sector.
So, to get the complete binary content one could use
C$=CATALOG$ from TAPDUP to read the directory record
READSECTOR N,R$,D from to read the subsequent raw "data" records.
Here are my notes on some of the functions in this binary program:
The TAPDUP Binary (Notes by M. Hepperle)
This binary contains functions to read tapes (HP-85, 9915) at low level. It
does not handle disks.
The program was part of the "Tape Duplication and EPROM Programming Pack"
(09915-10010).
As the original software was not available the binary was re-assembled from
an assembler source file.
This source file was obviously created by disassembling the original binary.
It was found at M. Craggs web site:
http://www.biblewitness.org/technical/HP_Series-80/HP-85/ASSM .
Martin Craggs home-made disassembler produced many unnecessary DRP and ARP
statements, which could be cleaned up to improve readbility.
Functions in the TAPDUP binary:
C$=CATALOG$
Return the directory record of the tape in form of a 512 byte buffer (2
records).
C$ must be DIMed to at least 512.
OPEN IMAGE F$
Find the file F$ and open it for reading.
ERRN=67: file not found
T=READTYPE
Return the file type of the currently opened image
(the file image must be opened by a preceding call to OPEN IMAGE)
34 = PROG
N$=READNAME$
Return the file name of the currently opened image
(the file image must be opened by a preceding call to OPEN IMAGE)
R$=READ RECORD IMAGE$
Read the next record of the currently opened file.
The record has a length of 256 bytes.
Reading can be continued by another READ RECORD IMAGE$ until ERRN=71
indicates a read behind the end of the file.
See lines 440 ff in IMAGE program for a typical reading loop.
(the file image must be opened by a preceding call to OPEN IMAGE)
ERRN=71: end of file reached.
CREATE IMAGE S$,I,J,K
3 numeric parameters
WRITE IMAGE R$
Write record to (where?) "Error 244: No file open"
WRITE CATALOG C$
Writes the catalogue back to disk.
C$ must contain a valid catalog structure, otherwise your tape will be
unreadable afterwards.
READLOGLEN
Read the logical record length, which is 256.
Another useful function in the Program Development ROM
C$=CHECKSUM$(S$)
Return the IBM SDLC CRC checksum of the given string (the length of the
checksum is two bytes).
Example: dumping the tape catalog
Each catalog entry is 12 bytes
10 DIM C$[512]
20 C$=CATALOG$
30 K=1
40 FOR I=1 TO 504 STEP 12
50 FOR J=1 TO 12
60 PRINT C$[K,K];
70 K=K+1
80 NEXT J
90 PRINT
100 NEXT I
110 PRINT
120 END
Tape documentation lifted from Everett Kaser's Series-80 Emulator (I hope
Everett won't sue me for this blatant copyright infringement):
TAPE LAYOUT
-------------------------------------------------------
The HP-85 tape cartridges contained at most 43 files.
File 0 was always the TAPE DIRECTORY, and was always
4 records long. Files 1-42 were the user-created files.
The tape itself had 2 TRACKS, 0 and 1.
There were TWO COPIES of the TAPE DIRECTORY, one in
records 0 and 1 of file 0, and a second in records 2 and 3
of file 0. Record 2 was an exact duplicate of record 0,
and record 3 was an exact duplicate of record 1. Only
one record of the directory could be read into memory at
a time, so the system had to keep track of whether the
first 1/2 or the second 1/2 of the directory was in memory
(or neither).
Each DIRECTORY RECORD consisted of 21 12-byte directory
entries, which equals 252 bytes. The final 4 bytes of
each record as follows:
252 directory segment flag (0 or 1).
253 FILE# of file that wraps from the end of TRACK 0 to
the beginning of TRACK 1.
254 (2 bytes) RECORD# of first record of the split file
255 that's on TRACK 1.
Each DIRECTORY ENTRY consists of 12 bytes, allocated thusly:
BYTES DESCRIPTION
----- ---------------------------------------------
0-5 ASCII FILE NAME, blank filled
6 EXTENDED File Type
7 FILE TYPE
8-9 # RECORDS in the file
10-11 # BYTES in each record
The FILE TYPE is thus:
BIT DESCRIPTION
--- -----------------------------------------------
0 No directory name listed
1 Soft write protect
2 Extended file type (****)
3 Binary Program (BPGM)
4 Data file (DATA)
5 BASIC Program (PRGM)
6 Empty file (NULL)
7 Next available file
The most significant bit of the EXTENDED FILE TYPE byte will
signify extended file type as well as BIT 2 of FILE TYPE, but
it shouldn't be used, as a bug in the system doesn't clear that
bit if you purge the file. The lower seven bits allow the
differentiation between various extended file types (****).
Hi,
what is the recommended way to image HP 85 tape cartridges? The best would
be including headers and whatsoever, and to be able to recreate tapes from
the images and have a 1:1 duplicate from the original cartridge.
I'm almost done with rebelting and imaging our 264x cartridges and would
like to continue with the other tapes (85 and 9845).
Christian
Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN.
Is there some copy still around ??
I had a look in Google, Bitsavers, HPmuseum, with NO success.
Thank for help and/or advise.
Howdy friends,
In need of 8 pcs. MT4067-15 or equiv. to fill out the RAM board in a Tandy
1000 EX. These are 64k x 4bit I believe.
Just checking to see if a group member might have some stashed away?
CHM has a 1072 with a AM-100L 68000 processor and a scsi interface.
one of the boot proms has gone bad, has anyone imaged these?
I'm also trying to locate the hardware manual for the AM-620 QIC cartridge tape interface.
Hi folks,
My trusty DECserver has bitten the dust in a silent and non-violent way
with the fuse still intact so has anyone got tips on troubleshooting? I
know it's the PSU because I 'borrowed' another PSU from work and the unit
is running again. It's an ASTEC unit under the hood, and in my experience
of fixing the older types like the AC8151 (Memotech, TRS80 II/III, Osborne
etc) the chief culprits on an utterly dead PSU are the input caps and/or
the small 220uF or 330uF startup cap in the feedback circuit.
I haven't checked bitsavers etc for a schematic yet, does such a thing
exist? Helpfully the ASTEC board doesn't have a model number on it.
Cheers
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest private home computer
collection?
t: @binarydinosaurs f: facebook.com/binarydinosaurs
w: www.binarydinosaurs.co.uk
I've been thinking it might be nice to have an LDA BFD backend for gnu binutils, so gas, ld, objdump etc. could deal with LDA's directly without having to use separate conversion utilities.
Before jumping in on that, though, I thought I'd ask here to see if anybody might have already started or done this? I've noticed several of the folks here also have contributions on some of the binutils lists.
thanks,
--FritzM.
DID YOU CHECK? HP MUSEUM DOWN UNDER?? THEY HAVE A FAB? ONLINE COLLECTION OF? SOFTWARE...
In a message dated 2/24/2019 3:04:03 AM US Mountain Standard Time, cctalk at classiccmp.org writes:
Back in ''70, sometimes we were running "basic" BASIC ( NOT Time sharing ) on 2116B, 2100A, just for FUN.
Is there some copy still around ??
I had a look in Google, Bitsavers, HPmuseum, with NO success.
Thank for help and/or advise.
re: Cisco and IBM protocols
If you're really interested, all of this is exhaustively documented
under the umbrella of Cisco's "IBM Feature Set". There's a *lot* here
under the hood, but the last time I looked (admittedly, a while) a
number of folks had web sites that documented the correct incantations
for Hercules and common hardware.
You can bridge between TR (and FDDI) and ethernet on a Cisco,
generally for non-routable protocols (e.g. NetBIOS); see:
'translational bridging'. If you're trying to get these protocols
across an intermediary 'alien' network (like the corp FDDI backbone,
or the Internet), there are things like DLSw.
If you're trying to get TCP/IP from TR to ethernet and vice versa,
routing generally works better/is simpler (IME), but Cisco has all
sorts of bizarre encapsulation/translation features for different use
cases should you need them.
You can also make the router look like an SNA concentrator (PU?).
KJ
Slightly off topic for list although the rack and equipment are almost 20
years old now....
I got me a hand me down Compaq Proliant StorageWorks UE Rack. Basically it
is a rack case that can hold 14 drives. The case is secured to the cabinet
with two thumb screws (see attached pictures). These are like standard thumb
screws except there is a spring component to them as well (I assume to give
wiggle so it is easier to match screw to cage nut).
You can see pictures of the screws in this VCF post:
www.vcfed.org/forum/showthread.php?68556-Compaq-Rack-Thumb-Screws&p=559354#p
ost559354
On my hand me down the one on the left is missing. I have looked and there
doesn't seem to be a Compaq part number (I think the screws are press fitted
into the metal frame so not really user replaceable). I don't think there is
anything special about the screw and I can always use a standard M6 screw
for the missing side. However, I'd like to try and match/restore the
original. I have tried googling for theses screws but I am not coming up
with the right item. I am guessing I am not using the right terms or names
for the screws. So does anyone have some broken/parts Compaq rack equipment
where I can have the screws? Or can point me to a source online to get a
replacement? TIA!
-Ali
In the early 1970s a socket to hold multiple DIP chips was being sold under
the brand name DipStik. Up to six chips were inserted in a trough in the
socket, a top screwed on with thumbscrews on the ends. It had solder lugs
on the top and bottom for each of the chip pins.
We are restoring an old electronic device that was built in part with
these, but due to some corrosion we could use replacement DipStik units if
anyone has them.
Carl
Does anyone on the list have or have seen the stand that DEC sold with the
VT52? I'm just curious; does the stand screw into holes on the monitor or
does it just sit on top?
>From what I've seen before it just looks like an office chair base with a
top that is the correct size.
Thanks,
Marc
http://bitsavers.org/bits/TI/Explorer/cartridge_tapes
the 2.6.0 diag 6.0 bootable and 6.0 patches are probably the most interesting
has there been ANY posts about the Explorer simulator in the last decade?
I've also not verified any of them are what the label says
I ran into a couple that were overwritten. Some I know are correct, because
there were multiple copies.
Hi Ali,
I'm planning on a USB controller, but I've seen ISA projects that are also
microcontroller based so I think it wouldn't be awfully difficult to
replace the USB data pipe with an ISA one.
Zooming out, I have a list of USB controllers to build:
- Kennedy 9800 tape drive
- IBM 6360 8" floppy drive
- IBM <something> 5 1/4" floppy drive
My friends think it's silly, and they're probably right. =P
On Tue, Feb 19, 2019, 1:18 PM Ali <cctalk at ibm51xx.net wrote:
> >
> > Now that I have my glorious disk toaster (2D model I think, says "2D"
> > on
> > the drive levers), I want to build a controller for it. I found pinouts
> > and
> > some description of the media organization here:
> >
> > http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241-
> > 6248-3_Displaywriter_6360_6580_Product_Support_Manual_Feb1983.pdf
>
> Congratulations! Those are nice looking drives. The problem of course is
> they don't work with anything "standard".
>
> > I'd like to actually store data to these disks in the same manner the
> > original systems did, and I'm proficient in hardware/firmware. Has
> > anyone
> > made a controller for this already? How about emulating the filesystem?
>
> Wow. That is going to be big endeavor.... A question what is your target
> system (i.e. are you planning on implementing this on a controller
> connected to a modern system w/ USB or are you planning on a nice ISA card
> so these drives can be used on older systems?) I wish I could help you
> technically but my background is far removed from engineering... However, I
> will follow with great interest specially if you go the ISA route...
>
> -Ali
>
>
So, I used SIMH to do an install of a complete OS on
an RA81 disk. I would like to move this to a real disk
and try it on a real PDP-11. Is there a way to do this
using dd on a BSD machine? I tried but it created a
non bootable system. Well, actually, it starts to boot
but then fails very early in the startup process. I used
"dd if=filename of=raw-device bs=1024". Could it be that
the block size needs to be something else?
I know that VTServer and PDPGUI can move disk images but
it would take a week at 9600 baud and I think very little
likelihood of it ever completing successfully.
bill
Hello everyone - since people have already been asking (we even had
someone call the hotel to try to register - that's some refreshing
pro-activeness), we can confirm the date of this year's Vintage
Computer Festival Midwest will be:
September 14-15, 2019
2019 will bring a NEW LOCATION which will be announced in the coming
weeks. So don't call the old hotel - they're already sad that they
lost us*.
Updates will be posted first to our site at http://vcfmw.org, as well
as our mailing list, which you can join there.
Thanks to all who have attended in the past and are considering it
this year. This one will be something special**, for sure.
-jht
* Nothing wrong with the old place - we just outgrew it!
** Note that that is a measure of magnitude, not direction.
lots? of? piles? of? phones...
some? areas? a? real? mess...
this? guy? gets the hoarder? award? for? ?wooden? phone? cascaras
back? when? the payphone? biz? went? privatized and legal? also? ?that? way? ?Ron had? conversion kits...?
he? did? well in the? ? ?make? your? kitchen into a? country? kitchen? craze....? sold? lots? of? cobbled? to? ?work? ? oak? phones? ?for? ? the? kitchen.? there? was a? good? market? back in the? 70s? ?not? much? now? though? the old? people that remember the 'LASSIE"? ?wood? phone in? their? house as? kids? are? dying off? now...
really interesting? ?guy....? ? ?very? odd business model....
ed#
In a message dated 2/20/2019 11:26:20 AM US Mountain Standard Time, cctalk at classiccmp.org writes:
So...how 'bout them phones? (hint, hint)
Does anyone know if they have any CO stuff?
(only a tiny, tiny fraction of telephone collectors care, even a tiny
bit, about CO stuff)
--
Will
> From: Grant Taylor
> I agree with your logic.
> However your valid logic
Anyone who thinks logic starting from common sense has anything to do with
the workings of legal systems is likely in for a rude awakening at some
point.
Noel
Fred,
Are we being a little sarcastic or serious? :)Honestly, a sw implementation would be interesting but would it work on vintage hw? Or are you suggesting for use only with a modern system??For example here is my dilemma: my stinkers, whom you have met, are getting old enough to want to mess with my stuff. *shudder* i mean cool! but I really don't want them ruining my one actual original disk for any programs I own. So what I do is make backup copies just like in the old days. And before someone suggests emulators, it is just not the same. I mean if we wanted to emulate everything why bother even preserving hardware?Problem is when we have copy protection, as many games or old SW do, then you need a Copy II PC board. I have one and they are fairly common but ridiculously expensive now a days. So it would be nice if the functions could be duplicated in an easy to use manner. Kyro Flux is powerful but not for everyone. I want an FDC that would cover 90% of the vintage hobby (i.e. Apple II, Mac, and IBM). An FDC that combines a CompatiCard IV with a copy ii pc deluxe and a Match Point card would cover all of the above plus then some.Just a thought.... ;D
I got a laugh out of this anecdote. Of course, folks heard me chuckle
and I tried to share the joke but.... Way too geeky for public
consumption.
Back in 2000-ish, I was upgrading my DG MV4000/dc to 8mb so as to be
able to run the snazzy AOS/VS II tapes I'd got along with the 9 track
drive I hacked onto the machine...
The install would start and then bomb at a certain point every time. I
decided to work the machine hard and then pull the board and give a
good SNIFF. This is a 15x15 inch board populated with 256kx1 drams.
The time in the machine got the board cooking nicely, and when I
smelled a certain charred smell in the vicinity of a 74ls04, I knew it
was that magic black smoke. I pulled a 74HCT04 from a known-good isa
card, socketed the spot and viola! Working 8mb board. It isn't
ALLWAYS the most expensive chip, thank God, and sometimes even us not-
as-bright guys come off with a win.
I really enjoy reading this list even though I don't contribute all
that often or anything of much value. It is a pleasure to watch you
guys work.
Jeff
On Thu, 2019-02-14 at 12:00 -0600, cctalk-request at classiccmp.org wrote:
> Re: PDP-11/45 RSTS/E boot problem
> When our 11/45 failed in the MMU in 1975, my classmate Josh Rosen
traced the failing path on the schematics. When Jim Newport the field
service engineer showed up, Josh described the diagnostics result that
pointed at the failed path, and added "This is the failed chip"
(pointing to one particular chip.
Jim asked "Why that one?" Josh answered "because that is the most
expensive chip".
It turned out he was right.
paul
Fred,> Are we being a little sarcastic or serious? >:)>>A lot of BOTHJust making sure. ;)>I would like to see software for flux >transition hardware that would >extract sectors.>THEN, I would like to see that software as >a >subroutine, with an interface similar to >INT13h.>THEN, I would like to see that ROMable, >either on a physical ROM, or >loaded into RAM, with the INT13h vestor >repointed to it.That would make for a very powerful tool but as you pointed out yourself how many users would learn to use it? Unless it is a simple driver that gets loaded and the user has to simply put in a couple of generic parameters, e.g. "device=c:\drives\emudsk.sys APPLE", and it is up and running most users won't be able to make use of it.>My preference would be REAL MODE (DOS).As would mine but would a 286 be able to do it? And if you have a machine that runs real mode DOS why not make use of the HW that is there?>Match Point could be implemented in >software on the Central Point board.Great. Then if the DOB HW is duplicated then that part can be SW and no need to have Match Point HW duplicated. I am surprised the Copy II PC DOB card did not handle Apple II disks along with Mac disks.?>CompatiCard was just an ordinary FDC, >without the crippling corners cut.True, but if you are building the ultimate FDC then you don't want crippling corners cut. So something functionally equivalent.>SO, you are asking for FDC plus flux >transition, but better integrated, >rather than flux transition hardware >interrupting the drive cable.Yes! All on one card. Throw in FDADAP functionality to properly write 8" disks and you have a controller that handles most if not all IBM, Apple II, and Mac disks. As I understand it, in my limited way, having both FM and MFM should allow for many CP/M formats including SD. Will some formats be left out? Sure. Will it be as powerful as a Kyro Flux for archiving? Heck no. But will it let me pop in my original 123 disk and copy it for use with out too much hassle and work? Of course.?>There are a few exceptions, such as Pro-lock.Well then you had the ENHANCED Deluxe Board. :)>But, in quite a few cases, people have >disassembled (now illegal under >DMCA!), found the vulnerabilities and >simply disabled the copy protection.?Yes but that is harder and harder to find. They were never public but each city had multiple BBSes offering such altered programs. And of course the other problems w/ this method is you are confined to the one altered version? (even if you own a later version). Also there is no guarantee the alterations will not cause a bug that will crop up later due to a lack of total testing.-Ali
go? to? garage? sales? ?'
thy? turn up there.
In a message dated 2/19/2019 1:57:35 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
On Tue, Feb 19, 2019 at 09:58:00AM -0600, John Foust via cctalk wrote:
> Old tech, but not computers:
I have a fondness for old rotary dial phones, especially ones like they used
in movies and TV shows set in the '40s and '50s.? I've never managed to
acquire one.? I'd love to have a few of them, but not that many.? :-)
--
Kevin
http://www.RawFedDogs.nethttp://www.Lassie.xyzhttp://www.WacoAgilityGroup.org
Bruceville, TX
What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
A History of Engineering & Science in the Bell System TRANSMISSION TECHNOLOGY and ELECTRONICS TECHNOLOGY
A History of Engineering & Science in the Bell System TRANSMISSION TECHNOLOGY
and A History of Engineering & Science in the Bell System ELECTRONICS TECHNOLOGY? ( the? transistor? and devices? etc...)
60 for the? Pair? plus? 16.95? priority? mailing? insured? tracked and? signature? confirmation? payment to be? made? via? pay? pal? friends and? family...only? after? we? ok? who? gets them .
both? ?tight? beauty? copies? with? ?great? jackets on them!
Let me? ?know? asap? ?if? you? want.
extra? copies? help re-roof museum buildings!Thanks? Ed#
> From: Grant Taylor
> I do know that there are a lot of companies here in the US that are
> filtering their website like this.
It does go both ways; a while back, a vintage rail site I read regularly
('Weekend Rails') moved to a new hosting service, and that service filtered
out and refused attempts from the US to read any of the sites they hosted (it
wasn't at the site owner's request; I asked). So I had to use a European-based
proxy for a while to get to it.
Noel
Hello,
I have a couple of Alpha workstations that were last used 5-6 years ago
with some version of Tru64 on them. They haven't been turned on since, and
may need some work to get running again. They're free to anyone who thinks
they can use them, and can pick them up from the 78722 zip code (near UT
Austin). Please contact me off-list to co-ordinate pickup.
Thanks,
Arun
Is there some trick to making boot floppies for the RS/6000 7043-140 (a
mid-90s PReP architecture machine)?
I initially tried to install Solaris 2.5.1 on it and created the boot
floppy by dd'ing the image using a SPARCstation (running NetBSD). I
dd'ed the image over, dd'ed it back and verified the SPARCstation could
read back what it had written to the floppy. The RS/6000 loads what is
on the floppy, but hangs transferring control to what it loaded.
The 7043-140 does not appear on the list of supported systems in the
Solaris 2.5.1 release notes, so, even though 2.5.1 supports PReP and the
7043-140 is a PReP machine, maybe they aren't compatible, so I tried
NetBSD. The 7043-140 is listed as a supported system.
The NetBSD boot floppy images are confusing to me. The files are too
large to fit on a 1.44M floppy. I didn't see instructions on how to make
boot floppies out of the .fs files one can download in the install
instructions. I went ahead and tried to dd the part that fits onto a
1.44M floppy and try to boot that and of course that failed. I have
e-mailed the NetBSD prep mailing list and no response from that.
The system does boot the AIX install on one of its hard disks, but this
is a recycled system and I don't have usernames/passwords for that install.
Does anyone here have a suggestion on how to proceed?
alan
Ah, cool thanks!
I'm interested in storing arbitrary files in the manner close to the
original as possible. Sounds like the extent list and allocation map would
be useful for this; not so much the document content format.
--
Anders Nelson
+1 (517) 775-6129
www.erogear.com
On Tue, Feb 19, 2019 at 2:44 PM Chuck Guzis <cclist at sydex.com> wrote:
> On 2/19/19 11:12 AM, Anders Nelson wrote:
> > Hi again,
> >
> > Is there a description of the DW filesystem somewhere I can look at?
>
> Hi Anders,
>
> Not that I'm aware of, unless Al has some document squirreled away that
> we don't know about.
>
> What I know is from a lot of examining DW floppies and trying to
> reverse-engineer it--and what little I could find on the web.
>
> The DW filesystem is basically a linked-list sort of structure. There's
> a volume header block that contains an extent list and allocation map,
> from which documents are treed from. Each document, in turn, links to
> other entries that describe various properties of each document. For
> example, the dates of the document, its name, the list of positions of
> lines within the document, the document text, the formatting information
> for the text, and so on. It's pretty complicated.
>
> One aside is that even though the DW is an 8086 system, numeric
> quantities are big-endian.
>
> --Chuck
>
>
Guys,
I am wanting to determine which CDC (or possibly other) computer some of my
modules came from. If you were a CDC employee around the time of CDC 6xxx
computers, let me know where I could send my photos for identification of
these items.
Many thanks,
peter
|| | | | | | | | |
Peter Van Peborgh
62 St Mary's Rise
Writhlington Radstock
Somerset BA3 3PD
UK
01761 439 234
|| | | | | | | | |
Hi friends,
Now that I have my glorious disk toaster (2D model I think, says "2D" on
the drive levers), I want to build a controller for it. I found pinouts and
some description of the media organization here:
http://bitsavers.trailing-edge.com/pdf/ibm/6580_Displaywriter/S241-6248-3_D…
I'd like to actually store data to these disks in the same manner the
original systems did, and I'm proficient in hardware/firmware. Has anyone
made a controller for this already? How about emulating the filesystem?
Any help is appreciated, and I'd open-source whatever I make (PCBs,
firmware, etc.).
Thanks!
--
Anders Nelson
+1 (517) 775-6129
www.erogear.com
Hi everyone,
I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay
them a visit. I'm taking pictures of as much vintage computing gear as I
can as we speak. I'll be here until they close today at 5pm EST, so if you
see something you like feel free to give them a call and I'll help them
navigate.
Photos updated as I walk through, here:
https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8
If you see something you like it'd be great if you could check if I'm
interested first until I'm finished today. ;]
Hope this helps someone, they shut down soon!
> On Feb 18, 2019, at 11:00 AM, dwight wrote:
>
> There were a couple hp XY plotters that had the mylar plate delaminating. I've reworked these with model airplane mono coat.
Are you referring to MonoKote (www.monokote.com <http://www.monokote.com/>)? That looks perfect for repairing the gouged bed of one of my 9872C plotters. Is a hot air supply suitable for applying the film, or did you use their heating iron? I'm guessing a bit of pressure to adhere the film is necessary?
Oops, this was meant to go to the list _and_ William. Sorry for duplicate Will.
At 09:10 AM 18/02/2019 -0500, Will wrote:
>> I see 4 Boxes of punch cards. All blank?
>>
>> https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHb…
>>
>> Too bad he wants $25 a box.
>
>25 dollars for a full box of blank cards is actually a really good
>price - but those cards are probably too far gone. Jam city.
Maybe, maybe not. And there they are, as opposed to being mythical, somewhere else.
Anyway, if someone was to go to Kemners and offer $10 a box for all 4, arguing that
"they are pretty far gone, jam city, dusty, in a mess, maybe some blocks are OK, etc."
Then I'd pay for them and pack & postage to my US reshipper in CA. At this address:
Guy Dunphy
3503 Jack Northrop Ave
Ste J8637
Hawthorne, CA 90250
USA
And then be facing the postage to Australia too. Hence my low offer.
Reason: As part of the Australian Computer Museum Society equipment dispersal, I have
an IBM 028 and three IBM 026 card punches to restore. Eventually.
Plus that Documation TM200 card reader. Which I'm still seeking a manual for btw.
Guy
At 01:51 PM 16/02/2019 -0500, you wrote:
>Hi everyone,
>
>I heard Kemners Surplus in Pottstown, PA was going away so I decided to pay
>them a visit. I'm taking pictures of as much vintage computing gear as I
>can as we speak. I'll be here until they close today at 5pm EST, so if you
>see something you like feel free to give them a call and I'll help them
>navigate.
>
>Photos updated as I walk through, here:
>
>https://photos.app.goo.gl/4Q8Jx7n36fmVczLN8
That's a lot of visual fun, thanks for the photos. There is NO SUCH THING in Australia.
There were still a small number when I was a child (1960-70s), all long gone now.
>If you see something you like it'd be great if you could check if I'm
>interested first until I'm finished today. ;]
>
>Hope this helps someone, they shut down soon!
I see 4 Boxes of punch cards. All blank?
https://photos.google.com/share/AF1QipN-btB2yizsHBmabHb7xtHr_zUWZlS6QENHMHb…
Too bad he wants $25 a box. And it's on the East coast, not West coast near my LA reshipper (to Australia.)
And I'm near broke again, after this:
http://www.eevblog.com/forum/testgear/hp-8594e-spectrum-analyzer-at-last-i-…http://www.eevblog.com/forum/repair/hp-8594e-spectrum-analyzer-repair-%28i-…
Guy
Of all machines I've used, the beloved Atari 8-bit is most vocal. It
has the feature of 'i/o noise' by default. It can be disabled with a
Poke, but every kind of io has distinctive sounds and actually
represents the data being sent/received. If you disable it and crank
the volume on your TV, you can STILL hear it, but very muted. I think
this feature was created to conceal this fact...
It isn't just the Atari8 that has this 'feature' in its muted version,
all of the RF-TV-type machines from the 80's produce it. In theory, I
think you could snoop the actual data, Tempest-like, using some radio
gear.
One gets very attuned to the noise and can tell the type of data being
sent, (Text, vs Binary, for example) by ear. Of course, tracking
noises from floppies and hard disks are also very useful indicators.
In the 90's I got the hpfs386 driver out of a warp server pack and hung
it on my warp 4 client. I LOVED hearing it hit the drive at boot. Boy
howdy what a performance increase that gave.
Best regards,
Jeff
On Fri, 2019-02-15 at 12:00 -0600, cctalk-request at classiccmp.org wrote:
> Speaking of sounds made by machines
Hi folks,
I think the NI Ethernet device is ready for some real world beta
testing. I have put up a page here with details about how to build SIMH
and how to install the "NI" ethernet drivers and TCP/IP software here:
https://loomcom.com/3b2/networking.html
If you're interested in helping out, you can build the current "3b2-ni"
feature branch from GitHub and give it a test. If you run into any
problems, I'll walk you through how to do some debugging and get logs
for me to look at.
If you have any questions or need any additional help, please don't
hesitate to email me!
Best Wishes,
-Seth
--
Seth Morabito
Poulsbo, WA, USA
web at loomcom.com
Has anyone been successful in dumping the EPROM contents from an MC68701?
As I understand it, this MCU requires executing a particular program from
external memory to access the internal EPROM, both for programming and
reading.
I will write a utility to dump the contents if necessary, but I am happy to
refrain from reinventing the wheel if a solution already exists.
Thanks!
Kyle
> > On Fri, 2019-02-15 at 12:00 -0600, cctalk-request at classiccmp.org wrote:> > as
These hardware wizard stories remind me of a legendary repair wizard,
> non-computer industrial devices I think. He was called in to fix a
> tricky problem at the customer site. Studied it for a while, took
> out a small hammer, whacked the device at some spot, and reported
> "fixed". He then sent in a bill for $500
That has been my line any time I've needed to know if a machine had a
'flaky'. Sometimes, on the phone, ask a customer to give the machine a
kick. They always balk, but I tell them "Shock and vibration are
legitimate diagnostic tools", and that usually convinces them. In
situations I suspect the problem is a flaky, it often results in a
'working' system and the customer says "oh wow! you Fixed it!". To
which I say NO NO NO. It is not Fixed, only the problem is now
revealed. I'll be over shortly to actually bolt down what needs
bolting or otherwise make the machine immune to shock and
vibration.....
Best,
Jeff
Hello, I need to do some work on my intel UPP-833 personality card in my UPP and am looking for documentation
This document:
9800133F_Universal_PROM_Programmer_Reference_Manual_1977
has schematics for personality cards available in ?77 but does not include the UPP-833
I am having trouble with my UPP-833 and could use some documentation. Documentation on the UPP-832 would probably be helpful if nothing on the 833
There may be a newer version of 102448-001 I do not know about. There are two Documents that should have the information are:
102448-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966
123832-001. Printed Wiring Assembly UPP-833 Personality (drawings and schematics), L1002488, 123832, 2000966
Can anyone help?
Regards
Craig
Sorry, moderation fail. Forwarding to cctalk:
-------- Forwarded Message --------
Subject: Latest Batch of Items from Sellam's VWoCW
Date: Fri, 15 Feb 2019 20:27:12 -0800
From: Sellam Ismail via cctech <cctech at classiccmp.org>
Reply-To: Sellam Ismail <sellam.ismail at gmail.com>, General Discussion:
On-Topic Posts <cctech at classiccmp.org>
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Hello Folks!
I've put together another batch of items as I continue to wade through my
warehouse and winnow out the wonders:
HP 2116C System Manual #1
HP 2116C System Manual #2
HP 2116C System Manual #3
HP 2116C Power Cord
Using the HP 3000: An Introduction to Interactive Programming
Tandy WP-2 Portable Word Processor
M7859 KY11-LB Console Interface
Kraft 3-button PC Mouse
Mouse Systems 3-button PC Mouse
Zenith Z-Box External ISA Expansion Chassis
Novell IBM NIC ShareNet Board
Epson External 5.25" Floppy Drive
SuperMac Technology DataFrame DF20 20MB external hard disk
ClubMac C104 External SCSI CD-ROM Drive
Midiman Mini MacMan Macintosh MIDI Interface
Passport MIDI Interface for Macintosh
Neutronics Hexadigit S-100 Bus Monitor
Gimix Ghost 32K RAM
Compaq SLT/286 portable
VTech The Equalizer Laptop
IBM Model M Keyboard
IBM Model M Keyboard
IBM Model M Keyboard
IBM Model M Keyboard
The main index for these and other fine items is here:
https://docs.google.com/spreadsheets/d/1I53wxarLHlNmlPVf_HJ5oMKuab4zrApI_hi…
I've put some work into the index and improved it so that links keep
properly updated as new items are added or sold items are removed (whereas
before the index links in the New Arrivals Niche would get hopelessly out
of sync). However, I believe there might have been some problems with the
links before so if you saw an item you liked and the link did not lead to
it and you assumed it was sold, please check again. From this point going
forward, all links (above the notice in the sheet) should stay in sync.
I've been preoccupied for the last few months with personal business and
haven't been able to put a lot of time into curating the collection for
sales but I am trying to catch up. There are a couple people that are
waiting on me and I haven't forgotten about you. I will get caught up
shortly and I thank you for your patience.
As always, please contact me directly by e-mail via
<sellam.ismail at gmail.com>
to make an order or an offer.
Thanks!
Sellam
Does anyone have documentation stashed away for the Intel PC-BUBBLE Card? The PC-BUBBLE is an 8-bit ISA card that Intel produced for prototyping bubble memory applications in the mid-1980s, the ROM on mine is v3.0 and says it?s copyright 1986.
I don?t want to insert this into a system until I?m sure all the (many) jumpers are configured reasonably, and I?m sure that the empty 40-pin socket at U5 isn?t something that?s critical to its operation?
-- Chris
At 01:17 AM 2/15/2019, Randy Dawson via cctalk wrote:
>What we have, is the screen time problem with the kids. If we are not there hounding and policing them, they will be on for hours.
There are also consumer firewall/routers that have time-based limits.
When I've had clients ask about this, or also ask for content filtering,
it's such a difficult world these days. The kids don't have tablets
or phones or iPods that do WiFi and can get the Internets from
cellular connections or the neighbor's WiFi?
Kids rapidly figure out solutions to bypass limits. High schools
have WiFi, block social media, the kids install VPNs on their phones.
- John
Before I develop this, I thought it may already exist, and the classiccmp mail list might be the place to ask.
What we have, is the screen time problem with the kids. If we are not there hounding and policing them, they will be on for hours.
All the medical community says, we need to limit their screen time, as it contributes to their AD disorder and schoolwork, homework failures.
My idea was initially do this in hardware, with a timer, and a solid state relay to gate the AC to the PC.
On further thought, I should be able to do this in software, with a timer that lets the PC run for an hour, and then shuts the PC down until the next 24 hour cycle.
(Installs itself on windows startup)
Has anybody seen this, before I re-invent the wheel?
Randy
> From: Paul Koning
> Studied it for a while, took out a small hammer, whacked the device at
> some spot, and reported "fixed".
That reminds me of an amusing story from the first time I went to see 'Star
Wars; I went with a group of people from Tech Sq. It has that scene where
they're about to make the jump to hyperspace in the 'Falcon', and it won't
go; so one of them (I think Solo) jumps up and whacks a particular spot on
the bulkhead with his fist, and away she goes.
We all found this terribly amusing, since one of the DEC time-sharing systems
on the 9th floor had a sticky relay in the power controller, and when you'd
try to power it on or off from the front panel, the relay would stick, and
nothing would happen. So the procedure was to go around the back, open a
particular door, reach in, and whack the power controller behind it in a
particular spot with the side of your fist, and away it went!
Noel
> From: Paul Koning
> or a backup team of subsystem experts at the home office to call on.
Actually, the actual hardware problem wasn't too hard for Fritz to find, I
gather, once we knew exactly was failing (the RK11), and how (at 0170000, the
XM incremented). It's not like it was a comes-and-goes kind of problem (it
was quite solid and repeatable), or anything like that, so I'm not sure a
'team of experts' would really have helped.
And the exact details on the failure were also pretty easy to find, once we
got past a lot of other distractions! Once it became clear that the pure text
was getting trashed, it was pretty easy (modulo some confusion caused by the
differing OS images in the 'Ritchie' and 'Wellsch' distros :-) to stop the
machine once it had a) assembled the pure text in main memory, and b) swapped
it out.
Looking at the copy in main memory verified it was good _before_ it was
swapped, looking at the arguments on the stack gave us the disk block it was
written to, and looking at the actual contents of the RK (which PDP11GUI has a
mode to do) showed us the first 02400 bytes were good, and then it was
trash. Bingo!
Then, looking at the RK registers after the transfer had completed showed
something had gone wrong in the hardware - the address left showing
afterward was not the start_address+size - the XM had incremented
inappropriately! And since the start address for the transfer in physical
memory was 0165400, and 0165400+2400 = 0170000, that sounded pretty
suspicious!
So, that all happened pretty quickly. Really, the part that took the longest
was getting past all the confusing noise: my confusion about R5, the
malfunctioning front panel, the different versions of the OS, etc, etc.
Noel
> Message: 2
> Date: Wed, 13 Feb 2019 15:03:41 -0500
> From: Paul Koning <paulkoning at comcast.net>
> To: Jay Jaeger <cube1 at charter.net>, "General Discussion: On-Topic and
> ??? Off-Topic Posts" <cctalk at classiccmp.org>
> Subject: Re: PDP-11/45 RSTS/E boot problem
> Message-ID: <C07861A6-BFD8-4AD0-AAB9-F4715904BB60 at comcast.net>
> Content-Type: text/plain;??? charset=us-ascii
>
>
> > On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk
> <cctalk at classiccmp.org> wrote:
> >
> > ...
> > Maybe that story about FE's using Unix as a test to confirm operation
> > even when diagnostics said the machine was OK was not so much just a
> > legend?
>
> It still fels like a legend.? My experience with DEC field service
> engineers is that they used the diagnostics.? In the PDP-11 era, Unix
> knowledge around DEC was pretty sparse, especially early on when it
> could be found only in the Telephone Products Group (Armando
> Stettner).? RSTS would be more plausible, but I never saw that in the
> hads of FS engineers either.
> By and large diagnostics would find problems. I've seen a number in
> the 1970s, including a messy data path failure in the 11/45 MMU where
> we (college students) did the initial diagnosis while the FS engineer
> was on his way. My suspicion is that things not solved by diagnostics
> would be escalated to the "wizard from Maynard". And they'd probably
> start replacing whole subsystems. I've seen that once, when our
> college RSTS-11 system (11/20, 16 DL-11 lines) was crashing on average
> once a day for months. DEC brought in several of those "wizards". The
> "fix" was to replace the 11/20 by a "spare part" -- an 11/45 with more
> memory, a DH11, and RSTS/E. Decades later I was told that the wizards
> actually pinned the blame on the college FM broadcast transmitter,
> about 200 feet down the hall from the computer center. That may well
> be, though I didn't heard that at the time. RSTS did get used in
> manufacturing, at Final Assembly & Test sites like Westminster MA and
> Salem NH, where PDP-11 systems large enough to run RSTS/E were
> subjected to a load test of exerciser programs running under that OS.
> The way it was explained to us is that a system that would be happy
> with such a test would also be happy with any customer application.
> It's not clear if that was because RSTS would load things more than
> most, or was more finicky about hardware glitches than most, but it
> certainly was the practice for quite some time. Of course, not all
> PDP-11 configurations could be tested that way. paul
I guess the experience in NJ was a bit different since AT&T had two
dedicated Field Service offices who handled their sites including Bell Labs.
I was on the Commercial/Government side from 81-86 and we didn't get to
play with RSTS on customer sites at all (but sometimes we got to play in
the in-house machines in Princeton or on our own hardware).
It was a bit different in the Vax side since many diags were run under
VAX/VMS and as a brand new hire I was doing Vax installs -- including
installing the VMS 2.x and 3.x on 11/780's and 11/750's at install time.
If they had paid for software installation -- the software guys would
wipe and reinstall.
If not we left the pack and prayed the customer wouldn't wipe the diags
that we installed on the disk when we build the VMS pack.? Realistically
the only thing the customer needed to do after we got done was tweak the
systen parameters, check the swap etc. and lay on the layered products
like languages.
Things got much more interesting when the VMS3.x and 4.x got CI780's and
HSC50's.? That was more involved than the easy VMS 2.x-3.x install.
As far as the 11/70's -- I'm building a pidp1170... My last 11/70
install was around 84 or so when I put in a late DECDatasystem 570 blue
11/70 with the FCC Cabinets at AT&T in Freehold.
As far as the Wizard from Maynard -- one story from my branch support
guy (rumored to be about his
brother on the 11/70 line in (I think in Westminster MA... not Salem or
other NH plants) had an intermittant 11/70 that would crash every couple
of days and they could run all the diags and DEC X11 with no issues.?
They called over their in-house wizard who ran toggle-in programs from
the front panel -- playing the switches like piano keys with both
hands.?? After about a half hour his comment was "Clean the terminator
fingers."
Machine ran like a SOB once the gold fingers were cleaned.
Weirdest 11/70 mess I had was after I left DEC to work for a third party
maintenance group.? Their regional support was in Dallas.? I was in NJ.?
They couldn't find their support guy so they rushed me on a plane to
Chicago to work with two techs who were babysitting a mess they had no
clue on.
The site was WW Granger in Skokie and I arrived at 3AM...? They had a 5
or 6 story warehouse which was a totally robotic automated site picking
water heaters and other industrial equipment from what looked like an
over-sized 6 floor tape library.? Two 11/34's running RSX11 ran the
picker.? One was down for weeks.? Their 11/70 was half disassembled with
two techs working on it.? They were VAX trained at a third party school
but they weren't PDP11 techs.? An RM03 on the 11/34's was down as well.
The 11/70 was a RSTS/E box doing all the billing and inventory for
Granger at the site.
I walked in at 3AM with my Digital truckers cap on and found they
couldn't boot XXDP+ from tape.
The OS wouldn't come up either.
The customer gave me a pile of error logs dating back over six months --
(I think Sept through March) and they all showed memory management error
aborts and retries.
The techs who thought they were changing memory never found the MOS
memory box... they were swapping cache boards thinking they were memory.
Went to 10000 and deposited 014747 and ran it... It either failed on
addresses ending in 0 or 4 or 2 or 6.
The MOS on the 11/70 had two controllers and interleaved the memory.?
Pulled one of the interleave controllers -- ran the toggle in and it
worked.? Aha... bad memory controller.
Booted diags and sent for the board spare.
Decided the RM03 would be a bitch to work on without the tester or tools
and the management found a spare locally at a used DEC joint in the
area.? Swapped the drive once we carried the new one up the stairs.
The 11/34 had a problem... the machine wouldn't boot and the run light
(IIRC) was on all the time.
The machine had two full unibus dd11-dk boxes even though it didn't need
them all.
Terminated at the CPU backplane and did toggle-ins.? OK.? Worked...
jumpered out the next UNUSED segment of the Unibus backplane with a
Unibus ribbon cable and the problem was gone.
The guys had been there over two weeks digging themselves a hole.? Third
party service on DEC stuff varied with the person.? Some were ex-DEC
genius types who were consultant level experts on the hardware.? Some
just knew to swap the board with the Red Led lit.
Another time I ran into an engineer who told me (chip info here faked --
don't pull the prints...too many
years to have kept TE16/TM03 prints).
A call comes in to dispatch with the following information:
"The TE16 at Naval Air Propulsion, Trenton is down.? It doesn't come on
line.? The light is lit but the
system doesn't see it.? I put the board on an
They supposedly changed memory on the 11/70 -- but wextender and U34 pin
12 is low and doesn't go high.
I need someone to come out and change the chip."
I call the site back.? I'm in Princeton 15-20 minutes away.? I get the
customer on line and tell
him I'll be there in 3 weeks or so.? DECservice 2 hour response won't
cover the call since he wants a chip changed in 1985 and we don't stock
them -- so it will be a special source issue for logistics and we'll get
back to him.? Or... I can swap the M8916 Logic And Write board in
about15 minutes.? Does he want it fixed or does he want to prove he
called the correct chip...
Bill
Ken Bush - IT Solutions Specialist
Parallel Technology, LLC
23510 Telo Ave #7
Torrance, CA 90505
310-320-8477 x1
Trillian "kenbush4sun"
Lots of old Sun gear, will configure as requested.
Please contact him directly.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
WTS sun T5220, USED, qty 10, CALL, We have a huge qty of sun available
interested let me know sun equip available now:
1X STORAGETEK 3510 FC
1X x4100 m2
1X sparc t520
3 x enterprise 250
1X SUN SPARC 220r
2 X SUNFIRE V210
4 X ENTERPRISE T5120
1X ENTERPRISE M4000
1X SUNFIRE V4440
1X sunfire V880
3X X SUNFIRE 240
2X SUNFIRE V245
5 X SUNFIRE V490
1X SUNFIRE 280R
3 X SUNFIRE 440
1X SUNFIRE 4200
1X SUNFIRE 4100
1X SUNFIRE X4100 M2
5X SUNFIRE V120
25 X BLADE T6340
1X BLADE T6240
10 X BLADE CHASSIS 6000
2 X BLADE X6220
1X BLADE T6320
10 X BLADE T6300
Daniel Fecteau
6025 Arthur sauv?
Mirabel, Quebec
J7N 2W4
TEL: 450-969-1616 ext 101
Mail: save at savesysteme.com
Does not have to be sold as a lot, you can pick and choose.
Please contact Daniel directly if interested.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Hello Cindy. I did have some of the Sun T5440's in stock. I can cover at
least 4 units that would be configured. The config and cost is listed below.
Let me know if you need the config adjusted in any way. Thank you.
(qty-4) T5440/4x1.4ghz/128gb/2x300gbhd/DVD: $525 each
BEN WILLIAMS
SUN - ORACLE BROKER REP
P: 315-732-1420 EXT.304
F: 315-732-1502
SKYPE: BEN at ADIRONDACKNETWORKS.NET
TRILLIAN: BENANET
Please contact him directly to purchase.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Mainframes and other stuff
Recycle center in NC is willing to save out "stuff" for people.
No, no one can go in the back and scrounge.
No, he does not want a lot of emails from people.
Yes, he gets big blue and orange and beige 6 foot tall OLD mainframes in all
the time. They squash them at the moment.
Yes, he will package small orders, and will properly palletize larger
orders.
Local pick up will be available after the new year.
So, if u can send me a picture with description and some part numbers, along
with what you want to pay, I will consolidate things and make arrangements.
Please don't ask for specific boards from DEC; they don't want to go into
that much detail.
QBUS will mean nothing to him.
Big orange cabinet that says xxxxx is much more likely to get saved.
They are moving to new warehouse 1st of the month, so all this will start
happening after the 1st of the year.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-792-3400 phone
830-792-3404 fax
sales at elecplus.com
AOL IM elcpls
Just outside Dallas is a very large warehouse. I have been there before, and
have posted about it before.
It has been acquired by a recycling company, sort of.
The old man who owns the stuff thinks of the equip as his children.
A week from Sat I will be going to the warehouse with 2 or 3 guys from San
Antonio.
We will arrive about noon, and hire a truck to bring stuff home before it
turns into mincemeat.
He will not sell to the public, but I have a license.
If you want to attend, I can buy stuff for you.
The address is 9525 Skillman St, Dallas, TX 75243
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Ethan Dicks <ethan.dicks at gmail.com> wrote:
> I have had an RK11-C for a long time that I've never tried to
> power up (I got an RKV11-D and used that on Qbus machines
> instead).
Wow, someone else with an RKV11-D! I thought I was the only
person who had one. I modified mine (using the dead bug
technique) to add 18-bit addressing instead of just 16, and
ran it successfully with RT-11 and RSX-11M on my 11/73 system.
I have had DEC people visit my place, look at the RKV11-D, and
say "DEC never made anything like that!". :-)
Alan "and I don't exist either" Frisbie
Previously I have posted some vendors who have old hardware they are willing
to sell.
Earlier this week I was in San Antonio, and I stopped by an old friend to
say hello.
He has several 3174 controllers, and every imaginable add-on available for
them. Pallets of them!
Also IBM 4700 banking controllers, and 1 monitor. No keyboards.
8" floppy drives.
IBM terminals, most models available, $85 tested and working with matching
keyboard, no severe screen burn.
Contact bfloyd at southtexasproducts dot com.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> Calabasas, CA
Well for a change it is someone just next door so I can definitely take a
look. I wonder if they have anything available. Do you have contact
info/address?
-Ali
>
> -----Original Message-----
> From: Ali [mailto:cctalk at ibm51xx.net]
> Sent: Tuesday, February 05, 2019 2:57 PM
> To: 'Electronics Plus'; 'General Discussion: On-Topic and Off-Topic
> Posts'
> Subject: RE: Another dealer going under
>
>
> > I don't get replies from here yet, so I have seen no replies to my
> > posts,
> > nor the posts themselves.
> >
> > There is a shop that has been in biz for over 25 years that is
> closing
> > in
> > California.
> >
>
> Cindy,
>
> Where in CA? It's a big state :)
>
> -Ali
> From: Jerry Weiss
> I am trying to understand how the diagnostics didn't reveal this defect.
Vondada #12: "Diagnostics are highly efficient in finding solved problems." :-)
Noel
[oops, accidentally replied directly instead of to the list]
On 2/13/19 12:54 PM, Ethan Dicks wrote:
> It's interesting that it was a bad 7430 in [your RK11-C]. I find that for equipment of that vintage, my usual suspects are failed 7474s and failed 7440s, probably 80% of the total. Behind that, it goes 7420s and then maybe 7430s.
Looking back over my repair log, my totals just within the RK11-C were:
2x 7430 (M119, M795)
1x 7420 (M141)
1x 7401 (M149)
1x 7400 (M203)
> > > Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
> >
> > No; the RK11 spec says "[the two extended memory bits] make up a two-bit
> > counter that increments each time the RKBA overflows".
> >
> > The actual error turns out to be slightly different to my guess; there's
> > a spurious overflow from the low 16-bit register to these bits at 0170000.
>
> Maybe a problem with E29 or E34 on the M795 module?
I am finding this entire discussion extremely fascinating!
Every day I look forward to reading the latest twists in the
plot. The ideas, hunches, tests, dead ends, and results are an
excellent example of the debugging process.
I am awaiting the exciting Perry Mason style conclusion, where
the guilty chip stands up and confesses on the stand. :-)
Alan "Where were you on the night of the crime?" Frisbie
> From: Alan Frisbie
> I am finding this entire discussion extremely fascinating! Every day I
> look forward to reading the latest twists in the plot.
I forgot to mention the most amazing part of the whole story: he first
acquired the machine while he was a student (I think?) at CMU, decades ago,
and has been dragging it around the country with him ever since!
He's also had to do a tremendous amount of work on it to get it running,
starting with building an entire new power harness. He's also had to find and
fix a long list of failures, all over the machine; there were bad chips on
almost every board in it.
Fritz has written most of the whole adventure up:
http://fritzm.github.io/category/pdp-11.html
it's an incredible story.
Noel
> From: Alan Frisbie
> I am finding this entire discussion extremely fascinating! Every day I
> look forward to reading the latest twists in the plot.
:-)
> The ideas, hunches, tests, dead ends, and results are an excellent
> example of the debugging process.
Yeah, and it was a Duesie of a problem, too.
Although once we got clear of the bad data from the console and my confusion
about R5, and it became clear that in the Unix failure, the pure text was
being damaged, from that point it was pretty straightforward to track it down
(albeit one that needed detailed understanding of how V6 handled pure texts -
and luckily I'd come to understand that part of the system a bit while getting
the QSIC running).
Fritz's lucky discovery, early on, that it was location dependent was also a
big help.
Noel
Hi,
I'm (still) trying to reverse-engineer a ton of M68K ROM code which was
apparently compiled with a circa-1990 C compiler.
Does anyone have copies of any of the following -- or any other C
compilers for the 68K which were around at that time?
* Sierra Systems 68000 C compiler (was part of some Sega Genesis
developer kits)
* HP 68000 C compiler (either the HP 64000 or MSDOS versions)
(I believe this was sold as the "HP B3640 Motorola 68000 Family C
Cross Compiler)
* Lattice C
* Anything not on this list ;)
My game plan is to take the compiled standard libraries from these
compilers and build up some patterns/"fingerprints" to try and make a
better guess at what the code is up to.
I figure if I can at least pin down the stdlib and floating-point code, I
have a better chance at figuring out what the main code does.
I've seen the HP cross compiler manual on Bitsavers, but the compiler
itself doesn't seem to be on bitsavers/bits.
Thanks.
--
Phil.
philpem at philpem.me.uk
http://www.philpem.me.uk/
Does anyone here still actively wire wrap circuits? I am thinking
about dumping my inventory of nice machine pin wirewrap sockets.
Lately they have been selling like lead balloons.
Contact me off list.
--
Will, in the Hudson Valley
jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
> > From: Alan Frisbie
>
> > Harbor Freight sells a nice hydraulic lift table for under $200 that I
> > have found very useful for that sort of thing. It doesn't go up very high
> > (like for the top of a rack), but I used it with some wood blocks
>
> Thanks for the tip! I got one on sale for about US$140; it's _very_ sturdy.
> And the top is just large enough to hold two milk crates (available at
> Home Depot, BTW), so it's guite easy to build up a stack as high as one
> needs to reach the top of a 6' rack.
Thank you very much for the feedback -- it makes me happy when I
know that someone finds my suggestions useful.
I've used the milk crate technique myself, with a piece of sheet
metal on top to make it easier to slide the load off. I hope you
secure such a stack tightly. :-) I used some of the inexpensive
1" wide Harbor Freight cargo straps.
Alan "You can't have too many clamps or straps" Frisbie
https://www.ebay.com/itm/132933407806
this is interesting because of the price and that all of the Sun drives
I've ever come across had the 800bpi option in them
*Eric Smith *writes:
> On Mon, Feb 11, 2019 at 11:18 AM Al Kossow <aek at bitsavers.org <http://www.classiccmp.org/mailman/listinfo/cctech>> wrote:
>
> >/Does it have the 800 bpi option board? />//
> I haven't yet unboxed it. I took photos of the outside of the destroyed box
> to send to the shipper. The front bottom left corner of the 88780 is
> visible through a hole in the box, and is visibly mangled.
>
I acquired mine as a piece of decommissioned hardware where I worked.?
It came home with me in my car.
Some time later (mid 90s) I loaned it to a friend for some contract work
at <a likely-bankrupt public utility in San Francisco>.? I drove it up
there and delivered it on a cart.? The stars, however, did not align for
getting it back to me the same way so they shipped it to me where I
worked.? There was some damage to the plastic front cover and control
panel mounts.? I was able to repair or work around most of it, and the
unit still works fine to this day. (Well, the plastic take-up reel is
loose...)
Pretty much everything I have that could go in a rack I fetched myself
rather than having it shipped to me.? While one can't always do that, I
recently carted home an HP 3455A multimeter from Los Angeles, some 400
miles.? I was already in the area, otherwise I don't think I'd've made
the round trip just for it.
> Based on the service manual, it appears that option 800 requires:
> * buffer PCA 07980-6xx14 (512K) or 07980-6xx34 (1M)
> * read/write/formatter PCA 07980-6xx31
>
Mine has the 800 bpi option.? Not by inspection, but by operation.
--
Jeff Woolsey {{woolsey,jlw}@jlw,first.last@{gmail,jlw}}.com
Nature abhors straight antennas, clean lenses, and empty storage.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
Card-sorting, Joel. -Crow on solitaire
Hey Kyle.
You can narrow things down a bit by removing the optional Z-buffer and
additional bitplane memory (ZB3 and BP4). While that removes those two
masses of memory out of the equation that still leaves the still massive
amount of ZIPP base video memory. for the later Onyx systems I've only seen
pinstriping when the video memory or supporting glue has been allowed to
overheat. I can't recall if it tests the graphics as well but have you tried
running the ide diagnostics in case that refines the error a little?
-John
>I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've
>got vertical lines appearing on the screen, but not everywhere on the
>screen; that seems to hint at an issue with one buffer having bad memory.
>It was especially evident in the flight simulator demo, where alternating
>frames flashed with and without lines.
>
>The ever helpful self test says, "ERROR: Failure detected in the
>Electronics Module (graphics). press <Enter> to continue".
>
>The system is equipped with the ZB3 and BP4 on a GR1.2.
>
>How can I better diagnose this issue? There are so many RAM chips soldered
>on these three boards. Tracking it down to a single chip sure would be
>nice.
>
>Thanks!
>
>Kyle
although? ?I? think? ?most? production? ? for? switch gear? ?was? ?done? ?with the later? ?32? bit? ?unit
Ed#
In a message dated 2/10/2019 12:49:36 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
telephone? gear?
ed#
In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes:Bringing up a bit of an old thread here, as I just picked up one of theseyesterday. Typed in some example programs, which took far too long thanksto a bouncy keypad. But hey, at least it works!
Were there any real applications for the MAC-8? Haven't been able to findmuch.
Thanks,
Kyle
> From: Jerry Weiss
> it is impressive that UNIX booted successfully without tripping over a
> boundary.
Well, V6 is (or can be configured to be) extraordinarily small, so I'm not
surprised it booted OK without going over the 0170000 mark.
I have this persistent memory that the -11/40 in the CSR group at MIT had only
3 banks of MM-L (@16KB each) when I first got there! Which is plausible; the
smallest V6 config would have about 22KB of core text, and about 2KB of
initialized data. If you cut all the parameters to the bone (minimal number of
disk buffers, etc) you could probably get away with say 6KB of un-initialized
data. That would leave you 18KB for user programs on such a system, a bit less
than their recommendation of 24KB minimum for users, but probably minimally
useable.
We quickly added more memory, I'm sure, but I don't now remember how/what!
Later on it was converted to an -11/45, and then we got an Able ENABLE, but
that would have been a couple of years later.
Noel
> From: Jerry Weiss
> Though not a disk controller, the DEC DR11-B/DA11-B would not cross 64K
> boundaries.
Interesting! What's odd is that the DR11-B uses the Bus Interface card (M7219)
>from the RC11 controller, and that _can_ cross moby boundaries, so clearly it
has the right overflow output; someone just decided not to implement it - the
DR11-B sets ERROR instead on an address overflow. Wierd.
Anyway, it will be interesting to see if RSTS operates correctly once this
problem is fixed...
Noel
Greetings to the List -
I am mounting a couple of heavy (130-pounds each) HP7970e tape drives
to a 19" rack.
The screw holes that mate to the standard spaced holes on the right
side of the drive after you open the case are visible and obvious.
However, the holes on the left are hidden under the heavy die-cast(?)
frame of the drive.
Anyone know how to get to those three screw holes with a horrible disassembly.
There has to be a trick to this that I don't see (so what else is new? :)
Best,
Jack
----------------------------------------------------------------------------------
Jack Harper, President
Secure Outcomes Inc
2942 Evergreen Parkway, Suite 300
Evergreen, Colorado 80439 USA
303.670.8375
303.670.3750 (fax)
http://www.secureoutcomes.net for Product Info.
> From: Fritz Mueller
> If, as you are suspecting, we find damning evidence pointing
> specifically to the RK11
I got an update from Fritz. As you all will recall, the problem seemed to be
a corrupted 'pure text'. So the question was 'when was it damaged, and how'.
After some confusion caused by different OS images (the 'Ritchie' and
'Wellsch' distros), he managed to get a look at the text in main memory after
it was first read in from the file system, and before it was swapped out (it
was showing up damaged after a swap out/in cycle); it looked good at that
point. The copy written out to the swap disk however, not so good.
A look at the RK11 registers after the swap-out showed an anomaly; something
about the extended memory address bits? (Maybe a multi-block transfer than
crosses a 64KB boundary? That would explain the address sensitivity we were
seeing.) Hopefully he'll track it to its lair shortly.
We also need to characterize exactly what the fault is, because the DEC RK11
diagnostics weren't finding it, so it seems the diagnostic suite could use an
enhancement....
Noel
> From: Alan Frisbie
> Harbor Freight sells a nice hydraulic lift table for under $200 that I
> have found very useful for that sort of thing. It doesn't go up very high
> (like for the top of a rack), but I used it with some wood blocks
Thanks for the tip! I got one on sale for about US$140; it's _very_ sturdy.
And the top is just large enough to hold two milk crates (available at
Home Depot, BTW), so it's guite easy to build up a stack as high as one
needs to reach the top of a 6' rack.
Noel
> From: Jon Elson
> Likely some disk controllers did NOT SUPPORT crossing 64K boundaries!
No; the RK11 spec says "[the two extended memory bits] make up a two-bit
counter that increments each time the RKBA overflows".
The actual error turns out to be slightly different to my guess; there's
a spurious overflow from the low 16-bit register to these bits at 0170000.
I can see how the diags didn't catch that one! Unless you try a multi-block
xfer that walks across the boundary.... A perfect example of Vonada #12.
Noel
All boards are corroded.
May be some can be saved ?
I am offering :
12002 B XL Ctrl 512 Kb 51x0-013 x = ? Pictures available
12001 C CPU 12001-80001 Has the 1AB5-6001 "HP SoS processor" with Two EPROM ( 12001-80006 and 80007 )
Any interest in imaging these ? BUT, ** I ** cannot do it !
A ser Qty TWO 12005-60010 Has the 1AF5-6001 "HP SoS processor"
HP_IB 12009-6x00 x=? with 1AA6-6004 and 1AC5-6001
12021A Cntrl R 12021-60001 has the 3 Eprom
and Nec P16175-12 / Intel D8291A / ? FD1791A
Eprom : 2116, white ceramic, labeled : 5180 - 0144, 0137, 0136 ( U43, U53, U63 )
Any interest in imaging these ? BUT, ** I ** cannot do it !
Backplane 2 column, 4 row .... a slight scrubbing may be enough
Card Cage, if needed : Fine
Power supply seems in great condition. Will check more closely, if needed.
Battery board !!!!! Only the relays and buzzer can be saved !
Case ?? Who would like a case ?? ;-)
TERMS :
Remember : I live in France ( shipping ..... )
Small item ... free
Medium items ( cards ) ..... shipping cost
Large items .... shipping cost plus a fee for packing material and my time.
Will wait a full week, to see if BOARDS are asked for, before making PARTS available.
Picked up this core memory trainer yesterday. Seems pretty obscure.
http://imgur.com/a/TIOvt7r
Has anyone seen one before? Would love to find some documents someday.
Thanks,
Kyle
I've got a graphics issue in my 4D/35, and I suspect it's a VRAM chip. I've
got vertical lines appearing on the screen, but not everywhere on the
screen; that seems to hint at an issue with one buffer having bad memory.
It was especially evident in the flight simulator demo, where alternating
frames flashed with and without lines.
The ever helpful self test says, "ERROR: Failure detected in the
Electronics Module (graphics). press <Enter> to continue".
The system is equipped with the ZB3 and BP4 on a GR1.2.
How can I better diagnose this issue? There are so many RAM chips soldered
on these three boards. Tracking it down to a single chip sure would be
nice.
Thanks!
Kyle
telephone? gear?
ed#
In a message dated 2/10/2019 12:26:20 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
Bringing up a bit of an old thread here, as I just picked up one of these
yesterday. Typed in some example programs, which took far too long thanks
to a bouncy keypad. But hey, at least it works!
Were there any real applications for the MAC-8? Haven't been able to find
much.
Thanks,
Kyle
there should be a yellow covered 8x11 manual out there if not.. let me know...
Sent from AOL Mobile Mail
On Sunday, January 13, 2019 Jason T via cctalk <silent700 at gmail.com; cctalk at classiccmp.org> wrote:
On Sun, Jan 13, 2019 at 7:47 PM ED SHARPE via cctalk
<cctalk at classiccmp.org> wrote:
>
> If any the? group? gets the? bell mac? we would love? a scan? or? hi? res? photo of that multi? colored? sheet. It? would? look? nice? printed in the? back? of? a? display? of? ? one of these units? here.We? have? 3 of these units as? I remember...? and? actually? when I? get my hands around them one? will be? up? for? grabs. Please? advise? ------Ed# SMECC
Seconded - I have one of these boards (without the fancy case) but I
have zero docs for it, save for what little is online.? The auction
seemed to have a few booklets, as well as the poster.
j
Been catching up on a backlog of scanning, grab what you like. Manuals
indicated with an asterisk are available for cost of packing+shipping
if you want something printed. This offer will expire in about a week
so please indicate interest early.
Burroughs [1]
* B2000_B3000_B4000 Work Flow Language Reference Manual Oct-1980
* B4000_B3000_B2000 Series BPL Reference Manual Jul-1978
* B4000_B3000_B2000 Series Data Management System II Users Manual Mar-1979
* B4000_B3000_B2000 Series DMS II DASDL Reference Manual May-1979
* B4000_B3000_B2000 Series DMS II Host Language Reference Manual May-1979
BJ-8-B8500 System Reference Manual May 1967
Various B6700 manufacturing documents
Burroughs TD700 manuals [2]
TD700 Central Control Schematic
TD700 Display Assembly (Head Unit) A2
TD700 Keyboard Assembly A1
TD700 Logic and Power Supply Assembly
TD700 Power Supply schematic
TD700 PW Board Assembly driver (interim)
TD700 Unit Travel Log
Misc [3]
* Freedom 220 USERS MANUAL Preliminary Edition
* Microsoft utility software package reference manual for 8080
microprocessors 8102-343-04
* The COPS Programming Manual National Semiconductor Feb 1985 [2]
* Users Manual for the VG-920 Terminal (Tentative)
* CPL is a First Aid Kit by Dr AA Grainger UTAS CC
[1] https://drive.google.com/drive/folders/1GXEU_kWWKo4btixnrQLRa5qFjZm9uqCM
[2] https://drive.google.com/open?id=1iihVNRfkd_zX_PwV30gKQTNLzLcnMEvm
[3] https://drive.google.com/drive/folders/1VEiZs1j11VPBYaZrNUaDxSpKWiZasfCC
> From: Al Kossow
> I have a source tape. I'm trying to figure out why modern tar doesn't
> understand it.
I had an issue reading some TAR's of Unix V7 stuff; I brought up an older
version of TAR under Windoze and they read fine with it. I don't recall if I
figured out what the problem was, or if I just wanted the bits, and as soon as
I had them, dropped it.
Noel
> From: Bill Gunshannon
> What about all the cross compilers that ran on PDP-11's?
Good point; by coincidence, I just found the stuff about the 68K
cross-compiler from Alcyon (in San Diego) which we used at Proteon;
it ran on an -11/73 running Ultrix.
According to the ad sheet, it also ran on VAXen, HP9000s, Textronix 8560s,
etc; OS's were various Unix flavours, VMS, VersaDOS, and Regulus.
I have the man pages for it, the assembler and linker, the c.out format it
produced, etc if those are any use/interest.
Noel
> From: Fritz Mueller
> This seems the best place to start with the LA this weekend then.
I'm going to respectfully semi-disagree! I think that at this point there's a
good chance we can localize to within a gate or two before we start applying
test instuments.
My thinking starts with two pieces of data; i) your discovery that when the
MM trap happens, the end of the pure text segment contains a fragment of code
>from 04000 lower in the text, and ii) the data that the location in main
memory where that _should_ have been is full of zeros - i.e. never been
written into.
The latter is, I think, due to the fact that Unix clears all of main memory
on startup; I think it's just chance that that memory hasn't been used yet
for something else, and is still 0's. (Unix does clear main memory in a few
places during regular operation - e.g. when expanding the stack, the newly
added area is 0'd - but in general, e.g. when swapping in a pure text, it
doesn't seem to bother, which makes sense since it's all about to be
over-written anyway.)
Anyway, those two, together with my previous analysis that this was unlikely
to have happened when the text was first being read in from the file, block
by block, lead me to believe that the likely cause is that the BAR on the
RK11 skipped up a whole bunch (setting the 04000 bit at some point) when it
was reading the pure text back in from the swap, and skipped writing into
that zero-filled block of main memory, putting the stuff that should have
gone there up 04000, instead.
(Why it's swapping the text back in is too complicated to be worth explaining
here; anyone who _really_ wants to know should look here:
http://gunkies.org/wiki/Unix_V6_internals
in the last section, "exec() and pure-text images".)
It's easy to confirm all these suppositions/deductions fairly easily, without
having to connect up, configure, etc the LA: we can just stop the machine
after the text is first read in (in xalloc()) from the file-system, and
confirm that the text looks good there; if so, either the swap-out (albeit
unlikely, since that doesn't account for the 0's) or subsequent swap-in had
an issue. The latter would be easy to confirm: just halt the machine after
the text is swapped in, and see what the RK registers contain.
At that point, as I said, we'll know to within a few gates where the issue
is, and then it'll be time to bring out the LA.
Actually, a plain oscilloscope would do; it's interesting to recollect that
these machines were designed and maintained without benefit of a LA, purely
with an oscilloscope! We're so spoiled now! :-)
Noel
> From: Fritz Mueller
> is it possible for you deduce where Unix _should_ be placing these "bad"
> bits (from file offset octal 4220)?
Yes, it's quite simple: just add the virtual address in the code to the
physical address of the bottom of the text segment (given in UISA0). The VA
is actually 04200, though: the 04220 includes 020 to hold the a.out
header at the start of the command file.
So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
obviously an interesting number.
> Maybe a comparison of addresses where the bits should be, with
> addresses where the "bad" copy ends up, could point us at some particular
> failure modes to check in the KT11, CPU, or RK11...
Here's where it gets 'interesting'.
Executing a command with pure text on V6 is a very complicated process. The
shells fork()s a copy of itself, and does an exec() system call to overlay
the entire memory in the new process with a copy of the command (which sounds
fairly simple, at a high level) - but the code path to do the exec() with a
pure text is incredibly hairy, in detail. In particular, for a variety of
reasons, the memory of the process can get swapped in and out several times
during that. I apparently used to understand how this all worked, see this
message:
https://minnie.tuhs.org/pipermail/tuhs/2018-February/014299.html
but it's so complicated it's going to take a while to really comprehend
it again. (The little grey cells are aging too, sigh...)
The interesting point is that when V6 first copies the text in from the file
holding the command (using readi(), Lions 6221 for anyone who's masochistic
enough to try and actually follow this :-), it reads it in starting from the
bottom, one disk block at a time (since in V6, files are not stored
contiguously).
So, if it starts from the bottom, and copies the wrong thing from low in the
file _up_ to VA:010200, when it later gets to VA:010200 in the file contents,
that _should_ over-write the stuff that got put there in the wrong place
_earlier_. Unless there's _another_ problem which causes that later write
to _also_ go somewhere wrong...
So, I'm not sure when this trashage is happening, but because of the above,
my _guess_ is that it's in one of the two swap operations on the text (out,
and then back in). (Although it might be interesting to look at PA:165600 and
see what's actually _there_.) Unix does swapping of pure texts in a single,
multi-block transfer (although not always as an integral number of blocks, as
we found out the hard way with the QSIC :-).
So my suspicions have now switched back to the RK11... One way to proceed
would be to stop the system after the pure text is first read in (say around
Lions 4465), and look to see what the text looks like in main memory at
_that_ point. (This will require looking at KT11 registers to see where it's
holding the text segment, first.)
If that all looks good, we'll have to figure out how to stop the system
after the pure text is read back in (which does not happen in exec(),
it's done by the normal system operation to swap in the text and data
of a process which is ready to run).
We could also stop the system after the text is swapped out, and key in
a short (~ a dozen words) program to read the text back in from the
swap device, and examine it - although we'd have to grub around in the
system a bit to figure out where it got written to. (It might be just
easier to stop it at, say, Lions 5196 and look at the arguments on the
kernel stack.)
> a suggestion here to check the KT11 address translation adders ... A
> bug in one of the carry lookahead generators used between the bit
> slices of that adder could cause a mistranslation on only a fairly
> selective subset of virtual addresses
This could be happening, but from the reasoning above about the order that
the blocks of the text are read in, something would have to interfere with
the later read of the higher memory blocks, too, no? So I'd discount the KT11
_for the moment_.
> *IF* that's the case and we can chase the IR trace upstream to the
> place of an unlucky mistranslation, it will be pretty easy to track
> down then in the hw and fix.
It'll be interesting to look at the text after it's read in (i.e. before it's
swapped out). If it's OK there, that's pretty conclusive that it _can't_ be
the KT11 - because from then on, the kernel doesn't _do anything_ to that
binary, except swap it out and in with the RK11. And since those are both
single I/O operations (with swapping on the RK11, at least, which can do
multi-block transfers), _and_ the bottom of the text segment comes in OK (so
the RK11 is being set up with correct disk and main memory addresses for both
the out and in), I can't think of a fault _elsewhere_ in the system that
could cause that 'stuff winds up in the wrong place' error.
I know this is complicated, but look at the bright side: we started with
three apparently un-connected problems:
* R5 trashage
* an 'impossible' MM fault
* bad text data
The first one turned out to be non-existent (my fault in interpreting the
kernel stack in the process core dump), the second was also not really there
(although a hardware fault in the console gave us bad data, so there really
was a hardware issue there), and now we're down to one - albeit a tricky one.
So we were dealing with two un-related hardware problems - now we're down to
one, and hopefully soon will have it isolated to a single sub-system!
(And thanks to whoever gave us the voltage tip, that fixed the first one.)
Noel
On Fri, 2019-02-08 at 12:00 -0600, cctalk-request at classiccmp.org wrote:
> Re: Looking for: 68000 C compilers
There is a GNU OS for the Atari 68k-based ST, TT, and Falcon computers
which might be fun to play with. It is called MiNT. FreeMiNT and
SpareMiNT are two distros. They are available. Aranym/Afros are
current projects. Of course tools are available within.
Best regards,
Jeff
For those who are intrigued by the VAX-11/780, here:
https://www.ebay.com/itm/321399703349
If you can't have a real 780, at least you can have the prints! :-)
Noel
Jack Harper <harper at secureoutcomes-hq.com> wrote:
> I got both drives into the rack this past weekend and I am an old guy
> (67) - I carefully stared at the thing before I started and finally
> figured out that I could, in fact, lift the drive from a waist high
> cart for a few seconds, but definitely could not lift it or lower it
> vertically with my arms - no way - and I would have one shot at
> getting the drives into the rack on the rails.
Harbor Freight sells a nice hydraulic lift table for under $200 that
I have found very useful for that sort of thing. It doesn't go up
very high (like for the top of a rack), but I used it with some wood
blocks to lift a DEC ES45 Alpha system into a rack by myself.
500 pound capacity, 28.5" lift height, $170
https://www.harborfreight.com/500-lbs-capacity-hydraulic-table-cart-61405.h…
1000 pound capacity, 34.5" lift height, $260
https://www.harborfreight.com/1000-lbs-capacity-hydraulic-table-cart-69148.…
Alan Frisbie
Hi Cindy,
Thanks for the email. We have a large inventory of HP gear in Minneapolis. I
have a lot of older HP stuff too from the 1980's and 1990's to current. I
don't know what you are looking for HP1000's? old workstations and servers?
Here is our store but I only listed a very small amount of our stock.....
https://store.flagshiptech.com/
Brad Ziton
HP Product Manager
SKYPE: bradz at flagshiptech.com
Trillian: BradZFTI
bradz at flagshiptech.com
3939 County Road 116
Hamel, Minnesota 55340
(800) 416.8900
t: 763.516.1346
f: 763.516.1310
c: 612.708.3960
RS/6000 pSeries ? AS/400 iSeries ? Sun Microsystems ? HP9000 ? HP Proliant ?
Cisco ? Dell
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
I'm wondering if anyone knows of any CP/M software using GSX-80, which
could be an interesting demo, or game. I have found Kasekastchen (
http://atariage.com/forums/topic/244781-kaesekaestchen-a-new-gsx-based-game…)
(misspelled without accents to make the mailman happy), but it mostly just
freezes after loading GSX-80 on my TS-803 so far (under the 'remote
processor' version of the OS at least).
Thanks,
Pat
> From: Jon Elson
> I'm thinking it is bad memory. ... I think it is just a bad memory chip
Nothing so simple, I'm afraid! The memory actually contains:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
and it's _supposed_ to be holding:
PA:171600: 110024 010400 000167 000016 010500 010605 010446 010346
This together with Fritz's discovery of that first 'bad memory' pattern _elsewhere_
in the binary for the command makes it look pretty likely that some sort of other
error has wound up with stuff being put in the wrong location.
Noel
I know there's an old (I think) official Sega Genesis devkit that's,
erm, "around" on various console homebrew sites. No idea which exact C
compiler is included, but it's not too difficult to find.
> From: Brent Hilpert
> what about the refresh circuitry of the memory board?
> ...
> It might also explain why a number of 4116s were (apparently) failing
> earlier in the efforts ... replacing them might have just replaced them
> with 'slightly better' chips, i.e. with a slightly longer refresh tolerance.
Ooh, excellent idea!
Noel
> From: Fritz Mueller
> It looks like the question boils down to either "how did that part of
> the binary get to that part of memory?", or "how did we end up
> executing out of that part of memory?"
More the former, I think.
UISA0 contains 001614, and physical memory at 0161400 does contain the first
few instructions of the command's binary, so that 01614 is probably correct
for the base address of segment (page) 0, which contains all the code for the
command. (Without looking through the OS's guts, I can't confirm, from interal
data structures, that that's where it decided to put the command's binary.)
The PC at fault time is 010210, which is correct for the frame setup
function, CSV; and looking at the contents of the stack, registers etc makes
it pretty certain it had just done the "JSR R5, CSV" to get there. And
0161400 + 010210 = 0171610, which contains something completely different
>from what's in the command binary at 010210!
> Could still be a memory issue _elsewhere_ that lands us there, of
> course... Could also be a translation error lurking in the KT11, or a
> CPU bug not found by any of the DEC diagnostic suites.
Yup. Like I said, good news is we're down to one problem; bad news is it's
a Duesie!
Noel
> From: Mattis Lind
>> we've also looked at what's in memory at that location, and the low
>> part of the text segment seems to be correct, but there was junk at
>> the top, around the target of the JSR (i.e. at 'csv'). Not just one
>> word, but everything around that location was wrong, which would
>> suggest to me that the cause is not a simple memory failure there.
>> I've suggested to Fritz that we look at that again, to see if what was
>> recorded before is accurate
> Would it be possible to insert a breakpoint or halt and run the
> program, insert original instruction and single step?
I'm not sure that's going to tell us much: the latest development is that
Fritz looked at the actual memory contents again, and it is once again
trash; _almost_ identical to what was there before:
PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144
but with some extra 010000 bits:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
(It's not clear if this represents a real difference, or if that
front panel issue Fritz mentioned caused the contents to be displayed
incorrectly.)
The exciting thing is that if the latter really is what's in main memory,
that '16700 16152' at the PC of the MM trap could indeed generate the MM trap
we're seeing: it's "MOV 26364, R0", and that address is in segment (page) 1,
which is only 03500 long....
If so, i) we're down to one problem (good news), and our problem turns into
finding out how that section of the code got trashed (bad news). Which is not
going to be simple, alas, I suspect. I don't think it's the RK11, because
Unix reads the program image into system buffers in low memory, and that's
clearly working OK in the 'sleep;ls' case. (It may not use the exact same
buffers, though...) It then copies it out to the memory where it's going to
execute from, using an MTPI loop. So maybe the memory still has issues, or
maybe the MTPI isn't working with some main memory locations or or or...
Noel
This keyboard has now been sold!
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Leslie is preparing a list.
She has also contacted another friend who is quitting the biz, to see if
they want to get rid of equip.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
1 keyboard PN 3201072-01 still in plastic and foam (Type 5)
1 metallic type mousepad, never used
1 mouse 370-1170-01, used
1 cable 530-1594-01 used
1 cable 530-1662-01 new
1 cable 530-1442-02 used
1 battery holder that is plugged into the 530-1594-01, used, no battery
installed
These are in my stock. All fits in one box. Make offer.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Pics of equipment on request .
Hi, we occasionally get some.
For example, we have the following:
2x Phones ROLM 61000 in boxes (see photos) ('86 year of manufacture); Bunch
of (see photos):
FAX-MODEM USRobotics 33.6K Model 0459 PN: 00083907
FAX-MODEM USRobotics 56K Model 0701 PN: USR5686D
FAX-MODEM USRobotics 56K V.92 PN: 5686
Let me know what you think.
I'll keep you posted on any antique equipment we will be receiving.
Nick Makarovskiy,
nick at ictcompany.com
Office: +1-781-912-1717 x 710
Direct:+1-781-912-1710
Cell/WhatsApp: +1-617-309-8705
400 Tradecenter, Ste 5900
Woburn MA 01801
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> From: Phil Pemberton
> * Anything not on this list ;)
The TRIX project at MIT-LCS did a 68K compiler very early on (soon after the
first 68K wa released)x, using Steve Johnson's Portable C Compiler as a base.
Noel
At 12:26 PM 2/6/2019, Ethan Dicks via cctalk wrote:
>OTOH, at home, I'd had an Amiga since 1986 and used a variety of
>native tools (Lattice C later SAS/C, and various assemblers either
>commercial or from a Fish Disk).
Somewhere I have the DOS-hosted C compiler for the Amiga that was part
of the first developer kits. I think they were Sage-hosted for a while, too.
- John
Preowned Barcode Ltd
John Gallant
Halifax NS Canada
PH (902) 468 8210
Cell (902)719 6031
Email: sales at preownedbarcode.com
This gent has stuff from the 80s and 90s in the barcode and scanner
departments.
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Last May Steve auctioned off the assets, and and printer/plotter co bought
the name and website. Steve retired to Hawaii. All is gone L
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> Date: Sun, 3 Feb 2019 22:22:42 +0100
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Looking for Limited Function Board
> Message-ID: <20190203212242.GF24947 at Update.UU.SE>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> I'm restoring a PDP-8/a with the help of some
> friends. The CPU is now passing the MAINDECs I've
> thrown at it. The memory is a modern semiconductor
> board my friend Anders Sandahl made.
>
> This machine is pieced together from several others
> and the limited function panel I got does not match
> the backplane I have.
>
> My theory is the DEC simplified the design of the
> boardto cut costs and simpler design is not
> compatible. Mine is labeled (on the PCB):
>
> "LIMITED FUNCTION BD.
> 5411507
> 5011506C-P2"
>
> And the one I need is:
>
> "LIMITED FUNCTION
> 5411165
> 5011167"
>
> However, the picture I have of the other is not so
> good. I may have read the numbera wrong.
>
> I would very much like to buy one to finish this
> project.
>
> /P
F?r du inget napp s? ritar jag upp ett kort till dig, det borde g? att
flytta ?ver brytarna fr?n det du har. Lite synd att scrappa ett
originalkort bara, men ?r man f?rsiktigt s? man inte tar s?nder det s? g?r
det ju att ?terst?lla...
/A
> From: Paul Koning
> Another possibility occurs to me: bad bits in the MMU (UISAR0 register
> ... if UISAR0 has a stuck bit so the "plain" case maps incorrectly
> you'd expect to come up with execution that looks nothing at all like
> what was intended.
One would hope that the DEC KT11 diagnostic would check for this... but just
to be thorough, we have in fact written a short diagnostic which stores every
possible value in each UISA register and checks that it's correct. So unless
there is some sort of pattern sensitivity (e.g. when A is in UISAm and B is in
UISAn), that's not it. Also, and perhaps more significantly, when checked
after the trap happens, all the UISA registers and all the KISA registers
contain correct data. So, unless it's something where _sometimes_ one reads
UISAn and gets X when it actually contains Y, I'm not sure the SARs (PARs) are
involved.
> From: Jon Elson
> OK, here's a really complicated thing to try. If you know the physical
> memory address of ls when it has the problem
We do (see above), and we've also looked at what's in memory at that
location, and the low part of the text segment seems to be correct, but there
was junk at the top, around the target of the JSR (i.e. at 'csv'). Not just
one word, but everything around that location was wrong, which would suggest
to me that the cause is not a simple memory failure there.
I've suggested to Fritz that we look at that again, to see if what was
recorded before is accurate (i.e. if we see the same wrong contents), to make
sure we didn't make a mistake somehow.
> write a machine language program that loads a copy of ls into that
> location and then tries to read it back.
Yeah, it may come to that. One issue we've been having is doing specialized
test programmes; trying to run the C compiler fails. I don't know about the
assembler, though. And as Fritz mentioned, it takes hours to load a new disk
image. I think we've come up with a way around that, though; produce binary
of stand-alone tests elsewhere (I've often/always got a v6 running on
Ersatz-11 here), and load them into the /45's main memory with PDP11GUI.
Noel
So I've been helping Fritz look into his -11/45 problem, and things have
gotten to a point where I'd like to reach out for help, more eyes, etc.
I have to say, I spent almost a decade at the start of my career working on
PDP-11 hardware ('new build' DMA devices, as well as fixing broken stuff), and
software, and this is, I think, the most confusing and difficult problem I
have _ever_ seen on one. Hence the above...
What's _particularly_ confusing and difficult is that it seems like _three_
separate, un-related things all go wrong at exactly (2 of 3) or close to (the
other) the same time. And the machine now passes all the diagnostics that have
been thrown at it, particularly the KT11 and RK11 diagnostics (why this is
important will become clear). So here's what we've found to date.
The failure we're looking at is that an attempt to execute the 'ls' command
under Unix V6 fails; it gets a memory mangement fault, and dumps core.
AFAICT, the shell successfully forks, and its attempt to do an exec() of 'ls'
sort of works (more below), but a few instructions in, we get the MM fault - but
there's even more wrong when that happens (details toward the end below).
I've been looking at the core dump produced by the process, which gives me the
registers at the time of the trap, the user's stack, etc - but not a copy of
the binary code - the 'ls' command is a so-called 'pure text', i.e. the binary
is segregated into separate, potentially shared, read-only 'segment(s)' (only
1 in this case) of the PDP-11's User mode address space, and is not included
in the process dump.
(I use the term 'segment', which is actually what DEC called them in the first
version of the PDP-11/45 processor handbook, because that's what they are, not
pages, as pages are on most systems. I assume they changed to 'page' for
marketing reasons. And please, can we hold debate about this and focus on the
problem? Thanks! :-)
I do have the ability to look at the binary that it _should_ be executing, by
examining the command in its file. Also, Fritz has worked out that he can
patch the MM trap vector (before trying to do the 'ls') to halt the machine
when it happens, so he can read out all the KT11 registers, look at the actual
program in main memory, etc.
First oddity - the problem is dependent on the location of the command in main
memory! If Fritz says "sleep 360 &", to run a trivial command in the
background, and _then_ says 'ls' - it works (so we know the binary of 'ls' on
disk is OK)! We _think_ this is because the process executing the 'sleep'
takes up a chunk of main memory, and thus changes the location of the process
executing the 'ls'.
The problem is that I'm reluctant to try and change anything (e.g. to have the
OS print out anything) because that will change the location of things, and we
may (likely?) will not get the problem. With nothing changed, it _reliably_
fails - I've looked at two different core dumps, and all the essential data
(registers, user stack etc) are identical. The KT11 registers all seems to be
the same, too.
So, on to details.
I'm pretty sure the command only gets a few instructions in before it blows
up. Here are the process' registers, and the _entire_ contents of the user
mode stack:
R0 177770
R1 0
R2 0
R3 0
R4 34
R5 444
SP 177760
PC 010210
060: 000000 000020 000001 177770 177774 177777 071554 000000
010210 turns out to be the first word in 'csv', which is an internal routine
which PDP-11 C uses to build a stack frame - _every_ C routine starts with
a "JSR R5, CSV" instruction as the first thing it does.
So looking at the stack (which looks good; it contains a valid 'argc' and 'argv'
that the process would be started with), and the registers, I'm pretty sure
it does these starting instuctions OK:
start:
setd
mov sp,r0
mov (r0),-(sp)
tst (r0)+
mov r0,2(sp)
jsr pc,_main
_main:
jsr r5,csv
and then blows up on:
csv:
mov r5,r0
So it's the 8th instruction in that blows up (*): but not only is what's in
memory at that location _not_ 'mov r5,r0', it also gets an MM trap that
makes no sense.
(*: In user mode: if you don't have an FPP, the first one will trap, which
UNIX ignores.)
Fritz has looked at the KT11 register when the trap happens, and the PARs and
PDRs all look good. The SSRs contain:
> SSR's: 040143 000000 010210 000000
SSR2 gives the PC at the time of the fault (again 010210); SSR0 shows:
Abort - segment (page) length error
User mode
Segment (Page) 1
which is the first thing that's wrong - neither the instruction that's
_supposed_ to be there (next), nor the one that's _actually_ there, contains
any reference to segment 1!
The _actual_ code it's trying to execute is:
> 171600: 016162 004767 000224 000414 006700 006152 006702 006144
(Per UISA0, text base is 0161400, plus a PC of 010210, gives us 0171610, which
is right in the middle there.) That does not, alas, look anything _at all_
like what's _supposed_ to be there, which is:
010200: 110024
10400 mov r4,r0
167 jmp 10226 (cret)
16
PC-> 10500 mov r5,r0 (start of CSV)
10605 mov sp,r5
10446 mov r4,-(sp)
10346 mov r3,-(sp)
So somehow the command (at least, this part of it - Fritz is going to check on
the first few instructions, but I'm pretty sure they will be OK) has gotten
read in wrong - but that's the least of our problems! 06700 is 'SXT R0', and
neither that nor 'MOV R5, R0' can _possibly_ cause an MM violation - least of
all one on segment 1 (this code is in segment 0)!
I could see there having been an error reading in the command binary (e.g. maybe
the RK11 has an issue), but WTF is happening here?
Just to make things triply confusing, R5 contains trash! The 'JSR R5, CSV' _should
have put the old PC in R5; but that call to CSV is at 030, so R5 _should_ contain
034, not 0444.
Needless to say, this is a real head-scratcher. What's confusing the heck out
of me are the three separate issues, all happening together - R5 contains
junk, the spurious (?) MM trap, etc.
The bad command binary in main memory could be caused by any number of things:
to get it, Unix reads file system blocks off the disk into buffers in low
memory, and then writes them out to the user's memory with MTPI. So an RK11
glitch could be doing it, but also a KT11 problem, etc.
I'm having a hard time seeing a common thread here - maybe a KT11 issue? But
how would that cause R5 to contain trash? That should only involve the KB11.
And the JSR R5, CSV must have been executed more-or-less OK, otherwise how did
it wind up at CSV?
I was wondering if some noise could be causing it - some sort of pattern
sensitiity - but how is it bashing R5 _and_ causing a spurious MM trap? That's
some glitch!
Most of the data above (e.g. SSR contents at trap time) has been re-checked,
and Fritz is going to check the rest (e.g. actual main memory contents for the
start of the code, and the user's stack - to check that the process' core dump
worked OK - although given the consistent stack contents, I'm expecting those
to be good).
I suggested to him that the time had come to apply the logic analyzer; I'd
love to see (from the IR in the CPU) the instruction that faults, and where it
came from. And also what the bus cycle is that's causing the fault; is it the
instruction fetch (possibly) or something that instruction is trying to do?
Does anyone have any comments/insight that could help work out what's going on
here? Or suggestions on things to look at? If so, thanks!
Noel
I don't get replies from here yet, so I have seen no replies to my posts,
nor the posts themselves.
There is a shop that has been in biz for over 25 years that is closing in
California.
I asked for anything old Apple, Sun, HP, IBM, and any old keyboards.
She will call me back tomorrow. She never dealt with the off brands, just
major maintenance contracts.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Unfortunately, they have already scrapped everything! They were distributors
of old HP and IBM hardware.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
If anyone out there needs an EIA distribution panel to go with their
DZ11, here:
https://www.ebay.com/itm/321225351590
are some of the 8-line ones (as used in the later modular back panel
system). The seller (Efi) is good people.
Noel
Daniel Fecteau
6025 Arthur sauv?
Mirabel, Quebec
J7N 2W4
TEL: 450-969-1616 ext 101
Mail: save at savesysteme.com
He has a variety of Model M 122 key keyboards. Contact him if you are
interested.
Not affiliated with seller, etc.
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
> From: Cindy Croxton
> I changed email providers, and received no emails for a week. If you
> tried to contact me, please ask again!
Perhaps 'test' was not an optimal Subject: line - a lot of people think that
flags a message they can ignore, and not even look at - which was not what
you wanted! :-)
Noel
Hi Al.
$ 60, plus shipping ?
I live close to Paris, France. Zip Code : 77310
( Payment through Paypal seems the only way ?? )
On an other subject, did you see my previous cctalk post on imaging HP 1000 L series Eprom ? Any interest ?
Best regards
Gerard
I own a HP 1000 L series 200
Cards are badly corroded at connectors level BUT some other parts are in very good shape.
I can offer,
HP "special SoS" processors : 1AA6-60004, 1AC5, 1AB5, 1AF5 ( - 60001 )
The set of (3) Eprom ....
I cannot image them, but I am willing to send them to someone that will do it.
Al. may be ?
The power supply seems in pristine state. Just have to check more closely if needed.
Other parts ? .... just ask.
"fee" : Eprom, free
Processors : shipping cost
Power supply : shipping cost + a little more for packing material and my time.
I am in France, close to Paris.
I changed email providers, and received no emails for a week. If you tried
to contact me, please ask again!
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
This looks like a project with a ton of potential for archviving media
without having to deal with the asshattery of the kryoflux people.
https://github.com/picosonic/bbc-fdc
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
> From: Fritz Mueller
> I've had a bit of time in front of the machine to repro this and take a
> look. What I actually see is:
> R0 177770
> R1 0
> R2 0
> R3 0
> R4 0
> R5 34
> R6 141774
> PC 000254
Argh. (Very red face!)
I worked out the trap stack layout by looking at m40.s and trap.c, and
totally forgot about the return PC (that's the 0444) from the call to
trap():
0001740 000013 141756 022050 000013 000000 000000 000000 000034
0001760 000444 000031 177760 000000 030351 177770 010210 170010
I clearly should have looked at core(V) in the V6 manual!
The R6 you have recorded is correct for just after the trap; that's
the kernel mode SP, which points to the top of the kernel stack,
in segment 6 (in the swappable per-process kernel area, which runs
>from 140000-1776).
So there is no R5 mystery, I was just confused. Back to the other two!
Noel
> From: Wayne S
> it might be a wonky filesystem. ...
> The corruption probably came because the entire disk was going bad.
This theory is contradicted by the fact (mentioned several times, including in
the message you were replying to) that doing a plain 'ls' bombs, but 'sleep
300 &; ls' works fine.
Noel
> From: Jay Jaeger
> This sort of situation, where DEC diagnostics run OK but UNIX has issues
> was reported to be not all that uncommon - to the point where the urban
> legend was that some DEC FE's would fire up Unix V6 as a sort of system
> exerciser.
Amusing! Never heard that; our -11's were never under maintenance, so DEC FE's
never worked on them.
> Make a copy of ls, and see if the copy also fails
It acts just like the original; fails when run by itself, runs OK when 'sleep'
is also running (in the background).
> From: Bob Smith
> We finally had the cpu backplane replaced
Ow. Not an option for Fritz, I expect. (I dunno - anyone have a spare /45
backplane?)
> From: Paul Koning
> Is there any way to attach a logic analyzer to various data paths on
> this machine?
I had suggested to Fritz that the symptoms led me to believe that it was time
to deploy a LA, especially since the MM trap only occurs once between him
typing 'ls' and the process failing - i.e. easy to trigger on.
He offered me the options of look at the IR or at the UNIBUS - I opted for
the IR so we can see _exactly_ what the machine _thinks_ it is doing! No
report back yet, though.
Noel
> From: Jon Elson
> Does the MMU classify what the error condition was
Yes, there are a series of bits in SSR0 to indicate the particular error:
'non-resident', 'length', 'read-only', etc (and also the segment number the
error's from). As my message mentioned, we're seeing the 'length' error bit
on, and for segment 1 (which the instruction isn't using).
> is it possible to borrow an MMU from somebody else?
Fritz does have a spare board, but it has known errors. We haven't thought about
borrowing one yet, it may come to that.
> If this fault could be caused by memory
Well, _some_ of it could. E.g. if the 'jsr r5, csv' is read as 'jsr r4, csv',
dropping the '1' bit in the register number, that would explain the wonky R5
content - R4 does contain the 034 that should be in R5, I have just noticed.
But that doesn't explain the bogus MM trap. Although I suppose there could be
several different problems, all at the same time.
> does this machine have a cache?
Nope.
Noel
Here's a question for someone who has been around long enough to
remember.
Why did none of the available PDP-11 Unixes support the TU-58?
I have looked at Ultrix-11, V7M and BSD 2.11 (didn't try 2.9
but I suspect if it isn't in 2.11 it wasn't in 2.9) and none
of them had support for the TU-58. Seems to me it would have
been a rather simple device to handle as it ran over a serial
line.
bill
Hi
I'm restoring a PDP-8/a with the help of some
friends. The CPU is now passing the MAINDECs I've
thrown at it. The memory is a modern semiconductor
board my friend Anders Sandahl made.
This machine is pieced together from several others
and the limited function panel I got does not match
the backplane I have.
My theory is the DEC simplified the design of the
boardto cut costs and simpler design is not
compatible. Mine is labeled (on the PCB):
"LIMITED FUNCTION BD.
5411507
5011506C-P2"
And the one I need is:
"LIMITED FUNCTION
5411165
5011167"
However, the picture I have of the other is not so
good. I may have read the numbera wrong.
I would very much like to buy one to finish this
project.
/P
> From: Bill Gunshannon
> Why did none of the available PDP-11 Unixes support the TU-58?
> I have looked at Ultrix-11, V7M and BSD 2.11
The 'TUHS' list might be more likely turn up the reasoning?
Noel
I have made a SA1000 adapter board for my MFM reader emulator. I did a
small run which seems to work so if you are interested email me to get
in on the next order. Prices may get a little better if I get enough
orders.
http://www.pdp8online.com/mfm/http://www.pdp8online.com/mfm/sa1000/sa1000_usage.shtml
I have used it for reading Shugart SA1004 and Quantum Q2040 drives.
Another has used it to replace drive in a TRS-80 Model II 8 Meg drive unit.
Some other items that may be of interest:
Dealing with stuck head problem with Quantum Q2040 drives
http://www.pdp8online.com/q2040/q2040.shtml
Using a DAC to pull the head servo to recover otherwise unreadable data
>from DEC RD53 drive. Also procedure tried for Q2040 but data had been erased
so not successful.
http://www.pdp8online.com/mfm/head_servo/
If you were thinking of joining us for VCF PNW 2019 in Seattle then now is
the time to let me know!
The event is March 23-24th (Saturday and Sunday) with setup the day
before. We still have room for some more exhibits if you are interested in
joining us. If you are going to join us I need to know by Friday, February
8th. If you have told me you were coming but did not complete the
registration form, well, now is the time ...
A description of the event can be found at http://vcfed.org/vcf-pnw .
General information for exhibitors including pictures from last year, a
link to the registration form, and a FAQ can be found at
http://vcfed.org/wp/vcf-pnw-exhibitor-registration/ . Also, yell at me
directly if you have questions
Thanks,
Mike
mbbrutman at brutman.com or michael at vcfed.org
PS: Not exhibiting at the event but interested in unloading some tonnage?
We're doing a consignment area again, and that's open to everybody. Now is
a good time to start cleaning and testing things that you might want to
sell.
Evening folks,
I?m bringing a Sharp MZ80B back to life and have so far fixed a horizontal collapse problem on the video board meaning I can see what it?s prompting for at boot. I remember when I first got this machine back in 2003-ish I dismantled it and discovered some of the tape transport had melted and gummed up the automatic head mechanism.
Fast forward* 15 years and I have the transport in bits again on the bench and I can see that one belt has melted and another is on the way to collapse. Did we ever find a reasonable source of replacement belts? I know a couple of collector friends with 3D printers have printed replacements but this is new tech and I need old tech :)
Cheers!
*sorry, pun intended
--
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest private home computer collection?
t: @binarydinosaurs f: facebook.com/binarydinosaurs
w: www.binarydinosaurs.co.uk
Does anyone have any DC6525 tape cartridges they would be willing
to part with? One of the Expansion boxes on my VAX has a TKZ10
but none of the older QIC tapes I have can handle the format from
this drive.
bill
My google-fu is failing me; forgive me.
Is the Tandy DWP-220 daisy-wheel printer a rebrand/OEM of someone
else? In particular, can I find ribbons and font wheels under another
manufacturer?
KJ
My PDP 11/40 suddenly lost it's ability to boot RL02 disks except the XXDP
disk. I have two drives, both boot up an XXDP (I have more than one) just
fine, but any formerly-working RT-11 (v 5, 5.1, 5.3) no longer boots, it
just hangs. I have been troubleshooting, running the 11/40 XXDP tests, but
they seem to just hang too. And I am not a big fan of XXDP anyway. I have
cleaned the drive heads, the disks are ok. I can load BASIC just fine from
PDPGUI "tape" through the serial card (M7800)
Any off the cuff suggestions why this specific issue would arise? Power
seems ok, looking for dumb reasons that I missed. I have swapped out CPU
cards, does not make any difference. I am pretty sure it's a UNIBUS
interference issue, at least that's my working theory. I suppose there may
be an RT-11 boot instruction call or routine of the CPU that XXDP does not
exercise explaining why XXDP boots. Maybe RAM locations.
In the end I just have to work through everything, but I am open to
suggestions to help cut down the time spent diagnosing the problem.
Thanks in advance, I will be around tonight (East Coast USA Time)
Bill
Random question
would you prefer having, if you had to pick only one, the original PDP
11/70 or the newer "blue cabinets" PDP 11/70, assuming both were complete
configurations with racks of storage etc as they would have been sold, more
or less.
Assume space and power are not issues, consider just the machine itself.
Bill
Those reading through the recent "PDP-11/45 RSTS/E boot problem" thread here will know that I've gotten to some corners of my 11/45 CPU now that don't match up with the commonly available engineering drawings.
My /45 is an early serial number (#152). So far I've verified hardware differences on at least my M8100 and M8105 cards and spares, relating to parity error abort handling. I would really like to track down any of the following resources:
- PDP 11/45 system engineering drawings *earlier* than those currently available on bitsavers (Jun '74)
- Any PDP 11/45 backplane wire list (what looks to be a wire list in the currently available engineering drawings is actually only a breakdown of the power harness.)
- PDP 11/45 ECO information, particularly the following:
M8100 00003
M8103 00005
M8105 00005
M8106 00007, 00008, 00012, 00012A
M8110 00008
KB11-A 00015
Bitsavers seems to have a DEC-O-LOG for M8105, but this does not contain specifics on cuts and jumps for ECO 00005, referring only to the associated "kit". DEC-O-LOGs for the other processor boards are missing.
If anybody thinks they might have any of this info squirreled away anywhere, I'd really love to find out more about it!
Parts of the ECO's are pretty easy to figure, just by comparing the state of my existing boards to the '74 drawings. But other parts not so much...
thanks much,
--FritzM.
Hi,
I knew that since ~20 yrs, but I didn't know the affected gcc
version(s). According to http://toni.technetium.be/hacker/pragma.htm
this "special" pragma handling should be in gcc 1.34.
But I cannot find gcc 1.34. ftp.gnu.org has gcc-1.30.atari (where the
sequence doesn't exist), and gcc-1.35 (where it's "#if 0"ed).
Does anyone know where to find the source code of gcc 1.34?
regards,
chris
From: Jay Jaeger
> Here is what I have for drawings:
Wow. You have some very desirable stuff there! Let me point at a couple
of things of particular interest:
> B-TC-FP11-C-6 FP11-C (Print Set MP00038) December 75
> [M8126, M8127, M8128, M8129]
AFAIK, prints for the FP11-C are not available online:
http://manx-docs.org/details.php/1,9306
so those of us with an FP11-C would be particularly grateful if you could
scan those and make them available.
> EK-KT11C-MM-005 KT11-C, CD Memory Management Unit Maintenance Manual
Not available online; the earlier DEC-11-HKTCA-C-D KT11-C Memory Management
Unit Maintenance Manual is available online, but doesn't cover the -CD. This
one is in the fiche set, but it's a pain to work with (especially since my
fiche reader burned out its bulb recently :-), so it's a 'nice to have',
scan-wise.
> EK-MS11A-MM-006 MS11-A,B,C memory System Maintenance Manual
Agaih, not available online, but in the fiche. Ditto 'nice to have'.
Of course, anything you've got that's not online should be scanned
'eventually' (I have several of those myself, sigh).
Noel
> Sorry, but no. It?s grossly offensive for things that work perfectly well and that someone might actually find useful to go to scrap. There?s tons of useless and broken junk that our civilization can mine for scrap, we don?t need to actually destroy things that have actual value.
>
> If someone isn?t able to sell for the price they?d like to get, maybe the market won?t bear that price and they need to lower it. Scrapping should be a course of last resort, a way to recover value from something you can?t even give away, not a competing outlet for goods.
>
> -- Chris
While I also don't like scrapping out things that work or can be
repaired relatively easily, a saying I use in a variety of situation is
"don't force your limitations on me, I have enough of my own."
That said, I VERY much appreciate the free pile at VCFMW that allows me
to get rid of stuff that will go to a good home rather than go to
landfill or scrap (I DON'T DO EBAY!!!) Many times I find free to be far
to expensive for most people including myself (think
postage/shipping/prep time.)
> From: Fritz Mueller
> I would really like to track down any of the following resources:
> - PDP 11/45 system engineering drawings *earlier* than those currently
> available on bitsavers (Jun '74)
My KB11-A prints have an 'overall' date of "4/76" (on the front page), but
prints within the set seem to be older.
E.g. my M8100 prints are dated 2/72, and none contain any entries in the
'Revisions' block (lower left). However, they are marked as Rev. D, which is
newer than the KB11-A prints at Bitsaver, which are marked as Rev. C. So I
have no idea what changed to cause the rev update! (The first drawing, the
board layout, does show a listing for 'D', so maybe it was just a layout
change?)
The boards aren't all the same rev, though: the M8102 in mine are marked Rev.
C.
My KT11-D prints are dated "5/72" (on the front page), and the M8107 prints
are hand-marked as Rev. A, but the M8108 pages have mostly been replaced with
'yellow-sheet' updates with Rev. F, dated 6-'73.
Noel
At 07:13 PM 1/28/2019, dwight via cctalk wrote:
>When looking at the 45 minutes, also consider the various overheads involved.
>They are in business. Time is money.
Space is money. Organization is money. Information is money.
Advertising / listing for sale takes time and money. And it all only
gets worse if the item is heavy, dirty, or leaking.
- John
Hi,
I'm looking for some (technical!) information on the HP E2447AA or
E2447AB probe pod (for using a HP logic analyser to monitor a 68000 CPU).
I need to probe a DIP64 packaged 68HC000, but the E2447AA/AB are for PGA
parts. So I figured I'd make a "top hat" PCB to adapt the 68k to a bunch
of HP transition headers.
The E2447AA delays the UDS and LDS signals before passing them to the
analyser. Does anyone know how much of a delay is introduced compared to
the original signal?
Thanks,
Phil.
Kudos to Jesse for working with me offlist, I feel I've gotten a good deal. I appreciate the offers to help purchase, very much, but I got this taken care of directly with Jesse and I'm happy.
We have to understand, as others pointed out, that if no one speaks up for stuff at a price that can keep the parts houses in business then the parts won't be around. By the same token, the parts houses have to know we can't pay typical full price that corporations/military can. We must be willing to pay something above scrap value, of course.
I ask folks to keep an open mind and give Jesse a fair shake moving forward.
Best,
J
On Thu Jan 24 16:26:48 CST 2019, Electronics Plus sales at elecplus.com
said:
> I just got off the phone with Jesse at Cypress. He said he did not post
the
> gold and tantalum items on ebay. It is someone else, trying to cast a bad
> name on him.
Sorry, but this doesn't really check out. Jesse sent an email to the list,
original subject 'Hewlett-Packard 3000, 9000, Itanium (HP-UX & MPE/iX)
Servers, Storage Arrays, Replacement Parts, Maintenance, & Disaster
back-ups' and put his email and website in the message. Going to that
website, cypress-tech.com, we can go to the 'ebay store' page where the
apparently official ebay store of Cypress Tech is linked to. Following the
link, http://stores.ebay.com/Cypress-Technology-Inc we see that this is the
same seller as the original gold scrap ebay link,
https://www.ebay.com/itm/382505855460
Here is the list of reasonable possibilities that I can think of:
- Somebody sent a fake email, from a fake Cypress-Tech.com, and made a fake
ebay page with the sole purpose of defaming this person (I'll admit, not
entirely out of the realm of possibility if there were someone with a
grudge against him)
- Jesse does not maintain full exclusive control over the ebay store, and
one of his coworkers/employees have posted the gold scrap auctions without
his knowledge (I suppose this is possible)
- You've been lied to, or otherwise you made a mistake
Please correct me if I've made an error somewhere, and please don't take
this as a personal attack of any kind. I don't have any interest in this
matter really, but my BS detector was showing a reading, so I checked it
out a little deeper and that's what I found.
Best Regards,
Joe Zatarski
> From: Fritz Mueller
> it flagged a bunch of memory locations that weren't reported by my much
> simpler diagnostic (which only does all-ones/all-zeros passes looking for
> stuck bits at this point.)
What is is complaining about?
> The MAINDEC memory diagnostic is bulky and complicated, and it takes
> several minutes to re-download it after a power cycle, so it's not
> exactly convenient to use while troubleshooting.
Would it be possible to put it on a disk and boot it from there? If it's in
some documented format (e.g. .LDA), I can easily produce a Unix disk with it
on, if that would help (although loading the image onto the physical pack
would take forever, I guess - although you could let it run overnight).
It's probably not worth trying to devise a way to load individual files onto
a Unix disk over the serial line until Unix is working reliably, so the
program can run under Unix (otherwise a stand-alone program would have to
include file-system code).
> I'll probably be beefing up my smaller diagnostic with a few more tests
> (including parity).
One of the first things to add is to store each location's address in it during
a set-up pass, and check to see that it's still there during the checking pass.
> Went ahead and tried both RSTS and Unix again after the above repair,
> and saw the same fault behaviors from both (sadness).
Yeah, sounds like you still have memory issues (per the diagnostic grumping).
> I tried enabling trap on parity error in the MS11 CSR before running my
> diagnostic, but it didn't trap, even though it did flag parity error(s)
> in the CSR. So maybe I *also* have a bug I haven't yet addressed in
> parity handling within CPU.
Starting the CPU (i.e. 'START' switch) or an INIT instruction will clear
the 'trap enable' bit in the MS11-L CSR.
I'd modify your program to set it, and check to see if you're getting
parity error traps. (Clearly, if that hardware - either in the MS11-L,
or the CPU - isn't working you need to look at that first.)
> some of the earlier ones support setting a bit to determine whether
> parity errors will halt or trap the CPU
Huh? I was just looking at parity in the MM11-L and MM11-U (to see if
parity needed to be enabled on them, or if it's always on by default),
and I didn't see that. Also, there's no way I know of, on the UNIBUS,
for anything to halt the CPU (the QBUS has such as line, but not the
UNIBUS). Which memory has this feature?
> I'm curious how OS init code sniffs out what memory CSRs there are,
> determines their specific flavors and, in a heterogeneous system,
> determines how much address space is under the auspice of each CSR?
Unix V6 does nothing at all with parity (doesn't enable it in memory modules,
although the memory that was extant at the time - MM11-S, MM11-U, etc - did
support it as an option).
If one turned it on, the code _would_ catch the trap and 'panic' (print a
message and halt operation). It would be pretty easy to modify the code to
send a signal to the process if it happened in User mode. I'm not sure there's
much to be done if it happens in Kernel mode.
V6 sizes memory by doing a read every 0100 bytes (of the xxxx00 byte), looking
for success or a trap. If that succeeds, it clears the 32. sequential words
starting at that address, and then tries the next 0100. (So if you modified
the code to enable parity traps, you wouldn't hsave to deal with bad parity
left over from random contents at power-on....)
> The 11/45 prints show a jumper (W1, lower left of sheet UBCB) that
> looks like it would entirely disable Unibus parity error detection if
> removed.
Yup, that's what it looks like to me too..
> when I pulled and examined my UBC board (and also looked over my spare)
> no such jumper or any associated pads were anywhere to be found! So maybe
> this was either added/removed from later etches of the UBC?
Well, if you have an M8106, you do have a KB11-A; in the later /45 CPU, the
KB11-D, that has been replaced by the M8119 - but that still has W1! (The
KB11-D prints are in MP00039, 11/55 Vol 1.) I looked on my M8119, and W1 is
indeed there - it's a 0-ohm 'resistor' (single black band) just less than
half-way up the 4th column of chips, with a '1' next to it in the etch. The
M8106 board layout drawing (a couple of pages back from UBCB) does show W1 -
upper left corner of the board, next to E84.
Noel
all the 3000 stuff too? sorry to hear that Al.. ?back in the 80s would visit him nice guy glad to hear he is,still alive. ?ed#
...
-----Original Message-----
From: Al Kossow via cctalk <cctalk at classiccmp.org>
To: cctalk <cctalk at classiccmp.org>
Sent: Sat, Jan 26, 2019 07:49 PM
Subject: Re: OT Parts houses & scrappers
On 1/26/19 5:40 PM, ED SHARPE via cctalk wrote:
> Is? Larry? at? Crisis computer still around?
He is in Sacramento. Most of what he had was scrapped 15 years ago.
A large number of Bay Area people were involved in saving what could be saved.
I ended up with a lot of 9000/300 stuff. I didn't go after any 21xx stuff because
I had literally hundreds of boards. All were stolen from a storage container
about a year ago.
Gentemen,
All of you have at one time expressed interest in all or part of this
rack full of Alphaservers and one of you even talked about driving a truck
up from Montana and taking it all home.
Are any of you still interested?
First priority goes to anybody willing to come up here and pick up all or
part of the collection. I will consider shipping if that is what it comes
down to but the packing and transprotation will be expensive for the DS15
and extremely expensive for the other units.
--
Richard Loken VE6BSV : "...underneath those tuques we wear,
Athabasca, Alberta Canada : our heads are naked!"
** rlloken at telus.net ** : - Arthur Black
Is? Larry? at? Crisis computer still around?
Jay? used to? know him? too back? years ago.
Ed#
In a message dated 1/26/2019 6:35:21 PM US Mountain Standard Time, cctalk at classiccmp.org writes:
> That sounds all well and good.? Until you something unexpected and
> unknown when you are at an auction for something else.? There's only so
> much self education you can do on a smart phone 10 minutes before the
> auction.
Start now with the research. You can gain quite a lot knowledge from
the various scrap forums and Youtube videos.
--
Will
> From: Electronics Plus
> I did not bring the stuff home. ... Call John Adler ... he owns the
> stuff in the sheds.
Now I am completely confused. What happened to the online spread-sheet that
some of us filled out? Did that go to him? If so, does the fact that we've
heard nothing means our offers were not interesting? If not, are we now
supposed to call instead?
Noel
> From: Fritz Mueller
> those PDP-11's have their toggles set for V6 single-user boot! :-)
Very observant! (Although I guess you've been using that a lot recently! :-)
> From: Paul Koning
> Was the 11/74 ever shipped?
I don't think so. (Well, I vaguely recall rumours of a couple going out on
beta-test; too busy to chase down where I saw that.)
Noel
> From: Paul Koning
>> Also, I still need images of a few things: -11/60 and -11/94 front
>> consoles, the original LSI-11 card, the KDJ11-E, and most of the DEC
>> QBUS boxes. (Yeah, I could try looking for free images
> Google "pdp11/60" turns up some good pictures, one showing the console
> panel closeup is from a UK computer museum.
Which one - 'computermuseum.org.uk'? Many of the pictures I saw online were
on pages with copyright notices. I was actually hoping someone who _has_ one
the the things I listed would take a picture and send it to me.
> It seems like a problem caused by taking the photo with flash; lit by
> ambient light it would probably look better.
They are in low-light locations; without flash it's a long exposure and I get
blurring because my hand isn't steady enough. And I don't feel like moving
them, or re-doing the lighting - too many higher priority things to do.
> A variant of the LSI-11 is the H-11 sold by Heathkit. .. it would be
> worth mentioning.
I've seen some go by on eBait, so I have an idea of the value, but I
couldn't get enthusiastic about listing them.
> Do you want to show the PRO system boards? And maybe the I/O boards?
Again, not enthusiastic enough to put in the work...
> In the discussion of boards, you might mention that "FLIP CHIP" often
> appears ... And there will be a "digital" logo, the 7-box kind.
OK, I will add that.
> (on older boards?All boards? Many boards regardless of age?)
It's spotty, and seems to die out later on. The -11/40 boards have it, but
for the -11/45 and -11/70, some do, and some don't. None of the KDF11 or
KDJ11 QBUS CPU boards do.
> The "Miscellaneous Digital Equipment Corporation PDP-11 Information"
> link lands me on a "Forbidden" error page.
Ooops. Fixed. Thanks.
> Zane Healy
> Don't forget the quad-height /73 board, it's much nicer than the
> dual-height boards.
That's the KDJ11-B, no? That's there.
> Is a /44 really worth that much now?!?!
Hey, one just went for more than that: eBait #183624991924, $3K! Admittedly,
that one was loaded, but the page does say "a number of factors will cause
them to vary considerably from the numbers given here ... Exactly which
peripherals and memory are included".
But I did adjust the number a bit - the boards are going for about $50 each,
and add in a BA11-A, it's probably $700 for a bare machine. Actually, I
really need to check all the numbers.
But I think I'd rather get the QBUS boxes sorted out first; I pretty much
only know the BA11's. If someone could tell me what later boxes to list,
above the BA23, (which I also need an image of), that would be very helpful.
Noel
In Japanese, but interesting.
http://www.geocities.jp/kugimoto0715/index.html
Talks about interfacing old school high current 5V interfaces like FDD or
SASI/SCSI into into lower voltage lower current RPI pins.
Warner
this? did not seem to? go though? when I? sent? as? a reply.--------------------------------------------------------------------
Glad? to? Hear? Jay -? I guess the? timeshare systems? were about the only? thing? I? ever? saw? those board? sets in.
ok~To? refile my? slightly? prior? ?message under? ?perhaps a better? title
I have? one? foot in each HP community? ?The? real production one and the? Collection of? vintage HP Gear? one.
I have had no complaints about? Jesse? ? from the? ?people? the? do data processing? with HP machines and have always? found him to be? friendly and timely in responses.
This? goes? for? Cindy? as? well.
Be? nice? to our? dealer? friends? they? can? help you. Maybe? not? today? but? ?you? will need? assistance some day and it is good to have them there.
well darn it... be? nice to everyone. eh?
Ed Sharpe archivist? for SMECC
In a message dated 1/25/2019 10:36:09 AM US Mountain Standard Time, cctech at classiccmp.org writes:
Kudos to Jesse for working with me offlist, I feel I've gotten a good deal. I appreciate the offers to help purchase, very much, but I got this taken care of directly with Jesse and I'm happy.
We have to understand, as others pointed out, that if no one speaks up for stuff at a price that can keep the parts houses in business then the parts won't be around. By the same token, the parts houses have to know we can't pay typical full price that corporations/military can. We must be willing to pay something above scrap value, of course.
I ask folks to keep an open mind and give Jesse a fair shake moving forward.
Best,
J
Sparcom Drive95 3.5 inch disk drive for the 95lx
Both? NOS in? box? was unsold inventory? from? computer exchange? ?in Phx? (my old? company...? ?these turned up in relatives? garage...)? ?one? has? manuals and all paper? work? one? has? no manuals and paperwork? but? NOS
I will offer? for? ?sale? and? ? ?even better if? you? buy? both. you? buy? both!? Offered? for? offers here? ? next? stop? ebay? if? no one here interested.? Sold? as? is.Ed#
Glad? to? Hear? Jay -? I guess the? timeshare systems? were about the only? thing? I? ever? saw? those board? sets in.
ok~To? refile my? slightly? prior? ?message under? ?perhaps a better? title
I have? one? foot in each HP community? ?The? real production one and the? Collection of? vintage HP Gear? one.
I have had no complaints about? Jesse? ? from the? ?people? the? do data processing? with HP machines and have always? found him to be? friendly and timely in responses.
This? goes? for? Cindy? as? well.
Be? nice? to our? dealer? friends? they? can? help you. Maybe? not? today? but? ?you? will need? assistance some day and it is good to have them there.
well darn it... be? nice to everyone. eh?
Ed Sharpe archivist? for SMECCIn a message dated 1/25/2019 10:36:09 AM US Mountain Standard Time, cctech at classiccmp.org writes:
Kudos to Jesse for working with me offlist, I feel I've gotten a good deal. I appreciate the offers to help purchase, very much, but I got this taken care of directly with Jesse and I'm happy.
We have to understand, as others pointed out, that if no one speaks up for stuff at a price that can keep the parts houses in business then the parts won't be around. By the same token, the parts houses have to know we can't pay typical full price that corporations/military can. We must be willing to pay something above scrap value, of course.
I ask folks to keep an open mind and give Jesse a fair shake moving forward.
Best,
J
On Thu, 24 Jan 2019, John H. Reinhardt via cctalk wrote:
> I also know I think other have their dibs in first.? But if they wash out...
Thanks John, I will keep you in mind.
--
Richard Loken VE6BSV : "...underneath those tuques we wear,
Athabasca, Alberta Canada : our heads are naked!"
** rlloken at telus.net ** : - Arthur Black
Holly smokes... 1st, Cindy thanks for calling me and vouching for me on
this list but let me clear something up here....
A. the ebay ads are mine and I put all content up there.
B. there reflects different locations (Largo, Clearwater, Land o lakes)
all around the Tampa area. We have been in that area since about 1995
and address have changed several times because we have moved .
C. The ebay ads are not all corrected with the current address since I
didn't thing that was going to be any kind of issue ever. I have like
400 running ads and you have to individually correct each one.. again, I
really never and up until this moment thought it was ever an issue since
selling on ebay since 1997.
D. some of the older 1k and older board ship from Pittsburgh because
thats where I split my time between Tampa and Pittsburgh and the really
old stuff is in Pittsburgh.
E. I never even posted my ebay stuff on here, I did an intro and posted
some stuff I was looking for.. Heck, I never even contributed to the
ebay thread.
Jesse
I have? one? foot in each HP community? ?The? real production one and the? Collection of? vintage HP Gear? one.
I have had no complaints about? Jesse? ? from the? ?People? the? do data processing? with HP machines and have always? found him to be? friendly and timely in responses.
This? goes? for? Cindy? as? well.
Be? nice? to our? dealer? friends? they? can? help you. Maybe? not? today? but? ?you? will need? assistance some day and it is good to have them there.
well darn it... be? nice to everyone. eh?
Ed Sharpe archivist? for SMECC
In a message dated 1/25/2019 10:18:12 AM US Mountain Standard Time, cctech at classiccmp.org writes:
Hello to all IBM 5100 owners,
I have started disassembling and commenting the Executable ROS of the 5100
that a kind soul has exctracted and provided me with the dump.
I've come across an inconsistency with the Maintenance Information Manual
as found on the net. I have both SY31-0405-2 and SY31-0405-3.
The issue is the description of the control I/O commands for device 1
(non-executable ROS selects). The manual says bit 12 is APL select and bit
13 is BASIC/Common select (page C-4), and that matches the block diagram
on page 5-20.
But in fact, the code uses the bits as defined for the 5110 (12=select
BASIC, 13=select APL, 14=select Common) and therefore, the 5100 must be
different from the system described in the MIMs.
So here are two questions:
- Does someone have a newer version of the MIM, i.e. SY31-0405-4 or greater?
A scan would be wonderful, especially because the scans for the
available MIMs are horrible...
- Are there known major revision changes in the 5100 line?
Christian
PS:
I really mean 5100, not 5110 or 5120 ;-)
Cypress Technology, Inc. is a HP hardware vendor specializing in selling
and supporting Hewlett-Packard HP 3000 (MPE/iX), 9000, and Itanium
(HP-UX) servers, workstations, parts, and all related peripherals. We
offer HP hardware from the early 1990's to the current date.
We offer but are not limited to the following HP items:
HP IA64 Itanium Integrity servers
HP 9000 Enterprise HP-UX servers
HP 9000 Visualize HP-UX workstations (PA-RISC and Itanium)
HP 3000 MPE/iX PA-RISC servers (aka e3000)
HP 1000 Series classic servers, parts, and peripherals
HP VME Industrial workstations, VME CPU boards, peripherals, and parts
HP ABB Advant Stations / RTA Real Time Accelerator platform / OSC / 800xA
HP Memory, disk arrays and drives, tape drives, CPUs, data
communications, & networking solutions
HP Enterprise Storage, XP, 3Par, Hitachi, EMC... Disk Arrays and drives
HP spare parts for all lines
We specialize in HP servers and workstations that support the following OS:
Linux, HP-UX, HP Unix, MPE/iX, OpenVMS, and MS Windows
. Contact us if you want a price quotation on any HP servers,
workstations, hardware, or services.
. Contact us if you wish to sell or trade for any hardware.
. Contact us if you have any questions.
. We offer hardware and software support.
. We offer migrations service for HP-UX and MPE/iX platforms.
. We provide parts and servers for discontinued HP items
. We sell to large and small corporations, World governments, military,
suppliers, re-sells, and end-users
. We buy off-lease bulk and surplus hardware
. We ship and export Worldwide to every country.
www.Cypress-Tech.com
Thank you
Jesse Dougherty
Cypress Technology, Inc.
Land O Lakes, Florida USA
Phone 888-954-3414 / (cell) 412-589-3779
jesse at cypress-tech.com
jesse.cypresstech at gmail.comwww.linkedin.com/in/jessedougherty