Houston, we have an image!

[sirmorris]

<applause> Well done! An inspiring job!

[RetroTechie]

Things are nicely progressing here! I've changed my hardware setup a bit such that all equipment (keyboard / TV / development PC / programming cable) is connected at all times, this enables much quicker design -> test cycles. Did significant cleanup:

• Got rid of all analog timing-related parts (RC delays). Most events are timed strictly through falling or rising edge of Z80 clock now (and using CPLD's global clocks for those). This should make the design much more robust timing-wise (fewer problems with different speed parts, better overclocking potential etc).
• /ROMCS signal stretched a bit - should match real ZX81 /ROMCS timing.
• USA/UK input needed a pull-up, this was cause of machine running in 60 Hz refresh + increased vertical height I saw.
• Got rid of /RFSH signal as a shortcut, only using signals on ULA socket now.
• Last change in the event timing got rid of trash in the border - solid white now as it should be.

So I'm starting to look at more or less normal ZX81 screen! Still to do:

• Implement invert-character bit (and I'll probably add inputs for "invert screen" + ZX80/ZX81 selection).
• Not quite satisfied yet with the video shift register implementation.
• Lots & lots of software testing... good that tape loading works so well (and screen loading patterns also look more or less 'normal' now).

[Andy Rea]

Things are nicely progressing here! I've changed my hardware setup a bit such that all equipment (keyboard / TV / development PC / programming cable) is connected at all times, this enables much quicker design -> test cycles. Did significant cleanup:

• Got rid of all analog timing-related parts (RC delays). Most events are timed strictly through falling or rising edge of Z80 clock now (and using CPLD's global clocks for those). This should make the design much more robust timing-wise (fewer problems with different speed parts, better overclocking potential etc).
• /ROMCS signal stretched a bit - should match real ZX81 /ROMCS timing.
• USA/UK input needed a pull-up, this was cause of machine running in 60 Hz refresh + increased vertical height I saw.
• Got rid of /RFSH signal as a shortcut, only using signals on ULA socket now.
• Last change in the event timing got rid of trash in the border - solid white now as it should be.

So I'm starting to look at more or less normal ZX81 screen! Still to do:

• Implement invert-character bit (and I'll probably add inputs for "invert screen" + ZX80/ZX81 selection).
• Not quite satisfied yet with the video shift register implementation.
• Lots & lots of software testing... good that tape loading works so well (and screen loading patterns also look more or less 'normal' now).

Excellent progress, i don't understand why your 'stretching' the /ROMCS (my scope shows /romcs switches approx 25ns after /mreq)

And a very well done for eliminating the /rfsh

Regards Andy

[RetroTechie]

Excellent progress, i don't understand why your 'stretching' the /ROMCS (my scope shows /romcs switches approx 25ns after /mreq)

When /MREQ returns high, pattern data isn't yet clocked into video shift register - that's why /ROMCS extends some beyond /MREQ going high (check Grant's scope pix). I'm just mimicking that ZX81's behavior, if nothing else it gives more room for clocking the shift register & some extra access time for the ROM.

Was just trying some of those test programs:

ZXTEST2.P does what it does on a real ZX81.
CLCKFREQ.P shows same number of frames as on a real ZX81 (and screens look okay).
REZ4K.P showed stable screens with same layout as on real ZX81, but graphic data not correct.

And then my TV gave up - just guessing some crazy sync fiddling by Rezzurection demo pushed that 10 years old CRT over the edge...
(fortunately if necessary, replacement can be found nearly for free these days)

[PokeMon]

And then my TV gave up - just guessing some crazy sync fiddling by Rezzurection demo pushed that 10 years old CRT over the edge...

I think modifications in sync signals could be like cardiac arrhythmias for an old TV.

Sorry, maybe not funny for you but I was just "rofling" after I read this message.

[Andy Rea]

Hmmm this ROMCS behaviour is not what i see using a 184 ULA

But i'm sure that it will all work out fine, it does not matter whats 'in the box' as long as the end result is the same

Regards Andy

[PokeMon]

BTW, I am not very happy with extending signals via R/C combinations as you can not easily change frequency or do overclocking.

[RetroTechie]

No analog delays here, as I wrote I did quite some cleanup! /ROMCS is done as follows:

Goes low with /MREQ low and A14 low. But when /MREQ returns high, /ROMCS follows at next low-to-high transition of CPU clock. In a forced NOP cycle, that is end of T4 / start of T1 in next instruction cycle, and @ that same time D0-D7 are clocked into the video shift register. Again this matches real ZX81 timing-wise.

Not sure whether /ROMCS timing is the same for regular instruction fetches / reads from ROM on a real ZX81, but it seems to work fine this way. And AFAICT there's no (chance of) overlap with /RAMCS active periods.

Checked internals of my TV in the meanwhile - looks like a problem in the power supply. Main fuse is okay, when I switch the thing on I can hear a ticking sound (and power LED flashes in same rhythm), but I don't see any sparks or so. Capacitors all look fine, no smelling/burned parts or blackened circuit board anywhere (in fact the things looks pretty good considering it's seen 10 years of heavy use!). I have schematic & a few things left to try, but if it isn't something easy to find/fix, I guess it's end of the line for this trusty old CRT..

[Andy Rea]

This post is preserved so that the 'continuity' of the thread is not broken. however what this post suggests has been proven false as was originally stated in previous posts... (i think i had a blonde moment )

ORINGINAL POST FOLLOWS:

Whilst i don't like to criticize other peoples work, I feel i must point out that what i see on the scope does not entirely match what Grant's work shows. Below is what i observe on an unalterd 1K zeddy fitted with a 2C184E ULA chip. during M1 video cycle.

<EDIT> erroneous image removed </EDIT>

As you can see /ROMCS and /RAMCS appear to be logically tied to /MREQ and A14, as i have found to be the case in every zeddy i have come across (unless some special memory decode is fitted). i believe that the Video-data is captured from the databus on the rising edge of /MREQ during T4 and the video stream is further buffered by a 9th bit in the shift register to eliminate the faint vertical banding between characters, as found on many examples of ZX80 where the newly loaded data IS the live video, this extra bit in the shift register results in the video-data that has just been grabbed not appearing until the start of the next T-cycle.

Regards Andy

[zx80nut]

Hi Andy.
I think all signals seem to match except for ROM CS.

I set the scope triggering to occur mid-line with a fully expanded DFILE. Also, using an LM1881 and some extra circuitry, I was able to eliminate the non-display parts of the screen, and therefore eliminate "normal" program execution statements.

The ROM CS during DFILE execution is extended, and therefore I believe the rom DATA is loaded at the same moment as for the ZX80.
This way, a "9th bit" is not needed, as the data is loaded directly, at the appropriate moment into the o/p shift register. TV out would always be on D0 of the register, so the new char is displayed immediately at the start of T1 and the remaining bits shifted through T1 to T4.

Please can you confirm that you are checking the DFILE execution and not "normal" program execution.
You need a FULLY expanded DFILE to see the operation clearly. With a collapsed DFILE, you are not seeing DFILE execution, as it is hitting the halt statement.

The traces that you show look like normal program operation and not the DFILE operation.
With a collapsed DFILE, the normal execution are the "stronger" traces, as very few DFILE executions would occur.
So, basically, normal program operation is as you see, but the DFILE execution has the ROM CS stretched until the start of the next cycle.

The faint vertical banding on the ZX80 is due to the propogation delay on IC 18 (74LS74) after the 2phi clock signal, so the "data load" is not purely synchronous, and is delayed slightly, so the load is slightly out of sync with the shift clock. Also, the dynamics of the capacitor coupling doesn't help.

If you fill the screen with characters and try again, you will then be able to see two sets of ROM CS traces on your scope, some stretched (DFILE) and some normal.

Regards.

Grant.