Front Panels - Update

[Rod Smallwood]

Hello Guys
The latest batch of PDP-8  panels are now reaching 
their new owners.

We held shipping until now to make sure  we had good product.

The only way you can check the quality is to go through the whole 
production cycle

We threw a fair few in the dumpster!

We did extra on the current run and there may be some 8/e Type B (After 
the switch change) available.

Next up are PDP-8/f and /m to fulfill existing orders.

I will be making for stock after fulfilling the current order book .

My policy is to ship from prepackaged stock.
We have loads of custom boxes and soft wrap.
We intend to hold manufacturing cycle stock  numbers
This means if takes three weeks to make a batch we will stock three 
weeks sales.


I'll publish the stock position once a week or by email order enquiry

We will be stocking:
 8/e A (pre switch change)
 8/e B (post switch change)
 8/f  (maynard address)
 8/f  (galway address)
 8/m (maynard address)
 8/m  (galway address)

Later pdp11/XX



Order cycle should be same/next  day dispatch against item in stock and 
PayPal transfer

Delivery  to UK next day, Europe 1-3 days and the US 2-5days

Currency exchange rates are moving all the time and may affect costs.


OEM quantities for reproduction makers of any panel, any 
manufacturer may be possible. (Email me)

 Bespoke one off for major restorations - email me.

Rod Smallwood (Panelman)

PDP 8A for sale

[Sellam Abraham]

I have a PDP 8A for sale.  It's kind of a project but as far as I can tell 
it's complete, with the front panel.

See photos and information here:

http://vintagetech.com/sales/Big%20Iron/PDP%208a/Chassis%201/

Asking price is $900 obo.

I also have two other PDP 8A systems in various states of disrepair here:

Complete boardset and chassis without front panel - asking $450 obo
http://vintagetech.com/sales/Big%20Iron/PDP%208a/Chassis%202/

Junk system for parts/serious restoration - asking $300 obo
http://vintagetech.com/sales/Big%20Iron/PDP%208a/Chassis%203/


Also please start here and navigate for more computers I presently have 
for sale:

http://vintagetech.com/sales/

Please inquire directly with me with any questions.

Thanks!

--

Sellam Abraham VintageTech
--
International Man of Intrigue and Dangerhttp://www.vintagetech.com

Whatsoever a man soweth, that shall he also reap.  The truth is always simple.


   * * * NOTICE * * *

Due to the insecure nature of the medium over which this message has
been transmitted, no statement made in this writing may be considered 
reliable for any purpose either express or implied.  The contents of
this message are appropriate for entertainment and/or informational 
purposes only.  The right of the people to be secure in their papers
against unreasonable searches and seizures shall not be violated.

Re: Honneywell multics? from panels. the inline phots in this message folks -smecc

[Noel Chiappa]

> From: Charles Anthony

> I desperately want to port Multics to a modern architecture

Funny you should mention this! Dave Bridgham and my 'other' project (other
than the QSIC) is something called iMucs, which is a Multics-like OS for
Intel x86 machines.

The reason for the x86 machines is that i) they have decent segmentation
support (well, not the very latest model, which dropped it since nobody was
using it), and ii) they are common and cheap.

The concept is to pretty much redo Multics, in C, on the x86. The x86's
segmentation support is adequate, not great. The Multics hardware had all
those indirect addressing modes that the compiler will have to simulate, but
the machines are now so freakin' fast (see simulated PDP-11's running at 100
times the speed of the fastest real ones - on antique PC's), that shouldn't
be a huge problem. We did identify some minor lossage (e.g. I think the
maximum real memory you can support is only a couple of GB), but other than
that, it's a pretty good match.

The x86 even has rings, and the description sounds like it came out of the
Multics hardware manual! Although I have to say, I'm not sure rings sare what
I would pick for a protection model - I think something like protection
domains, with SUID, are better.

