The Sinclair QL Forum

Derek_Stewart wrote: ↑Tue Jan 23, 2024 1:50 pm Looks the same board as the board that was delivered yesterday:

Let's wait for Leon's comments. If I understood correctly, it is possible that I have a different CPLD logic, meant to be closer to original ULA timings.

Hi, it is the same boards you got Peter with the one I sent to Derek that shipped the same day and works.
I can't think of something else other than the socket or a different problem with your QL motherboard that I think you mentioned had problems also with the original ULA and maybe they appear more with the ula replacement board.
I have tested these boards in 2 different issue QLs 5 and 6 before sending them.
Send them back and I'll refund.

Or maybe there is an incompatibility with your QL built? What issue motherboard is it?
If so I'll know and I'll try to find a QL like yours to test with.
After the error have you tried the reset button? It did the same ?
This talk should have started in the basic ULA topic the fpga board replaces the ram and no such problem could happen with the fpga board.

Hi Leon, Peter,

Leon, do you remember when you sent me a very early version of the ULA replacement? I had the same issue as Peter has now. It was a timing problem linked to RAM chips. You send me a different version of logic of the PLD which fixed the issue, slower RAM access, if I recall correct.

Probably same problem here?

Peter, if you want me to reflash, after conformation of Leon I am happy to do so.

Stephan

Hi Stephan
This version has already the changes I did for you but it has some other differences, I can make an identical with yours version to test if you both wish.
Your QL is issue 5 if I remember well. Your board had the PLCC socket cpld ?
Anyway I have to make a new programming file because the pins changed in the new version.
It seems some QLs are different than other QLs with the same issue motherboards.

Another test that could be informative is to test the boards to your QL before you reprogram them.
I already made this version and tested to my QL but everything I throw in my QL works. lol
Thank you Stephan for your intent to help.

And it works also on the other QL I have borrowed for tests the issue 6 with 150ns ram. Peter's board worked in it too but let's hope.

lliont wrote: ↑Tue Jan 23, 2024 6:54 pm I can't think of something else other than the socket or a different problem with your QL motherboard that I think you mentioned had problems also with the original ULA and maybe they appear more with the ula replacement board.

Fortunately I have been able to purchase another QL on eBay which runs absolutely stable.
The problem is reproducable on both QLs however, and goes away as soon as I use an original ULA.
I have seen two indications for a DRAM related timing issue caused by the replacement ULA:
1. Your CAS active comes later with respect to RAS active than the original ULA.
2. I cooled down the DRAMs to lower their access time a little, which made the QL with replacement ULA work until DRAM warmed up again.

The DRAMs on my QL are KM4646A-15. Maybe your QL has different ones?

Side note: I have seen that the replacement ULA generates about -1.9V undershoot on signals like RAS, while the original ULA generates just -0.2V. This is the typical effect of modern CPLD's fast rise/fall times on a two-layer PCB designed for very slow logic. I don't think it is connected to my problem, and it is still within allowed range for the DRAM. Just wanted to remind of this potential signal integrity issue (crosstalk, etc.) for your future QL developments. You might want to look into using series resistors at some point.

I'm pretty sure my problem can be resolved by a logic update.

My CAS goes active only half a cycle after the RAS goes active how could this be later than the original, see Nasta's logic analyzer trace, maybe you where observing the beginning of the ula's video memory read accesses where there is not problem even in your case.
You got a second QL that has the same behavior, I can't find one here.
For the undershoot maybe I can enable the reduced slew rate option of the cpld if you think that is a problem.

DRam is HM4864p-2

We can try slower access times even I don't like to make it slower
I can enable DTACK half a cycle later.
I can send Stephan 2 new versions to program to the 2 boards and send them to you to try them if you can't find a programmer.