[cctalk] Re: Microsoft & Apple

[Chris Hanson via cctalk]

On Sep 9, 2024, at 6:08 AM, Liam Proven via cctalk  
wrote:

> It was not an investment. That was a lie spread by the marketing
> lizards. Please don't repeat it or spread it. It is not true and never
> was.

This is also not true—Microsoft received some amount of restricted (non-voting) 
stock in Apple at the same time, so it was an investment *as well* as being a 
settlement of all pending litigation.

The investment paid off substantially for Microsoft as well.

  — Chris

[cctalk] Re: Heurikon HK68/M10 (Multibus) information?

[Chris Hanson via cctalk]

Will do! Do yours have ROMs, and can you dump them? Even with non-Hbug ROMs 
they cna be thrown in Ghidra and MAME and at least some of the memory map 
worked out.

  -- Chris

> On Jun 18, 2024, at 5:54 AM, Ken Seefried  wrote:
> 
> I have one or two as well.  I asked around about this a couple of years ago 
> and didn't turn anything interesting up.  A couple of former Heurikon folks 
> said they'd look but nothing came of it.  Ping me if you turn anything up.
> 
> KJ
> 
> On Thu, Jun 6, 2024 at 10:04 PM Chris Hanson via cctalk 
> mailto:cctalk@classiccmp.org>> wrote:
>> Does anyone have any manuals or other information on the Heurikon HK68/M10? 
>> Or the Hbug ROMs for it?
>> 
>> The HK68/M10 is a Multibus 68010 board with serial, SCSI, parallel, timers, 
>> 1MB onboard RAM, 2- or 4-channel DMA, and an optional 68451 MMU. It's 
>> similar but not identical to the HK68/V10 (the VMEbus version) and so far I 
>> haven't been able to find much that would make one usable.
>> 
>> I'm particularly interested in:
>> 
>> An Hbug ROM.
>> Pinouts for the top edge connectors, which provide the serial ports, the 
>> SCSI port, and the parallel port.
>> Jumpering/strapping and other configuration information.
>> 
>> And of course it'd be incredible to find the UniPlus+ distribution for it, 
>> but I'm not holding out much hope for that.
>> 
>> I already know what's on Bitsavers—such as the brochure—and I've already 
>> looked at the MAME HK68/V10 emulation, so no need to point those out.
>> 
>>   -- Chris
>> 

[cctalk] Heurikon HK68/M10 (Multibus) information?

[Chris Hanson via cctalk]

Does anyone have any manuals or other information on the Heurikon HK68/M10? Or 
the Hbug ROMs for it?

The HK68/M10 is a Multibus 68010 board with serial, SCSI, parallel, timers, 1MB 
onboard RAM, 2- or 4-channel DMA, and an optional 68451 MMU. It's similar but 
not identical to the HK68/V10 (the VMEbus version) and so far I haven't been 
able to find much that would make one usable.

I'm particularly interested in:

An Hbug ROM.
Pinouts for the top edge connectors, which provide the serial ports, the SCSI 
port, and the parallel port.
Jumpering/strapping and other configuration information.

And of course it'd be incredible to find the UniPlus+ distribution for it, but 
I'm not holding out much hope for that.

I already know what's on Bitsavers—such as the brochure—and I've already looked 
at the MAME HK68/V10 emulation, so no need to point those out.

  -- Chris

[cctalk] Re: Looking for an HP 9000/778 workstation B160/180

[Chris Hanson via cctalk]

On Apr 4, 2024, at 7:17 PM, Kevin Bowling  wrote:
> 
> There is an ebay seller 'biff-howard-tanen' that has some C200s up
> right now.  All their items have "Make an Offer'' and they tend to be
> fairly reasonable as long as you account for the free shipping they
> offer.  I've had mostly good luck with buying from them, and they made
> right the couple oops.

I can vouch for them as a seller in the same way, I've also gotten reasonable 
prices from them when making offers that account for shipping, and the seller 
actually knows how to pack stuff. Same with eBay seller jonnyadler, though 
their list price for a C180 is,  let's say, "optimistic.")

  -- Chris

[cctalk] Re: Looking for an HP 9000/778 workstation B160/180

[Chris Hanson via cctalk]

I just looked at the prices on eBay—yikes! All of my HP hardware from that era 
was pretty inexpensive a few years back.

What are people using the B180L for that’s driven the prices so high? I assume 
it’s another “there’s a piece of equipment that was built around this specific 
platform 20+ years ago, and we’re still running it so we need spares” 
situation, just like the equipment that was built around the VAXstation 4000 
Model 90 which keeps the price on that insane.

Is there a specific need you’re trying to fill? I wound up with an additional 
B- or C-series workstation as part of a deal, I can check what model it is 
(it’s in storage right now) and we can talk off-list about maybe getting it to 
a good home. (I’m in the SF Bay Area if that helps, no idea where you are.)

  -- Chris

PS - There’s a Vintage HP Computers group at https://groups.io/g/VintHPcom/ 
where you’ll also find lots of folks talking about the entire range of HP 
computer hardware.

[cctalk] Re: Vmebus

[Chris Hanson via cctalk]

On Feb 2, 2024, at 2:06 AM, David Brownlee via cctalk  
wrote:
> 
> On Wed, 31 Jan 2024 at 18:34, Wouter de Waal via cctalk
>  wrote:
>> If someone here has the warm fuzzies for PPC VME, we can talk :-)
> 
> Other than a reflexive twitch to see if NetBSD can run on the MPC7448? :-p

It’s NetBSD, of course it can run!

The real question is: Does it currently run? If the answer is “No,” it’s just a 
port away as long as sufficient information about the CPU and platform is 
available.

The modularity in NetBSD that enables this is its greatest strength. It enables 
things like the newly brought up “virt68k” platform which is basically NetBSD 
for a QEMU-hosted 68K emulator with VirtIO, which can be useful for things like 
kernel testing and pkgsrc builds.

  — Chris

[cctalk] Re: Vmebus

[Chris Hanson via cctalk]

On Jan 29, 2024, at 8:07 PM, Bill Degnan via cctalk  
wrote:
> 
> Anyone have a VMEbus system they use at least occasionally? If so, what
> make/model/config?

I have a variety of VME hardware that I use some of the time, and on the 
ClassicCmp Discord we even have a #vme channel.

I've mostly been using a Motorola MVME167 (with some additional VMEbus memory 
cards) netbooted to NetBSD off and on, though I also have 147 and 177 cards 
(68030 and 68060) that I'll use. I also have a couple of MVME197 88000-based 
cards that I've used to port OpenBSD-mvme88k forward by one point release from 
when they dropped support. (I wish NetBSD had mvme88k…) And I have a couple 
other 68K VMEbus cards like a Xycom XVME-600 and XVME-630; the 600 is cute and 
runs Mach2 FORTH from ROM, while the 630 is a more or less generic 68EC030.

I have a variety of peripheral cards that I've been trying to do various things 
with, including a slick RasterGraf RG-750 graphics & human interface card (it's 
34010-based and has AT keyboard and serial mouse ports), a couple NI GPIB 
cards, and a bunch of earlier cards like Motorola HD/floppy, Ethernet, SCSI, 
and intelligent serial cards, and so on.

I also have a few older Motorola 68010 and 68020 boards; I want to bring up 
MINIX 1.5.10.7 at some point on my MVME050+MVME121 and see if I can't get it to 
leverage the MMU. And I have a VME/10 workstation that needs to be put back 
together that I'd like to run Motorola SVR2 on.

Finally, I have a bit of more exotic gear. I have a couple of the INMOS 
Transputer VME cards (as well as the non-VME equivalents for my ITEMs) and I 
have a few Mercury Computer Systems i860 cards for which I really, really, 
*really* want to find documentation someday. It'd be a lot fun to have a bunch 
of i860s rendering a scene or something that I can then output via the RG-750, 
controlled by an 88K...

Oh yeah, and I have a few Suns and a Symbolics that use 9U VME, as well as a 
couple ISI systems that use 6U VME[1]. 

  -- Chris

[1] ISI used their own QBus-style ejectors on the card top instead of the 
standard Motorola style plates, so they're *not quite* the same form factor. 
Darned annoying.

[cctalk] Re: Vmebus

[Chris Hanson via cctalk]

On Jan 30, 2024, at 3:25 PM, Bill Degnan via cctalk  
wrote:
> 
> thanks.  I suppose that gives me enough idea what time period and use they
> had

VMEbus was widely used as a successor to MultiBus in the workstation market, a 
lot of vendors that started with MultiBus (Sun/SGI for example) switched to VME 
because they were using 68K anyway and it a supported full 32-bit address and 
data space, where MultiBus was mostly designed for 8080/8085/8086 (and even 
8086 required some extension to support 16-bit data bus width and 20-bit 
address space).

The biggest uses of VMEbus though were in laboratory automation, process 
control, and robotics, where it was in competition with both MultiBus and 
DIO[1] (the bus on the HP 9000-200 and 9000-300 series, which were originally 
designed as successors to the HP 1000/21MX/2100 series). That's why you'll see 
a lot of analog and digital I/O hardware, computer vision systems, motor 
controllers, and so on in the VMEbus 3U and 6U form factors. This is also what 
got VMEbus used in a lot of American defense applications.

  -- Chris

[cctalk] Re: The Mac at 40

[Chris Hanson via cctalk]

Apple didn't "steal" anything because Xerox received a tranche of pre-IPO Apple 
shares in exchange for allowing SJ and his folks to visit PARC for a bunch of 
demos and do whatever they wanted with what they saw.

Nowadays you can also try out systems like Smalltalk-78, Xerox ViewPoint, etc. 
as well as the original Lisa and Macintosh systems in emulation -- and read 
papers like "Inventing the Lisa Human Interface," published in ACM Interactions 
27 years ago -- to see just how different what SJ and his people saw at Xerox 
was from what Apple shipped in the Lisa and Macintosh 4-5 years after the visit.

- The top-of-screen menu bar was an Apple invention.
- Atkinson's "region" data structure to allow windows to update when partially 
obscured was an Apple invention.
- Open/Save file dialogs were an Apple invention for Macintosh, because with 
128KB of RAM it couldn't run both Finder and an application and thus couldn't 
use Lisa's "stationery pad" concept.

I can't believe people still don't have a solid grasp of these things after 40 
years of both journalism and academia covering them in rather exhaustive detail.

  -- Chris

[cctalk] Re: Computhink Eagle 32 - software, docs, info?

[Chris Hanson via cctalk]

I picked up this system from its previous caretaker yesterday, to hold onto for 
a friend. I’ve also inventoried the major functional ICs and archived the 
“IPL-M” ROMs.

Here’s what’s in the Eagle-32:

- Main Logic Board
  - 8MHz 68000 CPU
  - 2x D8255 programmable peripheral interface
