Of course the amiga 500 disk controller can be used...if you can write firmware for that :)

On 10/11/10, Eric Smith <eric at brouhaha.com> wrote: Apologies for any ambiguity, but to be clear, the genuine StarLAN transceivers I have are working fine on my 10BaseT network at 10Mbps, not 1Mbps. I was not trying to suggest you could plug a true 1Base5 StarLAN network directly into a 10BaseT network. Is it possible that different kinds of devices were all badged "StarLAN"? -ethan

On Mon, Oct 11, 2010 at 4:34 PM, Dave McGuire <mcguire at neurotica.com> wrote: Ok, I pulled out my 'black binder'. It's a copy of the AT&T Unix PC Reference Manual, and is for technicians doing component-level troubleshooting of the AT&T Unix PC logic board. It's pretty thick and contains sections on: * System Features and Functions * Logic Board Theory of Operation * Diagnostics * Logic Board Test Procedures * Schematics * PAL Equations * Mnemonics * Expansion Memory Locations As I said, it's pretty thick... has this been preserved in digital form somewhere? Mark

On Mon, Oct 11, 2010 at 8:26 PM, Dave McGuire <mcguire at neurotica.com> wrote: Ok, I'm open to suggestions. I have a scanner and can produce PDFs, but it would be a lot of pages. It would also take me some time, which is fine. Honestly, I've gotten so much out of this list and the discussions that, if I can give something back, that would make me happy. What's the procedure for doing this? Do I just give the PDFs I produce to bitsavers? Mark

On Mon, Oct 11, 2010 at 9:08 PM, Dave McGuire <mcguire at neurotica.com> wrote: If Al could send me the guidelines, I'll happily see what I can do. Mark

On Mon, 11 Oct 2010, Mark Davidson wrote: I have one of these here. Would be glad to split scanning duties with someone else. Where are these available? On bitsavers? Steve --

On 10/12/10 12:40 PM, John Foust wrote: Nice! How is its multi-platform support? I'm sure the doc organizing program is Windows-only, but what about the rest? -Dave -- Dave McGuire Port Charlotte, FL

On 10/12/10 12:58 PM, John Foust wrote: Wow, that sounds like a seriously nice device. I'm going to have to put that on my wish list. Thanks for the info! -Dave -- Dave McGuire Port Charlotte, FL

