Re: IEEE-488 on the PDP-11

[Ethan Dicks via cctech]

On Tue, Nov 16, 2021 at 6:09 PM Christian Gauger-Cosgrove
 wrote:
> On Tue, 16 Nov 2021 at 16:27, Ethan Dicks via cctalk
>  wrote:
> ... I have experience with IEEE-488 from my many hours
> > spent with Commodore PETs.
> >
> Hmm now that I'm reminded that a large proportion of Commodore's
> "stuff" was IEEE 488 or a serialized version thereof.

Yep.  All PETs have true IEEE-488, albeit a software-driven
implementation so it's not high-speed (few kb/sec).  Starting with the
VIC-20, they used that serialized version, because Jack Tramiel was
tired of the cost of cables and connectors.

> I kind of want to see now if an IBV11 and Commodore 1541 can be abused
> into cooperating.

I think it could be done.  The IBV11 can certainly keep up with the
6502 in the drive that's banging out the IEEE-488 protocol.

> (There'd need to be a small "box of stuff" to turn the real 488 bus to CBM's 
> serial thing.)

You would need a box like that (they do exist) for talking to a later
device like the abundant 1541 floppy drive, but you could just plug
the cable right into an older drive for the PET, a 4040
dual-double-density 5.25 drive, or an 8050/8250 drive (higher density,
more tracks), or even a D9060/D9090 hard drive (5MB or 7.5MB,
internally has an MFM drive and a SASI-ST506 bridge).

The "DOS" is in ROM in the disk drives, including everything about
files and filesystem layout.  You wouldn't have to port that to the
PDP-11.  You talk to all the drives with the usual IEEE protocol of
secondary addresses and command strings.  On the PET side, it's
LOAD/SAVE, OPEN/CLOSE, and PRINT#/INPUT# (later ROMs added a command
layer for "disk commands" but they are just wrappers around the
primitive calls).

The directory is a special file named "$"; to get a directory, you
open that file and read the contents.  The drive sends the directory
not as plain text, but as a loadable BASIC program so you do have to
convert "line numbers" (file block sizes) to ASCII, and you have to
convert all the text contents from PETSCII to ASCII.  All doable in a
couple of pages of code.

There are a number of books for how the Commodore side works.  You can
even use the later serialized drive books to understand the higher
protocol.  At a character level, it's identical.

In terms of using it as a more generic device, there are block-level
primitive commands (U1 and U2 for read and write-block) but the
physical block size is 256 bytes, even on the D9060/D9090 hard drives.
I'm sure it's possible to write a native driver for RT-11, bypassing
the Commodore filesystem, but it sure would be slow.

-ethan

Re: Sun-2 and Sun-3 mice (eBay)

[Ethan Dicks via cctech]

On Tue, Oct 26, 2021 at 5:20 PM Alan Perry via cctech
 wrote:
> >>> https://www.ebay.com/sch/xi_jinping/m.html?item=334195034340=item4dcf9388e4%3Ag%3Ar%7EcAAOSwFVhhd12t=nc&_trksid=p2047675.l2562
> I would be more concerned about paying $50 for an untested mouse.

I half expect that the LEDs need to be replaced - that was a common
problem with this type of mouse.  The IR LED in particular was driven
hard and dimmed with age after a few years of being powered on.

That's an easy and expected fix.  What would be entirely uncool, and
was the reason I didn't drop $65 incl postage on it, is if the cable
had damage to it.  That's the part that's unique to the Sun3, the
cable and connector.

> The mouse that came with my 3/260 was yellowed but otherwise looked
> fine.  Unfortunately it doesn't work.

Even if the LEDs light up, a mouse that won't track can still have
worn-out LEDs.  Definitely check that first.  If it's totally inert
(no bits of any kind, not even button clicks), then that's a different
matter.

> I still haven't restored the 3/260 enough to be able to use a mouse, but
> someday ...

I got around to fixing up my 3/60 to bring to VCF a couple of years
ago, but I had to borrow a suitable mouse.

