Installed 74F08 in 800XL, machine no longer boots

[+x=usr(1536)]

@kheller2: to answer your question about PCB revisions:

 

 

Part no. CO61851, Rev. C.  Datecode looks like 0884.

[+scorpio_ny]

Hi @x=usr(1536),

 

I just happened go to a website that offers a pictorial fault guide for the Atari 8-bit. He has list of things to look for a try specifically for a red startup screen. Maybe you can try some of the easier ones to see it if fixes your issue:

 

Atari 8-bit (400/800 XL/XL) pictorial fault guide

[+x=usr(1536)]

21 hours ago, scorpio_ny said:

Hi @x=usr(1536),

 

I just happened go to a website that offers a pictorial fault guide for the Atari 8-bit. He has list of things to look for a try specifically for a red startup screen. Maybe you can try some of the easier ones to see it if fixes your issue:

 

Atari 8-bit (400/800 XL/XL) pictorial fault guide

Thanks, and the pointer is definitely appreciated.  FWIW, I'm not getting the red screen at boot - I'm getting nothing at all.  A video signal is being generated, but it's just black.  Even Star Raiders doesn't run.

 

From where things are sitting right now, the 256K upgrade is just confusing matters.  I'm hopefully going to have some time to spend this weekend rolling the machine back to being a functional (mostly-) stock 64K system, at which point it should be possible to start troubleshooting a little more clearly.

[+x=usr(1536)]

These arrived today:

 

 

Current plan is to use one for the 800XL (I'll repurpose the ICs on the existing expansion's logic board for that machine), and build up the other two for the 600XL and 1200XL.  That should put all three of the primary machines on an equal footing in case one ever croaks.

 

Can't do anything with them until the weekend after next, but at least it'll give time for parts for the other two to show up and be ready to go

[+x=usr(1536)]

Memo to self: pulled the 74F08, checked continuity from all wipes in the socket at U18 to their destinations.  No problems.  This matches previous results as well as the Sams' Computerfacts schematics.

 

Checked the RAM expansion logic board.  Found that the connection between pin 12 of the PIA and pin 4 of the 74LS153 had come adrift, but not visibly so.  Repaired and reinforced with a vengeance.  Could have happened last time I was in there after I had checked it; could have happened after opening the machine up this time.  No way of knowing.

 

Found evidence to suggest that R20 (3KΩ, 0.25W) may be damaged internally and is not always passing current.  Will replace along with R16 and R19 (same spec as R20), R80 (1KΩ, 0.25W) and C43 (0.1µF, 25V, ceramic axial).  That'll shotgun everything in the vicinity of U18 that was likely to have been damaged.  They had been checked before, but I guess this was my lucky day for finding at least one of them being flaky.

 

Removed the Synertek SALLY that had been swapped in for testing back out for the Rockwell that was in there originally.  Will hold on to the Synertek as a backup; there was never a confirmation that the original CPU was bad, and with the discovery of the intermittent resistor(s) would prefer to go back to stock.

[+scorpio_ny]

Hi @x=usr(1536),

 

I wanted to share a similar experience just now to see if it helps.. I was working on a project that I needed to use my 800XL (testing keyboard) I was not doing anything the 800XL motherboard when I booted it up it gave a black screen. I looked at traces, recapped it and still no luck. I looked at it using a scope the chips all seemed to be working correctly. I started swapping chips. The computer had a Sophia 2, Pokeymax and ultimate 1MB installed. So, to make things easier to diagnose, stated the process of normalizing the computer with components from a known working computer. When I got the the Sophia 2 when I swapped it out, I was greeted with a red screen with no text! So note to myself: certain replacement chips do not behave like the original in a fault condition. Referring back to the 800XL service manual, it referred me back to a list of items to check for red screen.  So, I took a closer look. What I did differently was to press on those chips with my finger with the computer on see what happens. When I pressed on the OS ROM, I got a basic prompt! Taking a closer look, there was a broken trace on one of the pins of the socket for the OS ROM. Due to the angle of the break, I missed it on the first pass. What must have happened is that the motherboard flexed and broke the trace. I reflowed the trace and the computer was back working. This was two weeks of trying different things to get the computer working again.

