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).
Good luck !
http://sinclairzxworld.com/viewtopic.ph ... t=ULA+ZX81
Agreed. Scanline counter does seem to count through 0-7, with a single increase/scanline. So that looks good.PokeMon wrote: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.
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?
Yes, looks like line length is varying in that part of the screen... Not something that would happen with correct working ULA & original ROM.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.
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) 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 ).
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.RetroTechie wrote: 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?
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.
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
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.
Anyway great work & progress there, Commie. Congratulations on bringing your 'baby' to life!
Ah yes, that makes sense.PokeMon wrote: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.
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.