(So that e.g. a cross-process callable subsystem with 'private' data could
have that data marked R/W only to that user ID. In 'pure' Multics, one can
move the subsystem/data into a lower ring to give it _some_ protection - but
it still has to be marked R/W 'world', albeit only in that lower ring, for
other processes to be able to call the subsystem.)

It will need specialized compiler support for cross-segment routine calls,
pointers, etc, but I have a mostly-written C compiler that I did (CNU CC is
large pile, I wouldn't touch it with a barge-pole) that I can re-purpose. And
we'll start with XV6 to get a running start.

There would be Standard I/O, and hopefully also something of a Unix emulation,
so we could take advantage of a lot of existing software.

Anyway, we've been focused on the QSIC (and for me, getting my 11's running),
but we hope to start on iMucs in the late spring, when Dave heads off to
Alaska, and QSIC work goes into a hiatus. Getting the compiler finished is
step 1.


> but there is a profound road-block: the way that Multics does virtual
> memory is very, very different, and just does not map onto current
> virtual memory architecture.

You refer here, I assume, to the segmentation stuff?

> then you need to extend the instruction set to support the clever
> indirect address exceptions that allow directed faults and linkage
> offset tables

I think the x86 has more or less what one needs (although, as I say, some of
the more arcane indirect modes would have to be simulated). Although my
memory of the details of the x86 is a bit old, and I've only ever studied the
details of how Multics did inter-segment stuff (in Organick, which doesn't
quite correspond to Multics as later actually implemented).

> Then there is subtle issue in the way the Multics does the stack ..
> This means that stack addresses, heap address and data addresses are
> all in separate address spaces

Well, Multics had (IIRC) 4 segment registers, one for the code, one for the
stack, one for the linkage segment, and I don't remember what the 4th one was
used for. (I don't think Multics had 'heap' and 'data' segments as somone
might read those terms; a Multics process would have had, in its address
space, many segments to which it had R/W access and in which it kept data.)
But the x86 has that many, and more, so it should be workable, and reasonably
efficient.

> I think it is possible to move them all into the same space

You wouldn't want to put them all in the same segment - that's the whole
point of the single-level-store architecture! :-) Or perhaps I'm
misunderstanding your point, here?

> Also, Multics stacks grow upward -- great for protection against buffer
> overrun attacks, but a pain in a modern architecture.

Sorry, I don't follow that? Why does the stack growth direction make a
difference? It's just a convention, isn't it, which direction is 'push'
and which is 'pop'?

Noel

Re: DEC RK05 Emergency Retract Batteries

[dwight]

I'd think a stack of supper capacitors would do it.
Dwight



From: cctalk  on behalf of Paul Koning 

Sent: Wednesday, March 16, 2016 10:32 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: DEC RK05 Emergency Retract Batteries

> On Mar 16, 2016, at 1:24 PM, Jos Dreesen  wrote:
> ...
> Additionally the NiCd never keep charge, if , like me, the drives  are only 
> fired up once a year...
>
> I am thinking of just adding some wiring to an external battery.

I wonder if it might make sense to replace it by a capacitor.  For this kind of 
application, the total capacity is not an issue at all, but only the available 
current for a fraction of a second.  By that measure, it doesn't take all that 
large a capacitor to do as well as a battery; the difference is that the 
battery can sustain that current far longer -- which doesn't matter here.

paul

Re: Resistor/Fuse replacement (DEC H7104-D)

[Vincent Slyngstad]

From: Josh Dersch: Thursday, March 17, 2016 3:34 PM
It's listed in the print set as a 1 Ohm, 2 Watt resistor, with a "FUSE" 
designation.  I'm not entirely sure what I should be searching for for a 
replacement; clearly the "fuse" part of the designation is important but 
I'm not sure what a modern equivalent is.  I've browsed around Mouser 
for awhile and I'm not seeing anything obvious.  I'm sure this is 
obvious to anyone with experience -- can you point me in the right 
direction?


There was a recent discussion here about a similar component in 
a VT100 supply.  I think a suitable replacement was eventually found 
at Farnell/Newark.


   Vince

