test-drb

test-drb@ccmp.vtda.org

101090 discussions

by pontus＠Update.UU.SE

Hi Somewhat offtopic (and old), but interesting. Does the d|i|g|i|t|a|l cassette mean that it is a DECcassette they are using? http://pluggedin.kodak.com/post/?id=687843 Cheers, Pontus.

15 years, 7 months

using localtalk bridge

by jlobocki＠gmail.com

has anybody tried localtalk bridge ( http://docs.info.apple.com/article.html?artnum=60290 ) in their mac setups? I was thinking of taking one of my old LC slabs and throwing a $10-$20 ethernet card in, throwing a phonenet dongle on the modem port, either loading the hard drive with a low os with all but the needed extensions and files removed, or the same on a floppy, and just using it like a router, with its only purpose being passing data between the apple ethernet segments and the apple phonenet segments(which at this time is only my SE as every other mac has ethernet).

15 years, 7 months

Making flyback transformers?

by ard＠p850ug1.demon.co.uk

As some of us know all too well, flyback transofrmers fail, and are often next-to-impossible to get. So I have been wondering if it's possible to make a replacement... There would appear to be 2 parts to this. 1) Desigining the replacement. I think we can assume a schematic of hte horizontal output stage it's going to be used in. But how do you calcualtor the number of turns on each winding? Since the origianl is likely ot be potted in epoxy (for HV insulation reasons), counting the turns there is impossible. Are there any good references (books, web pages, etc) on the desing of such transoformes and/or the design of horizotnal output stages? I would have thought something must exist, but I've never seen it. 2) Making the replacement. It owuld ahve to be vacuum pmpregnated, I think. But I believe some model engineers who make internal combustion engines make the own ignition coils (and vacuum-impregnate them?). Again, any good references on doing this? -tony

15 years, 7 months

Video TECO

by n.theodore.matavka.files＠gmail.com

Hello, World! I took a cursory look through the archives at classiccmp, and I was disappointed to discover that the response to my having found the Video TECO tarball was lukewarm to negative. I understand that I may have committed a few mistakes along the way, but this was compounded by the fact that several other messages that I had written clarifying my reasons were not additionally sent to classiccmp. First of all, I had asked for and received permission from Paul Cantrell, my flying instructor, to have the source code. I had looked for it on sourceforge in vain, as the downloads section was completely empty. This was when I asked Paul to send me the source, which he did. In addition to this, I found a patch for Video TECO on another Web site, with a dead link---I also requested and received the patch. Only lately did I discover that the Video TECO tarball was available on CVS. Second, I understand the issue with licencing, and I take this moment to apologise. My actions were wrong, and I made the stupid error of not looking to see in the file whether there was a licence or not. My reasoning for publishing it under Sleepycat was the additional clause that if the software is bundled, the software it is bundled with should also be open source. I see now that I was mistaken, and I apologise for all the inconvenience it may cause. Third, I apologise for perhaps being unclear in my first post. For instance, Mr Alderson mistakenly believed or believes that I had implied that the original Video TECO (for DEC PDP's) had been lost. No, it hasn't, and yes, I've heard of it. alt.lang.teco? Seriously? There hasn't been a new post there in months! What there is is generic Viagra and "V1c0d1n" spam! Yes, maybe some of the other newsgroups I should perhaps have asked, but I thought I could have been excused from that as I did have the source code straight from the horse's mouth so to speak. Mr Stephens: there's a patch available that should fix your problems; it's on my Sourceforge site. Also: yes, I've made a few mistakes, but if someone would please help me on this project, it would be greatly appreciated. I am writing documentation for it (using Cantrell's very rough html file and some DEC manuals as a base), several pages per day, but I can't do the whole thing by myself. I mean, I can finish the docs by myself in a week or two if I work hard, but the rest of it might be a more dicey proposition. Cordially, Ted Matavka.

15 years, 7 months

Wanted: HP 7970E

by mloewen＠cpumagic.scol.pa.us

I'm still looking for an HP 7970E 9-track tape drive and a 13183A interface card. If you know of one available (preferably in working order), please let me know, off-list. Mike Loewen mloewen at cpumagic.scol.pa.us Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/

15 years, 7 months

Should you correct production mistakes?

by lbickley＠bickleywest.com

I posted this last Wednesday - but for some reason, it didn't make the "cctech" list. I'm posting it again FYI... Cheers, Lyle ---------- Forwarded Message ---------- Subject: Re: Should you correct production mistakes? Date: Wednesday 25 August 2010, 17:20:22 From: Lyle Bickley <lbickley at bickleywest.com> To: "General Discussion: On-Topic Posts Only" <cctech at classiccmp.org> On Wednesday 25 August 2010, Eric Smith wrote: > I wrote: > > Had we found any problem analogous to that in the PDP-1 restoration, > > where the machine operated correctly despite a manufacturing defect, I'm > > sure we would have had a debate on whether to fix it. I think my own > > opinion in that case would be that we should leave it alone, but tag the > > module (paper tag attached with a short loop of string) and document the > > issue in the system logbook. > > > Fred Cisin wrote: > > In the example that I mentioned of an IBM MDA board, it worked for about > > 10 years, and then became intermittent. Even that, I would NOT consider > > to be "operates correctly", as the particular defect IS a defect, and may > > eventually bring the system down. > > I think the way that I would state it is that just because the system is > working correctly (at the moment) doesn't mean that it isn't broken. > > Part of the reason I don't think we'd fix such a problem in the PDP-1 is > that the PDP-1 isn't doing anything criticial. We can afford to have > downtime if a latent problem eventual causes a failure. If we've > properly documented that latent problem, we can check for it when the > system does fail, and fix it if necessary at that time. To be specific, during the original restoration, we checked every solder joint in the PDP-1. We found four bad connections. We then reviewed the implications of the bad connections in terms of function and reliability. The Team decided to only repair two of the connections because they could affect normal operation and demoing of the system. We left the other connections "loose". As Eric already stated, we documented everything and labeled all changes (fixes) we made. BTW: We have never experienced a problem with the "unfixed" solder joints ;-) Cheers, Lyle -- Lyle Bickley, AF6WS Bickley Consulting West Inc. http://bickleywest.com "Black holes are where God is dividing by zero"

15 years, 7 months

New acquisition...

by mdavidson1963＠gmail.com

All the boxes finally arrived (and I still have to go through everything), but I am the proud owner of an Epson QX-10... with original manuals, newsletters from a users group and a nice collection of software... CP/M, Valdocs 2, Valdocs 3, dBase II, PeachText, Uniform and a bunch of other diskettes (easily 7 or 8 of the 10-disk holders). I'll post pictures and more info as I go through the boxes, but this is quite exciting! Mark

15 years, 7 months

EPROM programming (27c160's)

by ian_primus＠yahoo.com

Well, I am stumped here. I have been fighting with this for a while and I can't figure it out... I use an old Needham's PB-10 EPROM programmer. Best device programmer ever, as far as I'm concerned. It's fast, reliable, and the software is so nice and easy to use. Only problem - it's old, and doesn't support 16 bit devices. I really need to be able to program 27c160 and 27c322 devices. So, I built an adapter. I bought a 16bit adapter intended for those cheap and nasty Willem programmers. I made some minor modifications to use it with my Needhams, and added toggle switches for the upper address lines. Now, I can program larger devices in chunks. This worked perfectly for the couple of chips I had at the time - two 27c160's and two 27c800's. So, I bought more chips. 27c160's and 27c322's. The 27c322's work flawlessly. I can program them in four passes, the programmer thinks it's programming a 27c080. But 27c160s... I am having horrible luck with them. A couple out of the batch programmed. The rest did not. I was able to fill them with zeroes, but couldn't program data - it kept erroring out at various stages. Tried erasing/reburning, same thing. Finally got fed up and bought another batch from a different seller, assuming I just had some bad ones. Nope. SAME problem. I noticed a pattern: On chips with a date code before about 2000, the die is larger, and none of these want to program. On chips with a date code after 2000, the die is smaller, and some of them program perfectly, others get most of the way through before erroring out. In all cases, I'm working with ST brand chips - I haven't found any other manufacturer available. So, carefully reading the datasheet, I notice that the 27c160 wants a program pulse of 50us. The chip that the programmer thinks it's programming, a 27c040, uses a programming pulse of 100ns. The programming waveforms between a 27c160 and a 27c040 look the same to me, besides that. But it would seem that my problems lie with the waveform being incorrect, and newer chips being less picky about it than the older chips of the same part number. Now, I'm stumped. I *really* want to make this programmer program these chips. It does everything else properly, including program 27c322's with this adapter. Now, I know the adapter is wired correctly, because I have programmed newer rev 27c160's properly, and they have worked perfectly in their intended purpose. The adapter is wired up such that in 27c322 mode, the programmer is used as if it were a 27c080, and in 27c160 mode the programmer is used as if it were a 27c040. I did it this way due to the pinouts of the devices and the required programming algorithms. Basically, I am wondering if any of our resident gurus have seen behavior like this with EPROMs, and if there may be anything I can do to shorten pulses, buffer, or something to get this to program... or, if anyone just *happens* to have the source code to the EMP software laying around somewhere... Yeah, I know, long shot. Failing that, does anyone have a suggestion of an EPROM programmer that I can buy that will program 27c160's. Preferably something that can be operated from DOS over a parallel or serial port, or better yet, an ISA card. -Ian

15 years, 7 months

Article on first edition UNIX in IEEE Annals of the History of Computing

by joachim.thiemann＠gmail.com

For those that have access to IEEE Xplore (or a decently stocked library), the latest issue of the IEEE Annals of the History of Computing has an interesting article on restoring the first edition of UNIX (from paper copies, Al Kossow is mentioned) by Warren Toomey. The abstract: "Until recently, the earliest versions of the Unix operating system were believed to have been lost completely. In 2008, however, a restoration team from the Unix Heritage Society completed an effort to resurrect and restore the first edition Unix to a running and usable state from a newly discovered listing of the system?s assembly source code." Interesting read! Fun statement I noticed, with respect to the "factory faults" thread that is ongoing: "Should bugs or faults found in the leg- acy software be fixed, or should the envi- ronment be modified to work around the problem?" (p. 78) Joe. -- Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem

15 years, 7 months

dg 1200 queries

by jwest＠classiccmp.org

After some very minor cleanup and front panel fixing, the DG1230 seems to spring to life. I can deposit and examine different values from all four cpu registers, as well as small random ranges of memory. I've been skimming some of the DG docs I have, but I am coming up short on knowledge on a few points and was wondering if someone could shed light on any of these items or better yet, direct me to the appropriate manual that I can't seem to find. 1) In DEC & HP documentation, I can find a fair number of "front panel dittys" to perform basic tests in the absence of I/O devices. I can find no such short programs for the DG1200. Before I attach an I/O device (CRT, Cassette, or paper tape) I'd sure like to feel more confident that the cpu is on fairly solid ground. Unless someone knows of some docs on short front panel test programs, I'll just write a few short "copy range of memory from A to B, etc." programs myself and hand assemble them. 2) At the bottom of the backlane are several small pin connectors - P5, P6, P7, P8, and P9. Going from memory, but they are something like 2 rows of about 10 pins per row for each P connector. I can't seem to find where these are documented. Can someone point me to the right manual? They don't even show up on the backplane diagrams I have. 3) On most of my DG12xx cpu's, the backplanes don't have extra wiring, other than what is obviously going to a device. But on this one, Pin 10 of backplane connectors 2 through 12 is daisychained. I believe the signal is "VINH". I can't seem to find documentation on this. I'm guessing it has to do with allowing (or disallowing) memory cards in slots other than slot 2, but I'd like some better understanding as to when and when not this jumper set should be present. 4) Again, on most of my DG12xx boxes, the backplane has nothing other than I/O connections. But on this one, pin 96 (intp in) slot five is wrapped to pin 95 slot 16 (intp out). Likewise pin 94 (dhcp in) is wrapped to pin 93 slot 16 (dhcp out). I do have some idea what this is for, but I'd like a better understanding as to when and when not this jumper should be present. This has got to be documented/explained somewhere, but I sure can't find a discussion of it. Thoughts? I'm guessing this jumper is only required to get DHCP to the upper I/O card section on the "jumbo" version? Thanks in advance for any thoughts! Jay

15 years, 7 months

Jump to page:

2026

2025

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