- cctalk - classiccmp.org

Kickstarter for new Commodore 64 documentary

by Jeffrey Brace

Excited to hear about this fundraiser for a new documentary: Commodore 64: The Birth of a Cultural Icon https://www.kickstarter.com/projects/graciousfilms/the-commodore-64-the-bir…

1 month, 2 weeks

1
0
0 0

Alpha EV6 bus coherence

by Jeffrey S. Worley

I've been reinventing the wheel quite a bit lately and a couple of new things as well, so I'm glad I was not well-versed in the issues surrounding this machine in the BSD sphere and elsewhere. Some new ideas to help those with this machine: cycle a known-good elsa or permedia with rom disabled through each slot of an empty card-cage. On each swap, unplug the machine from the wall and leave the power switch on for a minute or two, then issue an init at srm. When you run out of slots: This should pattern the entire bus with a calm elsa stamp. There are three digital levels to this coherence problem (at least), and there's the analog one no one seems to have considered as a member of the whole picture. I searched for this above and it was no where. I don't think anyone thought of it. The system trains. I saw it do this recently with the si3114udc card. As the card drifts, the system drifts with it, in sympathy. This drift can become ingrained in the system beyond the digital realm. I think it is totally worthwhile to consider making a card for this purpose using a cheap cpld or mcu. There are already pci projects out there, it could be a snap. I'll look into it, but what it could DO is repeatedly and visciously assert aligned and properly timed data in the same way the 3114 and other misbehaved cards assert mis-skewed data and timing. This, in theory would re-train the entire io subsystem to compliance with the cards whole and healthy stride, normalizing the machine for expansion and deployment. I could really use some feedback. This list has the best there is. Weaponizing init and prefetch and a crash, exploiting the system is good, because it can work, but it isn't the whole fix, just a peek at the mechanisms which can unlock the problem entirely. So today I added an analog or dumb aspect to what has been seen as a monolithic problem. It really is a DUAL problem insofar as BSD is concerned, but for Alpha architecture it is a four-layered problem, as I see it. I lack the targam at this depth, so please forgive my terms: PCI cage physical state (why is this such a stepchild in the process? And red-headed!) PCHIP executing saved bitsieve which was generated by init probe before prefetch is re-asserted (one-boot process). PCI to EV6 bridge, logic and code the training is here, I believe, and incredibly active and intrusive. The SRM is a computer inside the computer. EV6 bus and its side of the divide. The way I see it is shooting through three sets of overlapping chain- link fences. If you are sqare to them and a good shot, you will put your shot through the same hole of the 'grid' and it will land in the appropriate target zone. If you are at an angle, you will land your shot, but it will be dislocated from your planned landing spot. The system is really tolerant to this!, it trains itself..... If I keep hitting the fences, the fences move to accommodate my shot, as though the strikes were physically enough to do that. I think the dec hardware guys wanted to puke when they were told to hang pci off ev6 AND as the only available bus. They hated it with their whole souls. So, the implemented the most rigorous and perfect implementation of the 'standard' they could. It was so good and so rigorous the software guys had to eat the puke they'd made the hardware guys egest. We are dealing with the aftermath of that battle, is my take. I'm just looking at the machine. So if it can fail for bad training, why not try GOOD training? Some of you may remember me. I've been here since 1997 or so? I have no formal education at all. I have 40 years of computing experience and have gotten this far in the project through logic and theory and the output of the framebuffer in various failure modes. One, for example would just look corrupted to a LOT of people, but it looks like a loader for a demo on an 80's 8-bit decompressing its payload. That is informative. I realized that the framebuffer had overflown into main memory and I was seeing the contents of that in this familiar way. That is science, even if it is using in-situ diagnostic tools. Using this as a primary window into the system I've built the theory as expressed here. A smarter person would use expensive tools I don't have, and those have been applied already I'm sure. I'ts been awhile is all. I've been lurking. Please holler! Best, Technoid Mutant Jeffrey S. Worley

1 month, 3 weeks

1
0
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

1 month, 3 weeks

4
5
0 0

Re: Looking for a paper in COMPCON '8

by Paul McJones

As a matter of fact, I had already sent Scott an email, but did not get a reply. > Date: Fri, 26 Jun 2026 08:57:24 -0400 > From: Ken Seefried <seefriek(a)gmail.com <mailto:seefriek@gmail.com>> > Subject: [cctalk] Re: Looking for a paper in COMPCON '83 > > You might reach out to the authors. I'm pretty sure S.B. Baden is Scott > Baden @ UCSD. > > https://cseweb.ucsd.edu/~baden/ > > KJ

1 month, 3 weeks

1
0
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

1 month, 3 weeks

3
2
0 0

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

1 month, 3 weeks

1
0
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

1 month, 3 weeks

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.

1 month, 3 weeks

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 🙂

1 month, 3 weeks

42
156
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 month, 3 weeks

3
2
0 0

2026

2025

2024

2023

2022

cctalk