The other angle I have is to finish my DA15-DIN8 converter so I can
use a newer mouse/keyboard.  I _have_ a Sun3 keyboard (cost me more
than the 3/60!) and I like to have that for exhibition, but just to
use the machine, I don't mind using a Sun4 or Sun5 keyboard with  it.

-ethan

Re: Sun-2 and Sun-3 mice (eBay)

[Ethan Dicks via cctech]

On Tue, Oct 26, 2021 at 10:45 AM Ethan Dicks  wrote:
> On Tue, Oct 26, 2021 at 2:43 AM r.stricklin via cctech
>  wrote:
> > https://www.ebay.com/sch/xi_jinping/m.html?item=334195034340=item4dcf9388e4%3Ag%3Ar%7EcAAOSwFVhhd12t=nc&_trksid=p2047675.l2562
> >
> > Hadn't realized before that there were Sun-2 mice which weren't black (were 
> > white/beige). I know some folks are looking.
>
> I am in need of a Sun3 mouse but that one looks like it got pulled out
> from under the porch.

Looks like someone got it.   I figured it wouldn't last long.

Really, I can get away with a cable adapter and a Sun4 mouse, or I
think I have a Sun4 mouse or two that someone cut the cable off of
that can be rewired with the right jack.

-ethan

Re: Sun-2 and Sun-3 mice (eBay)

[Ethan Dicks via cctech]

On Tue, Oct 26, 2021 at 2:43 AM r.stricklin via cctech
 wrote:
> https://www.ebay.com/sch/xi_jinping/m.html?item=334195034340=item4dcf9388e4%3Ag%3Ar%7EcAAOSwFVhhd12t=nc&_trksid=p2047675.l2562
>
> Hadn't realized before that there were Sun-2 mice which weren't black (were 
> white/beige). I know some folks are looking.

I am in need of a Sun3 mouse but that one looks like it got pulled out
from under the porch.

-etha

Has anyone gotten the old SIMH VAX-11/730 emulator to boot?

[Ethan Dicks via cctech]

Hi, All,

I'm fiddling with my 11/725 and as part of that, I'm prepping possible
system images to deploy using the 10-year-old 11/730 emulator that's
now part of SIMH.  I'm trying to get the original (v3.8) version
working because of the numerous changes to how simh 4.0 works now.

I'm working from the sources on http://www.9track.net/simh/vax730/
They compiled just fine and the binary runs (on Linux, FWIW) but I've
tried booting several different TU58 images and VMS device images and
so far, they all tell me "file open error".

Here's the current config with me trying to run the CRD tape/disk
combo (trimmed just show mounted images on TD0 and RB1).

sim> show conf
VAX730 simulator configuration

CPU, idle disabled, 2048KB, HALT to SIMH
.
.
.
TD, 2 units
  TD0, 262KB, attached to BE-T176I-DE.tu58, write enabled
  TD1, 262KB, not attached, write enabled
.
.
.
RB, address=FFFB86-FFFB87, vector=2A8, 4 units
  RB0, 64MW, not attached, write enabled, RB80
  RB1, 5242KW, attached to CRDPACK-RL02.img, write enabled, RB02
  RB2, 5242KW, not attached, write enabled, RB02
  RB3, 5242KW, not attached, write enabled, RB02


If I have to, I can grab the source for the current version off of
github, but having looked it over, it's essentially this same emulator
(with commit dates of 9-10 years ago) plus some recent structural
cleanup that's similar across all emulators.  The functional parts are
this same emulator.

Thanks for any tips.

-ethan

Re: Some new text adventure stuff for 2.11BSD

[Ethan Dicks via cctech]

On Sat, Jan 4, 2020 at 12:12 AM Adam Thornton via cctech
 wrote:
> I'm having a party on Saturday January 11 (and if any of you are in Tucson...

I'm a bit far off but it sounds cool.

