Sharing my experience of an Atmos resurrection (thread)

[jacqu]

Hi fellow Oricians,

In this thread (I will post upcoming follow-ups as response to this initial post) I want to share with you my experience of an Atmos restoration from a complete newbie point of view. I made a heavy use of the « Search » feature of this forum to collect all the information that I needed for my journey. So, first I would like to warmly thank all the contributors for their valuable content and a special big up to Dbug for maintaining and animating this fantastic resource.

This thread will be a compilation of useful informations I found mostly here but also on other places on the web to achieve the resurrection of the machine. I will also share some personal contributions, one of them has already been posted ( https://forum.defence-force.org/viewtopic.php?t=2467). I plan to add 5-10 posts to this thread in the coming weeks depending on the time I have.

The machine in question was bought on leboncoin.fr for 100€ and was in a pretty rough shape:

Its working condition was unknown, but I quickly discovered that the case was never opened since the warranty seal was still present and in perfect condition. The inside was in pretty good shape, the only oddity was two RAM chips from another brand and with obvious flux residues.

I suppose these two RAM chips were added manually afterwards, maybe due to a shortage during the wave soldering process (RAM shortages were pretty common in the early 80’s). Another explanation is that this board failed at quality testing after production and that some ICs had to be manually changed. If you look carefully at the picture above, you can see that a pad is lifted. This happens usually when you desolder an IC.

My first move was to replace the 3 electrolytic caps and the LM7905 regulator. I bought a modern 7.5V power supply ( https://www.mouser.fr/ProductDetail/ME ... oBGQ%3D%3D) in order to limit the power dissipated by the regulator. I checked the datasheet, 7.5V is within the specs. At this point I didn’t have a mean to display the video output (RF or RGB) so I ordered a RGB2HDMI adapter ( https://www.sellmyretro.com/offer/details/62102).

I also gave this machine a little cleanup with soapy water and a toothbrush and it came out pretty clean:

Without video there is still a way to check if the machine is alive: the clicking sound of keypress and by typing some emblematic and typically orician commands like PING ZAP…
So I powered the machine up and found out that the keyboard was perfectly silent. It was not a real disappointment since I did not expect that this cheap machine would work out of the box.

To be continued…

[Dbug]

Make sure you reconnect the keyboard properly, on the Atmos there's one more row on the connector, so it's easy to have an "off by one" connection that makes the keyboard to not work.

[jacqu]

Make sure you reconnect the keyboard properly, on the Atmos there's one more row on the connector, so it's easy to have an "off by one" connection that makes the keyboard to not work.

In fact, for the two keyboards I have, the number of pins on the connector matches the number of pins on the motherboard. Maybe the mismatch is due to connector shortage, for some specific batch of Orics ?

[jacqu]

According to many advisers on this forum, on YouTube channels (see Noel retro lab video on an Oric repair for example https://youtu.be/riNLmstDAVA) or in the excellent official Oric service manual from back in the days ( http://www.48katmos.freeuk.com/servman.pdf), the usual suspect is in 80% of the cases the DRAM. But before you have to eliminate some other obvious faults by checking the power supply voltage, the equivalent resistance between Vcc and GND which should be over 200 Ohms and all the clock signals (check the excellent Oric repair guide for this process: https://oric.signal11.org.uk/html/repairguide.htm).

Before desoldering the RAM chips, I wanted some kind of validation of this hypothesis. So I checked pin 14 of each DRAM with an oscilloscope to see if there was some activity on the output. And indeed, for at least one chip, there was no signal at all. For some others, the signal seemed pretty weak. So I decided to desolder the 8 DRAM chips and replace them. The new chips will be socketed in case of another DRAM failure in the future. This last decision (to socket the DRAM) will trigger some unexpected cascade of unfortunate consequences which I will detail in a future post.

If you want to desolder 8 chips with 16 pins on each, it is always a good idea to consider buying a desoldering gun. I ordered a Hakko FR301 for this task https://eleshop.eu/hakko-fr-301-desoldering-gun.html. It comes with a 1 mm diameter tip which is ideal for desoldering ICs from this era. After some testing and after viewing some interesting tutorials ( https://youtu.be/gS2oRdFFV8E) I tuned my technique and these are some tricks I learned:

• Set the temperature to 375 degrees Celsius

• Reflow the solder joint by added fresh leaded solder on each pin

• Straighten the pins while reflowing the joints

• When desoldering, describe little circles around the pin with the solder gun tip

• Remove the remaining solder on the components side using solder wick and flux

• Apply some lateral force on each pin with a screwdriver to check if they are free

I managed to successfully remove all ICs without lifting a trace expect for one which I suspect was already lifted (see picture in previous post). Thankfully, the rewiring of the track was pretty easy.

To be continued…

[iss]

Not bad desoldering result!
Check this two tracks:

... and after solder the sockets check all pins with continuity tester.

[jacqu]

Not bad desoldering result!
Check this two tracks:
3ECA6394-D1AB-40E3-82F0-0CAD29501EBF.jpeg
... and after solder the sockets check all pins with continuity tester.

Thanks iss

I checked all the tracks for continuity after this surgery. The two tracks you spotted caught also my attention, but it appears that the white marking only covers the track that is still in one piece below. The unfortunate consequences I mentioned about the socketing are mechanical, not electrical. I will elaborate this in a future dedicated post, since there is a lot to say.

[Dbug]

So I decided to desolder the 8 DRAM chips and replace them. The new chips will be socketed in case of another DRAM failure in the future. This last decision (to socket the DRAM) will trigger some unexpected cascade of unfortunate consequences which I will detail in a future post.

Let me guess... could not close the case?

[jacqu]

So I decided to desolder the 8 DRAM chips and replace them. The new chips will be socketed in case of another DRAM failure in the future. This last decision (to socket the DRAM) will trigger some unexpected cascade of unfortunate consequences which I will detail in a future post.

Let me guess... could not close the case?

[jacqu]

After desoldering, I checked for continuity every track coming to or from the RAM area. I soldered sockets and inserted new Fujitsu MB8264-15 DRAM chips. I noticed afterwards that these Fujitsu chips were 0.5mm taller than the original Texas Instruments OTMS4164-15NL chips, though perfectly compatible.

Meanwhile I received the RGB2HDMI converter which I assembled. I had to 3D print a new case from Thingiverse (https://www.thingiverse.com/thing:4866756) since the one that was provided was too small.

I removed the ROM which was socketed and replaced it with an EPROM (Hitachi HN4827128G-25 128K 16Kx8bit Uv-Eprom) flashed with a diagnostic ROM: https://oric.signal11.org.uk/html/diagrom.htm. I flashed the ROM using this well-known device: https://fr.aliexpress.com/item/10050044 ... pt=glo2fra. Note that the Hitachi HN4827128G-25 should be blanked with an UV light like this: https://fr.aliexpress.com/item/33010077 ... pt=glo2fra. Some eBay sellers provide chips that are already blanked. The Hitachi HN4827128G-25 should be perfectly compatible with the Oric even when using a device plugged in the expansion port.

Then I plugged the power supply (I always use a current limited power supply for a first try after some major modifications. For the Oric, it is safe to limit the current to 700mA) and tadaaa !:

At some point, the diagnostic program asks to plug loopback connectors into the cassette port and printer port which I did. All the tests passed except the Strobe/Ack test on the printer port:

Not sure what is the cause, maybe my loopback connector was wrongly wired (I checked) ? Or the wires were too long ? Or the most obvious explanation: there is a problem with the 6522 since the printer port is directly connected to it ? Do you guys have some experience with this specific stage of the diagnostic ROM ?

To be continued...

[iss]

Looking at the schematic, the loopback add-on is just straight wiring (i.e. you can simply use f-f dupon wires) to connect pins 1 and 19.
- Check if you didn't connect 2-20 instead of 1-19 ....
- Check with cont.-tester the tracks from VIA to the printer port;
- Test with another VIA if available in spares.

[jacqu]

Looking at the schematic, the loopback add-on is just straight wiring (i.e. you can simply use f-f dupon wires) to connect pins 1 and 19.
- Check if you didn't connect 2-20 instead of 1-19 ....
- Check with cont.-tester the tracks from VIA to the printer port;
- Test with another VIA if available in spares.

Thanks for the advice ! Since everything else worked fine on this machine, I did not push further my investigations on this problem so far. But I will try again. I'm still reluctant to desolder the old VIA and socket a new one since it will yield some additional conflicts with the case...

[jacqu]

After successfully booting the motherboard, I plugged the keyboard in and noticed that some keys were not registering. Since I had a spare keyboard, I tried this other one with almost the same symptoms except that the non-working keys were not exactly the same. Since both keyboards had problems, I (wrongly) concluded that the problem was elsewhere. I gave a more deeper look at the motherboard schematics (see this thread: https://forum.defence-force.org/viewtopic.php?t=1959) and noticed that two components were potentially involved in the keyboard decoding: the sound chip (AY-3-8912) and the VIA (R6522AP). I checked the connections between the keyboard plug and these two chips for continuity and found no obvious problems. I then checked the signals generated by the sound chip on pins 7 to 14 and I found an oddity: pin 14 had a totally different shape that the 6 other signals. I (wrongly, again) concluded that the culprit might probably be the sound chip.

On this page (https://osdk.org/index.php?page=articles&ref=ART16) you will find the schematics of the keyboard interfaced with the motherboard. It also explains very clearly how the keyboard decoding works. On the keyboard PCB, there is a multiplexer that is also involved in this process. To eliminate this chip from the equation, I replaced it with a new one, but with no change.

As a last resort, I checked the service manual and found some interesting information: it clearly states page 33 that the signal on pin 14 is different from the others. There are other plots that are given pages 34, 40, 41, 42, 43 that can be checked with a scope. I checked most of them and they did match the signals on my scope. It also states that in case of some VIA or sound chip problems related to the keyboard, either a whole line or a whole column of keys should be non-working (the keys are organized in a matrix). In my case, the non-working keys were scattered everywhere within that matrix. According to the service manual, this points to a contact issue directly at the key level.

So I checked more carefully the soldering joints on the keyboard PCB. I tested the continuity directly from the key contact pins to the multiplexer chip on the non-working keys and found out that some solder joints were cracked:

I looked for other cracks and found that most of the solder joints on the first physical row (1, 2, 3 ... keys) of the keyboard were cracked. I checked my spare keyboard and, bingo, also cracked solder joints. So I reflowed all the contacts pins of the keyboard by adding fresh solder. Warning: when doing this avoid heating too much the pins since there is a risk to melt the plastic holding the contacts in place. I first soldered one pin out of two on the whole line, then, the other pin, in order to give the temperature enough time to decrease. I did this on the two keyboards without issue. I now have two perfectly working keyboards again.

To be continued...

[Dbug]

On this page (https://osdk.org/index.php?page=articles&ref=ART16) you will find the schematics of the keyboard interfaced with the motherboard. It also explains very clearly how the keyboard decoding works.

Glad you found the article useful

[jacqu]

Now it is time to close the case. And that’s was not the easiest part of the journey. I did some research before socketing the RAM to see if the raise of the components level could yield a conflict with the orange bottom case lid. I found nothing relevant. Furthermore, in some YouTube videos, like the one from Noel Retro Lab, the RAM was visibly socketed and no mention was made about a potential conflict. So I learned it the hard way.

When I tried to close the orange bottom lid, it was obvious that something prevented to completely close the gap. I made some measurements with a caliper, measurements I should have done before, and it became obvious that the top of the socketed RAM was colliding with the orange bottom lid. I estimated the additional height at 3.5mm. At this point I was pretty disappointed since the only way to overcome this situation was modifying the case.

This calls for some comments. In order to preserve the original shape of the Oric, it is seemingly necessary to directly solder new RAM chips on the PCB without sockets. Since RAM chips are prone to fail, more desoldering might be necessary in the future, compromising each time more the integrity of the motherboard. So the dilemma: is it better to preserve the original shape of the Oric or to preserve the motherboard? I would love to here your point of view about this.

So I started to think about a case modification, minor enough to remain unnoticeable, but significant enough to avoid any collisions with socketed RAMs and a socketed VIA which is also prone to collision. My solution was to 3d print a set of spacers. Below, a picture showing the result:

As you can see the black glossy finish of the PETG matches pretty well the finish of the Oric case. There is no conflicts with the connectors since there is enough clearance for a 3.5mm shift. If you want to try this mod, you can follow this link: https://www.thingiverse.com/thing:5787738
I uploaded the CAD files so you can mod the mod.

To conclude, despite this restoration was not a straightforward path, I enjoyed the journey a lot. The final result is pretty satisfactory, though it is not in the exact original shape since I slightly modified both the keyboard and the case. Both modifications were necessary evil, since all Atmos keyboards have now cracked plungers that will eventually yield stuck keys and a large percentage of boot failures are due to bad RAM that will require RAM change.

I proposed to my 22 years old daughter, which is a hardcore gamer (you can see her rig in the background), to play some well-known games on the restored Oric. Some of her comments:

Waou, je pensais que les jeux étaient plus basiques!

(Wow, I expected more basic games). She was playing Xenon1.

C’est incroyable que cette machine fonctionne encore au bout de 40 ans!

(Incredible that this machine is still working after 40 years). This did not help me feel younger

[jbperin]

Félicitation pour cette réanimation qui contribue à protéger l'espèce.