Hello Mahjongg and welcome to the Forum.
So I guess my message reached you.
@Andy and Retrotechie
Here he is! Please help!
Kind regards
Paul
ZX81+35 Clone
Re: ZX81 Clone
In theory, there is no difference between theory and practice. But, in practice, there is.
-
RetroTechie
- Posts: 379
- Joined: Tue Nov 01, 2011 12:16 am
- Location: Hengelo, NL
- Contact:
Re: ZX81 Clone
Indeed, welcome to this forum, mahjongg! 
) most accurate representations of the ZX81's ULA function. Fairly easy to read/understand, too. For that reason I regard it as a good reference implementation.
As for front porch / back porch: front porch isn't really needed, and a ZX81 doesn't generate it afaik. Back porch is needed, the ..210 version ULA generates it, older ULA versions don't. Back porch = the period at black level that follows a sync pulse. Duration isn't critical, what matters is that it's there.
That's correct, in case you mean the horizontal sync generator.mahjongg wrote:If I understand it correctly the frame counter should not be reset/synchronised by the VSYNC signal, but by the interrupt acknowledgment (INTACK) signal which is /M1 AND /IORQ, meaning I need a single NOR port to generate it.
Afaik the length of a full (50/60 Hz) frame only depends on the total # of screen lines that the display routines generate before starting a new frame. A (software-generated) vertical sync basically masks horizontal sync pulses while it's active. But even then, the rate at which those hsync pulses arrive, stays constant. This is a necessary condition for monitors to stay locked to the sync signal(s).I'm willing to add the NOR, but I'm not convinced its a good idea to do so, it will influence the timing of the generated video signal by removing the number of cycles taken up by the VSYNC signal, because compared to the VSYNC signal INTACK is very short. In fact the current timing means that the total cycles used for a frame is the number of cycles of the frame counter PLUS the length of the VSYNC signal.
You may want to check out my CPLD-based ULA. I developed it running side-by-side with a real ZX81 ULA. And some details were hashed out / confirmed by other ZX80/ZX81 experts on this forum (like Grant Searle aka zx80nut) in various threads here. Long story short: it's probably one of the (if not the-I have to carefully study this again, by reading the ZX81 source code disassembled book to see what is actually expected that the ULA does.
) most accurate representations of the ZX81's ULA function. Fairly easy to read/understand, too. For that reason I regard it as a good reference implementation.There exist several ZX81 clones that work fine, run ZX81 software just fine, but still aren't 100% compatible timing-wise. In the end, software is what counts. If you can find software that executes slightly different than on a real ZX81, then there's still improvements to the logic possible. If you can't find any difference(s) no matter how small or no matter what software you throw at it, then you're good. The latter holds for my CPLD-based ULA...Also, the "VSYNC holds the frame counter" idea is not invented by me, at least two different other ZX81 clones, and a ULA remake use the exact same logic.
As for front porch / back porch: front porch isn't really needed, and a ZX81 doesn't generate it afaik. Back porch is needed, the ..210 version ULA generates it, older ULA versions don't. Back porch = the period at black level that follows a sync pulse. Duration isn't critical, what matters is that it's there.
Re: ZX81 Clone
Welcome mahjong, great to see you on our forum, what myself and tetrotechie discovered and then later verified by Grant searle is as far as we can tell correct behaviour of the zx81 ULA, Grant did a 10 point overview I'll try to find the link later, there is also a schematic for a "correct" hsyncs counter. Whilst a front and back porch is desirable in reality only the hsync and back porch are nessary to produce an acceptable image.
If you understand verilog I'd be happy to send you the code for the ULA replacement i made with a cpld, tetrotechie also did a cpld version i believe ( findnlink latter) that there are schematics for that on the web also.
And yes for a long time it was believed that hsync counter was reset with vsycn, indeed some of my early clones and the TTL ULA that a made used just that but there was always 1 thing that puzzled me, when loading from tape with no signal applied a genuine Zx81 would produce a slanting pattern of alternate black and white bars, but a vsync reset hsync counter would produce 2 neat vertical bars a clear sign that something was not quite right. It took me a while a a few experiments to track down what the difference was.
So once that you get the reset in place then you just rejig the front, hsync,back porch tomeing to suit
Regards
Andy
If you understand verilog I'd be happy to send you the code for the ULA replacement i made with a cpld, tetrotechie also did a cpld version i believe ( findnlink latter) that there are schematics for that on the web also.
And yes for a long time it was believed that hsync counter was reset with vsycn, indeed some of my early clones and the TTL ULA that a made used just that but there was always 1 thing that puzzled me, when loading from tape with no signal applied a genuine Zx81 would produce a slanting pattern of alternate black and white bars, but a vsync reset hsync counter would produce 2 neat vertical bars a clear sign that something was not quite right. It took me a while a a few experiments to track down what the difference was.
So once that you get the reset in place then you just rejig the front, hsync,back porch tomeing to suit
Regards
Andy
what's that Smell.... smells like fresh flux and solder fumes...
Re: ZX81 Clone
Hi Mahjongg,
didn't exactly study your schematics but front porch has nothing to do with vsync. Front porch and back porch are periods in the horizontal line (with 207 clock cycles length) where the video signal is not present (=black). The front porch is never needed on modern TVs - so I would forget about adding this. The back porch is needed to get the black level of the video signal correct and for a good brightness/contrast.
You may take a look at the timings here:
http://martin.hinner.info/vga/pal.html
By the way - the even/odd control isn't necessary either because the contents of odd and even frames is identical in the ZX81 video signal.
didn't exactly study your schematics but front porch has nothing to do with vsync. Front porch and back porch are periods in the horizontal line (with 207 clock cycles length) where the video signal is not present (=black). The front porch is never needed on modern TVs - so I would forget about adding this. The back porch is needed to get the black level of the video signal correct and for a good brightness/contrast.
You may take a look at the timings here:
http://martin.hinner.info/vga/pal.html
By the way - the even/odd control isn't necessary either because the contents of odd and even frames is identical in the ZX81 video signal.
Re: ZX81 Clone
Okay, I see I made a few terminology mistakes, when I said "front porch" I obviously meant "back porch", I often make that mistake, because in my "vision" the back porch is in front of the video, like a "porch" is in front of the house. So yes I do in fact meant the back porch, used by the VDU as a reference for the black level. I'm aware that early ZX81 (ULA's) didn't create one, but later versions did. Without it you often get a picture without any contrast when using it with a new TV. My solution to create a back porch signal was to clamp the signal to "black" during the first 16 cycles of the cycle counter. And yes I agree "frame counter" is also the wrong term, as it counts for a single video line, not a full frame.
Sorry for this, I'm not yet used to talk with other people about this subject, so I make some silly mistakes.
I will further study the exact timing that a ZX81 will use to create the video, and whether my back porch logic will do what I expect it to do, and will not overrule the vertical sync pulse, or be itself masked by the vertical sync pulse. I see I have still much to study.
And yes my aim is to create as perfect a ZX81 clone as possible.
I did dabble a bit with FPGA's, and learned a bit of VHDL, but not verilog, but I'm sure I will understand it when I see it.
The reason my design is not FPGA based is that I think using an FPGA is a practical problem for people who want to build my ZX81 clone, (the necessity to program it will be a problem for many) and also because a pure logic based design might be a bit more future proof, when someone wants to build one in say 20 years time the exact same FPGA might not be available, but logic might.
Sorry for this, I'm not yet used to talk with other people about this subject, so I make some silly mistakes.
I will further study the exact timing that a ZX81 will use to create the video, and whether my back porch logic will do what I expect it to do, and will not overrule the vertical sync pulse, or be itself masked by the vertical sync pulse. I see I have still much to study.
And yes my aim is to create as perfect a ZX81 clone as possible.
I did dabble a bit with FPGA's, and learned a bit of VHDL, but not verilog, but I'm sure I will understand it when I see it.
The reason my design is not FPGA based is that I think using an FPGA is a practical problem for people who want to build my ZX81 clone, (the necessity to program it will be a problem for many) and also because a pure logic based design might be a bit more future proof, when someone wants to build one in say 20 years time the exact same FPGA might not be available, but logic might.
Last edited by mahjongg on Wed Nov 25, 2015 7:46 pm, edited 1 time in total.
Re: ZX81 Clone
the link for Grant's page, its about converting a z80 to a zx81 by adding the NMI generator which of course contains the hsync counter, its all there.
http://searle.hostei.com/grant/zx80/zx80nmi.html
and the page for Retro Techie's cpld
http://bitcycle.org/retro/zx81/ula/
drop me a PM if you would like the verilog code for my cpld design
regards Abdy
http://searle.hostei.com/grant/zx80/zx80nmi.html
and the page for Retro Techie's cpld
http://bitcycle.org/retro/zx81/ula/
drop me a PM if you would like the verilog code for my cpld design
regards Abdy
what's that Smell.... smells like fresh flux and solder fumes...
Re: ZX81 Clone
thanks, I actually already had both information sources in my library, and used them, but not for the hsync counter logic, which produced a hsync at the last 16 cycles of the 207 cycle counter, and a front porch during the first 16 counts, that is (originally) directly after the VSYNC pulse ended, or so I thought.
This is however completely different from retro techies CPLD design, which generates a hsync pulse during cycles 16 to 32, and a porch signal in cycles 32-46.
At the time I could not figure out why he did that, and my setup seemed more correct, and so for the Hsync pulse generation my circuit is identical to rodney knaaps third version, which also uses the last cycles of the counter for sync, except that I added porch logic to it, which may have been done wrong, seeing retro techies CPLD logic again. Now I don't know anymore.
perhaps its better to accept my solution is wrong, and to adapt retro techies solution?
but how can it be that both using the last sixteen counts, OR counts 16 to 32 for hsync works? And which version is factually correct? Or am I missing something? It seems that the hsync and porch signals are generated at completely different times in regards to the cycle counter count.
when, after the start of the 207 cycle counter (when count resets to zero) does the ZX81 logic start to draw characters?
Also, for a different matter, what I did is to combine Sync and Vsync using an XOR, instead of a simple OR, my reasoning being that normally during the vertical sync pulse horizontal sync pulses are not masked, but continue as inverted pulses (that is "gaps" in the longer vertical sync pulse). I don't think it matters though, and the ULA probably didn't use an XOR either.
I dabbled myself with a Lattice FPGA at one time, and also used schematic input, not a hardware description language. So no, I'm not fluent in HDL, neither VHDL nor Verilog, but I did read some VHDL manuals to get acquainted with FPGA logic before deciding to go with schematic entry, so I have a basic understanding of VHDL.
This is however completely different from retro techies CPLD design, which generates a hsync pulse during cycles 16 to 32, and a porch signal in cycles 32-46.
At the time I could not figure out why he did that, and my setup seemed more correct, and so for the Hsync pulse generation my circuit is identical to rodney knaaps third version, which also uses the last cycles of the counter for sync, except that I added porch logic to it, which may have been done wrong, seeing retro techies CPLD logic again. Now I don't know anymore.
perhaps its better to accept my solution is wrong, and to adapt retro techies solution?
but how can it be that both using the last sixteen counts, OR counts 16 to 32 for hsync works? And which version is factually correct? Or am I missing something? It seems that the hsync and porch signals are generated at completely different times in regards to the cycle counter count.
when, after the start of the 207 cycle counter (when count resets to zero) does the ZX81 logic start to draw characters?
Also, for a different matter, what I did is to combine Sync and Vsync using an XOR, instead of a simple OR, my reasoning being that normally during the vertical sync pulse horizontal sync pulses are not masked, but continue as inverted pulses (that is "gaps" in the longer vertical sync pulse). I don't think it matters though, and the ULA probably didn't use an XOR either.
I dabbled myself with a Lattice FPGA at one time, and also used schematic input, not a hardware description language. So no, I'm not fluent in HDL, neither VHDL nor Verilog, but I did read some VHDL manuals to get acquainted with FPGA logic before deciding to go with schematic entry, so I have a basic understanding of VHDL.
Re: ZX81 Clone
it doesn't matter where in the actual count ( by whatever means you are counting clock cycles ) that you use for hsync and back porch
what is important is that the hsync starts exactly 16 clock cycles after the int-ack ends
i had one incarnation that reset the count to 191 and rolled round from 206 to zero, so using counts 0 to 15 for hsync...
it is also quite irrelevant as to when character generation starts as many custom display drivers exist each with unique characteristics
i also acknowledge their are errors in my TTL ULA design from many years ago, however i don't have access to that account anymore and am surprised that the page is even still up since as the account was closed nearly 3 years ago! my later GAL design improved upon that TTL design but was by no means perfect, it wasn't until i tinkered with cpld's around april / may 2011 that i discovered ( it may well have been discovered before ) but i have yet to find an earlier reference the hsync counter was reset by the int-ack
all fun stuff
regards Andy
what is important is that the hsync starts exactly 16 clock cycles after the int-ack ends
i had one incarnation that reset the count to 191 and rolled round from 206 to zero, so using counts 0 to 15 for hsync...
it is also quite irrelevant as to when character generation starts as many custom display drivers exist each with unique characteristics
i also acknowledge their are errors in my TTL ULA design from many years ago, however i don't have access to that account anymore and am surprised that the page is even still up since as the account was closed nearly 3 years ago! my later GAL design improved upon that TTL design but was by no means perfect, it wasn't until i tinkered with cpld's around april / may 2011 that i discovered ( it may well have been discovered before ) but i have yet to find an earlier reference the hsync counter was reset by the int-ack
all fun stuff
regards Andy
what's that Smell.... smells like fresh flux and solder fumes...
Re: ZX81 Clone
well the counter is (normally) reset to zero by the interrupt acknowledge (INTACK) signal so yes you do know "how to count the cycles", as you have to count relative to when the INTACK occurred. so on a system that has a counter that is reset by the INTACK, then when you say the "hsync starts exactly 16 clock cycles after the int-ack ends", (because the INTACK happens directly after end of the video generation for the previous line) that means it should happen on counts 16 to 31, and as the back porch signal should come immediately after that it does mean it should be in cycles 32 onward, but should stop in time so that character generation can commence, if the porch signal last too long it will block character generation, typically for PAL the porch has the same duration as the sync pulse, maybe a little bit longer, that means that your assessment "it is also quite irrelevant as to when character generation starts as many custom display drivers exist each with unique characteristics" isn't factually true, its not irrelevant at all, as character generation should happen after the back porch ends, so not before 46 cycles after the (end of) the INTACK. The INTACK is actually used to synchronize the otherwise free running counter with the software that generates the character generation, otherwise, without that synchronization, each line of a character would end up on a different horizontal location, careful study of the ZX81 code should reveal exactly when start of video generation code would happen, relative to the INTACK time, but what you tell me seems to mean it must be very shortly after cycle 46 (that is for the standard video driver, other drivers may deviate slightly, and make a wider picture. It all means the design of retro techie is correct, and mine isn't! I have to redesign so that the Hsync plus is generated during the count 16 to 32, and the porch signal lasts 16 or (preferably) somewhat less cycles after the end of the sync pulse. I'm guessing that with characters well within the boarder of the screen, it will be later than after cycle 46, so a 16 cycle porch signal should be okay.
I think i'm starting to get it, and I know what to do....
I think i'm starting to get it, and I know what to do....
-
RetroTechie
- Posts: 379
- Joined: Tue Nov 01, 2011 12:16 am
- Location: Hengelo, NL
- Contact:
Re: ZX81 Clone
Picture from that application note refers to NTSC timing, not PAL. They are similar though, for PAL the back porch is supposed to be a bit longer but as said this isn't critical.
For both PAL and NTSC, the "sync tip" is specced as 4.7 +/- 0.1 usec, @ 3.25 MHz this is 15.275 clock cycles. Again this isn't too critical (I've read of some ucontroller projects using 4 usec hsyncs), what IS important is that they arrive at a constant rate - that is, with low "jitter". Otherwise the image will go wobbly like a RAM pack on LSD...
Found a good overview here: Monochrome composite video
"Active display" is 256 pixels width (@ 6.5 MHz) = 128 cycles = 39.4 usec.
Difference = 79 cycles. Minus say, 32 cycles for sync tip + back porch leaves 47 cycles (~94 pixels width), divided between left and right that is ~47 pixels worth of white space in each border. How much of that is "invisible re-trace time", or actual visible border on your screen? (especially after all the signal processing & scaling a typical LCD screen will do).
My point being: a few clock cycles more or less around the hsync REALLY doesn't matter much. Andy is correct in saying so, especially as modified display drivers, hi-res demo's etc come into play. At worst, you'd see a small blacked out vertical strip on the extreme left of the screen. And even then, quite a few screens will have options to adjust screen size or position to make that go away.
There's really just a few things to worry about:
I suspect the XOR method is more 'correct' as it relates to existing display standards. How display equipment responds, will heavily depend from model to model. IIRC, I tried both methods in my CPLD-based ULA, one didn't work quite right, and the other a) worked with TV's I had on hand, and b) produced same effect as a real ULA. So therefore I suspect a ZX81 ULA uses the NOR method as well (but am not 100% sure). Found a good discussion on this topic here:
http://what-when-how.com/display-interf ... es-part-2/
One thing I have learned from this ZX81 ULA project: composite video isn't all that simple (especially color!), and the simplifications used in a ZX81 (monochrome, no even/odd frames) are very welcome.
For color video, I'd go analog RGB (SCART), or VGA, or even DVI/HDMI before ever considering doing color composite video.
Never mind Y/C - kind of the same thing.
For both PAL and NTSC, the "sync tip" is specced as 4.7 +/- 0.1 usec, @ 3.25 MHz this is 15.275 clock cycles. Again this isn't too critical (I've read of some ucontroller projects using 4 usec hsyncs), what IS important is that they arrive at a constant rate - that is, with low "jitter". Otherwise the image will go wobbly like a RAM pack on LSD...
Found a good overview here: Monochrome composite video
I suspect that # of 16 clock cycles after int-ack isn't too critical either. But with a different #, the exact length of frames and/or screen lines (and thus the frame rate) may be affected. Probably not something you'd notice right away, but measurable. But... when decoding a set of counts, that 16-cycle delay is easy to implement so why not do it?Andy Rea wrote:(..) what is important is that the hsync starts exactly 16 clock cycles after the int-ack ends
One screen line is 207 clock cycles = 63.7 usec.mahjongg wrote:if the porch signal last too long it will block character generation, typically for PAL the porch has the same duration as the sync pulse, maybe a little bit longer, that means that your assessment "it is also quite irrelevant as to when character generation starts as many custom display drivers exist each with unique characteristics" isn't factually true, its not irrelevant at all, as character generation should happen after the back porch ends, so not before 46 cycles after the (end of) the INTACK.
"Active display" is 256 pixels width (@ 6.5 MHz) = 128 cycles = 39.4 usec.
Difference = 79 cycles. Minus say, 32 cycles for sync tip + back porch leaves 47 cycles (~94 pixels width), divided between left and right that is ~47 pixels worth of white space in each border. How much of that is "invisible re-trace time", or actual visible border on your screen? (especially after all the signal processing & scaling a typical LCD screen will do).
My point being: a few clock cycles more or less around the hsync REALLY doesn't matter much. Andy is correct in saying so, especially as modified display drivers, hi-res demo's etc come into play. At worst, you'd see a small blacked out vertical strip on the extreme left of the screen. And even then, quite a few screens will have options to adjust screen size or position to make that go away.
There's really just a few things to worry about:
- Make signal timing closest to what display equipment expects, to minimize the chance of problems. Preferably such that timing matches an original ZX81. But perhaps not necessarily so: some timings may be adjusted without affecting overall duration (or effect on software!).
- How to implement things in a way that's both simple and understandable.
-
TEST on real-life equipment. Preferably many different types & models.
Yep, I noticed that.Also, for a different matter, what I did is to combine Sync and Vsync using an XOR, instead of a simple OR, my reasoning being that normally during the vertical sync pulse horizontal sync pulses are not masked, but continue as inverted pulses (that is "gaps" in the longer vertical sync pulse). I don't think it matters though, and the ULA probably didn't use an XOR either.
I suspect the XOR method is more 'correct' as it relates to existing display standards. How display equipment responds, will heavily depend from model to model. IIRC, I tried both methods in my CPLD-based ULA, one didn't work quite right, and the other a) worked with TV's I had on hand, and b) produced same effect as a real ULA. So therefore I suspect a ZX81 ULA uses the NOR method as well (but am not 100% sure). Found a good discussion on this topic here:
http://what-when-how.com/display-interf ... es-part-2/
One thing I have learned from this ZX81 ULA project: composite video isn't all that simple (especially color!), and the simplifications used in a ZX81 (monochrome, no even/odd frames) are very welcome.
For color video, I'd go analog RGB (SCART), or VGA, or even DVI/HDMI before ever considering doing color composite video.
Never mind Y/C - kind of the same thing.