Reproduction 8/e panel from Rod Smallwood

[Michael Thompson]

I received my reproduction 8/e panel from Rod Smallwood (aka "panelman")
this week. It looks spectacular compared to the peeling paint on the
original. Rod did not drill the hole for the rotary switch because the
position varies a little depending on the revision of the switch panel. I
put the original panel on top of the new one, marked the rotary switch
location, drilled a pilot hole and successively larger holes. I had to
adjust the position of the AC power switch a little to optimize the
clearance around the switches, but that was easy.

The original panel had rubber bumpers between the panel and the front of
the chassis that I will attach to the new panel with double sided adhesive
tape. The original panel had a tapered relief at the back of the hole for
the AC power switch, but the new one does not. I will use a file or Dremel
tool to remove some of the panel material. Without the relief the panel
will get stressed near the AC switch.

Overall, the workmanship on the panel is spectacular. Now I need to repaint
the 8/e front panel frame, RX01, RK05, and TU56 so they look as nice as the
new front panel.

-- 
Michael Thompson

anyone have a working RV-20 or RV-64?

[Al Kossow]

we have a bunch of optical packs at CHM that we'd like to archive
does anyone have a working setup?

Re: Code listings for the I4004 or I4040

[Kyle Owen]

On Mar 18, 2016 9:15 AM, "dwight"  wrote:
>
> Also, you see most applications using 1702s instead of 4001
> or 4308. I've never seen a 4308 in the wild.

I've seen one 4308 in the wild: in a later generation ARC RT-485A NAV/COM
radio. The earlier ones just use four 4001s.

Kyle

Re: anyone have a working RV-20 or RV-64?

[Paul Anderson]

I have a RV20 somewhere. Are you in a big hurry?

On Fri, Mar 18, 2016 at 6:48 PM, Al Kossow  wrote:

> we have a bunch of optical packs at CHM that we'd like to archive
> does anyone have a working setup?
>
>

Re: PDP-11/05-NC with M9301?

[Mattis Lind]

2016-03-17 15:24 GMT+01:00 william degnan :

> >
> >
> >
> > If one read notes in the PDP-11/04 printset it says: Do not insert a M930
> > or M9302 in a MUD slot. Only in the Unibus slots or you will have short
> > circuit. On the other hand it does not say that the M9301 (or M9312)
> cannot
> > be installed in a unibus slot. It recommends that those boards go into
> MUD
> > slots. But electrically I cannot see that it shouldn't work. Especially
> if
> > you jumper W1 - W5.
> >
> >
>
> Once I tried putting a M9312 into the backplane of my 11/05 NC.  The M9312
> did not boot to the console monitor, but there should be a way to do it, I
> just did not find it.   I have an expanded backplane.  If you look at the
> M9312 or M9301 you can surmise that these are not going to do anything like
> what the M930 does
>

In what slot did you put the M9312 in your 11/05 NC? In a MUD slot in the
Unibus expansion bus? Did you remove any of the other M930 boards then?

The M9312 and M9301 are nearly identical except for the way how the ROM
addressing takes place.

I would say that M9312 and M9301 has all functions of the M930 plus some
additional functions. They are bus terminators all of them. But M9301 and
M9312 has built in ROM and bootstrap logic whereas the M930 has not. The
M9302 on the other hand is a terminator plus the SACK logic.


>
> M930:
>
> http://vintagecomputer.net/digital/pdp11-05/EM_8Kx16_Planar_Memory_companion_card.jpg
>
> The M9301 is a ROM card, just like the M9312, one is an older model and
> they're compatible roughly I believe.  I recall from the manual that one
> could use the M9301 in an 11/05, but was not able pursue if it works yet
> for my set up.  I will eventually check this, but if there is a test you'd
> like me to try send and I will fire up the system.  I have the manual, I'd
> want to read up on it first to be sure I am installing correctly.  Not sure
> what ROM is installed on the card I have.
> b
> --
> @ BillDeg:
> Web: vintagecomputer.net
> Twitter: @billdeg 
> Youtube: @billdeg 
> Unauthorized Bio 
>