[+x=usr(1536)]

@scorpio_ny: thanks for that - it's certainly appreciated!

 

FWIW, I haven't ruled out a potential broken trace.  At least the ones from U18 and nearby components seem to be good, but I can't speak for any others as I've really only been concentrating on the area I was working in (which was U18).

 

My suspicion is that I broke one of the resistors and/or the cap surrounding U18 in the process of replacing the IC.  I have something of a track record for doing this, as this thread can attest to regarding my 600XL's 64K internal upgrade   R20 is the first suspect as I can get it to pass / not pass current depending on pressure placed on it, but I'm just going to shotgun everything in the vicinity to be on the safe side.

 

At this point, I need to finish putting together my Mouser order and actually place it; I'm trying to combine somewhere in the neighbourhood of 4 BOMs into one shipment.  Figuring out common components between BOMs is what's delaying me

[+x=usr(1536)]

Been fiddling with this on and off for the past month as time permits.  Replaced R16, R19, and R20 with 3.3KΩ resistors (should be 3KΩ, but didn't notice that I'd used 3.3Ks until after they were in), and R80 with a 1KΩ.  No change, though both R80 and R19 were damaged.

 

Finally got fed up with the 256K upgrade that was in there getting in the way, so removed it (including the wiring on the underside of the PCB) and replaced it with mytek's RAMBO XL-II board.  That didn't change anything either, though the machine is a lot easier to work in now.

 

The RAM, ANTIC, and PIA are the same as were used previously.  I don't have any 4164s conveniently floating around right now (the 1200XLs are the only other machines containing those, and they're buried in storage), but I do have spare ANTICs and PIAs available so will swap those out as the next step.  Quite honestly I don't think that the RAM is to blame in this case, but it is MT-branded, so there's always the possibility.

 

New inside photos:

 

 

 

 

 

Disregard J1 being a little melty - there was a heat gun misfire before it was installed, but since it was still working I decided to use it anyway

[+x=usr(1536)]

Desoldered the original PIA, installed a socket in its place, and stuck a known-good PIA in that.  No change.  Left the new one in there.

 

Swapped in the POKEY from the 600XL.  Was hoping that it might boot blind from the FujiNet, but no such luck.  Confirmed that the original POKEY was still good; it was, so put them back in their respective machines.

 

The symptoms haven't changed, so potential culprits are at least being narrowed down.  At this point, the only other major ICs that haven't been swapped out at one point or another are ANTIC and the RAM.  Will test an ANTIC swap as time permits, but may wait a bit on replacing the RAM.

[woj]

I did not go through the whole thread in detail, but since I had similar woes with two computers over the last two months, with about 50% of the sockets I soldered in, I would really suggest going back to the source and carefully checking the 74LS08 socket, the chip does provide the core hook-up points between the main ICs on the board. For me the problems were in 99% caused by poor cleaning and debris on the PCB, even though it looked clean. Poor quality flux when dry creates electrical mess as it turns out (for example, for me the problems got more frequent when I changed the solder wire from one brand to another). So take your IPA, whatever cleaning tools you can get (tiny wire brush for electronics, cotton swabs, silicon flexible tooth picks) and clean the socket in between legs on both sides of the board. Then spray the hell out of it with air duster. Reflowing the solder joints without adding new solder can also help. 

[+x=usr(1536)]

5 hours ago, woj said:

I did not go through the whole thread in detail, but since I had similar woes with two computers over the last two months, with about 50% of the sockets I soldered in, I would really suggest going back to the source and carefully checking the 74LS08 socket, the chip does provide the core hook-up points between the main ICs on the board.

That's a fair point, and I'm going to do that after swapping out ANTIC (hopefully this weekend).  My thinking is that if I eliminate all of the relevant ICs from being faulty, then I'm left with either RAM that died or the 74F08 socket itself.  I also have multiple 74F08s and 74LS08s in good shape, so can try a loose mount directly to the PCB and see if I can at least get a boot to BASIC.

