ZX81 RAM pack Issue 3 (ULA 1H035E) DRAM refresh

Discussions about Sinclair ZX80 and ZX81 Hardware
Sam-Can
Posts: 16
Joined: Sun Jun 27, 2021 4:13 pm

ZX81 RAM pack Issue 3 (ULA 1H035E) DRAM refresh

Post by Sam-Can »

I've been investigating the Ferranti ULA 1H035E used in the ZX81 RAM pack Issue 3. One aspect of this that is as yet a mystery to me is how the DRAM in this particular RAM pack is refreshed.

For the Issue 1, an analysis of the schematic that is widely floating around shows the following. I think. (Throughout all of this, both /RD and /WR, as well as /M1, remain inactive.)

Step #1
  • Z80 pulls /RFSH active during the first half of M1:T3
  • As /RFSH goes active, the inverted signal is used to pulse the 393 row counter and select the multiplexed counter (instead of A7:A0) for the 7-bit row ID to refresh.
  • As /MREQ goes inactive, the high address is selected.
  • /RAS line is pulled inactive by /MREQ.
Step #2 (about 160ns later since 1/2 cycle of 3.25 MHz)
  • During the second half of M1:T3, the Z80 pulls /MREQ active.
  • As /MREQ goes active, the high/low multiplexor selects the low address, itself multplexed to the counter.
  • /RAS line is pulled active by /MREQ.
With the /RAS line pulled active, the row ID indicated in the counter is selected and that row is effectively refreshed. Each IC has 128 rows (each of which has 128 columns), and the datasheet states that each row should be refreshed every 2ms. (0.002 / 128 => need a refresh every 15,625 ns... which coming from the Z80 refresh but using a +1 counter should easily happen.)

Step #3 (about 325ns later since 1 cycle)
  • During the second half of M1:T4, the Z80 pulls /MREQ inactive.
  • As /MREQ goes inactive, the high/low multiplexor now selects the high address A13:A7 (which will have part of the value of I:R).
  • /RAS line is pulled inactive by /MREQ.
Step #4 (about 160ns later)
  • Starting the new T1, the Z80 pulls /RFSH inactive.
  • As /RFSH goes inactive, the inverted signal is used to select the multiplexed counter back to A6:A0.
(The particularly astute reader will notice that the row address should be stable when /RAS is pulled active, however the Sinclair implementation comes in slightly later than /RAS being activated due to propagation delay across the selector logic and the multiplexor.)

Anyhoo, this is about DRAM refreshing on the Issue 3. This is a different beastie because of ULA IH035E instead of the OR gate, NAND gate, 1 of the multiplexors and the counter.

Here's the pinout of this chip:

Code: Select all

A11	[ 1	U	20]	Vcc
A12	[ 2	L	19]	4116:a4
A13	[ 3	A	18]	4116:a5
A4	[ 4		17]	4116:a6
A5	[ 5	I	16]	4116:/WRITE
A6	[ 6	H	15]	4116:/CAS
/RFSH	[ 7	0	14]	157:SELECT
/MREQ	[ 8	3	13]	4116:/RAS
A14	[ 9	5	12]	/WR
Vss	[10	E	11]	/RD
Thinking about the address inputs on the 4116s:
  • {a6,a5,a4} come from the ULA (which presumably has an internal multiplexor for {A13,A12,A11} and {A6,A5,A4}
  • {a3,a2,a1,a0} come from the 74LS157 multiplexor where the ULA selects either 0:{A8,A7,A10,A9} or 1:{A1,A0,A3,A2}.
Fiiiiinally, the question: how does refreshing work in this case? And in particular, where does the row ID come from?

One answer I know is wrong would be the hypothesis that the ULA has an internal 7-bit counter i.e. an equivalent of the 393 used in the Issue 1. This can't be the case because part of the row ID on the Issue 3 must be one of the outputs from its 157 i.e. either A10:A7 or A3:A0 from the address bus of the base system i.e. it would be picking up at least part if not all of the value of I:R. The bothersome thing about this is that I is a fixed value and R is reset to specific values for video generation.

Help! (Please :lol: )
Last edited by Sam-Can on Sat Aug 07, 2021 5:05 pm, edited 1 time in total.
User avatar
1024MAK
Posts: 3777
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: ZX81 RAM pack Issue 3 (ULA IH035E) DRAM refresh

Post by 1024MAK »

You may want to have a wander through this topic: DRAM control circuits ;)

Now ask the next question about DRAM refresh…

Mark
Sam-Can
Posts: 16
Joined: Sun Jun 27, 2021 4:13 pm

