Issue 6 VM12 & resistors confusion

[martyn_hill]

Hiya Tobi!

a failed EPROM seems relatively unlikely. Any lines stuck on the data bus would most probably affect the screen display.

Indeed, but Ruptor doesn't describe the latest display - only that the digits of Minerva's RAM test are visible.

I've had such a semi legible display before - enough to read the test results, but with nasty vertical patterns mixed-in - in that case, I discovered I had fudged my repair soldering, resulting in the (EP)ROM being enabled at times when it shouldn't have But, as you say, probably less likely than the other possibilities discussed.

Ruptor, can you capture a short video of the boot-up sequence and post it here for review? We can eliminate a few of the options with a clear video or image...

[Ruptor]

Here are the first three screens output. It looks like the '1' bit stuck on in all the bytes but in the second screen it is off in the upper byte which is a bit strange is that a correct interpretation? I belled out every pin on my homemade EPROM board and already checked the EPROM enable signal works correctly on the EPROM output enable because that is the one that has the transistor inverting the signal so I had to make sure it was right. Unless there is a timing issue using a more modern CMOS EPROM doesn't the fact that the memory test numbers are coming out say the EPROM code is running correctly?
What should the screen background be on the memory test?

[Pr0f]

If your eprom is hosting the Minerva OS that's giving you those numbers, then I would suggest it's ok - the problem lies with RAM / Transceiver / ZX8301, but most likely a failing RAM chip...

[Ruptor]

Looking at the circuit there are 33R resistors in series with the outputs that don't make sense. If they were there to protect against over current then they should be 330R to prevent more than 16mA so what is the point in 33R unless it is a timing problem? None of the chips are getting hot on my board like I have seen others describe.

[Pr0f]

Resistors on a bus like that in that sort of value range are more likely to be there to prevent ringing or overshoot on the bus lines due to long copper runs and associated capacitance / inductance.

[Ruptor]

I have done some poking around with the scope and found an obvious problem with the A15 line that doesn't get above 1.2V and the data line pin 2 & 14 on the rams doesn't have any data. I tested the A15 pin on the CPU by bending the pin out and it goes up and down to 5V but I suppose it might do that with no load so not sure if the test says the CPU is OK or not. Now things start to go down hill because putting the CPU back in the socket I bent one of the pins up badly and I was wondering if I blew up the A15 pin when I was looking at the signals on the 33R resistors that are near the ROM port. The scope probe slipped hitting the wire leads on the back of the ROM port making the computer do weird things and I now realise there is a zero volt metal ring around the bottom of the scope probe that might have shorted out the A15 line.
I took the CPU out and pulled the A15 pin up with a wire to see if any heated up but no change. Not sure what to do now.
Update: I put a 10K pull up on the A15 line and it gave 5V square waves but also what looked like spikes at regular intervals. It didn't make any difference to the original ROM operation but my EPROM board doesn't give the ram errors now. It could just be it has sustained damage due to being plugged in and out so many times so I am checking its continuity again.

[Ruptor]

My two new 68008 chips arrived. The A15 line switches 5V now instead of 1V but the problem is still the same so I did blow up the A15 output when my scope probe slipped. Poking the scope around I can see there is no signal on pin 15 of the RAM chips so they are probably not being refreshed are they? Lifted pin 10 CAS1L on the ZX8301 and it is stuck high and the unconnected RAM pins are low. I don't want to buy another ULA if it is the fault because it will only go again for the same reason they fail in other machines. What I don't get is how are the Minerva numbers being put on the screen if the screen memory isn't holding the data and ditto with the screen clear of a standard ROM. Looking for a QL expert to explain what is going on and if the ULA is really the problem.

[Pr0f]

The reason a display is possible, is that the CPU is mostly running code from the Eprom - as long as the sync signals are being sent to the monitor/TV, then you should get stable video - if you get data to make up the pixels - even if incomplete - it should still build a picture of some sort.

The RAM check logic is designed to test the RAM and output the first failing address and hopefully what bit's in the data are faulty.

[Ruptor]

The reason a display is possible, is that the CPU is mostly running code from the Eprom - as long as the sync signals are being sent to the monitor/TV, then you should get stable video - if you get data to make up the pixels - even if incomplete - it should still build a picture of some sort.

Sorry I don't understand. Isn't the display held in the dynamic RAM and pulled out by the ULA? If the RAM isn't holding the data how can we get a display? Is there a picture of the RAM test output on a fully working machine for comparison?

[Pr0f]

The RAM test display is just a green / white / red and black randomish pixel spread - covering the whole screen - the RAM is 128K in a standard QL, and the display sits in the bottom 32K of that memory. The ZX8301 takes the data it reads from RAM to produce the display - nothing intelligent will appear on the display until the RAM test completes. If it misreads data from the RAM or the RAM is faulty - you may see missing lines in the display, or some sort of pattern, but you can certainly get some display if the basic timing mechanics of the ZX8301 are working.