Houston, we have an image!

[Andy Rea]

Doh, how stupid of me

Please accept my most humble appologies, you are of course correct and filling the screen made it appear eaxctly like your own observation.

Regards Andy

[zx80nut]

No probs Andy - that is what I saw first of all - and it confused me for some time
Here is a pic that I posted earlier in this thread before I filtered out normal program execution statements:

OscPic1.jpg (51.67 KiB) Viewed 7940 times

I have annotated it here to show the normal prog and stretched DFILE ROM CS.

The scope pic that you see with short ROM CS in the refresh period is during normal prog execution and not the enable during the refresh when executing DFILE.

Regards.

Grant

[RetroTechie]

Ah I see... that would mean /ROMCS is only extended in forced-NOP cycles, and not in regular ROM reads / instruction fetches? If so, I'd consider changing my design accordingly. But perhaps I'll just leave this as it is, as long as there's no overlap with /RAMCS there's no problem, right? Another option would be to move the clock-into-shift-register forward in time. Not sure about pro's & cons of that...

Also I'm clocking data directly into the video shift register - works excellent as long as the timing is correct.

Btw I have only 2C210 version ULA's, no 2C184. And no scope to check. Nor a display for the moment...

[zx80nut]

Hi Retrotechie.
Yes, that's correct. Stretching only occurs during the "NOPed" execution.

Regards.

Grant

[Andy Rea]

Well now i'm really baking my noodle, how the blinkin heck does 1K hi-res work ! it looks to me that during refresh, ramcs is low when mreq is low then you get 1/2 cycle of romcs for the last half of T4....

However thinking about it nearly every hi-res enabled ram expansion also uses refresh signal and rd to enable ram... which ties in nicely with all this romcs strecthing... there is always something new to learn

@retrotechie, my advice leave it as it is, if it works to a satisfactory level... if the overall outcome is the same how much does it really matter if the method is slightly different ?

Regards Andy

[Andy Rea]

Well now i'm really baking my noodle, how the blinkin heck does 1K hi-res work ! it looks to me that during refresh, ramcs is low when mreq is low then you get 1/2 cycle of romcs for the last half of T4....

That will be because it doesn't... not on this zeddy 1K with 2c184e ULA anyway....

Andy

EDIT now i tried Blocky 1K game that does not work either !

[Andy Rea]

Well this gets even stranger ! i swapped the rom for one of the slower variants, and the image was different but not right.

Then i started poking around with the scope and when monitoring ROMCS (rom side of R28) and suddenly 1k hi-rez was working, take the probe away and it goes back to garbage.

Wiwo Dido,the case of Mazeddy's Castle is pretty good, and Blocky is cool, apart from the score at the bottom goes squiffy ???

andy

[RetroTechie]

Then i started poking around with the scope and when monitoring ROMCS (rom side of R28) and suddenly 1k hi-rez was working, take the probe away and it goes back to garbage.

Nothing strange there, Andy: the scope probe will add some capacitance to the signal. In combination with the series resistor (that allows external hardware to disable the ROM), this creates an RC network which has the effect of delaying /ROMCS signal @ the ROM side. Apparently just enough to make work what didn't work before.

So you do by accident what I did earlier as a quick hack - me thinks a 150 pF capacitor was more cost-effective than scope+probe...

[siggi]

So you do by accident what I did earlier as a quick hack - me thinks a 150 pF capacitor was more cost-effective than scope+probe...

I know that problem: my ZX81 web-server boots only, when a home made bus-extender board it plugged to the bus: (the card in the upper left corner):
http://www.zx81.de/bilder/html/IMGP0630.html

But I found it's easier, to have the bus-extender always in the Zeddy, than to check, which of the 64 bus lines would need some more pF

Siggi

[zx80nut]

When I "prod" about with a scope probe, I normally use the x10 setting on the probe, and increase the sensitivity of the scope appropriately.
The x10 setting puts a 9Meg attenuator resistor in series with the probe tip (scopes have a 1Meg input impedance) and drastically reduces the effective capacitance that the probe introduces onto the bus, and reduces the chance of the CPU crashing when pins are touched.

If capacitance allows something to work, then, I'm afraid, something is probably clocking/triggering at the wrong point and is unstable and open to glitches, so the circuit needs to be checked again. Lots of edge-triggering rely on the data latency present on chips before they give up the bus, a typical one being the read of data at the rising edge of a "read" signal, as this is also the o/p control on the chips being read from. The ram/rom supplying data takes a while to release the bus, so this is normally safe. If data is being latched in something external, however, then any propogation delays in the activation logic of the latch could push the trigger point to beyond where the chips supplying the data has released the outputs. Capacitance can delay the chip select signal and cause the data to be active a little bit longer.