Re: ZX81 RAM pack Issue 3 (ULA IH035E) DRAM refresh

Post by Sam-Can »

In all cases each data line (D0 to D7) goes to the data line (input and output) connections on each DRAM chip. Address lines A0 to A13 (for ZX81) go to two 74LS157 "two to one line selector" chips. The outputs from the 74LS157's go to all the DRAM chips. Note that the Z80 address lines A0 to A6 have the address for refresh on them, so these must be the lines selected by the 74LS157's and routed to the DRAM chips when /RAS goes active to logic low, so that the DRAM chips can refresh correctly. Other than that, the order of the address line connections is non critical.
Basically: /MREQ low -> /RAS low -> short delay -> flip address multiplexers -> short delay -> /CAS low. Those delays sometimes implemented using Z80 clock, sometimes with simple RC delays (both methods have pro's and cons).
Thanks for the link, I did actually read this one as part of my homework 8-)
Now ask the next question about DRAM refresh…
I'm in that dark place of not knowing what my next question should even be e.g. about DRAM refresh or about the ULA :?

Umm err here's a couple of attempts:
  • In the same way the order of data bits is not important e.g. data bus line D4 could go to any one of the 8 4116 ICs, in theory the same could be done within the two sets of A13:A7 (used for columns) and A6:A0 (used for rows) I guess (e.g. A6 could be used for a2, but A9 could not be because A9 does not convey the value of the R register)? In other words, addresses don't have to be refreshed rows 0, 1, 2... it could be any order as long as there is a complete uniform distribution it seems. :shock:
  • How come in the Issue 1 RAM pack they bothered to have a pulsed counter as opposed to (at least my understanding of) the Issue 3 strategy of relying on the Z80 generating the address to refresh? Part of me wants to think: Issue 1 was being thorough, Issue 3 was being more Sinclair i.e. get away with minimal BOM? :lol:
  • Why didn't they bother using DRAM with built-in refreshing, like they did with the base system 2K chips on the TS1000? I'm guessing this comes down to cost again but still...
Please teach me, oh guru, what I should be asking!
User avatar
1024MAK
Posts: 3777
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: ZX81 RAM pack Issue 3 (ULA IH035E) DRAM refresh

Post by 1024MAK »

Sam-Can wrote: Sun Jul 25, 2021 1:34 pm
  • In the same way the order of data bits is not important e.g. data bus line D4 could go to any one of the 8 4116 ICs, in theory the same could be done within the two sets of A13:A7 (used for columns) and A6:A0 (used for rows) I guess (e.g. A6 could be used for a2, but A9 could not be because A9 does not convey the value of the R register)? In other words, addresses don't have to be refreshed rows 0, 1, 2... it could be any order as long as there is a complete uniform distribution it seems. :shock:
Yep 👍
Sam-Can wrote: Sun Jul 25, 2021 1:34 pm
  • How come in the Issue 1 RAM pack they bothered to have a pulsed counter as opposed to (at least my understanding of) the Issue 3 strategy of relying on the Z80 generating the address to refresh? Part of me wants to think: Issue 1 was being thorough, Issue 3 was being more Sinclair i.e. get away with minimal BOM? :lol:
I suspect that because of the way that the ZX80 and ZX81 use the Z80 refresh system for part of the display generation, they thought that a separate refresh generator would be needed. But sometime later, someone obviously experimented and discovered that even with the arrangements used, the Z80 refresh system (along with normal program execution) was enough on its own to keep the DRAM content without problems. Possibly aided by the DRAM chips not actually needing to be refreshed as often as the timings in the data sheet say.

Remember the ZX81 video system works differently depending on how much RAM it has detected as being present. The video display file is fully expanded when a 16k byte RAM pack is fitted. The fully expanded VRAM size is 793 bytes. The refresh required by the 4116 DRAM is 128 cycles/7 bit. So while the system is generating a TV image, the mere operation of reading data from the RAM is refreshing it.
Sam-Can wrote: Sun Jul 25, 2021 1:34 pm
  • Why didn't they bother using DRAM with built-in refreshing, like they did with the base system 2K chips on the TS1000? I'm guessing this comes down to cost again but still...
Cost!

The cheapest RAM per byte at the time was 4116 16k x 1 bit DRAM. SRAM and DRAM with built-in refresh were very expensive in comparison.

Also note that every time the DRAM chip is accessed (be it refresh, read or write), the row concerned is refreshed. So as long as the running program causes address lines A0 to A6 to each change state sufficiently often and through every permutation, the DRAM will work fine. Until the processor gets in a tight loop or HALTs… that’s when the Z80 refresh system is the only method active to refresh the DRAM. Note, the above assumes the Z80 clock is not stopped and there has been no request to the Z80 to release control of the busses.

