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

[Noel Chiappa]

> From: Mouse

> As for buffer overruns, the point there is that a buffer overrun
> clobbers memory addressed higher than the buffer. If the stack grows
> down, this can overwrite stack frames and/or callers' locals.

Oh, right. Du! Buffers typically grow upward, no matter which direction
the stack grows. So the two directions for stack growth aren't purely a
convention.

Of course, in Multics, especially with AIM (Access Isolation Mechanism),
stack buffer attacks are much less dangerous. E.g. even without AIM, the
attacker can't load code into the stack, and return to it - generally the
stack segment had execute permission turned off.

And AIM really limits what 'bad' code can get up to. I keep ranting about
it's pointless to expect programmers to write code without security flaws, it
needs to be built in to the low levels of the system (one of Multics' many
lessons - it wasn't _really_ secure until the 6180 moved the ring stuff into
hardware, instead of simulating it in software, as on the 645). And so as
long as we continue to allow Web pages to contain 'active' content (i.e.
code), so that random code from all over the planet gets loaded into our
computers and run, browsers will neve be secure; they need to be run in an
AIM box.

Noel

Re: MEM11A Update

[Guy Sotomayor]

> On Mar 17, 2016, at 9:15 PM, Eric Smith  wrote:
> 
> On Thu, Mar 17, 2016 at 3:35 PM, Guy Sotomayor  wrote:
>> I’m planning on doing a 4 layer board so I can avoid having routing issues 
>> due to 3 different
>> power supply voltages (yea, modern low voltage design meets 5v).  I haven’t 
>> done a 4 layer
>> design before, so I’m in for a bit of learning (mainly on how to “pour” the 
>> inner layers).
> 
> In Eagle, you use the polygon tool, select the layer, and draw the
> polygon for the entire board outline (or wherever you want the pour).
> Then you use the "name" tool, select the polygon, and give it the name
> of the net you want it connected to (e.g, GND).  Once you've done
> that, any time you do a ratsnest command, Eagle will recalculate the
> polygon and connect all through-holes of that net to the polygon (with
> thermals by default). It doesn't recalculate as you add or move
> components, so it will look wrong until you give another ratsnest
> command to recalculate it.
> 
> While working on the layout, I find the display gets annoying with the
> polygons shown. Rather than hiding those layers, you can type "ripup
> @;" to remove the polygon routing until the next ratsnest command. I
> do that because I often have a few signals going through the layers
> that are otherwise mostly power planes, and I don't want to hide the
> entire layers because I want to see those signals.
> 
> Of course, this also works on the top and bottom side if you want
> copper pour there.

Thanks.  I think I have it mostly figured out.  ;-)

Still have to place all the caps.  ;-)  Then I can start to route everything.

TTFN - Guy

Re: OKI if800 CP/M

[Chuck Guzis]

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

On Mar 16, 2016 20:47, "Chuck Guzis"


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.

Sure, or a 22disk image, if you think you have the same disk I do.
Just something to check against to see if I'm "doing it right."


I'll try to get to it this weekend.

--Chuck

Re: where I've landed

[Ian S. King]

Sorry, Sergio, can't quite swing that.  :-)

On Mon, Mar 14, 2016 at 12:41 AM, SPC  wrote:

> No doubt, dude. Can anyone go to take a lunch?
> Sergio.
>
> 2016-03-14 6:43 GMT+01:00 CuriousMarc :
>
> > Awesome!
> > Marc
> >
> > -Original Message-
> > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Ian S.
> > King
> > Sent: Thursday, March 10, 2016 6:08 PM
> > To: General Discussion: On-Topic and Off-Topic Posts
> > Subject: OT: where I've landed
> >
> > Hi all,
> >
> > I informed the list when I left the Living Computer Museum, so it seems
> > appropriate to tell you where I've landed.  My new employer was in the
> news
> > this week:
> >
> >
> >
> http://arstechnica.com/science/2016/03/behind-the-curtain-ars-goes-inside-blue-origins-secretive-rocket-factory/
> >
> > The second photo is the view from where I ate lunch yesterday.  The fun
> > literally never stops living the dream! -- Ian
> >
> > PS: of course I'm finishing my doctorate - I'm kind of vested in it by
> now.
> >  :-)
> > --
> > Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <
> > http://ischool.uw.edu>
> > Dissertation: "Why the Conversation Mattered: Constructing a
> > Sociotechnical Narrative Through a Design Lens
> >
> > Archivist, Voices From the Rwanda Tribunal 
> > Value Sensitive Design Research Lab 
> >
> > University of Washington
> >
> > There is an old Vulcan saying: "Only Nixon could go to China."
> >
> >
>



-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

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

[drlegendre .]

Glad this came back up.

Was any consensus achieved, regarding the use of `flameproof` resistor
types as direct substitutes for designated "fusible resistors"?

On Thu, Mar 17, 2016 at 7:44 PM, Adrian Graham  wrote:

> On 17/03/2016 22:46, "Vincent Slyngstad"  wrote:
>
> > 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.
>
> Yep, that was me looking for the same part. Does yours look like this?
>
> http://f0p.co.uk/r22.jpg
>
> According to Onecall Farnell 'a blue band at position 5 indicates 20%
> tolerance' which would make it a tolerance multiplier of 2.
>
> However the only ones they sell are 5% tolerance, ie brown-black-gold-gold
> not brown-black-gold-silver + blue, but the technical chap I spoke to
> seemed
> certain these would be ok. I bought 5 just in case.
>
> Onecall are education-only suppliers but the same part numbers work with
> Farnell/Element14. Part# is 1692450.
>
> --
> Adrian/Witchy
> Binary Dinosaurs creator/curator
> Www.binarydinosaurs.co.uk - the UK's biggest private home computer
> collection?
>
>
>

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

[Mattis Lind]

> >
>
>
> I am not 1/2 as knowledgeable as others here, but what comes to mind is
> "backplane change",


You mean that I have to do modifications to the backplane. No, that is not
what I want...



> I think you'd leave the M930 where it is and on the 2nd
> backplane segment install the M9301.  If you don't have a 2nd plane I'd say
> you may not be able to use this.  Just my GUESS, but I am interested to
> learn the correct answer.
>

The PDP-11/05S I got had a M9301 in it when it arrived and it was installed
in a M930 slot (slot 3 AB). So that might be an indication that it could
work. But that is a different backplane.

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.


> b
> --
> @ BillDeg:
> Web: vintagecomputer.net
> Twitter: @billdeg 
> Youtube: @billdeg 
> Unauthorized Bio 
>

Re: Baydel Unibus disk systems

[Christian Corti]

On Fri, 18 Mar 2016, Mike Ross wrote:

I just have the controller board; I don't have any of the hard drives
left. All I remember is the disk was an 8" and the interface is a
single 40-pin cable; so not SMD and not SCSI. Far too early for IDE or
ATA. Any suggestions for what the interface might have been and what
disks might have been used? What hard disks were around in late 70s /
early 80s that used a single 40-pin connector??


My guess is that it's not a controller board but just the interface to the 
controller found in the external enclosure, probably with the hard drive. 
The interface would implement things like NPR and BR and the like, so 
there wouldn't be enough board space to implement a complete hard drive 
controller, especially if the board dates from that era. IMO it's 
something like a RX211 board for hard drives.


Christian

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

[Noel Chiappa]

> From: Charles Anthony

