Does anyone have one of these in running (reliable) condition? I
found a lot of documentation of an attempt to run one at Digibarn for
the 30th anniversary of the Alto, which did not appear to be successful,
and that got me to wondering if there was a working one anywhere.
Nick would probably be advised to look at that documentation as well as
other web pages I've sent him as far as planning what he tries to do
with his system.
It appears there were maybe 3 sets of spares for the Digibarn one (just
>from the video) and the photos showed in the background they went from
morning light to darkness trying to get it working before giving up.
I am not familiar with the person who was trying the bringup, but
assuming he was one familiar with the Alto and with all those resources,
it says a lot about getting one of these w/o extensive knowledge (true
of any vintage system) and trying to bring it up. It's the nature of
some designs they always did something you could nurse along to running,
and some, perhaps like the Alto may be pumpkins until a lot of things
work, and it can be very difficult to figure out if you are damaging
them along the course of the effort (2 steps forward 3 back).
http://www.digibarn.com/collections/systems/xerox-alto/
I have a BA356 shelf with a DS-BA35X-FB personality module. The personality
module has two high density connectors on it, I think they are 68-pin. The
pins are too small for me to be able to count them reliably, but the cable
has a 68-pin SCSI Wide connector on the other end. The second connector on
the personality module is not connected to anything, I do not have a
terminator for it and I am unsure if I need one. I have connected this to my
433au which has a Qlogic QLA1040 SCSI adapter in it. I have been unable to
locate any documentation for either the personality module or the SCSI
adapter.
I am having problems getting the SRM to recognise the disks in the shelf.
Sometimes it will see no devices at all, not even the CD-ROM connected to
the internal SCSI cable. Other times it will see a ton of disks as shown in
this partial extract from the console:
>>>sh dev
dka0.0.0.1009.0 DKA0
dka100.1.0.1009.0 DKA100
dka101.1.0.1009.0 DKA101
dka103.1.0.1009.0 DKA103
dka105.1.0.1009.0 DKA105
dka107.1.0.1009.0 DKA107
dka1100.11.0.1009.0 DKA1100
dka1102.11.0.1009.0 DKA1102
Just now I tried with one SBB in slot 0 and I got this:
>>>sh dev
dka400.4.0.1009.0 DKA400 MATSHITA CD-ROM CR-508 XS03
dva0.0.0.0.1 DVA0
ewa0.0.0.3.0 EWA0 00-00-F8-75-BE-63
pka0.7.0.1009.0 PKA0 SCSI Bus ID 7 5.57
pqa0.0.0.4.0 PQA0 PCI EIDE
pqb0.0.1.4.0 PQB0 PCI EIDE
When I added a second SBB in slot 1 then I got this:
>>>sh dev
waiting for pka0.7.0.1009.0 to poll...
waiting for pka0.7.0.1009.0 to poll...
waiting for pka0.7.0.1009.0 to poll...
dva0.0.0.0.1 DVA0
ewa0.0.0.3.0 EWA0 00-00-F8-75-BE-63
pka0.7.0.1009.0 PKA0 SCSI Bus ID 7 5.57
pqa0.0.0.4.0 PQA0 PCI EIDE
pqb0.0.1.4.0 PQB0 PCI EIDE
>>>
I am not quite sure what is going on, what the jumpers on the personality
module do, whether I need to insert a terminator on the second personality
module connector, or whether there are some jumpers on the QLA1040 adapter
that need to be set, or is there something else I need to do.
Anyone have any clues?
Thanks
Rob
>
> 110599066440
>
> Pretty lame listing. No useful pictures. He CLAIMS it is an Alto I, but
> you can't tell anything from the listing picture
>
It's not, it's an Alto II XM, here are pics from a very similar close
S/N system taken from VCF MW. You can see from those pictures the chip
dates are in the late 70's and therefore the unit on Ebay is also a
later version.
http://vintagecomputer.net/vcfmw-ECCC_2010/Xerox_Alto-II-XM/
Bill
Anyone have any experience getting the front panel of an IMSAI
computer to work with a CompuPro CPU-Z S100 board? I read the
documentation
(http://maben.homeip.net/static/S100/compupro/cards/CompuPro%20CPU-Z.pdf),
and there seems some configuration required, I obviously am missing
something as it is not working properly even after I attempt the config
in the documentation.
If you currently have a board working and can share a photo, or can
provide any technical assistance, I would be extremely grateful!
Nick
I acquired a Commodore SX a few years ago, but it lacks a keyboard cable
and one of the keyboard latches is broken. Does anyone here have a spare
keyboard and cable for the Commodore SX?
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Hi all,
anybody still cares about them?
Got a pile of them, so if anybody is looking for something specific,
please let me know (will take a while until I get into this pile).
Any good web page with hardware information of those?
Cheers
On 09/30/10 06:42, "Michael B. Brutman" <mbbrutman-cctalk at brutman.com>
wrote:
> I have been working on my TCP/IP stack for DOS, adding IP fragmentation
> support. There are not too many more features that I want to add to
> make it 'complete' before I open source the code and IP fragment support
> was a big one.
>
> I am having a terrible time testing it though. It seems that IP
> fragments out in the wild are pretty rare. I tried connecting to a slew
> of remote FTP sites hoping to find one that was behind a really bad
> network, and thus would have fragments coming from it. No joy.
>
> It seems that there are a lot of tricks out there to prevent fragments
> from being created, especially when using TCP. The only way I can test
> the code is to send myself oversized UDP packets. If it works for UDP
> then it should work for TCP too, but I'd really like to test the TCP
> path explicitly. Combine the tricks with modern broadband and getting
> fragments is really difficult.
>
>
Why? Are you handling UDP and TCP differently at the IP level???
I've written my own TCP/IP (for a PDP-11), and the fragment reassembly
code I mostly tested using ICMP, since that was so easy. The IP code is
totally protocol-agnostic, so if it works for one protocol, it will work
for any. If you haven't done your code this way, then maybe you should
rethink that part.
TCP is, as you noted, explicitly trying to avoid fragmentation. So it's
not an easy protocol to use to test this.
> Even on the home network I am having a hard time getting fragments. I
> put a Linux box between the DOS PC and a Windows machine, and set one of
> the Ethernet MTUs to 576. Well, that didn't force fragments because the
> Windows box is too clever. I could start turning everything off in the
> registry, but I really don't want to get that involved.
>
> Off the top of my head I think I am going to have to get another Linux
> box and dumb that down, if it is possible. Dumbing Linux down to turn
> off the features and then restoring it to a good state is probably
> safer/easier than doing it with Windows.
>
I doubt that would help you either. If you read through the TCP specs,
you'll find how the path MTU, and thus MSS is determined. And I doubt
you can turn those knobs off.
> Does anybody have a good technique for setting up a simple network that
> will result in IP fragments of TCP?
>
>
Nope. And I don't really think that it should be neccesary.
> On a related note, is this even worth it? I don't know of anything that
> needs to send fragments except for NFS over UDP. There might be other
> applications that send big packets over UDP but those would be the only
> class of applications that absolutely require fragment support. With
> TCP it is nice, but a user should be able to get around any problem by
> setting the local MTU to 576.
>
>
Yes, I think it is worth it.
Not only can packets be fragmented along the way, but you are not even
guaranteed that 576 byte packets will not get fragmented. IP requires
that you should always be able to pass through 576 byte packets, but it
don't actually say anything about fragmentation in this case.
If you dig really deep, you'll find that the guaranteed minimum packet
size that IP needs to handle without fragmentation is 65 bytes. All
above that could get fragmented, so fragment reassembly is a good thing
to have.
I think, for instance, SLIP interfaces usually run with an MTU of 296,
or something like that.
But, with all that said, several IP implementations do take a short cut
with regards to fragmentation and either totally skip it, or just
implement reassembly, and not fragmentation. You can get away with that
most of the time, even though it is breaking the requirements.
Johnny
>The "device control" codes appear to have their familiar uses:
>
>DC1 = ctrl-Q = reader on
>DC2 = ctrl-R = punch on
>DC3 = ctrl-S = reader off
>DC4 = ctrl-T = punch off
>However, it isn't yet clear whether the device being used is truly a
>reader/punch, or that these codes are used for some analogous purpose
>to turn on/off read/write of another device.
That would (to me at least) seem inconsistent with my theory that this
is a dialect of Tektronix 4010 control codes - I can't work out any
sensible interpretation of the sequence
1) 1D Group Separator
2) 37 7
3) 7F DEL
4) 20 SPACE
5) 40 @
6) 1F Unit Separator
7) 12 DC2
8) 1D Group Separator
9) 37 7
10) 7F DEL
11) 20 SPACE
12) 40 @
13) 1F Unit Separator
14) 14 DC4
that would allow for lines 1-6 and 8-13 to be both graphics control
codes (positioning the cursor) and lines 7 & 14 to be turning a device
on & off.
of course, I may be tracing the execution flow wrong, and there could
be errors in the dump...
>> The escape sequences I see are:
>> HEX ASCII
>> 1) 1F 26 24 <x y z> : ESC & $ <xyz>
>> 2) 1F 26 27 <x y z> : ESC & ' <xyz>
>> 3) 1F 26 21 <x y z> : ESC & ! <xyz>
>>
>> where 1,2,3 are all output at different times, with <x y z> being
>> values I haven't yet determined (they are register values i.e. set at
>> runtime, whereas the first 3 bytes are hardcoded)
>The first value is hex 1B, of course (not 1F).
yes - my bad!
>The x,y,z values apparently represent a record number (128-byte records).
>x is an ASCII digit (30 - 39 hex)
>y is an ASCII digit (30 - 39 hex)
>z has the range 40 - 5F hex (at sign through underscore)