> So I kind of wanted to put a general-purpose Z-machine interpreter on my
> PiDP-11, so that people could play Infocom (and community) games on a real
> terminal.

Fun!

> Turns out there wasn't really one, so I ported the venerable ZIP
> https://github.com/athornton/pdp11-zterp
> https://github.com/athornton/pdp11-tmenu/

Thanks for this.

> My biggest disappointment is that the memory map of Trinity, my favorite
> Infocom game, is weird and even though it's only a V5 game, I can't
> allocate enough memory to start it.

Is this just a 64K segment problem?  Perhaps there needs to be some
examination and optimization of the impure and pure storage and
caching design?

One can play larger games with 128K of total RAM on microcomputers,
but most of those engines are written in assembler not C so the engine
is tightly coupled to the processor architecture.

-ethan

Anyone have a firmware dump for Teleray Series 10 terminals?

[Ethan Dicks via cctech]

Hi, All,

I was recently at the CompuServe 50th Anniversary event which included
a tour of our old building at 5000 Arlington Center Blvd, where I
worked in 2001-2002.  The old data center is still in operation, being
rented out by Expedient as a cloud hosting and co-location facility.
One of the highlights of the tour is an old Teleray 10T they found
when they moved in 9 years ago.  They have it cleaned up and on
display in their conference room.  I did a little digging and quickly
found the docs on Bitsavers (thanks as always, Al).  What struck me
was the appearance of the mainboard.  I went up into my attic, and
wouldn't you know, I _have_ one, labelled "Model 10C" - same board but
(formerly) with special feature firmware to be a 10C.

What I don't have is ROMs in the ROM sockets.  :-(  It's five ;places
for standard 2708 EPROMs.  From the memory map and some of the photos
in the docs, not every model had ROM in "Position 5".  It looks like
all did have 4 EPROMs installed.

I have blanks and I have a burner.  What's not up on Bitsavers is the
10T or 10C firmware.  Does anyone have anything like that?

It looks like the keyboard is both easy and not easy to remanufacture.
It's a raw matrix, attached via fat round cable and DB25.  The
Keyboard includes a 74154 to decode 4 bits to 16 lines and the returns
are via 8 lines.  On the Terminal side, the 4 bits map to the 6502's
A0-A3 and the return lines map to D0-D7 (it appears at $-$000F in
the memory map).  91 keys, 1 IC and a lot of diodes would implement a
keyboard, as would an AVR microcontroller sitting on the 12 row/column
lines, translating to/from a modern keyboard.

The video appears to be standard 15.575KHz 1.0-2.5V mono video plus H.
Sync and V. Sync. routed off the board via the power supply connector
(+5V @ 3A, +/-12V @ 0.4A and a smattering of -5V for the 2708s).

So the only thing I would really need is copies of 4 or 5 EPROMs and I
think I could get this working with a replacement display and
reimplemented keyboard.  Anyone happen to have the firmware?

Thanks,

-ethan

Seeking documentation for Tallgrass Technologies "Shortcut"

[Ethan Dicks via cctech]

Hi, All,

Another recent find, a Tallgrass Technologies "Shortcut", 80286
upgrade for 8-bit PCs.  I've found several reviews online but no docs
and no software (to enable the onboard 16K cache).

One thing that concerns me is that on this unit, the 24-pin socket at
U18 is empty.  It might be nothing.  This one does not have the memory
daughtercard on J1, so perhaps they are related.

If anyone has docs or has one and could tell me if their U18 is empty
(and if not, what goes there), that would be great.

Thanks!

-ethan

Anyone have any docs on Termiflex handheld terminals?

[Ethan Dicks via cctech]

Hi, All,

I recently picked up an item I've been looking for for quite some
time, a handheld configuration "terminal" for a LeCroy 1440 HV
chassis, called a "Model 1447 Local Diagnostic Controller".  It's
superficially like the DEC hand-held used in the field for internal
RA81 diagnostics but it's not the same model.