> Slightly at cross purposes here; I was speaking of porting Multics; you
> are speaking of writing a Multics like OS. I was opining that I don't
> think that porting would work due to Multics reliance on very specific
> VM features.

Yes; my un-stated assumption was that the existing Multics code was so tied
to the peculiar Multics hardware (how many instances of "fixed bin(18)" do
you think there are in the Multics source :-) that it would be impossible to
run on any modern hardware except via (as you have so wonderfully done)
emulation. Hence the re-implementation route...


>> I think the x86 has more or less what one needs

Intesting note here: I was just reading Schell's oral history (a
_fascintating_ document), and it turns out he was a consultant to Intel on
the 286 (which architecture the later machines more or less copied exactly,
extending it to 32 bits). So I'm no longer surprised that the x86 has more or
less what one needs! :-)


>> 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 pulled down one of my many copies of Organick, and I had misremembered the
details (and of course Organick describes the 645, not the 6180, which was
subtly different). The code has its own set of registers; the PBR/IC (I was
probably thinking of the x86's CS here). Of the four pointer-register pairs
(which are effectively pointers to any segment, i.e. 'far' pointers, in a
sense), two are indeed to the stack and linkage segments, and the others can
be used for other things - one is typically a pointer to subroutine arguments.

> 8 pointer registers ..
> PL1 calling conventions reseverved certain regsiters for frame pointer,
> etc.

Yes, I got the 6180 processor manual, and a bunch of other things, and there
had been significant changes since the 645 (which is the version I was
somewhat familiar with, from Organick). Of the 8 pointer registers in the
6180, I was only able to find the usage of several:

0 - arguments
4 - linkage
6 - stack frame
7 - stack/linkage header

I assume the others (most?/all?) were available for use by the compiler, as
temporaries.

One apparent big change in Multics since Organick was that the stack and
linkage segments had been combined into one (not sure why, as I don't think
having one less segment in the KST made much difference, and it didn't save
any pointer registers); the header in the combined stack/linkage segment
contained pointers to each in the combined segment.


>> 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?

> It's been a long time since I look at the x86 segment model, but my
> recollection is that segments were mapped into the address space of the
> process; that is not how the Multics memory model worked. Each segment
> is in it's own address space; any memory reference was, per force, a
> segment number and offset.

In this last sentence, is that referring to Multics?

If so, that is exactly how the x86 _hardware_ works, but most x86 OS's (in
particular, all the Unix derivatives) don't really use segments, they just
stick everything in a limited number of segments (one for code, one for all
data - maybe one more for the stack, although perhaps they map those two to
the same memory).

> I am unconvinced that Multics could be ported to that architecture

No disagreement there - "fixed bin (18)"!

> an interesting Multics like operating system should be possible

Exactly.

> with he caveat that some things are going to have be done differently
> due to incompatibilities in the memory model.

I'm not so sure - I think you may be thinking that the x86 model is something
other than what it is. It does indeed not have the infinite inter-segment
pointer chaining possible on Multics hardware (where a pointer in memory
points to another pointer which points to another pointer), but other than
that, it does seem to have most of what is needed.

In particular, it has local and global segment tables (indexed by segment
number), and the ability to load pointer registers out of those tables, and
the ability to have most (all?) instructions use particular pointer registers
(including segment selection), e.g. if the linkage segment was pointed to by
the ES register, there is an optional (per-instruction instance) modifier
which causes most (all?) of the normal x86 instruction set to operate on that
segment, instead of the primary data segment (pointed to by the DS register).

Of course, until we get into the details, we can't say positively, but after
reading the manuals, it seemed like it was doable.

Noel

Re: Connecting a Cambridge Z88 to the Internet

[Adrian Graham]

On 18 March 2016 at 15:13, Liam Proven  wrote:

> Since I've been playing with my new Raspberry Pi 3 today, I was
> thinking one of those might make a convenient host system. A USB <=>
> RS-232 convertor is probably the easiest way.
>

I can do that too :)


-- 
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk

Resistor/Fuse replacement (DEC H7104-D)

[Josh Dersch]

Hi all --

Yesterday I replaced the dead 2N6547 transistor in the H7104 and fired 
'er up again.  Same exact results.  (The timbre of the power supply 
whine may have changed slightly, it's hard to tell).  So, back to the 
drawing board.  I tested the replacement transistor after power-up and 
it was still good, so at least it wasn't a casualty.


On closer inspection, I found what appears to be a large-ish (maybe 
2.5-3mm in diameter) resistor with a hairline crack down the middle.  
Testing reveals it to be open-circuit, and looking at the print set 
reveals it to be connected to a leg of the transistor I just replaced, 
so that seems suspect.  I noted no smoke or odor during any of the times 
I've powered this thing up (the resistor is on the outside edge of the 
supply and I was watching pretty closely at all times) so I assume it 
was dead long before I got ahold of this machine and I just overlooked it.


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?


Thanks,
Josh

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

[Adrian Graham]

On 17/03/2016 22:46, "Vincent Slyngstad"  wrote:

> 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.

Yep, that was me looking for the same part. Does yours look like this?

http://f0p.co.uk/r22.jpg

According to Onecall Farnell 'a blue band at position 5 indicates 20%
tolerance' which would make it a tolerance multiplier of 2.

However the only ones they sell are 5% tolerance, ie brown-black-gold-gold
not brown-black-gold-silver + blue, but the technical chap I spoke to seemed
certain these would be ok. I bought 5 just in case.

Onecall are education-only suppliers but the same part numbers work with
Farnell/Element14. Part# is 1692450.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: DEC RK05 Emergency Retract Batteries

[Jos Dreesen]

On 16.03.2016 09:12, Christian Corti wrote:

On Tue, 15 Mar 2016, Paul Koning wrote:

From the various comments, it sounds like NiMH is a useable substitute. On the 
other hand, NiCd batteries are still readily available.


Yes, but NiCd cells really don't like being charged only and never discharged. And they 
tend to crystallise quite badly with age and "misuse"; best examples are 3.6V 
NiCd battery packs as CMOS battery on many mainboards.

Christian




 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.

Jos

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

[Mouse]

> I have thought, on occasion, about simulating a segmented machine on
> a non-segmented machine, i.e. one with large unidirectional addresses
> (segmented being a bi-directionally addressed machine) - [...]

Hm, "unidirectional" and "bidirectional" are terms I'm having trouble
figuring out the meaning of here.  You seem to be using them as,
effectively, synonyms for "non-segmented" and "segmented", but I don't
see any way in which directionality makes any sense for either, so I
can only infer I'm missing something.  Is it anything you can explain?

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

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

[Adrian Graham]

On 18/03/2016 02:11, "Josh Dersch"  wrote:

>> However the only ones they sell are 5% tolerance, ie brown-black-gold-gold
>> not brown-black-gold-silver + blue, but the technical chap I spoke to seemed
>> certain these would be ok. I bought 5 just in case.
>> 
>> Onecall are education-only suppliers but the same part numbers work with
>> Farnell/Element14. Part# is 1692450.
>> 
> 
> Thanks!  Yes, that looks very similar except mine has a tolerance rating
> of 10%.  Vincent helpfully pointed me at:
> 
> http://www.digikey.com/product-detail/en/tt-electronics-irc/SPP2UL1R00JLF/989-
> 1272-1-ND/4215463
> 
> which look like they should do the job, and I ordered a handful just in
> case I ever need a few more.

