MikeS
Veteran Member
Sounds like something other people might also find very useful; go for it!
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
DOA PETs. (2001-8, 4032 and 8032)
- Thread starter Eudimorphodon
- Start date
dave_m
Veteran Member
Wow, you are right. It looks like there is such a configuration. From the parts list, the proper Editor ROM is P/N 970150-07 (it is listed as a 2516 EPROM). Does anyone have the .bin file for this chip? It does not seem to be in Zimmers.
The top assembly drawing in Zimmers unfortunately must not be the latest revision as it does not show the jumper arrangement for a -11 board (it stops at -08 ).
Is the 4000 series technical manual on the web or do you have a hardcopy?
Last edited:
Eudimorphodon
Veteran Member
There's a PDF of it on the "Bombjack" collection which a recent thread mentioned. From what I can tell it appears to be the source of most/all the schematics in the "2001N", "univ", and "univ2" schematic directories on Zimmers.
(Unfortunately there's no additional information to be found in it explaining the actual workings of the schematics at all. I just ended up printing out the PDF for it and binding it after I found it because doing so was far less cumbersome than sorting through which .gif files to print.)
The jumper arrangements for a -11 board are likewise missing from this edition of the schematic. If the 9" and 12" CRTs are not compatible somehow in terms of sync rates but *are* compatible electrically it could just be the ROM CRTC programming that's different, I suppose.
(Which bothers me somewhat. The 12" CRT is listed as "60hz" but is it not "NTSC compatible" in terms of sync rates/number of lines/etc? I hope a composite video adapter will actually work with the 8032's board, assuming its monitor is sick.)
dave_m
Veteran Member
I'm not a video expert, but looking at the video waveforms for the 9" and 12" screen, while both have a 60 Hz vertical rate, the 9" has about a 15.734 KHz horizontal rate and the 12" has a 20 KHz horizontal rate.
So, the 9" monitor timing seems to be NTSC compatible while the 12" perhaps may need something like the original NEC Multisync?
Last edited:
Eudimorphodon
Veteran Member
If the 12" screen really does refresh at a rate like that (Which... honestly sound suspiciously like what you might get if you ran a PAL-resolution monitor at 60hz) then I'm probably wasting my time building a composite adapter. Sigh.
carlsson
Veteran Member
As for composite adapters, a couple of years ago I tried to assemble one. With a 40 column PET, I got a picture that was out of sync but distinguishable text. With a 80 column PET, I got just garbage if even that. The adapter was connected to a regular 1084 though, not multisync in any way.
rmelick
New Member
I just finished restoring a 2001-8 from Albany Computer Services. http://rickmelick.org/pet/2001-8.html
Eudimorphodon
Veteran Member
I've created a similar kernel ROM image to try in my 4032. (EDIT: Don't see attached... explanation is below) It's pretty crude (I just borrowed some sample code from a 6502 simulator and hacked it) but it does slightly more than Ruud's in that in addition to initially filling the screen with some known characters it then goes into a loop where it cycles some blocks of characters on the screen forever.
My friend with the EPROM burner should be able to get me a burn of it by Thursday. I hope it works in real-life like it seems to on VICE.
If it works I guess I'll try to extend it to do a crude RAM check. (If I can figure out how to write a meaningful one that can run solely from CPU registers, that is.)
*EDIT* Don't use the kernal image I attached to this post. Before it was burned into a physical ROM I determined it had a bug which *appeared* to let it run properly in an emulator but could potentially cause unpredictable behavior on a machine with bad RAM. A fixed/better version is coming.
Last edited:
Eudimorphodon
Veteran Member
The 2001-8 Lives!
The 2001-8 Lives!
Today I decided to double-check the test ROM image I'd written before it was burned, and I discovered I'd made a newbie mistake in my assembly language. (I'd blown the subtle syntax distinctions between "immediate" and "zero page" versions of the lda/ldx/ldy statements, so in several instances where I thought I was "zeroing" a variable I was actually loading it with the contents of the first RAM location. This distinction was meaningless in VICE, which initializes RAM with all zeros, but obviously this might have bad consequences on a real piece of hardware.) So I rewrote it and much improved it.
This new version of the ROM does two things. First off, it does an elementary check on the first 1k of RAM. In this version it's pretty weak, in that all it does is write a single known value to the first 1k of RAM and try reading it back. If the readback matches a "g" gets written to a matching location in VRAM, while if it doesn't a "b" is written instead. (This test could miss a bad bit. I'm planning to revamp it so it does it twice, each time setting the even and odd bits.) After the RAM test it wastes about 2 seconds spinning through a nested delay loop, and then it writes VRAM with a full character set four times. Once done it runs a delay loop again and restarts from the beginning.
Anyway, the friend of mine with the EPROM burner also happens to be the person I gave the 2001-8 to, so he decided to try the ROM in his system this afternoon. And was nice enough to YouTube his results. Here's the first run. Notice the video RAM is all screwed up and the memory test indicates all b-s:
http://www.youtube.com/watch?v=KboRmKFsoUA
So... he decided what the heck, and fired up the soldering iron. This is the results after replacing the VRAM:
http://www.youtube.com/watch?v=EGlvn4J1Gtc
Memory test is still all b-s , but the video display is clean! So, now that he was hooked he looked in his junk drawer and found a set of 64k 4164 DRAMs. By bending up and jumpering some pins you can substitute those for 4108/4116s, so...:
http://www.youtube.com/watch?v=l5E8mpfBbZg
It passes the diagnostics! And finally, with a little more work re-jumpering the motherboard so it recognizes 16k instead of 8k and cleaning the keyboard:
http://www.youtube.com/watch?v=sbA02JSqVRE
Anyway. I've attached the ROM image seen in those youtube videos if anyone's interested. (rename from .txt to .bin, of course.) I'll be getting the ROM tomorrow, I'm keeping my fingers crossed it works on my non-CRTC PET. It may well just be bad RAM (that isn't amenable to piggybacking) that's stopping it from working!
The 2001-8 Lives!
Today I decided to double-check the test ROM image I'd written before it was burned, and I discovered I'd made a newbie mistake in my assembly language. (I'd blown the subtle syntax distinctions between "immediate" and "zero page" versions of the lda/ldx/ldy statements, so in several instances where I thought I was "zeroing" a variable I was actually loading it with the contents of the first RAM location. This distinction was meaningless in VICE, which initializes RAM with all zeros, but obviously this might have bad consequences on a real piece of hardware.) So I rewrote it and much improved it.
This new version of the ROM does two things. First off, it does an elementary check on the first 1k of RAM. In this version it's pretty weak, in that all it does is write a single known value to the first 1k of RAM and try reading it back. If the readback matches a "g" gets written to a matching location in VRAM, while if it doesn't a "b" is written instead. (This test could miss a bad bit. I'm planning to revamp it so it does it twice, each time setting the even and odd bits.) After the RAM test it wastes about 2 seconds spinning through a nested delay loop, and then it writes VRAM with a full character set four times. Once done it runs a delay loop again and restarts from the beginning.
Anyway, the friend of mine with the EPROM burner also happens to be the person I gave the 2001-8 to, so he decided to try the ROM in his system this afternoon. And was nice enough to YouTube his results. Here's the first run. Notice the video RAM is all screwed up and the memory test indicates all b-s:
http://www.youtube.com/watch?v=KboRmKFsoUA
So... he decided what the heck, and fired up the soldering iron. This is the results after replacing the VRAM:
http://www.youtube.com/watch?v=EGlvn4J1Gtc
Memory test is still all b-s , but the video display is clean! So, now that he was hooked he looked in his junk drawer and found a set of 64k 4164 DRAMs. By bending up and jumpering some pins you can substitute those for 4108/4116s, so...:
http://www.youtube.com/watch?v=l5E8mpfBbZg
It passes the diagnostics! And finally, with a little more work re-jumpering the motherboard so it recognizes 16k instead of 8k and cleaning the keyboard:
http://www.youtube.com/watch?v=sbA02JSqVRE
Anyway. I've attached the ROM image seen in those youtube videos if anyone's interested. (rename from .txt to .bin, of course.) I'll be getting the ROM tomorrow, I'm keeping my fingers crossed it works on my non-CRTC PET. It may well just be bad RAM (that isn't amenable to piggybacking) that's stopping it from working!
MikeS
Veteran Member
Excellent! I'm sure that ROM will come in handy.
Let's hope you have as much success with yours!
Fingers crossed...
Let's hope you have as much success with yours!
Fingers crossed...
Twylo
Experienced Member
Hi Rick,
Very, very nice job! Do you mind sharing how you painted it?
-Twylo
Very, very nice job! Do you mind sharing how you painted it?
-Twylo
MikeS
Veteran Member
Indeed; very nice!
Just curious:
Was that the original Commodore logo?
What does the "beeper" do? Monitor cassette activity?
How are you getting programs from the internet into the PET?
Eudimorphodon
Veteran Member
Fail
Fail
With much anticipation I plugged the PETTESTER ROM that worked so well on the 2001 into my 4032 and fired it up.
Squat. The machine is apparently too fouled to even run ROM code from CPU registers. I pulled all the I/O chips, all the extra ROMs, and tried just running it with nothing but the PETTESTER ROM and both of the 6502s I have on hand... again, absolutely nothing.
The possibility exists, I suppose, that the system is running the ROM code but is completely unable to write to VRAM, but... I don't think that's it. I'll try poking around later when I'm less fried and disappointed, but the few minutes of probing I did with my mini-scope before giving up made it look to me like the 74LS244s *might* be the problem. Maybe. I don't know.
Something of a disappointment, really.
Fail
With much anticipation I plugged the PETTESTER ROM that worked so well on the 2001 into my 4032 and fired it up.
Squat. The machine is apparently too fouled to even run ROM code from CPU registers. I pulled all the I/O chips, all the extra ROMs, and tried just running it with nothing but the PETTESTER ROM and both of the 6502s I have on hand... again, absolutely nothing.
The possibility exists, I suppose, that the system is running the ROM code but is completely unable to write to VRAM, but... I don't think that's it. I'll try poking around later when I'm less fried and disappointed, but the few minutes of probing I did with my mini-scope before giving up made it look to me like the 74LS244s *might* be the problem. Maybe. I don't know.
Something of a disappointment, really.
dave_m
Veteran Member
Yes, you tried about everything including putting in known good ROMs, so the problem must be in the 8 bit data path or the 16 bit address path.
Be patient with the probing and you should find some suspicious looking signals that look open (~1.7V DC) or shorted. All it takes is one cold solder joint to mess up a computer. And as you say, it could be one of the transceiver chips.
Hang in there.
Eudimorphodon
Veteran Member
I don't know. I'm re-evaluating whether I'm capable of doing this either mentally or emotionally. I'm not a strong believer in predestination or fate but the fact is out of three picks I got zero working ones, and the one of the three I gave away turned out to be the easiest to repair. It's sort of hard to avoid thinking that the universe just doesn't want me to get any joy out of this endeavor.
I wasted a few hours on this today, which I probably shouldn't of. I bought a random selection of replacement logic, mostly chips related to the address and data buffers and the related decoding and some sockets. Then I found an old ISA multi-I/O card that had through-hole logic and tried desoldering a few chips off it. Better part of two hours to replace two 20 pin chips with sockets and I probably scorched the board. GOOD JOB!
Anyway. Leaving the (garbage-bound?) 4032 alone for the time being I tried piggybacking a 74LS10 on the one where it appears the output from the video shift register stops on its way to the video port on the 8032. (As determined during the diagnosis session with Twylo. He loaned me a better oscilloscope so I can at least see if I'm seeing the same patterns as before or not.) No change. I even tried bending the output pin (12) for that NAND gate up in case something downstream were somehow shorting it out to ground... nothing. Either the output on that pin is *supposed* to always be inhibited (which doesn't make sense to me based on the input signals), my replacement 74LS10 is bad, or the "bad chip" is pulling down the input signals enough to prevent piggybacking from working... or something.
I did yank the motherboard and flip it over thinking I might as well try installing a socket, but after staring at the back of it for five minutes I lost my nerve. Between my terrible execution and having no idea what the signals look like in a working 8032 (thus meaning I might be scorching my board for nothing) it seems like a bad idea today.
I guess these particular PETs really wanted to go to that landfill.
dave_m
Veteran Member
If you are a novice with soldering, a good technique to use in replacing a chip is to cut off all the legs of the IC (close to the top of the chip) before trying to unsolder anything. That leaves only the legs sticking out of the solder pads. Now using solder wick, clean each hole of solder one hole at a time. If it starts to take a lot of time, just wait until it cools and try again.
It will take less time at each hole (since there so little mass without the body of the IC acting like a "heat sink"), and therefore less heat this way and it will protect the board from excess heat.
That being said, you should not replace parts without a good probability that the part is bad. Otherwise you are "Shotgunning" the problem and, by sad experience, we all know that leads to disappointment.
Methodically check the bus lines and the address lines looking for suspicious signals. At this point, I think that is a better plan of action on your stubborn PET.
Looking at the schematic, input pins 2 & 13 should be mostly high, enabling the video signal on pin 1 to pass through the NAND gate. Do you see a lot of pulsing on pin 1? If not, the problem is upstream of that gate.
Eudimorphodon
Veteran Member
The "PETTESTER" runs!
The "PETTESTER" runs!
So... I decided to clean up the 4032's motherboard a little bit. After wiping off some of the grossest dust/muck deposits with alcohol and letting the board dry I reinstalled a 6502, 6522, and that testing ROM I cooked up and fired the machine up prior to deciding where to start with the oscilloscope probing.
The machine looks just as "dead" as it did, but... this time I noticed a character "twitch" several seconds after it came up. And several seconds after that, another. With more observation I've determined that the interval appears to be correct for the RAM/VRAM test cycles in the ROM. The characters that change are not consistent in either their placement nor their values, but they do *change*. I pulled the diagnostic ROM and, viola, no more changes. So I think it *is* running the code. (Whether that has anything to do with me cleaning the board is its own question.)
For kicks I piggybacked the 2114s RAM chips with the replacements I purchased, and now I'm *sure* that the ROM code is running, at least for a while. (see later) The values which appear on the screen still appear to be scrambled, and large sections of the screen don't change at all. But again, the interval is correct, and the number of changing characters increases when the RAM is piggybacked. (My theory is that the existing RAM may be outputting *many* stuck bits, and perhaps piggybacking makes the block more "mutable".) The troubling thing is that sometimes it seems as if the program crashes after several repetitions. (Or sometimes doesn't start at all.) In any case, it seems like the updates to VRAM will peter out eventually. But it's not consistent. (Sometimes it seems to happily flip the screen for at least several minutes.)
A physical examination of the board shows what may be damage to the address decoder in UB3. (The chip has a really cruddy, almost burnt looking spot between pins 15 and 16, which are... input for address line eleven, output for 10? Oddly/coincidentally enough if those lines were completely dead I *think* the program in ROM should be able to manage....) I piggybacked on top of it and I think I *may* see more activity in the second half of VRAM, but the behavior is random enough I'm not comfortable enough to declare that diagnostic.
Anyway. I think I may be sold on the need to replace video RAM. The onscreen patterns do change drastically when it's piggybacked. But somehow I think that isn't the only problem. The question is whether I can do it without destroying anything.
The "PETTESTER" runs!
So... I decided to clean up the 4032's motherboard a little bit. After wiping off some of the grossest dust/muck deposits with alcohol and letting the board dry I reinstalled a 6502, 6522, and that testing ROM I cooked up and fired the machine up prior to deciding where to start with the oscilloscope probing.
The machine looks just as "dead" as it did, but... this time I noticed a character "twitch" several seconds after it came up. And several seconds after that, another. With more observation I've determined that the interval appears to be correct for the RAM/VRAM test cycles in the ROM. The characters that change are not consistent in either their placement nor their values, but they do *change*. I pulled the diagnostic ROM and, viola, no more changes. So I think it *is* running the code. (Whether that has anything to do with me cleaning the board is its own question.)
For kicks I piggybacked the 2114s RAM chips with the replacements I purchased, and now I'm *sure* that the ROM code is running, at least for a while. (see later) The values which appear on the screen still appear to be scrambled, and large sections of the screen don't change at all. But again, the interval is correct, and the number of changing characters increases when the RAM is piggybacked. (My theory is that the existing RAM may be outputting *many* stuck bits, and perhaps piggybacking makes the block more "mutable".) The troubling thing is that sometimes it seems as if the program crashes after several repetitions. (Or sometimes doesn't start at all.) In any case, it seems like the updates to VRAM will peter out eventually. But it's not consistent. (Sometimes it seems to happily flip the screen for at least several minutes.)
A physical examination of the board shows what may be damage to the address decoder in UB3. (The chip has a really cruddy, almost burnt looking spot between pins 15 and 16, which are... input for address line eleven, output for 10? Oddly/coincidentally enough if those lines were completely dead I *think* the program in ROM should be able to manage....) I piggybacked on top of it and I think I *may* see more activity in the second half of VRAM, but the behavior is random enough I'm not comfortable enough to declare that diagnostic.
Anyway. I think I may be sold on the need to replace video RAM. The onscreen patterns do change drastically when it's piggybacked. But somehow I think that isn't the only problem. The question is whether I can do it without destroying anything.
Druid6900
Veteran Member
Look, if you aren't comfortable with soldering and desoldering, then something that old isn't the thing to be practising on.
Perhaps your best bet is to send the motherboard to someone who is used to the work required to replace ICs that has the same unit type and let them repair it, test it in their rig and send it back.
And I don't mean me. The only PET I had went to MikeS along with a dual drive for it because I don't have time to work on stuff that none of my clients will ever want.
It might be better than destroying a repairable board.....
Perhaps your best bet is to send the motherboard to someone who is used to the work required to replace ICs that has the same unit type and let them repair it, test it in their rig and send it back.
And I don't mean me. The only PET I had went to MikeS along with a dual drive for it because I don't have time to work on stuff that none of my clients will ever want.
It might be better than destroying a repairable board.....
Twylo
Experienced Member
Hi Eudimorphodon!
Sorry I'm so late to the party (again), I've been catching up on a bunch of other stuff this weekend.
Sounds like you're making some progress, at least! I have a few words of advice about desoldering if you do want to go down that path.
Number one, it's incredibly important to have a good temperature controlled soldering iron for desoldering. A simple plug-in solder pencil or (God forbid) solder gun is absolutely, 100% not going to work
As you've discovered, they just scorch the hell out of things. They're not cheap, but you can get a totally reasonable temperature controlled soldering station for between $80 and $150, and they should last a lifetime. I've had mine for 15 years now, moved it across country three times, dropped it down the front steps, and it's still going strong Hakko or Weller both make awesome stuff.
And number two, flux is your friend! I can't emphasize enough how much of a difference it makes, it's night and day. Get a jar of brush-on liquid flux or a syringe of flux paste and apply it liberally to both the solder side and the component side around each lead. It'll smoke like crazy, but that flux is going to help the solder flow so much better when you're removing it. After the component is out, you just need to clean it up with some alcohol.
Number three is your choice - solder sucker, desoldering braid, or both. I use both. I like to use the solder sucker first, and then the braid for touch-up. I really like this guy's video on how to use a solder sucker, he looks like he's really experienced: http://www.youtube.com/watch?v=Aw4lZGk90i4
If you practice a little more, I think you'll find you can totally do it.
-Twylo
Sorry I'm so late to the party (again), I've been catching up on a bunch of other stuff this weekend.
Sounds like you're making some progress, at least! I have a few words of advice about desoldering if you do want to go down that path.
Number one, it's incredibly important to have a good temperature controlled soldering iron for desoldering. A simple plug-in solder pencil or (God forbid) solder gun is absolutely, 100% not going to work
As you've discovered, they just scorch the hell out of things. They're not cheap, but you can get a totally reasonable temperature controlled soldering station for between $80 and $150, and they should last a lifetime. I've had mine for 15 years now, moved it across country three times, dropped it down the front steps, and it's still going strong Hakko or Weller both make awesome stuff.And number two, flux is your friend! I can't emphasize enough how much of a difference it makes, it's night and day. Get a jar of brush-on liquid flux or a syringe of flux paste and apply it liberally to both the solder side and the component side around each lead. It'll smoke like crazy, but that flux is going to help the solder flow so much better when you're removing it. After the component is out, you just need to clean it up with some alcohol.
Number three is your choice - solder sucker, desoldering braid, or both. I use both. I like to use the solder sucker first, and then the braid for touch-up. I really like this guy's video on how to use a solder sucker, he looks like he's really experienced: http://www.youtube.com/watch?v=Aw4lZGk90i4
If you practice a little more, I think you'll find you can totally do it.
-Twylo
Eudimorphodon
Veteran Member
Here's where things stand now.
I'd been practicing with a low cost-ish Weller digital temperature controlled soldering station. After nuking a few more pads off the test board I finally found a video which clearly explained what the he** I was doing wrong with the Soldapullt, and... now I still suck, but I'm not a complete menace.
So... for the heck of it I tried the shotgun approach and replaced the video RAM. The verdict is... that wasn't the problem, at least not most of it. (On the bright side I haven't seemed to have made anything worse. Replacing it was a case of "I have to start somewhere, and doing so rules something out".)
The ROM tester (as seen in those video links I posted a while back re the 2001-8) is running. However, with the machine "as it is" you'll see a screen update essentially once in a blue moon. If I piggyback 74LS244s on top of the data buffers in E7 and E8 The number of screen locations which updates increases. (You can get more than half the screen toggling back and forth.) But tellingly, the actual value written to the updated screen locations is unpredictable, which should *not* be the case. (Any given spot should be toggling between "either a b or a g and a mathematically predictable PET-ASCII character" every two seconds or so.) The number of updated characters also increases if I piggyback the upstream buffers at E9 and E10, but not by as much as piggybacking the "closer" buffers.
In any case, I smell a rat. I could just try replacing those buffers, but I have no faith that they're the problem. My pathetic guess is that there's a weak or intermittent chip select that's causing "random noise" to be all that makes it through the buffers to the VRAM data bus. (This is the same area we got that *really noisy* trace from your logic analyzer.) Perhaps piggybacking the younger chips is are allowing "more noise" to get through but there's still massive data corruption.
I don't know if this is something I'll be able to figure out with just an oscilloscope or not. (I'm digging through the schematics now to try to figure out if I have any chance at all.)
If you're still interested in having a guinea pig to try your new fancy test equipment on just let me know. :^b