Re: Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Chuck Guzis via cctalk]

On 01/18/2018 06:18 PM, Fred Cisin via cctalk wrote:

> A few SCSI floppy drives existed, but they were never very common.
> Only SCSI floppy that I remember having was a "Floptical" (20MB), that
> also handled 1.4M

Most "real" SCSI drives were basically bolt-on adapter affairs to a
traditional floppy interface.   You can, for example, occasionally find
Teac FD235S drives for sale--and if you look, it's basically a
SCSI-to-floppy adapter bolted onto a regular FD235.

There were also some SMS/OMTI cards that served the same
purpose--floopy-to-SCSI.

--Chuck

Re: Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Richard Cini via cctalk]

For that card, no drivers are needed for the hard drives. The 
on-board ROM is an Int13 wedge.
Regarding using any other devices like a ZIP drive, CD or a floptical, not sure 
if those need drivers. ZIP definitely needed a DOS driver. The CD did as well 
(In both config.sys and autoexec) but the ROM may have CDROM extensions already 
to enable booting from CD. Never tried it with that card though. 



Get Outlook for iOS






On Thu, Jan 18, 2018 at 9:27 PM -0500, "Jason T via cctalk" 
 wrote:










On Thu, Jan 18, 2018 at 7:55 PM, Richard Cini  wrote:
> I use this card as a floppy/disk controller in a PC/AT that's used solely for 
> imaging. The controller is connected to two Seagate ST-2502N (442MB) hard 
> drives running MS-DOS 6.22. Works like a champ. Cables are readily available 
> on eBay but since they're regular 50-pin IDC connectors, you can DIY if 
> needed -- connectors are readily available.

Do you have (and can you post) the MS-DOS drivers for that card?  I
also run one in my floppy imager machine, which dual-boots btw. MS-DOS
and some later Linux.  Having SCSI for at least one of the OSes would
be nice.

I could also switch the other partition over to FreeBSD, as Warner L suggested.

Re: Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Jason T via cctalk]

On Thu, Jan 18, 2018 at 8:18 PM, Fred Cisin via cctalk
 wrote:
> Or, are you suggesting putting together an imaging machine that also handles
> HDD, CD-ROM, some tape cartridges, etc.?

Correct.  Two key components in short supply when you have 11
classiccmp projects are space and motivation, so if I can dd an old
hard drive/Jaz cart/etc from the same machine where I'm reading in
floppies, all the better.

Re: Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Jason T via cctalk]

On Thu, Jan 18, 2018 at 7:55 PM, Richard Cini  wrote:
> I use this card as a floppy/disk controller in a PC/AT that's used solely for 
> imaging. The controller is connected to two Seagate ST-2502N (442MB) hard 
> drives running MS-DOS 6.22. Works like a champ. Cables are readily available 
> on eBay but since they're regular 50-pin IDC connectors, you can DIY if 
> needed -- connectors are readily available.

Do you have (and can you post) the MS-DOS drivers for that card?  I
also run one in my floppy imager machine, which dual-boots btw. MS-DOS
and some later Linux.  Having SCSI for at least one of the OSes would
be nice.

I could also switch the other partition over to FreeBSD, as Warner L suggested.

Re: Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Fred Cisin via cctalk]

On Thu, 18 Jan 2018, Jason T via cctalk wrote:

Has anyone using one of these cards made use of the SCSI function?  It
has a Centronics 50 connector, which isn't terribly useful unless
you've got the right cable, but if you're building an all-in-one
imaging machine, it might be handy to have SCSI capability as well.
It seems the driver hasn't been in Linux for quite a few versions.
Not sure about the BSDs.


A few SCSI floppy drives existed, but they were never very common.
Only SCSI floppy that I remember having was a "Floptical" (20MB), that 
also handled 1.4M


Or, are you suggesting putting together an imaging machine that also 
handles HDD, CD-ROM, some tape cartridges, etc.?

Re: Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Warner Losh via cctalk]

On Jan 18, 2018 6:44 PM, "Jason T via cctalk"  wrote:

On Thu, Jan 18, 2018 at 6:58 PM, Adrian Graham via cctalk
 wrote:
> I could, but I guess by the time I’ve sourced a replacement I might as
well have bought an AHA-1522A instead, I have a couple of scouts out
looking for them as we speak :) The 1522A is a full pass for TESTFDC.

Has anyone using one of these cards made use of the SCSI function?  It
has a Centronics 50 connector, which isn't terribly useful unless
you've got the right cable, but if you're building an all-in-one
imaging machine, it might be handy to have SCSI capability as well.
It seems the driver hasn't been in Linux for quite a few versions.
Not sure about the BSDs.


FreeBSD supports it with the aic driver.

Warner

Re: Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Richard Cini via cctalk]

I use this card as a floppy/disk controller in a PC/AT that's used solely for 
imaging. The controller is connected to two Seagate ST-2502N (442MB) hard 
drives running MS-DOS 6.22. Works like a champ. Cables are readily available on 
eBay but since they're regular 50-pin IDC connectors, you can DIY if needed -- 
connectors are readily available.


Rich
 
--
Rich Cini
http://www.classiccmp.org/cini
http://www.classiccmp.org/altair32
 

On 1/18/18, 8:44 PM, "cctalk on behalf of Jason T via cctalk" 
 wrote:

On Thu, Jan 18, 2018 at 6:58 PM, Adrian Graham via cctalk
 wrote:
> I could, but I guess by the time I’ve sourced a replacement I might as 
well have bought an AHA-1522A instead, I have a couple of scouts out looking 
for them as we speak :) The 1522A is a full pass for TESTFDC.

Has anyone using one of these cards made use of the SCSI function?  It
has a Centronics 50 connector, which isn't terribly useful unless
you've got the right cable, but if you're building an all-in-one
imaging machine, it might be handy to have SCSI capability as well.
It seems the driver hasn't been in Linux for quite a few versions.
Not sure about the BSDs.

Adaptec 1522A SCSI Support (was re: New TestFDC Results Registry)

[Jason T via cctalk]

On Thu, Jan 18, 2018 at 6:58 PM, Adrian Graham via cctalk
 wrote:
> I could, but I guess by the time I’ve sourced a replacement I might as well 
> have bought an AHA-1522A instead, I have a couple of scouts out looking for 
> them as we speak :) The 1522A is a full pass for TESTFDC.

Has anyone using one of these cards made use of the SCSI function?  It
has a Centronics 50 connector, which isn't terribly useful unless
you've got the right cable, but if you're building an all-in-one
imaging machine, it might be handy to have SCSI capability as well.
It seems the driver hasn't been in Linux for quite a few versions.
Not sure about the BSDs.