Mark
User avatar
1024MAK
Posts: 3777
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: ZX81 RAM pack Issue 3 (ULA IH035E) DRAM refresh

Post by 1024MAK »

Oh, and you may want to compare the ZX81 with the ZX Spectrum 16K/48K/plus models. These have no refresh provision for the ‘lower’ 16k bytes of DRAM. There was a design error that prevented the Z80 refresh system from being able to refresh this area of RAM… Instead it’s only the reading of screen data by the ULA that keeps this area of RAM refreshed if the Z80 is not accessing it.

Mark
Sam-Can
Posts: 16
Joined: Sun Jun 27, 2021 4:13 pm

Re: ZX81 RAM pack Issue 3 (ULA IH035E) DRAM refresh

Post by Sam-Can »

Thanks Mark! Well this answers one question I had concerning the 128 x 128 DRAM matrix which was how come the rows were assigned the 7-bit value from A6..A0 and the columns A13..A7.

For any brave souls following along, in theory the other way around might seem cleaner i.e. A13..A7 rows, and A6..A0 columns within the rows. However given that the screen is at $4000 (yeah and $C000 sure) and there are HALT + 24_line x (32_colums + HALT) characters = (1 + (24 x (33 + 1))) = 793 = $319 memory locations used for the display file (when on a system with >= 4K RAM) then it follows that memory locations $4000..$4318 will be regularly accessed. Values in the range $000..$318 needs 9 bits to represent them, and 8 bits will do $00..$FF, and so 7 bits will do $00..$7F. Meaning that if one were to serially access $4000, $4001 etc., as is done to display the screen, the range $00..$7F is accessed $4000, $4080, $4100, $4180, $4200, $4280, $4300 = at least 6 times (and partially 7 for $4300..$4319). Since the screen is refreshed every 1/50s (1/60s in North America), there are those 6 refreshes every 0.02s = 20ms (or 16ms). Scaling that back to a single refresh, 20 / 6 = a refresh is generated every 3.3ms (2.7 ms). And apparently this is close enough to the datasheet specification of 2ms that the capacitors inside the memory hold their charge.

Much to learn. To paraphrase 3D Monster Maze, "Clive lies in wait" :lol:

Back to my original question:
How does refreshing work in this case? And in particular, where does the row ID come from?
The answer (at least for an Issue 3 RAM pack) would seem to be by a side-effect of the expanded system displaying the screen contents, where the row ID is the bottom 7 bits of the screen address.

Except now that raises a new question, as I read the discussion about SLOW / FAST mode. How come with a ZX81 with a 16K RAM pack when one selects FAST mode, and thus there is no screen access, the capacitance doesn't decay resulting in RAM gradually zero-ing due to a lack of video RAM access by the ULA? In that case, I can imagine an Issue 1 RAM pack working (as it has its own refresh circuitry) but the Issue 3 RAM pack would seem like its contents might "melt"...
User avatar
1024MAK
Posts: 3777
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: ZX81 RAM pack Issue 3 (ULA IH035E) DRAM refresh

Post by 1024MAK »

On the general subject of DRAM: Although the Acorn BBC Micro uses an Hitachi 16k x 1 bit DRAM chip, the principles and technology are very similar. I go into some detail over on the StarDot forum here.
Sam-Can wrote: Sun Jul 25, 2021 6:21 pmExcept now that raises a new question, as I read the discussion about SLOW / FAST mode. How come with a ZX81 with a 16K RAM pack when one selects FAST mode, and thus there is no screen access, the capacitance doesn't decay resulting in RAM gradually zero-ing due to a lack of video RAM access by the ULA? In that case, I can imagine an Issue 1 RAM pack working (as it has its own refresh circuitry) but the Issue 3 RAM pack would seem like its contents might "melt"...
Don’t forget the Z80 still increments the refresh register (R) with every instruction fetch (including during HALT) and outputs this on address lines A0 to A7 (although bit 7 does not change unless the program changes it). And as the display system is not used during FAST mode, this normal Z80 refresh will operate to keep the DRAM refreshed.

Wilf Rigter describes the video system in detail here ;-)

Mark
Sam-Can
Posts: 16
Joined: Sun Jun 27, 2021 4:13 pm

Re: ZX81 RAM pack Issue 3 (ULA 1H 035 E) DRAM refresh

Post by Sam-Can »

