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.
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)
I was unable to connect with this web site today, just curious if it's down
permanently or temporarily. When I visit the site without the SSL (
http://old-computers.com) I am taken to an "Site en construction" page.
Bill
I wanted to share some results I got when attempting to read 800 bli NRZI
9-track tapes:
I have not been able to read any of the 800 NRZi Tapes. I tried a number
of things using four computers. My analysis is detailed below.
The 800 bpi-related calibration on the M4 drive on hand may be off. Just
a guess.
Sources
https://web.geo.uib.no/eworkshop/uploads/Main/123477_23_9914_User_Diagnosti…
Followed suggestions from web search and AI prompts where applicable
There is a set of programs embedded on an eProm on the M4 drive. Program
41 sets the data encoding circuits to handle 800 bpi. I activated
this program before attempting a read. When I put in a 800 NRZI tape into
the drive it analyzes the tape and reports the tape type to be 800 bpi, but
I thought maybe running program 41 to explicitly force 800 bpi mode would
be useful/necessary just in case.
As a general rule, I always reset the drive using these commands before
trying another read:
mt -f /dev/nst0 status - OK (reports 800 NRZ ONLINE)
mt -f /dev/nst0 rewind - OK (rewinds tape)
2. I started with an Ubuntu 18 system. I was successfully able to attach
the drive, etc.
Next I broke down the testing - the simple stuff:
mt -f /dev/nst0 status - OK (reports 800 NRZ ONLINE)
mt -f /dev/nst0 rewind - OK (rewinds tape)
mt -f /dev/nst0 offline - OK (takes the drive offline)
mt -f /dev/nst0 setblk 0 - OK (sets to variable block mode)
mt -f /dev/nst0 fsf 1 - NOT OK (never finds a start of file, runs through
entire tape.)
But when I try to actually read a tape I get errors
Here are examples of the tape read commands, there are many variations one
can try:
dd if=/dev/nst0 of=block1.bin
dd if=dev/nst0 of /dev/null bs=1024
etc
I would open a 2nd window and run the following command to view the system
messages while the dd program is running
dmesg | tail -50
result example:
[ 1802.404408] st0: Failed to read 1326 byte block with 1024 byte transfer.
[ 1813.881884] st0: Failed to read 3846 byte block with 1024 byte transfer
The drive can see data on tape and start reading it but the host computer
is applying the wrong transfer size assumptions. I think.
I don't think setblk 0 is being implemented (use variable block size), but I
don't think this is a fixed-block vs variable block issue. I think that
Linux' st driver is issuing fixed-size read internally and failing when the
drive returns a different record size than expected. There is no
indication that I have bad media or can't read tape or nrz failure at
least. No errors like that.
It appeared to me that the Ubuntu 18 linux version of the st driver cannot
properly stream variable-block 800 bpi tapes, but it's not a SCSI issue.
3. I then built an older style Pentium III with Debian linux (version 7)
with an Adaptec 2950 SCSI controller. The hope was that I'd be closer to a
system that has native ability to read 800 bpi tapes. I used an older
version of linux etc. all to try to avoid emulation issues.
I ran the same tests as above plus other tests, nothing worked.
raw streaming:
mt -f /dev/nst0 setblk 0
dd if=/dev/nst0 of=tape_dump.bin bs=256k conv=noerror,sync
mt -f /dev/nst0 of=dump.bin bs-32k conv=noerror, sync
if tapes are structured then the following would work, but it does not:
mt -f /dev/nst0 fsf 1
dd if=/dev/nst0 of=record1.bin
(and repeat per record )
Result - The fsf command runs and rolls the entire tape, never finds a file
marker to indicate beginning of file. This indicates variable-block,
filemark-less (or nonstandard filemark) 9-track dump tapes, like you find
in IBM systems.
To just avoid buffer failures and bad records and keep going to the end of
the tape I tried this:
dd if=/dev/nst0 of=tape_dump.bin bs=64k conv=noerror,sync iflag=fullblock
Result - it tried endlessly but never advanced the tape.
I also tried cat, which is probably not as good as mt, but worth a shot:
cat /dev/nst0 > dump.bin
also tried
dd if=/dev/nst0 of=tape_dump.bin bs=256k conv=noerror,sync status=progress
repeats endlessly showing the output to the screen...
*Conclusions*
The drive is not successfully completing a forward-read operation. I
observed no forward motion, repeated zero-length reads.
*So I think the situation is ...*
SCSI is OK - I can issue commands that do not involve reading. The tape
transport (the physical movement of tape) is ok, NRZ 800 bpi selection
seems to work, and the mechanism appears to be able to at least detect that
there are blocks of data that can be read.
What does not work is when we attempt to perform sequential streaming
through variable block tapes like the NRZ's I have. The tapes appear
to be non-filemarked,
variable-block 9-track tape where forward streaming is error-sensitive. It
could be that the M4 9914’s NRZ (800 BPI) read path is marginal or out of
calibration. I believe the M4 mechanics for 800 dpi tapes are separate
from the 1600 dpi.
4. DEC 3000 and DEC 4000 servers with native centronics SCSI ports
Unfortunately neither even detected the M4 drive so I was not able to test
further. I asked AI and it suggested that the DEC firmware sometimes had
trouble with older SCSI-1 devices like the M4. Interesting that the PCs
with SCSI card were better able to detect the drive, but they were.
Note that I played around with termination of the SCSI ports to see if
there was a difference, none detected. I opened the M4 rear panel to see
if I could change the SCSI ID number to try a different number to avoid
possible conflicts but there was nothing available. The drive number
appears to be set by the eProm, but I did not want to open up the entire
drive.
The Adaptec controller reports the M4 to be:
Vendor: M4 DATA
Product: OPEN REEL TAPE
Revision: 138P
---------------------------
I am not sure bypassing SCSI and using the Pertec interface would work, I
don't have a computer that uses Pertec for data like that, or I'd have to
figure it out from scratch.
Bill
Hi all,
Around 1981, Intel made a 8086 companion chip named _operating system
processor_ (i80130, and i80150, resp.) which comprised a ROM and some
interrupt logic. The 80130 contained sort of a BIOS for iRMX86, the
80150 supported CP/M-86. Few info can be found at
https://en.wikipedia.org/wiki/Intel_80130, and a datasheet exists at
alldatasheet.com.
Some lore is also found in some history pages, but not much more than
the datasheet contains.
Was the ROM content of both chips dumped and is available on the
Internet somewhere, or does someone have such a system (supposedly some
iAPX86/30) and is willing to make this public, e.g. upload to bitsavers?
THX to any pointers
Kind Regards
Holger
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
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