I'll be adding mine tonight or tomorrow so if the smoke escapes I'll get
some of those, why they didn't come up on my search for 'fusible resistor'
I'll never know.

-- 
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?

Re: Code listings for the I4004 or I4040

[Eric Smith]

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: Honneywell multics? from panels. the inline phots in this message folks -smecc

[Charles Anthony]

On Wed, Mar 16, 2016 at 6:19 AM, Noel Chiappa 
wrote:

> > 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?
>
>
Slightly at cross purposes here; I was speaking of porting Multics; you are
speaking of writing a Multics like OS. I was opining that I don't think
that porting would work due to Multics reliance on very specific VM
features. I do think that it is entirely possible to write an Multics like
OS on modern hardware.


> > 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).
>
>
Organick can be confusing; Multics has some abstractions of the H/W, and
the book isn't always clear about the distinction between the abstractions
and the underlying hardware; also Multics continued to evolve after it was
written.



> > 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.)
>

8 pointer registers, which contained segment numbers and word and bit
offsets into the segment.

PL1 calling conventions reseverved certain regsiters for frame pointer, etc.

8 index registers which contained an offset into a segment.

The executable, stack, heap, and static data would all be in seperate
segments.



> 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
>

PDP-11/05-NC with M9301?

[Mattis Lind]

I was thinking of using a M9301 board to get a console emulator and some
different bootstraps with the 11/05. But can I just put the M9301 in the
slot where the M930 normally goes? Slot 4 AB.

>From looking in the schematics I get that:

1. The bus grant pull ups on the M9301 is through jumpers. According to the
note they should only be installed on 11/70 systems. But the M930 do pull
these up (no jumpers here) so my guess is that these jumpers should be
installed.

2. The M930 connects much more signals to a common ground. Except for the
normal ones the M9301 uses for ground (AC2, BC2, AT1 and BT1) it also has
connected AB2, BB2, AN1, AP1, AR1, AS1, AV2, BD1, BE1, BV2 to ground.

Reading the pin assignments on a MUD slot I think that putting a M930 into
it could potentially create a lot of smoke. BV2 is -5V and AV2 is +20V if
the appropriate regulator is in the system.

M9301 goes into MUD slots. But can it go into the slot where a M930
normally sits?

My thinking is that it should work. What is your experience?

/Mattis

Re: Code listings for the I4004 or I4040

[Chris Elmquist]

On Thursday (03/17/2016 at 10:04AM -0500), Kyle Owen wrote:
> On Thu, Mar 17, 2016 at 1:43 AM, Eric Smith  wrote:
> >
> > Unfortunately I do not, but I've recently become interested in such
> > things, as I have received from a friend's estate an old board from an
> > embedded system (possibly a cash register) which has a 4040 CPU.
> > Photos here:
> >
> > https://www.flickr.com/photos/22368471@N04/sets/72157665878868081/
> 
> 
> Wow, an engineering sample 4040. Very nice. Highly sought after by those
> CPU collectors out there. You should be abel to build a nice system from
> that. No telling what those hybrid packs did. Can't say I've come across
> many 4004/4040 designs with such devices.

I too have an engineering sample i4040 from 1975 (7504 date code).
I found it in the attic of the place I worked while in high school
in 1979.  I saved it along with a second non-ES device all these years.

Recently, I got the bug to see if either of these parts were still good
and so I bought one of these,

http://www.cpushack.com/mcs-4-test-boards-for-sale/

and sure enough, both 4040s are still good and run just fine on this
test board.

So count me in for collecting and sharing 4004/4040 code and simple
system designs.  This test board is a pretty simple design but there's
still something fun about hand wiring a board, writing a little monitor
and bringing it up to talk to a teletype ;-)

Chris
-- 
Chris Elmquist NØJCF

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

[Mattis Lind]

>
>
>
> I took a look at my 11/40, it has a 9312 in pos 1/2 in the middle of the
> 2nd/rear of two backplanes here:
> http://vintagecomputer.net/digital/PDP11-40/NPG.JPG
>
> With this arrangement I can boot into the console monitor installed on the
> 9312.
> http://vintagecomputer.net/digital/PDP11-40/Console_test.JPG


This means that you not have the terminator in the last slot of the bus,
right? Since your bus is so short it won't probably matter.

I have now beeped my way through all signals of the AB slots of the
11/05-NC backplane. Slots 2-9 has "Standard Unibus Pin Assignments" No MUD
slots anywhere.

Then I rechecked the M9301 and M9312 schematics. There are no signals used
on those that would conflict with the "Standard Unibus Pin Assignments". I
will also check the boards physically to see if there is a difference in
signals that are used. Then unless someone tell me "it won't work, I have
tried setting a M9301 in a standard unibus slot" I will go ahead and try
it. After all this is how my PDP-11/05-S was configured when it arrived.

 /Mattis

>
>

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

[David Bridgham]

On 03/16/2016 09:55 AM, Mouse wrote:

> As for buffer overruns, the point there is that a buffer overrun
> clobbers memory addressed higher than the buffer.  If the stack grows
> down, this can overwrite stack frames and/or callers' locals.  If the
> stack grows up, all it can overwrite is locals for the current frame
> and unused stack space.

If the stack is in its own segment, you get to use the segment
protection hardware to catch overruns.

Re: Code listings for the I4004 or I4040

[Eric Smith]

On Thu, Mar 17, 2016 at 9:04 AM, Kyle Owen  wrote:
> Wow, an engineering sample 4040. Very nice. Highly sought after by those
> CPU collectors out there.

I noticed that it was an engineering sample, but hadn't really thought
about that making it more valuable to collectors. Perhaps I should
sell that chip and buy a production 4040 for my homebrew system.

I'd also like to get a 4201 clock generator, 4289 memory interface
(replaces 4008/4009 pair with one chip), 4265 GPIO, and 4269
keyboard/display interface.  And some 4002 RAMs.

Re: NetBSD TK70 question

[David Brownlee]

On 17 March 2016 at 11:34, Christian Corti
 wrote:
> 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?

I'm pretty sure TK50 tapes definitely worked around 1.6, as I built
and tested releases on them :-p

>From my very loose MSCP reading 0x80 would be M_OP_END and 0xc01 would
be M_ST_INVALCMD (plus the 0xc00).

Hmm, is it possible you're issuing a read for a different blocksize to
that of the tape?

As an aside if you wanted to test a more recent kernel you *should* be
able to drop a new kernel as /netbsd.new or similar and then boot it
directly and keep using the netbsd-3 userland. This may not work if
the new kernel needs a more recent bootblock (which is sometimes
unfortunately the case)

Re: Connecting a Cambridge Z88 to the Internet

[Liam Proven]

On 18 March 2016 at 15:27, Adrian Graham  wrote:
> I know exactly where my Z88 and power supply are, serial cable and modem
> not a problem. But! Dial-up services? I could RS232 onto a VAX...


Since I've been playing with my new Raspberry Pi 3 today, I was
thinking one of those might make a convenient host system. A USB <=>
RS-232 convertor is probably the easiest way.

-- 
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]

Hi
 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.
