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
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.
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/
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"
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
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
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
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
I finally got some terminals (VT525) and DEC MMJ cables for my MicroVAX 3100/85. I tuned it on expecting it to be dead and found a copy of OpenVMS V7.1 is installed on the MicroVAX (well after I tried both serial ports on the terminal and the screen came up at 9600 baud).
I have never owned anything DEC or any computers that didn't have built in video, sound, keyboards so I have a few questions.
What kind of reading material do I need to understand how these systems and software work?
Is there a default login/password for OpenVMS V7.1
Is OpenVMS available for download? Is V 7.1 optimal for this old unit (I think it has the full 128MB but have to check, dual 2GB? drives and built in CDROM).
I assume I can use some old PC or Mac software to login over the coax ethernet (does it do DHCP?) once I get some ethernet cables and I know what the heck I am doing.
What kind of server was a MicroVAX 3100/85 anyway (files, applications, etc)?
What are optimal setting for the VT525 to work with the MicroVAX (serial settings, color, lines, etc).
Figured I would try some completely different systems last year and ended up finding the MicroVAX before it was turned into razorblades. Took me a while to get the other parts needed.
TZ
On 8/23/10, Chuck Guzis <cclist at sydex.com> wrote:
> But I've seen people ditch their desktop 2GHz P4 system for a new
> desktop Core Duo box in the hope that it will make their dialup
> connection faster.
If you know any such people, they can ditch it at me. ;-)
Personally, when I get asked "how can I make my computer go faster?",
I tell people, "type faster. It's waiting on you."
Then there's the old joke:
How do you accelerate a Macintosh?
Toss it out the window and it'll go 9.8m/s^2.
-ethan