Re: New TestFDC Results Registry

[Adrian Graham via cctalk]

>> manipulate SSSD images then tonight I read a message on VCFED from
>> our own Chuck Guzis saying there were two controller chips in the
>> 1542CF (national and broken Intel) and I discovered I had a broken
>> Intel one.
>> 
>> I may have cussed.
> 
> Perhaps all is not lost.  I'd have to go and look at my 1542CF, but I
> believe that I discovered that it uses either the Intel 82077 or the
> National PC8477 chip.

Yep, and that Intel broke the SSSD part of the FDC by adding tape support to 
the card.

> That being the case, if you're handy, you can simply replace the Intel
> chip with the National one.  They're pretty much pin-compatible (the NSC
> one requires a couple fewer external components).

I could, but I guess by the time I’ve sourced a replacement I might as well 
have bought an AHA-1522A instead, I have a couple of scouts out looking for 
them as we speak :) The 1522A is a full pass for TESTFDC.

> 
> There are many other SCSI controllers that have decent FDCs.  I've had
> good luck with Ultrastor and Future Domain cards, for example.

I noticed a couple of boards on the list that I might’ve gone past in the 
‘spare old boards’ box at work earlier and discounted because they were too 
‘new’, an Asus one and Aopen one which are both Athlon based. They both do SSSD 
so it’s also an avenue worth pursuing.

Cheers!

—
Adrian/Witchy
Binary Dinosaurs - Celebrating Computing History from 1972 onwards
w: binarydinosaurs.co.uk t: @binarydinosaurs
f: facebook.com/binarydinosaurs

Re: New TestFDC Results Registry

[Chuck Guzis via cctalk]

On 01/18/2018 12:46 PM, Adrian Graham via cctalk wrote:

> Gh, talk about the wrong timing for this XD. I say this because I
> just bought an AHA-1524CF on various folk’s recommendations (not from
> here) a couple of weeks ago only to find I still couldn’t really
> manipulate SSSD images then tonight I read a message on VCFED from
> our own Chuck Guzis saying there were two controller chips in the
> 1542CF (national and broken Intel) and I discovered I had a broken
> Intel one.
> 
> I may have cussed.

Perhaps all is not lost.  I'd have to go and look at my 1542CF, but I
believe that I discovered that it uses either the Intel 82077 or the
National PC8477 chip.

That being the case, if you're handy, you can simply replace the Intel
chip with the National one.  They're pretty much pin-compatible (the NSC
one requires a couple fewer external components).

There are many other SCSI controllers that have decent FDCs.  I've had
good luck with Ultrastor and Future Domain cards, for example.

--Chuck

Re: New TestFDC Results Registry

[Chuck Guzis via cctalk]

On 01/18/2018 01:57 PM, william degnan wrote:
> Please, call me Bill :-)
> I have a system with a Catweasel and a connection to the motherboard,  I
> am unsure how I have it set up as it has been many years since I opened
> the box.    I have to see what I am doing in there.  It's a dual-boot
> system that goes into either Win 2000 or DOS 6.22, but I forget how the
> catweasel is hooked up and wither I use it with image disk or not.  

Okay, so who was it on this list wanted to be called Will?   At any
rate, Bill,  I'll file that away for future reference.

I really doubt that IMD will do anything with the CW MK4.

Another rule of thumb is that if a motherboard is post-P4 and lacks a
parallel port, it's unlikely that it'll give any useful results with
TESTFDC.   I think the floppy facility was included mostly for
high-density *read* compatibility.

I've had some decent results with P4 and Socket 939 motherboards but
after that, not so much.  I don't know if that's a bright-line rule, but
it seems to hold with my gear.

--Chuck

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 18, 2018, at 9:39, Grant Taylor via cctalk  
> wrote:
> 
> On 01/17/2018 11:33 AM, Noel Chiappa via cctalk wrote:
>> E.g. it probably only supports class A addresses, for instance, which is 
>> going to influence the code for picking the first-hop router.
> 
> I was not aware that there was code that supported /only/ Class A (/8) 
> addresses and /not/ Class B (/16) or Class C (/24) addresses.
> 
> I /thought/ that everything was either classful (as in supports all three 
> classes: A, B, and C) or classless (as in supports CIDR).
> 
> Is my networking history missing something else?

In the course of this discussion I have been reminded that BBN did a TCP/IP for 
the HP3000 that ran under MPE IV. It is described in IEN 167 and if you read 
that carefully you will realize that they got started on MPE III; MPE message 
files (think record-structured pipes) first appeared in late MPE III but were 
not documented until MPE IV.

Trawling the Intertubes for, well, anything about this I turned up a sort of 
progress report.



It begins on page 66 of 81, on page 68 of 81 it describes changes to the 
routing table.  "Currently, this table has one entry for each of the possible 
256 networks, and accesses are very fast." and I'll just leave you with that.

