Let's talk about QIC-24 (Quarter-Inch Cartridge) recording format tape
drives. I have an Archive Viper 2150S drive and a few Tandberg QIC 1000 /
TDC4120's. I have a collection of tapes that have had their elastic
repaired to my satisfaction. I can see the tapes advance using the rewind
command etc. Some of the tapes read fine and I can pull their data.
My question is - a few of the tapes are not readable, I am using standard
linux tape commands fed to the SCSI drive. I am wondering if Sun tapes are
formatted differently and must be read in Sun tape drives. Could there be
different types of physical BOT holes, or are they all the same? Is there
something that makes a tape un-readable unless it's in a
Sun/Windows/Linux/VMS environment? I am just trying to get the data, not
use the data. At least not yet.
My bench system is Linux Debian 7.
I realize the tapes I have that I can't read may just be bad. Or maybe
they're simply not formatted. I just don't want to give up until I am sure
I have tried everything and know as much as possible.
Any ideas?
thanks
Bill
Paul Terrell, Liza Loop, Daniel Kottke and Ronald Wayne as they recreate
history by presenting Liza with a replica Apple 1 and then discuss the
early days at Apple. Bring all your burning Apple questions as you may have
an opportunity to ask them of the panel. Rumor is that Woz will be there!
Jeff Brace
VCF Evangelist
VCF West Sat Aug 1 at 4:3PM At the Computer History Museum in Mountain
View, CA.
Ronald Wayne discusses his time at Atari and Apple, how he authored the
original Apple partnership agreement, designed Apple's first logo and
worked on the Apple-1. Q&A session followed an autograph signing.
Jeff Brace
VCF Evangelist
Doesn’t time fly by? The Z80 processor could be bought in July 1976. It
along with Intel’s 8080 were the backbone of classic computing 50 years ago.
Happy computing,
Murray 😊
There have been a few versions of the utility imd2raw.c floating around
that will take Dave Dunfield's ImageDisk-created images (i.e. an .IMD file)
and make a linear binary image devoid of any metadata. This is similar to
the function of Dave's IMDU.COM program's /b switch.
I've corrected a problem with the assumption that all imd2raw.c descendants
to date have made: sectors that have a skew (i.e. not 1-1 interleaved)
weren't linearized correctly. The skewed sectors need to be written out in
"sorted" order, which is not necessarily captured/physical order. This is
easily verified by comparing output from "IMDU /b" to earlier imd2raw
outputs on any .IMD that has a sector skew that isn't 1, 2, 3 [...].
It's up on github here:
https://github.com/RetroFloppy/imd2raw
I found a Magellan Roadmate 2000 in a box in my basement.
It doesn't light up when I connect it to a USB charger (not the port on
my computer). Maybe it has a dead (not simply discharged) battery.
Maybe it's a brick.
If you want it, send a PDF for a small Postal Service Flat Rate box.
Van Snyder
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
> ***************************************