The 1447 is described in the 1440 docs, so I have the pinout (DA-15
with TxD and RxD on pins 2 and 3, plus ground and +5V on certain
pins).  A sticker on my 1447 indicates it's a "Termiflex" product but
all I can find online are pictures and docs from the later LCD display
units.  This one has a 1x16 LED alpha display.

Does anyone have any docs on older LED Termiflex units?  Again, I have
the pinout but I'm curious about the innards.  Unfortunately, the 4
case latches are difficult to unlock without some magic shim tool or
I'd just open mine and reverse-engineer the PCB (there are four 2mm x
8mm slots with some sort of metal barbs at the bottom that seem to
need a specific tool to open - a small blade has been unhelpful so
far).

Pinouts (cf J3)
https://prep.fnal.gov/catalog/hardware_info/lecroy/high_voltage/images/fig216.gif

>From the LANL docs for the 1440 I've found so far, it's unclear at the
moment if TxD and RxD are +/-12V or +5V and GND but that's easy to
check on the TxD line before I put anything on the RxD line.

Thanks for any info.

-ethan

Anyone ever attempt repairs on CTI boards for DEC Professionals?

[Ethan Dicks via cctech]

Hi, All,

In preparing for my VCF-East exhibit, I went through my stack of DEC
Pro gear.  The good news is I had enough working hardware to get a
Pro350 running Venix fully operational.  The bad news is that I don't
have enough working hardware to have even a second functional Pro.

One of my RX50 controllers has a mechanically bunged up CTI ZIF
socket.  It doesn't look repairable so I'm probably going to have to
replace it with a transplant from another board.

One of my standard (mono) video cards displays bit garbage on
power-up.  I haven't found schematics for it yet (bitsavers has
schematics for the Pro380 CPU, the RX50 controller, the RX50, the
RD50).  I could probably pull the RAM and test it outside the board,
but beyond that, I'm stabbing at things.

I did a lot of googling around and I haven't seen a lot of repair
details on these.  Not really surprised about that, but I figure it
was worth asking if anyone has attempted component-level repair on DEC
Professionals.  I'm sure there's lots of experience with board
swapping - that will definitely solve my problems.

Oh... and I happen to be one video controller short anyway.  I suppose
a partial machine made its way to me at some point.  I know my Pro380
used to be a console for our 8530.  I was able to rescue the console
at least.  I probably got the Pro350s sometime in the mid-1990s when
people were dumping them.  I'm still a bit puzzled why I have *5* 256K
memory cards.  There's only 6 slots and once you put in the RX50
controller, the RD controller, the video card, and possibly the color
bitplane extension card, you've got 2 slots left.

One fun bit - I was able to break into the Venix box using the 'guest'
account (I guessed there was one) and run John the Ripper on an i7
Linux laptop to crack all the hashes.  10/12 took literally seconds.
One password was '82', another was 'Bob'.  The root password took a
few hours because it was two dictionary words.  In the end, though,
they all fell.  The default root password for Venix is in the manuals
('gnomes').  They at least changed it on this box, but 1984 crypto is
no match for 21st Century cracking.

I don't see DEC Pro systems talked about much - they were kinda slow
and definitely limited in their expansion.  For a time, they were a
cute packaged PDP-11 system but that CTI bus connector is a royal
PITA.  I am not shocked there weren't that many peripherals for it,
but for a "desktop computer", how many different kinds of interfaces
does the average office user need?

If anyone happens to be coming to VCF East this weekend and has dead
Pro gear, I could use a card to pull a CTI connector from.  At least I
should be able to get the one RX50 controller going.

-ethan

Re: Greetings

[Ethan Dicks via cctech]

On Mon, Apr 29, 2019 at 12:44 PM allison via cctech
 wrote:
> On 04/29/2019 11:37 AM, Jon Elson wrote:
> > On 04/29/2019 06:47 AM, allison via cctech wrote:
> >> On 04/28/2019 09:28 PM, Grant Taylor via cctech wrote:
> >>> On 4/28/19 6:27 PM, Ray Jewhurst wrote:
>  I already have a Hobbyist License.  I am just interested in
>  experimenting with different OSes and different versions of OSes.
> >>> ACK
> >>>
> >>> I don't know what VAX hardware VMS 1.5 supported, what VAX hardware
> >>> that Simh supports, or what the overlap is between the two.
> >>>
> >> You are limited to what the VAX-11/780 system had for peripherals and
> >> typically under 8MB ram (it maxed at 16mb).
>
> The typical environment during the DEC years '83-93 was a 780 with a
> 4-12mb and dozens of users or more.

We (by that I mean Software Results) had an 11/750 that started out
with 512K of RAM and quickly upgraded to 2MB.  I later bumped it up to
8MB (adding the backplane wire and replacing the memory controller)
and we ran 40+ users on it.

> In 83 that meant 3.2 or later and much of the time was V3.8 or 3.9 till
> maybe 86ish then V4 and soon after V5.

I first encountered VMS in late 1984.  I started off a just a user, so
I don't recall the version, but ISTR we upgraded to either V3.4 or
V3.6.  We stayed there for a while, but the MicroVAX I we got was
upgraded from, MicroVMS 1.0 to MicroVMS 4.0 as fast as that came out.
Eventually we did the upgrade path to 4.0 and beyond, pausing at 4.6
on that machine in part because we had a SI9900 controller (you had to
patch DRDRIVER.EXE to use all the cylinders of a Fuji Eagle) and in
part because we had customers who were still on V4.X.  I put
V5.something on an 11/730 and we used that box to link our product for
newer versions of VMS (after 1988).

When we shut everything down in 1993, we were still running VMS 4.6 on
that 11/750 and never needed to upgrade it past 8MB.  It did have
about 1GB on 4 spindles and 2 controllers.

> The years 83 and 84 I fondly remember V3.6 and later mostly V3.8...

I definitely remember V3.6 but I don't think we were on V3.8 for very
long before moving to V4.0.

> If memory serves V4 was the last that ran in 1meg, V5 pushed that higher
> as a 4 meg system was more common then.

