How to troubleshoot a Sinclair ZX16K RAM Issue 3

[Moggy]

A thermal camera? It would be interesting to see what temp a standard zeddy ULA gets to after being inside a case for a hour (switched on and running! )

In my fan cooled zeddy a lot less than 45 deg I would say.

Considering this ULA is running at less than half the max junction temp for series 2C ULAs (125deg) whether in free air or not puts paid to the myth that ALL ULA failure is down to unproven heat damage and not mainly provable expansion slot abuse. It is a more hardy chip than people give it credit for with most of the heat coming from the voltage regulators scattered round the die having to sink something like 4 excess volts give or take. Even if Clive had only connected two thirds of the matrix together those regs would still give off a fair amount of heat, still it earns heat-sink suppliers a few bob.

[Lardo Boffin]

Not wishing to reignite the whole heat sink thing! Just curious what temperature they actually run at.

[Moggy]

In the past I saw one heat sink peddler doing the "probe on the die" thing and how his heat sink lowered the temp by a thousand degrees. Unfortunately it was done in free air so meaningless as to the internal closed case temps involved.

All joking aside his ULA was only running at 60 odd deg without a sink( which seems at odds with the 45.7 deg example pictured earlier in the thread with identical ULA's) with a claimed reduction of 13 deg with sink, all of this in free air and no indication of how loaded the ULA was, length of test etc and how long before the sink reached thermal equilibrium and again even at 60 deg this is less than half the max temp for this chip so heat is the least least of anyone's worry whereas clumsy expansion handling is more of a concern in my opinion.

I would add that the test was done with a multimeter and thermal probe attachment which i would say is not a combination known for total accuracy when measured against say a thermal camera which would go some way to explaining the 15 deg difference in two identical chips (issue threes) as measured by two different devices.

At the end of the day I know of no-one who has proof of heat damage only wiping out the chip whereas the times ULA's have been borked by expansion slot abuse, especially by kluz's like me, is fairly provable even if no-one will admit to such clumsiness.

[1024MAK]

In the meantime, putting electrical tape over 2A (and of course checking for non-continuity prior to switching on) does successfully pass the K test. However there is not the 16K "delay" and the DIM(3000) program above gives me 4/10 i.e. it runs out of memory.

Keep in mind that just isolating /RAMCS on the edge-connector 2A contact on it’s own, is not very helpful. The internal 1K RAM is not fully decoded, so the 1K of actual memory will respond across the whole 16K bytes from 16384 (0x4000) to 32767 (0x7FFF) for every address. So with this set-up you can’t actually read any of the RAM in the 16K RAM pack.

See here for the reason why.

Nice photos there Sam

Mark

[Sam-Can]

What I've understood so far:

[1] By preventing the RAM pack from connecting /RAMCS' to +5V is that the A14-based determination (0=>ROM, 1=>RAM) sent from the ULA is allowed to reach the onboard 1K RAM. Because otherwise if the RAM pack +5V were allowed, this would "over-rule" the /RAMCS' signal at the 1K RAM although wouldn't damage the ULA because of the 680 ohm R2 resistor. In summary: no RAM pack => ULA signal drives onboard /RAMCS, RAM pack => it over-rules the /RAMCS holding it high preventing the onboard RAM ever getting selected.

[2] Typical (UK model for this description) onboard RAM is 1K, which lies from $4000..$43FF. That requires 10 bits of decoding A9..A0 at a minimum, and the ZX81 main board does not decode any other lines. For example, the onboard RAM isn't attached to A10. Consequently if A10 were 1, such as with the address $4400, then the limited decoding results in this addressing ($4400 & %010000111111111) = $4000.

So now this makes me wonder whether some "add-on" logic to the RAM pack might solve this:

[-a-] Supposing one were to detect (A14 AND (((A10 OR A11) OR (A12 OR A13))) and feed that on to /RAMCS', rather than just the straight connection to 5V. My thinking here is that if any address [$4400..$7FFF] (and presumably its ghost [$C400..$FFFF] since I'm not decoding A15 were to be put on the address bus, the /RAMCS' line would be asserted high thereby disabling the onboard ROM.

[-b-] However any address outside of that range would err

Thinking about it, I'm not sure whether that's ideal since in the case of that OR clause being 0, I really want /RAMCS out of the ULA - note the lack of ' i.e. the value before the resistor. Uh oh, my lack of electronics is showing

(Photos = FLIR add-on to iPhone, works well.)

[1024MAK]

What I've understood so far:

[1] By preventing the RAM pack from connecting /RAMCS' to +5V is that the A14-based determination (0=>ROM, 1=>RAM) sent from the ULA is allowed to reach the onboard 1K RAM. Because otherwise if the RAM pack +5V were allowed, this would "over-rule" the /RAMCS' signal at the 1K RAM although wouldn't damage the ULA because of the 680 ohm R2 resistor. In summary: no RAM pack => ULA signal drives onboard /RAMCS, RAM pack => it over-rules the /RAMCS holding it high preventing the onboard RAM ever getting selected.

The ULA also includes the Z80 /MREQ signal in its logic for the /RAMCS, but otherwise correct

[2] Typical (UK model for this description) onboard RAM is 1K, which lies from $4000..$43FF. That requires 10 bits of decoding A9..A0 at a minimum, and the ZX81 main board does not decode any other lines. For example, the onboard RAM isn't attached to A10. Consequently if A10 were 1, such as with the address $4400, then the limited decoding results in this addressing ($4400 & %010000111111111) = $4000.

Yes.

So now this makes me wonder whether some "add-on" logic to the RAM pack might solve this:

[-a-] Supposing one were to detect (A14 AND (((A10 OR A11) OR (A12 OR A13))) and feed that on to /RAMCS', rather than just the straight connection to 5V. My thinking here is that if any address [$4400..$7FFF] (and presumably its ghost [$C400..$FFFF] since I'm not decoding A15 were to be put on the address bus, the /RAMCS' line would be asserted high thereby disabling the onboard ROM.

[-b-] However any address outside of that range would err

Thinking about it, I'm not sure whether that's ideal since in the case of that OR clause being 0, I really want /RAMCS out of the ULA - note the lack of ' i.e. the value before the resistor. Uh oh, my lack of electronics is showing

How and if, you further divide up the memory decoding depends on your objective.

For Sinclair, the objective was the lowest cost design, keeping in mind that the ZX81 ULA chip is basically is all the logic from the ZX80 plus a bit more in one chip. Hence partial decoding is used because it costs less. The result is that the ULA ONLY considers address line A14 from the Z80. And the 1K byte RAM chip only has ten address lines. All the remaining address lines (A10, A11, A12, A13 and A15) are ignored. This gives the ZX81 a 32K byte area where the Z80 can read or write to it, even though it is only a 1K byte chip. This is what makes it so easy to upgrade the internal RAM to 16K bytes

In normal use, there is no point in tidying up the decoding by including address lines A10, A11, A12 and A13 into the decoding logic, because it makes no difference. Furthermore, A15 can’t easily be included in the decoding, because the video system relies on the ‘echo’ / ‘shadow’ of the RAM being in the top quarter of the memory map (49152 or 0xC000 upwards, A14=1, A15=1).

Hence the decoding works like this:

Code: Select all

A15 A14 Memory
 0   0  Internal ROM
 0   1  Internal RAM
 1   0  Internal ROM
 1   1  Internal RAM

However, if you want to attach extra memory or some memory mapped input/output hardware, then the external device has to include some address decoding circuitry to disable either the internal RAM chip (regardless of what capacity it has) and / or the internal ROM chip (which is also partly decoded, if you PEEK 32768 (0x8000) onwards, you will find it returns the same values as 0 onwards, A14=0, A15=0 or A15=1).

This disabling for RAM can be continuous, that’s why 16K RAM packs connect /RAMCS to the +5V supply. Or logic can selectively control either /RAMCS and / or /ROMCS.

If you look at the topic I linked to earlier, you should find a link to download a schematic circuit diagram of the single logic chip and a diode that is needed to move your 16K RAM pack and remap it in the 32768 (0x8000) to 49151 (0xBFFF) range (A14=0, A15=1). To do this, it adds some logic to control /ROMCS. By doing this, it overrules the ULA to ROM control. And hence allows the Z80 to access the external RAM pack without the two different memory systems fighting one another (which is called bus contention).

Mark

[Sam-Can]

Thank you, Mark, for time to provide this invaluable guidance. For those following along, the link he is referring to is: viewtopic.php?p=16720#p16720 where Ian posted PokeMon's circuit. Borrowing heavily from that thread (thanks guys!) and Mark's post, here's how I've been thinking about it.

In theory:

• The typical address map of the ZX81 is something like $0000 ROM, $4000 RAM, $8000 ROM ghost, $C000 RAM ghost - sure there are other ghosts, these are the relevant ones here

• For the machine to be usable, the Z80 needs the ROM program to start from $0000 while the video system needs a RAM ghost at $C000

• /ROMCS' can be pulled high to over-rule the ULA control /ROMCS provided to the on-board ROM thereby preventing ROM enablement

From reading that link, and thinking a bit about it, my understanding of what this circuit does is as follows:

• The /RAMCS' signal is not passed through on the edge connector (the electrical tape trick mentioned earlier i.e. masking 2A on the edge connector) thereby preventing the RAM pack from clamping that signal to high which would otherwise prevent the onboard RAM from being enabled

• The A14 line (0 @ $0000, 1 @ $4000, 0 @ $8000, 1 @ $C000) which effectively indicates whether to select the ROM (if 0) or RAM (if 1) is not passed through on the edge connector - more tape, this time 12B.

• Using a 7402 NOR chip, one gate is used to invert A15 i.e. creating 1 if at $0000..$7FFF, and 0 if $8000..$FFFF. This signal is then NOR'ed with A14, which - if you work through the truth table - creates an output of 1 if the address bus has $8000..$BFFF otherwise 0. This output is passed to the A14 line on the RAM pack, which it decodes as "if 1 then normal RAM access " (else maybe refresh blah out of scope) since it is now effectively "seeing" the addressing of $8000..$BFFF (main PCB) as $4000..$7FFF (RAM pack)

• Using the two other gates on that chip, the A15 line (0 @ $0000..$7FFF, 1 @ $8000..$FFFF) is inverted then inverted again i.e. this is A15 buffered and delayed a bit. This output is tied to /ROMCS' via a diode to protect the chip output from getting zapped by the value otherwise on the line - bus contention management! Doing this means that when addressing $0000..$7FFF the ULA will get its wish and enable the ROM, however when addressing $8000..$FFFF the /ROMCS' line is held high to disable the ROM so the RAM pack memory can be addressed without any bus contention.

Notwithstanding any ghosts from partial decoding, This should result in an address map something like:

Code: Select all

$0000  ROM
$4000  Main on-board RAM (e.g. 1K UK model)
$8000  RAM pack memory (NB max 16k)
$C000  Ghost of incompletely decoded main on-board RAM

Comments/feedback welcomed. I will attempt to build this tomorrow when a fresh 7402 arrives. This mod armed with a memory tester (also kindly provided in the above link) should help me determine whether the RAM is even addressable. Hopefully this will take me closer to knowing why all the RAM pack signals seem fine (I scoped every pin) with the exception of CAS jammed high-ish. Of course if the CAS output is knackered in the ULA, then I'm really going to have to get creative

[TMAOne]

Best of luck Sam-Can.

I enjoy hearing about these things being rescued from the scrap pile, and PokeMon's brilliant little circuit is just the ticket.

Why, only the other day I discovered four more ZX81 RAM Packs holding up a 1963 Corvette Split Window Coupe behind an old barn. Of course I deftly pushed the old Chevy off and recovered the precious RAM Packs. Some people just don't understand the value of things,...

[1024MAK]

Well, ROFL after TMAOne’s comment

Yes, Sam, by George I think you’ve got it

Sorry, brain not getting much oxygen or blood, just come back from a carvery, so feeling a bit bloated at the moment…

Note, Pokemon recommends a 74HCT02. If you don’t have, or can’t get this version, I know of a different way to drive the /ROMCS line. In fact I think it was mentioned in one of the linked topics.

Mark

[Sam-Can]

Well the results are in, and they are err not so good. In summary, it's like the memory addresses $8000..$BFFF (i.e. the RAM pack memory) always return $FF.

See attached picture of implementation (meticulously checked for connections), where top board is a composite video thing and the board on the right is this PokeMon circuit. Also included: FLIR, test program and results before the computer reset And trying the .p in the link that writes $00 then $FF and tests, it crashed (This program is also > $1K )

Various other experiments are such that, when accessing the memory, PEEK only returns $FF. Remember the original symptoms when all signals were scoped were that everything was fine except for some reason the whole CAS line is jammed high.

Thoughts