Houston, we have an image!

[zx80nut]

Yes, but in that case, Wilf is not correct.
To implement exactly as a ZX81, it needs extending. As you have designed the ULA logic yourself, it doesn't need it.

Grant

[Andy Rea]

Hi pokemon,

Grant, retrotechie and myself have all observed the 'strected' Mreq signal, it's true this is what a real ULA does, Retrotechie implements it in his ULA in CPLD design, i did not

i think sinclair did it to allow for the slow-ish rams that were around at the time...

Regards Andy

[RetroTechie]

i think sinclair did it to allow for the slow-ish rams that were around at the time...

Replace "slow-ish rams" with "slow-ish roms": true Hi-Res works with internal RAM but is practically useless with 1 or 2K, and doesn't work with unmodified 16K RAM pack. For regular ZX81 display and pseudo Hi-Res, pixel data comes from ROM, and this is where stretched /ROMCS helps. IMHO it's a perfectly good explanation, that Sinclair didn't think of true Hi-Res option, and slow ROMs were the reason for /ROMCS stretching.

AFAIK most ROMs found in ZX81's would be fast enough to do withhout. But having the option to use much slower ROM chips (450 ns was available in those days) increases # of options from which manufacturer to source those ROMs. And increases safety margins for situations where you're cutting it close. All of which wasn't a bad thing for Sinclair who grabbed parts wherever they were cheapest.

My CPLD implementation is largely the result of having real ULA and CPLD side-by-side during development. Starting from scratch I'd probably have tried to avoid /ROMCS stretching. But I have it in there now, it matches real ZX81 behavior, works fine, and it isn't complex or difficult to understand.

In my CPLD implementation, /RAMCS timing is the same as /ROMCS (A14 only decides which of /ROMCS or /RAMCS goes active). So in true Hi-Res modes, /RAMCS is stretched like /ROMCS during DFILE execution. TBH I have no clue whether that is the case on a real ZX81. But I don't really care much as long as differences are invisible from software point of view, and on-screen result is the same.

More interesting would be to get rid of overlap between /RAMCS and forced NOP during DFILE opcode fetch (T2/T3). Shouldn't be too hard I think (eg. you could use force NOP signal as a disable for /ROMCS and /RAMCS). Without that overlap, there'd be no conflict on the databus(ses!), and the separator resistors in there (R7-R14) could go. Which would make a ZX81 clone both simpler & easier to understand. Should I ever revisit my ZX81 ULA, definitely something to try.

[PokeMon]

Did anyone really prove the timepoint when data is loaded into ULA shift register ?
As this is an internal process it can not really be measured, maybe just guessed through the stretched ROMCS signal during video code execution.
I want to do a test, feeding with data at falling edge of T4 and feeding with other data at rising edge of T1.
Did anyone do this before ?

As I know, Andys ULA is working properly on several hardware.
So maybe the extension is just a relic through some early testing and leave it untouched later.

Well I don't know about this but I think it is not just a question of some pF as you need something about 40pF or up to hold the datalines low for a period of about 75ns - assuming that /MREQ has a delay of 75ns after falling edge of T4 (the maximum is rated with 85ns in datasheet).

[zx80nut]

Although the actual load point has not been proven yet, the scope pics of the ZX80 and ZX81 reveal that the character appears exactly the same time very shortly after the T1 rise of the next opcode. As the ZX80 loads the character shift reg at the start of the T1 period and the two machines are producing the character at the same time, plus the extended /CS for the character load, then everything points to the ZX81 loading the character into the latch in the same way. I can't possibly see that the extended ROM CS being accidental. If it was standard timing then it would be too short for reliable capture by the shift register at the start of T1 (floating bus).