- left 8255 is clearly for parallel and user port
- right 8255 I strongly suspect is for hard disk, possibly ANSI or SASI
  - D8253C programmable interval timer
  - 2x 2651N programmable communications interface for serial ports
  - 2x 2716 for IPL-M 0/1 ROMs
- Disk Controller Board
  - FD1701B-02 floppy disk controller
- No video board, whether text or graphics

Since there’s no video board in the system, and a couple of cables internally 
that aren’t attached to anything, I expect it was removed by a previous 
caretaker. This is sad because without one it’s unlikely to come up, not that 
anyone has found any software for it. On the other hand, there are zero PALs, 
so both full reverse engineering and maintenance should be straightforward.

I threw the 4KB of boot ROM in Ghidra and confirmed a couple things:

- At boot, ROM is mapped to 0, and then remapped either by a write to the 
location or by a cycle counter: The initial stack pointer at 0x0 is 0x0001fffe 
and the initial program counter at 0x4 is 0x00ffc026, indicating the ROM is 
normally located at 0x00ffc000.
- The ROM freely interchanges addresses in the 0x00ffc000..0x00ff range and 
addresses in the 0xc000..0x range, which is annoying to deal with 
in Ghidra.
- I/O devices appear to be in the 0x00ff8000..0x00ffbfff range, all of the 
devices accessed via the bootstrap seem to be barely above 0x00ff8000.
- Only NMI, bus error, interrupt 2, and interrupt 5 are set up by the bootstrap.
- The bootstrap is very bare-bones but still has a bunch of indirection in it; 
it’s obviously written in assembly, but it does seem to have parameterization 
so it may support both console and serial I/O.

I suspect that I can figure out from the pattern of I/O accesses which devices 
are at which address in the memory map, at least if I bring up an emulation in 
MAME. That should at least allow writing new code for it, and _maybe_ even 
figuring out which CRT controller the video hardware uses and where in the 
memory map it is. (I suspect the 6845 and/or 6847 just from the time period, 
but who knows? Gotta see what it actually do when trying to show the “IPL IN 
PROGRESS” string contained in the ROM, or one of the couple error strings…)

  — Chris

[cctalk] Re: TI 960

[Chris Hanson via cctalk]

On Sep 4, 2023, at 1:01 PM, Bill Gunshannon via cctalk  
wrote:
> 
> Weren't the TI 900 series the things called Transputers?

No. Completely unrelated.

  — Chris

[cctalk] Re: Little Databases

[Chris Hanson via cctalk]

On Aug 19, 2023, at 7:33 PM, Sellam Abraham via cctalk  
wrote:
> 
> On Fri, Aug 18, 2023, 8:31 PM Gavin Scott via cctalk 
> wrote:
> 
>> It [SQLite] has billions of installations and on the order of a trillion
>> databases in use.
>> 
> 
> Surely you hyperbole.

This is not hyperbole, there are multiple billions of devices that have 
deployed SQLite—over a billion Apple devices alone.

  — Chris

[cctalk] Re: CPT Phoenix Jr system unit? Monitor and Keyboard

[Chris Hanson via cctalk]

On Jun 7, 2023, at 5:09 PM, Chris Hanson via cctalk  
wrote:
> 
> Sorry I missed this, you only sent it to the list and I haven't looked at the 
> list for a while. I've actually just acquired a CPT Phoenix Jr. computer to 
> go with my display and keyboard, so I now have a full system that I'm 
> planning to restore and use.

I've set up a group at https://groups.io/g/cptphoenixjr for discussion and 
preservation of the CPT Phoenix JR.

I've just posted a little bit about how I'm going about trying to get the ROM 
booting in emulation as a way to figure out how the hardware is attached. Of 
course, if you or anyone else has knowledge here, that'd make everything a lot 
easier than working backwards from the ROM code and peripheral data sheets. :)

  -- Chris

[cctalk] Re: CPT Phoenix Jr system unit? Monitor and Keyboard

[Chris Hanson via cctalk]

Sorry I missed this, you only sent it to the list and I haven't looked at the 
list for a while. I've actually just acquired a CPT Phoenix Jr. computer to go 
with my display and keyboard, so I now have a full system that I'm planning to 
restore and use.

In what way has your display failed? If it's dim a CRT rejuvenator might do the 
trick. And if it's just stopped working, it may just need a recap. I'd only 
give up on it if the tube is necked or the yoke damaged and a new tube couldn't 
be sourced...

That said, do you have any boot, utility, or other disks archived that the rest 
of us could use with a system?

  -- Chris

[cctalk] Re: The World Wide Web

[Chris Hanson via cctalk]

On May 4, 2023, at 10:51 AM, Patrick Finnegan via cctalk 
 wrote:
> 
> It seems like all of the good USENET providers are subscription
> services now. I'm not sure of any ISP that I've heard of who still
> runs one.

What about eternal-september.org?

  -- Chris

[cctalk] Re: NCD-17c and NCD-19 X terminal cap lists?

[Chris Hanson via cctalk]

On Apr 4, 2023, at 6:29 PM, Richard via cctalk  wrote:
> 
> In article <07a97414-a207-42f5-8c6b-64f4556e3...@eschatologist.net>,
>    "Chris Hanson via cctalk"  writes:
> 
>> Does anyone have a list of replacement capacitors to use for NCD X
>> terminals, specifically the 17c and 19? A couple searches online don't turn
>> up anything.
> 
> While I don't have a specific replacement list for those terms, this
> is exactly the sort of thing for which "caps wiki" was created:
> <https://caps.wiki/wiki/Main_Page>
> 
> At the least you should contribute what you learn to that wiki if you
> have to figure it out yourself.

Amen, will do! And thanks for the link, once I put together the lists I’ll also 
try to get links to them from the terminals wiki.

We’re all probably going to have to do a lot of recapping in the next few 
years, may as well save each other time…

  — Chris

[cctalk] NCD-17c and NCD-19 X terminal cap lists?

[Chris Hanson via cctalk]

Does anyone have a list of replacement capacitors to use for NCD X terminals, 
specifically the 17c and 19? A couple searches online don't turn up anything.

I just got my NCD 17c up and running—I showed a pic or two on 
discord://classiccmp/#terminals a couple days ago—and now while I hear the HV 
power up the low voltage power seems kaput and the system never comes on. And 
my NCD 19 won't power up either.

I can certainly take them apart and make lists, and I will if need be, but I 
was hoping maybe someone had already done so so I could get an order in ASAP. 
The power supply for these things is in the display portion, which makes me a 
bit nervous just generally… :)

  -- Chris

[cctalk] Re: Knockoffs, was: Low cost logic analyzer

[Chris Hanson via cctalk]

On Mar 14, 2023, at 2:55 PM, Jim Brain via cctalk  wrote:
> 
> On 3/14/2023 4:16 PM, Jonathan Chapman wrote:
>> There are other things that we've chosen not to run for the same basic 
>> reason, and others that won't get open sourced. 
> 
> I will admit I am trending in that direction.  I put things as FLOSS because 
> I wanted the designs to outlast my involvement with the community.  I thought 
> if the design was open source and I wanted to or had to depart (including the 
> Great Departure), the designs would continue to be available rather than 
> disappear. But, so many people have abused that idea.  Luckily, most of my 
> stuff is not useful enough to copy and sell online...

If you posted your design as Open Source, someone else producing it isn't a 
knockoff, it's the system working as intended.

  -- Chris

[cctalk] Re: PT-68K

[Chris Hanson via cctalk]

On Dec 27, 2022, at 7:47 PM, Will Cooke via cctalk  
wrote:
> 
>> On 12/27/2022 9:36 PM CST Chris via cctalk  wrote:
>> 
>> Those are for a different board. Maybe close enough?
> 
> If you read the description it says the only difference is the clock chip, 
> which I believe is "fully" compatible.

That’s the difference between the PT68K1 and PT68K1A. The system featured in 
Peter Stark’s “Build the PT-68K” series in Radio-Electronics was actually the 
PT68K2, which is the version with PC-XT slots, keyboard support, and PCB 
size/layout. There don’t seem to be ROM images on the web site for that.

They do exist on Bitsavers, look for Peripheral Technology.

  — Chris

[cctalk] Re: Data General Nova and Eclipse Hobbyist License...

[Chris Hanson via cctalk]

On Nov 17, 2022, at 10:12 PM, Bruce Ray via cctalk  
wrote:

> It is not a sublicense, Wild Hare Computer Systems, Inc., now has copyright 
> and title to the legacy DG/EMC software.

That's awesome news, congratulations!

  -- Chris

[cctalk] Re: LC:M+L (Living Computer Museum)

[Chris Hanson via cctalk]

On Oct 31, 2022, at 11:45 PM, Tom Hunter via cctalk  
wrote:
> 
> Thank you Rich for shedding light on this. Most of it makes sense to me,
> but the secrecy part where you weren't allowed to talk to those still at
> the museum is weird. I can't see any possible commercial reason for
> preventing former engineering staff to talk with their former colleagues or
> replacements. If anything you would think that any new staff would be
> encouraged to talk to the engineers who left to benefit from their
> experience. As I said this appears to be rather strange.

I think you have it backwards: The way I read Rich's message, former LCM+L 
staff can talk to each other -- they can't really prevent that! -- but anyone 
still on at LCM+L can't talk to them about LCM+L (or presumably the public).

That's fairly standard for a company; if I were to leave my employer, my former 
colleagues wouldn't be able to talk to me about current internal goings-on 
there because I'm a civilian. (We could certainly talk about anything else.) 
It's a bit weird for an educational/cultural institution though.

  -- Chris

[cctalk] Re: LC:M+L (Living Computer Museum)

[Chris Hanson via cctalk]

On Oct 31, 2022, at 4:31 PM, Rich Alderson via cctalk  
wrote:
> 
> Tour guides and front desk personnel were immediately let go, because it was
> clear that it would be several months, up to a year, before we could open
> again.


Microsoft, Google, Apple, Facebook etc. were willing to pay all of the 
ancillary on-site staff (like the people work at their coffee bars) their 
regular wages through the pandemic even when nobody was allowed in the offices.

LCM+L, being owned by a billionaire's foundation, could have chosen to do that 
too.

>  Professional museum staff (curator, educational coordinator, etc.) were
> retained for a short while, to wind things down.

They and the entire engineering staff should have been kept on until the museum 
could reopen, doing whatever work they could remotely, and should still be 
working there now.

That they weren't shows how little the foundation cares for the things Paul 
Allen cared about.

While I prefer the way LCM+L made working systems available to the public over 
the CHM's mostly-static "behind a velvet rope" approach, CHM has turned out to 
be the better institution since they at least kept people on.

> All of the engineers, which the exception of the manager of the department,
> were laid off as of 1 July 2020.  None of us was allowed to return to the
> museum at any future time, and no one associated with the mothballed museum 
> was
> allowed to talk to any of us.