I don't think I ever tried to run V4 in under 4MB (even our MicroVAX I
was maxxed out).  Or MicroVAX II had 9MB (and I think we had that one
on V5.4 for a while before moving to V5.5-1).  I think our VAX 8200
was on V5.4 for product development (COMBOARD for VAXBI) and it had no
less than 8MB (the total amount varied by how many slots we had to
free up by removing 2MB boards.

> However the Qbus uVAX has a RD54[system] and RD52[swap] on
> separate MSCP controllers
> for performance as thats where they bottlenecked when heavy swapping.

That sounds like fun - we never had enough hardware to pull that off.

> All my uVAXen have run from V4.4 [MicroVaxII/GPX] or later and my
> nominal version is 5.4.  Though I have a
> RZ56 with V7.2 on it.   All are physical hardware in the Qbus BA123
> realm and M3100 series.

Cool.  I've powered up the MicroVAX II in recent memory, and the VAX
8200 but I haven't fired up the 11/750 since the company folded.

> Running anything before V3 is painful as it was a build.  Also V1 was
> tied the 780 and that did PDP11 emulation
> mode for a lot of stuff.

Like I said, I started with V3.x so I missed out on the "joy".

> VMS changed a lot from 4.2 to 4.6, long file
> names are one that comes to mind as well as
> phase III and IV DECnet.

Yep.  Lots of changes, most of them improvements.

> That was a long time ago.

It sure was.

-ethan

Re: Rainbow 100 PSU capacitor list

[Ethan Dicks via cctech]

On Wed, Feb 27, 2019 at 1:21 PM Alan Perry via cctech
 wrote:
> Hi,
>
> I think that I need to re-cap the power supply in a Rainbow 100. Does
> anyone here know if anyone has put together a list of capacitors used in
> the power supply that I can use to order parts?

I don't have a list (I just got a pair of Rainbows last month) but
given the era of manufacture, I'd be looking for Rifa EMI filter caps
by the power inlet.  I've had those fail in BA23 cabinets and in a
Commodore D9060 hard drive, and a TRS-80 Model 4.

This is totally different than failing/bulging electrolytics.

-ethan

Identifying bad RAM on Amiga 1000 WCS board

[Ethan Dicks via cctech]

Hi, All,

I've been doing component-level diagnosis of a bad Amiga 1000 WCS
board and since I was unable to find this information anywhere, I
thought I'd post it to the list so that it's in the hands of more than
one person.

For an Amiga 1000 that starts up with a turquoise screen and never
asks for Kickstart, it means that the WCS RAM test has failed.  Common
causes are one or more bad 4464 DRAM chips on the WCS board or a bad
PAL.  I don't happen to have the PAL equations but I did spend some
time with a sick Amiga 1000, a Fluke 9010A and a cheap digital scope.

There are hand-drawn schematics floating around but they don't appear
to match the production hardware in either part placement or
completeness (the schematics describe 2 PALs, DAUGCAS and DAUGEN, but
the production hardware has two additional PALs, DPALCAS and DPALEN,
for one specific example).

If one has a Fluke 9010A and 68000 pod, one can test the WCS RAM by
pressing [RUN UUT] and turning on the Amiga and waiting a second or
two for the ROMs to set the right memory map bits to make the WCS
writable.  One can then do simple [READ] and [WRITE] tests to the
Amiga at $FC-$FF and even run a [RAM SHORT] on part or all of
that range (a RAM SHORT test on 256Kbytes will take more than a few
minutes).

The memory itself is a bank of 8 4464/50464 64Kx4 DRAMs at U1B-U1E and
U2B-U2E, arranged sensibly in two banks of 128Kbytes.  The chips in
row 2 are the lower half ($FC-$FD) and the chips in row 1 are
the upper half ($FE-$FF).  The individual bits are arranged as
follows:

U1E/U2E $000F D0-D3
U1D/U2D $00F0 D4-D7
U1C/U2C $0F00 D8-D11
U1B/U2B $F000 D12-D15

For those that want to trace individual bits the order on each DRAM is
pin-3, pin-2, pin-15, pin-17 which is slightly off the given order on
the 4464 datasheet of 2,3,15,17.

By way of verification, the WCS board I'm repairing failed the RAM
test with bad bits at $F000 when I pulled the defective chip from
position U1B.  The same chip failed testing in a Ming HT-21 "Handy
Tester" DIP logic and DRAM tester (but passed when tested as a 4416,
because the fault was not in the first 25% of the memory cells).

-ethan

Mounting screw threads for VR201?

[Ethan Dicks via cctech]

Hi, All,

I don't happen to have a VR201 here right now to measure directly (or
I would just do that), but IIRC, there's a threaded mounting insert on
the bottom (for the "E.T. Stand", if nothing else),  I want to
fabricate a shelf clip for a VR201 and am seeking the diameter/thread
pitch for the insert.  Does anyone have that info handy?  It's likely
larger than 1/4-20 from what I remember.

-ethan

Anyone have any info on the NEC D2167D-2?

[Ethan Dicks via cctech]

Hi, all,

I'm going through a box of random ICs and one particular item is not
showing up on my searches outside of a couple eBay auctions for chip
collectors.

The IC is a 20-pin ceramic body with side brazed legs, gold pins, chromed
lid, with NEC D2168D on it with "-2" painted on the ceramic and date codes
from 1984.  It's almost certainly a RAM chip of some kind, but I'm not
finding any pinouts or data sheets.

Anyone recognize this?  Anyone know a system that uses them?  I have more
than 10, and since I haven't run across them before, I probably don't have
a machine that needs them.

Thanks for any tips.

-ethan

Is a Hitachi P/N 21-18470-01 64Kx1 DRAM a rebadged 4864?