John Foust wrote: I have the S1500M (Mac OS X flavor) and have been able to convince it to produce files that I can make good enough for my purposes. What follows are some notes on what I've found and how I deal with it. Having been through the file boxes of old account statements, I turned my attention to books which I had multiple copies of so that I can have one at home and one at the office, for reference. One in PDF on the MacBook would be somewhat handier. I took Al's standards as a guideline. (See <http://bitsavers.org/>, look for the heading "The PDF DOcument Format" and start reading there, but I also got some verbal comments from Al and watched him do some scans with his setup.) 400dpi black-and-white scans, maybe 600dpi if there is fine-pitch text. The dot pitches given are indicated to support better OCR quality. Pages with primarily photographic content may be scanned as "grayscale" or "color" but this leads to them being saved through a DCT filter (i.e. JPEG-flavor lossy compression) in the PDF. Sometimes you have to choose what sucks less. I scan covers as 150dpi color documents (yielding JPEGs) with a flatbed scanner. Yeah, a bit chunky, but good enough for me. It can be important to create a ScanSnap scanning profile (preset) that forces black-and-white scans. In my experience letting the ScanSnap software make the decision how to scan a page will have it scanning yellowed or other non-white-paper pages in color with resulting use of the lossy DCT filter (and lower dpi too). One of the books I scanned early on was the Turbo C 2.0 Reference Guide. Yeah, I know, it's already up on bitsavers.org. I wanted to see how the output from the ScanSnap Mac software compared with the output from Al's process. The answer was, it produces PDF files that are two to three times as large. This is because it encodes black-and-white page scans with the Deflate filter, which is all very well and good and not lossy, but the CCITTFax filter simply yields better compression. The Acrobat 8 Pro (bundled with the ScanSnap) can do this for you: you set up a Preflight profile that includes the fixup "Compress all monochrome images using CCITT Group 4", and then open the PDF and execute that Preflight profile to re-compress the black-and-white page scans. I believe use of the Deflate filter is a (mis)feature of OS X Core Graphics; I observe that if I edit a PDF with Preview and save it, CCITTFax compressed monochrome images are re-compressed with the Deflate filter and the file grows much larger. Scanning is fast and easy and reasonably reliable. The ScanSnap is pretty good about detecting paper jams and misfeeds and multiple-page feeds; in 53000 pages through I think I've found one case where it didn't detect a multi-page feed. How do I detect that? I use Acrobat to number pages in the PDF with numbers that correspond to the page numbers in the scanned book. If they don't match up at the end I know I have a problem. Mind, for some books this can take considerable time. OCR is slow (a few pages per minute) but does sometimes come in handy for searchability. I'd like a version with an 11"-wide paper path: not only could I scan some more stuff, I could feed more originals through sideways for a shorter scan. Numbering the pages in the PDF effectively makes two sets of page numbers: physical page numbers (1, 2, 3, ..., n) and logical page numbers (the page numbers you put down in the PDF). This works OK when the PDF is viewed with Acrobat Reader or Preview: you see the page numbers you put down. It's not so useful when the PDF is viewed on an iOS or Android device; those readers show the physical page numbers. -Frank McConnell

[Unix PC schematics, etc, book] So would I, and I don't own a UnixPC. Reading old technical manuals is very interesting for me. And maybe one day I'll find such a machine, but they are very rare in the UK, and for various reasons I can't spend much money on classic computers at the momnet. But things can change... -tony

On Mon, Oct 11, 2010 at 6:34 PM, Dave McGuire <mcguire at neurotica.com> wrote: This is a fuzzy memory, but I do recall when I first got my 3B1s, reading about the Starlan it used and how it was not the same Starlan for which one can find a few bits on ebay. There was supposed to be a bridge device out there to 10BT ethernet. And of course there is the quite-rare 3B1 10BT card. I have at home a Starlan testing device! Not sure *which* Starlan that is for, though. -j

On 10/12/10, Steven Hirsch <snhirsch at gmail.com> wrote: It makes one wonder then how hard it would be to rig up a card with a Lance chip (7990) and either IDE or SCSI - I know there are "memory expansion" slots, but don't know how finicky the machine might be about borrowing some of that address space for I/O (or if the slots could decode regions already _in_ I/O space). Abstractly, I know how to do this on M68M machines, but I lack specific knowledge of the innards of the 3B1/7300 to predict how this would go. Of course, the expected market of such a peripheral would be somewhat small, and I suppose if it were easy, there would have been something like it 15 years ago. Still - it's easy to dream one up. Back when they were new, I would have loved to have had one, but they were priced far out of my reach (though many of my local friends who worked at the Columbus Bell Labs/Western Electric plant bought them through employee discounts - we were all part of a county-wide UUCP network in the days before ISPs and dialup PPP links were common. Later, many of the 7300s were gradually replaced by 386s running Interactive UNIX, which I _could_ afford). Was there ever an attempt made at a replacement, or was the nature of the machine (i.e., closed-source controlled by AT&T) such that user-initiated projects were doomed to fail? -ethan

Steven Hirsch wrote about the AT&T Unix PC (7300 or 3B1): However, the ".o" files for the kernel were available, which makes it somewhat more practical to hack than a linked kernel. At one time I was met someone who had the kernel sources, but was of course unable to give them to me. Eric

On 10/14/10, Eric Smith <eric at brouhaha.com> wrote: Unsurprising (given 16MB of range), but good to have confirmed. That would be when I would start - and maybe consider a WD33C93 (as found in the Amiga 3000) if the performance of the 5380 turned out to be an issue. Ah. Out of curiosity, did you happen to write it from scratch or did you have existing UNIX 5380 drivers to "borrow" from? That can be addressed with a real PCB prototype, but I probably wouldn't personally invest in a run of boards until driver issues were addressed. That is unfortunate - enough to make the whole process difficult. Perhaps a CPU-socket design is worth considering. 64 pin DIP sockets are still available. ;-) -ethan

On 10/14/10, Dave McGuire <mcguire at neurotica.com> wrote: Yeah... well... even so, the 5380, while trivial to hang off of a CPU, is not known for performance. Without a DMA engine, it might not be worth involving the 33C93 (for which there are probably fewer driver examples to borrow from). Ah... hadn't considered that arrangement. If that's true (I can't check myself), then that method is untenable (well... one could blow a hole in the case bottom and put the machine up on pegs...) I was more expecting that the CPU was under the PSU or the drive bay or otherwise cramped from the top. OK... next idea... a MC68010L-sized PCB with room for a MC68010FN (http://www.cpu-world.com/CPUs/68010/Motorola-MC68010FN10.html) and an SMT 5380. Sort of a "no slot clock" kinda of arrangement (same footprint, but perhaps only slightly thicker). The next most difficult thing to do would be to figure out how to get the SCSI signals off the board. Probably have to be a multi-layer board to get all the signals to all the right pins. The bonus would be that it would likely work in many, many MC68K machines (depending on the orientation of the off-board SCSI pins). -ethan

Dave McGuire wrote: Be careful, though. The Linux driver is GPL'd, and thus license-incompatible with the SYSV kernel. I imagine that the xBSD folks probably have some sort of 5380 driver, and it might be better to use that as the starting point. Eric

Ethan wrote: I was working from scratch, and was finding debugging to be exceedingly difficult. These days it would be somewhat easier as I have a good logic analyzer I could hook up to the MC68010. (An in-circuit emulator would be even better.) Yes, and there is enough clearance (barely) to fit such a thing in, though the MC68010 might have to be soldered in place as their might not be enough clearance for socketed components on the daughterboard. Eric

On Thu, 14 Oct 2010, Ethan Dicks wrote: Have you looked at the Intronix Logicport analyzer? A 500 Mhz. 34-channel USB connected unit for $389. I'm sorely tempted to pick one up. http://www.pctestinstruments.com Steve --

On Mon, Oct 11, 2010 at 3:11 PM, Eric Smith <eric at brouhaha.com> wrote: It would take some digging, but I've got more than one of these beasties, and I've also got the Wollongong software (as well as a LOT of diskettes for the Unix PC; I rescued a 3 machine setup from an owner who appears to have purchased every single option he could get his hands on). I've even got the 'black binder' which is the technician's field notebook for repairs, I believe. I can look at it and see if there's anything useful in it. I loved rescuing these machines and have set up 2 of them from the original (25 year old) diskettes, but I haven't had time to do much more than that. Mark