-Frank McConnell

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 18, 2018, at 9:27, Grant Taylor via cctalk  
> wrote:
> 
> On 01/17/2018 01:12 PM, Frank McConnell via cctalk wrote:
>> So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09 
>> (V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is late 
>> enough for it to be able to do IP over Ethernet (vs. V-delta-4 and before 
>> which could only do IEEE over 802.3).  And it has an FTP client.
> 
> Please clarify what you mean by "IP over Ethernet", specifically what frame 
> type?
> 
> Are you talking about Ethernet II frames?

What I meant to write in that latter part was "IP over IEEE 802.3".  HP's LAN 
business started out big on big-S Standards, as in an IEEE Standard was 
preferred over a document circulated by three other computer companies.  That 
document would be Ethernet II.  So HP's initial attempts at TCP/IP were done 
with IEEE 802.2 framing and SAP 6, and used HP’s Probe protocol for local 
address discovery.  And TCP/IP was done as a stopgap, the stated plan was to 
support the OSI stack when it was ready.

HP did eventually (by the end of the 1980s) come to grasp that the customers 
really wanted Ethernet (II) so they could at least ping the 3000 to see if it 
was up.  Support for that (and ARP) arrived in the version of NS Transport for 
MPE V/E V-delta-5.

>> So you might think I'd be able to move files between it and a modern FreeBSD 
>> box, right?  I mean, it's all just Ethernet, right?
> 
> Ethernet != Ethernet

OK, "IP over Ethernet II".  But most folks these days won’t be thinking about 
the other kinds.  Maybe even most folks on this list.

> I'm wondering if it might be possible to use an old NetWare 4.x / 5.x box as 
> a router to convert from one Ethernet frame type to another Ethernet frame 
> type.  I.e. from IP over Ethernet II frames to IP over 802.3 frames.

If you want something that was correct for the period, use a Cisco AGS router.  
(I think later Cisco routers will do too.)  It can do the routing and can also 
proxy HP’s Probe address-resolution protocol.

The Wollongong Group had a software routing product, WIN/ROUTE, and they worked 
it over a bit to make another product WIN/ROUTE2 which could do the 
802.3/Ethernet routing.  Can't remember whether it required 3C503 cards.

> I actually don't know if Linux can do this or not.  My typical go to tool 
> might not help here.  :-/
> 
>> Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport") 
>> in V-delta-9 and before, such that it tears down the connection with a 
>> failure if a packet is received with IP type-of-service not zero. And the 
>> FreeBSD FTP server sets a socket option that gets FreeBSD to send that sort 
>> of packet.
>> At a previous employer, I went round with HP a bit on behalf of a mutual 
>> customer and got HP to issue a patch for NS Transport that corrects this 
>> behavior on the MPE side.  Clearly, I don't have that patch on this system.
> 
> I think we all have experiences like that.  Some sort of custom code that we 
> didn't care about at the time (beyond fixing the problem) that we would now 
> like to get our hands on years later.

Upgrading to MPE Release 40 FOS with Platform 3P SUBSYS would do; the patch did 
make it into later releases of NS Transport (which would be on the SUBSYS tape).

>> FreeBSD is FreeBSD, and I can build its FTP server from source and change it 
>> so it works in this situation; but I think this should give y'all some idea 
>> of the hilarity that can ensue when you exhume a 1980s TCP/IP and put it on 
>> your network.
> 
> I wonder if there are other tricks that can be used to work around this 
> without needing to recompile services.  I.e. use IPTables (or FreeBSD's 
> counterpart that I don't know the name of) to change the type-of-service to 
> something other than 0.

Been a while since I did that sort of thing but it was with ipfw, a divert 
socket, and a program to modify the diverted packets and hand them back down to 
the kernel.

Really, commenting out the setsockopt() call in ftpd seemed the easiest thing 
to do at the time, but I’d need to do it over now and might go for this sort of 
approach.

> Here's a link with a lot of gory details on NetWare's support of multiple 
> Ethernet frame types.
> 
> Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
> - https://support.novell.com/techcenter/articles/ana19930905.html
> 
> Here are the four frame types that NetWare supports:
> 
> - Ethernet II
>- I think this is what we are using for just about everything today.
> - IEEE 802.3 "raw"
>- I'm speculating that this is the frame type that Frank is referring to 
> above.
> - IEEE 802.3 with 802.2
> - IEEE 802.3 with 802.2 SNAP
> 
> I /think/ that NetWare can bind IP to all four Ethernet frame types. 
> Hopefully one of them is compatible with V-delta-4 and before.

If it can, I think you want the "IEEE 802.3 with 802.2" on the HP side, and the 
"Ethernet II" on the 

Re: New TestFDC Results Registry

[william degnan via cctalk]

Please, call me Bill :-)
I have a system with a Catweasel and a connection to the motherboard,  I am
unsure how I have it set up as it has been many years since I opened the
box.I have to see what I am doing in there.  It's a dual-boot system
that goes into either Win 2000 or DOS 6.22, but I forget how the catweasel
is hooked up and wither I use it with image disk or not.
Bill

On Thu, Jan 18, 2018 at 4:36 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> Will, I wasn't aware the CW MK4+ had a legacy floppy controller on it
> (i.e. ports 3fx, DMA 2, IRQ 6 setup with NEC 765 command set).  The CWs
> that I have (a MK3 and a MK1) are all sui generis devices not supported
> by off-the-shelf software.  In particularly, I don't think they'll work
> with, say, IMD, or AnaDisk.
>
> --Chuck
>
>
> On 01/18/2018 01:17 PM, william degnan via cctalk wrote:
> > Does someone have results for the Siliconsonic / Individual computers
> > Catweasel MK4 plus?  IF not I will put that on my list of to-do's.
> >
> > I added a link to this onto my web site in the links section and the
> > archiving info thread.
> >
> > Bill
> >
> > On Thu, Jan 18, 2018 at 3:46 PM, Adrian Graham via cctalk <
> > cctalk@classiccmp.org> wrote:
> >
> >>
> >>> On 18 Jan 2018, at 15:46, systems_glitch via cctalk <
> >> cctalk@classiccmp.org> wrote:
> >>>
> >>> I'd been trying to reach Dave Dunfield with new TestFDC results since
> >>> apparently August with no results. So, I wrote a new TestFDC registry
> >> into
> >>> my site:
> >>>
> >>> https://services.theglitchworks.net/ng/testfdc_results
> >>
> >> Gh, talk about the wrong timing for this XD. I say this because I
> just
> >> bought an AHA-1524CF on various folk’s recommendations (not from here) a
> >> couple of weeks ago only to find I still couldn’t really manipulate SSSD
> >> images then tonight I read a message on VCFED from our own Chuck Guzis
> >> saying there were two controller chips in the 1542CF (national and
> broken
> >> Intel) and I discovered I had a broken Intel one.
> >>
> >> I may have cussed.
> >>
> >> Typically all the AHA-1522s are in the US, sigh.
> >>
> >> Cheers,
> >>
> >> —
> >> Adrian/Witchy
> >> Binary Dinosaurs - Celebrating Computing History from 1972 onwards
> >> w: binarydinosaurs.co.uk t: @binarydinosaurs
> >> f: facebook.com/binarydinosaurs
> >>
> >>
> >
>
>
> --
> --Chuck
>
> Sent from my digital computer
>

Re: New TestFDC Results Registry

[Chuck Guzis via cctalk]

Will, I wasn't aware the CW MK4+ had a legacy floppy controller on it
(i.e. ports 3fx, DMA 2, IRQ 6 setup with NEC 765 command set).  The CWs
that I have (a MK3 and a MK1) are all sui generis devices not supported
by off-the-shelf software.  In particularly, I don't think they'll work
with, say, IMD, or AnaDisk.

--Chuck


On 01/18/2018 01:17 PM, william degnan via cctalk wrote:
> Does someone have results for the Siliconsonic / Individual computers
> Catweasel MK4 plus?  IF not I will put that on my list of to-do's.
> 
> I added a link to this onto my web site in the links section and the
> archiving info thread.
> 
> Bill
> 
> On Thu, Jan 18, 2018 at 3:46 PM, Adrian Graham via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>>
>>> On 18 Jan 2018, at 15:46, systems_glitch via cctalk <
>> cctalk@classiccmp.org> wrote:
>>>
>>> I'd been trying to reach Dave Dunfield with new TestFDC results since
>>> apparently August with no results. So, I wrote a new TestFDC registry
>> into
>>> my site:
>>>
>>> https://services.theglitchworks.net/ng/testfdc_results
>>
>> Gh, talk about the wrong timing for this XD. I say this because I just
>> bought an AHA-1524CF on various folk’s recommendations (not from here) a
>> couple of weeks ago only to find I still couldn’t really manipulate SSSD
>> images then tonight I read a message on VCFED from our own Chuck Guzis
>> saying there were two controller chips in the 1542CF (national and broken
>> Intel) and I discovered I had a broken Intel one.
>>
>> I may have cussed.
>>
>> Typically all the AHA-1522s are in the US, sigh.
>>
>> Cheers,
>>
>> —
>> Adrian/Witchy
>> Binary Dinosaurs - Celebrating Computing History from 1972 onwards
>> w: binarydinosaurs.co.uk t: @binarydinosaurs
>> f: facebook.com/binarydinosaurs
>>
>>
> 


-- 
--Chuck

Sent from my digital computer

Re: New TestFDC Results Registry

[william degnan via cctalk]

Does someone have results for the Siliconsonic / Individual computers
Catweasel MK4 plus?  IF not I will put that on my list of to-do's.

I added a link to this onto my web site in the links section and the
archiving info thread.

Bill

On Thu, Jan 18, 2018 at 3:46 PM, Adrian Graham via cctalk <
cctalk@classiccmp.org> wrote:

>
> > On 18 Jan 2018, at 15:46, systems_glitch via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > I'd been trying to reach Dave Dunfield with new TestFDC results since
> > apparently August with no results. So, I wrote a new TestFDC registry
> into
> > my site:
> >
> > https://services.theglitchworks.net/ng/testfdc_results
>
> Gh, talk about the wrong timing for this XD. I say this because I just
> bought an AHA-1524CF on various folk’s recommendations (not from here) a
> couple of weeks ago only to find I still couldn’t really manipulate SSSD
> images then tonight I read a message on VCFED from our own Chuck Guzis
> saying there were two controller chips in the 1542CF (national and broken
> Intel) and I discovered I had a broken Intel one.
>
> I may have cussed.
>
> Typically all the AHA-1522s are in the US, sigh.
>
> Cheers,
>
> —
> Adrian/Witchy
> Binary Dinosaurs - Celebrating Computing History from 1972 onwards
> w: binarydinosaurs.co.uk t: @binarydinosaurs
> f: facebook.com/binarydinosaurs
>
>

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Grant Taylor via cctalk]