The RAM can then be use for both program and for data.
I don't recall if the 4008/9 support the RPM but I can look that
up later tonight.
It sounds like you may have a MCS4-02 or -03 board.
I'd love to see a picture of what you do have.
Don't assume the EPROMs are empty. I have a working system
with 3 1702As programmed in 1973. They still contain the original
data and work fine ( I have of course backed up the data ).
There are several assemblers and simulators available on the web.
I use my own home brew assembler and simulator. The assembler
is straight forward but simulators are tricky. If you don't know how
to write code ( usually using the same compiler ) you may not be able
to do much useful simulation. Attaching realtime I/O functions can be
tricky as they are the useful testbench part of the simulator.
You are welcome to my tools but they are written in Forth ( Win32 Forth ).
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.
It is also, not that hard to create a socket adapter to read out on
a programmer that can read 2716's. It does require an extra
power supply for the -10V.
Dwight



From: cctalk  on behalf of Eric Smith 

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

On Thu, Mar 17, 2016 at 9:04 AM, Kyle Owen  wrote:
> Wow, an engineering sample 4040. Very nice. Highly sought after by those
> CPU collectors out there.

I noticed that it was an engineering sample, but hadn't really thought
about that making it more valuable to collectors. Perhaps I should
sell that chip and buy a production 4040 for my homebrew system.

I'd also like to get a 4201 clock generator, 4289 memory interface
(replaces 4008/4009 pair with one chip), 4265 GPIO, and 4269
keyboard/display interface.  And some 4002 RAMs.

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

[Paul Birkel]

11/70:  M9301-YC -- E-F Slot #1.  It's specially wired like everything else in 
Slot #1 through Slot #39.  SPC doesn't start until Slot #40.  M9302 goes in Row 
A-B Slot #44.

KW11 (clock) goes adjacent in Row D Slot #1.

Row C Slot #1 is empty.

Rows A-B Slot #1 take the FP & CP maintenance modules, if in use.

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Mattis Lind
Sent: Thursday, March 17, 2016 1:09 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: PDP-11/05-NC with M9301?

...

What still would be interesting to know 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
>
>

Re: where I've landed

[Mark Wickens]

Looks great Ian - a lot more interesting than my attic! Although I do have
the Lake District to play in when I leave work.

Congratulations. All the best Mark
On 17 Mar 2016 03:52, "Ian S. King"  wrote:

> Sorry, Sergio, can't quite swing that.  :-)
>
> On Mon, Mar 14, 2016 at 12:41 AM, SPC  wrote:
>
> > No doubt, dude. Can anyone go to take a lunch?
> > Sergio.
> >
> > 2016-03-14 6:43 GMT+01:00 CuriousMarc :
> >
> > > Awesome!
> > > Marc
> > >
> > > -Original Message-
> > > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Ian
> S.
> > > King
> > > Sent: Thursday, March 10, 2016 6:08 PM
> > > To: General Discussion: On-Topic and Off-Topic Posts
> > > Subject: OT: where I've landed
> > >
> > > Hi all,
> > >
> > > I informed the list when I left the Living Computer Museum, so it seems
> > > appropriate to tell you where I've landed.  My new employer was in the
> > news
> > > this week:
> > >
> > >
> > >
> >
> http://arstechnica.com/science/2016/03/behind-the-curtain-ars-goes-inside-blue-origins-secretive-rocket-factory/
> > >
> > > The second photo is the view from where I ate lunch yesterday.  The fun
> > > literally never stops living the dream! -- Ian
> > >
> > > PS: of course I'm finishing my doctorate - I'm kind of vested in it by
> > now.
> > >  :-)
> > > --
> > > Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <
> > > http://ischool.uw.edu>
> > > Dissertation: "Why the Conversation Mattered: Constructing a
> > > Sociotechnical Narrative Through a Design Lens
> > >
> > > Archivist, Voices From the Rwanda Tribunal 
> > > Value Sensitive Design Research Lab 
> > >
> > > University of Washington
> > >
> > > There is an old Vulcan saying: "Only Nixon could go to China."
> > >
> > >
> >
>
>
>
> --
> Ian S. King, MSIS, MSCS, Ph.D. Candidate
> The Information School 
> Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
> Narrative Through a Design Lens
>
> Archivist, Voices From the Rwanda Tribunal 
> Value Sensitive Design Research Lab 
>
> University of Washington
>
> There is an old Vulcan saying: "Only Nixon could go to China."
>

Re: Code listings for the I4004 or I4040

[Eric Smith]

On Tue, Mar 15, 2016 at 10:54 PM, dwight  wrote:
> I've been scanning the web in search of any code listings for these 
> processors.
[...]
> Does anyone have a stash of paper tapes or listings?

Unfortunately I do not, but I've recently become interested in such
things, as I have received from a friend's estate an old board from an
embedded system (possibly a cash register) which has a 4040 CPU.
Photos here:

https://www.flickr.com/photos/22368471@N04/sets/72157665878868081/

The board also has the 4008/4009 memory interface, sockets for 16
1702s (I assume, though they are all empty), a bunch of TTL, a bunch
of hand-kludged stuff, and two 44-pin .156 pitch edge connectors (on
the same edge of the board).  It has all of *zero* 4002 RAM chips.
Maybe there were 4002 chips on another board.  The only marking on the
board, on both sides, is "MCS 4/4 N".

There are four strange-looking hybrids. Three of the hybrids have 22
pins with 600 mil row pitch, and are labeled (with stylized prefix
"IC"):

IC6298
  751


IC6270
 752


IC5220
 5002A

The fourth hybrid is a six-pin device with 300 mil row pitch, but
longer than a 16-pin DIP, and is labelled:

IC6302
 754

I suspect that the 751, 752, and 754 may be date codes, though the
5002A seems out of place.  My guess is that the primary purpose of the
hybrids was to make it difficult for competitors to clone the board.

For want of information on the board, I'll probably just remove the
4040, 4008, and 4009, and build my own system with them.

Would I be correct in thinking that the 4008/4009 (or the later 4289
that replaces them) only serves to interface to program memory, but
does not provide means to add RAM in the data address space?  (I know
that you can put RAM in the program space and write to it with the WPM
instruction, but that's nowhere near as convenient to access for
data.)

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

[william degnan]

On Thu, Mar 17, 2016 at 1:59 PM, Mattis Lind  wrote:

> 2016-03-17 18:50 GMT+01:00 Paul Birkel :
>
> > 11/70:  M9301-YC -- E-F Slot #1.  It's specially wired like everything
> > else in Slot #1 through Slot #39.  SPC doesn't start until Slot #40.
> M9302
> > goes in Row A-B Slot #44.
> >
> > KW11 (clock) goes adjacent in Row D Slot #1.
> >
> > Row C Slot #1 is empty.
> >
> > Rows A-B Slot #1 take the FP & CP maintenance modules, if in use.
> >
> >
> >
> I just found a rather unfocused picture of the backplane of a 11/70. And my
> guess was completely wrong. As you wrote it is in slot 1 EF. And the M9302
> in the last slot as normal.
>
> /Mattis
>


I took a look at my 11/40, it has a 9312 in pos 1/2 in the middle of the
2nd/rear of two backplanes here:
http://vintagecomputer.net/digital/PDP11-40/NPG.JPG

With this arrangement I can boot into the console monitor installed on the
9312.
http://vintagecomputer.net/digital/PDP11-40/Console_test.JPG
-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

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

[Al Kossow]

On 3/18/16 9:15 PM, Paul Anderson wrote:

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?




no, but I have nothing with a LESI interface, so finding a whole running
system would be better

PDP-8/a parts, 8 inch CDC floppy drives, 5.25 inch FH Tandon drives, TI SilentWriter, DECprinter I, LA30

[Mattis Lind]

I saw that there were a post on PDP-8/a systems (and parts).

