This has mushroomed and I'm so glad to have the opportunity to reveal
the entire mess here:
The Alpha XP900's PCI cage is no different than any 90's cage.
It uses PnP, it accepts and assigns cards intelligently and properly.
it has no discrete tool, like a 90's PC, but it is the same.
If you get it confused with a stupid cage-stuff:
Take all the cards out. Stuff the cage with RTL nics or VIA
usb cards, neutral, friendly, the bus will love them. If it makes you
feel better, boot bsd and run them on the bus. There's no way the cage
remembers anything after that. This problem never happens, but there's
your fix.
To propery orient the machine, prefetch_mode should be off for the
first probe by the booted OS, even if it crashes your machine. Then
turn it back on and boot again. This clinches the PCI cage and the EV6
bus through Pchip etc....
The problem open-source developers had was they could not be certain of
the hardware config. I can be.
They were bouncine their code off of unknown hardware and, having
nothing to hang their hat on, eventually quit, blaming the hardware.
Each time they ran a squirrely, unfenced driver, they skewed the bus
for everything. It was untestable. I think I destroyed a (very cheap)
Si3114ctu controller chip with netbsd's satalink driver. I got
80meg@sec (lucky boot) and beat the hell out of it, then it up and
died.... I think all the extra traffic and work involved literally
worked the chip to death. Add this to the mix as a possibility and it
re-enforces in the mind of userland the machine is junk.
So the ultimate answer is that the Open-Source Community, userland
specifically, screwed the pooch for every weak-memory-model
architecture they ever ported to, by ignoring page one of the Alpha
architectural white-paper.
NetBSD, OpenBSD, FreeBSD, and Linux kernels always booted because they
were written for the Alpha and obeyed the need for memory barriers to
enforce in-order messages to the card-cage. All userland But Drivers
use kernel for thier work and are thus protected by (netbsd's)
Bus_space(), or other similar mechanism.
The Tsunami does't give a hoot what order things come to it, but PCI is
linear and it sure does.
Since the kernels were all compiled with memory barriers, why doesn't X
run on any of them? Why does the onboard ata controllers on the Alpha
machines universally throw orphan (stray) irq's and downgrade to PIO
mode 4 after initial negotiation at UDMA2?
Userspace is not compiled with memory barriers at all. Xorg just pukes
out of order garbage at the pci cage and stuns the video card, crashes
the entire bus as often as not.
This is All the BSD's and All the Linux.
It is vital that these folks do something, for Risc V has a weak memory
model.
The Alpha is by far not alone:
The PowerPC FX970 also suffers from this, but the iMac G5 is a very
tightly integrate machine with no expandability and so survives the
bus-storms, but they are there in userspace, sure as God made little
green apples.
I don't think it helps performance at all on PARisc....
All of these would benefit from increased stability and better disk and
network IO! if userspace were properly curated.
The Alpha was just the First victim of a blind-spot so enormous it is
hard for me to credit, but every time I look at a release, I see the
same sin, over and over and over. No Bus_space(), no Alpha_mb()
ANYWHERE but the kernel(s).
Some new discoveries in-the-bud:
I feel very strongly that prefetch_mode in the srm does Not require
INIT to toggle. I think it is toggleable from there as often as you
like, in fact I think it is toggleable at a speed measured in at least
the kilohertz....
I think this is the toggle, with another one or two, maybe, which NT
and OpenVMS and Tru64 are able to achieve such good performance on a
bus which requires in-order data and is hanging in a bag off of the
Tsunami bus....
I think that these three operating systems have discrete rules they
enforce using these toggles. We don't know where they are, but
prefetch is one we do and perhaps can probe for in memory....?
Even if this dynamic mechanism is unreal ( I think it is real ), or
even if we can't exploit it (very likely, especially in short-term), it
doesn't really matter. We've always accepted Some penalty for open-
source and with the proper build it will run very very well with no
need to resort to the above speculated optimizations.
So, in short, the Alpha is clean. The hardware is good. Modern
hardware worke Better than period because it knows PnP better, but it
all works unless you are just a mad bomber.
All the BSD's and linux's work. NetBSD 9.2 works best by far on this
machine. I had X running for a week on a lucky boot with a clean cage
and a following wind. Heavy compiling all week (over a very quiet and
well-behaved Intel 1000 pro lan card).
I'm not a coder so the software side is up-hill, but I'll get there.
My first goal is to try and patch the wd0 driver for memory barriers.
I expect it will instantly negotiate to PIO4 UDMA2 and stay there
without any 'stray interrupt 14, stray interrupt 15' garbage in
console. That will validate this entire sad episode and I'll do it
first if someone doesn't beat me to it.
Please dig out your Alphas. There was nothing wrong with them to begin
with.
On my Facebook post I inluded some photos of a pirate copy of High-
Performance Computer Architecture, by Harold Stone. It is a clean-room
copy, a re-set, and there is only one in the world. I would love to
show this to Mr. Stone and tell him how it came to be. Here's a link
to a couple of pages of it:
https://www.facebook.com/groups/retrocomputers/posts/28340501522219693
Thanks for listening, thanks for being here all these years.
I didn't realize until this other day, but the list started about the
time I joined it, around 1998/2000. Then we were just a bunch of
geeks, but today classicmp is an institution, venerable and respected.
BZ!
.
BZ!On Tue, 2026-07-07 at 12:00 -0500, cctalk-request(a)classiccmp.org
wrote:
> Send cctalk mailing list submissions to
> cctalk(a)classiccmp.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> cctalk-request(a)classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner(a)classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
> Today's Topics:
>
> 1. Re: DEC Alpha EV6 (Tsunami) PCI pbus cohere. (David Brownlee)
>
>
> ---------------------------------------------------------------------
> -
>
> Message: 1
> Date: Mon, 6 Jul 2026 19:30:59 +0100
> From: David Brownlee <abs(a)absd.org>
> Subject: [cctalk] Re: DEC Alpha EV6 (Tsunami) PCI pbus cohere.
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk(a)classiccmp.org>
> Cc: "Jeffrey S. Worley" <technoid6502(a)gmail.com>
> Message-ID:
> <
> CAGN_6pbu=vbeDrQ5M6Urf+mkK642EDZaamugv08Mf_yk81f7Xg(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 26 Jun 2026 at 03:24, Jeffrey S. Worley via cctalk
> <cctalk(a)classiccmp.org> wrote:
> >
> > Today I decided to test the bus-cohere protocol with cards other
> > than
> > framebuffer and IT WORKS.
> >
> > SRM won't let me boot from it of course, but I:
> >
> > [... happy happy Alphe EV6 NetBSD 9.2 boot process complete with
> > x11 ...]
>
> Very cool news :)
>
> Presumably this could be incorporated directly into the alpha kernel
> initialisation - if on a model that requires it the kernel could
> pause
> before probing the PCI bus?
>
> David
>
> End of cctalk Digest, Vol 1224, Issue 1
> ***************************************On Tue, 2026-07-07 at 12:00 -
0500, cctalk-request(a)classiccmp.org wrote:
> Send cctalk mailing list submissions to
> cctalk(a)classiccmp.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> cctalk-request(a)classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner(a)classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
> Today's Topics:
>
> 1. Re: DEC Alpha EV6 (Tsunami) PCI pbus cohere. (David Brownlee)
>
>
> ---------------------------------------------------------------------
> -
>
> Message: 1
> Date: Mon, 6 Jul 2026 19:30:59 +0100
> From: David Brownlee <abs(a)absd.org>
> Subject: [cctalk] Re: DEC Alpha EV6 (Tsunami) PCI pbus cohere.
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk(a)classiccmp.org>
> Cc: "Jeffrey S. Worley" <technoid6502(a)gmail.com>
> Message-ID:
> <
> CAGN_6pbu=vbeDrQ5M6Urf+mkK642EDZaamugv08Mf_yk81f7Xg(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 26 Jun 2026 at 03:24, Jeffrey S. Worley via cctalk
> <cctalk(a)classiccmp.org> wrote:
> >
> > Today I decided to test the bus-cohere protocol with cards other
> > than
> > framebuffer and IT WORKS.
> >
> > SRM won't let me boot from it of course, but I:
> >
> > [... happy happy Alphe EV6 NetBSD 9.2 boot process complete with
> > x11 ...]
>
> Very cool news :)
>
> Presumably this could be incorporated directly into the alpha kernel
> initialisation - if on a model that requires it the kernel could
> pause
> before probing the PCI bus?
>
> David
>
> End of cctalk Digest, Vol 1224, Issue 1
> ***************************************
On Wed, 8 Jul 2026, Kevin McQuiggin wrote:
> Nice to see some photos. I have only ever read about RAMAC and the only photos I have seen are IBM marketing photos from the late 50s/early 60s.
The one that Dennis Boone posted is not bad:
https://gallery.porterstreetcafe.com/vcfmw/2007/slide_71.html
In 1958?, Nikita Khrushchev visited USA to try to calm the cold war a
little.
He wasn't allowed to go to Disneyland!
He was a little upset. "Is there an outbreak of cholera? Have gangsters
taken it over, who might harm me?" etc.
He was given an incredible dinner in Hollywood. Mrs. Khrushchev expressed
disapointment about not going. Sinatra said to Niven, "Tell the old broad
that you and I will take her there, personally"
To make up for it, they took him to the IBM facility in San Jose, and
showed him Ramac construction. He was more impressed with the
efficiency of the self service cafeteria.
I think that the Cuban missile crisis would have been a lot less tense if
they were to have let him go to Disneyland!
New Yorker ran a cartoon that showed a submarine surfacing off shore, and
a fat man sneaking to Disneyland.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
All,
A number of years ago, I ended up with a pile of MXV22M QBus controllers, which present a RXV21 compatible interface to the QBus, but talk to 5.25" diskettes. Thanks to a generous loan of a regular MXV22 from John Ball, I was able to convert the MXV22M to a regular MXV22:
http://users.glitchwrks.com/~glitch/2026/07/12/mti-mxv22m-conversion
The above writeup includes links to the fuse PROM images.
I'd like to build a mezzanine to replace the 7x fuse PROMs with modern EEPROM or Flash, but haven't had time to get on it, other than verifying that the original fuse PROMs aren't so fast as to make that impossible.
If you have blank fuse PROMs but no way to program, contact me off-list and I can blow a set on the Data I/O 29B.
I will be going through the MXV22Ms I have and converting them, as time permits, and then making them available for sale. If you want an untested MXV22M to convert yourself (cheaper if I don't have to!) then contact me off-list and let me know.
Thanks,
Jonathan
We can stand in awe as classic computerists at the advancement of
technology: I recently read that chip technology size is at 2 nanometers
for ultra-large scale processors. In 1971 it was 10,000 nanometers or 10
microns. This is a 5000x reduction in size in 55 years. One has to ask: Is
Moore’s Law still alive?
Happy computing?
Murray :-)
I run www.punchcardarchive.com. It runs on a shared server so I don’t worry too much about that stuff. My fun and games are defeating the bots and useless messages from my Contact page. I have a homegrown captcha. I require Roman characters. I added a honeypot field. I require a minimum number of words in the message. I recently got a message that had a whole page of text with a very weird message. So I am putting in a max number of words test. And I am adding a timer to the page so if the send-receive time is less that some number of seconds I will consider it spam.
The internet is the Wild Wild West. Minus Jim West and Artemus Gordon.
Greetings!
I recently stumbled across a early hard drive platter that appears,
based on measurements, to be an original RAMAC platter. Very little
comes up in Google beyond basic measures (diameter of 24" and a head
motion of 6".) I'm curious if there was anything out there that had
similar measurements. I did find a photo on facebook but it clearly
has different measurements.
Platter is in poor condition (no oxide, nicks and dings, etc although
still obviously a platter) but the owner is fascinated with possible origin.
Steve
I have two little cabinets of four drawers each with seven slots per
drawer, full of carbon resistors, probably 2,500 in all.
Anybody want them?
They're yours if you send a PDF for a shipping label. I'll measure and
weigh for a box if you're interested.
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)