5 hours ago, woj said:

For me the problems were in 99% caused by poor cleaning and debris on the PCB, even though it looked clean. Poor quality flux when dry creates electrical mess as it turns out (for example, for me the problems got more frequent when I changed the solder wire from one brand to another).

Thinking about it, this did happen around the time that I found a couple of old spools of solder and started using them.  They haven't been an issue in any other machine, but that could just mean that this one is sensitive to it whereas the others aren't.

5 hours ago, woj said:

So take your IPA, whatever cleaning tools you can get (tiny wire brush for electronics, cotton swabs, silicon flexible tooth picks) and clean the socket in between legs on both sides of the board. Then spray the hell out of it with air duster. Reflowing the solder joints without adding new solder can also help. 

[+x=usr(1536)]

Removed and replaced the old socket used for U18.  @woj: good call - there was a solder run beneath it that was bridging two pins on the top side of the board.  All I can figure is that one of the through-holes was overfilled, ran down the leg of the socket, and made its way between a couple of the pins.  This wasn't visible from above, since the socket's frame was obscuring it.

 

In any event, continuity checked out, which in turn led to progress:

 

 

From what I recall, a green screen is usually either the MMU, RAM, or OS.  Swapped a few known-good 74LS08s and 74F08s in and out of U18, but with no change; FWIW, the colour pot is adjusting colour as expected.

 

Decided to give the OS socket a quick look and found the following:

 

That is my field-expedient repair on pin 15.  Where the original leg went is anyone's guess, but it wasn't there when the chip was removed, wasn't left behind in the socket, and didn't appear to have fallen out anywhere that I could find either in or around the machine.

 

Now that we're past (I think) the U18 issues, moving on to the green screen problem at least gives a couple of ideas as to where to start the next round of troubleshooting.  I'll try some swapping between the 600XL and 800XL this weekend and see what happens, but I suspect I'll be ordering an MMU and OS ROM before too long.

[+x=usr(1536)]

@ClausB@mytek: if you have a moment, I'd very much appreciate it if you could please look at the jumper arrangement shown below and let me know your thoughts regarding it.  This is what the backside of the 800XL's PCB looked like with the ClausB board in place; when the RAMBO II-XL went in, both the small jumper wire and longer one were removed.

 

 

First up: the long continuous wire running from pin 1 to pin 1 (A8) of each 41256 RAM IC.  This pulls back to the 33Ω resistor on the ClausB logic board (5-chip version).  What is its purpose, and would this be needed for RAMBO II-XL to work?

 

Secondly, what is the jumper between pin 5 (A0) on the 2nd and 3rd RAM ICs for?  Could this be a fix for a damaged trace, or bad RAM?

 

Finally, R32 was never lifted with the ClausB board installed, and the RAMBO II-XL is connected to its right leg with the resistor still fully soldered in on the PCB.  Is this correct?

 

Any clarification appreciated, because I'm not clear as to whether or not I need to restore these changes in order for the RAMBO II-XL to work and there doesn't seem to be a great deal of information out there discussing why these wires may be necessary.

[ClausB]

On the 800XL I have, pin 1 of all the RAM chips are already connected together and pulled up by R32. So the white wires should be unnecessary and R32 should be lifted.

[+mytek]

18 hours ago, x=usr(1536) said:

if you have a moment, I'd very much appreciate it if you could please look at the jumper arrangement shown below and let me know your thoughts regarding it.  This is what the backside of the 800XL's PCB looked like with the ClausB board in place; when the RAMBO II-XL went in, both the small jumper wire and longer on were removed.

Wish I could help you, but when it comes to the DRAM memory in the Atari systems I never really got into it. In my own designs I simply swapped DRAM out for a single SRAM chip which required a very simplistic interface. As for the RAMBO-XL board I cloned, it's pretty much just a copy of what others did before me, and not something I put a lot of time into learning how it really worked. At the time I just needed a couple of them for my 1200XL systems, which when following the ICD installation manual worked first time out of the gate.

 