I have a few 8A100 chassis. These are H9300 with a G8016 regulator board.
No CPU, no memory, no frontpanels. Just the H9300 chassis including the 10
slot backplane, the 50Hz transformer assembly and the G8016 MOS memory
regulator.

BTW. The backup batteries are probably not in good shape any longer.
Nothing is tested so capacitors etc might need checking.

There are also some G8018 regulators, 50 Hz transformers for
8A400/8A600/8A800 boxes, 50 Hz transformers for 8A420/8A620/8A820 boxes
(these are really very heavy).


Then there are two CDC / IMI floppy drives. BR8A5D. Single sided. 8 inch.
http://i.imgur.com/cMp76YA.jpg
http://i.imgur.com/EA91ayu.jpg
http://i.imgur.com/pWpmdX6.jpg
http://i.imgur.com/eP3m06n.jpg

They are in the original box. Not sure if these are new or not. They look
fine. But haven't tested them. I might be able to test if there are
interest.

Then two Tandon TM100-3 Single sided 80 tracks  / 96 TPI drives. Tested
working.
http://i.imgur.com/UOnHNNI.jpg
http://i.imgur.com/F4ypilz.jpg

We have one too many of TI SlientWriters. I have no picture of it
currently. But is som 7XX model I think. Printing on thermo paper. Interest?

We have a few DECprinter I aka LA180. A manual can be included as well...

And since we got one LA30 working just fine, we don't need another one.
There is one DECwriter / LA30 available. It is complete but will probably
need care and attention to get working.

Everything is located in Sweden so shipping can be rather expensive for
heavier items.

Trade for something interesting...

/Mattis

Re: Connecting a Cambridge Z88 to the Internet

[Liam Proven]

On 18 March 2016 at 15:09, Austin Pass  wrote:
>> On 18 Mar 2016, at 14:04, 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.
>>
>
> I haven't, but have all the pre-requisites to giving it a go...

I'd be fascinated to hear of any gotchas if you were curious enough to
give it a go. My skills at things like making serial cables are very
minimal indeed.

-- 
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: Resistor/Fuse replacement (DEC H7104-D)

[Josh Dersch]

On 3/17/16 5:44 PM, Adrian Graham wrote:

On 17/03/2016 22:46, "Vincent Slyngstad"  wrote:


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.

Yep, that was me looking for the same part. Does yours look like this?

http://f0p.co.uk/r22.jpg

According to Onecall Farnell 'a blue band at position 5 indicates 20%
tolerance' which would make it a tolerance multiplier of 2.

However the only ones they sell are 5% tolerance, ie brown-black-gold-gold
not brown-black-gold-silver + blue, but the technical chap I spoke to seemed
certain these would be ok. I bought 5 just in case.

Onecall are education-only suppliers but the same part numbers work with
Farnell/Element14. Part# is 1692450.



Thanks!  Yes, that looks very similar except mine has a tolerance rating 
of 10%.  Vincent helpfully pointed me at:


http://www.digikey.com/product-detail/en/tt-electronics-irc/SPP2UL1R00JLF/989-1272-1-ND/4215463

which look like they should do the job, and I ordered a handful just in 
case I ever need a few more.


Thanks again,
Josh

LAST CHANCE for VCF East exhibit registration

[Evan Koblentz]

Everyone,

There is less than one month until showtime.

I'm declaring noon ET tomorrow as the final deadline for registering 
exhibits.


Exhibits so far:
http://vcfed.org/wp/festivals/vintage-computer-festival-east/vcf-east-exhibits/

Exhibit registration:
http://www.vcfed.org/registration/east_exhibitor_register-online.php

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

[william degnan]

On Thu, Mar 17, 2016 at 4:02 PM, Mattis Lind  wrote:

> >
> >
> >
> > I took a look at my 11/40, it has a 9312 in pos 1/2 in the middle of the
> > 2nd/rear of two backplanes here:
> > http://vintagecomputer.net/digital/PDP11-40/NPG.JPG
> >
> > With this arrangement I can boot into the console monitor installed on
> the
> > 9312.
> > http://vintagecomputer.net/digital/PDP11-40/Console_test.JPG
>
>
> This means that you not have the terminator in the last slot of the bus,
> right? Since your bus is so short it won't probably matter.
>
>
Dave McGuire and I went over the system and concluded the same, basically
it's either put it there or I can't have an RL02 drive controller because
the NC Grant.  Dave pulled the NC Grant wire from the backplane (where the
NC Grant card is now).

Anyway, I think the RAM card I have installed in this machine is
conflicting somehow with the RL02 attempt to initialize, this is TBD, but I
can't quite boot the machine.

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

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

[Noel Chiappa]

> From: David Bridgham

> how the GE processor mapped each segment to physical memory on its own
> while the x86 maps the segments into a single 2^32 byte linear address
> space first and then maps that to physical memory.

Oh, right, I remember there was a 4GB limit on physical memory (which I
mentioned in an earlier message in this thread), but I'd forgotten the
details.

The paging is done on that 4GB linear address space, so it's separate from
segmentation - on the 645 at least, the two are jumbled in together, which I
find over-complex. I like the clean separation between paging and segments.

> The x86 got this one wrong, in my opinion, as it means you can't have
> full-sized segments if you have more than one effective segment.

Well, but that's in the implementation, invisible to the user (in a properly
done OS). The user-visible architecture is 16K segments (8K local, 8K
global), of up to 4G each, or 2^46 total address space (per process).

Yes, not more than 4GB of them can be resident in memory at any one time, but
I'm not convinced that's a problem.

Noel

RE: Code listings for the I4004 or I4040

[Paul Birkel]

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Friday, March 18, 2016 5:41 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Code listings for the I4004 or I4040
.

I had a failed 4201 chip (clock gen), it would be nice to come across a
replacement, but solved the problem with a substitute made from 3 CMOS
chips. 

-

Brent:  Could you share your CMOS circuit design for a 4201 substitute?
THX!

Re: Code listings for the I4004 or I4040

[Brent Hilpert]

On 2016-Mar-17, at 10:11 PM, dwight wrote:
> Also, I've found a source for 5.185MHz crystals.
> ACE Components has some. They are in San Jose, on Oakland Rd.
> Dwight


I have two items which use 4004 procs, one is a Prolog M900B E/PROM programmer 
ca. 1979.
The manual includes the firmware source. (Somewhat bizarrely, it's 
typed/printed onto coding forms.)
Here are the first two pages (photos, not scanned). 
http://www.cs.ubc.ca/~hilpert/tmp/m900pgm1m.jpg
http://www.cs.ubc.ca/~hilpert/tmp/m900pgm2m.jpg

I've had to do some reverse engineering and work on the hardware (can provide 
schematic) but haven't sat down to examine the firmware.
There are 12 more pages if it's of interest. It's not quite a complete program 
though, the plugin modules have chip-specific subroutines in more onboard 
1702s, and those aren't included in the source provided.
I do have ROM dumps for two of the modules that could be disassembled.

I had a failed 4201 chip (clock gen), it would be nice to come across a 
replacement, but solved the problem with a substitute made from 3 CMOS chips. 

RE: ACE Key codes (xx2247 etc.)

[Jay West]

FYI - the key codes I measured previously for Data General and HP have been
cut, tested, and verified. Amazingly, my measurements were correct. So to
summarize:

XX2247
Code: 5173757
Use: DEC PDP-8 (all varieties), PDP-11 machines that do not use an ACE blank
(11/24, 11/44)

XX2065
Code: 1353757
Use: Data General Nova (800,1200,1220,2,3) Eclipse (S/130,S/200)

XX2946
Code: 4557457
Use: Hewlett-Packard 2100A/2100S

NOTE: The codes above are listed 7-1, and all key cuts are center offset.

Still unconfirmed or need more information:

Cromemco: XX4306
Code: (Mike Stein was going to measure his cuts)
Use: Cromemco Systems CS-1/CS-3/CS-100 

J

Re: OKI if800 CP/M

[Jason T]

On Mar 16, 2016 20:47, "Chuck Guzis"

> 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.

Sure, or a 22disk image, if you think you have the same disk I do. Just
something to check against to see if I'm "doing it right."

J

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

[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

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 

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

[Mouse]

>> As for buffer overruns, the point there is that a buffer overrun
>> clobbers memory addressed higher than the buffer.  If the stack
>> grows down, this can overwrite stack frames and/or callers' locals.
>> If the stack grows up, all it can overwrite is locals for the
>> current frame and unused stack space.
> If the stack is in its own segment, you get to use the segment
> protection hardware to catch overruns.

That doesn't help when (a) the stack grows downward, (b) all stack
frames are in the same segment, and (c) function-local arrays are on
the stack.  Running off the end of the buffer still trashes the memory
following, which includes stack frames and calling routines' locals.
All the segment protection does is prevent you from running off the
stack into non-stack memory, which is not how typical buffer overruns
work.

To stop that, you'd have to either (a) put each stack frame in its own
segment (which means a _lot_ of segments, potentially) or (b) adjust
the segment limits with each call/return (possible, but makes it
difficult to work with pointers to variables in the stack frames of
calling routines); (b) also requires keeping the stack frame outside
the segment or below the locals.

It would help to have two stacks, one for locals and one for stack
frames, but buffer overruns could still scribble on calling routines'
locals with a downward-growing stack.  Not as bad as scribbling on the
stack frame, certainly, but still not good.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Code listings for the I4004 or I4040

[dwight]

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: Connecting a Cambridge Z88 to the Internet

[Austin Pass]

> On 18 Mar 2016, at 14:04, 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.
> 

I haven't, but have all the pre-requisites to giving it a go...

-Austin.

Re: Connecting a Cambridge Z88 to the Internet

[Adrian Graham]

>I'd be fascinated to hear of any gotchas if you were curious enough to
>give it a go. My skills at things like making serial cables are very
>minimal indeed.

I know exactly where my Z88 and power supply are, serial cable and modem
not a problem. But! Dial-up services? I could RS232 onto a VAX...

A

On 18 March 2016 at 14:20, Liam Proven  wrote:

> On 18 March 2016 at 15:09, Austin Pass  wrote:
> >> On 18 Mar 2016, at 14:04, 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.
> >>
> >
> > I haven't, but have all the pre-requisites to giving it a go...
>
> I'd be fascinated to hear of any gotchas if you were curious enough to
> give it a go. My skills at things like making serial cables are very
> minimal indeed.
>
> --
> 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)
>



-- 
adrian/witchy
Owner of Binary Dinosaurs, the UK's biggest home computer collection?
www.binarydinosaurs.co.uk

Re: Code listings for the I4004 or I4040

[dwight]

There is a 4201 by national semi on ebay.
I bought a 4201 recently for around $10.
I'm mostly looking for a 4040. I have a 4289,
three 4002-1s and two 4002-2s. I'd like to setup
the 4289 such that I have a boot ROM and then shadow
it into RAM. I'd then disable the ROM and run on
RAM only. The 4040 is a lot easier to setup for
both write and read from the RAM.
I also have an extra 4004 but it is an early zebra.
I'd like to hang on to it.
Dwight



From: cctalk  on behalf of Paul Birkel 

Sent: Saturday, March 19, 2016 11:40 AM
To: 'General Discussion: On-Topic and Off-Topic Posts'
Subject: RE: Code listings for the I4004 or I4040

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Friday, March 18, 2016 5:41 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Code listings for the I4004 or I4040
.

I had a failed 4201 chip (clock gen), it would be nice to come across a
replacement, but solved the problem with a substitute made from 3 CMOS
chips.

-

Brent:  Could you share your CMOS circuit design for a 4201 substitute?
THX!

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

[Mattis Lind]

2016-03-17 13:49 GMT+01:00 Noel Chiappa :

> > From: Mattis Lind
>
> > I was thinking of using a M9301 board to get a console emulator and
> > some different bootstraps with the 11/05. But can I just put the
> M9301
> > in the slot where the M930 normally goes?
> > ...
> > M9301 goes into MUD slots. But can it go into the slot where a M930
> > normally sits?
>
> I haven't personally looked into doing this in detail, so I can't give a
> definitive answer, but your last question here makes alarm bells go off in
> my
> head.
>
> The M930 is designed to go in UNIBUS In/Out slots. These slots do have
> different wiring from the A/B MUD slots. (For instance, UNIBUS In/Out slots
> have _single_ pins assigned for BG4-7 and NPG, providing 'grant in' or
> 'grant
> out' functionality, depending on if it's an In or Out slot. I don't recall
> offhand what function/signal is on those pins in a MUD slot, but I'm pretty
> sure it's not a grant!)
>

The BG signals are used for +20V, Parity Detect and "reserved" in a MUD
slot. But these pins are provided through jumpers from the pullup resistors
to the bus and to be installed in a MUD slot these jumpers need to be out.

I am curios about the note saying that these jumpers need to be installed
in a 11/70. Why?  I tried to scan som 11/70 documents but did not find in
what slot the M9301/M9312 should go. Maybe it sits in the last slot on the
Unibus and that is why it need to have these jumpers installed?


> I would be fairly astonished if a device intended for a MUD slot would work
> in a UNIBUS In/Out slot, and vice versa.
>

>From the schematics I get that there is no real difference between M930 and
M9301 unibus wise if the jumpers are out. And thinking of this a bit more
these jumpers should be out unless I install it as the last terminator on
the bus. It makes no real sense to terminate the BG signals close to the
processor.

The M930 is grounding some more pins. That's about it. I will go home and
do some measurements on slot 4 AB to see how it is connected.

/Mattis


> Noel
>

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

[David Bridgham]

On 03/17/2016 11:59 AM, Noel Chiappa wrote:

> > Each segment
> > is in it's own address space; any memory reference was, per force, a
> > segment number and offset.
>
> In this last sentence, is that referring to Multics?
>
> If so, that is exactly how the x86 _hardware_ works, 

He might have been referring to how the GE processor mapped each segment
to physical memory on its own while the x86 maps the segments into a
single 2^32 byte linear address space first and then maps that to
physical memory.  The x86 got this one wrong, in my opinion, as it means
you can't have full-sized segments if you have more than one effective
segment.  Or if you can do it, it's going to be a painful process of
keeping multiple versions of the segment table that maps in different
windows of the full-sized segment you're trying to access.

Baydel Unibus disk systems

[Mike Ross]

Folks,

I've found something I forgot I had; a Baydel Unibus disk controller.
At one time I had 3 or 4 of these in complete systems but carelessly
managed to trade them all away(!) - except this one board.

They were all identical; a pdp-11/04 with a quad Unibus Baydel disk
controller hooked up to an 8" hard drive in a separate rack mount. In
use the Baydel subsystem emulated multiple RK05s.

The part number on the board is B01061. Unusually Google seems to be
utterly silent on the subject; it seems Baydel and these products have
slipped beneath the digital waves without trace. Does anyone have any
information?

I just have the controller board; I don't have any of the hard drives
left. All I remember is the disk was an 8" and the interface is a
single 40-pin cable; so not SMD and not SCSI. Far too early for IDE or
ATA. Any suggestions for what the interface might have been and what
disks might have been used? What hard disks were around in late 70s /
early 80s that used a single 40-pin connector??

Thanks

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

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

[Noel Chiappa]

> From: Mouse

> Well, what was the largest virtual memory space available on various
> machines?

I have thought, on occasion, about simulating a segmented machine on a
non-segmented machine, i.e. one with large unidirectional addresses (segmented
being a bi-directionally addressed machine) - in fact, I think it was in the
context of the VAX that I went through this mentally.

I don't recall any more the exact outcome of my mental design processes (it
was a _long_ time ago), but I have this vague recollection that it could sort
of work, but that it would be ugly (as in, the compiler would have to simulate
cross-segment pointers, etc - they don't look just like normal pointers as
there has to be provision for binding them when first used, etc).

