The Sinclair QL Forum

This is a video from one of the guys on here showing the reset and classic startup speckle pattern at 5:47

https://youtu.be/61TCPEPBsBE

It still doesn't make sense. The pixels making up the numbers are in RAM and it complains about the lowest location $2000 so it didn't get past the first word. If the lowest memory location isn't working how can the code put anything in memory and still expect it to display correctly? All the pixels in the numbers appear to be white as intended meaning what the test writes to memory is correct. Perhaps that means what is read back is faulty and that would point to IC21 that is a LS245 but labelled as LS257 on my issue 6 circuit. I still can't understand why there is nothing on the ULA CAS1L pin surely it should do something?

Hi Ruptor

In case it helps any to understand what you are seeing, consider the following sequence:

a) The RAM test starts by writing to DRAM from 20000 onwards. It cannot know whether or not a given byte was actually successfully written until the next stage, and so it proceeds through (almost) the entire memory map, blindly writing bytes without any indication whether or not they were successfully persisted.
b) Then the test attempts to read-back what was written - checking that what is read back matches what it 'remembers' was written to that particular location. It knows what was written only because it uses sections of the ROM itself as the pattern to write (hence, what looks like random jibberish/'tweed' pattern, manifesting as green/red/white and black pixels, as we are in Mode 4) - in Minerva, each fresh press of the reset switch will cause it to use a different memory location in ROM as the starting point for the byte pattern that is used.
c) The first memory location that fails to match (but see next point) upon read-back is then - in Minerva- presented on-screen as those digits you can make out between the white stripes by again, writing to the video area of DRAM - this time not jibberish, but as the ASCII representation of the relevant digits, effectively overlaid upon the 'corrupt' display. If such an error is detected, the RAM test will stop in its tracks.
d) Assuming instead no faults, the bytes read-back will still fail to match what was written at some point in the process - but in this case, because we have reached the end of the available DRAM (which is not known in advance, although some educated guesses are made in the test program) - and which is then recorded as 'RAMTOP'. This is distinguishable from a memory fault because the byte read-back is in fact the same as what was written to a specific lower memory location (I'm overly simplifying things here, for brevity.)

Coming back to the interpretation of the displayed memory fault numbers, those vertical white stripes which you'll note occur periodically throughout the display as well as the hex digits - are representative of bits in the data that failed to store and/or read-back correctly and, with a bit of thinking about, can help point you to which DRAM ICs are at fault - or else the databus buffer IC, or perhaps the address multiplexers, some shorts or open-ccts in some databus lines or a combination of all of these...

So, yes, some/most of the bytes written to DRAM during the first stage of the RAM test were successful, hence some of the display is as expected and some of the hex digits legible - at least for the human brain (it takes quite advanced AI to pluck-out those digits amid the corrupt 'noise' and why those I'm not a Robot images/text are often used on web-pages to distinguish between a webbot and a human when submitting an online form...)

Your uploaded images aren't quite clear enough to me to say more, but it is entirely consistent with one or more of the potential fault-areas listed in the paragraph above.

Can you try to take a photo again, but this time with finer resolution?

I still can't understand why there is nothing on the ULA CAS1L pin surely it should do something?

CAS1L will go low only when accessing the second 64kB bank of DRAM - and only for the second half of each memory cycle. It is entirely possible that the RAM test has given up long before it reached that point in the DRAM memory map...

M.

I have not read the whole thread, but just a few short comments:
- Minerva does not write the whole RAM and only then starts to check it. In 32-bit steps it will write 1s to all bits, check them, then write the "random" value and check that, too. So your RAM check immediately fails on the "random" part of the first Longword. The stripes you see is noise within the RAM chip plus another problem as the RAM has not been initialized with data yet.
- The first value you see on screen is the 32-bit value written, the second the one read back. So your D0 bit is stuck high.
- If bit 0 was low in the displayed picture this would point to IC21. Your picture is pretty bad quality to tell much, but it looks like bit 0 is stuck high in the displayed picture, too (the white stripes). Meaning that either IC1 and IC9 are both faulty or, more likely, that one of the chips or something else pulls the line high. Basically it boils down to IC1, IC9, IC21 and IC22. Or some other bridge bringing D0 high on the ULA bus side.
- CPU and CPU bus is fine as Minerva is executing correctly.

Marcel

Some progress has been made but there appears to be many faults or at least more than one. I put the original processor back in with the dodgy A15 line while I am poking around the board and I found that there is something flaky next to the IC33 ROM and IC21 buffer. I took a picture of the top pin I could see a problem with although all the pins on IC21 are dull and look like dry joints to me. If you look close you can see the pin actually looks like it is sitting in a hole and hasn't been wet by the solder. I scraped and soldered the pins and the board wasn't dodgy to being pressed any more but no change in the green screen with the old ROMs. Don't ask me why but I checked the A15 line with the IC33 ROM removed and it goes the full swing with what I thought was a dead CPU pin so clearly it is the ROM that is pulling the line down and the CPU is OK. That is two faults solved but still it doesn't run on my Minerva ROM and one of the data lines has two levels making the signal look different to the others on the buffer. If it was in a socket I would have changed it.
Here is another fault or a circuit error you tell me which. The clock on the ZX8301 IC22 is 5.1 MHz and all hell breaks sometimes when I stick a scope on it to look at it. Something else to look at tomorrow.
I thought there is a limit to the picture size of 800x600 on these web systems so I always reduce the resolution to get pictures of 50K rather than 4Mb plus. The memory testing all seems a bit complicated given all the other problems that my machine has. Why use the random internal ROM as data and not the standard 55 then AA hex that show exactly what bits are stuck? Once that is established you can get more complicated with fancy codes that stress the memory but I never bothered on noddy systems since the simple pair suffice.

one of the data lines has two levels making the signal look different to the others on the buffer.

Lett me gess: D0?

The clock on the ZX8301 IC22 is 5.1 MHz and all hell breaks sometimes when I stick a scope on it to look at it.

To me that sounds more like a problem with your scope than the ULA. If all hell breaks loose then you're disturbing the signal and anything you have measured is more or less meaningless. Given that the video timing is also generated from the 15Mhz clock it is very unlikely that this is wrong.

Why use the random internal ROM as data and not the standard 55 then AA hex that show exactly what bits are stuck?

What if there is some bridge between D0 and D2 for example? You could never tell. Besides, it's an iconic look and I wouldn't have it any other way

A lot of pins seem to have jiggling when high from other signals and some are worse than others but the two high levels don't come anywhere near the level that would be seen as low. I guess it is just poor supply rails, tracking and decoupling.

mk79 wrote:To me that sounds more like a problem with your scope than the ULA. If all hell breaks loose then you're disturbing the signal and anything you have measured is more or less meaningless. Given that the video timing is also generated from the 15Mhz clock it is very unlikely that this is wrong.

It isn't the scope it is probably another duff joint. I noticed before if that area is touched sometimes things go cuckoo including the screen.

mk79 wrote:What if there is some bridge between D0 and D2 for example? You could never tell. Besides, it's an iconic look and I wouldn't have it any other way

That is why other codes mathematically determined to identify where a fault might be with the least codes are used in a proper memory test. Most data tracks are parallel so checking adjacent pins is a good compromise between speed of testing and detection. It seems you like iconic chaos but boringly I like order.
Gone to the sort out the clock signal now hoping there are not too many other faults.

mk79 wrote: - Minerva does not write the whole RAM and only then starts to check it.

Thanks for correcting my understanding, Marcel! Time for me to look again at the Minerva source!

M.

Ruptor wrote:That is why other codes mathematically determined to identify where a fault might be with the least codes are used in a proper memory test.

Yeah, with these test being bigger than the whole of Minerva. There is not one byte to spare in that ROM.

martyn_hill wrote:Thanks for correcting my understanding, Marcel! Time for me to look again at the Minerva source!

ss_ramt_asm, label "do_1st"