Houston, we have an image!

[PokeMon]

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.

I agree with Andy. R28 is a 680 Ohm resistor and a good scope probe used in 10:1 mode has a capacitance of 10-15 pF. That gives a T (tau) of about 10 ns, so this would extend the rom cs with maximum of 10 ns. Anyway it does not extend the rom cs because it takes nearly same amount of time to get low, so rom cs is not extended just temporarily moved for about 10 ns. Nothing worth about talking regarding 3,25 MHz operating frequency.

[Andy Rea]

Nothing worth about talking regarding 3,25 MHz operating frequency.

But 10ns is a lifetime when we are talking setup hold times for the video-data latch in the 2c184e ULA, it makes 1K hi-rez work ! without that fractional delay i get rom-data instead of ram data...

Andy

[PokeMon]

But 10ns is a lifetime when we are talking setup hold times for the video-data latch in the 2c184e ULA, it makes 1K hi-rez work ! without that fractional delay i get rom-data instead of ram data...

Maybe. But then it was a faulty design of the circuits.
I think most of ZX81 devices are working without a scope.

[RetroTechie]

Hi guys!

After my TV broke down it took a while to get replacement (1st candidate broke down within hours didn't even get to hook up my ZX81). And have been busy with other things.

Anyway picked up development a few days ago. First that Rezurrection demo - couldn't get it to work properly, because I stared myself blind on the /ROMCS timing. Until I realized that Hi-Res programs might read data from RAM in the forced NOP cycle. So I adjusted /MREQ signal timing before combining with A14 to obtain /ROMCS and /RAMCS. Et voila: Hi-Res was working.

Something was still off in the vertical sync, this was quickly solved by making a small fix to the sync mixer. From that point on everything worked exactly the same as on my reference ZX81 (which has Sinclair-supplied ULA & internal 16K RAM mod). So you could say I reached 'feature-parity' with original ZX81 ULA. Spent some time on software tests (mostly a variety of Hi-Res demos & games), various optimizations (reduced CPLD resource usage a little), and some easy/useful extra's. Current features:

• Some pins to select white or black border, and inverted display.
• A pin to disable NMI's to the Z80, (sort of?) 'ZX80-mode'.

I plan to leave it this way for the time being, because my primary goal was to have something as much equivalent to original ZX81 as possible. So if I add things like modified memory layout, clock-doubling option etc, that'll be something for later. Don't expect plug-in ULA boards soon, since I don't have the leftover time+money to do a small 'production run'... but I intend to publish this design, when I feel it's tested enough & 'done' - hopefully soon! Software tested (& working perfectly) so far:

• Rock Crush
• Dan's Revenge
• Forty Niner
• Guus Flater
• Rezurrection demo
• a couple of other hi-res demo's
• Rocket Man
• the small test proggies uploaded earlier in this thread
• Z-Xtricator
• some regular ZX81 games

Next stop is some other advanced ZX81 demo's, if I can find .P files for those online (any suggestions )... oh - some screenies (as before, pics don't show it well but white=white & black=black):

Rezurrection demo (set to white-on-black)

Rezurrection.jpg (20.23 KiB) Viewed 8531 times

Z-Xtricator (with some motion blur ;-)

Z-Xtricator.jpg (16.46 KiB) Viewed 8530 times

[sirmorris]

Congrats

[Andy Rea]

Excellent stuff

[RetroTechie]

Time for an update... I've been testing loads, loads, loads of games, demo's and utilities on my ZX81 with CPLD-based ULA. This test-ZX81 has internal 16K (S)RAM expansion, which makes true Hi-Res software work (WRX scheme, basically: RAM outputs data during refresh - should be the same as external RAM pack with that resistor + 2 diodes mod). CPLD or Sinclair ULA makes no difference here. Conclusions so far:

• Some software doesn't work because it needs RAM in 2000-3FFFh and/or other Hi-Res hardware. Without modifications / add-on hardware these wouldn't work on a real ZX81 either.
• Selection of border color + inverted screen works excellent. Even with the 25thanni demo that has text running right up to the edge of the screen (overscan), black-on-white and white-on-black both work perfect.
• EVERYTHING I've thrown at it lately works exactly the same way as on a ZX81 with Sinclair ULA. In the rare cases where something doesn't work, it fails in the same way as with a Sinclair ULA.

Summarized: the CPLD design as I have it now, shows 100% true ULA behavior.

Today I had some troubles due to a static discharge event when disconnecting some equipment. Took me a while to figure out the CMOS Z80 (8 Mhz version) went from 100% to 99% functional, not enough to throw away but enough to replace. I put in a Nec Z80 to continue testing with a good old NMOS part. To do:

• Check if SAVEing programs to tape actually works. So far I didn't bother to check 'cause I never do that anyway these days. Vsync-based sound does work but very weak (low volume).
• Finish testing with some goodies I found on the 'net recently.
• Re-wire the CPLD -> ULA socket connection on my test-ZX81, to make things more neat / reliable / fit in case. This will involve a change of pinout & thus another rebuild of the CPLD configuration.
• Write things up & put on my website.

[sirmorris]

You should be very proud

Can we have some pictures of the board as it is now?

C

[Paul]

Yes, I agree completely:
You definitely should be proud of your achievment AND a picture or two would really be great.

Congratulations
Paul

[PokeMon]

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

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

Does anyone has a full scope picture during video execution ?
I heard about stretched /ROMCS.
Could anybode explain more in detail ?

Have problems when enabling my RAM during refresh period.
I don't know exactly whats happening but there is some disturbance between RAM and ROM when using /RFSH to enable the RAM for read during refresh period.
I think this couldn't happen because during refresh there should be I+R registers on address bus so RAM could not be selected during normal video execution.
It's only /CS low when A14 or A15 high and MREQ low.

But it is, when enabling /RD with either /RD or /RFSH have big trouble unstable and uncontrolled behaviour.
Sometimes "K" appears, sometimes software crashes when pressing any key.
One time could load a HIRES graphic which was shown.
But most time not working.

When I enable /RD only with /RD there is no problem at all.
So what's going on at the ROM and why is my RAM selected during refresh even in normal video execution with I register pointing to $1E ?