[Ethan Dicks via cctech]

Hi, All,

I have some Hitachi parts, marked 21-18470-01, that I pulled from a
DEC Professional 350 on an upgrade to 256Kx1 DRAMs.  I am trying to
track down a specific thing about them.  I found a vcfed.org post
about these same type chips in a DEC Rainbow and the question (but not
firm confirmation) that they could be Hitachi 4864s based on DEC parts
lists.

http://www.vcfed.org/forum/archive/index.php/t-24574.html

It matters to me because I'm trying to find some 7-bit/128-cycle
refresh DRAMs to stuff into a TRS-80 Model 4.  I mostly have 4164s
made by TI and such that are 8-bit refresh, so they won't do.  If
these are 4864s, then they'll do.

http://www.minuszerodegrees.net/memory/4164.htm

(I already have the GAL file for the Model 4 upgrade, so I don't need
the reminder that the 128K upgrade needs more than just eight more RAM
chips).

Thanks,

-ethan

Re: RX01 and RL01 on same UNIBUS system

[Ethan Dicks via cctech]

On Thu, Aug 17, 2017 at 4:48 PM, william degnan via cctech
 wrote:
> Just curious,
> Is there anyone out there with a combo RX01 and RL01 on the same UNIBUS
> system, today?

I never ran an RL01 on my RL11 (my RL01 mostly lived on my RL8A, but
sometimes ran on an RLV11 in a Qbus box).
  I've only ever run RL02s on an RL11.

> Are there any known issues?