> Now that 64-bit address space is becoming common

Large unidirectional machines do have one advantage, which is that the
canonical flaw of single-level-storage on a segmented machine is that really
large objects don't fit in a single segment, unless you have ridiculously
large addresses (e.g. 80 bit). When simulating segments on a unidirectional
machine, one can of course make any individual segment as large as one likes
- up to the total size of the unidirctional machine's address space.

Noel

Re: MEM11A Update

[Eric Smith]

On Thu, Mar 17, 2016 at 3:35 PM, Guy Sotomayor  wrote:
> I’m planning on doing a 4 layer board so I can avoid having routing issues 
> due to 3 different
> power supply voltages (yea, modern low voltage design meets 5v).  I haven’t 
> done a 4 layer
> design before, so I’m in for a bit of learning (mainly on how to “pour” the 
> inner layers).

In Eagle, you use the polygon tool, select the layer, and draw the
polygon for the entire board outline (or wherever you want the pour).
Then you use the "name" tool, select the polygon, and give it the name
of the net you want it connected to (e.g, GND).  Once you've done
that, any time you do a ratsnest command, Eagle will recalculate the
polygon and connect all through-holes of that net to the polygon (with
thermals by default). It doesn't recalculate as you add or move
components, so it will look wrong until you give another ratsnest
command to recalculate it.

While working on the layout, I find the display gets annoying with the
polygons shown. Rather than hiding those layers, you can type "ripup
@;" to remove the polygon routing until the next ratsnest command. I
do that because I often have a few signals going through the layers
that are otherwise mostly power planes, and I don't want to hide the
entire layers because I want to see those signals.

Of course, this also works on the top and bottom side if you want
copper pour there.

Re: Code listings for the I4004 or I4040

[dwight]

I find it interesting that most applications seem to use a small amount
of RAM but a lot of ROM.
When the 4004 was designed, it had the extra pins assigned to select
more banks of RAM instead of ROM.
By the 4040 time they added more ROM select controls.
I don't think I've ever seen all possible RAM banks used.
Also, you see most applications using 1702s instead of 4001
or 4308. I've never seen a 4308 in the wild.
Dwight

Re: ISO: VAX-11/75

[Ken Seefried]

> My call for a VAX-11/750 a month or so ago actually bore some fruit
> (locally, even!) and as of a couple of weeks ago, I now have a very
> nicely configured 11/750 system taking up most of the basement.

Some guys have all the luck.  Now if anyone in the Southeast has a 750
they're no longer attached to...

Congrats

KJ

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

[Mattis Lind]

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?



> TTFN - Guy
>
>
>
/Mattis

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

[Mattis Lind]

> > This means that you not have the terminator in the last slot of the bus,
> > right? Since your bus is so short it won't probably matter.
> >
> >
> Dave McGuire and I went over the system and concluded the same, basically
> it's either put it there or I can't have an RL02 drive controller because
> the NC Grant.  Dave pulled the NC Grant wire from the backplane (where the
> NC Grant card is now).
>

I am not sure what you mean by NC grant. On the other hand, when I think
more about it, it is a little bit weird with this setup. A MUD slot does
not carry the BG signals. And the M9312 does not terminate them unless
there is five jumpers installed. This means there will be no terminator for
the BG lines.

I am not familiar with 11/35-11/40. Is there a terminator in the other end
of the bus or is it on one of the CPU boards?

The 11/04 (and 11/34) terminate the BG signals locally at the CPU board
(since they are not terminated by the M9312 board in the MUD slot), the
11/05 does not terminate the BG signals on the CPU board it self but relies
on the M930 close to the processor.

So just maybe the BG signals are not propagating very well from the
processor back to the device since there are no terminator for them in the
far end? Just a thought.



>
> Anyway, I think the RAM card I have installed in this machine is
> conflicting somehow with the RL02 attempt to initialize, this is TBD, but I
> can't quite boot the machine.
>

I cannot really understand how the RAM card can conflict with the RL02
controller unless they are broken somehow. Fault in the address decoding
maybe? I have a QBUS memory board that responds to almost the entire range.


/Mattis

MEM11A Update

[Guy Sotomayor]

Just wanted to let folks know where the MEM11A (as opposed to the UMF11) is.

All of the verilog code is written for the CPLD and I’ve simulated full unibus 
transactions
to the FRAM and everything seems to work.

I’m almost done with schematic entry.  I just have a few things to clean up and 
verify.

I’ve done basic component placement (still have to finish placing the 40+ 
bypass capacitors).

I’m planning on doing a 4 layer board so I can avoid having routing issues due 
to 3 different
power supply voltages (yea, modern low voltage design meets 5v).  I haven’t 
done a 4 layer
design before, so I’m in for a bit of learning (mainly on how to “pour” the 
inner layers).

I’m still undecided if I’m going to place some (or all) of the bypass caps on 
the backside of the
board.  It would make things easier especially around the 100pin CPLD.

At this point I’m hoping to FAB a set of prototype boards in about a month from 
now (mid to
late April).  I’ll hand populate a couple (total prototype FAB run will ~5 
boards) and test them 
out.  I’ll be using my 11/34, 11/40 and possibly my 11/20 for testing these so 
there should be
pretty good coverage.

I should know pretty quickly after I’ve started debugging the prototypes what 
the price will be
for the assembled & tested boards.  I’ll start taking orders then.

I’ve also decided that the Unibus interface IC’s will be socketed (mainly I 
don’t want to deal
with the “wastage” from the assembly house for NLA parts).  It also means that 
if some of
my stock don’t work, it’s an “easy” fix.  For those that care, I’ll be using 
machined pin
sockets (gold plated of course).  Any for any that ask, no I will *not* be 
making the boards
available without the drivers.  I’ll be providing fully assembled and tested 
boards.

TTFN - Guy

Connecting a Cambridge Z88 to the Internet

[Liam Proven]

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: PDP-11/05-NC with M9301?

[Noel Chiappa]

> From: Mattis Lind

> I was thinking of using a M9301 board to get a console emulator and
> some different bootstraps with the 11/05. But can I just put the M9301
> in the slot where the M930 normally goes?
> ...
> M9301 goes into MUD slots. But can it go into the slot where a M930
> normally sits?

