How to troubleshoot a Sinclair ZX16K RAM Issue 3

Discussions about Sinclair ZX80 and ZX81 Hardware
User avatar
1024MAK
Posts: 5101
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: How to troubleshoot a Sinclair ZX16K RAM Issue 3

Post by 1024MAK »

You should also add a 100nF and a 10uF decoupling capacitors across the +5V/VCC and 0V/GND of the logic chip, the 100nF should be as close as possible to pins 7 and 14 as possible.

Try

Code: Select all

1 LET P=32768
2 LET O=PI-PI
3 POKE P,O
4 PRINT AT O,O;PEEK P
5 POKE P,255
6 PRINT AT 1,O;PEEK P
7 GOTO PI
Then see if /CAS on the DRAM chips pulses low.
You can speed up the program, but without the display showing anything by using FAST. Press SPACE/BREAK to regain control. SLOW gets back to normal.

If /CAS does not pulse low, then the PEEK will return 255, as the DRAM chips will not be responding. In which case, either there is a problem with the address or control lines to the RAM pack ULA, or there is a problem with the ULA.

Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: Standby alert :!:
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer later in the year.
Sam-Can
Posts: 16
Joined: Sun Jun 27, 2021 4:13 pm

Re: How to troubleshoot a Sinclair ZX16K RAM Issue 3

Post by Sam-Can »

Ah yes, decoupling the IC power from the main power supply. For fun, I put a scope on the power to observe the effect of adding these capacitors:

Before:
Existing power.jpg
After:
Power both.jpg
Then I did a slight variation on your program:
Prog.jpg
And measured the /CAS line on the RAM pack:
CAS jammed hi.jpg
And unfortunately still:
Result.jpg
So I think we are at the point of:
  • An issue with the RAM pack control lines: { /WR /MREQ /RD / RAMCS /RFSH }.
  • Something with one or more of the 4116's causing the /CAS line to be as observed. Of course they are all soldered to the board. So I guess I could remove them all, test them outside the circuit and replace as necessary.
  • Problem with the RAM pack ULA generating a /CAS signal. I can't see inside the ULA, so that's kinda got to be the "if all else fails" hypothesis.
RAM pack control lines:
  • /RAMCS: Main board gives lots of pull active/low, RAM pack gives high. Difference makes sense because PokeMon circuit calls for these two not to be connected.
  • /RFSH: Both sides (main board/RAM pack) this line is pulled active/low often (150..300 KHz) which makes sense because the Z80 is signaling to the RAM pack etc. other topic.
  • /MREQ: Both sides this line is pulled active/low very often. Again, makes sense: the program is POKE-ing and PEEK-ing, in addition to the ROM interpreter running the program etc.
  • /WR: Both sides this line is relatively occasionally pulled active/low. I can buy this in the sense that the program is POKE-ing, but that's really the only memory writes going on.
  • /RD: Both sides this line is very often pulled active/low. Same comment as /MREQ.
So... I claim the control lines are behaving as expected.

That kinda leaves us with the 4116s and the RAM pack ULA output, doesn't it?
User avatar
1024MAK
Posts: 5101
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: How to troubleshoot a Sinclair ZX16K RAM Issue 3

Post by 1024MAK »

Tested on the ULA pins I presume?

Also, what do you get on ULA pin 9 and on pin 14?

For ideas on how to replace the ULA, have a look at this topic ;-)

Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: Standby alert :!:
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer later in the year.
Sam-Can
Posts: 16
Joined: Sun Jun 27, 2021 4:13 pm

Re: How to troubleshoot a Sinclair ZX16K RAM Issue 3

Post by Sam-Can »

Before responding to your question, MarkI wanted to verify my implementation of PokeMon's circuit is OK. Having scoped it a bit, I'm not so sure it's behaving as intended.

Quick theory recap:

Code: Select all

00.. .... .... ....    ROM 0000 
01.. .... .... ....    RAM 4000 - normally the onboard 1K
10.. .... .... ....    ROM 8000 - normally the unused shadow ROM, so this is what to detect
11.. .... .... ....    RAM C000 - shadow of 4000, where M1 cycle triggers forced NOPs while reading real "opcodes" as video data
OK now on to testing. This was on the modified ZX81 with the K cursor just sat there i.e. nothing is being asked of the 16K RAM pack that is in essence just sat there powered up presumably refreshing a whole load of nothing.

Here the upper yellow trace is pin 2 i.e. A14 off the board, while the lower cyan trace is pin 3 i.e. /A15 off the board. If you mentally invert the cyan one, these signals seem to be following each other i.e. either both inactive (reading ROM?) or both active (reading RAM for video). This makes sense given that the computer isn't running a program: that would provoke more non-video use of RAM i.e. yellow changing, cyan not.
Pins 2 (Main A14) and 3 (Inv A15).jpg
The the result generated by the 74LS02 (which remember is a NOR IC - if both inactive then active, otherwise inactive) is as follows:
Pin 1 (RAM pack A14).jpg
This isn't right: the yellow line in the lower image should be flat inactive because when just sat there with a K there is no attempt to access the RAM pack memory at $8000..$BFFF i.e. there's no "10.." like in the above table.

When I did further scope analysis, there seems to exist a moment when both inputs are logical 0 due to:
  • A 0 from the slightly delayed rising edge of /A15, the output of NOR gate b which is an inverter of the falling edge of A15 i.e. when going from shadow RAM to RAM. This line is busy of course because while sat there with just a K on the screen, the video system is still busy.
  • A 0 from the falling edge of A14 i.e. when going from RAM (shadow or normal) to ROM.