Disgusting. Good luck to LCM+L hiring anyone with real skills for passion rates 
if they ever actually do try to reopen.

  -- Chris

[cctalk] Re: 50 Years of the HP 3000

[Chris Hanson via cctalk]

On Nov 1, 2022, at 11:55 AM, Mark Moulding via cctalk  
wrote:
> 
> I'd like to see $2000, but will cheerfully entertain offers (cheerfully if 
> they're reasonable, or met with hysterical laughter if not).

You may need to adjust your expectations on that front. Even with 
pandemic-related inflation, that’s quite high for something not a lot of people 
will know they should be interested in.

  — Chris
  — who has a 917LX and A400, and wishes he could find a 37 or Micro

Sent from my iPad

[cctalk] Bubbl-Tec bubble memory (QBus)

[Chris Hanson via cctalk]

I just acquired the several Bubbl-Tec bubble memory boards for QBus, and was 
wondering if anyone had manuals or more information than the couple of web 
pages I've found with high-level descriptions:

MBC-11A bubble memory controller
MBB-11A bubble memory board for use with MBC-11A
QBI-11C bubble memory board
QSB-11A bubble memory board with RX01/02 emulation

It looks like I can just drop the QSB-11A into a system and it should work as 
if it's an RX01 attached to a controller, but the other boards appear to need 
cabling and possibly jumpers to configure them for use, and maybe custom 
drivers/code too.

  -- Chris

[cctalk] Re: DECnet to be dropped from Linux

[Chris Hanson via cctalk]

It just sounds to me like the implementation should move to userspace. Why does 
it need to be in the kernel?

  -- Chris

Later Data General (D214/AViiON) keyboards?

[Chris Hanson via cctalk]

No, I'm not looking for old Dasher keyboards because "omg Severance."

I have a couple of Data General terminals (D214) and a couple of Data General 
UNIX workstations (AViiON, using m88k CPU) and only one keyboard. The one that 
uses an 8-pin DIN connector similar to the 5-pin IBM PC XT keyboard 
connector—and it speaks the same protocol over the same lines, but also has a 
couple extra features enabled by those extra 3 pins. (I believe the part number 
of the DG keyboard is 6348, but I'm not positive and can't find my reference at 
the moment.)

Does anyone have any more of the keyboards for D214 terminals or AViiON 
workstations that need a good home, a home which reunites them with appropriate 
hardware? I gather I can use XT-compatible keyboards with the AViiON systems at 
least, because of the compatibility I noted above, but I don't know about my 
terminals.

  -- Chris
  -- also always looking for anything else AViiON-related, 
hardware/software/docs
  -- and for docs for the D214 terminal too, of course

Re: Sun-2 and Sun-3 mice (eBay)

[Chris Hanson via cctalk]

On Oct 26, 2021, at 6:49 PM, Rico Pajarola via cctalk  
wrote:
> 
> I bought some of his stuff, but I picked it up. No complaints, it cleaned
> up nicely. Try "make an offer"...

As have I, got a Sun-2 monitor too! He should list his whole stock, not just 
one item at a time. (I gather he's got a few Sun-3/50, keyboards, mice, mouse 
pads, and a few HP 9000-340 too. Don't know if he has any more monitors than 
the Sun-2 monitor I bought though.)

  -- Chris

Re: FTGH

[Chris Hanson via cctalk]

On Oct 11, 2021, at 11:52 AM, John Forecast via cctalk  
wrote:
> Due to family medical issues I have to downsize and move into a retirement 
> facility at the end of this month.

Oh no! I hope everything will be OK, and that you're not being forced to 
downsize *too* much as part of this.

> 
> DEC VT180 with 4 floppy drives
> 
>   Includes HSC Inc’s CO16 8086 coprocessor with 256KB memory
>   Full hardware documentation for the CO16
> 
>   Documentation:
>   Bios User’s Guide
>   CP/M Operating System Manual
>   Multiplan Manuals
>   Microsoft M80/L80 Manua
>   MBasic VT180 v5.21 Reference manual
>   
>   No software available. If/When I find the software I will make it 
> available to whoever
>   takes this system.

If this is still available, I would pay for someone to pick this up, pack it, 
and ship it to California. (I'd also send John money for it too, IMO it's only 
fair if I'm paying someone to retrieve, pack, and ship it.)

> Minix Software
> 
>   Minix 1.5 for Macintosh (including disks)
>   Minix for the Atari ST
>   Minix Binaries and Sources for IBM PC/AT (5¼” floppies)

If this is still available, I would **desperately** like to acquire all of the 
above. Again, I'm willing to pay someone (and send money to John!) to pick this 
up, pack it, and send it to me in California.

I have MacMinix 1.5, but a couple of my disks are bad, and I'd really like to 
have the other Minix bits too. Literally simultaneously with John's sending of 
this email, I was running the Mac IIfx in my office at Apple, and rebuilding 
all of MacMinix 1.5.10.7 at -O2... Seriously! (Part of a personal project to 
port Minix 1.5.10.7 to a 68010 VME board set.)

My first Open Source contribution was to MacMinix. I created a patch that 
flushed the instruction and data cache on the 68040 when necessary (probably 
too often, in fact) so it would run nice and fast on the Centris 610 that I 
upgraded to from a Mac IIci in late 1993.

In any case, if I don't get these myself, I hope they went to good homes, and 
I'd absolutely love it if whoever got them could make and share disk images of 
the MacMinix disks since right now the only publicly-surviving artifact is the 
StuffIt archive of an installed system.

  -- Chris

Seeking DEC BC19S (VS2000 color video/keyboard/mouse) cable

[Chris Hanson via cctalk]

I now have a 4-plane color graphics card for my VAXstation 2000, and I'd like 
to actually connect it to a display.

Does anyone have a DEC BC19S cable that needs a good home? For reference, this 
has a DA15F connector on one end that plugs into the VAXstation, which leads to 
a box that screws into the back or base of a display and has the RJ11 and 
Mini-DIN-7 jacks for keyboard and mouse, and then has three short BNC cables 
coming out of of it for color video.

I have the parts to make a breakout box if I have to but that'd be more of a 
pain than giving someone money and having a thing arrive in the mail. :)

 -- Chris

Re: Linearizing PDF scans

[Chris Hanson via cctalk]

On Aug 14, 2021, at 3:54 PM, J. David Bryan via cctalk  
wrote:

> I guess the operative question is whether people tend to view PDF pages on 
> a server or download files and view them locally.

Even when viewing files locally, linearization is important for not having to 
load too much of the file for basic operations like navigating and scrolling.

PDF requires page independence so linearization isn't what puts the information 
for each page together; instead, linearization is what ensures the content in 
the PDF is in presentation order. You can jump around and scroll in a PDF by 
doing byte-range fetches even without linearization, but you may have to do 
more work (e.g. you can't load "the next few pages" for scrolling in just a 
single fetch, it may require one fetch per page).

  -- Chris

Re: Writings on AI from 17 years ago....

[Chris Hanson via cctalk]

On May 24, 2021, at 10:07 AM, Alan Perry via cctalk  
wrote:

> However, it looks like they may be trying to re-form it as a charitable 
> organization, Vulcan Arts & Entertainment, similar to what happened with 
> EMP/MoPOP. They have a fancy new website (https://vulcanae.com) and are 
> soliciting interest in memberships, donating, and volunteering.

Good thing they shut LCM+L down even though they could have kept it funded at 
100% through the entire pandemic! Because nothing attracts memberships, 
donations, and volunteers like setting your goodwill _on fire_.

  — Chris

WTB: HP 9000-340 memory (HP 98268A), AUI (HP 98235A), SCSI (HP 98658A)

[Chris Hanson via cctalk]

I've acquired an HP 9000-340C+ and I'd like to kit it out with the maximum RAM, 
SCSI, and AUI rather than thin Ethernet. Desired:

- RAM boards: HP 98268A RAM board (three of them to get to 16MB, I'd probably 
buy extra just to be safe)
- AUI LAN board: 98571-66534, aka HP 98235A AUI LAN Upgrade
- SCSI board: HP 98658A SCSI Interface Card

Anyone have any of this stuff that they might be interested in parting with?

I'm also always on the lookout for an HP 98556A 2D/integer graphics accelerator 
in case anyone happens to have one that needs a home. That's the integer 
accelerator with a 68020 and some RAM, which piggybacks atop the 98550A 
(1280x1024 8-bit color card) via its extra Eurocard connector.

  -- Chris

Re: Greaseweazle

[Chris Hanson via cctalk]

On Feb 2, 2021, at 7:58 AM, geneb via cctalk  wrote:
> 
> You're absolutely correct, however the only thing Al contributes (for the 
> purposes of this particular discussion) are complaints about how other people 
> are doing it wrong.

I think Al has contributed enormously to the archival and preservation of our 
industry history, which is exactly why I pretty much always want to hear more 
from him on anything related—and why my ears perk up when he says there's a 
better way to do something.

Also, I'm 100% with Al about not siloing projects _on social media sites like 
Facebook_. They're terrible for technical projects because they're specifically 
designed to surface "engaging" social information and push further engagement, 
rather than to actually preserve chronology, or to make it easy to refer back 
to or link to anything at all in the past. There is only forward, and only at 
the whim of The Algorithm.

Mailing lists are by far the best choice when it comes to collaboration on 
technical projects, with tools from project hosting sites like SourceForge, 
Bitbucket, GitLab, and Github a close second.

  -- Chris

Re: Greaseweazle

[Chris Hanson via cctalk]

On Feb 1, 2021, at 5:07 PM, Antonio Carlini via cctalk  
wrote:
> 
> Indeed. The important part is that someone's written some firmware. Oh, and 
> it's cheap too, of course.

And that it's something available for the community to work with and improve, 
rather than something where people are hoping to profit off archival ventures.

  -- Chris

CPT Phoenix Jr system unit?

[Chris Hanson via cctalk]

I’ve acquired the display and keyboard portion of a CPT Phoenix Jr but the 
seller didn’t have the system unit. (I suspect someone along the chain of 
custody thought it was a generic PC and recycled it.)

Does anyone have one that needs a home?

  — Chris
  — who has an affinity for portrait displays

Sent from my iPhone

Re: personal history of personal computers

[Chris Hanson via cctalk]

On Jan 24, 2021, at 3:13 PM, Chris Hanson via cctalk  
wrote:
> What happens if it's not possible to talk to you? Can you write up just what 
> the deal is with the drive, so that everyone can learn?

And now I see that you've done so—thank you!

  -- Chris

Re: personal history of personal computers

[Chris Hanson via cctalk]

On Jan 4, 2021, at 1:31 PM, dwight via cctalk  wrote:
> 
> There was a little known 68K machine. It was the Canon Cat. Although, it was 
> generally not intended as a development machine, in its short life, several 
> applications were developed.
> It was primarily sold as a word processor ( quite powerful one at that ). It 
> had Forth running under the word processor. One could do both assembly and 
> other things once one understood how to access the Forth.
> If you should ever get one, don't use the disk drive until you talk to me.
> It has a common problem that if you don't understand it will destroy the 
> drive.

