- cctalk - classiccmp.org

Project Release Announcement - Vintage UNIX (and others) Online Manuals

by r.stricklin

I've been working on this project for ages. It is not complete. It may never be complete. It is, however, finally in a state that I consider to be eminently usable. A "beta" or "soft opening" - there are absolutely some visibly unfinished areas. But, it can absolutely be used while I continue improving the typesetter and the indexer, polishing the presentation, and adding manuals for new systems. http://www.typewritten.org/Manual/ Some folks were given access to previous development versions and asked not to share the URLs. If you were one of them, please transition to this URL instead; this one can be considered fully public. ok bear. ps. this announcement was also sent to the VCFED forum and the TUHS mailing list

35 minutes

5
8
0 0

Re: ...a .TAP by any other name...

by Vasile Buruiana

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 > *************************************** >

4 hours, 38 minutes

2
2
0 0

MC6800 MUDBUG

by Roland van straten

Dear all, I came across MUDBUG a monitor for the MC6800. It is much more “sophisticated” then MIKBUG and friends… I did find a report at a .gov website that shows the manual and schematics. Could not find anything on the website of Arizona State University which did a great part of the development. The question is if there is a) a S19 file, but rather the asm source code? It would be nice historically to add this to the legacy of mikbug, minibug, etc. Regards, Roland MUDBUG MUDBUG was a monitor and debugger program created for the Motorola 6800 by developers at Arizona State University in the mid-1970s. Designed as a resident system tool for low-level program control, MUDBUG provided early microcomputer users with interactive facilities to inspect, modify, and debug memory and registers. It exemplified the era’s shift toward software-based development environments for new microprocessors. Key facts Platform: Motorola 6800 Type: Machine-language monitor/debugger Developed at: Arizona State University Period: Circa mid-1970s Purpose: Memory and register examination, program testing, and I/O control Background and development MUDBUG emerged shortly after Motorola’s introduction of the 6800 microprocessor in 1974, a period when educational and research groups built tools to support the device’s use in embedded and teaching contexts. Arizona State University’s version extended the capabilities of Motorola’s own MIKBUG monitor, offering improved memory handling and command flexibility for laboratory instruction and small-scale system development.

9 hours, 6 minutes

2
1
0 0

...a .TAP by any other name...

by Jacob Ritorto

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

1 day, 9 hours

2
2
0 0

ID'ing a core module: Any Univac 1108/6 processors still existent?

by Brent Hilpert

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>

5 days, 10 hours

4
7
0 0

TECHNOLOGY SWAP MEET & Fundraiser - Wall, NJ - May 30, 8AM to 2PM

by Jeffrey Brace

TECHNOLOGY SWAP MEET & Fundraiser = May 30, 2026, 8AM to 2PM, Wall, NJ - 6th St and Monmouth Boulevard https://vcfed.org/vcf-swap-meet/ Vendor Setup at 7AM Vendor Registration: https://docs.google.com/forms/d/e/1FAIpQLSdZcnVFT2lfJJuYwwJSwclxfyvZFBd1kp1…

6 days, 8 hours

1
0
0 0

Emulex UD33 + Fujitsu M2284K sectoring

by Jacob Ritorto

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!

1 week

2
2
0 0

Rainbow 100 and Univation Hard Disk

by Robert Armstrong

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!

1 week, 2 days

2
4
0 0

xterminal

by cp

hi I have a tektronix xp217, with Tekxpress v7. Are you interested? let me know

1 week, 2 days

3
2
0 0

Did anyone here work on Burroughs A Series/Large Systems MCP back in the day?

by Alan Perry

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

1 week, 4 days

1
0
0 0

2026

2025

2024

2023

2022

cctalk