Re: Resurrecting integrated circuits by cooking them.
On 2019-07-24 13:31, Jeffrey S. Worley via cctalk wrote: Yesterday evening, in the process of refurbishing five very badly treated Atari 800 computers I had a hunch and subjected a failed Pokey chip (Atari Part CO12294 Wikki link https://en.wikipedia.org/wiki/POKEY ) to high heat by way of the barrel of my soldering iron until saliva evaporated from it in about 1 second. The chip, which did not work before in any of the machines now works perfectly. Pokey (see wikki link) is common to all Atari 8-bit computers and common in many Atari coinop video game systems. These chips are becoming scarce, so much so there is a sort of replacement being manufactured https://hotrodarcade.com/products/pokeyone-atari-pokey-chip-replacement-for-atari-arcade-games . The replacement Pokey only emulates the audio portion of the original chip, leaving the PotKEY part unimplemented. Pokey gets its name from Potentiometer Keyboard. It also handles the Atari SIO peripheral signals, so without those an Atari computer cannot use standard peripherals like serial disk drives, and other common interfaces. Thus, for Atari computers a true Pokey is a must. I stumbled upon a fix for this one and wonder if I reinvented the wheel or if this information may be of use to the group in treating other sorts of chips. Reflowing is a treatment for a lot of hardware these days and generally regarded as a hack which won't last. As modern hardware, CPU's and video chips in particular run very hot, I can see how this might be, but Pokey and most of the stuff we work with don't have this environmental restriction. Most of our gear runs at 40 degrees centigrade or lower. So I'm guessing the problem with my disused chip was oxidation within the package and that cooking the chip a bit cleaned things up? Any advise or observations would be appreciated. I tried this on another chip the same evening, an Antic. The Antic DID work for a second or two, whereas it had before given no signs of life, but then returned to its failed state. Best, Jeff (Technoid Mutant) I tried this a year or two back with about 30 x SID, VIC, and PLA chips out of C64's. I heated them in the oven at about 250 for 15 minutes. None of them showed any more signs of life than before I tried it, unfortunately. -- -Pete Rittwage
Re: Apple ][+ Keyboard
On 2019-05-22 11:56, John Many Jars via cctech wrote: I feel like I'm falling down a rabbit hole with this old ][ europlus I've had for years. The smoke came out of the power supply, so I replaced it with one from ReactiveMicro. Now it boots, and was working okay, until this morning. Now, no keyboard if you hit ctrl-reset. All other keys are ignored. Anyone have any ideas? (: Thanks, John (aka Mark) I've had that issue. If you or someone over the years accidentally plugged in the keyboard cable wrong, it blows one or both of the 7400's and if you are unlucky, the unobtainable keyboard encoder. They could of course also break from a PSU surge or static. -- -Pete Rittwage
Re: EPROM baking
> Hi, > >> On Wed, Dec 13, 2017 at 9:08 AM, Mark G Thomas via cctalk < >> cctalk@classiccmp.org> wrote: >> >> > Hi, >> > >> > I am working on several projects requiring 2708 and 2716 EPROMs, and >> > am finding some of my chips will not erase, and some will not take >> > a program. I've also learned more in the past week than I wanted >> > to know about repairing Data-I/O 29a/b programmers. >> > >> > I vaguely remember in the 1990s baking such EPROMs in the oven, but >> > I do not remember temperature or time. I was surprised that Google >> > didn't turn up anything useful with this info. >> > >> > I'm sure someone here will have some notes on EPROM baking. >> > >> > Mark >> >> Mark, >> >> If this is an issue about reviving bad eproms? I assume you have tried >> the >> regular stuff. >> >> What process are you using now to erase 2708/16's? I have a simple >> eraser >> unit and it seems to always work. Some eproms go bad but I never have >> issues with erasing them. My point is that maybe you need a better prom >> eraser unit. > > They seem to erase fine, using a PRO-LOG 9103 eraser (box, timer, tube...) > >> I would avoid baking them until you have exhausted other >> options. Not sure what others think. This topic has come up before >> here, >> about putting them outside and all that. The erasers are all over ebay, >> and the hardware store is full of the correct types of lighting, why not >> make a box that will do the job?I assume there is more to it that >> simply erasing them. >> >> >> Bill > > Erasing seems to work fine. It's the re-programming them that is the > problem. > > On Wed, Dec 13, 2017 at 02:49:39PM +, dwight via cctalk wrote: >> When I was at Intel, years ago, I recall the baking was only to repair >> the retention of the EPROMs. It was not to fix random failures. >> >> It sounds like your EPROMs have various failures that wouldn't be helped >> by baking. >> >> Each time the EPROM is programmed, there is a slight increase in the >> leakage of the floating gate. This was typical after thousands of >> program/erase cycles. Baking them repaired the damage to the insulating >> layer that was damaged. >> >> Dwight > > I don't think these chips have been reprogrammed many times. It seems more > age related, affecting some brands/models in my spares but not others. > > The failure mode is the chips erase successfully, but any attempt to > program them fails, and they still test blank and read back "...". > Some of these were chips I erased years ago before putting in my spares > drawer, and some had fine working code on them, but I erased them to > re-program with a newer version of software on them, to discover I could > not. > > My stash of TI and NEC 2732s seem to have the disease, but my ST, > Mitsubishi, and several others program fine. > > In the case of a bunch of 2732s, I have tried both a vintage DataI/O 29A > programmer and a modern Batronix programmer, with the same results. > I don't think I have a programmer problem. > > I still swear someone in the late 80's had me baking EPROMs in an oven > to restore their programability, but I don't remember the specifics. I > tried a few at 450F for 15 minutes, but they still won't program. > Are you positive you have the programming voltage right? I have a box of really old ones and every time I have to research a little to find the right voltage for different brands. All 27128's are not the same, for example. Some are 12V, some may be 25V (for example). My programmer only has one setting in the software, and I have to change jumpers to modify programming voltage. My USB programmer won't touch any of the old ones because I assume it can't provide enough voltage/current for them. -Pete Rittwage
Re: Preventing VAX running VMS / Multinet from being used as SMTP relay
> I have a microvax set up with VMS 5, running MULTINET (and decnet > locally). The server has a FQDN and after a while being exposed to the > WWW someone out there started using the server as an SMTP relay. I can > disable and clear the queue, but I'd like to block entirely this from > happening in the first place. I'd like to learn more about how this > happens in VMS. > > Anyone have had this same problem before? I realize back when VMS 5 was > current it was not so much of an issue, but today it is. I am working on > a > solution. I can envision a few ways including blocking the smtp relay > port > from the firewall, but if possible I'd like to set up a VMS Multinet > solution as a learning exercise. > > I am open to suggestions, and once I find the solution I'll post it. > > I understand that this kind of thing is not cookie cutter, there are > different levels one could address something like this. I have a comcast > business router, and one of the 5 IPs I have is NAT assigned to the > internal 10.1.10 port of the microvax. > > This is the same machine I wrote about previously as with then, thanks for > your help. I find the best way to learn is on the actual hardware warts > and all. > > Bill > You should never use one-to-one NAT like that. You should only forward the ports you need from the firewall to your server. In this case, I assume you only need tcp/23 for telnet from the outside? -- Pete Rittwage
