Hi PokeMon,
Have you checked documentation with my ZX81 ULA project? There's a similar 'scope' picture in it which may explain a lot:
- Signal_timing.png (4.09 KiB) Viewed 3669 times
What version ULA do you have? What are you using as RAM (internal or RAM pack), and what's the logic for control signals? Do you experience same problems with regular ZX81 display, pseudo hi-res and true hi-res software?
First thing to realize is there are 2 stages in DFILE execution: 1) The instruction fetch (where Z80 gets fed a NOP), and 2) The refresh cycle that follows (where either ROM or RAM outputs the graphic data).
The instruction fetch is basically a regular memory read, where A14/A15 determine source of the data. But in a refresh cycle, I register is on high bits of the address bus. That tidbit of info is
HARD to find
in official docs, but here it is: quoting the MK3880 Technical Manual, /RFSH pin description:
A7 is logic zero and the upper 8 bits of the Address Bus contains the I Register.
First part of that statement is probably not true; R register is on A0-A7, bit 7 of that is
usually 0 (=reset state, and isn't included in refresh counter), but programmer can set it using LD R,A instruction, and that bit
is preserved (as expected).
Second half of above quote is true AFAIK.
PokeMon wrote:I heard about stretched /ROMCS.
Could anybode explain more in detail ?
In normal ROM reads, /ROMCS follows /MREQ timing. In DFILE execution (refresh cycle), /ROMCS activates when /MREQ goes active, but stays active
after /MREQ returns to inactive (see dotted part in above picture). As far as I (or Grant) know, only for forced NOP cycles (DFILE execution), not regular refresh cycles or memory read/writes.
Why? IMHO: simply to accomodate a convenient point in time to clock ULA's video shift register. Read: a point in time which allows you to clock that data directly, in such a way that all pixels get equal 'display time' when shifted out to the screen, and without tricks like an extra 8-bit buffer or 9th bit in between. Which is the exact same reason I'm duplicating that /ROMCS behavior in my ZX81 ULA project.
So it's maybe not important if ROMCS is stretched ?
Purely an implementation issue, not something that "should be done".
As long as net effect is the same, anything goes.
Sometimes "K" appears, sometimes software crashes when pressing any key.
That's an important observation! If the wrong graphic data is fetched by the ULA, it does not affect CPU operation, and you'd see screen corruption but stable running machine. So if you experience crashes, that would suggest something goes wrong during the instruction fetch (and following from that, maybe wrong character code gets clocked into the ULA's character latch, which might explain "K" cursor corruption).
There's a few things to check:
- Regardless of what control signals you input, /ROMCS and /RAMCS should NEVER be active at the same time (only one of them at most). Can you verify that?
- Whether ROM or RAM is source for the hi-res data, isn't relevant for signal timing. Only highest address bits (A14/A15/contents or I register) decide source of the data, DFILE execution or not decides signal timing. So if /ROMCS or /RAMCS gets 'special treatment' in some way, that might be cause of the problem.
If anyone has a better theory: please share! 