On 01/18/2018 12:53 PM, Eric Smith via cctalk wrote:
Proxy ARP is (or was, at the time) something that had to be configured 
for individual IP addresses or ranges. What I did was have it reply to an 
ARP for any IP address outside the subnet(s) configured on that interface.


Intriguing.

I guess this means that you only heard ARP requests for IP addresses 
that other systems in the same broadcast domain thought were local to 
said broadcast domain.


You wouldn't need to worry about errant ARP requests for things outside 
of the local subnet as that would go through the default gateway (or 
other defined router).


I like it.


Yes. Specifically IPv4.


*nod*

The point of bozo-arp and anyipd was that the only necessary configuration 
was to turn it on. Of course, there may be scenarios in which one does 
not want the router to respond to bogus ARP requests, in which case 
bozo-arp/anyipd should not be used.


Like all tools, you have to be careful where you do use it.  -  I'd 
default with it off (or not installed) and  turn it on as necessary.




--
Grant. . . .
unix || die

Re: New TestFDC Results Registry

[Adrian Graham via cctalk]

> On 18 Jan 2018, at 15:46, systems_glitch via cctalk  
> wrote:
> 
> I'd been trying to reach Dave Dunfield with new TestFDC results since
> apparently August with no results. So, I wrote a new TestFDC registry into
> my site:
> 
> https://services.theglitchworks.net/ng/testfdc_results

Gh, talk about the wrong timing for this XD. I say this because I just 
bought an AHA-1524CF on various folk’s recommendations (not from here) a couple 
of weeks ago only to find I still couldn’t really manipulate SSSD images then 
tonight I read a message on VCFED from our own Chuck Guzis saying there were 
two controller chips in the 1542CF (national and broken Intel) and I discovered 
I had a broken Intel one.

I may have cussed.

Typically all the AHA-1522s are in the US, sigh.

Cheers,

—
Adrian/Witchy
Binary Dinosaurs - Celebrating Computing History from 1972 onwards
w: binarydinosaurs.co.uk t: @binarydinosaurs
f: facebook.com/binarydinosaurs

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Eric Smith via cctalk]

On Thu, Jan 18, 2018 at 11:35 AM, Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> On 01/18/2018 11:00 AM, Eric Smith wrote:
>
>> Years ago I added a configurable "bozo-arp" feature to the Telebit
>> NetBlazer router, which would respond to ARP requests for non-local
>> addresses and reply with the router's MAC address (on that interface),
>> specifically in order to make classful-only hosts work on a CIDR network.
>>
>
> That functionality sounds exactly like my understanding of what Proxy ARP
> is supposed to do.
>

Proxy ARP is (or was, at the time) something that had to be configured for
individual IP addresses or ranges. What I did was have it reply to an ARP
for _any_ IP address outside the subnet(s) configured on that interface.

Since you stated that anyipd "…would respond to ARP requests for non-local
> addresses…" I"m assuming that you are talking IP and not another protocol.
>

Yes. Specifically IPv4.

Recently I've needed that functionality on Linux, as I have multiple old
>> systems that only understand classful, including the AT UnixPC (7300 or
>> 3B1). I suppose I should rewrite and open-source it.
>>
>

> I /think/ (it's been too long since I've done this) that you would
> configure one classless interface with 10.20.30.254/24 and another
> classless interface with 10.10.10.254/24 -and- enable Proxy ARP on both
> (?) interfaces.  You will likely need to enter the target machine's IP
> addresses in a file that the Proxy ARP sub-system references to learn what
> target IPs that it needs to Proxy ARP for.
>

The point of bozo-arp and anyipd was that the only necessary configuration
was to turn it on. Of course, there may be scenarios in which one does not
want the router to respond to bogus ARP requests, in which case
bozo-arp/anyipd should not be used.

Re: New TestFDC Results Registry

[Jason T via cctalk]

On Thu, Jan 18, 2018 at 9:46 AM, systems_glitch via cctalk
 wrote:
> I'd been trying to reach Dave Dunfield with new TestFDC results since
> apparently August with no results. So, I wrote a new TestFDC registry into
> my site:
>
> https://services.theglitchworks.net/ng/testfdc_results

Thank you for doing this!  It's a valuable resource for us
disk-imagers and really needed an update. Maybe we can find other
"full pass" cards and I can stop hoarding Adaptec 1522s :)

-j

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Grant Taylor via cctalk]

On 01/18/2018 12:23 PM, Dennis Boone via cctalk wrote:

You all talk about Proxy ARP in the past tense for some reason. :)


Please don't interpret the fact that I am inadvertently talking about 
Proxy ARP in the past tense to mean anything.


I personally started solving the problem that Proxy ARP is meant to 
solve with a different solution.


I fell in love with Linux bridges (brctl, etc) for things like this (I'm 
guessing) 15+ years ago.  I can create a Bridging Router (a.k.a. 
BROUTER) that combines layer 2 and layer 3 functionality.  This allowed 
me to bridge non-IP protocols, like NetBIOS / IPX, while routing IP.


I could further extend things to include selectively bridging IP via 
adding EBTables to the mix.


I did a LOT of crazy things with Linux bridges.  }:-)

In hind sight, Proxy ARP might have been the simpler solution.  Though I 
think Proxy ARP would have required that I configure IPs to be Proxy 
ARPed on all intermediate hosts.  Where as bridging has it's own 
inherent L2 learning.  (At least when I was working with non-IP protocols.)


I don't know how well Proxy ARP plays with things like OpenVPN or 
OpenSSH layer 2 tunnels.  -  I know that I can easily extend layer 2 
across a LARGE majority of networks using Linux bridges.  -  I think 
that I can even bridge any type of network that uses 802.2 Link Level 
Control headers.  I.e. Token Ring (802.5) and Ethernet (802.3) and 
Wireless (802.11) and various tunnels.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Phil Budne via cctalk]

Noel wrote:
> but I dunno how one would hook _that_ simulation up to a simulated host
> running a simulated ARPANET interface.

It would seem silly to simulate a bit by bit interface, so just come
up with an encapsulation of 1822 messages in TCP?

Two-octet count(*), plus 1822 leaders .

(*) and if any out-of-band signals are required maybe some flag bits?

And if hooking up a network of simulated IMPs gets old, you could
write a single ARPAnet server program that multiple hosts connect to

Mr DeMille; RFNM

p

Re: Reviving ARPAnet

[Charles Anthony via cctalk]

On Thu, Jan 18, 2018 at 10:27 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Grant Taylor
>
>
> The ARPANET supported several different kinds of interfaces between the
> IMPs
> (the switching nodes in the ARPANET) and hosts, but the 'usual' one was
> either 'Local Host' (LH) or 'Distant Host' (DH) which were _basically_
> identical except at the very lowest level - LH was TTL, and DH was
> differential pair.
>
> Those interfaces were a custom bit-serial thing with a handshake (with
> "there's-your-bit", "ready-for-next-bit" lines, etc); see BBN Report #1822:
>
>
And an "end-of-packet" bit.


>   http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf
>
> So the "ARPANET interface" in the host is a piece of custom hardware (some
> were DMA; I also used one which was interrupt per byte) which went on the
> host, which talked 1822 (as it was called), of either the DH or LH physical
> form.
>
>
>
> > Do the necessary emulators support the ARPANET interface?
>
> Dunno, but they shouldn't be too hard to add.
>
> The real problem is going to be 'what do you hook the simulated ARPANET
> interfaces up to, and how'? I know they have IMP code running in
> simulators:
>
>   http://mailman.trailing-edge.com/pipermail/simh/2013-
> November/007672.html
>
> but I dunno how one would hook _that_ simulation up to a simulated host
> running a simulated ARPANET interface.
>
>
The IMP emulator emulates the DH/LH interface with UDP packets. I wired up
the dps8/m emulator to the IMP emulator, but I don't have the ARPAnet stack
for Multics, so it's just packets.

-- Charles

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Dennis Boone via cctalk]

 > > which would respond to ARP requests for non-local addresses and
 > > reply with the router's MAC address (on that interface),
 > > specifically in order to make classful-only hosts work on a
 > > CIDR network.

 > Yeah, Proxy ARP (an early RFC here:

You all talk about Proxy ARP in the past tense for some reason. :)

De

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Noel Chiappa via cctalk]

> From: Eric Smith

> which would respond to ARP requests for non-local addresses and reply
> with the router's MAC address (on that interface), specifically in
> order to make classful-only hosts work on a CIDR network.

Yeah, Proxy ARP (an early RFC here:

  https://www.rfc-editor.org/rfc/rfc1027.txt

but IIRC it was people at CMU who first came up with the idea; this RFC is
from people at UT-Austin, documenting it) was originally done to support
subnetting (see

  https://www.rfc-editor.org/rfc/rfc917.txt

for more) when it was first introduced - for hosts for which people didn't
have the source, but needed to attach it to a subnetted network.

Subnetting was a stage before CIDR (which took subnetting and Carl-Herbert
Rokitansky's 'supernetting' and mushed them together).

Noel

Re: Reviving ARPAnet

[Lars Brinkhoff via cctalk]

Grant Taylor wrote:
> Do the necessary emulators support the ARPANET interface?

Ken Harrenstien's PDP-10 emulator does.  ITS uses the IMP interface for
TCP/IP to this day.

Re: Reviving ARPAnet

[Warner Losh via cctalk]

On Thu, Jan 18, 2018 at 11:27 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:
>
> Easier, to get this old TCP/IP running, might be to write a Unix V6 driver
> for
> an Ethernet card (one the simulators do support - I know Ersatz-11 does the
> Interlan NI1010A/2010A, which is nice and simple) and write an Ethernet
> network interface module for that TCP, which talks to said driver; i.e.
> just
> replace the ARPANET interface stuff completely.
>

That's what I had thought about maybe doing... As well as playing with a V7
port  in my copious spare time

Warner

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Grant Taylor via cctalk]

On 01/18/2018 11:00 AM, Eric Smith wrote:
Years ago I added a configurable "bozo-arp" feature to the Telebit 
NetBlazer router, which would respond to ARP requests for non-local 
addresses and reply with the router's MAC address (on that interface), 
specifically in order to make classful-only hosts work on a CIDR 
network.


That functionality sounds exactly like my understanding of what Proxy 
ARP is supposed to do.


