test-drb October 2010

test-drb@ccmp.vtda.org

175 participants
274 discussions

by jws＠jwsss.com

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/

13 years, 9 months

Confused by Alpha 433au and SCSI

by robert.jarratt＠ntlworld.com

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

13 years, 9 months

another alto on ebay

by billdeg＠degnanco.com

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

13 years, 9 months

CompuPro CPU-Z with IMSAI and Front Panel issues

by nick.allen＠comcast.net

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

13 years, 9 months

3B1 tech ref scans

by snhirsch＠gmail.com

I have finished scanning both binders. Please contact me private e-mail if you are interested in them. Steve --

13 years, 9 months

Seeking Commodore SX keyboard and cable

by dgriffi＠cs.csubak.edu

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?

13 years, 9 months

at&t unix pc

by emu＠e-bbes.com

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

13 years, 9 months

IP Fragments - Worth doing, testing strategies?

by bqt＠softjar.se

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

13 years, 9 months

identifying terminal by escape codes?

by jonnosan＠gmail.com

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

13 years, 9 months

Legendary steampunk computer 'should be built' - programmer • The Register

by woyciesjes＠sbcglobal.net

http://www.theregister.co.uk/2010/10/05/analytical_engine_build_call/ -- --- Dave Woyciesjes --- ICQ# 905818 --- AIM - woyciesjes --- CompTIA A+ Certified IT Tech - http://certification.comptia.org/ --- HDI Certified Support Center Analyst - http://www.ThinkHDI.com/ Registered Linux user number 464583 "Computers have lots of memory but no imagination." "The problem with troubleshooting is that trouble shoots back." - from some guy in the internet.

13 years, 9 months

← Newer
1
...
16
17
18
19
20
21
22
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb October 2010