/Mattis

Re: OKI if800 CP/M

[Chuck Guzis]

On 03/16/2016 03:37 PM, Jason T wrote:

On Tue, Mar 15, 2016 at 7:01 PM, Chuck Guzis 
wrote:

22Disk has the definition, which is the same as the BMC IF800 (it
was marketed under both brandings).  I have samples in my files.


Do you think you may have the same disk I'm imaging?  It would be
nice to have it in another format for comparison purposes.  The front
label is here:

http://chiclassiccomp.org/docs/content/computing/_DiskSleeves/OKI_001a.jpg


I rarely keep originals, but copy them and return them to the original 
owner.  If you're interested, I can dig a disk or two out and list the 
contents.


--Chuck

Re: Connecting a Cambridge Z88 to the Internet

[Robert Rissell]

Your problem would be finding a suitable host device.   Early internet
access was serviced by text only portals such as Gopher.   Today I would
not count on finding one operating other than as a remote termial session
on an older machine.
On Mar 18, 2016 10:04 AM, "Liam Proven"  wrote:

> I've been asked about doing this for an exhibition.
>
> From some cursory Googling, it seems that the Z88 has a terminal
> emulator, and equipped with a suitable serial cable, you could just
> run a cable to a host device with an Internet connection and have a
> text-only terminal session fairly readily.
>
> Not much more than that, though.
>
> Has anyone on CC done this?
>
> --
> Liam Proven • Profile: http://lproven.livejournal.com/profile
> Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
> MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
> Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
>

Re: Code listings for the I4004 or I4040

[dwight]

Also, I've found a source for 5.185MHz crystals.
ACE Components has some. They are in San Jose, on Oakland Rd.
Dwight



From: cctalk  on behalf of dwight 

Sent: Thursday, March 17, 2016 7:51 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Code listings for the I4004 or I4040

Eric
 The answer is no and yes.
You can not use the normal RAM instructions with the 4289. Still, one
can have RAM through the 4289. It would have no status RAM like the 4002s
but for a program that is written to use conventional RAM through the
4289, it has no more overhead than regular 4002s, for character RAM.
You'd setup a register pair as a pointer and a SRC, just like 4002s for
character RAM.
If you only need quick access of status RAM, you are stuck with 4002s
or, create your own circuits.
So, I wouldn't say yes and no, I think no and yes is the answer.
I did look up to see if 4008/9 recognize the RPM. The 4040 shows
WPM for both 4289 and 4008/9 but only shows RPM for the
4289. I take that to mean that the 4008/9 doesn't support the
RPM, even with the 4040 processor.
Dwight



From: cctalk  on behalf of Eric Smith 

Sent: Thursday, March 17, 2016 1:23 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Code listings for the I4004 or I4040

On Thu, Mar 17, 2016 at 1:18 PM, dwight  wrote:
>  The 4289 can be used for RAM with the 4040, using the WPM and RPM. It can be 
> used
> on the 4004 but it is limited to WPM only.

I know about that; what I was asking about was whether the 4289 (or
4008/4009) could replace "normal' 4002 RAM. I think the answer is
negative.

> In any case, please don't erase the EPROMs, thinking they are blank.
> I offer my services to read them. Also, there may be someone closer
> to you that can extract the data.

I can read them.  Or rather, I could if I had them.  The sockets are empty.

Re: PDP-11/05-NC with M9301?

[Guy Sotomayor]