Don’t forget the Z80 still increments the refresh register (R) with every instruction fetch (including during HALT) and outputs this on address lines A0 to A7 (although bit 7 does not change unless the program changes it). And as the display system is not used during FAST mode, this normal Z80 refresh will operate to keep the DRAM refreshed.
Indeed it does. However I have the ULA extracted and on my workbench, and I can confirm it has an internal counter of some kind. I've been investigating. And I now have proof that when /RFSH-ing, the Issue 3 is just like Issues 1 and 2 i.e. that it does not use the I:R value presented on the address bus.

ULA.jpg

Yeah it's ugly e.g. no debounce on the push-button. Using 10K pull-up/down resistors does seem to be yielding results... of sorts :lol:

Finding #0: It draws about 0.46-0.50A at +5V and operates at about 35oC. (For pin-outs, see earlier in the thread.) When just sat there, a4-a6 simply reflects A4-A6. (I'm using lower case a to indicate the output address bits that go to the 4116 i.e. there's a0..a6 in theory although the ULA only does a4..a6 and a0..a3 come from the adjacent 75LS157 multiplexor.

Finding #1: Every time /RFSH pulsed active, some apparently internal value is presented at the ULA's output a4-a6 values. It’s as if there’s an internal counter that adds 1 because every 10 pulses the a4 output value changes. The a5 value alternates between 0 and 1 at less frequency, perhaps changing every 20 counts, and a6 at even less frequency. (Tough to count… 40?) The internal counter is not initialized to 0: on a few power ups, sometimes /RFSH and a4 output is high sometimes it is low.

Finding #2: As per #0, when doing "nothing", a4-a6 reflects A4-A6. However when /MREQ is pulsed active, the ULA does two things: select output goes to 0, and pins 18:20 are set to a11-a13 instead of the usual a4-a6. When I pulse both /MREQ and /RD "together" (on the same push-button switch), I get the same results. It's like it's starting to do what it would need to do to multiplex the address for the target 4116s, although nothing on /CAS - more on that in a moment.

Finding #3: So far, at least, the same results are achieved with A14 at 0 or 1. So much for gating the whole thing, as for example Issue 1 and Issue 2 seem to do.

As presented in #2, *no* sign yet of any action on /CAS. At least it is not floating, like it was when it was in-circuit :D (Perhaps a bust 4116 was doing that?) I would expect /CAS to go active moments after /RAS when doing a /MREQ AND /RD pulse... unless I've not (yet) wrapped my head around the Z80 behaviour? (Issues 1 and 2 use the output of the address high/low multiplexor pair such that when a column address is selected (the 3/4 pair in "that schematic", output of pin 11 on the OR gate is 0) that output is slightly delayed before being presented at /CAS on the 4116s.)

Back to Issue 3: this may be a bust ULA, I have no way to guarantee this - although it seems a bit convincing. However at this point I'm coming up for air because I may not be giving this a fair test.

Any suggestions about how to test this further please? And/or to improve the testing!
User avatar
1024MAK
Posts: 3777
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: ZX81 RAM pack Issue 3 (ULA 1H 035 E) DRAM refresh

Post by 1024MAK »

Sam-Can wrote: Tue Aug 03, 2021 1:59 pm Finding #0: It draws about 0.46-0.50A at +5V and operates at about 35oC.
Do you really mean 460mA to 500mA :shock:
Sam-Can wrote: Tue Aug 03, 2021 1:59 pm Finding #1: Every time /RFSH pulsed active, some apparently internal value is presented at the ULA's output a4-a6 values. It’s as if there’s an internal counter that adds 1 because every 10 pulses the a4 output value changes. The a5 value alternates between 0 and 1 at less frequency, perhaps changing every 20 counts, and a6 at even less frequency. (Tough to count… 40?) The internal counter is not initialized to 0: on a few power ups, sometimes /RFSH and a4 output is high sometimes it is low.
That’s interesting. Maybe Sinclair were not certain that the various signals from the Z80A would be enough on their own to properly refresh the DRAM. Even though it works on various third party memory expansions.
It’s strange that the count is not a factor of two. Maybe they did it that way deliberately to prevent it becoming synchronised to the address from the Z80A.
Sam-Can wrote: Tue Aug 03, 2021 1:59 pm Finding #2: As per #0, when doing "nothing", a4-a6 reflects A4-A6. However when /MREQ is pulsed active, the ULA does two things: select output goes to 0, and pins 18:20 are set to a11-a13 instead of the usual a4-a6. When I pulse both /MREQ and /RD "together" (on the same push-button switch), I get the same results. It's like it's starting to do what it would need to do to multiplex the address for the target 4116s, although nothing on /CAS - more on that in a moment.
That sounds like there is a failed ‘gate’ in the ULA. Have you tried holding/RD low before pulsing/MREQ?
Sam-Can wrote: Tue Aug 03, 2021 1:59 pm Any suggestions about how to test this further please? And/or to improve the testing!
Use a NE555 or better still, a 7555. Feed the output to a 74LS04 or 74HCT04 or similar to sharpen up the rise and fall times. Then feed to the /MREQ pin on the ULA.

