- cctalk - classiccmp.org

Harold S. Stone, Please contact Jeffrey Worley

by Jeffrey S. Worley

This is irregular, and I beg your indulgence, as it at least in light of the recent Alpha EV6 discovery. I have a story to tell you Mr. Stone, that you will be very glad, amazed and fulfilled to hear and to know. This is not the forum for such things, but I am a very little person and could not hope to reach you in any other way. Thank you gentlemen for your forbearance. I ask further of you even, if you know Harold S. Stone, the author of High-Performance Computer Architecture, please ask him to message me on facebook or call me. I'm not hard to find, I'm @Technoid_Mutant on Youtube... Again, my thanks. Jeff

3 hours, 12 minutes

1
0
0 0

DEC Alpha EV6 (Tsunami) PCI pbus cohere.

by Jeffrey S. Worley

NetBSD 9.2 and a lot more will now work on Alpha EV6 using a newly discovered PCI bus cohere protocol involving a couple of SRM commands and reboots to accomplish whenever the contents of the card cage has been physically modified. Here's what I've found: The Tsunami's bus is reconciled with the PCI bus via a bitsieve, a matrix stored in undocumented non-volatile memory somewhere on the board, Pchip most likely. Triggering a bus-scan with PFREFETCH_MODE enabled just spams the PCI bus with speculative reads and never gives the cards a voice. Nothing good is generated and that nothing good is stored in pchip. This is familiar behavior for the past 30-ish years. After PREFETCH has been disabled, an attempted boot of the target operating system, NetBSD 9.2 fails in the expected way, with a Black Screen of Death at the moment WSCONS is robbed of the framebuffer for Xwindows. This is the only netBSD problem and it can be resolve with a simple workaround which separates those two events by some time, however brief ( a second would do, a tenth ). The kernel parament 'n', passed via the boot -if n dqa0 command in the SRM puts Netbsd in a mode convenient to us, as the framebuffer is initialized as-such (see how nice the text is!) and has had time to settle. When we take the defaults and 'exit', the process completes to an XDM login and a desktop. I believe DEC intended this to allow NT boots under odd circumstances and did not delete the feature, leaving us a backdoor to boot our operating systems with the machines full cooperation. I believe (without testing the method with other than the video card very thoroughly) that other cards may be positively affected by this new-found ability to cohere the bus: Sata/Pata cards (Please God!), and other commodity cards which otherwise would not work. Why do SCSI cards always work no matter what? The reason is that these premium cards already know themselves quite well and operate at a higher-level on the bus. They are immune from the storm coming through the broken bitsieve, basically establishing a fixed mode without negotiating? The Promise ATA133, for example, ought to work, but it is shouted-down by the mess through the wrong sieve and craps out to pio mode 4. I think, and I will test, that cohering the machine after installing this card may give me a fast and reliable (Cheap) local storage. Why doesn't the onboard ata controller ever really work? It is not really on the PCI bus, but is rather sort of in-between the Tsunami and PCI on an ISA bridge and so cannot benefit by a probe. I believe the drivers for NT, VMS, and TRU use specific driver tweaks to accomplish stable performance at UDMA speeds on this commodity chip. The alterations to fix the boot process are trivial, it isn't and never really has been a NetBSD problem, nor OpenBSD. Go ahead and cohere your Alpha's bus by: Install NetBSD 9.2 with the full installation, enable XDM if you want. It won't run X. We knew that, but the process allows the bus to be probed without prefetch confusing everthing. Enter SRM. Alphabox>>> set pci_parity off Alphabox>>> set prefetch_mode off Alphabox>>> init let the boot proceed to the familiar Black Screen of Death. Reset the machine and re-enter the SRM Alphabox>>> set prefetch_mode on Alphabox>>> init The machine is permanently configured with the new bitsieve generated by the probe we just conducted. You will not need to modify these again unless you makes some hardware change in the card-cage. If you have an Ev6 in the closet, now's the time to drag it out and reclaim its glory. This fix allows prefetch to work the way it was designed to, with tremendous performance benefits, and with the proper sieve in place, strange things will no longer occur. I have not tested as yet, but I believe that with this cohere in place on your macine, and using a similar mechanism to allow the video card time to settle, OpenBSD 5.9 and/or 6.0 should run, even though no one ever saw X on them before, you can today. Why did the oldest versions of NetBSD, OpenBSD, and Linux work in Xwindows just fine? I am guessing, but given that DEC had no possible interest in helping anyone do this (Evidence all of HISTORY), these three teams had no real choice but to slavishly emulate the boot process in every way they could, not knowing which emulated eccentricity was the actual key. It worked, but no one outside of DEC could know why. When the Openbsd/Netbsd/freebsd teams got new members, changed tools, rebuilt anew, at some point they forgot why the code was so strange and obviously inefficient. It should have been a clue, but they instead 'streamlined and optimized'-away the CAREFUL TIMING and they wiped away another thing that I think was probably once done by Tru, NT, VMS, OBSD, FBSD, and NBSD, all. I think they blindly passed something to Pchip, a key bitsieve or a special command to probe without prefetch and then go back as we are doing manually via SRM. Whatever the mechanism was, it was not seen as such and removed, breaking X then. Regression would show what worked, but it would never tell you why without a terrific forensic effort involving long and unfettered access to the actual, known-good vintage iron. Best Regards, Technoid Mutant (Also Known as The Technoid and as Technoid6502)