Later someone paid me to write a NetBSD daemon ("anyipd") to do the same 
thing, though for an entirely different reason.


Nice.

Since you stated that anyipd "…would respond to ARP requests for 
non-local addresses…" I"m assuming that you are talking IP and not 
another protocol.  Please correct me if I'm assuming incorrectly.


Recently I've needed that functionality on Linux, as I have multiple 
old systems that only understand classful, including the AT UnixPC 
(7300 or 3B1). I suppose I should rewrite and open-source it.


I'm trying to make sure that I understand what you're wanting / needing 
to do and evaluate if Proxy ARP can do it or not.


I'm guessing that you have a host, AT Unix PC, that's at (for the sake 
of discussion) 10.20.30.40/8 and you'd like to communicate with another 
machine that's at 10.10.10.10/24.  Obviously 10.10.10.10/24 is a subset 
of 10.0.0.0/8, so the AT Unix PC thinks that 10.10.10.10 is local.  - 
Does this accurately represent your use case?


Unless you correct me, I'm going to assume that this is accurate enough 
for the sake of discussion.


I /think/ (it's been too long since I've done this) that you would 
configure one classless interface with 10.20.30.254/24 and another 
classless interface with 10.10.10.254/24 -and- enable Proxy ARP on both 
(?) interfaces.  You will likely need to enter the target machine's IP 
addresses in a file that the Proxy ARP sub-system references to learn 
what target IPs that it needs to Proxy ARP for.


I might not have the nuances exactly correct because I've not done this 
in a long time.  But I have made this scenario work with the Proxy ARP 
support that currently exists in the Linux kernel.


So … I wonder what additional functionality your anyipd would provide. 
-  I'm actually quite curious to learn.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Noel Chiappa via cctalk]

> From: Grant Taylor

>> It is TCP/IPv4, so it's got compatible headers

> Are you referring to the 802.3 Ethernet (vs Ethernet II) frame type

No, I meant the IP and TCP headers. Those are end-end; the Ethernet stuff is
just a local wrapping, and can be substituted.

> I was not aware that there was code that supported /only/ Class A (/8)
> addresses and /not/ Class B (/16) or Class C (/24) addresses.
> I /thought/ that everything was either classful (as in supports all 
> three classes: A, B, and C) or classless (as in supports CIDR).
> Is my networking history missing something else?

Yes. There was a stage before A/B/C. See RFC-760.

> Please clarify ... what you mean by ARPANET interface? Are you
> referring to host specific hardware that was used to communicate
> with an IMP?

Basically, yes.

The ARPANET supported several different kinds of interfaces between the IMPs
(the switching nodes in the ARPANET) and hosts, but the 'usual' one was
either 'Local Host' (LH) or 'Distant Host' (DH) which were _basically_
identical except at the very lowest level - LH was TTL, and DH was
differential pair.

Those interfaces were a custom bit-serial thing with a handshake (with
"there's-your-bit", "ready-for-next-bit" lines, etc); see BBN Report #1822:

  http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf  

So the "ARPANET interface" in the host is a piece of custom hardware (some
were DMA; I also used one which was interrupt per byte) which went on the
host, which talked 1822 (as it was called), of either the DH or LH physical
form.

(There was also an Host/IMP interface called VDH, but that used a modem, and
a _lot_of software; see here:

  https://en.wikipedia.org/wiki/Talk:Network_Control_Program#Layer_locations

for a bit more about it.)


> Do the necessary emulators support the ARPANET interface?

Dunno, but they shouldn't be too hard to add.

The real problem is going to be 'what do you hook the simulated ARPANET
interfaces up to, and how'? I know they have IMP code running in simulators:

  http://mailman.trailing-edge.com/pipermail/simh/2013-November/007672.html

but I dunno how one would hook _that_ simulation up to a simulated host
running a simulated ARPANET interface.


Easier, to get this old TCP/IP running, might be to write a Unix V6 driver for
an Ethernet card (one the simulators do support - I know Ersatz-11 does the
Interlan NI1010A/2010A, which is nice and simple) and write an Ethernet
network interface module for that TCP, which talks to said driver; i.e. just
replace the ARPANET interface stuff completely.

Noel

Re: Reviving ARPAnet

[Grant Taylor via cctalk]

On 01/18/2018 10:53 AM, Peter Coghlan via cctalk wrote:
I thought that what Novell refers to as "IEEE 802.3 raw" was an early day 
foulup on their part where they put IPX data directly into IEEE 802.3 
frames with nothing to indicate what protocol was being transported.


That's my understanding as well.

It's also my understanding that they made this decision prior to the 
standards we use today existed.  -  So, assuming my understanding is 
correct, I don't fault them for betting on the wrong option.


It became a problem because lots of people whose first experience of 
networking was a Novell Netware server used it because it was the default 
frame type, making life difficult for them when they wanted to add other 
protocols to their network later on.


Agreed.

The above are what they should have used instead of IEEE 802.3 "raw" 
if they really wanted to fly the 802.3 flag.


I don't know that Novell /wanted/ to fly the 802.3 flag.  I think they 
just wanted something that worked.  Purportedly, standards didn't exist 
yet, or weren't widely adopted, and they made a decision.  Granted, in 
retrospect it was the wrong decision.  But it did work for them at the time.


As far as I know, anyone who wanted everything to work just used Ethernet 
II (and 802.3 / 802.2 SNAP if they also wanted Appletalk support). 
I don't thing IEEE 802.3 with 802.2 and no SNAP was very useful because 
of the limited number of protocols it could be used to specify.


Agreed.

Though most of this is related to having multiple protocols on the same 
network segment / broadcast domain.  -  It's also my understanding that 
most businesses had multiple disconnected networks (likely using 
different physical technology) that had their native protocol(s) and 
didn't inter operate with each other.


Maybe, if V-delta-4 and before used IEEE 802.3 with 802.2 but I doubt 
if anyone other than Novell used what they called IEEE 802.3 "raw".


Fair enough.  I don't have any information to refute that.  -  So I 
modify my statement to be "I wonder if NetWare 4.x / 5.x can route IP 
between (what Novell called) 802.2 and Ethernet II.  ;-)


My desire is to find a way to interconnect between the existing 
protocols & frame types without needing to modify things on hosts.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Peter Coghlan via cctalk]

Here's a link with a lot of gory details on NetWare's support of 
multiple Ethernet frame types.


Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
  - https://support.novell.com/techcenter/articles/ana19930905.html

Here are the four frame types that NetWare supports:

  - Ethernet II
 - I think this is what we are using for just about everything today.
  - IEEE 802.3 "raw"
 - I'm speculating that this is the frame type that Frank is referring to 
