Oric-1 DRAM – oddities & questions

[AdamT117]

Hello all. I’m fairly new to Oric repair, so I wanted to share this both as a learning experience and to ask whether this is a known issue with ageing Oric hardware. I am new here, so apologies if this has been covered before.

I was chasing an intermittent fault on an Oric-1 that was very hard to pin down:

• Diagnostics would pass, including the RAM test

• An Arduino-based DRAM tester also passed

• On cold boot, a lowercase “p” (or sometimes another character) would appear after the Ready prompt

I initially investigated ROM differences, AY sound, keyboard, capacitors, and timing-related causes, but none of those resolved it.

What I found
Eventually I came back to DRAM, even though all tests said it was fine.
By swapping DRAM chips around (some were already socketed), I found that IC13 and IC14 were consistently involved. Replacing them eliminated the stray character on cold boot — but only with certain DRAM chips. Other chips that appeared “good” still produced different random characters.
Once the right replacements were fitted, Cold-boot corruption disappeared.
This strongly suggests a marginal timing / speed issue, rather than outright DRAM failure. Assuming these positions may relate to screen RAM or very early memory access, where borderline 4164s can misbehave even though they pass diagnostics.

My Takeaway
A RAM diagnostic pass does not necessarily mean the DRAM is truly healthy for the Oric.

Questions for the experts

• Is this a known Oric-1 issue with ageing 4164 DRAMs?

• Are certain brands or speed grades known to work better?

Hopefully this helps other newcomers avoid a long chase — and I’d really appreciate any guidance from those with more Oric experience.

Thanks!

[Dbug]

Is it possible to test the speed of a ram chip with the arduino tester?

[Chema]

I have a theory, but it might be nonsense.

The way the Oric multiplexes the buses (using part of the 1MHz cycle for the ULA and part for the CPU) requires parts which should be faster than usual. That is why memories should be 120ns and CPU and ULA should be parts which support 2MHz clocks.

But I've seen motherboards repaired using the usual slower chips working out of spec. They might work, or not depending on multiple causes. My Oric clone is unstable with some CPUs (faster) and works perfectly with the 1MHz model.

Do you think this makes any sense?

[AdamT117]

Is it possible to test the speed of a ram chip with the arduino tester?

Probably. I dont think the generic testers you can get are that sophisticated with the CAS and RAS strobe? I read that the Retro Chip Tester Pro can detect additional issues, but thats a bit out of my budget.

[AdamT117]

I have a theory, but it might be nonsense.

The way the Oric multiplexes the buses (using part of the 1MHz cycle for the ULA and part for the CPU) requires parts which should be faster than usual. That is why memories should be 120ns and CPU and ULA should be parts which support 2MHz clocks.

But I've seen motherboards repaired using the usual slower chips working out of spec. They might work, or not depending on multiple causes. My Oric clone is unstable with some CPUs (faster) and works perfectly with the 1MHz model.

Do you think this makes any sense?

I wondered around the need for 6502A and 6522 A designations - so that makes sense. Im my case I have these 2MHz variants. Although your mention of 120ns might be an issue. I have "-15" DRAM, does this mean 150ns?

[iss]

@AdamT117: Welcome to Oric world!

Everything you found is already observed in other Oric's.
From my experience: Oric works well with "set" of DRAMs, best all chips from the same manufacturer/batch.
As rule don't trust chinese sources but I have lot that work fine. I've tested with many ( hundreds! ) chips and I can not conclude that faster (120ns) are better than slower (150ns). The whole thing is kind of card trick - shuffling and swapping the same 8 chips on different places can make Oric to work stable! This had happened lot of times.

About the DRAM testers (all copies/clones/upgrades of my DRAMARDUINO) can't do speed test. I made new firmware with some goodies and it will be released soon...

The random char issue: It's known too and sometimes adding a 1k (2k, 4k7 or so) resistor solves the problem:

20260122_193741.jpg

In search for stability you can try swapping VIA 6522 too (and post 1-2 pictures of the PCB).

[AdamT117]

@AdamT117: Welcome to Oric world!

Everything you found is already observed in other Oric's.

Many thanks for this information and the welcome. Sorry if this is a repeat of stuff that is obvious, i have yet to delve fully into the rabbit hole .
I will keep this post updated with any findings - as these are good pointers. Let the journey begin....

[Vyper68]

I thought the random single character on cold boot was a quirk of the ULA? I also avoid the 4164 from China as you never know what you are letting yourself in for. I have a 50% succsess rate on chips from China be it an AY chip, 6522 or RAM.

[AdamT117]

The plot thickens.