What happens if it's not possible to talk to you? Can you write up just what 
the deal is with the drive, so that everyone can learn?

  -- Chris

Re: Anyone want some LMI Lisp Machine tapes?

[Chris Hanson via cctalk]

On Dec 2, 2020, at 7:58 PM, Al Kossow via cctalk  wrote:
> 
> On 12/2/20 7:37 PM, r.stricklin via cctech wrote:
>> On Dec 2, 2020, at 12:48 PM, Chris Hanson via cctech wrote:
>>> I’m bidding on these tapes with the intent to get them into the hands of 
>>> someone like Josh and/or Al who has the skill and equipment to read and 
>>> archive them.
>> Then I hope you're not making it harder by bidding against them.
> 
> I'm not bidding, it's just Josh

Josh and I coordinated, it’s just me. :)

  — Chris

Re: Anyone want some LMI Lisp Machine tapes?

[Chris Hanson via cctalk]

I’m bidding on these tapes with the intent to get them into the hands of 
someone like Josh and/or Al who has the skill and equipment to read and archive 
them.

I hope nobody is trying to acquire them just to “have” them.

  — Chris

Re: DEC PDP-8/E wanted

[Chris Hanson via cctalk]

On Nov 20, 2020, at 10:08 AM, Tom Uban via cctalk  wrote:
> 
> For those interested in a PDP-8 system but don't want the large size/weight 
> and
> maintenance issues, I built the full set of Spare Time Gizmos SBC6120 
> (integrated
> PDP-8), FP6120 (front panel for SBC6120) and IOB6120 (Jim Kearney's 
> multi-function
> companion board) a number of years ago and would be willing to part with them
> for a reasonable offer. Here are related links:

Does anyone know of anyone building them for sale? I don’t need a “real” PDP-8 
in my life with all my other hardware (more Q-bus PDP-11, on the other hand…) 
but I’d love having *a* PDP-8, especially one that doesn’t require enormous 
amounts of power.

  — Chris

Re: Crypto Ancienne: TLS for the Internet of Old Things

[Chris Hanson via cctalk]

On Nov 18, 2020, at 4:16 PM, Cameron Kaiser via cctalk  
wrote:
>> Another option for these systems is mbedTLS, originally by ARM. It only
>> requires C89,
> 
> I looked at mbedTLS (formerly PolarSSL) before I even embarked on it based
> on other recommendations, but it claims to require c99:

Oh, bummer, maybe I'm just misremembering.

> 
>   https://github.com/ARMmbed/mbedtls
> 
> Have you had success building it on other systems? What compilers could you
> get away with? I'd rather not reinvent the wheel but it seemed like I had to.

I was able to build its three component libraries just fine with CodeWarrior 7 
on Mac OS 9 on my iMac G4. Same with libssh2. I never actually got to the point 
of testing it though, the iMac's PSU died. :(

>> At some point MacSSH may use it. Or maybe the current maintainer will try
>> cryanc. :)
> 
> Didn't lsh get some updates? Or was I thinking of something else? ISTR that
> MacSSH used lsh under the hood.

It did, but it was also in the process of switching to libssh2, so Brendan 
switched that from OpenSSL to mbedTLS too:

https://github.com/macssh/macssh/tree/libssh2

In case anyone wants to contribute. (Alas I can't, for the usual reasons, but 
maybe someone can…)

  -- Chris

Re: Crypto Ancienne: TLS for the Internet of Old Things

[Chris Hanson via cctalk]

On Nov 16, 2020, at 10:34 AM, Cameron Kaiser via cctalk  
wrote:
> 
> If you have an older pre-C99 system, I've backported a TLS 1.2 library to gcc
> versions as early as 2.5 as long as it has 64-bit ints (long long, usually)
> and stdarg.h.
> 
> https://github.com/classilla/cryanc

Great work, Cameron!

Another option for these systems is mbedTLS, originally by ARM. It only 
requires C89, it can serve as a replacement for SSL libraries that follow the 
standard API signatures, it is also quite easy to build (a little more 
complicated than Crypto Ancienne, though not by much--you just need to examine 
its GNUmakefile to derive a build system for whatever OS you're targeting), and 
it's fairly complete.

One advantage of mbedTLS is that it works with libcurl, libssh2, etc. already 
so if you need to build more such things you have a good basis to start from.

At some point MacSSH may use it. Or maybe the current maintainer will try 
cryanc. :)

  -- Chris

Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

[Chris Hanson via cctalk]

On Oct 4, 2020, at 1:53 PM, Brent Hilpert  wrote:
> 
>> For the latter two, I need to figure out whether my backplane supports ABCD 
>> use in the first couple of slots, or if it’s purely an ABAB model. (The 
>> KDF11-A, RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to 
>> interpret that as ‘these were configured together in this pattern” rather 
>> than “these happened to fit in here for storage.”)
> 
> I have an ~ 30 page manual for the MDB MLSI-BA11-600 series chassis, if there 
> is something that might be answered from that.

Whoa, cool—that’s the chassis I have! Is the manual scanned?

  — Chris

Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

[Chris Hanson via cctalk]

Thanks to everyone who replied, on- and off-list! There’s an MXV11-B (M7195) on 
its way to me. :)

Since people were asking about my setup, here’s what I have:

- MDB BA11-clone enclosure, PSU, and 8-slot 22-bit backplane
- DEC KDF11-A (M8186) rev C processor with FPP added
- DEC DLV11-J (M8043) SLU
- Motorola M1132 128KW RAM

And some stuff that’s untested but I’m eager to try:

- (soon) Emulex UC07 SCSI controller
- (soon) DEC MXV11-B (M7195) system controller
- DEC MSV11-LF (M8059) 64KW RAM
- DEC DEQNA (M7054) Ethernet controller
- DEC RLV12 (M8061) RL01/02 disk controller
- MDB MLSI-SCM11 system controller

For the latter two, I need to figure out whether my backplane supports ABCD use 
in the first couple of slots, or if it’s purely an ABAB model. (The KDF11-A, 
RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to interpret that 
as ‘these were configured together in this pattern” rather than “these happened 
to fit in here for storage.”)

I’m actually still looking for docs on the MSLI-SCM11, since it looks extremely 
configurable and I have no idea how to use it or what it’ll provide…

As for what I’m going to do with it, I’m thinking XINU. Comer’s book is one of 
the two books via which I learned C (Tannenbaum’s was the other) so I think 
that’d be a fun system to have up and running, especially since it has IP 
support.

  — Chris

Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

[Chris Hanson via cctalk]

My little LSI-11 system doesn't have a usable Line-Time Clock because it lacks 
the register, which it expects to be in either an MXV11-B (M7195) or a BDV11 
(M8012). My power supply theoretically supplies the LTC but I haven't confirmed 
that, so my preference would be an M7195 if possible.