Look at my scope pics and it shows the character out for both the 80 and the 81 (it's displaying a solid black block in a vertical line down the screen, so there is an 8 pixel black period with white either side). The offset is purely due to propogation time into the shift register.

http://searle.hostei.com/grant/zx80/zx80ScopePics.html

Regards.

Grant.

[PokeMon]

Yes - you could assume that it is loaded parallel into a shift register and bit 7 is wired to video out immediately.
Could be also wired to an additional flipflop which creates the delay of 1 pixel / half clock period.
This is not an explanation for extending ROMCS.

By the way I could not find any reason why length of ROMCS is handled different during refresh depending on video output or not.
Anyway they could even suppress ROM access when no ULA is used for video out or use the same length of ROMCS regardless if video out or not.
I think ROM data is not needed at all during refresh when no video out routine is running.

Strange, isn't it ?

[zx80nut]

Hmmm... I can see no point in delaying by half a clock - that is additional logic which in this case would be wasted. Why would they bother with the extension to the ROM CS if they already had the data in the buffer? As I said, I cannot see the extension to the CS being accidental, as it fits perfectly with what would be required to match the existing ZX80 implementation.

This is not an explanation for extending ROMCS.

I disagree. Not sure how much more evidence is needed.

By the way I could not find any reason why length of ROMCS is handled different during refresh depending on video output or not.

I think we have already explained that

To me, the evidence is definitely pointing to the same as the ZX80. After all, the ZX81 is only a revisited ZX80 with NMI logic and a few tweaks (and a few cut-downs eg. using resistors instead of multiplexors that are in the ZX80).

Grant.

[RetroTechie]

Yes - you could assume that it is loaded parallel into a shift register and bit 7 is wired to video out immediately.
Could be also wired to an additional flipflop which creates the delay of 1 pixel / half clock period.

You can safely assume that last option is not the case. Why? Simple: it would require an additional flip-flop.

I know, this sounds like a BS reason, and 'logic is cheap'. But remember we're talking a semi-custum IC here that was produced in 100,000's or more. For such IC's, you simply DON'T include anything that isn't absolutely necessary. Period. Semi-custom IC's aren't developed like average software, but more designed & built like a house. And certainly in the 80's, even a single storage bit in a semi-custom IC wasn't as cheap as today. So if an extra storage bit could have been avoided, chances are it was (+ observed behavior matches that).

This is not an explanation for extending ROMCS.

That's even simpler. Remember the correspondence between ZX80 and ZX81 behavior? Now go check ZX80 schematic. It shows ROM /CS something like "(/MREQ active and A14 low) OR (/RFSH active)". The "/RFSH active" is the important thing here, it means that its ROM is enabled whenever /RFSH is active, regardless what other signals are doing. Which allows reliably clocking the video shift register at end of T4, because /RFSH is still active @ that point.

The ZX81 ULA doesn't have /RFSH signal on any of its pins, so ZX80 logic without changes isn't possible. We can only guess why that is so - perhaps another occurrence of "semi-custom IC, not absolutely necessary, therefore not included".

By the way I could not find any reason why length of ROMCS is handled different during refresh depending on video output or not.

EDIT - didn't read properly before. This is an interesting question indeed, why /ROMCS stretching would not be done for regular refresh cycles also (to minimize the logic). One possible reason would be to not enable the ROM more than necessary, in order to keep power consumption to a minimum. Which would be a valid reason with the tiny heatsink on the 7805 and cramped (plastic!) ZX81 housing. Another possibility is that it doesn't make any difference in complexity for the decode logic, and what the ZX81 ULA does is simply a 'random' option that was picked.

Anyway, like Grant says: try to understand a ZX81 as a ZX80 with tweaks, and your life will be easier.

[PokeMon]

By the way I could not find any reason why length of ROMCS is handled different during refresh depending on video output or not.

I think we have already explained that

Nobody did explain this at all. What is the reason for not enabling the ROM during /RFSH in same way regardless if video output or not ?
Just a little bit power consumption ? And why and for what is /ROMCS needed during refresh cycle when not outputting video data ? If it's handled in a different way they could even suppress it.

To me, the evidence is definitely pointing to the same as the ZX80. After all, the ZX81 is only a revisited ZX80 with NMI logic and a few tweaks (and a few cut-downs eg. using resistors instead of multiplexors that are in the ZX80).

There are some modifications. You only assume that the discrete logic of the ZX80 has been packed into the ULA without any modifications. But there are modifications, not just NMI. For example the ROM in the ZX80 is enabled simply during refresh cycle (pin 5 of IC6 simply wired to GND) and no disctinct wether video display or not (assuming that CS1 and CS2 of the ROM are active low, wasn't stated in schematic nor did I find any datasheet of this ROM). And in the ZX81 the /ROMCS is not enabled during whole refresh cycle).

By the way I did find out, that it doesn't matter at which timepoint the data is token into the shiftregister as it is always the same timepoint. This would just result in moving the picture 1 or 2 pixel to the left or right on screen.

But found some more complicate stuff. As studied schematic of ZX80 the Shift/Load is low under following conditions:
"Video display=1" which is build with /HALT=1 & A15=1 & D6=0
/MREQ=1
system clock=0 (the clock to this logic has to be "1" but is mirrored with the system clock of cpu)

This condition can occur 2 times in refresh cycle, during T3 low and during T4 low. During T4 low is sure, but could be during T3 low depending on cpu timings. So not a 100% stable condition in my eyes. And it's not clock based, its simply enabled as long as condition met.

Anyway the compatibility between ZX81 and ZX80 does not manifest that ULA logic is really 100% identical.
And I think the condition /MREQ=0 and falling edge of T4 is more safe than the conditions used for the ZX80.
But I will maybe measure this out - as nobody did before I think.

[PokeMon]

Yes - you could assume that it is loaded parallel into a shift register and bit 7 is wired to video out immediately.
Could be also wired to an additional flipflop which creates the delay of 1 pixel / half clock period.

You can safely assume that last option is not the case. Why? Simple: it would require an additional flip-flop.

I know, this sounds like a BS reason, and 'logic is cheap'. But remember we're talking a semi-custum IC here that was produced in 100,000's or more. For such IC's, you simply DON'T include anything that isn't absolutely necessary. Period. Semi-custom IC's aren't developed like average software, but more designed & built like a house. And certainly in the 80's, even a single storage bit in a semi-custom IC wasn't as cheap as today. So if an extra storage bit could have been avoided, chances are it was (+ observed behavior matches that).

Well I don't think that the ULA's are produced custom specific than more have been "programmed" custom specific. I am not very familiar with this logic arrays but think you have to choose between different sizes, lets say 100 logic gates, 200 logic gates and so on. I don't think they really produce them with 141 logic gates when needed 141. Anyway a flip flop should be a standard base unit in an ULA, not very complicate to manufacture or program. But as I stated above, it doesn't care if the pixel comes out one half clock earlier or later if it's always the same timepoint. So an additional flip flip is not needed at all.

The ZX81 ULA doesn't have /RFSH signal on any of its pins, so ZX80 logic without changes isn't possible. We can only guess why that is so - perhaps another occurrence of "semi-custom IC, not absolutely necessary, therefore not included".

Thanks for that hint, didn''t take a look on ZX80 schematic before. The reason for no /RFSH at ULA pin could be that all other ULA pins needed.
And they were not willing to pay for a 42 pin DIP case.