above.


I thought that what Novell refers to as "IEEE 802.3 raw" was an early day
foulup on their part where they put IPX data directly into IEEE 802.3 frames
with nothing to indicate what protocol was being transported.  It became a
problem because lots of people whose first experience of networking was a
Novell Netware server used it because it was the default frame type, making
life difficult for them when they wanted to add other protocols to their
network later on.



 - IEEE 802.3 with 802.2
 - IEEE 802.3 with 802.2 SNAP



The above are what they should have used instead of IEEE 802.3 "raw" if they
really wanted to fly the 802.3 flag.  As far as I know, anyone who wanted
everything to work just used Ethernet II (and 802.3 / 802.2 SNAP if they also
wanted Appletalk support).  I don't thing IEEE 802.3 with 802.2 and no SNAP
was very useful because of the limited number of protocols it could be used
to specify.



I /think/ that NetWare can bind IP to all four Ethernet frame types. 
Hopefully one of them is compatible with V-delta-4 and before.




Maybe, if V-delta-4 and before used IEEE 802.3 with 802.2 but I doubt if
anyone other than Novell used what they called IEEE 802.3 "raw".

Regards,
Peter Coghlan.

Re: Reviving ARPAnet

[Paul Koning via cctalk]

> On Jan 18, 2018, at 12:27 PM, Grant Taylor via cctalk  
> wrote:
> 
> On 01/17/2018 01:12 PM, Frank McConnell via cctalk wrote:
> ...
>> So you might think I'd be able to move files between it and a modern FreeBSD 
>> box, right?  I mean, it's all just Ethernet, right?
> 
> Ethernet != Ethernet
> 
> I'm wondering if it might be possible to use an old NetWare 4.x / 5.x box as 
> a router to convert from one Ethernet frame type to another Ethernet frame 
> type.  I.e. from IP over Ethernet II frames to IP over 802.3 frames.

I didn't know there's any such thing as IP over 802.3.  There's IP over 802.2 
(LLC) which is used for things like FDDI, but it would be weird to attempt that 
on Ethernet.

> ...
> Here are the four frame types that NetWare supports:
> 
> - Ethernet II
>- I think this is what we are using for just about everything today.
> - IEEE 802.3 "raw"
>- I'm speculating that this is the frame type that Frank is referring to 
> above.

That's the infamous non-compliant mess Netware came up with by not 
understanding the 802 standard.  It's never valid to run "raw 802.3" -- the 
only correct usage is 802.2 (LLC n for some n) over a MAC layer like 802.3 or 
FDDI.  SNAP is essentially an additional muxing layer on top of 802.2.

paul

IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Eric Smith via cctalk]

On Thu, Jan 18, 2018 at 10:39 AM, Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> I was not aware that there was code that supported /only/ Class A (/8)
> addresses and /not/ Class B (/16) or Class C (/24) addresses.
>
> I /thought/ that everything was either classful (as in supports all three
> classes: A, B, and C) or classless (as in supports CIDR).
>

Years ago I added a configurable "bozo-arp" feature to the Telebit
NetBlazer router, which would respond to ARP requests for non-local
addresses and reply with the router's MAC address (on that interface),
specifically in order to make classful-only hosts work on a CIDR network.
Later someone paid me to write a NetBSD daemon ("anyipd") to do the same
thing, though for an entirely different reason. Recently I've needed that
functionality on Linux, as I have multiple old systems that only understand
classful, including the AT UnixPC (7300 or 3B1). I suppose I should
rewrite and open-source it.

Re: Reviving ARPAnet

[Grant Taylor via cctalk]

On 01/17/2018 11:33 AM, Noel Chiappa via cctalk wrote:
This just a guess, but 'sort of'? It is TCP/IPv4, so it's got compatible 
headers, but I don't know if other parts have changed enough to make it 
not work.


Are you referring to the 802.3 Ethernet (vs Ethernet II) frame type that 
Frank mentioned?


E.g. it probably only supports class A addresses, for instance, which 
is going to influence the code for picking the first-hop router.


I was not aware that there was code that supported /only/ Class A (/8) 
addresses and /not/ Class B (/16) or Class C (/24) addresses.


I /thought/ that everything was either classful (as in supports all 
three classes: A, B, and C) or classless (as in supports CIDR).


Is my networking history missing something else?

Also, do any of the systems that people want to emulate have conflicting 
classful networks?  -  Read:  Were any of the systems that people want 
to emulate on the same classful network?


If all the systems that people want to emulate are on different classful 
networks, it should be relatively trivial to interconnect them.



Also, the only driver is, IIRC, for an ARPANET interface.


Please clarify for this n00b what you mean by ARPANET interface?  Are 
you referring to host specific hardware that was used to communicate 
with an IMP?


Do the necessary emulators support the ARPANET interface?



--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Grant Taylor via cctalk]