3 hours, 17 minutes

1
3
0 0

Looking for a paper in COMPCON '83

by Paul McJones

I’m trying to get a copy of this paper: S. B. Baden and D. R. Patel. “Berkeley FP — Experiences with a Functional Programming Language. Conference Record of COMPCON ’83, San Francisco, California, pp. 274–277, March 1983. and wonder if anyone on this list has a copy of the proceedings? The source code is available in the tuhs.org archives and the manual is available in the supplementary documentation for BSD 4.2, but I am interested in what the author wrote about their experiences. (I’m working on a history of John Backus’s functional programming project; Berkeley FP is based on Backus’s work.) Paul McJones

6 hours, 19 minutes

2
1
0 0

Speaking of Algol: RSRE Flex (info+connections sought)

by Tom Stepleton

Greetings, Over the past several months I've been privileged to experience RSRE Flex, an operating environment for PERQ workstations (and a few other bespoke machines before that). Flex is interesting for being a networked capability-based system with a hypertext-ish user interface, and everything is implemented in Algol 68. Closures (in the programming language sense; called "procedures" in Flex) are a fundamental abstraction similar in importance to how files are fundamental to Unix*.* Flex was developed in the late '70s and the '80s by the Royal Signals and Radar Establishment, a research lab of the UK Ministry of Defence. Its influence on computing has been limited as far as I can tell: the same researchers went on to develop the Ten15 abstract machine which begat the TenDRA compiler, and that might be most of the story. Nevertheless, the system remains fascinating (I think) if you get the chance to learn about it. I've collected some Flex materials here: https://mg-1.uk/flex/flex.html In a few weeks I'll be giving a talk and demonstration of Flex to a technically well-informed but otherwise unfamiliar audience. I can certainly fill the time with rich technical details and descriptions of things like Algol 68 and the PERQ, but I'd like also to have more to say about the circumstances that brought Flex about and the ways people encountered it at the time. I'm also hoping to gather information that might lead to a public release of Flex someday (another thing I've been working on behind the scenes). So this message is a general request for information and connections: - Did you or did someone you know work in computing at RSRE in the '70s and '80s? - Flex was shared with people outside of RSRE in the '80s, mainly universities and colleges from what I can tell. Did you encounter Flex running on a PERQ in one of these settings? - Did you ever use Flex under any circumstances? What for? Also: - Flex contains numerical routines in both Algol 68 and PERQ microcode that bear copyright assertions by Numerical Algorithms Group Ltd (now nAG, nag.com). Does anyone know someone at nAG who would be a sympathetic person to approach about the disposition of this very old IP? Many thanks, --T

