I am working on a deal which includes several PDP11/15 or 20s. I will be
looking at them next week and hope to get more details. I will look for
exact model numbers and configuration.At least 2 of them have non DEC
silkscreens on the front panel.
Also a selection of 11/05 and 11/10 including 5 1/4 box, BA11-D, and BA11-K
units.
If you are interested in a box or parts please email me off list.
Thanks, Paul
The Apple Mac, 40 years old, came from Xerox PARC’s GUI and Apple’s LISA.
Not sure that it really changed computing though! Financially it didn't
help Apple until after 1997 and Gate's investment.
Happy computing!
Murray 🙂
I've been hunting for a while now for OAK PCB mount keyboard switches
that I can't find a part number for. I've attached a product listing for
the switch that shows it pretty well. DPST-NO preferred.
Only $0.40 in the early '70s!
Any quantity considered...
Thanks!
John :-#)#
--
John's Jukes Ltd.
7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3
Call (604)872-5757 (Pinballs, Jukes, Video Games)
flippers.com
"Old pinballers never die, they just flip out"
On Tue, Jan 23, 2024 at 3:05 PM Wayne S <wayne.sudol(a)hotmail.com> wrote:
> Can’t the pack be read and copied on the system it’s currently on?
>
It's not been near a computer since 1979. It's currently in Fred van
Kempen's storage.
Graham
In 1979, the Dutch team of Harry Whitfield's students writing the
Groningen University Time Sharing O/S called GUTS sent an RK05 to Edinburgh
for us to try out on a PDP11/60 we had access to in Steven Salter's
Wavepower project lab. Ian Young spun it up and learned how to use it.
After some years of being out on loan, we hope to have the disk pack
returned to us this year, so I'm now looking for someone reliable who can
recover very old disk packs, preferably in the USA where we can ship the
pack to them, without having to go through customs and risk damage in an
inspection (I remember those scary 1970's diagrams showing the
comparative size of a smoke particle next to the gap between the heads and
the disk surface!). To minimize the risk of damage during shipping, I'm
hoping that the person who currently has it can ship it directly to
whomever we can find who can read it for us, rather than to me and then to
that person.
I'll be happy with a raw disk read, but the GUTS file format should be
backwards compatible with RT11 files so if the disk is readable I don't
think we'll have trouble getting the data off, especially if the person
with a pdp11 runs RT11 on it. If we can get a disk image however I think we
could get it running again under emulation.
Please contact me at gtoal(a)gtoal.com if you know of anyone in the US who
might be able to read this disk pack, or contact them and ask them to
contact me if they're interested.
Thanks,
Graham <gtoal(a)gtoal.com>
PS We have the 3 GUTS manuals in pdf format, but that's the only GUTS
documentation that we know of which survived:
https://gtoal.com/history.dcs.ed.ac.uk/archive/scans/guts/red.pdfhttps://gtoal.com/history.dcs.ed.ac.uk/archive/scans/guts/orange.pdfhttps://gtoal.com/history.dcs.ed.ac.uk/archive/scans/guts/yellow.pdf
FASTBACK bak up ptogrsm...Help how to recover files stored in this backup format,?
Back when the museum was next to computer exchange Inc. Pre '94. We put out a journal once a year Over 100 pages tightly leaded would like to access files and reprint. Would need Pagemaker 3 orveoukd data files be upward compatible with indesign by adob?
Thanks Ed Sharpe archivist for SMECC MUSEUM PROJECT Glendale AZ
Sent from AOL on Android
> On Jan 19, 2024, at 10:34 PM, Rodney Brown <rdbrown0au(a)gmail.com> wrote:
> ...
>
> I'm not a polymath who keeps lots of Assembly mnemonics in my head, so I hoped the "IEEE Standard for Microprocessor Assembly Language" IEEE Std 694-1985 1985 doi:10.1109/IEEESTD.1985.81632 would have taken off. I think only the Motorola 88000 used it and C probably was far more prevalent. I think the HPPA 1.1 then started the trend of SIMD instructions, so the portability would have reduced.
I had never heard of that IEEE standard, and it doesn't seem to have gone anywhere. Which makes sense; assemblers represent the architectural choices of the hardware, so standardizing them is a strange notion. You could standardize a style of construction (making it sort of a "meta-standard") but that isn't very interesting. The general style of opcode and operands had been the predominant style by then, and for a long time before. Other styles, like CDC 6000 Compass (CPU side) or stranger examples seen on Electrologica, haven't been used in ages.
About the only style issue that would be nice to have consistent is ordering: does destination come first, as with ARM and IBM 360, or source first as with PDP-11 and VAX? Then again, I suppose that's just about as hard a problem as byte order.
paul
Forth was ported to an HP-2100 in 1972, by Elizabeth Rather, so had early
history on HP hardware, though from what I can it it was never a product
available from HP.
I don't know if Forth Inc ever supported Forth on HP machines.
Anthony Pepin provided a Forth to the HP3000 Contributed Library in
September 1982, though I think his looks like a virtual machine, I don't
remember trying it in the day.
Thanks to Gavin Scott's "system" and J. David Bryan's SIMH HP-3000 emulator,
I can look at it now.
As Anthony Pepin observed, Forth implementations at the time assumed a
von Neumann architecture. The HP 3000 with a Harvard architecture implying
read-only code with a different address space, needs more thought.
Why Forth?
I've never been a Forth programmer, but as I understand it,
compilers/interpreters weren't standard with HP 3000 Systems, nor were
there
scripting languages like awk, sed & perhaps the Bourne shell on Unix.
A Forth interpreter supporting the HP 3000's supported types & the
mathematical
functions in SL.PUB.SYS (the system shared library), even without
compilation,
would have been bettered by the Unix dc (RPN calculator) only for it's
multi-precision maths.
HP 3000 types (using kludged C <stdint.h> style
int16_t => INTEGER, uint16_t => LOGICAL, int32_t => DOUBLE
f32_hp3k_t = REAL, f48_hp3k_t => LONG REAL
COMPLEX & Packed Decimal?
A Forth supporting code compiled to Data space would have been a useful tool
for learning & testing & perhaps as a scripting language.
With Date & Actuarial procedures added, I suspect our Actuarial students
would
have found it useful. Don't know if it would have been seen as useful at
educational institutions like RMIT here in Melbourne, Australia that had
3000s.
Assemblers in Forth seem to be a common thing, it would be possible to
assemble the Data space code with minor peephole optimization, and the
necessary
translation from modifying the Next Data instruction variable to
branches in the
code. That and the Dictionary entry could then be written out as an
input file
for PATCH.PUB.SYS, allowing the interpreter to be extended without
understanding
the USL format.
I've finally read some of Koopman, Philip (1989) "Stack Computers: The
New Wave" looked a little at his Harris RTX-2000 MS-DOS Emulator source,
and at
James Bowman "J1: a small Forth CPU Core for FPGAs".
Like the HP 3000, the Harris RTX-20[01]0 & the J1 are 16-bit machines with a
16-bit instruction width (soley for the Harris & J1).
Other than the HP 3000, the architecture use the sign bit to use the
instruction
value as a call-target address or decode an ALU operation with some Forth
special sauce.
I've wondered for a while whether the HP 3000 XEQ instruction which
executes a
stack adressable 16-bit word (0..15 deep on the Stack-Up stack (S register))
has been used for anything other than exiting to clean up the stack on a
Ctl-Y
trap.
A virtual Forth machine where negative int16_t values give a negated call
address, with the least-significant bit selecting Code or Data.
Almost all 16-bit HP 3000 instructions are positive.
Below is an SPL sketch of the virtual machine interpreter
Nonsense @ characters are *Fix Me*s
equate Deepest = 15, Dict'Sz = 1024, Padded'Dict'Sz = Dict'Sz + 16;
integer X = X;
logical PB'Address; << Poor Name>>
logical bu'S'15;
pointer restore'S'15;
logical S'15 = S - 15;
logical D'Dict'Used := 0;
logical Code'Offset;
label Next'Word, Execute'TOS, ...
integer array D'Dict(Padded'Dict'Sz);
<< Code must immediately follow, need to access padding perhaps >>
Next'Word:
TOS := D'Dict(Code'Offset);
if < then begin << Call (int16_t < 0) >>
Return'Stack'X := Return'Stack'X + 1;
Return'Stack(Return'Stack'X) := -((Code'Offset + 1) & LSL(1)));
assemble(NEG, DUP);
if TOS then begin << Odd => PB (Code) address >>
PB'Address := TOS & LSR(1);
Assemble (@); << Indirect Jump through PB'Address Variable >>
else begin << Even Data Address >>
TOS := TOS & LSR(1);
assemble(DUP);
if TOS >= D'Dict'Used then begin
Error(@);
end
else begin
Code'Offset := TOS; << Weak bounds check >>
goto Next'Word;
end;
end
else begin << (int16_t >= 0), HP-3000 16-bit instruction >>
Execute'TOS:
bu'S'15 := S'15; << Needs testing, backup the value >>
@restore'S'15 := @S'15; << Save Data address of stack element >>
S'15 := TOS; << Save the instruction as deep as possible >>
assemble(XEQ 14); << Needs testing probably wrong depth number >>
<< Execute the instruction just deposited >>
restore'S'15 := bu'S'15;
Code'Offset := Code'Offset + 1;
goto Next'Word;
end;
<< Not sure how to handle end of the Forth code in Data
Could call to a PB (Code) address or do an indirect branch through
a procedure local to the handle code. So in data, a sentinal of
sorts>>
<< Have Execute'TOS as a label for flexibily >>
<< Basically, Search the DB (Data) Forth dictionary, if found interpret
the data
code, otherwise search the PB (Code) Forth dictionary, if found jump to and
execute the the code directly. >>
<<Restoring & Saving the Status register around each XEQ instruction use,
would be better as a teaching tool & allow using Condition Code effects
when the
Forth word is compiled to Code space. >>
--
The output from BUILDINT.PUB.SYS over a copy of SPLINTR.PUB.SYS gives
the type
signatures of the System Intrinsics and compiler library routines.
This could be curated & processed to generate shims for calling from the
Forth
interpreter, though the Option Variable Procedures would take some thought.
There seem to be ~600 declarations, some of which are duplicate entry points
for the Fortran compiler library for REAL & LONG REAL functions. (ie
RAND & RAND' etc), so you'd need 3 or
more code segments to get around ~256 STT (Segment Transfer Table) limit to
call everything.
Virtual Stack machines executing directly on the HP 3000 stack was what
our COCAM
language did.
Comments? Were HP doing anything like this in the labs?
Philip Koopman's Stack page at CMU
http://users.ece.cmu.edu/~koopman/stack.html
