ZX81 ULA-in-a-CPLD

[commie]

PokeMon,

I love your avatar, it makes me feel like life is in a cartoon and why should it not be with backup, that said, I took heed of your post and went for the hsync generator, starting at 200 counts and ending somewhere around 207 one step at a time. This cleared the zig zag on the top right hand corner of the screen and almost cleared the phasing error on the inverted 'K' but for one scan line out. I will attempt further experimentation tomorrow.

I just want to make it clear about this whole cpld thing, I found Retrotechie's design 3 years ago, I happen to be reading this thread from the begining and found out Retrotechies compiler uses schematic entry, mine uses digital/boolean equations only so I went from schematic to equations.I think equations are better because the end user has the option to make fine adjustments(tweeking).

[PokeMon]

These experimentation boards and lots of cables are very sensitive when touched and there is a GND problem often as well but as it works it is okay. So about the correct scanline counter reset this thread form Grant Searle (zx80nut) may be helpful for you to eliminate the last problem.
Good luck !

http://sinclairzxworld.com/viewtopic.ph ... t=ULA+ZX81

[RetroTechie]

Thx for those screenshots, very informative!

So one of the main problems for the corrupt cursor is that the scanline counter is not reset correctly.
There is a mismatch of 4 lines.

Agreed. Scanline counter does seem to count through 0-7, with a single increase/scanline. So that looks good.

Maybe you picked up reset for the scanline counter in the wrong place? Other thing I could imagine is that output bit 2 of the scanline counter is inverted ( -> reset, and output counts are then 4,5,6,7,0,1,2,3). Perhaps you used a few separate flip-flops rather than a counter, and by mistake wired bit 2 count to a flip-flop /Q output rather than regular Q? Or used a different type output buffer for A2 line vs. A0/A1 lines? Or a different enable signal for these output buffers?

The other point is, that the line length is not set correctly resp. is too short. You can see that when the picture ends (after the last cursor line) that there is probably 1 pixel too less so that end of line moves step for step in the visible picture. This length is normally 207 clock cycles long (308ns clock * 207=63.7us) while the horizontal syncs are shorter than 64us (if present at all during NMI time). The horizontal sync is created in software during picture display with the HALT instruction (NEWLINE) at the end of a scanline. It can and should also be present when NMI is switched on. So there is a mismatch.

Yes, looks like line length is varying in that part of the screen... Not something that would happen with correct working ULA & original ROM.

I'd still be interested in the exact logic you're using in certain parts. Especially the part from your design which corresponds to the area circled below: (beside the exact contents of your hsync generator)

ZX81_line_counter_and_sync_logic.png

(18.76 KiB) Downloaded 444 times

Note that AND gate (with one inverted input) that produces "start_vsync" in above picture. Tbh I forgot what exactly it does or why (if?) it's needed, but I suspect I didn't put it in there by mistake. Maybe something went wrong with inclusion / input or output logic levels of that gate?

Also note that the design elements pictured above, have some properties that may not be immediately obvious. For example some type flip-flops are reset whenever CLR input is active (asynchronous reset), whereas other types are reset only when CLR input is active during an input clock edge (synchronous reset). Similar story for counters. A slip-up in this context should be very easy to make when porting a design between different vendors' software...

Upon synthesis, your CPLD design software should generate a file which contains the exact logic equations as determined by the software. Analog to "Fitter report.txt" in my project archive. Could you post that? (preferably as attachment rather than copy & paste in a post ).

[PokeMon]

Note that AND gate (with one inverted input) that produces "start_vsync" in above picture. Tbh I forgot what exactly it does or why (if?) it's needed, but I suspect I didn't put it in there by mistake. Maybe something went wrong with inclusion / input or output logic levels of that gate?

It is needed because a vsync starts with the first keyboard read but would also be generated if keyboard is read during nmi phase form BASIC and/or user program. This would result in screen distortions in the visible region above and below the main picture.

About the reset of the scanline counter - I didn't check your approach using the hsync to clock and vsync to reset. I did use the INTACK signal (M1/IORQ) to clock the scanline counter which gave different results for FAST mode and SLOW mode (counter offset of 1) and I used a delayed clock enable. Maybe your approach is easier.

[commie]

After much head scratching across the entire weekend and today, I think I have reached my objective.I had to include another d-type flip flop to Retrotechie's design around the line counter reset.










For some reason(and there are quite a few), it still doesn't load commercial software. However, the real reason I wanted a functional Zeddy is to do calculations.

Retrotechie, your ringed schematic is identical to mine, I cross checked your diagram with Grants zx81 slow mode adapter and your circuit is completely equivalent. I have made amendments around line counter reset and added gates and another f/f.

Okay, for now
Commie

[commie]

Hi All,

More good news, I've just loaded my first commercial game CHESS and it is working.

Retrotechie, about that AND gate with the inverted input?, PokeMon is right, what happens is on the plot screen you get flickerin on the display so you need it.

So heres my line up, total chip count =7 and we have 8kbyte either end of normal 16kbyte of ram.So, now I must concentrate on how I'm gonna build this thing on a pcb.

Cheers all
Commie

[RetroTechie]

Seems like you've still got some off-by-1 error to fix (or something like that). At least that K cursor doesn't look exactly how it's supposed to look.

Anyway great work & progress there, Commie. Congratulations on bringing your 'baby' to life!

It is needed because a vsync starts with the first keyboard read but would also be generated if keyboard is read during nmi phase form BASIC and/or user program.

Ah yes, that makes sense.

[PokeMon]

Yes - about the cursor, I have seen this, too. I think it is half a pixel moved to the right and I assume this is a clock polarity mismatch (falling/rising edge) of the video clock (6.5 MHz).

[commie]

Hi Fella's,

Wow!, I didn't notice the cursor shifted to the right but it is, I did notice that on the chess game the pieces were slightly unsymmetrical anyhow it just so happened it was an easy fix. Thanks for bringing it to my attention.

In between there was another problem which cropped up, I was bringing out the entire video signal through one pin(digitally), funny enough when running ordinary basic/text etc it was perfect nice and crisp, then when I started loading games, the picture was positioned 1/4 way down and wrapped around. This was only occurring with games. At this stage, I knew that the syncs and video data need separating and recombining with an analogue circuit which fixed the problem.This is what my video looks like now...



And here are the left shifted cursor fixed.Notice the loss of clarity, this because of analogue video circuitry.Im talking shit, it's because I forgot to adjust the monitors sharpness control. sorry



And here's a game I loaded called scramble...






So it looks like I now have a zx81 clone.

Cheers
Commie

[commie]

I assume this is a clock polarity mismatch (falling/rising edge) of the video clock (6.5 MHz).

Correct.