This is way beyond my electronics expertise. How to get rid of the spurious output please?

That being said, I had a moment of inspiration (something Mark wrote earlier I think) and ran my simple program in FAST mode...

Code: Select all

10 POKE 32768,2
20 PRINT PEEK 32768
30 GOTO 10
With this, I got nice waveform outputs as expected from the whole system - yay. (I also got a screen-full of 255s :roll: ) And this makes sense. In FAST mode there's no video so there's none of those pesky edges listed above causing the spurious edge. Yes this is a kludge, however I'm being transparent about it!

Requested signals off RAM pack ULA IH035E:
  • Pin 9 = inbound A14 from this circuit is as expected - in FAST mode, it's active when accessing 32768. So this signal is behaving as expected i.e. it occasionally goes HIGH representing that access to 32768.
  • Pin 14 = select signal to the 74LS157. When not running the program, this signal is busy active/inactive - makes sense if nothing else for the refreshing going on. When the program is run, there is also busy active/inactive. However when pin 9 is HIGH, select is LOW for the entire pulse i.e. selecting A8/A7/A10/A9 as the lower 4 bits. It doesn't however flick over to HIGH to multiplex the other half of A1/A0/A3/A2 in.
  • Pin 15 = CAS... my nemesis. No matter whether the program is running or not, it just floats high.
User avatar
1024MAK
Posts: 5101
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: How to troubleshoot a Sinclair ZX16K RAM Issue 3

Post by 1024MAK »

Sam-Can wrote: Sun Jul 11, 2021 6:13 pm The the result generated by the 74LS02 (which remember is a NOR IC - if both inactive then active, otherwise inactive) is as follows:
Pin 1 (RAM pack A14).jpg

This isn't right: the yellow line in the lower image should be flat inactive because when just sat there with a K there is no attempt to access the RAM pack memory at $8000..$BFFF i.e. there's no "10.." like in the above table.

When I did further scope analysis, there seems to exist a moment when both inputs are logical 0 due to:
  • A 0 from the slightly delayed rising edge of /A15, the output of NOR gate b which is an inverter of the falling edge of A15 i.e. when going from shadow RAM to RAM. This line is busy of course because while sat there with just a K on the screen, the video system is still busy.
  • A 0 from the falling edge of A14 i.e. when going from RAM (shadow or normal) to ROM.
This is way beyond my electronics expertise. How to get rid of the spurious output please?
No need, remember, the memory (control logic and hence memory chips) should not respond until the /MREQ signal from the Z80A is active (low). The address lines and any address decoding logic can produce any old random waveforms while /MREQ is high.
Sam-Can wrote: Sun Jul 11, 2021 6:13 pm That being said, I had a moment of inspiration (something Mark wrote earlier I think) and ran my simple program in FAST mode...

Code: Select all

10 POKE 32768,2
20 PRINT PEEK 32768
30 GOTO 10
With this, I got nice waveform outputs as expected from the whole system - yay. (I also got a screen-full of 255s :roll: ) And this makes sense. In FAST mode there's no video so there's none of those pesky edges listed above causing the spurious edge. Yes this is a kludge, however I'm being transparent about it!

Requested signals off RAM pack ULA IH035E:
  • Pin 9 = inbound A14 from this circuit is as expected - in FAST mode, it's active when accessing 32768. So this signal is behaving as expected i.e. it occasionally goes HIGH representing that access to 32768.
  • Pin 14 = select signal to the 74LS157. When not running the program, this signal is busy active/inactive - makes sense if nothing else for the refreshing going on. When the program is run, there is also busy active/inactive. However when pin 9 is HIGH, select is LOW for the entire pulse i.e. selecting A8/A7/A10/A9 as the lower 4 bits. It doesn't however flick over to HIGH to multiplex the other half of A1/A0/A3/A2 in.
  • Pin 15 = CAS... my nemesis. No matter whether the program is running or not, it just floats high.
That’s very odd, the ULA pin 14 signal.

There is more than one way of doing the controls for DRAM. Normally DRAM control logic changes /RAS from high to low, while holding the multiplexer control (‘switch’) input in the correct state so that the DRAM chips get the lower seven bits of the address bus. As this is the address lines needed for refresh (from the Z80A). The DRAM chips latch the address in on the falling edge of /RAS. Hence the name, row address strobe.

What happens next depends on the design. Either the multiplexer control (‘switch’) input changes shortly after the /RAS line changes state, and it does this every time regardless. Or it only changes state when either an actual read or write operation is taking place because the address decoding circuitry has decided the address is valid.

Either way, if the address decoding decides it’s a valid memory access, after a short delay to allow the multiplexer chips to present the upper half of the address to the DRAM chips and for the lines to stabilise, /CAS should go from high to low to strobe in and latch the upper half of the address into the DRAM chips. Then the DRAM chips will either grab the data on their data input pin(s), or output data on their data output pin(s) depending on the state of the /WRITE control line.

If the address decoding logic decides the address is not valid then /CAS should remain high.

Whenever the DRAM see /RAS go from high to low, they perform a refresh operation whether or not /CAS changes state.

Note the above is valid for this type of DRAM (4116), some later DRAM chips have other memory cycles.

Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: Standby alert :!:
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer later in the year.
Post Reply