Anyway it looks like Claus gave you the best advice

 

BTW, the 576NUC+'s extended memory was a design by @HiassofT with some tweaks by @tf_hh , and not something I created on my own. Like I said memory isn't my thing, both in my designs and unfortunately shared by my brain at times

[+x=usr(1536)]

14 hours ago, ClausB said:

On the 800XL I have, pin 1 of all the RAM chips are already connected together and pulled up by R32. So the white wires should be unnecessary and R32 should be lifted.

Thanks, and much appreciated.  I'll give that a shot later today and see how it goes.

 

FWIW, the ICD manual doesn't say anything about lifting R32 - just that the jumper wire from D should be soldered to its right leg.  This is what's been throwing me off, since the ClausB board that was in there previously didn't lift it, but didn't have anything soldered to it, either.  If I'm understanding correctly, it sounds as though the wire jumpering pin 1 all the way down the RAM ICs was doing the same thing as lifting R32 and soldering pin D on mytek's board to it.

8 minutes ago, mytek said:

Wish I could help you, but when it comes to the DRAM memory in the Atari systems I never really got into it. In my own designs I simply swapped DRAM out for a single SRAM chip which required a very simplistic interface. As for the RAMBO-XL board I cloned, it's pretty much just a copy of what others did before me, and not something I put a lot of time into learning how it really worked. At the time I just needed a couple of them for my 1200XL systems, which when following the ICD installation manual worked first time out of the gate.

Totally understood, and appreciate the reply

8 minutes ago, mytek said:

Anyway it looks like Claus gave you the best advice

I'll do what he says, then

[ClausB]

1 hour ago, x=usr(1536) said:

the ICD manual doesn't say anything about lifting R32 - just that the jumper wire from D should be soldered to its right leg. 

It's a weak pull-up, so it's probably OK to leave it in circuit.

[+x=usr(1536)]

Lifted R32; no change.

 

I did run across something that I hadn't seen before, however: the Atarimax 256k Memory Upgrade for 800XL and 1200XL Computers (attached).  What makes this interesting to me is that it also uses a pin 1 interconnect wire on the RAM ICs, though its design is in no way chip-comparable to either the ClausB or mytek boards.

 

Next move will probably be to restore R32 to its original position and reconnect the pin 1 wire.  That originally pulled back to the 33Ω resistor on the ClausB board, so should be able to do the same on mytek's PCB.

inst256k800xl.pdf

[ClausB]

34 minutes ago, x=usr(1536) said:

Next move will probably be to restore R32 to its original position and reconnect the pin 1 wire. 

Use an ohmmeter to test whether RAM pins 1 are connected to R32. If so, you don't need the wires.

 

I've lost track of your repair. Is the XL not working at all?. If not, remove the 256K  board and restore R32 and the LS158 IC. Leave in the 256K DRAMs. Then get the machine working before restoring the 256K circuit.

[+x=usr(1536)]

1 hour ago, ClausB said:

Use an ohmmeter to test whether RAM pins 1 are connected to R32. If so, you don't need the wires.

Yep, RAM pins 1 are connected to R32.  Continuity is good all the way through from the 33Ω resistor on the upgrade board to R32; this path takes it through pin D on the upgrade board, FWIW.

1 hour ago, ClausB said:

I've lost track of your repair. Is the XL not working at all?

Nope.  It's still dead, though with further progress (sort of).  More on that below.

1 hour ago, ClausB said:

If not, remove the 256K  board and restore R32 and the LS158 IC. Leave in the 256K DRAMs. Then get the machine working before restoring the 256K circuit.

Will do.  Probably going to let it sit for a couple of weeks while I order more RAM - it's primarily for the 1200XL, but also ordering replacements for the MT 41256s currently in the 800XL makes sense as it will save on another shipping cost.

 

