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

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?

[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

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

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

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

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

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

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

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

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