> On Mar 17, 2016, at 9:35 AM, Mattis Lind  wrote:
> 
> 2016-03-17 17:27 GMT+01:00 Guy Sotomayor :
> 
>> 
>>> On Mar 17, 2016, at 6:01 AM, Mattis Lind  wrote:
>>> 
> 
>>> 
>>> If one read notes in the PDP-11/04 printset it says: Do not insert a M930
>>> or M9302 in a MUD slot. Only in the Unibus slots or you will have short
>>> circuit. On the other hand it does not say that the M9301 (or M9312)
>> cannot
>>> be installed in a unibus slot. It recommends that those boards go into
>> MUD
>>> slots. But electrically I cannot see that it shouldn't work. Especially
>> if
>>> you jumper W1 - W5.
>>> 
>> 
>> Hopefully this will clarify a few things:
>> “Unibus”: These are the AB connectors in the *last* position of a
>> backplane.
>> It allows for bridging between backplanes.  The only “card” that can go
>> these
>> “slots” is a terminator (ie M930) or a terminator bootstrap (ie M9312).
>> 
>> SPC: These are the CDEF connectors in any of the slots of a “unibus”
>> backplane.
>> Not all backplanes support SPC slots.
>> 
>> MUD: These are the AB connectors in some newer backplanes (usually
>> associated with
>> the extra slots in a CPU backplane…11/34 and 11/04 CPUs have MUD slots).
>> MUD
>> stands for “Modified Unibus Device”.  They are *not* compatible with
>> Unibus slots
>> as they have different voltages present than what are on the Unibus
>> slots.  You *will*
>> “blow out” a board by plugging something designed for a Unibus slot into a
>> MUD
>> slot.
>> 
>> 
> Yes. That is pretty clear from pin assignment list that bad things WILL
> happen if you try to install a Unibus-slot-compatible device into  a MUD
> slut. But the vice-versa? Installing a MUD-compatible device into a
> Unibus-slot?

Most of those are memory boards and from my recollection they just won’t
work.

TTFN - Guy

NetBSD TK70 question

[Christian Corti]

I'm not sure where I should start asking, so I'm starting here ;-)

I have a problem reading TK70 (and probably TK50) tapes in NetBSD 3.0 on a 
MicroVAX II. There is absolutely no way of reading a single tape block 
with a simple read(). All I get is

  mt0: unknown opcode 0x80 status 0xc01 ignored
on the console, and then the driver hangs. The output is generated in 
/usr/src/sys/dev/mscp/mscp.c
It is my impression that the code has *never* been tested on real hardware 
after all that years. BTW the TK70 is working fine otherwise (e.g. I can 
boot the MVII diagnostic tape).
Now for something strange: the same procedure works in SimH (with the same 
system installation and kernel). So apparently SimH has a "bug", too. It 
doesn't behave like the real device.

Background of the story: I want to image TK70 tapes as TAP files.

Has anyone ever encountered the same behaviour?

Christian

Re: OKI if800 CP/M

[Jason T]

On Tue, Mar 15, 2016 at 7:01 PM, Chuck Guzis  wrote:
> 22Disk has the definition, which is the same as the BMC IF800 (it was
> marketed under both brandings).  I have samples in my files.

Do you think you may have the same disk I'm imaging?  It would be nice
to have it in another format for comparison purposes.  The front label
is here:

http://chiclassiccomp.org/docs/content/computing/_DiskSleeves/OKI_001a.jpg

Re: PDP-11/05-NC with M9301?

[Mattis Lind]

> > Yes. That is pretty clear from pin assignment list that bad things WILL
> > happen if you try to install a Unibus-slot-compatible device into  a MUD
> > slut. But the vice-versa? Installing a MUD-compatible device into a
> > Unibus-slot?
>
> Most of those are memory boards and from my recollection they just won’t
> work.
>

Ahh. You are thinking of hex size memory boards, right? I was think of the
M9312 and M9301 bootstrap and terminator boards. Essentially a terminator
with some bootstrap PROM and some logic to handle location 24/26 etc.

Anyway, I will try to check the backplane wiring to see if that gives a
hint.

What still would be interesting to now is in what slot the M9301 or M9312
goes into a PDP-11/70. My guess is the last unibus slot on the bus with the
jumpers installed. Much like the M9313 terminator and unibus exerciser
which is in the last slot of the  11/750 unibus.

/Mattis

>
> TTFN - Guy
>
>