I haven't personally looked into doing this in detail, so I can't give a
definitive answer, but your last question here makes alarm bells go off in my
head.

The M930 is designed to go in UNIBUS In/Out slots. These slots do have
different wiring from the A/B MUD slots. (For instance, UNIBUS In/Out slots
have _single_ pins assigned for BG4-7 and NPG, providing 'grant in' or 'grant
out' functionality, depending on if it's an In or Out slot. I don't recall
offhand what function/signal is on those pins in a MUD slot, but I'm pretty
sure it's not a grant!)

I would be fairly astonished if a device intended for a MUD slot would work
in a UNIBUS In/Out slot, and vice versa.

Noel

Re: Code listings for the I4004 or I4040

[Kyle Owen]

On Thu, Mar 17, 2016 at 1:43 AM, Eric Smith  wrote:
>
> Unfortunately I do not, but I've recently become interested in such
> things, as I have received from a friend's estate an old board from an
> embedded system (possibly a cash register) which has a 4040 CPU.
> Photos here:
>
> https://www.flickr.com/photos/22368471@N04/sets/72157665878868081/


Wow, an engineering sample 4040. Very nice. Highly sought after by those
CPU collectors out there. You should be abel to build a nice system from
that. No telling what those hybrid packs did. Can't say I've come across
many 4004/4040 designs with such devices.

Kyle

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

[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.

TTFN - Guy

Re: Code listings for the I4004 or I4040

[william degnan]

>
>
>
There is a nice 1975 iasis inc.educational book series about
microcomputers.  Volume III covers "The 4-bit Microcomputer" and takes a
person step by step through the 4004 processor, and it came with a
reference card.  It covers the entire chip set for the i4000.

-- 
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

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

[Mouse]

>> 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'?

Well, some architectures have autodecrement move-to-memory and
autoincrement move-from-memory, but not autoincrement move-to-memory or
autodecrement move-from-memory.  The Super-H is an example; I don't
know whether x86 is another.

As for buffer overruns, the point there is that a buffer overrun
clobbers memory addressed higher than the buffer.  If the stack grows
down, this can overwrite stack frames and/or callers' locals.  If the
stack grows up, all it can overwrite is locals for the current frame
and unused stack space.

Actually, it might be interesting to do a VAX OS that used P1 for
program text and data and P0 for an upwards-growing stack.  (It'd mean
not using the VAX stack instructions, since they have a
downward-growing mindset wired into them, but the VAX _does_ allow
mixing either kind of auto-modify with either direction of data move,
so that would be a minor annoyance at worst.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: PDP-8/a parts, 8 inch CDC floppy drives, 5.25 inch FH Tandon drives, TI SilentWriter, DECprinter I, LA30

[Paul Anderson]

I have M8315s, M8316, M8317, M8357s (RX8-E), etc if anyone needs any to go
with the boxes.

Paul

On Sat, Mar 19, 2016 at 12:12 PM, Mattis Lind  wrote:

> I saw that there were a post on PDP-8/a systems (and parts).
>
> I have a few 8A100 chassis. These are H9300 with a G8016 regulator board.
> No CPU, no memory, no frontpanels. Just the H9300 chassis including the 10
> slot backplane, the 50Hz transformer assembly and the G8016 MOS memory
> regulator.
>
> BTW. The backup batteries are probably not in good shape any longer.
> Nothing is tested so capacitors etc might need checking.
>
> There are also some G8018 regulators, 50 Hz transformers for
> 8A400/8A600/8A800 boxes, 50 Hz transformers for 8A420/8A620/8A820 boxes
> (these are really very heavy).
>
>
> Then there are two CDC / IMI floppy drives. BR8A5D. Single sided. 8 inch.
> http://i.imgur.com/cMp76YA.jpg
> http://i.imgur.com/EA91ayu.jpg
> http://i.imgur.com/pWpmdX6.jpg
> http://i.imgur.com/eP3m06n.jpg
>
> They are in the original box. Not sure if these are new or not. They look
> fine. But haven't tested them. I might be able to test if there are
> interest.
>
> Then two Tandon TM100-3 Single sided 80 tracks  / 96 TPI drives. Tested
> working.
> http://i.imgur.com/UOnHNNI.jpg
> http://i.imgur.com/F4ypilz.jpg
>
> We have one too many of TI SlientWriters. I have no picture of it
> currently. But is som 7XX model I think. Printing on thermo paper.
> Interest?
>
> We have a few DECprinter I aka LA180. A manual can be included as well...
>
> And since we got one LA30 working just fine, we don't need another one.
> There is one DECwriter / LA30 available. It is complete but will probably
> need care and attention to get working.
>
> Everything is located in Sweden so shipping can be rather expensive for
> heavier items.
>
> Trade for something interesting...
>
> /Mattis
>

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

[Mattis Lind]

2016-03-17 18:50 GMT+01:00 Paul Birkel :

> 11/70:  M9301-YC -- E-F Slot #1.  It's specially wired like everything
> else in Slot #1 through Slot #39.  SPC doesn't start until Slot #40.  M9302
> goes in Row A-B Slot #44.
>
> KW11 (clock) goes adjacent in Row D Slot #1.
>
> Row C Slot #1 is empty.
>
> Rows A-B Slot #1 take the FP & CP maintenance modules, if in use.
>
>
>
I just found a rather unfocused picture of the backplane of a 11/70. And my
guess was completely wrong. As you wrote it is in slot 1 EF. And the M9302
in the last slot as normal.

/Mattis

Re: Code listings for the I4004 or I4040

[Klemens Krause]

On Fri, 18 Mar 2016, Brent Hilpert wrote:



I have two items which use 4004 procs, one is a Prolog M900B E/PROM programmer 
ca. 1979.
The manual includes the firmware source. (Somewhat bizarrely, it's 
typed/printed onto coding forms.)
Here are the first two pages (photos, not scanned).


We have this Prolog 900 too and I remember the hand written firmware listing 
in the manual. It should be somewhere in a pile of papers.

And we have the Prolog M980, which contains a 4040.

And we also have a PCB, containing a 4004 system. I once reverse 
engineered the hardware and added a keyboard an a display to it. I wrote a
program for an desktop calculator. Integer only, but it can calculate 
square roots. With luck the source for this should be on an old PC of 
mine.

look at www.computermuseum-stuttgart.de/dev/i4004
(sorry, I didn't translate this page.
We have also the "MCS-4 Users Manual" (Feb. 1973, Rev. 4). It contains 
some coding examples (16 digit addition,  BCD to binary conversion, A-D-

converter)

Klemens


--

klemens krause
Stuttgarter KompetenzZentrum fyr Minimal- & Retrocomputing.
http://computermuseum.informatik.uni-stuttgart.de

Re: ISO: VAX-11/75

[Mike Ross]

On Fri, Mar 18, 2016 at 10:38 AM, Ken Seefried  wrote:
>> My call for a VAX-11/750 a month or so ago actually bore some fruit
>> (locally, even!) and as of a couple of weeks ago, I now have a very
>> nicely configured 11/750 system taking up most of the basement.
>
> Some guys have all the luck.  Now if anyone in the Southeast has a 750
> they're no longer attached to...

I'm also looking for a 750... since I'm in NZ it's pretty inevitably
going to involve a long haul!

Also on the lookout for 50Hz RA series drives - RA81 RA82 RA60 etc...
my US ones are 60Hz and conversion to NZ 50Hz isn't really practical.

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'