January 2024 - cctalk - classiccmp.org

by Paul Anderson

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

3 months, 1 week

8
15
0 0

The MAC at 40

by Murray McCullough

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 🙂

3 months, 1 week

12
22
0 0

Looking for 1970s OAK keyboard switches...

by John Robertson

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"

3 months, 2 weeks

2
3
0 0

IBM 38 on Facebook Marketplace

by Anders Nelson

I know nothing of what they're referring to, but just in case someone is interested: https://www.facebook.com/marketplace/item/1033559851065048 -- Anders Nelson www.andersknelson.com

3 months, 2 weeks

3
2
0 0

WTB: Keyboard for IBM 3290-1 terminal.

by Andrew Back

Hello, I'm looking for a keyboard to use with an IBM 3290-1 terminal (DB25 connector). IBM part number 6016730 or similar. Regards, Andrew

3 months, 2 weeks

2
1
0 0

Re: Can anyone (pref in USA) recover data from an old RK05 disk pack?

by Graham Toal

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

3 months, 2 weeks

2
1
0 0

Can anyone (pref in USA) recover data from an old RK05 disk pack?

by Graham Toal

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.pdf https://gtoal.com/history.dcs.ed.ac.uk/archive/scans/guts/orange.pdf https://gtoal.com/history.dcs.ed.ac.uk/archive/scans/guts/yellow.pdf

3 months, 2 weeks

1
0
0 0

FASTBACK Help how to recover files stored in this backup format,?

by ED SHARPE

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

3 months, 2 weeks

2
1
0 0

Re: Forth on the HP 3000: Alternate History

by Paul Koning

> 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

3 months, 2 weeks

2
1
0 0

Forth on the HP 3000: Alternate History

by Rodney Brown

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

3 months, 3 weeks

4
6
0 0

2024

2023

2022

cctalk January 2024