Hello and thank you for the hints.
Short version:
Would you please tell me some more details about where to find " *Johnny's
tpw under 2.11BSD* " utility, which *"it achieved writing simh TAP to a
real TK50"* ? It will be of great help.
Long version:
I'm working at a PERTEC-interfaced tape emulator using some Am2900
bit-slice processors and a STM32. Currently I somehow replicated the simh
.TAP but it does not fully follow and respect its format. My emulator reads
tapes, dumps content inside 4 x 32MB EDO RAM for the data, and 1 x 4 MB EDO
RAM for the 'map of the tape' - file sizes, filemark separators and so on.
When EOT is reached, the tape is rewinded while the big RAM content is
dumped [AM2900 side] into a microSD card [STM32 side] while following the
tape map from the smaller RAM, in such a way that the resulting file
becomes a frankensteined simh tap file. It can also do the reverse - reads
that frankenstein TAP [STM32] and writes it to the tape.
The STM32 acts like an i/o interface to the microSD and also as a user
interface. All the rest (i/o protocol, interrupts, ram transfers) is done
with physical gates and some diode logic ROM, for me to keep the stm32
software part as simple as possible. Whatever I could implement with
external hardware, I did.
The big weirdness is as following: whatever format is dumped from the
physical tape inside my "not-quite-simh TAP" file, it appears to be
converted and written correctly back on another physical 9-track tape, as
it can be correctly read by another frankensteined half-breed dinosaur made
from some communist Romanian clones of PDP11 (called Coral 4030) - the
boards - and French CII IRIS50 (called Felix C-256) - the i/o peripherals:
tape drives, punched card, cassette tapes and so on.
However my "not-quite-simh" TAP is not accepted by simh and also not
accepted by the 'unvtape' program from you, mr. Jacob Ritorto, from your
github.
But if the STM32 sends data to its own RAM chip (the board containing
the stm32 is *waveshare's core429i*), then extracts it back, the simh file
format result is as perfect as it is supposed to be. But I can't use that
RAM with the rest of the system, as there are not enough spare i/o ports
left in order to talk to the AM2900 side.
The EDO Rams are tested and they work absolutely fine. I made some mistakes
for sure while building the physical board (bad/expired beer?), some little
mess with the gates which I can't fully follow - unable to replicate the
initial conditions, I no longer have that bad beer which gave me headaches
during the design phase. Now I have only the good stuff.
So I am asking for help in order to run that "*tpw" *program and follow
the registers, while graphing the physical measurements logic using two
HP1662 logic analyzers: would you please let me know where I may find it?
This is an older version of my pertec tape drive emulator. The project
advances slowly - not too much spare time available, not even to update
with new pictures and progress. My wife, child and workplace demand 99% of
my attention. Unfortunately I have limited knowledge about working with
github, mostly because it is owned by Microsoft (and used for inspiring
their business, that's why I refused to learn about it), and also because I
am used to the old times when programs were stored & exchanged on cassettes
and floppies, and version control was manually followed with pen and paper.
At this time it is easier and faster for me this way.
https://hackaday.com/2019/05/02/a-mainframe-tape-drive-emulator/
Thank you.
Vasile
On Tue, May 26, 2026 at 8:00 PM <cctalk-request(a)classiccmp.org> wrote:
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 May 2026 12:08:09 -0400
> From: Jacob Ritorto <jacob.ritorto(a)gmail.com>
> Subject: [cctalk] Re: ...a .TAP by any other name...
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk(a)classiccmp.org>
> Message-ID:
> <
> CAHYQbfAspc+gs6mRZv5ePmt__kp_xb-WvFUBO9K-HiCsX8iNyA(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Thank you for that ,Ken - good to have in the pocket!
> I tried Johnny's tpw under 2.11BSD and it achieved writing simh TAP to a
> real TK50. So I'm booting real hardware from that sept 1992 rsts/e image
> now!
>
>
> End of cctalk Digest, Vol 1186, Issue 1
> ***************************************
>
So there's RSX .TAP format that works with VCP.
Then there's this simh .TAP that doesn't.
Is there a conversion program to make one into the other?
Or a way to write simh .TAP to physical tape from RSX?
Asking because I want to write a physical TK50 from my real 11/70 running
RSX-11M-PLUS using this handy rsts/e dist .TAP I found on the Internet and
install me an rsts but VCP doesn't like the format!
$ dir *.tap
Directory DU0:[RITORTO]
23-MAY-26 15:16
RSTS101.TAP;1 47249. 23-MAY-26 14:53
Total of 47249./47250. blocks in 1. file
$ vcp connect rsts101.tap
VCP - *Diag* - Error opening file DU0:[RITORTO]RSTS101.TAP;1,
Status = Bad record type
Other ideas on how to proceed with a minimum (or even a modicum) of
friction?
thx
jake
I was asked to examine a large core module, it has a UNIVAC label and part no, manufactured in 1971 but probably a little older in design. No providence known.
I suspect it is from an 1108 or perhaps an 1106, based on the reasoning presented in the web link below. I’m a little curious for a firmer confirmation though. 1108/6 documentation on bitsavers has been very useful, but what’s there doesn’t go deep enough into the hardware to provide a hard confirmation. Is there even an 1108 or 6 still in existence?
The module, and what I’ve figured out:
http://madrona.ca/e/coreUnivac/index.html <http://madrona.ca/e/coreUnivac/index.html>
Hi all,
I have this UD33 controller that works perfectly with another newer SMD
disk (CDC 9720), but when I try it against my beautiful old Fuji 160
(M2284K), It gets through format okay but has intermittent errors on verify
/ reliability test. If I reduce the number of cylinders / heads, I can get
it to pass, but not every time.
I have a good thick ground and same cables that worked perfectly with the
other disk, hoping that's enough of a sanity check on those.
I have the UD33 configured thusly:
type: 1
units: 1
sectors per track: 32
physical heads: 10
physical cylinders: 823
spare sectors per track: 1
spare cylinders: 2
configuration bits: 6
LOWER RPS: 3
UPPER RPS: 7
split into one drive with 1 head and the other with 9 heads to speed things
along :)
GAP 0: 259
GAP 1: 4112
GAP 2: 780
Spiral offset: 1
The drive's switches are set for soft sectoring and tag 4/5 enabled.
I had tried hard sector setting on the drive with 32 sectors / 640 bytes.
It's SO CLOSE to working I can taste it :).
I have another Fuji 160 that is doing basically the identical same
misbehaviour.
And as usual, I am just not quite understanding the final clincher piece.
Anyone know of better settings I should be using and most importantly Why?
thx
jake
P.S. I was hoping that somewhere someone would have written down what
controller settings work with the UD33 or QD32, etc, but no luck finding
them. You'd think despite the 3 or so years gap in the disk vs controller
that this would've been officially supported at some moment in the
universe, no? I just wish I knew how to calculate it properly myself!
I have a Rainbow 100A with the Univation hard disk. Works (wow!), but the
Univation HDD controller was not DEC compatible and you have to boot from a
floppy to get the disk drivers loaded. And of course, the 100A ROMs didn't
support any kind of hard disk, DEC or otherwise.
Did anybody ever make an updated ROM image for the 100A that supported
booting from the Univation directly? I think the 100A used 2716 EPROMs,
and it'd be easy enough to burn some new ones.
And is there any surviving documentation for the Univation? Bitsavers
seems to have nothing.
Thanks!
Hi all,
I worked on system software at Burroughs in the late 80s and a couple weeks ago gave a talk about Burroughs history in computers and the Large Systems/A Series/B5000 and B6500 architecture at VCF PNW. There was enough interest that I am putting together another talk or two. One of the topics is Large Systems MCP and I am looking for other people who worked with it to give their own perspective and confirm things I am trying to remember from 40 years ago.
BTW, if you haven’t seen it, the trove of Burroughs documents in the bitsavers Burroughs collection on the Internet Archives is amazing. Unfortunately I still can’t find any documentation for most of the stuff that I worked on. I should have kept copies of those manuals when I left.
alan
Apologies for spamming this with a very specific hardware issue - but I
felt this was so unusual, that it was worth sharing the kind-of solution.
I have an old 386 running Solaris, works fine.
I swapped the VGA monitor it, didn't think much of it. VGA is VGA right?
(except old Compaq 286SLT have one of the VGA pins removed, but that's
another story)
The replacement monitor (19" Sun from c. 2001) worked fine. Booted system,
logged in. But - I Couldn't ping. No networking.
Checked the router. Check switch, all green lights. TV streaming still
working. No one else in the house screaming about no internet. Hmm... But
I couldn't ping out of that 386, nor FTP back into it, like I had been.
I consulted GPT on its thoughts. I swapped NIC cables, VGA cables, long
cables, short cables, moved the power brick of the 19" Dell. All same
result. Finally, GPT made this comment, that I'll summarize like this:
"If your NIC isn't working, try turning off your monitor."
I figured another dumb AI hallucination. But holy smokes, that actually
worked! It was a pure 1:1 correlation - whenever I turned that 19" Sun
monitor off, I could ping out of the box and ftp into it. As soon as I
powered it back on, all the network traffic stopped. It no fancy LCD - no
speakers, no USB, just a typical VGA/DVI connector heavy LCD with a Sun
Micro logo stamped on it.
So the specific test was this: prep a ping command, like "ping
192.168.1.1" turn the monitor off, press ENTER. Wait 2 seconds, power the
monitor back on. And yea, consistently, that worked. But when trying to
ping while the monitor was left on, I couldn't ping from the NIC in this
386.
GPT's only suggestion was some sort of grounding interference by this
particular 19" Sun monitor, and some blah-blah about how old 386's are more
impacted about EMI.
Just curious what other think on this - any particular known issue about
2001-ish period Sun 19 flat-panel LCDs? This one uses a 19V DC power brick
(and I tried using different outlets).
I never would have considered trying to solve the NIC issue by powering off
the monitor. So I have to put back on the widescreen for now - which
everything works fine with that. So not a real solution, but I gotta
admit that GPT did help uncover what was causing the issue.
Cheers,
Steve