Re: further progress: swapped the OS ROM with the one in the 600XL.  It now boots to the standard blue screen with cursor in the upper left-hand corner, but doesn't go past that point.  BASIC does not start and OPTION does not enter self-test; this happens regardless of whether or not the keyboard is connected.  There are no cassette boot squawk / SIO noises.  Inserting a cartridge (tested with Star Raiders) causes a completely black screen at power-on, as does connecting any device (FujiNet, 1010, 1050) to the SIO port.  Unplug everything except power and video and it's back to the blue screen.

 

So, since I'm going to be placing my year-end component orders next week, I figure I'll also add a couple of MMUs and OS ROMs to the list.  Agreed that getting it working again as a 64K machine should be the priority ahead of figuring out what the 256K boards may or may not be doing; once I have a known-good OS ROM to put in it, I'll pick this back up again.

[Ricky Spanish]

Odd dilemma for sure, looking at the 256k RAMBO schematics here, the 800XL looks to be a very simple hook up. Did you take a second (or 5th) look at 74f08?

[+x=usr(1536)]

2 hours ago, Ricky Spanish said:

Odd dilemma for sure, looking at the 256k RAMBO schematics here, the 800XL looks to be a very simple hook up.

Yep, it is, and I've been working from the same version of that manual.

 

What was clouding things for me was that the 256K upgrade that had been in there previously wasn't installed 100% per the RAMBO method.  Basically, the pin-1-to-pin-1 RAM jumper wire on the underside of the PCB that the old upgrade was using performed the same function as R32 does in the RAMBO upgrade.  Once I understood that, a number of things clicked into place.

2 hours ago, Ricky Spanish said:

Did you take a second (or 5th) look at 74f08?

Many looks have been given in its direction   I neglected to mention that it was again swapped out with several known-good 74F08s and 74LS08s and had zero change in the blue screen behaviour.

 

The good news is that the blue screen is something of a known quantity, and tends to happen around the OS, PIA, and/or MMU.  At this point, we know that the OS ROM is bad and the PIA has been recently replaced and tested as working in the 600XL before it went in to the 800XL.  That leaves the MMU and possibly RAM as likely culprits, but I want to get a good OS ROM in first so that it can be completely ruled out.

 

My money's on the MMU at this point.  It'd be odd for it and the OS ROM to fail simultaneously, but they are about the same age so it's not outside of the bounds of possibility.

[+Stephen]

Bad PoKey can cause the hanging at startup too, since one of the 1st things the OS does after setting os the graphics mode, is start polling devices over SIO to attempt a boot.

[+x=usr(1536)]

1 hour ago, Stephen said:

Bad PoKey can cause the hanging at startup too, since one of the 1st things the OS does after setting os the graphics mode, is start polling devices over SIO to attempt a boot.

Thanks for the reminder; I'd forgotten about that.

 

Time to start gathering up the pixie dust for a replacement

[+x=usr(1536)]

Undertook the following today:

• Replaced ANTIC
• Replaced CPU
• Replaced OS ROM
• Replaced RAM (removed MT 41256s, replaced with NEC 41256s)

Each change was tested as it was implemented.  The machine still doesn't boot, but it is now giving a dark green screen.

 

All ICs were tested in the 600XL for functionality prior to installation in the 800XL, and all passed.  The sole exception to this are the NEC 41256s since there's no good way to check them in that machine.  However, swapping back to the MT RAM did not produce a change in behaviour in the 800XL.

 

Also removed the RAMBO II-XL, replaced the PIA with an unaltered one, and stuck a 74LS158 into U27.  This effectively reverted the machine back to stock configuration as far as the memory goes, but there was no change.

 

The one thing I haven't done yet is swap out the MMU.  I have one here, but no 20-pin sockets.  Will order some and do the swap once it can be done a bit more flexibly.

 

At this point, the only thing I can think of is that the MMU and / or delay line may be bad.  Failing that, damage to an as-yet undiscovered component may also be a possibility.

 

One of Lotharek's 64K SRAM CPU adapters is en route, so once that gets here it should be possible to bypass / replace a ton of potentially-faulty circuits.