You can then watch the outputs with a logic probe, LEDs (with current limiting resistors), logic analyser or a oscilloscope.

Mark
Sam-Can
Posts: 16
Joined: Sun Jun 27, 2021 4:13 pm

Re: ZX81 RAM pack Issue 3 (ULA 1H 035 E) DRAM refresh

Post by Sam-Can »

1024MAK wrote: Tue Aug 03, 2021 3:22 pm
Sam-Can wrote: Tue Aug 03, 2021 1:59 pm Finding #0: It draws about 0.46-0.50A at +5V and operates at about 35oC.
Do you really mean 460mA to 500mA :shock:
Despite this thing glowing at 35oC, I was missing a zero :oops:. The ULA draws about 50mA. Good catch!
1024MAK wrote: Tue Aug 03, 2021 3:22 pm
Sam-Can wrote: Tue Aug 03, 2021 1:59 pm Finding #1: Every time /RFSH pulsed active, some apparently internal value is presented at the ULA's output a4-a6 values. It’s as if there’s an internal counter that adds 1 because every 10 pulses the a4 output value changes. The a5 value alternates between 0 and 1 at less frequency, perhaps changing every 20 counts, and a6 at even less frequency. (Tough to count… 40?) The internal counter is not initialized to 0: on a few power ups, sometimes /RFSH and a4 output is high sometimes it is low.
That’s interesting. Maybe Sinclair were not certain that the various signals from the Z80A would be enough on their own to properly refresh the DRAM. Even though it works on various third party memory expansions. It’s strange that the count is not a factor of two. Maybe they did it that way deliberately to prevent it becoming synchronised to the address from the Z80A.
I agree. I need to investigate a bit more on an uninterrupted stream of /RFSH pulses. Coming soon. (And same circuit to test feeding the /MREQ pin, as you suggested.)

1024MAK wrote: Tue Aug 03, 2021 3:22 pm
Sam-Can wrote: Tue Aug 03, 2021 1:59 pm Finding #2: As per #0, when doing "nothing", a4-a6 reflects A4-A6. However when /MREQ is pulsed active, the ULA does two things: select output goes to 0, and pins 18:20 are set to a11-a13 instead of the usual a4-a6. When I pulse both /MREQ and /RD "together" (on the same push-button switch), I get the same results. It's like it's starting to do what it would need to do to multiplex the address for the target 4116s, although nothing on /CAS - more on that in a moment.
That sounds like there is a failed ‘gate’ in the ULA. Have you tried holding/RD low before pulsing/MREQ?
To test your /MREQ pulse idea, I set up:
  • A11/A12/A13 to 0:0:0 and A4/A5/A6 to 1:0:0 (to hopefully see the multiplex)
  • /RFSH inactive (tied high)
  • /MREQ pulsable (tied high although can ground through switch)
  • A14=1 since $4000, RAM etc.
  • /RD active (tied low)
  • /WR inactive (tied high)
And the results from the scope are:
  • /RAS is inactive until the pulse, after which active for the whole duration of the /MREQ pulse. As soon as /MREQ gets off 0V, /RAS is too.
  • /CAS just sits there at 4V: pulses, no pulses, whatever :x
  • a4 is 0 except during the pulse, when it goes to 1. (a5 and a6 stay at 0 as expected.) When a4 is 0, this means the A11/A12/A13 values are being output from the ULA a4/a5/a6 to the 4116s. When it is 1, A4/A5/A6 are being output instead.
  • SELECT is 1/high/5V until the pulse, after which it stays 0/low/0V (causing the 157 to select A0..A3) until the end of the pulse. Like /RAS, as soon as /MREQ gets off 0V, select is back to 1.
  • /WRITE stays inactive as expected.
In terms of the multiplexing, since A4 was set to 1, it follows that when /MREQ gets pulsed active (with /RD already active) the ULA presents the lower address lines (A0/A1/A2/A3) from the 157 and A4/A5/A6 (from ULA). That's expected. What is not expected is /CAS just sitting there at about 4V not doing anything.

This is lending credence to the ULA /CAS output having been damaged somehow :roll: perhaps by a 4116 since all the voltages measure OK. Anyone else got a ZX81 16K RAM pack Issue 3 where they could test the /CAS line? Anyone??
Post Reply