On 01/17/2018 01:12 PM, Frank McConnell via cctalk wrote:
So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09 
(V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is 
late enough for it to be able to do IP over Ethernet (vs. V-delta-4 and 
before which could only do IEEE over 802.3).  And it has an FTP client.


Please clarify what you mean by "IP over Ethernet", specifically what 
frame type?


Are you talking about Ethernet II frames?

So you might think I'd be able to move files between it and a modern 
FreeBSD box, right?  I mean, it's all just Ethernet, right?


Ethernet != Ethernet

I'm wondering if it might be possible to use an old NetWare 4.x / 5.x 
box as a router to convert from one Ethernet frame type to another 
Ethernet frame type.  I.e. from IP over Ethernet II frames to IP over 
802.3 frames.


I actually don't know if Linux can do this or not.  My typical go to 
tool might not help here.  :-/


Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport") 
in V-delta-9 and before, such that it tears down the connection with 
a failure if a packet is received with IP type-of-service not zero. 
And the FreeBSD FTP server sets a socket option that gets FreeBSD to 
send that sort of packet.


At a previous employer, I went round with HP a bit on behalf of a mutual 
customer and got HP to issue a patch for NS Transport that corrects 
this behavior on the MPE side.  Clearly, I don't have that patch on 
this system.


I think we all have experiences like that.  Some sort of custom code 
that we didn't care about at the time (beyond fixing the problem) that 
we would now like to get our hands on years later.


FreeBSD is FreeBSD, and I can build its FTP server from source and 
change it so it works in this situation; but I think this should give 
y'all some idea of the hilarity that can ensue when you exhume a 1980s 
TCP/IP and put it on your network.


I wonder if there are other tricks that can be used to work around this 
without needing to recompile services.  I.e. use IPTables (or FreeBSD's 
counterpart that I don't know the name of) to change the type-of-service 
to something other than 0.


Here's a link with a lot of gory details on NetWare's support of 
multiple Ethernet frame types.


Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
 - https://support.novell.com/techcenter/articles/ana19930905.html

Here are the four frame types that NetWare supports:

 - Ethernet II
- I think this is what we are using for just about everything today.
 - IEEE 802.3 "raw"
- I'm speculating that this is the frame type that Frank is 
referring to above.

 - IEEE 802.3 with 802.2
 - IEEE 802.3 with 802.2 SNAP

I /think/ that NetWare can bind IP to all four Ethernet frame types. 
Hopefully one of them is compatible with V-delta-4 and before.


Obviously addressing would be a concern.  -  I want to do some more 
digging to see if NetWare supports any form of Proxy ARP.  Hopefully 
Proxy ARP support would allow us to form proto bridges to extend the 
classful /A or /B or /C networks that the desired nodes are in.


I'm happy to ponder some more scheming and networking black magic if 
people are interested.




--
Grant. . . .
unix || die

Re: help id a chip

[Jon Elson via cctalk]

On 01/18/2018 04:37 AM, william degnan via cctalk wrote:

P1010110 is an IBM SLT card out of a 360 or 1800 computer.

P1010112 is same thing from different angle.

Jon

New TestFDC Results Registry

[systems_glitch via cctalk]

I'd been trying to reach Dave Dunfield with new TestFDC results since
apparently August with no results. So, I wrote a new TestFDC registry into
my site:

https://services.theglitchworks.net/ng/testfdc_results

This registry currently includes Dave's last registry update from 2007.
There's now a form for entering your results, you can find it as a link
from the registry, or here:

https://services.theglitchworks.net/ng/testfdc_results/new

Result submissions have to be manually approved currently so that the
registry doesn't get spammed. Text export forthcoming. Any suggestions
welcome!

Moderators, if someone wants to sticky this (here or in other forums), I
think this would be a valuable resource for anyone wanting to use ImageDisk
on non-PC formats.

Thanks,
Jonathan

Re: DL10 documentation

[Lars Brinkhoff via cctalk]

Noel Chiappa wrote:
> Well The "decsystem10 System Reference Manual (DEC-10-XSRMA-A-D) -
> available online:
>
>   
> http://bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-10-XSRMA-A-D%20DECsystem10%20System%20Reference%20Manual.pdf
>
> has a definition for the -10 side of the interface on pages C-21 and
> following (page 365 of the PDF).

I have taken a quick look at this, and also the Rubin 10-11 interface
that was used on MIT-AI.  So far they look similar.  Was there a chance
one inspired the other?

Re: help id a chip

[william degnan via cctalk]

On Jan 18, 2018 4:13 AM, "Christian Corti via cctalk" 
wrote:
>
> On Wed, 17 Jan 2018, william degnan wrote:
>>
>> Not sure, I have a bunch of items that need to be investigated including
>> that one.
>> http://vintagecomputer.net/pictures/2017/Objects/
>> b
>
>
> Well, two objects are obvious ;-)
>
> P1010070.JPG is the program drum for an IBM 29 card punch (and similar
models)
>
> P1010126.JPG is the clock generator module for an LGP-30
>
> Christian

I would never have guessed LGP-30.  Very much appreciated.  I am glad I
asked.
Bill

Convergent AWS machines (formerly Sold on eBay: Convergent Technologies S/50 a.k.a. Unix PC, AT 3B1 Unix Workstation)

[AJ Palmgren via cctalk]

Alan, my apologies for the confusion here.  The email subject still said
S/50, but I believe we had switched topics mid-thread.

On Mon, Jan 15, 2018 at 6:16 AM, dwight  wrote:

> Years ago, we used one of the Convergent machines. I recall playing rats
> on it. It had a green screen. It was a 8086 processor and had some
> Multibus slots in it.
>

I was replying to Dwight with a link to my AWS machine when Dominique
chipped in with the Burrows comment.

I believe that Dominique was referring to my AWS that I show at
http://mightyframe.blogspot.com/2017/03/convergent-technolog
ies-workstation.html

And I agree with you wholeheartedly on your points.  They look nothing
alike, and are based on totally different processors.

|Alan Perry via cctech 
|
|As I mentioned elsewhere, I worked on software for them at Burroughs
('86-'89). I
|picked up a bunch of B25 stuff in '03, but I could never find any software
for
|them. In retrospect, I wish that I has stashed away B25 (and B1000 (I was
one
|of the last people in the office supporting software onthe B1000)) stuff,
rather
|than return everything, when I left the company.
|
|alan

That's very cool that you worked on the software.  And, yes, Alan, agreed
about wishing to keep a few of them around...But, I may be able to get the
one that I have running soon.  I'll be working on it on and off this year.

I plan on trying trying to restore the Convergent CTOS on this, rather than
the Burroughs BTOS, at least at first anyway...

I'll keep you posted here on my progress on that.

Thanks, all!

Best,
-AJ



On Wed, Jan 17, 2018 at 11:02 AM, Alan Perry via cctech <
cct...@classiccmp.org> wrote:

> Are you sure?
>
> The B20, B21, B22 looked like this - http://www.computerhistory.org
> /collections/catalog/102662660 - and nothing like the 3B1 or the S/50.
> The B25 and subsequent models (which are often referred to as B20s) are
> modular systems that are box-shaped and got wider as "slices" were added.
> The B20s were x86-based and the 3B1 (and presumably the CT S/50) was
> 68k-based.
>
> alan
>
>
> On 1/17/18 2:41 AM, Dominique Carlier via cctech wrote:
>
>> It's interesting, I had exactly the same machine a long time ago, but
>> with a different label. It was a Burroughs B20 distributed by Unisys
>>
>> Dominique
>>
>> On 17/01/2018 06:45, AJ Palmgren via cctalk wrote:
>>
>>> Did it happen to be one of these older-style Convergent AWS machines?
>>>
>>> http://mightyframe.blogspot.com/2017/03/convergent-technolog
>>> ies-workstation.html
>>>
>>>
>>>
>


-

Re: help id a chip

[Christian Corti via cctalk]

On Wed, 17 Jan 2018, william degnan wrote:

Not sure, I have a bunch of items that need to be investigated including
that one.
http://vintagecomputer.net/pictures/2017/Objects/
b


Well, two objects are obvious ;-)

P1010070.JPG is the program drum for an IBM 29 card punch (and similar 
models)


P1010126.JPG is the clock generator module for an LGP-30

Christian