Well done Cristian - progress indeed!
Given how close to fully working and the specific bit-error still present, it does seem likely that one further RAM chip replacement is worth the effort. Good luck
If I may sabotage your thread temporarily with the intention that some of the below _might_ prove useful to someone in the future, I thought to present some of my own findings after just repairing an old spare Iss5 motherboard of my own (and feeling quite proud of myself!). It was your efforts and the conversation in this thread that prompted me to explore a bit more deeply - thanks for that!
I don't believe the following relates to Cristian's situation directly, even though the initial symptoms looked very close. Read-on only if you have a few minutes to kill...
Original spec & state:
Issue 5 motherboard, originally with AH EPROM piggy-back and flying lead arrangement (very early model.) Purchased from eBay - unsure of working state from the outset.
I had already hacked the board and specifically, re-purposed the 74LS00 NAND (IC17) to convert one of the ROM sockets to directly suit an EPROM (I didn't have a spare Minerva carrier-board at the time and dislike having to bend-out those three pins anyways!) - simply inverting the positive ROMOE from the ZX8301 to a negative signal suitable for EPROM and a number of link and signal line re-wiring (A15, for example). Badly, as it turned-out...
A later plastic 68008 CPU had been fitted. I had a spare CPU (earlier ceramic type), plus a couple of spare ZX801's and a spare ZX8302 as well as Hermes replacement for the 8049 IPC. None of the 'mandatory modifications' had originally been applied, so I added those according to the QL Service Manual. I also had another working Iss5 (among other models) to compare against - a real luxury!
With Minerva 1.97 EPROM fitted in the modified ROM socket, I was getting RAM test errors that _loosely_ but not consistently pointed to DRAM IC 3. I replaced that (after adding a socket). Now I was not even getting to the RAM test, with broad black/white horizontal-banding plus thin black-white vertical bars (inverting as they crossed the white horizontal bands) - very similar to one of Cristian's earlier photos - except no RAM test results displayed at all - so 'worse' than before the DRAM replacement.
I discovered a poor solder connection on the replaced DRAM socket that was effectively grounding CAS0 permanently. After correcting that I got to and passed the RAM test without error! However, after the Minerva logo appears on a first boot, the F1..F4 dialogue box would appear slightly corrupted (missing memory size - just the 'K', and the Minerva ROM version randomly missing) and then after a couple of seconds (but less than Minerva's 15sec auto-start delay) the screen would blank-out to black and the system would just freeze.
With the black-out display, I tested the keyboard with the Hermes IPC clicking for the first 8 key-presses, then silence, indicating that it was not being serviced by the ZX8031 via the OS.
Subsequent resetting via the push-switch would only get to the Minerva logo and blank out immediately afterwards. Only after a power-down would a further start-up show the F1..F4 prompt again. Very odd and slightly similar to another poster on the forum recently...
This is when I tried all sorts of combinations of plug-in ICs - testing both this board's components in a working Iss5 board, and vice-versa. This boards components all worked in the other board except, curiously, the plastic CPU, which always resulted in RAM test failure on the otherwise working other board. How, I thought, could it work partially in the suspect board, and barely at all in the working board?
Also curiously, only one of my EPROM candidates (various flavours of Minerva) worked in the suspect Iss5 board - with any of the the others fitted (of a different brand) RAM test failures always resulted (random - much like before the DRAM soldering bodge had been corrected.) All EPROMs worked in my other Iss5 board (with suitable carrier.)
But this got me thinking about the original mod of the ROMOE signal inversion in the 74LS00. I attached my cheapo digital analyser and observed that, whilst ROMOE was being inverted, it was never toggling - but staying permanently active! I really thought my digital probe was playing-up, until I finally looked at my earlier soldering of the 74LS00 NAND IC. The original job was a bit of guess-work as the Issue 5 schematic (from the Service Manual) is less than clear about the various permutations of the wire-links (JUx).
Excuses aside, it turned out that I had mistakenly shorted the ROMOE from the ZX8301 to +5v. No wonder - the (EP)ROM was permanently enabled and quite amazing that the system powered-up at all!
After correcting that bodged solder-job (for which I seem to excel!), no change... no RAM test errors, but black-out shortly after Minerva logo/F1..F45 prompt.
Head scratching followed, then I swapped-out the plastic CPU for the ceramic one that previously produced RAM errors in this board. The RAM errors were no more and the system booted all the way to the command prompt! Finally success.
In summary - self-evident, perhaps:
a) RAM test errors are not necessarily all due to the DRAM, especially where they appear particularly random. The inter-connectedness of all things - (c) Mr Adams, RIP... - inside our humble QL means that a number of other candidates should be included in the investigation.
b) A multimeter/connectivity tester at least is essential, and where possible, a simple digital analyser should be considered an invaluable investment when troubleshooting the QL board.
c) Keeping a 'spare' working unit AND plug-in ICs, whilst a luxury, goes a long way to eliminating dead-ends and streamlining one's efforts.
d) Its quite possible that multiple faults exist (especially if you've applied any of your own mods!), so persevere and cross-reference earlier results to formulate the next hypothesis.
e) Assumptions are needed when testing each hypothesis - just make sure you keep any assumptions in mind, for testing later (e.g. that plastic CPU working better in the suspect board - it was always one of the faulty components in the final analysis.)