Hi,
I have really fond memories of this operating system (from before the
SVR4 Solaris days). It was the first UNIX I used (and I'm still a big
BSD fan).
(Not sure what the protocol is here for asking something like this so
if I run afoul of a copyright policy or something, just tell me to
stop asking and I will.)
Is there any way someone can get their hands on an install disc for
this? I have some old SPARC hardware that it would be fun to run on
if I could find the installer.
Thanks,
Bryan
> From: William Degnan
> OMG
Yeah, but look at it this way: their being inverted can be a memory jogger -
'Oh, the DL11, that effed-up interface where the jumper sense is inverted
between address and vector!' Then you only have to look up one of the two.. :-)
> Yes, so I can use a terminal with the machine, I need a working
> terminal.
"Terminal" != "console". (Or, rather, the latter is a unitary subset of the
former.) The 'system console' is, by definition, on all PDP-11's, a DL11-type
serial interface at 777560. However, it may have many 'terminals'! :-)
>> For 777560/60 (standard for the console), you want A7/A3 and V4/V5 'in'.
> I think you mean 60/64, right?
Sort of (unless you mean 'instead of 777560/60, you meant 60/64, right?').
777560 is the base address, 60 is the base vector.
The receiver registers are 777560-2, and the transmitter are 777564-6, but on
the DL11, one can only set the base of the entire group of 4 registers, one
can't move the transmit and receive around independently. Similarly for the
vector, one can only set the base; the receive (B) and transmit (B+4) are
paired in the hardware.
Hence, "777560/60".
Noel
I have a PDP-11/23 with two RL02 drives, in a third party rack, that I
need to rehome. The PDP does not have any cards installed! Nothing has
been tested.
Available! Cheap! Always open to trades. The rack is a shorty, and I
could deliver it within reason.
I still have those MINC-11 cards, too.
--
Will, in IBM land NY
> From: William Degnan
> Does anyone have a M7800 (DL11) set for 9600 b N71 or N81 jumper'd with
> the default address for use as a serial terminal interface?
Yup. (And BTW the baud's not jumpers, it's the dials.)
> I understand the other jumpers on the card, but the address and vector
> jumpers confuse me.
Join the crew... :-)
The simple rule on the DL11 is that vector jumpers are the inverse of address
jumpers: for the vector, jumpers are 'in' for '1', and for the address, they
are 'in' for '0'.
> I think for use as a simple serial terminal interface I need to jumper
> "in" *A9, A7, A5, A4, A3* ... correct? Vector jumpers *V6, V7 "*in" .
You mean for the console, right? (All DL11's are 'simple serial terminal
interfaces' ;-).
The jumpers you give are for DL11 #1, address 776500, vector 300. For
777560/60 (standard for the console), you want A7/A3 and V4/V5 'in'.
Noel
I am in possession of two Magnavox (North American Philips) CM8562
monitors. Out of the box they handle composite and digital RGBI (CGA)
input. What I'd like to do is get one to handle analog RGB (like arcade
boards, Amiga, Atari ST, and Apple IIGS put out). I wouldn't think this was
possible, but I seem to have a certain memory that I saw mention of doing
just that *somewhere* on the web a few years ago, even though I can't find
that mention now.
According to the rather unwieldy chart at
http://gona.mactar.hu/Commodore/monitor/Commodore_monitors_by_model_number.…
, the service manual and schematic for the Commodore-branded 1084 and
1084S-P is "also good for Magnavox ... CM8562". I assume this means the
monitors are basically the same underneath. Both of those Commodore
monitors support analog RGB. However, when I look at the service manuals
provided for those, they specifically state in several places that parts of
the manual referring to analog RGB do not apply to the CM8562.
Also, according to
http://www.retrocomputing.net/parts/commodore/1084S-P1/docs/1084p/readme.txt
, there are two chassis designations, which both confusingly include the
string "CM8562": CM8505/CM8562/CM8705/CM8762, 8CM505/8CM515/8CM542/8CM643
on the one hand; and 8CM542/CM8562/CM8762 on the other. The latter is noted
as only accepting digital RGBI.
Physically, both monitors I have have an 8-pin DIN input for the digital
RGBI, and a circular area with the legend "lin RGB" underneath. One one
monitor, that circular area is perforated; on the other one, it's just a
circle but with no indication that it can be easily knocked out. I have not
yet opened either one.
So... does anyone know if these monitors can in fact be made to accept
analog RGB? Or have a way I could tell after opening them up? And, of
course, I'd like instructions on just how to do it, if it is possible.
--
Eric Christopherson
I have two brand-new 13" green screen monitors available.
We got them at work from a surplus source a LONG time ago, I
think to replace failing monitors in Graph-on 140 terminals.
These are Motorola DS4003-500 units, with AC power supply
for either 120 or 240 V operation.
They take a card-edge connector for video and sync. (I
think they are RS-170 for composite sync, but I'm not
completely sure.) I used a scope to pick up the horizontal
frequency, it was 53.6 us or ~ 16.5 KHz.
I did power one of them up, and it gave a green raster when
the brightness was turned up.
Anybody interested?
Jon
Everyone,
CHM contacted me. They're seeking copies (or better yet, original disks)
of Lotus Development?s Executive Briefing System for the Apple II and
Prentice-Hall?s VCN ExecuVision for the IBM PC.
The software is not on Bitsavers, Archive.org, etc.
Contact: dbrock at computerhistory.org
-Evan
2016-06-11 22:00 GMT+02:00 Pete Turnbull <pete at dunnington.plus.com>:
> On 11/06/2016 18:17, Mattis Lind wrote:
>
>> I just dig out this little thing form my father stash of various stuff.
>>
>> When bringing up the setup screen it does not look like the one in the
>>
> > manual.
>
> I love the way they felt they had to explain the keyboard at such length.
> And explain that the unmarked key is the space bar - I remember when I was
> about 6 or 7, having to ask my dad how to get a space on his office
> typewriter.
>
> I was also amused to see they have a section on connecting it to the UK's
> BT lines (in the days when things needed BT Approval) so it's obviously
> intended for UK use, yet it's pictured with an American power lead.
Unfortunately for me my unit does not seem to be the same as the one in the
manual. The section on connecting to BT lines is probably still valid since
it does have a Rockwell modem board in it.
I did find an old Computerworld ad from 1989 which matched. Informer 213 -
emulating a 3274 control unit with an attached 3178 mod 2 terminal. Someone
with IBM knowledge might share what that means and how the terminal can be
used.
Anyway. I put together a webpage on the thing:
http://www.datormuseum.se/peripherals/terminals/informer-213
/Mattis
>
>
> --
> Pete
>
Hi all --
Having overcome my earlier issues with SIMH, I now have MULTOS/8 happily running on the real hardware, with two terminals. (Yay!). I'd like to get the system up to four terminals and here's where I'm running into trouble.
I've modified PARAM.PG appropriately (set JOBS to 4, TERMS to 4, and filled in the device codes for the extra terminals). I've rebuilt JOBS.BN and MULTOS, ran BUILD and inserted J1 through J4 and everything runs and the system comes up with 4 terminals (yay!).
What isn't working properly are the job devices J1 through J4 -- each of these provides each terminal/user his/her own "virtual" drive on the system's RK05 pack -- effectively it partitions the RK05 into four smaller drives, J1: through J4:. With the two user setup, J1: and J2: are approximately 3000 blocks in size (so each basically gets one side of the RK05 pack). With the four-user setup, I'd expect J1:, J2:, J3: and J4: to each be about 1500 blocks, but they're still reporting as 3000 blocks each.
What's more, the actual starting offsets of J1: through J4: appear to be what I'd expect (that is, J1 starts at 0, J2 starts at ~1500, J3 starts at ~3000, etc.). So if I start filling these drives, eventually they clobber each other.
The only manual I've found (http://www.pdp8.net/os/multos8/) suggests that these should be appropriately sized (see section 2.1.1) automagically, but this does not seem to be the case; doing a ZERO on them creates a filesystem 3000 blocks in length.
I'm digging through the source code to look for clues, but I haven't found anything yet.
Anyone fooled with this before?
Thanks,
Josh