Hello All,
I've seen references to a CP/M port for the IBM Displaywriter in magazines of the era. Has anyone ever seen this beast in real life? Better yet anyone have a copy of it?
> From: Don North
> If the bootstrap card is an M9312 with the standard console PROM, it
> does NOT require any memory to be present/accessible to get to the ODT
> prompt that prints out the registers and waits for a command.
Ah, right you are; I'm not familiar with the M9312 codes (you seem to have
that all well in hand :-), I've only studied the M873 and M9301 codes.
But the M9301 'console without testing' code does in fact look like it would
run without any memory in the machine. (Which explains some odd features in
the code - I'd always wondered about the 'unusual' subroutine caling
sequence, but now I see it allows it to work without any memory.)
> From: Ed Groenenberg
> ISTR that there is a jumper which selects for +12 or +15 volt.
Not that I am aware of - see the power circuitry in the drawings, MP-00742,
pg. 25. Maybe you're thinking of the M7891 (MS11-L), which does have such
a jumper?
>> The M7891 uses +/-15V as well as +5V?
> Yes, both +5 and +15 is used and measure ok on the backplane.
Actually, having looked at the prints, it also uses either -5V or -12V/-15V
(there's a jumper). So you might want to figure out i) which your system has
(in a BA11-K box, if you have an H745 'brick' you will have -15V, if an H754
-5V; if a BA11-L box, different versions of the H777 provide different
voltages, but I'm too lazy to check :-), and ii) check to make sure the -
voltage is good too.
Although I doubt the - voltage is causing this problem; I'm pretty sure only
the memory chips use it, so it's it's not right, probably the memory would
return bad data, is all.
Noel
I just became the happy new owner of a nice old HP 41C calculator with a matching barcode wand. I haven't powered it up yet, as there's lots of battery compartment corrosion. I'm looking into getting one of the replacement flex circuit assemblies that have been made for it. I was quite curious about the 41C when I saw them in magazines, but I had never touched one before. My first HP calculator was a 28S, and I finally upgraded to a 48GX a couple of years ago. I think this 41C will be a fun addition to my collection once I get the battery compartment fixed up and get it running.
If anybody has any interesting HP 41C peripherals or accessories available for trade, let's talk! eBay and I don't talk any more, so I need to find my new toys the old fashioned way.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
I bought a few cases of those not all that long ago... Let me see if I can
dig up the source.
Mike
On May 15, 2016 2:38 PM, "Mark J. Blair" <nf6x at nf6x.net> wrote:
I think I already know the answer to this ("no"), but is there any
remaining source of usable, or at least restorable, ribbons for the DEC
Correspondent printing terminal? The re-inking roller in the single ribbon
that came with my printer is hard as a rock. Maybe I'll be able to restore
the roller or fabricate a new one, but I wouldn't mind having more ribbons
on hand in any case.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
I am glad to see this effort of Jon's remain Independent. I believe he
would have wanted it that way.
Ed Sharpe archivist for SMECC
In a message dated 5/11/2016 11:50:30 P.M. US Mountain Standard Time,
curiousmarc3 at gmail.com writes:
This is great news despite the sorrow. Thank you for that, the museum is
such an awesome resource for HP collectors. I saw your video on the 2116
restoration were both Jon and you appear. We have at least one more at the
CHM, just as a static display for now. I hope I can visit you in Melbourne one
day.
Marc
Sent from my iPad
> On May 10, 2016, at 2:25 PM, Paul Berger <phb.hfx at gmail.com> wrote:
>
> The following was posted on hpmuseum.org this morning:
>
> *RE: Jon Johnston Passes *
> As an update to the sad news of Jon Johnston's death, I can advise that
the HP museum and the hpmuseum.net website he built will be continued and
maintained for the foreseeable future.
>
> Over the last 8 months I have worked with Jon in restoring items from
his collection of equipment and, among a range of items, recently restored an
HP2116A computer to working order - one of only two Jon was aware of in
the world and the only one that's operational.
>
> At this stage we have not been able to access the website and put any
notices or updates but that should be addressed shortly.
>
> Jon's wife has asked me to look after the museum and website for the
foreseeable future and as much as possible, continue to develop the museum in
line with Jon's vision and objectives.
>
> As a short background, I joined HP Australia in 1982 as a Customer
Engineer maintaining HP3000s, HP250s, all peripherals, terminals etc. I stayed
with HP for over 26 years (including 5 years in Palo Alto) in a range of
Services roles and have many fond memories of the company and the people I
worked with.
>
> While my ability to invest time into the museum is more limited than
Jon's, I hope to honour both his memory and the legacy of the 'old HP' by
keeping the museum going as best I can, hopefully with help from the HP
interest groups across the world.
>
> David Collins
>
I think I already know the answer to this ("no"), but is there any remaining source of usable, or at least restorable, ribbons for the DEC Correspondent printing terminal? The re-inking roller in the single ribbon that came with my printer is hard as a rock. Maybe I'll be able to restore the roller or fabricate a new one, but I wouldn't mind having more ribbons on hand in any case.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
I just got the new boards:
https://www.flickr.com/photos/22368471 at N04/albums/72157668325096875
Differences of new version:
* bezel is black with white legends
* legend font is a bit larger and heavier
* legends are above switches
* switch PCB wiring errors fixed
* right angle header
* plastic caps installed on all toggles
I assembled the new one with C&K switches that are more readily
available (e.g., from Digi-Key and Mouser), but I don't like them as
much. Originally I used switches with a V-bracket which makes
alignment and assembly easier, and they have a uniform threaded
bushing height. The more common toggle switches have a longer threaded
bushing. This can be seen by comparing the edge-on views; for the more
common switches without the V-bracket, the red switch body is seen.
I'm soliciting input as to whether the switch legends should be
changed from the vector font to a "real" font, and if so, what font
and size is desired.
> From: Rob Doyle
> the 'objcopy' utility in the Binutils package can translate between
> binary, tekhex, srec, ihex, etc.
Right, but the problem is that I had dumps which were what the PDP-11 CPU
saw, but due to hardware oddities on the M9301 board, the _ROM contents_ were
diferent: bits 1-8 (_not_ 0-7, which would have been simpler :-) have to be
inverted. I'm not sure any existing tool could manage that!
Speaking of hardware oddities in the M9301, it seems the Tech Manual
(EK-M9301-TM-001) has an error: it seems to indicate that the first (low)
words in the PROM should contain the first words at 173000 ("address
locations 773000 .. are located in the lower 256 words of the PROM", pg. 2-7).
However, looking at the prints, the signal "765XXX L" is fed into the high
address bit of the PROMs, and looking at how it is generated (Fig. 2-8, pg.
2-8) it should be low when the low addresses (765xxx) are being read, so the
low addresses in the PROM should correspond to 765xxx?
Also, looking at Mattis' read-out of the actual PROMs, they have the code
that's at 773000 at 0x100 in the PROM.
So it does seem as if the PROMs aren't organized the way the Tech Manual
claims...
Noel
> From: Glen Slick
>> No, but I do have a un-annotated dump in octal. Can you point me at
^^^^^
>> a description of Intel HEX format
> Or you could just use the SRecord tool package to convert between
> binary / Intel hex / Motorala hex
I had a look through the doc, but I couldn't find 'octal' anywhere... :-)
And anyway, my format is not identical to either Intel or Motorola, so I'd
have to write a converter _anyway_, to get from my format to something a tool
would understand. (Converting my dumper to emit Intel instead of my format
would still mean a lot of work, because I have all these boards dumped in my
format - I'd have to swap them all into the machine to get Intel-format dumps.)
Plus to which the M9301 ROM format is kind of wierd; the high addresses on
the bus (173000 and up) go in the low locations in the ROM, and the low
locations (165000 and up) go in the high, _and_ the low bits (0377) of each
word (i.e. the two ROMs which hold the low bits) have to be inverted because
of a kludge on the M9301 having to do with the way it writes the contents of
the switch to the bus when the machine is starting. So all in all, it's just
easier to...
>> I already have a program to read my octal dump things, so I'll just
>> have to tweak that a bit.
Which turned out to be pretty easy - probably easier (for me, at least) than
understanding the documentation on the SRecord tool page well enough to
understand how to make it do what was needed... :-)
> From: Pete Turnbull
>> Can you point me at a description of Intel HEX format
> Take a look at http://www.dunnington.info/public/IntelHEX
> There's a description and also some code you could adapt.
Thanks for that; alas, by the time I saw it, my brain had turned on and I
remembered this wonderful thing called 'Google', which had led me to info
about the format! :-)
Noel
> From: Dave Wade
>> In theory, the M8044-EE should be an "MSV11-DE" (not "MSV11-EE", that
>> would be an M8045-EE), but none of my documentation, including the
>> M8044 prints, covers such a variant.
> The back of the board says M8045 5013128DP1 32K 18bit MOS memory
All M8044's I've ever seen say M8045 in the etch. The M8044 is the non-parity
version ("MSV11-Dx"), and the M8045 is the parity version ("MSV11-Ex"), and
for the M8044's, they just left one row of chips out.
>> something like a BDV11 or something
> These all seem to have vanished from E-Bay at present.
Paul A has (or used to have) a bunch of them.
Noel
> From: Chuck Guzis
> Styles change.
And like women's hem-lines, they eventually work their way back to a previous
generations' (now semi-forgotten) style.
I remember being amused when black became the 'new' 'cool colour' for PC's;
back to the era of KA10's and early PDP-11's!!
Noel
> From: Dave Wade
> Cards are
> M7264
11/03 processor with 4-Kword MOS RAM
> M7940
> M9400ye
DLV11 Serial Line Unit (system cosole)
REV11-E (240-ohm terminators for Q18)
QBUS termination is a complex subject; when you have multiple backplane
sections, connected by cables, each section has 'termination'. That's what
this REV11-E card is; it's also the QBUS 'out' to the card in the 780 CPU
which the console -11 uses to control the /780 CPU. Why it's in the middle
slot, I'm not sure (unless things have been moved around)?
> M8044ee
> m7946
MSV11-?? (My list doesn't contain an '-EE', but it's some sort of
small MOS memory, Q18)
RXV11 (RX01 8" floppy disk controller)
In theory, the M8044-EE should be an "MSV11-DE" (not "MSV11-EE", that would
be an M8045-EE), but none of my documentation, including the M8044 prints,
covers such a variant. Maybe I need to look in the /780 prints, it may be
a special variant for use in the /780 console machines.
> M8192
LSI-11/73 CPU; a nice machine, if you can eventually get it running. You'll
want a bunch more memory (note that the M8044/8045 cards are Q18, and so you
can only have up to 256KB with them - they _WILL NOT WORK_ in a system with
more than 256KB in it).
> Also have loose grant card....
You mean an M9047?
I would start with just the 11/03 CPU and the console card; hook it up to
something, and see if you can get it to talk to the console. (Configure
the CPU to halt, and fall into Console ODT, on power-on.)
It's probably worth getting one of the various LSI-11 CPU handbooks:
Microcomputer Handbook (1976-77)
Microcomputer Processors (1978-79)
Microcomputer Processor Handbook (1979-80)
Microcomputers and Memories Handbook (1981)
Microcomputers and Memories Handbook (1982)
they all cover the quad-width 11/03 CPU. Although they're probably available
online, it's very handy to have a hard-copy one; those are available on eBay
and such.
That backplane is probably a so-called 'serpentine' backplane, i.e. ones in
which the (dual) slots are numbered:
1 2
4 3
5 6
8 7
so the console would need to go in '3' if it's the only card other than the
CPU (at least, if you want it to be able to do interrupts).
Once you get it working in that configuration, you can configure and add the
memory card (if you can figure out what the devil it is ;-). And then the
RX01 controller.
The REV-11 isn't needed in this configuration. The boot PROM for this machine
was actually on the card in the /780 CPU, so eventually you'll need a
replacement - something like a BDV11 or something (they are available, and
not too expensive).
> From: Robert Jarratt
> The seller said it was indeed out of a 780.
Yeah, that's what it looks like.
> I got the impression the 11/23 card was just a spare he had that he put
> in the enclosure, not really part of the original system.
Actually, an 11/73, but yes, definitely not part of the original system. I
don't know if it will work in that backplane without the backplane being
upgraded from Q18; it might, but that would need some investigation.
Noel
I have two failed Corcom filters in two DEC Rainbows. I see some spares
available in the US, but shipping to the UK is likely to be prohibitive and I
would like if possible to find a modern equivalent. It is this one:
http://meci.com/corcom-12-20129-01-emi-line-filter-model-f2987a.html.
I am told it isn't enough to know the current rating (2A at 240V) and that it
you need to know the source impedance (and the impedance of the load?). Does
anyone know the spec for this filter so that I can get a suitable one?
Incidentally, when I fix these PSUs, I may be wanting to pass on one of the
Rainbows. In this case it would not be free because I had to pay for it (and
drive a fair distance to get it too). The one I may pass on is in a vertical
pedestal. I may also have a third one to pass on which has a fault on the system
board, I don't have a logic analyser capable of helping me to find the fault
though.
Thanks
Rob
Does anyone here know how to order this device? It seems to still
possibly be offered, but I am not sure how to order it.
I'm not sure if the person is on the list, if so you can reply off
list. Looked for faq or shopping or buy pointer, didn't find one.
thanks
JIm
http://retropcdesign.com/forums/showthread.php?threadid=6
Pete Turnbull wrote:
> On 12/05/2016 22:17, Noel Chiappa wrote:
> > > From: Mattis Lind
>
> > > You don't have a dump of the PROMs in Intel HEX?
> >
> > No, but I do have a un-annotated dump in octal. Can you point me at a
> > description of Intel HEX format, so I can whip up a converter program? (Which
> > will also take an array of PDP-11 words, and split it up into the 4 different
> > ROM chips, since each word is spread across all 4 chips.) I already have a
> > program to read my octal dump things, so I'll just have to tweak that a bit.
>
> Take a look at http://www.dunnington.info/public/IntelHEX
> There's a description and also some code you could adapt.
>
Does anyone recognise this hex file format from anywhere?
#00002110F01140007D6C62B70608&2F
#000CED52300119&4A
#00113FCB1287ED6A87ED6A10F076&E4
$
As far as I can tell, the first four hex digits is a 16 bit address,
followed by up to 48 hex digit pairs of data and the hex digit pair
after & is a checksum. The $ appears to be an end of file marker.
It came from a Z80 cross assembler which ran on VAX/VMS. Searching
for information about it has turned up very little except for a
reference on the DECUS website to:
V00250 UCAMS: Universal Cross-Assembler for Microprocessors
Version: February 1987
however, I don't think this is it.
Does anyone have a better description of the file format or
anything that might have produced it?
Regards,
Peter Coghlan
Re: PDP11 M9301-Yx ROM dumps
> From: Mattis Lind
> I checked the contents in the machine versus your listing.
And now that I think of it, I wonder if the ROM in the board I dumped had any
errors? I have two, I should dump the other one and compare - but I forget
which one I dumped, and I fried one of them! :-(
The board did 'work', but I only used the console emulator, and the serial
line loader, so there might be an error elsewhere (e.g. in one of the disk
bootstraps).
> Two locations have the high bit set for some reason, 165020 read 100501
> and 165032 reads 106303.
Well, the second is definitely wrong; not sure about the first, I'd have to
figure out what it's doing with that data word.
> Trying to run halts the machine with 165102 in the front panel.
That's odd, that doesn't make any sense.
> Single stepping it it will step to 165106 but become non-responsive
> with the lights at 165106.
Hmm, does that mean that it actually froze at 165102, or at 165106? (I.e. is
the display the address of the current instruction, or the next one?)
> I think this is because it had a bus fault.
That shouldn't freeze the machine - unless you had a double bus fault (i.e.
trying to push and old PS/PC, and the SP is gubbish). Try loading the SP with
the address of some working memory before you start the test, and see what
happens. You might also deposit 6/0/12/0 in locations 4-12, so that if it
does see an illegal instruction or NXM, it will just halt.
> So for now, it is not necessary with more disassembly. Unless you have
> som spare time of course.
Well, I'll keep working on it anyway.
> You don't have a dump of the PROMs in Intel HEX?
No, but I do have a un-annotated dump in octal. Can you point me at a
description of Intel HEX format, so I can whip up a converter program? (Which
will also take an array of PDP-11 words, and split it up into the 4 different
ROM chips, since each word is spread across all 4 chips.) I already have a
program to read my octal dump things, so I'll just have to tweak that a bit.
I'm going to need to start blowing ROMs soon (including some sets of 9301-YF
PROMs, for the one I zorched), once I get my 29B hooked up, so I might as
well start with this...
Noel
>
> Date: Wed, 11 May 2016 14:27:49 -0700
> From: Josh Dersch <derschjo at gmail.com>
> Subject: Re: PDP-11
>
> > The 8{3|5}50s our biggest customer used had Pro380 VAX CONSOLES, I
> remember
> > our main menu system looked odd on them since they had a bitmapped
> display.
> > I've still got one of them I think, can't remember the last time I
> powered
> > it up but I'm pretty sure it was running TSX-11.
> >
>
> While we're on that subject --
>
> I have a friend locally with an 8550 that's missing the console Pro-380
> system; if anyone happens to have one (with the appropriate VAX interface
> hardware) drop me a line...
>
> - Josh
>
Josh, I donated a Pro-380 VAX console to the RCS/RI crew about 15 years
ago. They probably still have it.
--
Michael Thompson
> From: Mattis Lind
> I also have a YF card. ... I could access the contents but it didn't
> run very well. So either the CPU is still bad or the PROM contents are
> bad. Could you please direct me to your YF dumps so I could compare?
They are on my "Miscellaneous Digital Equipment Corporation PDP-11
Information" page:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/PDP-11_Stuff.html
in the "ROM Dumps" section.
> If you also have done a disassembly that would be very interesting.
I haven't completely disassembled the -YF version, but the -YA is almost all
done, so it should help.
Let me know if you need to have the -YF fully disassmbled & commented, and
I'll hop to it.
Noel
OK, so we already had a dump of the M9301-YA ROMs, but were (apparently)
missing the others?
So I fnally got one of my UNIBUS 11's running, and whipped up a small program
to dump the ROM contents, and now have the -YB, -YF and -YH ROMs dumped. I'm
in the process of disassembling them now.
(If anyone needs the contents in binary format, to blow new ROMs, let me know,
and I can probably produce them if you give me the details on the format you
need the data in.)
Does anyone have any of the others - YC, YD, YE and YJ?
If you're not up to dumping them, I can send you my small program (currently
in .LDA format, but I can convert it to a script - it is not very long at all
- for the console emulator in the M9301 series), which will do it - it
produces packed octal output, 8 words/line, so a very small output.
Noel
> From: Dave Wade
> I have recently a PDP-11 which apparently came from a VAX console.
If that's really where it came from, it's a QBUS 11/03. (And IIRC only the
780 had a PDP-11 console, although I'm not a VAX expert.)
> It looks to me like there are two CPU's in there
Well, as Bill said, send us the 'M-numbers' (on the board handles), and we'll
tell you what you've got - but multi-CPU PDP11's basically don't exist (with
some rare exceptions), and certainly not in a VAX console. So I'm not sure
what you have there.
> and Bus Terminator
Actually, that's the 'QBUS out' connector card; the way the PDP-11 runs the
VAX is that there's a card in the 780 CPU which is on the QBUS (there are
cables that run from the QBUS out to that card), and it allows the -11 to
totally control the 780 CPU.
> I have done lots of searching and there doesn't seem to be a simple
> list of what can run on it
Well, nothing that needs memory management - at least, as it sits. You could
swap out the CPU card for an 11/23 or 11/73, then you could run an OS that
needs memory management (Unix, or one of the DEC OS's that needs it - I know
nothing of the DEC OS's for the -11, someone else here will, though). And
your backplane is probably so-called Q18, limited to 256KB of memory, but
that's easy to upgrade.
Noel
From: ben
Sent: Wednesday, May 11, 2016 5:42 PM
> On 5/11/2016 5:54 PM, Toby Thain wrote:
>> On 2016-05-11 7:43 PM, Liam Proven wrote:
>>> If we'd had 4 decades of effort aimed at fast Lisp Machines, I think
>>> we'd have them.
>> Compiled Lisp, even on generic hardware, is fast. Fast enough, in fact,
>> that it obviated Symbolics. (More in Richard P. Gabriel's history of
>> Lucid.) See also: The newly open sourced Chez Scheme.
> But List still sequential processing as far as I can see? How do you
> speed that up?
This is another of the long-standing myths perpetuated by people who
know nothing about the language.
It has literally been decades since lists were the only data structure
available in Lisp. If you need non-sequential access to process data,
arrays are the ticket, or hashes. Choose the best data structure for
to problem at hand.
(Similarly, data types other than atoms have been around since the very
earliest LISP. They just weren't sexy, and didn't get a lot of press
since they weren't novel and difficult to understand. Math code from
the MACLISP compiler was better than that generated by the F40 FORTRAN
compiler.)
>> The myths around garbage collection are also thick, but gc doesn't
>> impede efficiency except under conditions of insufficient headroom (long
>> documented by research old and new).
> Well GC is every Tuesday here. :)
You joke, but in one of the visionary papers on GC from the early 70s, a
tongue-in-cheek scenario was proposed in which GC was done by a portable
system which had sufficient memory would visit large facilities to do
background GC for them on, say, a monthly basis.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.orghttp://www.LivingComputerMuseum.org/
>
> My father is a civil engineer. When I was a little
> kid, he was in the US Air Force. We would frequently
> go to the runway snack bar, get ice cream and watch
> the B-52s do "touch-and-go" landing practice. The
> plane's wings would "flap". It raised the hair on
> the back of my neck. My dad explained that, if they
> didn't flex, the wings would break off. After a
> while, I understood, intellectually. It still "gave
> me the willies". Later I had a similar experience
> when I was with him in a tall building and realized
> that it was "waving in the wind". Same thing, if it
> didn't flex, it would fall.
That reminds me of the following joke :
There is an airline passenger. During some particularly
turbulent conditions he looks out the window and sees
the plane's wings flexing. He looks very worried.
The flight attendant comes over to him and tries to
comfort him by saying
'Our pilots are fully trained to fly in conditions like
this. It's only turbulence, it's quite normal'
He replies
'You don't undertand. I work for Boeing. I am one
of the men who designed this aircraft. The wings
are not supposed to flex like that.'
> > The other is that, as I said before, any ground
> > connection has impedance (it's the inductance that
> > is troublesome normally) so that points (say IC pins)
> > that are shown as grounded may actually have a
> > voltage difference between them.
>
> If I think about it too much, this gives me the
> willies, the same way.
It's a very real problem, it's the main reason for
decoupling capacitors which provide a local
source of power with a low impedance connection
(as they are so close to the IC).
That's why I said that most times the interconnections
are the hard part of a digital circuit.
-tony
> From: Dave Wade
> Small card, looks like it fits deep in bus.
If it is a QBUS grant continuity card, it will have two looped-back pin pairs
(the QBUS has two grant lines - DMA and interrupt) on the back-side, with a
blank pin between them. (AM2-AN2 and AR2-AS2, to be exact.)
> Any clues on where I can find pin-outs for making a cable.
All the DEC 40-pin serial line headers have the same pintout, AFAIK. So you
can use any of the manuals for the DL11, e.g. EK-DL11-OP-001, available
widely, e.g.:
http://vaxhaven.com/images/4/42/EK-DL11-OP-001.pdf
which uses that same pinout, and has it in great detail, for making a cable.
Those directions produce at DTE cable - if you want to produce a DCE
(suitable for plugging into another computer), you need to reverse RD and TD,
etc.
Noel
I've been looking for a 128K MOS memory board for my PDP-8/A for a while. I finally got one, but it turned out to be an M8418.
The docs I've seen (bitsavers EK-MS8CD-TM-001, 1980 + printsets) talk about an M8417 with 4k DRAM chips (MS8-C) and an M8417 with 16k DRAM chips (MS8-D), but apparently at some point the 16k versions became known as the M8418. The card I received has 96 Fujitsu MB8116E 16k DRAMs, arranged in two 8 x 12 chip arrays. The actual circuit board says PDP MOS MEMORY - M8417 - 50 12701B on the back but the metal card ejector edge is stamped M8418 JC. Chip dates on the board put it at 1980 production.
None of my literature has the M8418 p/n but most of it may be too old. The M8418 part number (with JC suffix to indicate Fujitsu RAM) does show up in the 1988 Options Module List.
I know several list members have similar boards. How are they marked? Can anyone point to more info on the M8418?
Thanks,
Jack
Hi guys,
I scored a cheap Interact Model One (original with chiclet keys). It's an
interesting piece - much larger than photos suggest. It appears to be
somewhat functional (comes up to the press L to load tape screen), however I
lack any tapes to load with it. I've not found any archives of tapes for
this thing anywhere (I guess being an oddball computer like it is, not much
demand). Wondered if anyone out there had one of these and if software was
out there?
Brad
Now that I've cleaned a stack of RK05 DECpacks, I want to keep them clean.
Ideally, I'd like to find Ziploc-style poly bags like the DEC originals with the warning about dirt on the heads (the famous hair/head picture). I haven't been able to find a match for the original (roughly 16.5" square) but I have a sample of U-Line S-14411, a 6 mil reclosable bag that measures 16 x18. It's just slightly snugger than the original but seems to do the job. Does anyone have any other suggestions?
Thanks,
Jack
> Date: Wed, 11 May 2016 07:05:52 -0400
> From: Corey Cohen <applecorey at optonline.net>
> To: cctalk at classiccmp.org
> Subject: Is there a C compiler for CP/M-80?
> Message-ID: <F0EEB6C4-53FA-4E58-94FF-9AC3246415CF at optonline.net>
> Content-Type: text/plain; charset=utf-8
>
> I think the title explains it all. Looking for a C compiler I can run on
my Sol-20
> with CP/M 1.4
>
> Thanks,
> Corey
My goto C for CP/M was always BDS C which is I believe still available along
with source which is now in the public domain.
Comart used to develop system stuff with it in the UK for their S-100 stuff
before moving to DeSmet C for 8088/86.
There is also Aztec C and HiTech C but I don't have any personal knowledge
of them or their current availability.
James
A friend has a large set of paper tape which seems to be from a DG User
group (not sure about that, but label on box sort of implies that).
The tape pile is fanfold about 10" across in a DG box specially made for
such use.
We hope to have a reader to digitize it soon, but wonder if anyone knows
of such a program? We just have the labels which say that is what the
tape has to go on.
More photos and the like later. I know that more info would be helpful,
but figured I'd ask first.
thanks
Jim
Folks,
I have recently a PDP-11 which apparently came from a VAX console. It looks
to me like there are two CPU's in there, a console card, RX02 Controller,
Memory and Bus Terminator. I have done lots of searching and there doesn't
seem to be a simple list of what can run on it, assuming I can find some
RX02 floppy disks to go with it.. Any pointers to documentation? Clues on
how to arrange the cards in the box.
Dave Wade
If anyone knows the dip switch settings, I'd be grateful to learn them please or even better a manual. It doesn't match any of the units currently on bitsavers. Compared to the more common Remex units this one is quite compact.
I tried some test tapes and it produces a regular pattern differing only in a couple of bits, I think it is indicating parity errors, I'm guessing one of the dip-switch settings controls parity.
Hi folks,
Picked up a couple of nice condition VT's today, a VT101 and VT131 though
only one DEC keyboard. 2 other keyboards were included which look identical
to DEC ones but have different keytops and obvious non-DEC cables though
they have the 6mm jack plug on the end. Need to dig into those.
Anyhoo, the VT101's screen is showing the stretch-at-top-compress-at-bottom
issue, is that adjustable using the troubleshooting guide in the technical
reference or am I looking at replacing some caps?
I also get character set glitches and it either doesn't register key presses
or registers too many, I know it's not the keyboard itself since I've tried
my 'DECbox' VT102 keyboard and it does the same. Not looked at the 5V rail
yet, that's a job for tomorrow...
cheers,
--
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?
Since I now have a couple of these and google is coming up blank-ish has
anyone come across a VT keyboard, possibly from a Plessey PT100 style
terminal, that is 99% VT100 in shape, colour and key layout? Even the 6mm
jack plug though I know Apple used that too on the Lisa.
I found a message thread from here in 2002 about the VT131 and what sounds
like an identical keyboard but aside from 'don't knows' and a mention of
Plessey nothing else was found and it descended into chat about scanning
Microfiche. I toyed briefly with the thought that I'd ended up with the VT
and keyboard of those messages but the OP of that was in Champagne IL.
Earlier tonight I dismantled one of them in the hope of seeing a
manufacturer or any sort of branding but nada. There's a 2716 EPROM marked
'PKB00' which I dumped but there's nothing of note in there either.
Maybe the pic will help, maybe not since you'll think 'that's a VT keyboard'
:)
--
Adrian/Witchy
Binary Dinosaurs creator/curator
Www.binarydinosaurs.co.uk - the UK's biggest private home computer
collection?
I can?t remember if I already asked, but I need to find a working example and ask it?s owner to run some tests on it for me to help me diagnose a fault on mine. Ideally the machine would be running VMS.
Thanks
Rob
Sent from my Windows 10 phone
On 05/10/2016 02:33 PM, Bill Sudbrink wrote:
>> The other is that, as I said before, any ground
>> connection has impedance (it's the inductance that
>> is troublesome normally) so that points (say IC pins)
>> that are shown as grounded may actually have a
>> voltage difference between them.
> If I think about it too much, this gives me the
> willies, the same way.
>
>
I have a 3500 Lb Sheldon lathe. During rebuilding of it, I
got a very sensitive electronic level, to aid in making sure
the bed was reground straight. I found that when I walked
>from one end of the lathe to the other, it tilted about one
arc second. That was my weight deflecting the concrete
floor of my basement, causing the lathe to tilt slightly.
All structures, including the earth, deflect under load.
Jon
I figure I'm good for about eighty hours or so of reading and fooling
around with electronics before I'll want to move onto a different hobby
for a while (I rotate through a whole bunch). That's my normal MO. So, I'm
wondering what kind of skills I could build with that time, once I get
started. I'd love to hear if anyone has suggestions for how to use my time
wisely to learn skills that would be most useful for working on older
machines (mid 80's to late 90's is my focus as far as a hardware
bandpass).
Here's what I (think) I know now:
- Basics about electricity. Ie.. Ohms law, power vs frequency, etc..
- I understand basic physics ("A" in 100-level college course and two
years of high school physics, too). I actually had an excellent teacher,
too!
- I used to do math to about a 300-400 level, but now I'm at a 100-200
level (I can still do most algebra II, some trig, and a few other bits).
- I understand what most analog components do (resistors, capacitors,
diodes, etc..). I can run a volt-meter, and super-basic operations with
an analog scope (checking test points and that kind of simple crap) . I
also have a rudimentary rig for soldering etc...
- Since I'm a coder, I understand boolean logic (which I hope would help
with ICs).
- I took a digital electronics course in college. However, it was pathetic
and it's all gone now anyway.
I've spent most of my technical energy learning coding and sysadmin
skills, not hardware. I'm still interested in it, though. I'm most
comfortable with self-teaching via projects. Any that you folks would
recommend (even if they are for kids, I don't mind, I'm not proud) I'd
love to hear about them. Books, project kits, etc.. My goal would be able
to understand 40% of what is happening on an Amiga 500 or that level of
machine. If I could do that.... wow. fun. cool. Plus I bet I could repair
many more items/problems than I can today.
-Swift
Hi there,
I have a Memodyne M-80 Digital Cassette 'Computer' which, in talking to
people more experienced than me, seems to be just a digital cassette
recorder. Googling around there seems to be very little info out there,
although one paper written about their use with scientific equipment
detailed some of the bits triggered to make the recorder operate. Mine has
several cards including a Z80 CPU card and serial input/output.
I was wondering if anyone out there was familiar with these and/or had a
manual? I read these were even used sometimes with SWTPC
terminals/computers, so I'd be interested to see if I can get it running.
Thanks!!
Brad
> From: Diane Bruce
> PL/M wasn't bad either.
I forgot about PL/M...
> Telephone companies preferred deterministic behaviour from their code
> and operating systems.
Not just telco's. Many (most?) people doing stand-alone applications want
this, or something close to it.
> There are many warts in C I would remove if I had the power to. ;)
Eh, don't we all.
My favourite peeve: in cloning BCPL, they left out 'valof/resultis'. That
made certain kinds of macros really, really ugly...
> C is a high level PDP-11 assembler to this day. (auto increment and
> decrement)
This myth persists, but it's wrong. B (the typeless predecessor to C) on the
PDP-7 had them, before the PDP-11 existed, as DMR attests:
People often guess that they were created to use the auto-increment and
auto-decrement address modes provided by the DEC PDP-11 on which C and Unix
first became popular. This is historically impossible, since there was no
PDP-11 when B was developed.
The document that's excerted from:
http://www.bell-labs.com/usr/dmr/www/chist.html
might be of interest here, since it contains a section ("Whence Success?")
containing his take on why C was a success (e.g. "it evidently satisfied a
need for a system implementation language efficient enough to displace
assembly language, yet sufficiently abstract and fluent to describe
algorithms and interactions in a wide variety of environments").
Noel
Oh, another factor that led to success for C, I suspect: I/O is not in the
language, it's handled by optional subroutine libraries. This made it very
easy for compilers/etc to produce language for stand-alone systems. Compare
PL/I, which needed a large subroutine library to run on bare hardware.
> From: Paul Koning
> Algol 68 has both pointers and structures.
Yeah, but Algol-68 never did much (although it had a certain amount of
influence). Why, I'm not certain - I suspect the fact that it was fairly
complex had something to do with it, but I expect its biggest problem was
that a number of _very_ respectd people from its committee denounced it
roundly (whether their reasons were good or bad, I can't say).
Tony Hoare's Turing lecture, "The Emperor's Old Clothes", recounts a lot of
that. (That's the source of the famous quote about "there are two ways of
constructing a software design: One way is to make it so simple that there
are obviously no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." He was talking about Algol-68,
there.)
> So does Pascal.
Which didn't have a lot of the capabilities needed to be system language at
_that point in time_ (remember, this is about 'why did C succeed, back then');
it was, after all, originally designed as a pedagogical language.
> And Modula.
That was late 70's - C was already off and running by then.
> The main thing C has that most other languages don't is *unsafe* data
> typing - the ability to subvert the type system at the drop of a cast,
> and the programming tradition to do this a lot.
{Sighs.} You really seem to have it out for C. You'll never be able to
understand why it was so successful if you start out with the mindset that
it's total crap (even if that's not the way you thought you meant that
comment). That _is_ the implication of that "the main thing that C has"
comment - compared to things available _at the time_, like BCPL, etc, it _did_
have significant advantages.
Does it have issues? Sure. But the main reason it was so successful is that
compared to the other alternatives available _at the time_, it was, overall,
a better mouse-trap. (It wasn't just that it went with Unix - as DMR pointed
out, below, it succeeded in a lot of places that Unix didn't.)
> But it was cheap, available, and good enough to do useful work.
There's a lot of truth to that. Dennis Ritchie's HOPL presentation, "Five
Little Languages and How They Grew":
http://www.bell-labs.com/usr/dmr/www/hopl.html
has a section at the end about "how C succeeded in becoming so widely used",
and it's close to that. Some may consider your description a put-down; DMR I
expect would embrace it.
> I think the answer is simpler: Unix was adopted by a number of academic
> groups because it was available on easy terms
That certainly didn't hurt, but I don't think it was the biggest factor, by a
long way.
I think one of the biggest things is that early Unix (I'm thinking V6, V7)
was a system with an incredibly high bang/buck ratio - for the size, one got
a heck of a lot of functionality. This was important not just for _use_, for
for pedagogical reasons - to give students an example of a well-done system.
The fact that the hardware it ran on (PDP-11's) was modestly priced (for the
day) also helped a lot.
> and it was adopted by a very successful company (Sun)
Unix had taken off big-time before Sun even appeared.
Noel
On 10 May 2016 at 03:12, Eric Christopherson <echristopherson at gmail.com> wrote:
> Gmail always tells me COURYHOUSE's messages would have been treated as
> spam, if I hadn't specifically exempted the messages of this list from ever
> being blocked. I wonder if Google has a prejudice against aol.com
> addresses? :)
No, it's a problem caused by the mailing list, yahoo (and presumably
aol as well) use an authentication system to let recipients validate
that the email is legit. That doesn't work properly with many standard
mailing lists. Google 'dmarc yahoo mailing list', for example.
nope it is working
In a message dated 4/27/2016 10:48:48 P.M. Mountain Standard Time,
dkelvey at hotmail.com writes:
Has the list gone down or just dropped me again?
Hi guys,
I have a Memodyne M80 'Cassette Computer'. From what I've gathered, it's
basically just a digital tape drive (it has about 5 boards in it, including
a Z80 board with an emprom marked '1200 baud', although from one sales doc
it looks like it could have been built out to be a 'general purpose' Z80
computer. I've read these were used for a variety of purposes including
SWTPC terminals like mine.
What I cannot find though is any actual instruction manuals, etc that
explain how to use it. I did find one PDF online as part of a university
paper that described another Memodyne's system a little bit.
Wondering if anyone has any info out there. It's a neat little box to look
at, anyway.
Many thanks, esp. to those like Chuck who were able to offer some useful
advice thus far on it! :)
Brad
Hi guys,
I have a Memodyne M80 'Cassette Computer'. From what I've gathered, it's
basically just a digital tape drive (it has about 5 boards in it, including
a Z80 board with an emprom marked '1200 baud', although from one sales doc
it looks like it could have been built out to be a 'general purpose' Z80
computer. I've read these were used for a variety of purposes including
SWTPC terminals like mine.
What I cannot find though is any actual instruction manuals, etc that
explain how to use it. I did find one PDF online as part of a university
paper that described another Memodyne's system a little bit.
Wondering if anyone has any info out there. It's a neat little box to look
at, anyway.
Many thanks, esp. to those like Chuck who were able to offer some useful
advice thus far on it! :)
Brad
Hi,
I have an InterSystems DPS-1 chassis in pretty good condition
coming my way and I'd like to put an IA-2000 CPU in it. Anybody
have one they might consider selling?
Thanks,
Bill S.
Hi, all. It's been a while since I've discussed anything here. We've made
a lot of progress re-constructing a couple of Point 4 machines (as much as
one can without the actual hardware), yet still need some help from a few
knowledgeable folks in this 35+ year old OS. It was built on the DG Nova
foundation, but made by Educational Data Systems, which became Point 4, for
their Point 4 machines. So, it doesn't exactly "just run" on SimH Nova.
We've been in regular contact with Bruce Ray, who is a true expert in all
Data General and related systems. He has already helped us TREMENDOUSLY.
http://NovasAreForever.org
But other than Bruce Ray, are there any other folks here on this forum who
may have had any IRIS programming, either on the Point 4, or another system
of similarity in the late '70s to early '80s?
I've hunted down a handful of people so far on LinkedIn and scouring the
internet, and only a few of those have responded. But I just thought I'd
make a shout out here. A small handful have kindly responded, with either
limited recollection or availability, or both.
In addition to Bruce, those who have contributed so far include David
Takle, and one of the original Point 4 IRIS designers, Dan Paymar.
We've added a LOT of new content and progress to our
restoration/re-creation of what is turning out to be TWO distinct Point 4
IRIS systems.
Stop by our site if you like, and especially review the directory page
"Understranding IRIS":
http://microtechm1.blogspot.com/p/understanding-iris.html
Does anyone here have anything to add, or IRIS/Point 4 documentation that
could be helpful here (other than what we have at
http://microtechm1.blogspot.com/p/manuals.html ).
Thanks all, I always appreciate the fantastic feedback here.
-AJ
http://MightyFrame.comhttp://MicrotechM1.blogspot.com
I don't suppose anyone has a copy of the CDC 9429 floppy drive
maintenance manual they'd be willing to scan for me?
I have reason to believe that the CDC 9428 and 9429 are identical
except that the 9429 is jumpered for 80 tracks and the 9428 is
jumpered for 40 tracks... but I'm not 100% sure. I do have a copy of
the 9428 maintenance manual, thanks to Bitsavers, but having the 9429
manual would put my mind at ease lest I follow the alignment
procedures from the 9428 manual and screw something up.
-Seth
--
Seth Morabito
seth at loomcom.com
Just picked up a Decmate 2 and have managed to get a monitor, keyboard and
boot disk (I think) setup for it, but when I attempt to boot it, I'm
getting alternating error codes 17 and 19(on different boot attempts).
I've searched and found some of the startup error codes but not these
particular ones. Anyone know where I could find such a list?
Thanks,
Tom
Has anyone ever worked up a PC parallel port to Facit 4070 paper tape
punch interface?
I found one on a Swedish website. The punch parallel input looks like
it is TTL compatible, but I can't find anything in the documentation
that describes the input voltage specifications.
Chuck
If you care, you might want to check out:
ftp://ftp.hp.com:/pub/alphaserver/firmware
I'm always updating firmware on older alphas and I've noticed this site
has undergone some changes lately. I've also noticed that HP's web sites
have been absolutely trashed for a couple of years now. However, now many
alpha related searches return 0 results on most of their portals. When you
do find something, it's often a dead link. Many of the Tru64 pages are all
a broken link, broken CSS, shambles.
Anyhow, my trust in HP is at an all-time-low (more than I even knew was
possible after I got my whopping $26 dollar settlement for them ripping
folks off on ink cartridges and getting class-action-sued for it).
Unsurprisingly, they can't even run a website anymore, and even the FTP
site seems to be feeling the shake up (directories moving around, things
obviously undergoing some major changes). So, you might want to grab
whatever you need off the post-Fiorina walking corpse of HP before they go
full zombie and eat their own brains and lose everything. There are
patches, firmware etc... many things their management would probably
remove if they were literate enough to know they still had them online in
an undamaged form (folks so often forget about FTP).
-Swift
> From: Mattis Lind
> I'll check all PROM chips on both board sets tomorrow.
Check out the Computer History wiki Web page first; I looked at a couple of
boards, and added all the chip types I could find. DEC used a vast variety,
it seems!
Noel
> From: Mattis Lind
> What about compatibility between different revisions? I.e. Is it
> possible to mix DataParh board and Control board from different
> revisions with different microcode?
Well, I don't recall seeing any mention of compatability in the manuals, but
that is not definitive either way. I had a look at the two versions of the
data path board, and it seems to me that they are basically identical in their
interface and function, so that either version would work with any control
board version.
I looked at the interconnects with i) the other CPU board (on the C-F
connectors), and ii) the front console (through the Berg connector), and as
far as I can see, both boards use the same interconnects. I didn't track down
every last pin, and check them all, but I checked many, many pins, and all
the ones I checked were the same.
The two versions don't seem that different, internally. The PROMs are the
same on the two versions of the data path board, for what that's worth -
which is probably not that much. (The PROMs on the data path board don't
contain any microcode at all; that's all on the control board.)
One major difference is that the register file chips on the older board
(which have tri-state outputs, and use that to do a mux) have been replaced
by different register file chips, and real mux chips; however, the two
versions should work identically. There are differences in the area of the
serial line clock, but those should be immaterial.
There are some other minor differences, but again, it seems like they should
also work identically. So, that's the source of my conclusion that the two
versions of the data path card are functionally identical, and can be
interchanged.
Noel
> From: Steven Malikoff
> I was lucky to find an original 11/05 print set dated 1973. For what
> it's worth, the microcode listing in my doc is Revision B
Do note that a lot of the PROMs on those boards aren't actually 'microcode',
and aren't covered in that listing. For instance, on the M7261 (control)
board, there are 7 which aren't 'microcode' (list drawn from the 11/05
article on the Computer History wiki):
A01A2 = E12 = Bus Request -> Grant processing
A02A2 = E30 = Internal address decode (first stage)
A07A1 = E68 = Internal address decode (second stage)
A09A1 = E69 = Internal address decode (second stage)
A09A2 = E101 = Branch utest service
A13A1 = E90 = Internal interrupt acknowledge
A14A1* = E100 = Console switch control
and 10 which are:
A04A2 = E92 = Next instruction (high bits)
A05A2 = E93 = Processor Status Word control
A07A2* = E95 = Bus control
A10A2 = E103 = Next instruction (low bits)
A11A2 = E104 = ALU operation select
A12A2 = E105 = Branch utest
A13A2 = E106 = Multiplexor control
A14A2 = E107 = Bus control
A15A2 = E94 = ALU control
A16A2 = E96 = Miscellaneous
And I haven't included the 11 PROM chips on the M7260 (Data paths) board,
none of which are 'microcode'. So those 'microcode' listings only cover about
1/3 of the PROM chips in the CPU; so one can't use just the microcode
revision level to tell you what's what.
E.g there are two chips different between the C and E etch levels of the
M7261: A07A2 and A14A1 (marked with a '*' above); one is 'microcode', one
isn't.
BTW, when you say that the microcode listings in your 1973 print set are
"Revision B", are you referring to the "Microprogram Flow", "Microprogram
Symbolic Listing", or "Microprogram Binary Listing", because they can be at
different revision levels (given in the box in the extreme lower right
corner)?
E.g. the ones in the KD11-B prints in the GT40 print set (dated February
1973) are 'B', 'C' and 'C', respectively; the hard-copy set I have (not dated
explicitly, but apparently mid-1972, given the modification date on the
'Index' sheet) has 'B', 'B' and 'B'.
> it is *exactly* the same printout as in the the Bitsavers doc Revision
> C
You mean the July 1976 set, the ones with microcode revision levels (as
above) of 'C', 'E', and 'E', right?
That is M7261 etch revision 'F', which uses quite a few different PROM chips
>from the earlier ones, so I'd be fairly surprised if the microcode was
actually identical. I think you'd have to look at every bit to be sure; the
data on which chips changed, here:
http://gunkies.org/wiki/PDP-11/05#Control_PROMs
would allow anyone who wanted to actually do that to focus in on specific
columns of the microprogram to look for differences.
(In fact, the 'F' etch rev has one less PROM chip than the 'E' etch rev, but
I suspect - i.e. I haven't checked the exact function of each chip on those
etch levels - that it's not a micro-program chip, though: there's one less
32x8 PROM chip, and those are generally used for control functions, the
microprogram chips are all 256x4.)
Noel
Has anyone used any modern hardware to interface with HP-HIL gear? (HIL is Human Interface Link, not to be confused with HP-IL.) I?d like to interface an HP 46085A Control Dial Box <http://www.hpmuseum.net/display_item.php?hw=684> with my Mac via USB.
But before I go any further in this?I?ve already put a bunch of effort into trying to get it to work?I realized I should probably ask here to see if anyone else has done it. Has anyone?
HP-HIL uses what *should* be a pretty basic serial protocol with available docs. (Thanks, Bitsavers!) The only odd things about it are (1) a data rate of 100Kbps (rather than say 115Kbps) and (2) the use of 12/O/1 framing (rather than say two 8/E/1 frames per packet and (3) a 12V supply line for what?s otherwise a TTL-compatible bus.
Getting the actual host interface IC is just about impossible without removing it from existing equipment, and the client interface IC doesn?t really seem like it would act as a host. The weird framing means virtually no common UART will work, and the data rate means something like an Arduino only has 160 cycles/bit to work with.
It looks like I might be looking at either using either an Arduino or a CPLD to implement a 12/O/1 UART to talk to the control dial box, and using a second Arduino to communicate with that (via a parallel interface) to actually implement the USB HID via the builtin HID stack functionality on some models of Arduino.
-- Chris
Dear Experts,
during discussing the Rolms I came accross the following question:
What was the first (Minicomputer) architecture which offered
memory- and IO protection? I'd define the minimum requirements as:
- Existence of a superuser mode (Rolm calls this Executive mode)
- Existence of a user mode (With at least two users, Rolm offers 4)
- In superuser mode, IO and memory protection for each user can be
set up individually.
- Any access violation is trapped and handeled by superuser code.
- Of course commands for mode switching and setting up the
memory and IO ranges must exist.
I have got a real machine (Rolm 1602) having this implemented
and dating from 1975. A document on this "Access Protection Module" as
Rolm calls it also is dated 1975. It consists of a microcode module
which realizes an extension of the 16 bit Nova instruction set and an
additinoal CPU module, taking care of the new modes and supervising
the IO- and memory accesses.
My question is not regarding virtual memory memory, but regarding
protection (IO and memory) to ensure capsulation of indivitual
processes - not necessarily for multi user environments but e.g.
for safety critical applications...
Probably OS/2 in 1987 was one of the first home computer OSes to
support memory protection (how about IO protection?), BSD on some
Digital PDP-* was earlier (1977?) but still after the 1602.
Any hints out there on other "Mini" architectures of that era
having someting similar?
Erik.
> From: Mattis Lind
> Now I am convinced that if I program a new A04A2 PROM the machine
> should behave much better.
Indeed! I have annotated the PROM tables on the Computer History wiki page
with the function of each, and that PROM is the high part of the 'next
microinstruction' field, so if it's bad, the computer will be acting very
strangely indeed! :-)
> The failing chip was yet another NS chip in plastic
Can you see the type? I'd like to add to the page lists of all the alternate
chip types DEC used in place of the Intersil chips specified in the drawings.
>> the 'F' etch rev has one less PROM chip than the 'E' etch rev, but I
>> suspect .. that it's not a micro-program chip, though
My guess was correct; the missing chip is the one I called "Internal
interrupt acknowledge"; it was replaced with a 74154 4->16 demux.
Noel
This one has a failed BCACHE, but I am told it will still boot and run VMS,
albeit slowly. I have not tried this myself, but I have verified that it
boots to the console. It is in a BA42B enclosure (i.e. desktop not
rackmount).
Is there any interest or should I just take out the bits I want from it and
then throw it away?
It is in Manchester, UK. I do occasionally travel to the East Midlands and
to the Reading area though. Not keen on shipping it, but will do so if it
means not throwing it away. The machine is free, any shipping would have to
be paid for of course.
Regards
Rob
I want to read the DROM chip with my programmer, but I can't ID the chip. Does anyone know what kind it is? It is in a PLCC32 package and the label on it is:
369E7
AYOMA
49/95
I am sure at least some of that is DEC stuff, unrelated to the type of chip. However, none of those parts of the label seem to correspond to any EPROM I can find. My programmer's software has an auto detect feature, but that also failed to ID the chip. I don't really want to remove the label if I can avoid it.
The underside is marked
76394-23
Singapore
C4
522 (might be 322)
512X
None of these appear to match anything either.
Any ideas what it might be?
Thanks
Rob
> From: Mattis Lind
> Has anyone dumped the microcode of the PDP-11/05?
> ...
> When tracing the microprogram flow it looks very suspicious. Comparing
> the same sequence with a better working pair reveal a few differences.
> All these can be narrowed down to one single PROM chip.
Josh had an 11/05 that had a uROM fail, and he had to blow a new one (IIRC he
sent in a report, it's in the list archive). I'm not sure if it's the same one
as the one you need, but if his post doesn't give the chip ID, no doubt he can
let us know.
> There are microcode listings in the manual but they need to be treated
> to get into a dump.
Which is exactly what Josh did.
Speaking of which, is there any chance we can get those machine-readable
listings online? I can host them with my other DEC material, and I can also
put them in the Computer History wiki.
Noel
Request for information about a Facit 4070.
Yes, it can be hooked up to a parallel port interface. It takes a single 74LS00 chip to generate the proper signals, and the ACK signals. I did it in a simple jumper wire block (it has a male and female connector along with a jumper field.
At the moment I have lost my documentation, but I have a working unit ready to be dissected to produce the proper diagram (it may take a while). I have connected it to a "real" and a USB parallel port and used direct writes to the parallel port device under Linux with no modification.
Also if you are interested, I have a program that sends out block letters to be punched on the tape (along with leader). The letters are 5x7 and the 8th is the descender for lower case letters.
The various docs for the 4070 are on Bitsavers, and you want to be sure that the "option" board just has jumpers on it (as it comes from the factory).
Al mentioned the 940 so I thought I would fill in the details:
Lichtenberger and Pirtle extended the hardware to include a page map: 14
bits of VA was divided into 3 bits of page # and 11 bits of offset. The 8
pages were held in 2 x 24 bit words divided into a 8 x 6 bit page numbers.
The high order bit of the mapped page number served as the Read Only bit.
This meant that "subsystems" (a.k.a. applications) could be shared between
users.
Additionally, the instruction set was protected against users with specific
prohibition against using the I/O instructions.
This was described in FJCC 1965 with modifications done in 1964.
> From: William Degnan
>> I would need a dump of .. at least A04A2 / E102 on the Control board.
> Can you clarify? Is this a typo?
No, there are two different major versions of the M7261 Control board; see
http://gunkies.org/wiki/PDP-11/05#CPU_board_versions
A04A2 is inded E102 on the later major version of the board; on the earlier
version (prints for that version are in the GT40 prints online, pg. 162 and
on) A04A2 is E92.
Speaking of the two major versions, though, I wonder if the ucode in the two
versions is identical? The uROM chip numbers should give it, (if they are the
same on both versions, albeit in different locations on the board), but I have
yet to check. Does anyone happen to know?
Noel
Before there were books of kids doing thins with computers there was:
The Radio Boys and Girls: Radio,
Telegraph, Telephone and Wireless
Adventures for Juvenile Readers,
1890-1945 - A View Though Literature
By Mike Adams
A Review By Ed Sharpe Director and Lead Archivist for Southwest Museum
of Engineering Communications and Computation
Glendale Daily Planet / KKAT-IPTV
Read At
http://glendaledailyplanet.com/the-radio-boys-and-girls-radio-telegraph-tele
phone-and-wireless-adventu-p570-154.htm
Has anyone dumped the microcode of the PDP-11/05?
I am looking into a CPU board pair that are not behaving that well. The
only switch that does anything is the START switch. The rest is doing
nothing. The CPU clock is stopped.
When tracing the microprogram flow it looks very suspicious. Comparing the
same sequence with a better working pair reveal a few differences. All
these can be narrowed down to one single PROM chip.
It doesn't look like it is something else that is wire-ored onto the micor
address bus since the enable signals for all those are inactive. And one
signal is already low so wire-ORing would not change it.
I would need a dump of the chips or at least A04A2 / E102 on the Control
board. There are microcode listings in the manual but they need to be
treated to get into a dump. So if someone already have a dump that would be
highly appreciated.
/Mattis
fido news when he became editor and they are lamenting the Internet
taking away from fido net....
https://gopherproxy.meulie.net/gopher.meulie.net/0/fidonews/2002/fido1902.nw
s
In a message dated 4/30/2016 7:43:59 P.M. Mountain Standard Time,
geneb at deltasoft.com writes:
On Sun, 1 May 2016, Tomasz Rola wrote:
> On Wed, Apr 27, 2016 at 10:07:34AM -0700, geneb wrote:
>> On Wed, 27 Apr 2016, Sean Conner wrote:
>>
> [...]
>>> Just look into the political machinations of what was known as FidoNet
to
>>> see how this could end up.
>>>
>> What IS known as FidoNet (1:138/142 here. :) ) and it's still a
>> political shit-show, mostly due to people from Zone 2. *sigh*
>
> Pardon my ignorant question but is there a place on the net where I
> could read some more about it? Or maybe it is short enough to explain
> here?
>
Books could be written about it unfortunately, One of the more annoying
aspects is Bjorn Felten, the current editor of FidoNews - he's refused
repeated requests to pass on his editor duties for various reasons and
he's refused - for at least the last 10 years. Find a telnetable BBS
that's a member of FidoNet and start reading the FidoNews echo for a taste
of the insanity. The Fido Sysop (FNSYSOP) is also a pretty deranged
place.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
Are there any archived issues of _Processor_ from the 80's or early 90's, online anywhere?
I seem to recall it went through at least one major printing format change (from newsprint to cheap bound magazine or the other way around).
It sometimes had articles but was mostly ads from second-hand minicomputer vendors. Most of what I remember was DEC-aftermarket of course, but there was also overlap with DG, IBM aftermarket, various office machines, and later PC-clones and Sun stuff.
I just received from S&H a PDF copy of the TSX 6.50 Release Notes - and
Jay has posted it to the http://tsxplus.classiccmp.org website.
Lots of interesting/helpful information for all you TSX-Plus buffs...
Cheers,
Lyle
--
73 AF6WS
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
> From: Erik Baigar
> very interesting reading
If you want to see a great example of why it was important, check out the
so-called 'Berlin Tunnel':
https://en.wikipedia.org/wiki/Operation_Goldhttp://www.fas.org/irp/cia/product/tunnel-200702.pdf
Some of the traffic that was intercepted was teletype traffic - which had
been encrypted. However, the equipment that connected the gear to the line
allowed a tiny electronic whisper of the original plain-text onto the line,
along with the encrypted form, and it was possible to read the plaintext off
the line with suitable gear.
Noel
> From: Erik Baigar
>> as was coming up with something that could be both EMP-survivable and
>> TEMPEST-worthy.
> TEMPEST?
A set of standards for allowed levels of emissions (in particular,
electro-magnetic radiation) from communication/computing gear, intended to
prevent listening to the activity of that gear:
https://en.wikipedia.org/wiki/Tempest_(codename)
Noel
At 11:24 PM 5/4/2016, Andy Holt wrote:
>Could someone with access to the OED please check up the first use of the term "minicomputer"
I am not the OED, but when I first saw the TX-0 and the PDP-1 at MIT in late 1964 or early 1965 I believe that I heard the term minicomputer applied to them. Certainly when I next saw them in the summer of 1967 both were being called minicomputers by the staff there.
Dale H. Cook, Roanoke/Lynchburg, VA
Osborne 1 / Kaypro 4-84 / Kaypro 1 / Amstrad PPC-640
http://plymouthcolony.net/starcity/radios/index.html
> From: Erik Baigar
> I wanted to have a computer using core memory and so I bought a black
> box from the Tornado aircraft which contained core. This started a 10
> year yourney of analyzing it, decyphering the command set and building
> tools to program it. ... I have a project page on this:
> http://www.baigar.de/TornadoComputerUnit/index.html
I am absolutely, completely, blown away. This has got to be one of the most
amazing projects I have ever come across. I'm utterly awed by the work you
did to reverse engineer this thing.
Everyone should check out this site - especially the detailed time-line
Noel
On Tue, May 3, 2016 at 10:14 AM, Mike Stein <mhs.stein at gmail.com> wrote:
> What's the best commonly available solvent for cleaning the rubber goo that used to be pressure
> rollers, belts, feet etc.?
On a similar note, does any have a solution to firm up rubber that is
just starting to gooify?
I have some joystick feet that are just starting to get sticky.
--
--
tim lindner
"Proper User Policy apparently means Simon Says."
I was skimming the Wikipedia article for tsx-plus, some of it seemed off to
me. Anyone know the facts for sure?
1) They suggest tsxplus generally didn't support more than 8 users
well. At my high school, we had 16 users on it constantly and it seemed to
perform very well. Anyone have experience along those lines?
2) They say LEX-11 (wordprocessing) was included. I don't believe so.
3) They say a spreadsheet program from Saturn Software was included. I
don't think so. Saturn had a wordprocessor, but it was a chargeable product
and I don't think S&H distributed it.
4) They say the latest version of TSX-Plus has TCP/IP support. That's
not true, at least not built in. There was a TCP/IP stack done by a 3rd
party (actually, think it was a person that ported one and put it in a
public contributed library) but that wasn't "included" by S&H.
Do I have those things wrong?
J
Reminds me of a challenge I had in the early 80's The place I worked
made IC test and evaluation systems, starting price in 1980 was around
$300K and many where close to $1.5 million. This one was for IBM. They
were designing a 288K bit ram and one thing they wanted was to be able
to 'see' failed bits as parameters such as supply voltage were
changed. If you looked at the die it was 9 'squares' of i think 128 x
256 ( i think that was the size) cell or bits. The 9 th was for
parity. The memory was read by the system and a 0 or 1 was stored in a
buffer in the system. The system was run by a PDP11/44 the display was
a Tektronix GMA125 with option 42/43. The GMA 125 was the OEM display
used in the 4116, a 25" DVST terminal. Option 42/43 was feed from a
DR11. The 42/43 could be driven in Tek 401x format (that's the same
you still see today when you put your X11 display into Tek mode) which
had a point plotting set of commands.
So one had to read in a loop this external memory which came back in
some long forgotten 16 bits per something mode, calculate the position
of the 'bit' which was in memory block x and position x and y in each
block and either display a dot or plus or something at the respective
location on the CRT. Doing it all in some time IBM wanted it done in
.. loops within loops within loops and finally a test for 1 or 0 and
out the DR11W.
The only way I could get the code to meet IBM speed requirement was to
do the unthinkable. Upon start the inner most work that was test for
'display if zero' or display if one' was modified to be branch of true
or branch if false.
Sometimes you just have to violate all the rules. Other fun things
were using shifting bits and using indexing for some of the coordinate
translations.
oh well when every instruction time made a difference.
it was challenging but fun
-pete
On Wed, May 4, 2016 at 9:56 AM, Bill Sudbrink <wh.sudbrink at verizon.net> wrote:
> I took a peek at the access logs for the Cromemco Dazzler
> files that I recently put up on my web server. I'm
> gratified to see that a lot of people are taking advantage
> of the availability of these documents, that have not
> recently (if ever) been easily available on the web. I
> also see that a lot of people took the Dazzlemation HEX
> file and the Magenta Martini paper tape image, presumably
> to run on Udo Monk's great Windows Cromemco Z1 simulator.
>
> Also, thanks to everyone that generated pdf files for me!
>
> One thing I noticed is that not many people looked at the
> disassembly of Dazzlemation. If you are an 8080 or Z80
> programmer (or any 8-bitter for that matter) I really
> recommend that you take a look, it's a real treat. I'm
> reliably informed that Mr. Dompier hand wrote that program
> LITERALLY (hand, pencil, paper), no editor, no assembler.
> He then toggled it in (or maybe raw keyed it in with a
> primitive ROM monitor) and went through a few iterations of:
>
> 1) store to paper tape
> 2) modify in memory
> 3) test
> 4) go to 1
>
> It's neat to see some of the "tricks" he used and also the
> level of sophistication of the code. It does a lot of
> stuff in not a lot of bytes. Also, here and there, in
> "dead" areas, you can also see the debris of ideas that he
> started and then abandoned.
>
> Bill S.
>
>
>
I took a peek at the access logs for the Cromemco Dazzler
files that I recently put up on my web server. I'm
gratified to see that a lot of people are taking advantage
of the availability of these documents, that have not
recently (if ever) been easily available on the web. I
also see that a lot of people took the Dazzlemation HEX
file and the Magenta Martini paper tape image, presumably
to run on Udo Monk's great Windows Cromemco Z1 simulator.
Also, thanks to everyone that generated pdf files for me!
One thing I noticed is that not many people looked at the
disassembly of Dazzlemation. If you are an 8080 or Z80
programmer (or any 8-bitter for that matter) I really
recommend that you take a look, it's a real treat. I'm
reliably informed that Mr. Dompier hand wrote that program
LITERALLY (hand, pencil, paper), no editor, no assembler.
He then toggled it in (or maybe raw keyed it in with a
primitive ROM monitor) and went through a few iterations of:
1) store to paper tape
2) modify in memory
3) test
4) go to 1
It's neat to see some of the "tricks" he used and also the
level of sophistication of the code. It does a lot of
stuff in not a lot of bytes. Also, here and there, in
"dead" areas, you can also see the debris of ideas that he
started and then abandoned.
Bill S.
Back in the early 90's I remember that many times I'd see a print
advertisement for a Video Toaster or a new genlock card, they'd say things
like "features you'd have to pay thousands for in a professional paintbox
or titler!" I always wondered what they were talking about, since I'd
never seen how broadcast was done back then (and still don't know). So,
I'm really talking about the tech of the 80's (since that's what the
marketing folks were referring to, I assume).
Here's what I could find that I'm speculating were the "competition" of
the time:
The Quantel Paintbox:
https://en.wikipedia.org/wiki/Quantel_Paintbox
Superpaint running on a DG Nova 800
https://en.wikipedia.org/wiki/Superpaint
The Bosch FGS 4000
https://www.youtube.com/watch?v=9oyGaEu7D7s
These are about the only ones I could find. Does anyone know of any
others?
Also, here are my favorite paint and 2D animation programs of yore. If you
guys have others that you loved and remember, what were they?
DOS
1. Deluxe Paint II Enhanced
2. PC Paintbrush
3. Autodesk Animator
4. Paul Mace's GRASP
5. Deluxe Paint Animation
Amiga
1. Photogenics
2. Photon Paint
3. TVPaint
4. Brilliance
5. Disney Animation Studio
Sorry, I didn't use the Mac enough to form any favorites, though I did
love Fractal Design Painter (now Corel Painter).
-Swift
> I have a Visual Basic 4 application that I need to run on modern 64-bit
> hardware I can do this in a VM, but I really need this VM to be wicked
> small, like under a gig. The smallest XP VM I?ve seen is 600MB (which
> might
> be good) but XP is becoming very hard to source these days.
VB4 was a bridge between 16-bit Windows 3.1 applications and 32-bit
everything later (such as the DOS-based Win-95, -98, and -ME, and all of the
NT-based operating systems, which is everything else through Win-10 64-bit).
As such, the package included both a 16-bit an 32-bit compiler. If your
application was compiled using the 16-bit version, you're pretty much stuck
with XP-32 or earlier (in a VM, if necessary), as it will automatically
spawn a 16-bit virtual environment (ntvdm.exe) to run the 16-bit
applications. Win7 and beyond, and all 64-bit versions, do not support this
feature (I supported a VB3 application for 20 years; Win7 was what finally
broke it for good.)
If it was compiled to 32-bit, then you should be pretty much good to go; you
may run into a few insurmountable problems with some now unsupported OCX's.
Other than those, all of the 32-bit code should run fine on anything
current.
If you have the source, you're also in pretty good shape. VB4 is very easy
to port to VB6; there were almost no backward-incompatible features of the
later Visual Basic classic languages. Find an old copy of VB6 SP6,
re-compile it (perhaps replacing some of the failed OCXs with others that
will work - a common one was DBGrid, which is quite easy to replace with
FlexGrid), and you're golden. I currently support just such an application,
and although the development environment requires a couple of tricks to get
working smoothly, the compiled application works just fine on Win10-64.
Drop me a note off-line if you'd like any additional or more specific help
with this; I have a reasonable amount of experience with just this problem.
Of course, there are always older versions of Wine...
~~
Mark Moulding
Anyone here do any transformer specification or design and would be
interested in some consulting dollars to help me source/create a weird
transformer option?
What I need is a 12V primary, 12V:12V center tapped secondary that can
support 12VA of power. Higher voltages are OK, but not needed. I am
struggling on the Xformer details, but I know it needs to be center
tapped, 1:1:1 @12VA
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
Yet another nice color brochure.
https://dl.dropboxusercontent.com/u/96935524/Datormusuem/lab11.pdf
Has anyone seen a VR20 in real? Rather interesting to be able to do a red
and green X/Y screen based on different energy levels. Someone care to
explain how that works?
If I read the fine print on the back correctly (and comparing with the
others) I would guess that this brochure is from 1971.
For those of you running DECnet/E on simulators...
paul
> Begin forwarded message:
>
> From: Paul Koning <paulkoning at comcast.net>
> Subject: Re: RSTS and slow DECnet operation in SIMH
> Date: May 2, 2016 at 1:37:45 PM EDT
> To: SIMH <simh at trailing-edge.com>
>
>>
>> On Apr 19, 2016, at 2:46 PM, Paul Koning <paulkoning at comcast.net> wrote:
>>
>> With help from Mark Pizzolato, I've been looking at why RSTS (DECnet/E) operates so slowly when it's dealing with one way transfers. This is independent of protocol and datalink type; it shows up very clearly in NFT (any kind of file transfer or directory listing) and also in NET (Set Host). The symptom is that data comes across in fairly short bursts, separated by about a second of pause.
>>
>> This turns out to be an interaction between the DECnet/E queueing rules and the very fast operation of SIMH on modern hosts. DECnet/E will queue up to some small number of NSP segments for any given connection, set by the executor parameter "data transmit queue max". The default value is 4 or 5, but it can be set higher, and that helps some.
>>
>> The trouble is this: if you have a one way data flow, for example NFT or FAL doing a copy, the sending program simply fires off a sequence of send-packet operations until it gets a "queue full" reject from the kernel. At that point it delays, but the delay is one second since sleep operations have one second granularity. The other end acks all that data quite promptly, but since the emulation runs so fast, the whole transmit queue can fill up before the ack from the other end arrives, so the queue full condition occurs, then a one second delay, then the process starts over.
>>
>> This sort of thing doesn't happen on request/response exchanges; for example the NCP command LOOP NODE runs at top speed because traffic is going both ways.
>>
>> I tried fiddling with the data queue limit to see if increasing it would help. It seems to, but it's not sufficient. What does work is a larger queue limit (32 looks good) combined with CPU throttling to slow things down a bit. I used "set throttle 2000/1" (which produces a 1 ms delay every 2000 instructions, i.e., roughly 2 MIPS processing speed which is at the high end of what real PDP-11s can do). Those two changes combined make file transfer run smoothly and fast.
>>
>> Ideally DECnet/E should cancel the program sleep when the queue transitions from full to not-full, but that's not part of the existing logic (at least not unless the program explicitly asks for "link status notifications"). I could probably add that; the question is how large a change it is -- does it exceed what's feasible for a patch. I may still do that, but at least for now the above should be helpful.
>
> Followup: I created a patch that implements the "wake up when the queue goes not-full". Or more precisely, it wakes up the process whenever an ack is received; that covers the probem case and probably doesn't create many other wakeups since the program is unlikely to be sleeping otherwise.
>
> The attached patch script does the job. This is for RSTS V10.1. I will take a look at RSTS 9.6; the patch is unlikely to apply there (offsets probably don't match) but the concept will apply there too. I don't have other DECnet/E versions, let alone source listings which is what's needed to create the patch.
>
> With this patch, you can run at full emulation speed, with the default queue limit (5). In fact, I would recommend setting that limit; if you make the queue limit significantly larger, the patch doesn't help and things are still slow. I suspect that comes from overrunning the queue limits at the receiving end. (Note that DECnet/E leaves the flow control choice to the application, and most use "no" flow control, i.e., on/off only which isn't effective if the sender can overrun the buffer pool of the receiver.)
>
> To apply the patch, give it to ONLPAT and select the monitor SIL (just <CR> will give you the installed one). Or you can do it with the PATCH option at boot time, in that case enter the information manually. The manual will spell this out some more, I expect.
>
> I have no idea if this issue can appear on real PDP-11 systems. Possibly, if you have a fast CPU, a fast network (Ethernet) and enough latency to make the issue visible (more than a few milliseconds but way under a second). In any case, it's unlikely to hurt, and it clearly helps a great deal in emulated systems.
>
> paul
>
On Thu, 4/28/16, Liam Proven <lproven at gmail.com> wrote:
>>> The efforts to fix and improve Unix -- Plan 9, Inferno -- forgotten.
>
> It is, true, but it's a sideline now. And the steps made by Inferno
> seem to have had even less impact. I'd like to see the 2 merged back
> into 1.
Actually, it's best not to think of Inferno as a successor to Plan 9, but
as an offshoot. The real story has more to do with Lucent internal
dynamics than to do with attempting to develop a better research
platform. Plan 9 has always been a good platform for research, and
the fact that it's the most pleasant development environment I've
ever used is a nice plus. However, Inferno was created to be a
platform for products. The Inferno kernel was basically forked from
the 2nd Edition Plan9 kernel, and naturally there are some places
that differ from the current 4th Edition Plan 9 kernel. However, a
number of the differences have been resolved over the years, and
the same guy does most of the maintenance of the compiler suite that's
used for native Inferno builds and for Plan 9. Although you usually
can't just drop driver code from one kernel into the other, the differences
are not so great as to make the port difficult. So both still exist and
both still get some development as people who care decide to make
changes, but they've never really been in a position to merge.
And BTW, if you like the objectives of the Limbo language in Inferno,
you'll find a lot of the ideas and lessons learned from it in Go. After
all, Rob Pike and Ken Thompson were two of the main people behind
Go and, of course, they had been at the labs, primarily working on
Plan 9, before moving to Google.
BLS
>Date: Mon, 2 May 2016 12:37:43 +0200
>From: Mattis Lind <mattislind at gmail.com>
>To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
>Subject: Re: PDP8 MAINDEC ?
> Selling, trading, giving away. What ever works. Rather than the garbage
> bin. I have no need for multiple copies. Just checking if someone like to
> play with the real paper tapes.
> When it comes to digital copies the plan is to check what is already online
> and then scan / read those that aren't. But it is a long time plan since it
> takes quite a while. Unless you feel like helping out... A page feed
scanner and a couple of thousands of pages.
>
> /Mattis
I can take good care of (some part of) it, a bit depending on which tapes
and documents you have.
/Anders
> From: Pontus Pihlgren
> I wonder what the three leftmost cabinets contains. I don't recall what
> peripherals have the blinkenlights at the top. RK05 and TU10
> controllers perhaps?
I have a half-done page with images of all the 5-1/4 inch indicator panels
(PDP-8, -11, -15); so I can identify the indicator panel on the right (above
to the two DECTape drives), which is a TC08 DECTape controller (I have a large
picture of one of those, for the page, and that's definitely it), which makes
sense, given it's in the same cabinet as the DECTape drives.
The other one, I have no idea - anyone?
I'm pretty sure it's not an RK08. The RK08, like the RK11-C, was wired for an
indicator panel, but like the TM08, it only used two rows of lights. (I've
never seen an image of one: this is deduced from reading the engineering
drawings.)
The partial page is here:
http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html
if anyone is interested. Good images of the missing 5-1/4" indicator panels
(which also include the RF11 and FP15, as well as the mythical RK11, which may
not exist) gratefully accepted!
Noel
We have quite a lot of PDP-8 MAINDEC which are duplicates even when taking
different versions into account. This include the paper listing and the
actual paper tape.
Is there an interest in such tapes / documentation?
Just to let folks know that I just received the prototype boards for the MEM11A (FedEx just left).
The boards look great! The parts from Digikey arrived late last week, so once I get my soldering
station set up (new microscope and new Metcal soldering iron) I?ll start to build a couple of boards
to test out. Once I have a couple working *and* I get firm orders for at least 25 boards (hint, hint)
I?ll do a production run.
TTFN - Guy
> From: Guy Sotomayor
> The reality is that an SPC board will be more expensive because of the
> gold edge fingers.
Oh, right, forgot about that. Yeah, six of one...
> I was originally thinking that if I do have to split the board up, that
> I'd make them completely independent. But that has the issue of
> requiring 2x the number of UNIBUS transceiver parts (which are all but
> unobtainium as of now).
Actually, 8641's (at least) are still around for not much. See below.
> some of the signals I'm running are pretty fast between the FPGA and
> some of the other components ... I wouldn't want to run those signals
> very far and certainly not across any sort of cabling.
For sure. We've been having issues (although we think we have it licked now)
with signals running across a flat cable between the prototype QSIC's
mother-card (a QBUS wire-wrap card) and its daughter-card (an bought-in FPGA
devel card), and that's for much slower signals (the only thing on the
mother-card are QBUS transceivers and level converters). Of course, the fact
that the interface doesn't put a ground wire between each pair signals wires
doesn't help! :-)
> From: Ethan Dicks
> I'm starting to get sorry I sold off my surplus NS8641s from Software
> Results 20 years ago. To be fair, I did get over $4 each for them, so at the
> time, it was a good deal for me (ISTR retail was $7.50 even then, so I
> got a good spread on the price).
> I do have some left, but handfuls, not armloads.
NS8641's are still available. I got a bunch from a guy in Hong Kong for
US$1.50 each - considering the source, I built a test card to make sure they
met specs, and they do, so I'm pretty sure they aren't counterfeits. :-)
When I was worried he couldn't find enough, I checked with a supplier (4 Star
Electronics, I think) and they had like 50K available, and quoted me a price
in about the same region, so I don't think UNIBUS transceivers actually are a
problem, at least, not at the moment.
Noel
Sounds like some of the SMR stuff Seagate is working on. Not sure if HAMR needs fs changes or not, but I know SMR does for certain.
Sent from my T-Mobile 4G LTE Device
-------- Original message --------
From: Eric Christopherson <echristopherson at gmail.com>
Date: 5/1/2016 1:44 AM (GMT-05:00)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
Subject: Re: File systems expert for a news article (urgent)
On Fri, Apr 29, 2016, Evan Koblentz wrote:
> >>Anyone here on cctalk consider themselves a file systems expert and have
> >>the credentials or job title to vouch for it? If so, then I need to
> >>interview you ASAP today (in the next hour-ish) for a TechRepublic.com
> >>article. Contact me offline: news at snarc.net.
> >>
> >>Not going to discuss the story itself here in public.
> >>
> >
> >Can you be a little more specific?? File systems is quite broad
> >
>
> One of the hard disk standards bodies is working on a new feature (which I'm
> not going to post here) that would require changes to file systems,
> otherwise the new feature is academic and useless in the real world. So I am
> looking for someone with FS chops to comment on whether the changes can
> reasonably happen. Cannot say more except in private.
Hopefully not something that would require said filesystem
implementators to pay licensing fees or sign NDAs or take affirmative
action to limit users' use of data, or onerous things like that.
--
??????? Eric Christopherson
hilpert at cs.ubc.ca
that is a valid idea....
or a replacement also for TSS-8 using pdp8s but would timeshare
Ed Sharpe Archivist for SMECC
In a message dated 5/1/2016 2:20:53 P.M. US Mountain Standard Time,
hilpert at cs.ubc.ca writes:
On 2016-May-01, at 1:55 PM, Paul Koning wrote:
>> On May 1, 2016, at 4:37 PM, Warner Losh <imp at bsdimp.com> wrote:
>>
>> Cool brochure. When was this price list in force?
>
> Judging by what it advertises, probably 1972, maybe 1973. Unlikely to
be later than that.
I wonder if this MINI-RSTS/BASIC-PLUS was a marketing response to HP's
timeshared BASIC system for the 2100s.