7 hours, 14 minutes

2
2
0 0

Compuwriter IV Going for Cheap

by Cory Heisterkamp

Too far north for me, but hopefully it doesn't get scrapped out. No relation. -C https://bid.schmalzauctions.com/Vintage-The-CompuWritter-IV_i60266313

12 hours, 35 minutes

2
1
0 0

System/38 update

by Joe George

We've been working on restoring and powering up a fairly rare bird of IBM Midrange machine, the IBM System/38. We had some good success this past weekend that I'd like to share. https://crusty.computer/?p=89 June Work Recap: Edith – The Crusty Computer Club crusty.computer tl;dr: she powered up and no smoke came out and no sparks came out! There are several repairs needed but they are known and fixable.

13 hours, 51 minutes

4
4
0 0

Intel 3086

by Murray McCullough

Intel's x86 technology as in the 8086 came into existence for the microcomputer-user at this time back in June 1978. It was a response to Motorola's and Zilog's move to 16-bit processing. Still in use today...the basic tech so to speak. Can it be unseated by RISC(Apple and such) and Nvidia? Happy computing. Murray 🙂

19 hours, 51 minutes

42
156
0 0

Re: What constitutes a dead computer language

by Mark Green

Yes, I did early development on both. At least the interface to the OS was Pascal. I still have the early documentation buried in a box somewhere. Sent from my iPhone > On Jun 20, 2026, at 2:02 PM, Fred Cisin via cctalk <cctalk(a)classiccmp.org> wrote: > > On Sat, 20 Jun 2026, ben via cctalk wrote: >> PL/1 and C are the only two high level languages a operating system is written in, that I can think of that are well documented, and easily found on the WEB. > > I heard that all of the Lisa OS, and much of Macintosh, were written in Pascal. (obviously other than some low-level drivers and performance critical routines?) > Is that correct? > > http://pascal.hansotten.com/apple-lisa-pascal/ > > When did Macintosh development switch to C? > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com

1 day, 6 hours

17
25
0 0

Burroughs DCALGOL vs tapes [from dead computer language thread]

by paul.kimpel＠digm.com

Yes, DCALGOL is still around and actively used. It is a superset of the standard Extended ALGOL, and originally exposed some special APIs and data types for talking to the Datacom Processor front-end. Those APIs are still used, although the "front end" is now TCP/IP. The language has since been extended with numerous other APIs for use primarily by system-programmer types. There is also a DMALGOL compiler primarily used internally with the DBMS, DMSII. All three ALGOL variants have been compiled from the same source code since sometime in the '70s. DCALGOL would have been no different than ALGOL for dealing with tapes, and I'm surprised you found it harder to do with the MCP than with OS/360 EXCP I/O. Depending on the block and tape label formats, you may have had to do your own deblocking, and possibly read the tape as unlabeled, but the MCP I/O Logical I/O subsystem was quite rich even in 1975. You had to understand how the file attribute settings worked when dealing with non-native tape formats, however -- I've seen that trip a lot of people up. As an alternative, a variant of Logical I/O called Direct I/O was available, which is user-mode asynchronous I/O that reads and writes raw blocks. It's basically a thin wrapper around the MCP's internal Physical I/O mechanism. I know this is water long over the dam, but I'd be interested in hearing what kinds of issues you encountered, and if possible, a reference to the DEC formats you were trying to read.

1 day, 15 hours

3
2
0 0

Re: What constitutes a dead computer language

by Mark Kahrs

As a fan of BCPL (from the Alto), I only wish it was better documented. For example, Tripos has next to no documentation on it including how to compile and load it. Documentation on the runtimes is also lacking (and that's where the rubber meets the road). Unfortunately, the Alto changes were not picked up so it remains an isolated branch (and *dead* by the definitions put forward).

2 days, 4 hours

7
8
0 0

2026

2025

2024

2023

2022

cctalk