PokeMon wrote: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 ?
As for the WHY: how would anyone know? (for sure, that is). A "why" is not something you can observe. Perhaps even original designer(s) forgot why they did things the way they did it. IMHO that's a bit like arguing about why bananas are yellow... one can figure out
what happens,
how it happens, but the
why is just speculation (and will likely remain so).
And why and for what is /ROMCS needed during refresh cycle when not outputting video data ?
It isn't. Outside DFILE execution, data that the ROM (or even RAM for that matter) outputs during refresh, isn't read by anything so it goes nowhere.
If it's handled in a different way they could even suppress it.
True. Oh wait, as far as we know that's exactly what happens in a ZX81 (as stated somewhere in the beginning of this thread).
You only assume that the discrete logic of the ZX80 has been packed into the ULA without any modifications.
True (if one ignores differences between ZX80 and ZX81 logic). However: that particular assumption is
very strongly supported by observed behavior. Yes, it's still an assumption (and will remain so until someone decaps a ZX81 ULA and re-creates the logic by following silicon traces). It's also a case of "all evidence points in the same direction". In that way, current understanding of the ZX81 ULA's function is much like a scientific theory: it can't, and won't ever be proven as 100% certain. But you can keep collecting bits of evidence supporting or undermining that theory, and update / refine it as you go. As long as there's much in support & little or nothing to disprove it, accept as "that's how things are". When there's something that clearly disproves the theory: show it.
But there are modifications, not just NMI. For example (..)
Ehm... yes. A ZX81 is not a ZX80, and the logic inside a ZX81 is not (100%) the same as the logic inside a ZX80. We already knew that.
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.

That would be my guess. IC pins are
extremely expensive (even more than custom logic).
Okay - correct it now. The schematic has in some way a crazy design. (..) But still not convinced that this is exactly done in ULA of the ZX81.
In a way, the ZX80 works more 'analog' in some places, where plain flip-flop(s) or logic gates will have been used in the ZX81 ULA (at least very likely, as RC delays don't lend themselves well for integration in a custom IC). But in the end, all digital logic is analog too. So the only thing that
really matters is the net effect. As long as we don't know
exacly what's inside a ULA, the best you can get is not "something that works the same as a ULA", but "something that shows similar external behavior", or "something whose behavior produces the same net result". A 'model' that
represents ZX81 ULA function.
Andy Rea wrote:the best way of getting to know the exact in's and outs of the ULA video generation is to build a ula yourself
Well it's a very good way. Personally I'd prefer the "decap & follow silicon traces" method. The decap is doable, but I'd be totally lost at the "follow silicon traces" part...

(I have a microscope, but that's no use if you don't know what you're looking at - bipolar transistor, FET, resistor, via, supply connection, ..., or what -for example- a NOR gate looks like in silicon).
by taking the parrallel approach that retrotechie took you can see things work side by side. and can easily compare signals.
Unfortunately, not quite. Signal transitions will relate to clock edges somehow. Those clock edges are generated inside the ULA by an oscillator, which is inherently an analog circuit. Externally it's possible to observe signals changing as a result of those
internal clock transitions, but not
exactly when those internal clock transitions occur.
Single-stepping the ULA's clock might fix that. Unfortunately I didn't manage that since the ULA clock pin is not a simple logic input, but a pin that's designed to tie into a ceramic resonator circuit. And
if single-stepping the ULA's clock were possible, you'd be observing static behavior (and thus ignoring short delays / dynamic behavior as in full speed operation). So you can do a lot, but ultimately you're still stuck with the "black box" problem.