None that I can think of.  They should be perfectly happy in the same
box.  They have different CSRs, and different vectors.  No possibility
for a conflict there.  They might be at the same BR level (have to
look - it's the wee PCB plugged into the machined pin socket), but if
so, that just matters which board is in front of the other as to who
gets interrupts first.  It's _possible_ there's a preferential order
there, but it's not a limitation I recall from the old days.

> I found a large box of RX01 disks, lucky me.  Working to get the RX01 drive
> running, experimenting.  My particular PDP 11 does not like it (11/40) but
> I think the drive is faulty, at least so far.  Much work to do.

You have an RX01 and an RX11 (M7846) not an RX211 (M8256), right?

If you have a KM11 or replica, you can use that to debug the RX01.

-ethan

Re: early (pre-1971) edge-triggered D flip-flop ICs

[Ethan Dicks via cctech]

On Thu, Jul 20, 2017 at 11:35 AM, Norman Jaffe via cctech
 wrote:
> Or, in today's dollars - $58. Ouch.

Wow!  That's many dollars per flip and or flop!

> On Wed, Jul 19, 2017 at 11:29 PM, Ethan Dicks  wrote:
>> I have no datasheet, but I have examples on DEC M-series FLIP-CHIP
>> modules from my PDP-8/L, c. 1968.
>>
>> I am pretty sure I have examples with 1968 date codes and possibly
>> 1967 date codes.
>
> Thanks! Also, the 1967 Allied catalog lists the SN7474 (flat pack) and
> SN7474N (plastic DIP), priced at $8.00.

Anyone have any hardware docs on a Hyundai Super LT-3 80286 laptop?

[Ethan Dicks via cctech]

Hi, All,

Chunking through the pile of old machines has revealed a Hyundai Super
LT-3 80286 laptop.  I see several for sale presently on the infamous
auction site (and not selling...) and I see numerous forum requests
for DIP switch settings (it has two 8-pin feature DIP switches behind
the carrying handle and one 4-pin switch in the battery case - along
with a dozen 3-pin jumpers inside).  Everyone refers back to an
InfoWorld review...

https://books.google.com/books?id=ATwEMBAJ=PT7

... that mentions the DIP switches select CPU speed, boot drive and
external video adapter (the unit has a built-in supertwist 640x480 LCD
that reponds as CGA, but there's a DE-9 marked EGA on the back).

So I guess I'll add my voice to the chorus to ask if anyone has any
documentation on the DIP switches and/or internal jumpers.

My unit has a dead Dallas DS1287 battery, of course, and like all of
them, you have to replace the unit or add an external battery to the
existing unit or the CMOS settings are _not_ preserved after setting
them and saving-and-exiting.  This is not specific to this laptop;
I've observed this behavior on other PCs with Dallas DS1287 clocks
(unlike the NiCd-powered cheap clone motherboard clocks that _do_ work
without/with a dead battery if you boot up, update the settings and
just don't turn it off).  Like in my Compaq SLT/286, the DS1287 is
soldered in place here, so I'm going to attempt to cut the case
without desoldering the chip.  There's plenty of room inside the case
to mount a CR2032 out of the way on a 4" lead.

I can test the Connor 20MB hard drive in another machine.  That's
easy.  One interesting bit about the LT-3 packaging - the drive is
_not_ powered via its 4-pin Molex connector.  It's powered by a JST
connector on the other side of the drive.  There are no internal Molex
connectors from the internal PSU.  If I replace the spinning drive
with a IDE-CF adapter, I'll have to hack the power connector.  No
biggie, just an extra step.

It seems that there is not a lot of love right now for 80286 machines,
at least as evidenced by the perpetual relistings of sales that fail
to garner an asking price of $80.  All the attention with retro-DOS is
with the 486.  FWIW, I still use my Compaq SLT/286 because it has a
docking station with 2 ISA slots and one of those is stuffed with a
proprietary ISA card to drive my B Microsystems device programmer.
If it weren't for that, I'd have no real "need" for a '286.

Thanks for any info or tips on the configuration of the Super LT-3.  I
did document the present settings so I could just start flipping
switches, but I'd love *any* period docs on what any of them are.
Once I get the CMOS battery situation fixed, I may just try flipping
switches to see what changes.  I don't think I have a color EGA CRT
anywhere (who still does?) but I do have a wee monochrome EGA ELT
flatscreen for testing.

-ethan

Seeking schematics/maintenance prints for DMB32/T1012 and H3033 distribution panel

[Ethan Dicks via cctech]

Hi, All,

With all the recent chatter on the VAX8200 on the simh list, I was
motivated to dust mine off and do a little digging.  I finally took
the plunge and got a DMB32 (right now, all I have are the 4 built-in
console ports) but while it was easy enough to find the
8.5"x11"-format user guide and technical manual which describe
registers and installation and problem diagnosis, I also want the
internal cable pinouts and schematics.  I know it's harder to find
post-Unibus-era C-sized prints since DEC stopped shipping printsets
with every order, so I have to ask, does anyone have any schematics
for either the T1012 module, the H3033 I/O bulkhead board, or both?  I
can likely quickly recreate the schematic for the H3033, it's 10
D-shell connectors (8x DB, 1x DC, 1xDD) and 6 30-pin ribbon cable
connectors.  Lots of signals, but lots of repetition.  The D-shell
pinouts are in the documenation I already have.  The 30-pin
connectors/BI fingers are not.  But if the schematics are already
available, I don't have to buzz one out.

http://manx-docs.org/collections/antonio/dec/dmb32ug1.pdf
http://manx-docs.org/collections/antonio/dec/dmb32td1.pdf

ftp://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/vaxbi/EY-5554E-SG-0002_VAXBI_Adapters_Student_Guide_Feb87.pdf

Thanks for any new docs.

-ethan

Re: IBM S/32, PDP-11/60+RL01, PDP-11/34, East Lansing MI

[Ethan Dicks via cctech]

On Tue, Feb 28, 2017 at 10:47 AM, Earl Evans via cctech
 wrote:
> I'm on the other side of the country or I'd be all over this.

I'm hours away myself...

> Someone please rescue this equipment. The thought of it going to the 
> scrappers is, well, brutal.

Indeed.

> Aren't PDP-11/60s kind of a rare beast?

Quite rare.  I've seen more 11/20s than 11/60s... (not that either
number is large).

-ethan