Look further down the list for a post entitled
"Re: New acquisition"
This guy has the the most boo-ti-ful DS570 Decdatasystem I have ever
seen.
All the right periperials, LA36 console priner, VT crt and what looks
like an LP11 line printer.
Get a load of that lights and switches front panel.
I think the DS570 is the 11/70 version.
Rod
-----Original Message-----
From: cctech-bounces at classiccmp.org
[mailto:cctech-bounces at classiccmp.org] On Behalf Of Rod Smallwood
Sent: 17 September 2007 17:39
To: General Discussion: On-Topic Posts Only
Subject: RE: Help identifying a PDP-11
A couple of other things have come to mind.
DEC DataSystem usually indicated that it supported *DIBOL running under
OS/8, RT11 or VMS
They were intended to be a business package system ready run and often
included training, installation and maintenance.
There's a possible confusion here 'DEC System' refered to a DEC10 or
DEC20 and DEC DataSystem to one of these package jobs.
*Program Structure like COBOL. Syntax like Fortran/BASIC. BCD Arithmetic
Rod Smallwood
-----Original Message-----
From: cctech-bounces at classiccmp.org
[mailto:cctech-bounces at classiccmp.org] On Behalf Of Tim Shoppa
Sent: 17 September 2007 13:50
To: cctalk at classiccmp.org
Subject: Re: Help identifying a PDP-11
> Can anyone help me identify my latest PDP-11 rescue. Not been able to
> get a good look at it yet as it is in a room packed (and I mean
> packed) with junk. Machine consists of a DEC Datasystems cab (about
> 35-40U with a blue bottom panel, pretty similar to light blue cabs
here:
> http://www.computermuseum.li/Liste/Digital/PDP11.70.4.html)
> I'm not familiar with the DEC Datasystems versions of PDP-11s. Does
> anyone have any background information on them?
> Also, I'm pretty sure I've not lucked out and found an 11/70 as no
> toggle switch console, any ideas on what other models were fitted to
> these cabs. I'm guessing 11/34.
That is an 11/70, but with the "remote diagnostics console". You will
find a M8255 KY11-RE in there to connect up a modem to give remote
console access. Probably hooked up to a modem that was owned by DEC
maintenance org and leased as part of the maintenance agreement. I'm
sure that sometimes they asked for the modem and console back if the
maintenance contract was terminated but as a practical matter I find
that they hardly ever reclaimed the equipment.
Tim.
Hi,
I just wanted to let y'all know that I recently acquired a DEC 2065. I
put up a quick web page of how my shop is being reorganized to
accommodate the new "toy". Warning this is not a permanent location (ie
if you link to it you may not find it in a month).
http://web.mac.com/ggs17/site
--
TTFN - Guy
----------------Original message:
Date: Mon, 17 Sep 2007 23:57:59 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: PS/2 Interface (was: Wang 300 Calc]
>> When I think about it, the MITS 8800 had connector punchouts for DB25
>> *only* in the back panel. DB25 seemed to be the lingua franca back
>> then for hobbyist interfaces. If one had an 8" floppy drive, one ran
>> the ribbon cable right through the crack between the back panel and
>> the case cover directly to the controller card(s). No DD50s.
>I have an S100 amchine called a CASU Super C. It contains a Cromemco CPU
>board, some other stnadard 64K RAM bvoard, a Micromation Doubler disk
>controller and CASU-designed boot ROM and seiral interface boards.
>The disk drive (a Persci) is in a separate box. The 50 wire interface
>cable is split down the middle adn connected to a pair of DB25s...
>-tony
---------------Reply:
Cromemco did the same thing with their external 8" IMI hard disks; the Z-2
could have one internal (sacrificing half the slots to make room) but if you
wanted more you got a 2-drive HDD cabinet the same size as the Z-2
connected through 2 DB25s.
mike
Hi,
I've been doing some more work on the FDD
reader/writer, and I came across
an interesting note on the Software Preservation
Society website:
> We cannot yet support the Catweasel for technical
reasons, primarily because
> it does not yet enable us to read disks in
sufficient detail for dumping, nor
> does it allow writing IPF files back to disk. And
while it does seem that the
> Mk4 would be suited to the job, current models are
still running Mk3 firmware
> and drivers, meaning that we are still no closer
forward in this regard.
>
> As soon as Mk4 firmware is available for these
cards, we will do our best to
> obtain one with a view to support it for these
purposes. Until then, our hands
> are tied.
[http://www.softpres.org/glossary:catweasel]
Now what I'd like to know is, what part of the
Catweasel's design prevents it
>from being used for archiving discs?
From what I remember, the Amiga FDD controller is a
bog-standard raw reader
with an MFM sync detector. All it does is sync up to a
bitstream and read it
>from the disc as a raw stream until it gets told to A)
shut up or B) receives
another MFM sync.
From what I've read, the Catweasel differs only in
that it measures the
timing between bits, and can do MFM pre-decoding. So
what part of its design
makes it such a bad choice for this kind of work?
FWIW, I'm almost at the point where I can start
thinking about doing the PCB
designs for the USB floppy disc reader/writer. I've
found a solution to the
lack of I/Os on the microcontroller (which involves
adding a second CPLD to
act as an bus expander - probably over I2C). I'm going
to do some testing on
the bus expander Verilog code tonight, and update the
schematics, then any
spare time I get next week will probably be spent
working on the PCB artwork.
My intention is to take a weekend off work at some
point in the next month to
build up the prototype and do some coding and testing.
If all goes well, I
might do a small production run in November, depending
on interest.
--
Phil. | (\_/) This is Bunny.
Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your
signature to help him gain
http://www.philpem.me.uk/ | (")_(") world
domination.
Phil,
I have seen the SPS website you mentioned and read
this thread but for the life of me I cannot understand
why the Catweasel would be unsuitable for archiving
vintage computer floppy disks.
If fact, I think a Catweasels raw "bit dump" would be
the idea archiving format since it records all the
details found on the track. Maybe wrap the raw data
in a container format with metadata like the DMK.
With Catweasel, you can see everything on the track
clock, data, junk, etc. Whatever is there you can see
it in the raw data. Once you have the raw bit dump
you could make near identical copies or write programs
to extract the data files, work with emulators, etc.
Regardless of the SPS position, I know some people are
already using the Catweasel for archiving vintage
computers. Tim Mann's software pretty much covers the
almost the whole soft sector disk format spectrum and
Jim Battle made a SOL-20/PTDOS hard sector disk
imaging program. I think someone else made a program
to archive Data General disks.
Catweasel seems like the way to go to me. If there is
something else out there as good, especially for the
hard sector disks, I would certainly like to hear
about it.
Has anyone tried Disk2FDI on any hard sector formats?
It sounds interesting and inexpensive if it works.
Thanks!
Andrew Lynch
Try www.bulgin.co.uk and go for the General Connectors page
(http://www.bulgin.co.uk/Products/GenPurpose_Connectors/GenPurpose_Connector…)
Many type on that page but I think you should see what is described towards
the bottm.
Mike.
> Anyway, the connectors I am thinking of were part of as series. They were
> circular, most of them were chassis mouting plugs and cable sockets. The
> plug was recessed into the panel, and the socket part fitted into it.
> There were 1.5A and 5A versions with 2, 3, or 6 pins. Polaraision was
> acheaived by a groove down the side of the socket part and a
> corresponding ridge in the recessed plug. In many cases the wire
> terminals on the socket part were covered by a simple screw-on cap which
> means they're not not approved for use above 50V (since you can unscrew
> said cap and get access to live parts without the use of a tool). There
> were later mocels of some of the sockets with the cover held on by
> screws, AFAIK those are still OK for mains use.
>
> If you like I can tey to find the part numbers for them.
>
> -tony
>
>
--------------Original Message:
Date: Fri, 14 Sep 2007 21:09:17 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: Wang 300 Calc
>
> On 13/09/2007, Gordon JC Pearce <gordonjcp at gjcp.net> wrote:
>
> > It still doesn't excuse having a physically-but-not-functionally
> > interchangeable connector for PS/2 mice and keyboards, though. That is
> > where USB has a big win.
>
> Absolutely 100% concur. That was criminally stupid.
IIRC, the PS/2 mouse interface and PS/2 keyboard interface are very
similar. Both are TTL level interfaces with clock and data lines, both
have 4 signals on the connector (+5V, ground, clock, data), and the data
transfer protocol is much the same.
IIRC, the pin assignemts of the 2 interfaces is the same too, and it's
possible to make a device where you can plug the mouse and keyboard into
either connector, and detect what sort of device is plugged into a given
socket. The fact that most PCs didn't let you do that is not the fault of
the interface.
So why not use the same connector for the 2 interfaces?
-tony
-----------------Reply:
Why not indeed; old Compaq laptops have a single connector which will
accept either a mouse or an external keyboard (an external key_pad_ used
a submini earphone-type connector).
IBM allowed for both together; a mouse or external keypad connected directly
to the single connector while an external keyboard required a Y adapter
which routed the keyboard clock & data signals to the two unused pins.
And then there are the dual-mode mice which put RS-232 on the unused pins
and came with an adapter so they could be used either way...
Laptops were probably also a reason for reducing the size of the connector.
"Criminally stupid"? I suppose you'd also want incompatible connectors for
the right & left channels of your stereo? ;-)
Funny how on the one hand I read the sentiment here that people should be required
to pass a course in advanced computer science before being allowed to plug in a
computer, and then that they should be so simple to hook up that a retarded^H^H^H^H
mentally-challenged blind^H^H^H vision-impaired chimpanzee could do it;
just no pleasing some folks...
m
>> The FDI format (google "Disk2FDI") is open and complete, and there's a
>> few emulators supporting it (WinUAE, others that are also non-Amiga).
>> Doesn't require a catweasel either.
>
> Wow, looks like it can handle both raw bitstreams, and decoded bitstreams too,
> not to mention fully decoded sectors...
It doesn't appear they've ever has do deal with anything but soft-sectored formats
though.
Hi,
I've been doing some more work on the FDD reader/writer, and I came across
an interesting note on the Software Preservation Society website:
> We cannot yet support the Catweasel for technical reasons, primarily because
> it does not yet enable us to read disks in sufficient detail for dumping, nor
> does it allow writing IPF files back to disk. And while it does seem that the
> Mk4 would be suited to the job, current models are still running Mk3 firmware
> and drivers, meaning that we are still no closer forward in this regard.
>
> As soon as Mk4 firmware is available for these cards, we will do our best to
> obtain one with a view to support it for these purposes. Until then, our hands
> are tied.
[http://www.softpres.org/glossary:catweasel]
Now what I'd like to know is, what part of the Catweasel's design prevents it
>from being used for archiving discs?
From what I remember, the Amiga FDD controller is a bog-standard raw reader
with an MFM sync detector. All it does is sync up to a bitstream and read it
>from the disc as a raw stream until it gets told to A) shut up or B) receives
another MFM sync.
From what I've read, the Catweasel differs only in that it measures the
timing between bits, and can do MFM pre-decoding. So what part of its design
makes it such a bad choice for this kind of work?
FWIW, I'm almost at the point where I can start thinking about doing the PCB
designs for the USB floppy disc reader/writer. I've found a solution to the
lack of I/Os on the microcontroller (which involves adding a second CPLD to
act as an bus expander - probably over I2C). I'm going to do some testing on
the bus expander Verilog code tonight, and update the schematics, then any
spare time I get next week will probably be spent working on the PCB artwork.
My intention is to take a weekend off work at some point in the next month to
build up the prototype and do some coding and testing. If all goes well, I
might do a small production run in November, depending on interest.
--
Phil. | (\_/) This is Bunny. Copy and paste Bunny
classiccmp at philpem.me.uk | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.