Does anyone have one they'd be interested in parting with? I'm fine with 
shipping internationally and with paying a reasonable price, and I promise to 
take good care of it and pass it on to another good home if I should ever part 
with it. (Friends don't let friends recycle rare electronics.)

Alternately, is there a "modern" Q-bus board that provides things like LTC 
(both the clock and the register), SLU, memory, etc.?

  -- Chris

Re: Old Terminals

[Chris Hanson via cctalk]

On Oct 2, 2020, at 12:01 PM, John Many Jars via cctalk  
wrote:
> 
> I've always had a weakness for terminals.
> 
> I have a question, are all those RJ-11 style keyboards interchangeable?

No, virtually every manufacturer had its own signaling and protocols, and in a 
lot of cases individual *models* have their own signaling and protocols.

You can probably find help fixing your ICL M8 here, it should be repairable.

  — Chris

Re: Exploring early GUIs

[Chris Hanson via cctalk]

On Sep 21, 2020, at 9:29 PM, Richard Pope  wrote:
> 
>The Amiga 1000 with AmigaDos and Workbench was released in late 1985. 
> AmigaDos is based on Unix and Workbench is based on X-windows.

Neither of these claims is correct.

  — Chris

Re: Exploring early GUIs

[Chris Hanson via cctalk]

On Sep 21, 2020, at 3:38 PM, Cameron Kaiser via cctalk  
wrote:
> 
> Almost looks like a SunView ancestor.

I’m pretty sure SunWindows/SunView predates MGR by 2-3 years.

  — Chris

Re: Care and feeding of some Lisp machines (TI Explorer and Xerox Star)

[Chris Hanson via cctalk]

On Sep 14, 2020, at 9:00 AM, Josh Dersch via cctalk  
wrote:
> 
> The Star mouse pad can be recreated with a laser printer (I've used this:
> http://www.digibarn.com/collections/devices/xerox-mousepad/index.html, and
> there's a postscript file floating around out there…).

Here’s some PostScript that was based on Xerox’s patent:

http://rendezvous.eschatologist.net/xerox/XeroxMousepad.ps

I’ve also put a PDF version here:

http://rendezvous.eschatologist.net/xerox/XeroxMousepad.pdf

It just needs to be printed at sufficiently high resolution to be used as a 
mousepad.

  — Chris

Re: CMU Andrew system (and wm) preservation

[Chris Hanson via cctalk]

On Sep 7, 2020, at 6:24 AM, dst...@execulink.com wrote:
> 
> The description I have for AUIS (6.3.1) is:
> 
> "AUIS (Andrew User Interface System) - compound document
> environment offering a word processor, mail/bulletin board
> reader/writer, drawing editor, spreadsheet, font editor,
> application builder, and many other facilities"
> 
> Again, an application, not a windowing system per se.

Yes, the Andrew environment implemented proper layering, so ATK was made to 
work atop X and the applications (messages, ez, console, typescript, etc.) came 
along.

At Carnegie Mellon in the early 1990s, you could (with only a little work, to 
use a console rather than graphical login) use either X or wm on some of the 
campus workstations. On a DECstation 3100 running Ultrix, if you weren’t going 
to run any X applications wm was *much* more responsive. I wasn’t around when 
the clusters had Sun-3 or IBM RT hardware but I can imagine the differences 
there were even more pronounced. (With wm, a DECstation felt as much faster 
than a Mac II as it actually was…)

Applications built against ATK could run atop either wm or X; I don’t know if 
there were distinct builds of ATK or if the conditional logic was in the 
framework itself, but the applications themselves worked just fine with either 
since Andrew implemented a shared library mechanism. (Yes, even on Ultrix.)

The publicly-released Andrew distributions don’t include the wm code, only the 
X version. I don’t know if they’ll actually build against the wm headers and 
libraries if they’re present, or if by the time CMU was releasing them publicly 
they had stripped that code out entirely.

  — Chris

Re: CMU Andrew system (and wm) preservation

[Chris Hanson via cctalk]

On Sep 6, 2020, at 2:10 PM, Don Stalkowski  wrote:
> 
> Forgive a dumb question, but is this somehow related to the Andrew Tool Kit
> or the Andrew User Interface System?

Yes indeed, the Andrew window manager and the Andrew Tool Kit were both part of 
the Andrew User Interface System.

  -- Chris

CMU Andrew system (and wm) preservation

[Chris Hanson via cctalk]

Back before X11 took off, IBM funded CMU's development of Andrew, which had its 
own complete window system represented by its "wm" window manager. One of the 
many things that led to X's prevalence was that to get ahold of Andrew and wm, 
you had to license it from IBM, whereas X was licensed freely by MIT and 
available via FTP, tape, etc.

When I was at CMU in the early through mid 1990s, the CMU Computer Club 
continued to maintain a fork of "wm" called "wmc" that was available to club 
members, including source code. While I'm pretty sure I have an archive of this 
code on a Zip disk somewhere, I thought I'd put out the call to the community 
to see if anyone else had preserved early Andrew bits since they're both 
historically important and architecturally interesting.

What's architecturally interesting about them? Among other things, CMU created 
their own shared library mechanism for Andrew, and their own object oriented 
dialect of C (implemented via a separate preprocessor) that was surprisingly 
similar to Objective-C. The entire Andrew system was also component-oriented, 
such that it supported embedding components for handling different media types 
within each other, while keeping the embedded ones editable -- most of what 
developers got later with OLE and OpenDoc.

So it'd be great if this stuff was archived in such a way that it could be used 
with contemporary systems, whether emulated or real hardware. Has anyone done 
any of this yet?

  -- Chris

Micro Memory VME card info? MM-6316

[Chris Hanson via cctalk]

I have a Micro Memory Inc. 16MB VME DRAM card MM-6316 but unlike many other 
Micro Memory products I can’t find a user’s manual.

Does anyone know anything about the jumpers/switches for this board?

 — Chris

Sent from my iPad

Re: SIMH on low overhead platform

[Chris Hanson via cctalk]

On Aug 20, 2020, at 4:30 AM, Jan-Benedict Glaw  wrote:

> It's debateable whether or not the all-in-one builds are good or bad.
> Ie. GCC went into quite some development effort to gain LTO (link-time
> optimization) up'n'running, which was built quite exactly to allow
> optimizations that would otherwise only be possible if all sources are
> compiled in one run.

Link-time optimization has been a thing for a few decades, independent of 
whether GCC & GNU ld supported it. And very few compilers actually do anything 
any differently when all of the sources are passed in one go; to follow the 
spec, the compiler must consider each compilation unit independently, which 
it'll typically do by spawning one compilation process per compilation unit.

This also means the build system can't manage the build's parallelism, which is 
something you really want on a large project.

>  With any halfway modern hardware, build times probably don't really
> matter. Sure, if you're sitting in front of it waiting to finish a
> build, every second feels like ... ages.

Build times really do still matter. On my modern hardware SIMH still takes long 
enough to build that it's a hassle.

>  However, in my experience speed isn't really all that important.
> Correctness is. And the Makefile quite works, even without pulling in
> all the GNU autoconf or CMake stuff.

In my experience the more complex the Makefile, the less likely it is to be 
correct, and there's an enormous amount of unnecessary complexity in SIMH's 
Makefile—especially since it doesn't just build the simulators but also runs 
their tests without being instructed to. SIMH's Makefile results in a lot of 
unnecessary rebuilding and waiting.

>  On my laptop, a `make -j4' (building all simulators and running
> their tests) takes some 6min 20sec. Fair enough. Building just one
> (ie. ,/BIN/vax aka. vax3900 which I care the most about personally) is
> a matter of 21 seconds. Sure, that could be faster with careful
> dependency tracking, but that's okay for me.

You don't even need careful dependency tracking to improve this, just regular 
make behavior. What's more, the way the Makefile is currently constructed 
interferes with your use of `make -j4` by producing unnecessary output.

In short, cleaning up the build to work like any other make-based project would 
result in faster builds and make SIMH easier to work on for people interested 
in doing so.

  -- Chris

Re: SIMH on low overhead platform

[Chris Hanson via cctalk]

On Aug 18, 2020, at 5:50 PM, Grant Taylor via cctalk  
wrote:
> 
> On 8/17/20 5:34 PM, Chris Hanson via cctalk wrote:
>> One thing that would make it much easier to experiment with SIMH in 
>> scenarios like this is if its build system wasn't horribly redundant.
> 
> Why are you mentioning SIMH's /build/ system in a thread discussion boot 
> times?

Did you miss the part where I said it would make it much easier to experiment 
with it if the build system was better? For example, switching between 
different networking implementations can require a rebuild.

> I wouldn't object if SIMH's /build/ took 20 minutes if it's something that 
> only happens every 3-12 months while starting on a tiny Linux / *BSD / et al. 
> system that /boots/ in a low number of seconds.


SIMH improves quickly enough that you won't want to do a 20 minute build every 
3-12 months, but instead perform new builds with some regularity.

Between that and ease of experimenting (or the lack thereof) a bad build system 
can really hold back a project.

  -- Chris

Re: Sun/3-powered 737 flight sim

[Chris Hanson via cctalk]

Yeah, there's good reason more modern AUI-based Ethernet and more modern SCSI 
systems use resettable polyfuses...

  -- Chris

> On Aug 17, 2020, at 4:44 PM, Michael Thompson  
> wrote:
> 
> I have also seen the SCSI terminator power fuse blow when the terminator is 
> hot plugged.
> 
> On Mon, Aug 17, 2020 at 7:26 PM Chris Hanson  > wrote:
> On Aug 17, 2020, at 10:52 AM, Michael Thompson via cctalk 
> mailto:cctalk@classiccmp.org>> wrote:
> > 
> > I have a Sun 3/E, including a SCSI/Ethernet board, that ran fine the last
> > time it was powered on. There is a collector in southern Germany who also
> > has a 3/E board set. I didn't see any contact information for the simulator
> > owners.
> 
> The originator of the Reddit thread works on this simulator and is the point 
> of contact.
> 
> They're really interested in moving off the Sun 3/e rather than continuing to 
> try to get spare parts etc. I've also suggested they check the capacitors and 
> fuses, especially on the Ethernet/SCSI cards, since the originator claims 
> multiple failures. The Ethernet fuse in particular is likely very easy to 
> trip because people these days aren't used to AUI adapters which generally 
> *can not* be hot-plugged without blowing a fuse.
> 
>   -- Chris
> 
> 
> 
> -- 
> Michael Thompson

Re: SIMH on low overhead platform

[Chris Hanson via cctalk]

On Aug 17, 2020, at 4:28 PM, Chris Hanson via cctalk  
wrote:
> 
> NetBSD runs SIMH just fine and can be made to boot extremely quickly.

Oh yeah, NetBSD 9.0-stable 64-bit also only takes a few seconds to boot on a 
Raspberry Pi 3B+. It's easy enough to just throw on an SD card and try out. 
Alas the Raspberry Pi 4 isn't supported yet by NetBSD, though I think it's 
coming along. An RPi4 with 4 or 8GB of RAM should be a very nice turnkey SIMH 
server.

  -- Chris

Re: SIMH on low overhead platform

[Chris Hanson via cctalk]

One thing that would make it much easier to experiment with SIMH in scenarios 
like this is if its build system wasn't horribly redundant. It genuinely looks 
like someone looked at make and said "How can I turn this into a procedural 
scripting system?" and then wrote the SIMH makefile in that style.

It should only take a couple seconds to build SIMH but instead it takes a 
couple minutes, rebuilds a ton of things redundantly, and runs all sorts of 
testing as a side-effect (instead of having that under a separate target).

At one point I worked out that most of the preprocessor macros fall into just a 
couple of buckets so building SIMH could be separated into building just a 
couple of libsimh libraries from the same sources (one for 32-bit simulated 
pointers, one for 64-bit simulated pointers) and then most of the rest of the 
targets could *just* be the target-specific sources plus the right libsimh.

Unfortunately (1) I can't contribute back that change if I make it without 
jumping through a lot of bureaucratic hoops (employment agreement) and (2) the 
current maintainer appears to not want to hear any criticism whatsoever of 
SIMH's build system.

  -- Chris

Re: SIMH on low overhead platform

[Chris Hanson via cctalk]

On Aug 17, 2020, at 12:43 AM, Tom Hunter via cctalk  
wrote:
> 
> Has SIMH been ported to a low overhead (instant-on) platform?
> 
> I ask the question because the startup time of Linux is distracting when
> powering on a PiDP-11/70 or similar clone systems based on SIMH.

NetBSD runs SIMH just fine and can be made to boot extremely quickly.

I use NetBSD on a surplus HP ProLiant DL360p Gen8, NetBSD 9.0-stable boots in 
just a few seconds. The hardware itself takes a couple minutes to go through 
its bootstrap process, however. (I should have considered setting up ESXi and 
installing NetBSD atop that to avoid the hardware boot process, since I'm 
regularly rebuilding and updating NetBSD…)

  -- Chris

Re: Sun/3-powered 737 flight sim

[Chris Hanson via cctalk]

On Aug 17, 2020, at 10:52 AM, Michael Thompson via cctalk 
 wrote:
> 
> I have a Sun 3/E, including a SCSI/Ethernet board, that ran fine the last
> time it was powered on. There is a collector in southern Germany who also
> has a 3/E board set. I didn't see any contact information for the simulator
> owners.

The originator of the Reddit thread works on this simulator and is the point of 
contact.

They're really interested in moving off the Sun 3/e rather than continuing to 
try to get spare parts etc. I've also suggested they check the capacitors and 
fuses, especially on the Ethernet/SCSI cards, since the originator claims 
multiple failures. The Ethernet fuse in particular is likely very easy to trip 
because people these days aren't used to AUI adapters which generally *can not* 
be hot-plugged without blowing a fuse.

  -- Chris

Re: OpenVMS Community License

[Chris Hanson via cctalk]

On Jul 28, 2020, at 4:41 PM, Zane Healy  wrote:
> 
> On Jul 28, 2020, at 4:30 PM, Chris Hanson via cctalk  
> wrote:
>> 
>> Can someone please post a link to some text describing the new licensing 
>> program and how to apply to it?
>> 
>> Just sending a video isn't useful for everyone.
>> 
>> — Chris
> 
> 
> Honestly, Camiel’s answer on my one question provides more info than the link 
> does.
> 
> https://vmssoftware.com/about/news/2020-07-28-community-license/
> 
> I applied this morning, who knows how long it will take.

Thanks! I've just applied as well. :)

  -- Chris

Re: OpenVMS Community License

[Chris Hanson via cctalk]

Can someone please post a link to some text describing the new licensing 
program and how to apply to it?

Just sending a video isn't useful for everyone.

  -- Chris

Re: Motorola 12Xbug?

[Chris Hanson via cctalk]

Thanks once again!

  — Chris

Sent from my iPad

> On Jul 19, 2020, at 7:54 AM, Plamen Mihaylov  
> wrote:
> 
> 
> http://afterpeople.com/vmefiles/ 
> 
>> On Sun, Jul 19, 2020 at 8:43 AM Chris Hanson via cctalk 
>>  wrote:
>> Does anyone know where to find Motorola 120bug or 12Xbug? I have an MVME121 
>> but it has a third party ROM, not the typical Motorola boot ROM. (The 12Xbug 
>> manual would be handy too, of course.)
>> 
>>   -- Chris
>> 

MVME225 documentation

[Chris Hanson via cctalk]

Does anyone have MVME225 documentation? I have one of these boards now and no 
docs for how to set the addressing jumpers/switches.

  -- Chris

Motorola 12Xbug?

[Chris Hanson via cctalk]

Does anyone know where to find Motorola 120bug or 12Xbug? I have an MVME121 but 
it has a third party ROM, not the typical Motorola boot ROM. (The 12Xbug manual 
would be handy too, of course.)

  -- Chris

Re: MVME332XT documentation?

[Chris Hanson via cctalk]

Just so you know, the file named MVME332XT is actually MVME332XTFW and the one 
named MVME332XTFW/D2 is actually MVME332XT/S2, which is apparently a release 
note for Motorola System V driver update for the board. Do you also happen to 
have the installation & user guide?

  — Chris

Sent from my iPad

> On Jul 3, 2020, at 11:50 PM, Plamen Mihaylov  
> wrote:
> 
> 
> Here you go  http://m88k.com/files/
> 
>> On Sat, Jul 4, 2020 at 9:13 AM Chris Hanson via cctalk 
>>  wrote:
>> I’ve acquired a couple of MVME332XT (plus port panels and cabling) and was 
>> surprised to find that there’s very little documentation online, only a few 
>> references for setting up the board as part of specific systems. And a 
>> driver for it in OpenBSD 5.5—for their mvme88k platform only, because for 
>> some reason they don’t share drivers between all the VME platforms.
>> 
>> Does anyone have scanned or printed documentation for the MVME332XT? How 
>> about document number MVME332XTFW, about the 332’s firmware?
>> 
>>   — Chris
>> 
>> Sent from my iPad

Re: MVME332XT documentation?

[Chris Hanson via cctalk]

Excellent, thank you!

  — Chris

MVME332XT documentation?

[Chris Hanson via cctalk]

I’ve acquired a couple of MVME332XT (plus port panels and cabling) and was 
surprised to find that there’s very little documentation online, only a few 
references for setting up the board as part of specific systems. And a driver 
for it in OpenBSD 5.5—for their mvme88k platform only, because for some reason 
they don’t share drivers between all the VME platforms.

Does anyone have scanned or printed documentation for the MVME332XT? How about 
document number MVME332XTFW, about the 332’s firmware?

  — Chris

Sent from my iPad

Re: UUCP on macOS / *BSD

[Chris Hanson via cctalk]

On Jun 28, 2020, at 6:07 PM, Grant Taylor via cctalk  
wrote:
> 
>  - uuto / uucp copy files from my non-root / non-(_)uucp user to the UUCP 
> spool.  But the (demand based) ""call (pipe over SSH) is failing.

macOS switched to launchd from inetd a very long time ago. If you're going to 
use macOS as a UUCP node you'll want to enable the com.apple.uucp service, 
which will ensure uucico is run for you by the system.

> I noticed that the following files weren't set UID or GID like they are on 
> Linux.  But I don't know if that's a macOS and / or *BSD difference when 
> compared to Linux.
> 
> /usr/bin/uucp
> /usr/bin/uuname
> /usr/bin/uustat
> /usr/bin/uux
> /usr/sbin/uucico
> /usr/sbin/uuxqt
> 
> Adding the set UID & GID bits allowed things to mostly work.

That's a macOS difference, not a BSD one. I don't *think* you need to re-add 
any setuid or setgid bits, but I could be mistaken. It's been a very long time 
since I've actually used UUCP. If they do need to be made setuid or setgid, 
that sounds like a bug.

> Aside:  Getting the contemporary macOS so that I could edit the 
> (/usr/share/uucp/) sys & port files was a treat.

In macOS 10.14-10.15 these files are indeed covered by system integrity 
protection, I think that's probably a bug since they need to be edited by a 
sysadmin to use UUCP.

  -- Chris

PS - Here's the UUCP source for recent macOS: 
https://opensource.apple.com/source/uucp/uucp-12/ 

Re: CSPI SC-3XL and SC-4XL documentation?

[Chris Hanson via cctalk]

It looks like what I’m looking for from CSPI (aka CSP, Inc.) is the “SuperKit” 
board support, function, and RPC library for the SuperCard SC-3XL and SC-4XL, 
along with their documentation.

There are mentions of it in the Wayback Machine for http://www.cspi.com/ and 
the vendor is still around, but there’s obviously no mention anywhere on the 
current web site of this stuff, and I doubt contacting their support would do 
any good…

Does anyone have more detail? Or do I have to reverse-engineer any ROMs that 
happen to be on these boards?

  — Chris

CSPI SC-3XL and SC-4XL documentation?

[Chris Hanson via cctalk]

I've just come into a couple of CSPI VME cards, an SC-3XL and an SC-4XL (both 
with attached memory), and I was wondering if anyone has documentation.

They're based on the Intel i860 and intended for VME-based array processors.

  -- Chris

Re: Future of cctalk/cctech

[Chris Hanson via cctalk]

On Jun 17, 2020, at 10:48 AM, Fred Cisin via cctalk  
wrote:
> 
> On Wed, 17 Jun 2020, ED SHARPE @ AOHell.com via cctalk wrote:
>> These 2 have my vote as well
>> I do not know, anyone using a text only mail reader anymore!
>> 
>>> The one thing I would change here is removal of the restriction on 
>>> attachments.
>>> Well, two things.. Getting rid of the cctalk/cctech split as well.
> 
> I read this list on PINE, on a shell account at my ISP.
> 
> In this group, I doubt that I am the only one.
> 
> 
> Can we restrict to TEXT emails?

Why?

Pine/Alpine should show the text portion of any multipart messages perfectly 
reasonably, and not even attempt to download non-text MIME content from your 
IMAP server. Crispin designed the application and the protocol that way 
intentionally; his approach was always that you should be able to run your MUA 
locally with just a 2400bps link to your IMAP server, and get perfectly 
reasonable performance.

  -- Chris

Re: Future of cctalk/cctech

[Chris Hanson via cctalk]

On Jun 17, 2020, at 1:50 AM, Tor Arntsen via cctalk  
wrote:
> 
 There is also groups.io, and it has some very nice features compared to
> 
> Please please, no groups of any kinds. They're all horrible to use.

Do you mean "web forum" where you say "groups?"

> A
> genuine mailing list like this is infinitively easier to keep track of
> and read at leisure. Can't stand groups.io.

I've found the groups.io  mailing list mode to be perfectly 
reasonable for a number of groups I'm a part of. And it has a forum-like front 
end for people who insist on doing everything through a web page.

  -- Chris

Re: Future of cctalk/cctech

[Chris Hanson via cctalk]

On Jun 16, 2020, at 10:23 PM, Lars Brinkhoff via cctalk  
wrote:
> 
> Jon Elson wrote:
>> Yes, several other groups I read and contribute to have moved to
>> groups.io, and they are working quite well and reliably.  Some options
>> require $10 a month to be free from ads.
> 
> That's a red flag.

Being able to pay a service not to show ads on their web site shows that 
they're willing to say "no" to advertisers, which is pretty much the opposite 
of a red flag to me.

  -- Chris

Re: Living Computer Museum

[Chris Hanson via cctalk]

On May 28, 2020, at 5:25 PM, Tony Aiuto via cctalk  
wrote:
> 
> So depressingly true. I run the little museum in Google's NYC office.
> I've had a bunch of working 80's-90's era machines and workstations on
> display, but they require constant repair because people are too lazy or
> entitled to treat them with care

At the fruit company there are a few such employee-curated displays but so far 
as I know we’ve never had such problems. Of course, there’s also the fact that 
only employees have access. (And even before the phone, when some guests were 
allowed in some areas, they had to be personally escorted at all times.)

Back during the mid-1990s there was a small “museum” display by the cafeteria 
of some inactive hardware under glass, and there was also a big lab of our 
products from every era off the engineering support library upstairs in the 
same building. That lab was more like LCM in that you could just go to it and 
work with anything; it was maintained by the engineering support library and 
only accessible to employees, so that’s probably why it never had serious 
problems with people breaking or stealing things.

  -- Chris

Re: Living Computer Museum

[Chris Hanson via cctalk]

On May 28, 2020, at 9:41 AM, Robert Harrison via cctalk  
wrote:
> 
> Does anyone know what it would take to sustain the museum until it can 
> reopen? Are tickets a major source of income? 
> This is the first I have heard of the museum, so I don’t know much about it, 
> but it sounds like something worthy to try to save.

LCM+L is owned and operated by Paul Allen’s $20 billion estate. They are not 
hurting for cash, though I’m certain some bean-counter at Vulcan sees 
continuing its operations during the pandemic as a drain on resources. 
Management by the numbers.

The actual Living Computer Museum + Labs was *great* to visit, and from the 
outside worked exactly like you would expect a museum about computing history 
to work: A visitor to the museum could actually *interact* with most of the 
systems they had, they weren’t just displaying static artifacts behind a velvet 
rope or pane of glass with a placard describing them. The stuff you couldn’t 
interact with directly you could still interact with through terminals and even 
the Internet.

This is one of the things that disappointed me most about the Computer History 
Museum in Mountain View, CA. Sure you can’t let the public interact with 
*everything*, but since so much of computing since its inception has been about 
interaction with active systems, just displaying them is leaving out a large 
amount of what really makes them interesting. The CHM does a lot of great 
preservation, archival, and curatorial work, but this really feels like a 
glaring omission.

  -- Chris

Re: Living Computer Museum

[Chris Hanson via cctalk]

On May 28, 2020, at 10:31 AM, William Donzelli via cctalk 
 wrote:
> 
>> Loans are standard practice in art museums, from other museums as well as 
>> from private collections.  Perhaps not so much in science/technology museums.
> 
> Art museums work under a different set of rules and ethics than other museums.

Do tell.

  -- Chris

Re: Living Computer Museum

[Chris Hanson via cctalk]

On May 27, 2020, at 8:48 PM, Jecel Assumpcao Jr  wrote:
> 
> I would think that if people you liked got replaced with people who
> don't care then you might have a major battle trying to get back stuff
> you loaned.

It might be a battle, possibly even a major one, but it would be fundamentally 
winnable when there’s explicitly no transfer of ownership.

That may, of course, be why they told Alan they don’t take loans; they may want 
to not worry about dealing with people who want loaned pieces returned, or 
dealing with the risk of loss or damage (e.g. insurance), and so on.

  -- Chris

Re: Living Computer Museum

[Chris Hanson via cctalk]

On May 27, 2020, at 8:02 PM, Alan Perry  wrote:
> 
> That wasn’t an option for most folks. They told me that they didn’t accept 
> items on loan.

Well, that really sucks.

  -- Chris

Re: Living Computer Museum

[Chris Hanson via cctalk]

The big problem with this situation is that it’s simply unnecessary: Living 
Computer Museum + Labs is not independent of Vulcan, and Vulcan can *easily* 
afford to keep the people who work there on payroll and working from home 
indefinitely.

This is happening entirely because the people holding the pursestrings have no 
idea how to run a museum, or even what a museum *does*. It’s pretty clear that 
they think they can just pack things away for a while, then hire a few people 
to take tickets and put out exhbits when they decide to reopen, without any 
consideration to the kind of historical preservation work the museum is in the 
process of doing or even what might need to be done to prepare exhibits for 
public access, what it means to be ready to obtain, receive, and preserve 
newly-uncovered historical artifacts, and so on.

https://twitter.com/eschaton/status/1265751114953011200

A group of people who actually understand (like Woz and Gates et al) should 
step in, take it off Vulcan’s hands, and endow it as an independent entity. And 
people should stop donating their collections to museums and lend them instead.

  -- Chris

Re: Living Computer Museum

[Chris Hanson via cctalk]

This is why people should avoid donating equipment directly to institutions and 
instead lend hardware to them.

At least then you have a claim with which to try to get your stuff back if they 
fold, close, or decide to go in a direction you don’t like.

  -- Chris

Re: (V)HDL Toolsets

[Chris Hanson via cctalk]

On May 23, 2020, at 7:54 AM, Jay Jaeger  wrote:
> 
> I don't think a 100K character IBM SMS machine needs DDR.  8D   For my
> old student ECE ZAP machine, I just used very simple
> on-development-board RAM, with a layer in between.  Probably do the same
> here.

These days, the RAM on a lot of development boards is DDR or something else 
that requires a significant amount of controller work.

> Ethernet might be nice, but I don't think I'd include a whole IP just to
> get that

I think it depends on whether you want to expose *Ethernet* to the device 
you’re implementing, or just to provide access to it *over* Ethernet. Exposing 
serial and other channels via SPI or I2C is certainly straightforward.

> probably just use I2C or SPI to an external micro controller
> (for lamps, switches, the console selectric, etc.)  Doing this would
> also help me fit to a smaller FPGA.

Of course, there are also IP blocks for I2C and SPI, some of which may again 
map to dedicated hardware on the FPGA, providing more room for your logic.

So yes, context matters, but you need to look at both what you want to 
accomplish *and* what the tooling and FPGA you’re using can provide.

Why do more integration work than you have to when you can focus on the 
interesting stuff?

  -- Chris

Re: (V)HDL Toolsets

[Chris Hanson via cctalk]

On May 21, 2020, at 8:46 AM, Jay Jaeger via cctalk  
wrote:
> 
> Helpful tips - I agree with avoiding vendor extensions.  Thanks.

I’d strongly suggest that the situation with FPGAs & HDLs requires a bit more 
nuance than that. You *should* probably avoid or carefully isolate vendor 
*language extensions*. However, you *should not* avoid vendor *IP blocks*.

As an example, let’s say you have a design that needs a RAM controller. Do you:

(1) Write your own DDR controller as part of your design; or,

(2) Interface your design to your FPGA vendor’s DDR controller IP block?

In general you *should* do the latter—as long as you can do so via a sane 
abstraction—rather than the former, unless you have an extremely compelling 
case for doing the former.

And “portability” isn’t actually that compelling of a case: Virtually every set 
of tools and chips you might want to work with will have a similar variety of 
IP blocks available, many implemented via dedicated on-device logic (rather 
than consuming general-purpose logic cells), so as long as you can isolate 
their use you can still keep your overall design portable.

This is particularly important for things that have strict timing requirements 
and that might otherwise soak up a lot of your device’s bandwidth, e.g. HDMI 
input/output, RAM control, Ethernet, and so on.

  -- Chris

Re: Any fun SunWindows/SunView stuff?

[Chris Hanson via cctalk]

On Mar 9, 2020, at 2:26 PM, Jason T via cctalk  wrote:
> 
> On Mon, Mar 9, 2020 at 2:19 PM Chris Hanson via cctalk
>  wrote:
> 
>> Were there any fun SunView applications or hacks back in the day?
>> 
>> Other than the demos, the only stuff I currently have is emacstool (built as 
>> part of emacs 18.59) and the PLATO client (which I haven’t actually built 
>> yet). I know I can read through the comp.sources.unix archives but I figure 
>> maybe some folks might remember things to look for.
> 
> You're not fully experiencing SunOS if you're not running Pizzatool.


Wasn’t that for NeWS? :)

Which isn’t to say I won’t run it! Maybe if I can find the source I’ll hack it 
to be usable with the pizza place across the street from my home…

  -- Chris

Re: HPE OpenVMS Hobbyist license program is closing

[Chris Hanson via cctalk]

On Mar 9, 2020, at 1:01 PM, Bill Gunshannon via cctalk  
wrote:
> 
> On 3/9/20 1:33 PM, John H. Reinhardt via cctalk wrote:
>> On 3/9/2020 12:20 PM, Eric Smith wrote:
>>> On Sat, Mar 7, 2020 at 4:32 PM John H. Reinhardt via cctalk 
>>> mailto:cctalk@classiccmp.org>> wrote:
>>> 
>>> I would think that those that already have legal VAX PAKs/licenses 
>>> could still run them. It's just no *NEW* PAKs could be legally generated.
>>> 
>>> 
>>> The hobby PAKs _and_ the licenses have a one-year expiration.
>> As a Hobbyist license holder since 2004 I am well aware.  The language Bill 
>> used implied that no one would be able to legally run OpenVMS on a VAX.  I 
>> was saying that those who had bought licenses previously (implying 
>> commercial and other entities) should still be legal in running VAX OpenVMS 
>> even after HPE shuts down their OpenVMS activities.  Bill may have been 
>> intending just the Hobbyist (and educational licenses, too) but the language 
>> was ambiguous.
> 
> Actually, as long as they can live with incorrect time Hobbyists
> could use that last set of PAKs forever.

That’s from a technical perspective, from a legal perspective their license 
expired.

  -- Chris

Any fun SunWindows/SunView stuff?

[Chris Hanson via cctalk]

I have my Sun-4/110C set up and running SunOS 4.1.4.

Were there any fun SunView applications or hacks back in the day?

Other than the demos, the only stuff I currently have is emacstool (built as 
part of emacs 18.59) and the PLATO client (which I haven’t actually built yet). 
I know I can read through the comp.sources.unix archives but I figure maybe 
some folks might remember things to look for.

  -- Chris

Mach

[Chris Hanson via cctalk]

On Jan 5, 2020, at 2:30 PM, Guy Sotomayor via cctalk  
wrote:
> 
> It did seem for a while that a lot of things were based on Mach, but
>> 
>> very few seemed to make it to market. NeXTstep and OSF/1, the only
>> version of which to ship AFAIK was DEC OSF/1 AXP, later Digital UNIX,
>> later Tru64.
> 
> Yes, a lot of things were based on Mach. One OS that you're forgetting
> is OS X. That is based upon Mach 2.5.

Nope, Mac OS X 10.0 was significantly upgraded and based on Mach 4 and BSD 4.4 
content (via FreeBSD among other sources). It was NeXT that never got beyond 
Mach 2.5 and BSD 4.2. (I know, distinction without a difference, but this is an 
issue of historicity.)

I think only some of the changes from Mach 2.5→3→4 made it into Mac OS X Server 
1.0 (aka Rhapsody) so maybe that’s what you’re remembering.

>> MkLinux didn't get very far, either, did it?
>> 
> 
> I think that was the original Linux port for PPC.

It was the original Linux port for NuBus PowerPC Macs at least. It was never 
really intended to “get very far” in the first place, it was more of an 
experimental system that a few people at Apple threw together and managed to 
allow the release of to the public.

MkLinux was interesting for two reasons: It documented the NuBus PowerMac 
hardware such that others could port their OSes to it, and it enabled some 
direct performance comparisons of things like running the kernel in a Mach task 
versus running it colocated with the microkernel (and thus turning all of its 
IPCs into function calls). Turns out running the kernel as an independent Mach 
task cost 10-15% overhead, which was significant on a system with a clock under 
100MHz. Keep in mind too that this was in the early Linux 2.x days where Linux 
“threads” were implemented via fork()…

I don’t recall if anyone ever did any “multi-server” experiments with it like 
were done at CMU, where the monolithic kernel were broken up into multiple 
cooperating tasks by responsibility. It would have been interesting to see 
whether the overhead stayed relatively constant, grew, or shrank, and how 
division of responsibility affected that.

  — Chris

OpenStep Solaris

[Chris Hanson via cctalk]

On Jan 5, 2020, at 7:02 AM, Liam Proven via cctalk  
wrote:

> Sun *did* do a full port of OpenStep to Solaris, but while I know
> people who saw it, I am not sure if it got a full commercial release.

Not quite! Sun was a participant in creating the OpenStep standard (the NS 
class prefix stands for “NeXT/Sun”) and *created their own implementation* of 
OpenStep for Solaris. (Just as GNUstep is an independent implementation of the 
OpenStep spec under the FSF umbrella, and OPENSTEP/Mach and OPENSTEP/Enterprise 
were NeXT’s implementations.)

OpenStep Solaris was released, both the user and developer environment, and you 
should be able to find them today and install them on Solaris 2.5 or later. I 
think OpenStep will run on everything through Solaris 7 or Solaris 8, but at 
some point it stopped working because it required Display PostScript in the 
window server.

> Sun also bought a number of NeXTstep software houses, including
> Lighthouse, but didn't release the code.

Indeed, that was post-OpenStep; they weren’t buying companies like Lighthouse 
to get a suite of applications for OpenStep Solaris, they were buying them to 
port their stuff to Java (since Java was based rather heavily on Objective-C, 
and some aspects of the Java frameworks’ designs on OpenStep).

  — Chris

Taligent

[Chris Hanson via cctalk]

On Jan 5, 2020, at 12:56 AM, Jeffrey S. Worley via cctalk 
 wrote:

> Does Talingent Pink sound familiar?  OS/2 was ported to powerPC, and so
> was Netware iirc.  The field was quite busy with hopeful Microsoft
> killers.  OS/2 was to be morphed into a cross-platform o/s, to wean
> folks from dos/x86. Then PPC kills the x86 and we all get a decent
> os.  That was the plan anyway.   I never saw OS2 for PPC or Netware for
> OS/2, thought I know both to have shipped.

Pink was the C++ operating system project at Apple that became Taligent. I know 
a couple of people who did a developer kitchen for Pink pre-Taligent, and I 
also know a number of folks who worked on the Taligent system and tools—and 
have personally seen a demo of the Taligent Application Environment running on 
AIX.

I’ve even seen a CD set for Taligent Application Environment (TalAE) 1.0 on 
AIX, and I have a beta developer and user documentation set. Unfortunately my 
understanding is that the CD sets given to employees to commemorate shipping 
TalAE were all *blank*—the rumor I’ve heard is that IBM considered it too 
valuable to give them the actual software that they had worked for years on. 
(Maybe there were tax implications because of what IBM valued the license at, 
and the fact that it would have to be considered compensation?)

Taligent itself was only one component of IBM’s Workplace/OS strategy, which 
was a plan to rebase everything atop Mach so you could run AIX and OS/2 and 
Taligent all at once on the same hardware without quite using virtual machines 
for it all. The idea is that Apple would do pretty much the same with Copland 
and Taligent atop NuKernel rather than Mach.

It would be really great to actually get the shipping Taligent environment and 
tools archived somewhere. While only bits and pieces of it are still in use—for 
example, ICU—a lot of important and influential work was done as part of the 
project. For example, the design of most of the unit testing frameworks today 
actually comes from *Taligent*, since Kent Beck wrote SUnit to re-create it in 
Smalltalk, and JUnit and OCUnit were based on SUnit’s design and everything 
else derived from JUnit…

  — Chris

Re: IBM RS/6000 Model 320 (7012-320) SCSI cabling

[Chris Hanson via cctalk]

On Jan 3, 2020, at 10:31 PM, Glen Slick via cctalk  
wrote:
> 
> I don't have any internal SCSI cables left from those systems. I do
> still have a 70F9733 5-foot external SCSI cable that has the weird
> 60-pin connector on the system end, and the weird pass-thru normal
> 50-pin connector on the device end. I haven't had any use for that
> 70F9733 SCSI cable since I got rid of those systems.
> 
> The device end is weird because it could plug into the deep recessed
> connector on the external SCSI tape or CD-ROM drive, which only had a
> single connector, and then either a terminator or another cable could
> be chained onto the second pass-thru connector on the cable device end
> plug.

That sounds like exactly what I need! Would you be willing to part with it? For 
how much? :)

  — Chris (in Campbell, CA, USA)

IBM RS/6000 Model 320 (7012-320) SCSI cabling

[Chris Hanson via cctalk]

Does anyone have a spare internal or external SCSI cable for the IBM RS/6000 
Model 320 with the IBM MCA SCSI-1 card (3-1)? For those who don’t 
know/remember, this card uses a pair of edge connectors (like MFM/ESDI) rather 
than an IDC connector to connect to its internal two-drop cable, and its 
external connector is a **sixty-pin** higher-density Centronics connector.

I can make an IDC cable adapter pretty easily but if anyone knows where to 
acquire working original cables, that’d be preferable to my relative lack of 
mechanical skill.

  -- Chris

IBM RS/6000 Model 320 (7012-320) and AIX 3.2.5

[Chris Hanson via cctalk]

I have an IBM RS/6000 POWERstation 320 (original 7012-320) with plenty of RAM 
and SCSI storage. I’d like to install AIX 3.2.5 on it.

Here’s the hardware setup:

- POWERstation 320
  - 8MB RAM currently, soon to be 72MB
- Serial port adapter so I can use a terminal
- Correct IBM keyboard (not working at the moment, hence the terminal)
- Correct IBM mouse
- MCA Color Display Adapter (1-1)
- MCA Ethernet Adapter (2-1)
- MCA SCSI-1 Adapter (4-1)
- AIX 3.2.0 floppy images, including boot floppy images
- AIX 3.2.5 CD-ROM images
- External SCSI DAT (DDS-1) and CD-ROM drives

The CD images appear to be ISO-9660 format, containing piles of “AIX 
backup/restore format file” archives; the floppy images are also identified as 
being that format (no filesystems, just archive content). I’ve seen some stuff 
online that talks about installing from tape using DAT, so it seems like in 
theory I should be able to just push the CD contents to a tape and go.

Can I use the 3.2.0 boot floppy images with a couple of DDS-1 tapes containing 
the files from the 3.2.5 CDs to directly install AIX 3.2.5? In what order 
should the files be put on the tapes? Or do I really need to do a complete 
install of 3.2.0 first?

Another important question: Will I need some sort of key to use the included 
AIXwindows and xlc, or should this stuff just work?

Finally, is there a complete set of post-release patches for AIX 3.2.5 online 
somewhere? I know 3.2.5 itself was primarily a patch roll-up release, I assume 
that with Y2K remediation and other bug fixes in the mid- and late-2000s there 
were a few additional patches released over time.

  -- Chris

Re: Vigra MMI-210 (VME DSP/audio card) documentation?

[Chris Hanson via cctalk]

On Oct 24, 2019, at 10:30 AM, Ethan O'Toole  wrote:
> 
>> I just acquired a Vigra MMI-210 VME DSP/audio card that I’d like to get 
>> working. Does anyone happen to have manuals or know where I could find them? 
>> The Wayback Machine at the Internet Archive provides some Anyone have a 
>> source for more information, or another place to dig for it?
> 
> SGI sold one model of these as their audio option for SGI Onyx and Challenge 
> series I believe? If it's similar enough maybe there is documentation from 
> that?

Yeah, the docs I’ve found say the MMI-110 was sold for the Onyx as Vigrasound 
and used extensively in Discreet Logic installations.

There’s a whole huge chain of acquisitions Vigra went through though (Visicom, 
Titan, L3, Harris) and I fear this information was lost. There are *a lot* of 
jumpers on this card, it’s pretty oldschool VME.

  -- Chris

Vigra MMI-210 (VME DSP/audio card) documentation?

[Chris Hanson via cctalk]

I just acquired a Vigra MMI-210 VME DSP/audio card that I’d like to get 
working. Does anyone happen to have manuals or know where I could find them?

The Wayback Machine at the Internet Archive provides some programming 
information 

 so if I can configure the card, I can make it do things.

Unfortunately I have yet to find an installation guide. Since it’s a VME card, 
it has plenty of jumpers that will need to be properly set before it’ll 
actually work.

Anyone have a source for more information, or another place to dig for it?

  -- Chris

Re: Data General AViiON AV300D docs?

[Chris Hanson via cctalk]

One thing I’ve done is dump the ROMs in my two AV300D. They’re identical except 
for the last 4 bytes, which I suspect is where their host/Ethernet ID comes 
from.

Unfortunately while the ROM is a JEDEC 1Mbit part, my dump doesn’t look 
coherent, in that there’s no simple ASCII text like appears at boot, and the 
contents at 0 are not proper 88100 instructions. I expect Data General didn’t 
use D[7-0] on the ROM as D[7-0] — and may not have used A[16-0] as A[16-0] 
either. And since my systems have bum power supplies, I can’t boot them and 
dump the ROMs that way.

Anyone have a running AV300 or AV400 system from which you could dump the ROM 
via SCM (the boot monitor)? Then I could compare it with my dump and figure out 
how it’s wired up.

If anyone likes puzzles, here are the last 8 bytes of each system’s ROM:

$ tail -n 1 AV300-10794-01-1AFB.hex 
0001fff0:     7184 f4a2 04fb 67fe

$ tail -n 1 AV300-10794-01-3163.hex 
0001fff0:     7184 f4a2 9cfa f7fc

The ROMs were labeled 1AFB and 3163 respectively. If anyone can see a coherent 
mapping in that, I’d be quite happy. :)

  — Chris

Re: HP vintage boards being sold as scrap

[Chris Hanson via cctalk]

On Sep 26, 2019, at 7:24 AM, Patrick Finnegan via cctalk 
 wrote:
> 
> 3. Just because you have different opinions doesn't mean their ways are
> wrong. Hell, they even seem to be willing to work with people interested in
> single boards. I'm sure they're putting "GOLD!!!" in the title for
> advertising's sake. It seems to have worked just fine for advertising here
> ..
> 
> 4. Maybe just quit whining? If you can't get what you want where you are,
> to quote the immortal words of Dave McGuire, "Time to move!”


Destroying something that’s useful in the name of a quick buck is wrong.

  -- Chris

Re: Data General AViiON AV300D docs?

[Chris Hanson via cctalk]

Thank you! 

  -- Chris

> On Sep 24, 2019, at 7:32 AM, alan--- via cctalk  wrote:
> 
> 
> I mean to add, that view is looking through the machine not the connector.  
> So with the PSU oriented in it's natural position, that is the pinout of the 
> solder pin tails coming up through the PSU PCB or the face of the connector 
> on the main board.
> 
> Also I never scoped the control pins to figure out their roles.  The board 
> and mounting hole dimensions are in the Eagle files.
> 
> -Alan
> 
> On 2019-09-24 10:27, alan--- via cctalk wrote:
>> I stuck the files up here for the next few weeks as I don't have a
>> project page for it yet:
>> https://www.retrotronics.org/tmp/dgpsu
>> Hope this helps.
>> On 2019-09-24 01:39, Chris Hanson wrote:
>>> I’ve seen that datageneral.uk at least has a pinout for an Eclipse MV
>>> SCSI port, which hypothetically might match the AViiON DB-50 SCSI.
>>> In the absence of real docs though, who can say?
>>> Can you post the AViiON AV300D power supply pinout you’ve figured out?
>>> Maybe I can power on my system with a couple bench supplies or an ATX
>>> supply...
>>>  — Chris

Re: Data General AViiON AV300D docs?

[Chris Hanson via cctalk]

I’ve seen that datageneral.uk at least has a pinout for an Eclipse MV SCSI 
port, which hypothetically might match the AViiON DB-50 SCSI.

In the absence of real docs though, who can say?

Can you post the AViiON AV300D power supply pinout you’ve figured out? Maybe I 
can power on my system with a couple bench supplies or an ATX supply...

  — Chris

Data General AViiON AV300D docs?

[Chris Hanson via cctalk]

Does anyone have AViiON AV300D or related docs? I got a pair that have bum 
power supplies and I’m hoping to find something that will makes servicing them 
easier.

After I get them running, I’ll obviously be looking for software. And a pinout 
for their unique SCSI port, though I hear they can netboot; any details about 
that would be useful too.

  — Chris

Sent from my iPhone

Re: Pinout for current loop interface

[Chris Hanson via cctalk]

On Aug 17, 2019, at 9:14 AM, Charles via cctalk  wrote:

> I just hate having to make a custom cable for every terminal and computer I
> own or work with ;)

Ah, but isn’t doing what so many before you have had to part of the charm? :)

  -- Chris