Upon further testing, the issue currently observed is different and more repeatable: DRAM failure under sustained load / heat. When memory is exercised continuously, system stability progressively degrades, leading to screen corruption and RAM errors, and eventually lock-ups. Powering down and allowing the board to cool restores normal operation.

The lowercase 'p' at boot has gone for now but....

@Vyper68 I do accept that the ULA could have been a factor in the original cold-boot symptom, as it is involved in DRAM timing. I can't recall whether swapping the ULA does change behaviour. However a reduced timing margin at the ULA could plausibly impact DRAM.

However, for now I’m treating DRAM as the primary fault mechanism, as the current failures are clearly load- and temperature-related.

My current focus is on developing a simple RAM stress test to reliably identify whether errors map to specific DRAM ICs, before drawing further conclusions. The thought being to use XOR of known values to reveal which bits are wrong. i.e D7 = IC12, D6 = IC13 etc. I am thinking that repeatable may indicate DRAM, and not - being general timing back to the ULA.

Does such a test progam or ROM already exist?

[AdamT117]

Hi all — quick update with some specific RAM failure data to continue the troubleshoot, and I’d welcome advice on next steps.
As a recap when memory is exercised continuously, system stability progressively degrades, leading to screen corruption and RAM errors, and eventually lock-ups. My original problem was the a lowercase 'p' that was "fixed" by swapping ram chips.

Using a small test ROM that I put together (please feel free to find my mistakes in this )
https://github.com/Kayto/oric-dram-fault-finder

I’m seeing a repeatable bit-level failure pattern, not completely random corruption. Across multiple addresses in page $02xx, an AA pattern ($10101010) consistently reads back as $80, with a constant diff of $2A.

For the tests i have run.

Code: Select all

$AA → $80   diff $2A   at $0200, $0202, $0212, $0266, $0288, $02EE

So when bits D7, D5, D3, D1 are expected high, only D7 is present; D5/D3/D1 read low. This behaviour is repeatable across passes and becomes more pronounced under sustained load / temperature. There was one non-repeatable walking-bit failure outside page $02, i am treating as an outlier, but the AA55 failure ($AA → $80, diff $2A) within page $02 is relatively consistent.

Given this specific pattern, (assuming my test code is correct ) would your next step be:

• suspecting multiple marginal DRAMs on those data lines,

• look for a trace / socket issue,

• or investigating reduced timing margin (e.g. ULA-related)?

I suppose i am starting to think this is more than just a RAM issue.

Any guidance on how you’d interpret this exact bit pattern would be very helpful.

[AdamT117]

Hi all — closing this out with what I believe is the root cause and the fix, in case it helps someone else.
Symptoms I was chasing

• Cold boot stray character after Ready (most often a lowercase “p”)

• General instability over time under sustained RAM activity / warm-up, eventually showing screen corruption, RAM errors and lock-ups (and then recovering after power-off/cool-down)

What fixed it (for my board)
After a lot of chasing (and despite diagnostics / generic DRAM testers passing), this did come back to DRAM.
I swapped IC12–IC15 (these were socketed on my board) and replaced them with the most consistent set I could — same type and as close as possible in manufacturer/batch to match the existing IC16–IC19.
That change dramatically improved stability to the point where I’m now happy the Oric-1 is fixed and is running consistently and correctly.

20260131_110516.jpg

Takeaway
Even if all 4164s test “OK” in diagnostics and generic testers, in my case there appears to be a real benefit in keeping DRAMs matched (manufacturer/batch/similar parts) rather than assuming a mixed set will behave identically under the Oric’s timing.
This strongly aligns with advice from iss earlier in the thread: Orics often behave best with a matched “set” of DRAMs, and stability can change simply by swapping identical chips between positions.

Useful links
Here are few that I wish I had bothered to search before starting
https://wiki.defence-force.org/doku.php ... ric1_atmos

viewtopic.php?p=31984#p31984
Side observation (ULA/ROM pairing quirk)
As a separate curiosity: I also found a ULA/ROM pairing quirk on my setup:

• One ULA, Oric will not boot reliably with the original Oric-1 v1.0 ROM, but boots fine using an EPROM copy.

• Another ULA, Oric boots fine with the original ROM.

This is outside the scope of the DRAM fault itself, but it does perhaps underline that part pairing and timing margin can matter more than appreciated in these machines. This was on an Oric-1 Issue 4 board and may be specific to my parts — so YMMV.

Thanks to everyone who contributed ideas and experience — especially iss for the practical “matched set” guidance. Hopefully this saves someone else a long chase. If anyone has any comment on my attempt at a DRAM tester, which was a useful tool, then please let me know.