Mixing
Why does the ZX80 not produce a steady display signal?
Clash Royale CLAN TAG#URR8PPP
up vote
12
down vote
favorite
As Tommy pointed out in my question about BASIC tokens on the ZX Spectrum, the ZX80 is a computer which does not produce a signal which is displayed steadily on the TV. It looks to me as if the CRT is losing sync, causing the picture to roll upward.
The similar computers, the ZX81 and the Galaksija do not have this problem as far as I can tell. The Galaksija, though considerable effort was taken to keep parts count low, it at least uses some kind of hardware timer to generate an interrupt which sets the CPU drawing the screen from the top, and since that timer keeps firing, there's no problem keeping the display from rolling like that. And there is plenty of time to scan the keyboard during the vertical or horizontal blanking.
My question is if my diagnosis of the Rolly Screen on the ZX80 is correct and why it was built that way.
zx80
asked Aug 9 at 11:12
Wilson
7,969434100
add a comment |Â
up vote
12
down vote
favorite
As Tommy pointed out in my question about BASIC tokens on the ZX Spectrum, the ZX80 is a computer which does not produce a signal which is displayed steadily on the TV. It looks to me as if the CRT is losing sync, causing the picture to roll upward.
The similar computers, the ZX81 and the Galaksija do not have this problem as far as I can tell. The Galaksija, though considerable effort was taken to keep parts count low, it at least uses some kind of hardware timer to generate an interrupt which sets the CPU drawing the screen from the top, and since that timer keeps firing, there's no problem keeping the display from rolling like that. And there is plenty of time to scan the keyboard during the vertical or horizontal blanking.
My question is if my diagnosis of the Rolly Screen on the ZX80 is correct and why it was built that way.
zx80
asked Aug 9 at 11:12
Wilson
7,969434100
add a comment |Â
up vote
12
down vote
favorite
up vote
12
down vote
favorite
As Tommy pointed out in my question about BASIC tokens on the ZX Spectrum, the ZX80 is a computer which does not produce a signal which is displayed steadily on the TV. It looks to me as if the CRT is losing sync, causing the picture to roll upward.
The similar computers, the ZX81 and the Galaksija do not have this problem as far as I can tell. The Galaksija, though considerable effort was taken to keep parts count low, it at least uses some kind of hardware timer to generate an interrupt which sets the CPU drawing the screen from the top, and since that timer keeps firing, there's no problem keeping the display from rolling like that. And there is plenty of time to scan the keyboard during the vertical or horizontal blanking.
My question is if my diagnosis of the Rolly Screen on the ZX80 is correct and why it was built that way.
zx80
asked Aug 9 at 11:12
Wilson
7,969434100
As Tommy pointed out in my question about BASIC tokens on the ZX Spectrum, the ZX80 is a computer which does not produce a signal which is displayed steadily on the TV. It looks to me as if the CRT is losing sync, causing the picture to roll upward.
The similar computers, the ZX81 and the Galaksija do not have this problem as far as I can tell. The Galaksija, though considerable effort was taken to keep parts count low, it at least uses some kind of hardware timer to generate an interrupt which sets the CPU drawing the screen from the top, and since that timer keeps firing, there's no problem keeping the display from rolling like that. And there is plenty of time to scan the keyboard during the vertical or horizontal blanking.
My question is if my diagnosis of the Rolly Screen on the ZX80 is correct and why it was built that way.
zx80
asked Aug 9 at 11:12
Wilson
7,969434100
asked Aug 9 at 11:12
Wilson
7,969434100
asked Aug 9 at 11:12
Wilson
7,969434100
asked Aug 9 at 11:12
Wilson
7,969434100
7,969434100
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
14
down vote
accepted
It's probably bad form to cite yourself, but I wrote up my understanding of the ZX80 and ZX81 hardware here, scraped together from a few different sources but most notably Wilf Rigter's hardware and software summary.
Your assessment is right. The standard ZX80 ROM loop outputs a screen, checks for keypresses, and repeats. That loop is exactly the length of a frame if no key is pressed. If a key is pressed then additional processing happens, so the start of the next frame is delayed. The TV is then out of sync.
Interrupts are used during display generation to communicate the end of a line. The logic is trivial: during a refresh cycle bit 6 of the refresh address is echoed to the interrupt line. So when bit 6 is 0, an interrupt is signalled.
However:
- the Z80 performs an interrupt if it is being signalled one cycle before the end of an instruction. Therefore an interrupt is communicated only if the final part of an instruction is a refresh cycle; and
- when it is signalled is a function of the rate at which the refresh counter has increased. Which also depends upon the particular instructions being performed.
Therefore the interrupt mechanism doesn't have reliable behaviour during arbitrary code. It can't be used for line counting or any other purpose anywhere other than during the output cycle.
As a result the base ZX80 has no means to keep track of display position outside of its display loop. So it doesn't even try; it just allows the display to lose sync.
Digressions:
There are ZX80 games which do not roll through very careful cycle counting of every possible execution path.
The interrupt logic isn't so much for keeping track of position, it's more to allow the compact display to work — a ZX80 will put a HALT at the end of any line that is less than 32 bytes wide, and not use any storage for the rest of the line. The Z80 will HALT when it gets there and then stay where it is until the interrupt is signalled. So rather than the display taking a fixed 32*24 = 768 bytes on a 1kb machine, it takes only 32 + (number of visible characters).
The ZX81 remedies the situation with a horizontal counter that generates both NMI and WAIT. NMI is edge triggered, not level, so you don't need to worry about where the Z80 is in its stream when you signal it. Using WAIT as well overcomes the problem of phase: it's essentially true to say that there's a maximum amount of time it can take for an NMI to begin processing, and the NMI response honours WAIT so you can stretch the NMI response to a fixed time relative to the horizontal scan.
edited Aug 11 at 12:28
Anthon
1032
answered Aug 9 at 13:43
Tommy
12k13261
2
I wonder if a 555 or 7555 could have been used for vertical sync timing? Drop horizontal sync during the lower overscan interval, do a tiny bit of computation, wait for the timer, and then start horizontal sync for a few lines, then vertical sync, and then back to horizontal sync. The image wouldn't be perfectly stable, but would be a lot less bouncy than starting frames at "random" times.
– supercat
Aug 9 at 18:06
In your fifth para, what did you mean by "There's a strong chance that the interrupt might not occur at all"? Did you mean in the case that the CPU is executing arbitrary instructions, therefore the interrupt might not happen, therefore the screen flips out?
– Wilson
Aug 10 at 10:34
@Wilson essentially. Arbitrary instructions are not guaranteed to generate a captured interrupt. Therefore the interruption mechanism that ensures lines are the correct length can't be used to keep track of raster position during arbitrary code. I'll try to edit the answer later.
– Tommy
Aug 10 at 15:10
1
For more details on using the processor executing instructions to create video timing, see Don Lancaster's book "The Cheap Video Cookbook". While it uses a different CPU than the ZX-80, the concepts are similar.
– Dithermaster
Aug 14 at 19:50
add a comment |Â
up vote
7
down vote
The ZX80 uses the CPU to generate the video display signals, and the timing is not perfect. It differs from the PAL spec slightly. In addition the clock controlling the CPU frequency is a low cost resonator (see X1 in the lower right hand corner) which didn't produce the most stable frequency, and that signal is then buffered and transferred from one side of the PCB to the other which all adds jitter.
The ZX80 ROM doesn't use interrupts or timers, it simply dedicates itself to producing the video signal and runs at maximum speed in a loop while doing so. The timing is created by the execution time of the inner loops that generate the video signal.
That's why the display blanks when you press a key or do any processing. The CPU simply stops generating the video signal while it handles the keypress or executes a BASIC instruction.
answered Aug 9 at 13:13
user
1,664210
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
accepted
It's probably bad form to cite yourself, but I wrote up my understanding of the ZX80 and ZX81 hardware here, scraped together from a few different sources but most notably Wilf Rigter's hardware and software summary.
Your assessment is right. The standard ZX80 ROM loop outputs a screen, checks for keypresses, and repeats. That loop is exactly the length of a frame if no key is pressed. If a key is pressed then additional processing happens, so the start of the next frame is delayed. The TV is then out of sync.
Interrupts are used during display generation to communicate the end of a line. The logic is trivial: during a refresh cycle bit 6 of the refresh address is echoed to the interrupt line. So when bit 6 is 0, an interrupt is signalled.
However:
- the Z80 performs an interrupt if it is being signalled one cycle before the end of an instruction. Therefore an interrupt is communicated only if the final part of an instruction is a refresh cycle; and
- when it is signalled is a function of the rate at which the refresh counter has increased. Which also depends upon the particular instructions being performed.
Therefore the interrupt mechanism doesn't have reliable behaviour during arbitrary code. It can't be used for line counting or any other purpose anywhere other than during the output cycle.
As a result the base ZX80 has no means to keep track of display position outside of its display loop. So it doesn't even try; it just allows the display to lose sync.
Digressions:
There are ZX80 games which do not roll through very careful cycle counting of every possible execution path.
The interrupt logic isn't so much for keeping track of position, it's more to allow the compact display to work — a ZX80 will put a HALT at the end of any line that is less than 32 bytes wide, and not use any storage for the rest of the line. The Z80 will HALT when it gets there and then stay where it is until the interrupt is signalled. So rather than the display taking a fixed 32*24 = 768 bytes on a 1kb machine, it takes only 32 + (number of visible characters).
The ZX81 remedies the situation with a horizontal counter that generates both NMI and WAIT. NMI is edge triggered, not level, so you don't need to worry about where the Z80 is in its stream when you signal it. Using WAIT as well overcomes the problem of phase: it's essentially true to say that there's a maximum amount of time it can take for an NMI to begin processing, and the NMI response honours WAIT so you can stretch the NMI response to a fixed time relative to the horizontal scan.
edited Aug 11 at 12:28
Anthon
1032
answered Aug 9 at 13:43
Tommy
12k13261
2
I wonder if a 555 or 7555 could have been used for vertical sync timing? Drop horizontal sync during the lower overscan interval, do a tiny bit of computation, wait for the timer, and then start horizontal sync for a few lines, then vertical sync, and then back to horizontal sync. The image wouldn't be perfectly stable, but would be a lot less bouncy than starting frames at "random" times.
– supercat
Aug 9 at 18:06
In your fifth para, what did you mean by "There's a strong chance that the interrupt might not occur at all"? Did you mean in the case that the CPU is executing arbitrary instructions, therefore the interrupt might not happen, therefore the screen flips out?
– Wilson
Aug 10 at 10:34
@Wilson essentially. Arbitrary instructions are not guaranteed to generate a captured interrupt. Therefore the interruption mechanism that ensures lines are the correct length can't be used to keep track of raster position during arbitrary code. I'll try to edit the answer later.
– Tommy
Aug 10 at 15:10
1
For more details on using the processor executing instructions to create video timing, see Don Lancaster's book "The Cheap Video Cookbook". While it uses a different CPU than the ZX-80, the concepts are similar.
– Dithermaster
Aug 14 at 19:50
add a comment |Â
up vote
14
down vote
accepted
It's probably bad form to cite yourself, but I wrote up my understanding of the ZX80 and ZX81 hardware here, scraped together from a few different sources but most notably Wilf Rigter's hardware and software summary.
Your assessment is right. The standard ZX80 ROM loop outputs a screen, checks for keypresses, and repeats. That loop is exactly the length of a frame if no key is pressed. If a key is pressed then additional processing happens, so the start of the next frame is delayed. The TV is then out of sync.
Interrupts are used during display generation to communicate the end of a line. The logic is trivial: during a refresh cycle bit 6 of the refresh address is echoed to the interrupt line. So when bit 6 is 0, an interrupt is signalled.
However:
- the Z80 performs an interrupt if it is being signalled one cycle before the end of an instruction. Therefore an interrupt is communicated only if the final part of an instruction is a refresh cycle; and
- when it is signalled is a function of the rate at which the refresh counter has increased. Which also depends upon the particular instructions being performed.
Therefore the interrupt mechanism doesn't have reliable behaviour during arbitrary code. It can't be used for line counting or any other purpose anywhere other than during the output cycle.
As a result the base ZX80 has no means to keep track of display position outside of its display loop. So it doesn't even try; it just allows the display to lose sync.
Digressions:
There are ZX80 games which do not roll through very careful cycle counting of every possible execution path.
The interrupt logic isn't so much for keeping track of position, it's more to allow the compact display to work — a ZX80 will put a HALT at the end of any line that is less than 32 bytes wide, and not use any storage for the rest of the line. The Z80 will HALT when it gets there and then stay where it is until the interrupt is signalled. So rather than the display taking a fixed 32*24 = 768 bytes on a 1kb machine, it takes only 32 + (number of visible characters).
The ZX81 remedies the situation with a horizontal counter that generates both NMI and WAIT. NMI is edge triggered, not level, so you don't need to worry about where the Z80 is in its stream when you signal it. Using WAIT as well overcomes the problem of phase: it's essentially true to say that there's a maximum amount of time it can take for an NMI to begin processing, and the NMI response honours WAIT so you can stretch the NMI response to a fixed time relative to the horizontal scan.
edited Aug 11 at 12:28
Anthon
1032
answered Aug 9 at 13:43
Tommy
12k13261
2
I wonder if a 555 or 7555 could have been used for vertical sync timing? Drop horizontal sync during the lower overscan interval, do a tiny bit of computation, wait for the timer, and then start horizontal sync for a few lines, then vertical sync, and then back to horizontal sync. The image wouldn't be perfectly stable, but would be a lot less bouncy than starting frames at "random" times.
– supercat
Aug 9 at 18:06
In your fifth para, what did you mean by "There's a strong chance that the interrupt might not occur at all"? Did you mean in the case that the CPU is executing arbitrary instructions, therefore the interrupt might not happen, therefore the screen flips out?
– Wilson
Aug 10 at 10:34
@Wilson essentially. Arbitrary instructions are not guaranteed to generate a captured interrupt. Therefore the interruption mechanism that ensures lines are the correct length can't be used to keep track of raster position during arbitrary code. I'll try to edit the answer later.
– Tommy
Aug 10 at 15:10
1
For more details on using the processor executing instructions to create video timing, see Don Lancaster's book "The Cheap Video Cookbook". While it uses a different CPU than the ZX-80, the concepts are similar.
– Dithermaster
Aug 14 at 19:50
add a comment |Â
up vote
14
down vote
accepted
up vote
14
down vote
accepted
It's probably bad form to cite yourself, but I wrote up my understanding of the ZX80 and ZX81 hardware here, scraped together from a few different sources but most notably Wilf Rigter's hardware and software summary.
Your assessment is right. The standard ZX80 ROM loop outputs a screen, checks for keypresses, and repeats. That loop is exactly the length of a frame if no key is pressed. If a key is pressed then additional processing happens, so the start of the next frame is delayed. The TV is then out of sync.
Interrupts are used during display generation to communicate the end of a line. The logic is trivial: during a refresh cycle bit 6 of the refresh address is echoed to the interrupt line. So when bit 6 is 0, an interrupt is signalled.
However:
- the Z80 performs an interrupt if it is being signalled one cycle before the end of an instruction. Therefore an interrupt is communicated only if the final part of an instruction is a refresh cycle; and
- when it is signalled is a function of the rate at which the refresh counter has increased. Which also depends upon the particular instructions being performed.
Therefore the interrupt mechanism doesn't have reliable behaviour during arbitrary code. It can't be used for line counting or any other purpose anywhere other than during the output cycle.
As a result the base ZX80 has no means to keep track of display position outside of its display loop. So it doesn't even try; it just allows the display to lose sync.
Digressions:
There are ZX80 games which do not roll through very careful cycle counting of every possible execution path.
The interrupt logic isn't so much for keeping track of position, it's more to allow the compact display to work — a ZX80 will put a HALT at the end of any line that is less than 32 bytes wide, and not use any storage for the rest of the line. The Z80 will HALT when it gets there and then stay where it is until the interrupt is signalled. So rather than the display taking a fixed 32*24 = 768 bytes on a 1kb machine, it takes only 32 + (number of visible characters).
The ZX81 remedies the situation with a horizontal counter that generates both NMI and WAIT. NMI is edge triggered, not level, so you don't need to worry about where the Z80 is in its stream when you signal it. Using WAIT as well overcomes the problem of phase: it's essentially true to say that there's a maximum amount of time it can take for an NMI to begin processing, and the NMI response honours WAIT so you can stretch the NMI response to a fixed time relative to the horizontal scan.
edited Aug 11 at 12:28
Anthon
1032
answered Aug 9 at 13:43
Tommy
12k13261
It's probably bad form to cite yourself, but I wrote up my understanding of the ZX80 and ZX81 hardware here, scraped together from a few different sources but most notably Wilf Rigter's hardware and software summary.
Your assessment is right. The standard ZX80 ROM loop outputs a screen, checks for keypresses, and repeats. That loop is exactly the length of a frame if no key is pressed. If a key is pressed then additional processing happens, so the start of the next frame is delayed. The TV is then out of sync.
Interrupts are used during display generation to communicate the end of a line. The logic is trivial: during a refresh cycle bit 6 of the refresh address is echoed to the interrupt line. So when bit 6 is 0, an interrupt is signalled.
However:
- the Z80 performs an interrupt if it is being signalled one cycle before the end of an instruction. Therefore an interrupt is communicated only if the final part of an instruction is a refresh cycle; and
- when it is signalled is a function of the rate at which the refresh counter has increased. Which also depends upon the particular instructions being performed.
Therefore the interrupt mechanism doesn't have reliable behaviour during arbitrary code. It can't be used for line counting or any other purpose anywhere other than during the output cycle.
As a result the base ZX80 has no means to keep track of display position outside of its display loop. So it doesn't even try; it just allows the display to lose sync.
Digressions:
There are ZX80 games which do not roll through very careful cycle counting of every possible execution path.
The interrupt logic isn't so much for keeping track of position, it's more to allow the compact display to work — a ZX80 will put a HALT at the end of any line that is less than 32 bytes wide, and not use any storage for the rest of the line. The Z80 will HALT when it gets there and then stay where it is until the interrupt is signalled. So rather than the display taking a fixed 32*24 = 768 bytes on a 1kb machine, it takes only 32 + (number of visible characters).
The ZX81 remedies the situation with a horizontal counter that generates both NMI and WAIT. NMI is edge triggered, not level, so you don't need to worry about where the Z80 is in its stream when you signal it. Using WAIT as well overcomes the problem of phase: it's essentially true to say that there's a maximum amount of time it can take for an NMI to begin processing, and the NMI response honours WAIT so you can stretch the NMI response to a fixed time relative to the horizontal scan.
edited Aug 11 at 12:28
Anthon
1032
answered Aug 9 at 13:43
Tommy
12k13261
edited Aug 11 at 12:28
Anthon
1032
edited Aug 11 at 12:28
Anthon
1032
edited Aug 11 at 12:28
Anthon
1032
1032
answered Aug 9 at 13:43
Tommy
12k13261
answered Aug 9 at 13:43
Tommy
12k13261
answered Aug 9 at 13:43
Tommy
12k13261
12k13261
2
I wonder if a 555 or 7555 could have been used for vertical sync timing? Drop horizontal sync during the lower overscan interval, do a tiny bit of computation, wait for the timer, and then start horizontal sync for a few lines, then vertical sync, and then back to horizontal sync. The image wouldn't be perfectly stable, but would be a lot less bouncy than starting frames at "random" times.
– supercat
Aug 9 at 18:06
In your fifth para, what did you mean by "There's a strong chance that the interrupt might not occur at all"? Did you mean in the case that the CPU is executing arbitrary instructions, therefore the interrupt might not happen, therefore the screen flips out?
– Wilson
Aug 10 at 10:34
@Wilson essentially. Arbitrary instructions are not guaranteed to generate a captured interrupt. Therefore the interruption mechanism that ensures lines are the correct length can't be used to keep track of raster position during arbitrary code. I'll try to edit the answer later.
– Tommy
Aug 10 at 15:10
1
For more details on using the processor executing instructions to create video timing, see Don Lancaster's book "The Cheap Video Cookbook". While it uses a different CPU than the ZX-80, the concepts are similar.
– Dithermaster
Aug 14 at 19:50
add a comment |Â
2
I wonder if a 555 or 7555 could have been used for vertical sync timing? Drop horizontal sync during the lower overscan interval, do a tiny bit of computation, wait for the timer, and then start horizontal sync for a few lines, then vertical sync, and then back to horizontal sync. The image wouldn't be perfectly stable, but would be a lot less bouncy than starting frames at "random" times.
– supercat
Aug 9 at 18:06
In your fifth para, what did you mean by "There's a strong chance that the interrupt might not occur at all"? Did you mean in the case that the CPU is executing arbitrary instructions, therefore the interrupt might not happen, therefore the screen flips out?
– Wilson
Aug 10 at 10:34
@Wilson essentially. Arbitrary instructions are not guaranteed to generate a captured interrupt. Therefore the interruption mechanism that ensures lines are the correct length can't be used to keep track of raster position during arbitrary code. I'll try to edit the answer later.
– Tommy
Aug 10 at 15:10
1
For more details on using the processor executing instructions to create video timing, see Don Lancaster's book "The Cheap Video Cookbook". While it uses a different CPU than the ZX-80, the concepts are similar.
– Dithermaster
Aug 14 at 19:50
2
2
I wonder if a 555 or 7555 could have been used for vertical sync timing? Drop horizontal sync during the lower overscan interval, do a tiny bit of computation, wait for the timer, and then start horizontal sync for a few lines, then vertical sync, and then back to horizontal sync. The image wouldn't be perfectly stable, but would be a lot less bouncy than starting frames at "random" times.
– supercat
Aug 9 at 18:06
I wonder if a 555 or 7555 could have been used for vertical sync timing? Drop horizontal sync during the lower overscan interval, do a tiny bit of computation, wait for the timer, and then start horizontal sync for a few lines, then vertical sync, and then back to horizontal sync. The image wouldn't be perfectly stable, but would be a lot less bouncy than starting frames at "random" times.
– supercat
Aug 9 at 18:06
In your fifth para, what did you mean by "There's a strong chance that the interrupt might not occur at all"? Did you mean in the case that the CPU is executing arbitrary instructions, therefore the interrupt might not happen, therefore the screen flips out?
– Wilson
Aug 10 at 10:34
In your fifth para, what did you mean by "There's a strong chance that the interrupt might not occur at all"? Did you mean in the case that the CPU is executing arbitrary instructions, therefore the interrupt might not happen, therefore the screen flips out?
– Wilson
Aug 10 at 10:34
@Wilson essentially. Arbitrary instructions are not guaranteed to generate a captured interrupt. Therefore the interruption mechanism that ensures lines are the correct length can't be used to keep track of raster position during arbitrary code. I'll try to edit the answer later.
– Tommy
Aug 10 at 15:10
@Wilson essentially. Arbitrary instructions are not guaranteed to generate a captured interrupt. Therefore the interruption mechanism that ensures lines are the correct length can't be used to keep track of raster position during arbitrary code. I'll try to edit the answer later.
– Tommy
Aug 10 at 15:10
1
1
For more details on using the processor executing instructions to create video timing, see Don Lancaster's book "The Cheap Video Cookbook". While it uses a different CPU than the ZX-80, the concepts are similar.
– Dithermaster
Aug 14 at 19:50
For more details on using the processor executing instructions to create video timing, see Don Lancaster's book "The Cheap Video Cookbook". While it uses a different CPU than the ZX-80, the concepts are similar.
– Dithermaster
Aug 14 at 19:50
add a comment |Â
up vote
7
down vote
The ZX80 uses the CPU to generate the video display signals, and the timing is not perfect. It differs from the PAL spec slightly. In addition the clock controlling the CPU frequency is a low cost resonator (see X1 in the lower right hand corner) which didn't produce the most stable frequency, and that signal is then buffered and transferred from one side of the PCB to the other which all adds jitter.
The ZX80 ROM doesn't use interrupts or timers, it simply dedicates itself to producing the video signal and runs at maximum speed in a loop while doing so. The timing is created by the execution time of the inner loops that generate the video signal.
That's why the display blanks when you press a key or do any processing. The CPU simply stops generating the video signal while it handles the keypress or executes a BASIC instruction.
answered Aug 9 at 13:13
user
1,664210
add a comment |Â
up vote
7
down vote
The ZX80 uses the CPU to generate the video display signals, and the timing is not perfect. It differs from the PAL spec slightly. In addition the clock controlling the CPU frequency is a low cost resonator (see X1 in the lower right hand corner) which didn't produce the most stable frequency, and that signal is then buffered and transferred from one side of the PCB to the other which all adds jitter.
The ZX80 ROM doesn't use interrupts or timers, it simply dedicates itself to producing the video signal and runs at maximum speed in a loop while doing so. The timing is created by the execution time of the inner loops that generate the video signal.
That's why the display blanks when you press a key or do any processing. The CPU simply stops generating the video signal while it handles the keypress or executes a BASIC instruction.
answered Aug 9 at 13:13
user
1,664210
add a comment |Â
up vote
7
down vote
up vote
7
down vote
The ZX80 uses the CPU to generate the video display signals, and the timing is not perfect. It differs from the PAL spec slightly. In addition the clock controlling the CPU frequency is a low cost resonator (see X1 in the lower right hand corner) which didn't produce the most stable frequency, and that signal is then buffered and transferred from one side of the PCB to the other which all adds jitter.
The ZX80 ROM doesn't use interrupts or timers, it simply dedicates itself to producing the video signal and runs at maximum speed in a loop while doing so. The timing is created by the execution time of the inner loops that generate the video signal.
That's why the display blanks when you press a key or do any processing. The CPU simply stops generating the video signal while it handles the keypress or executes a BASIC instruction.
answered Aug 9 at 13:13
user
1,664210
The ZX80 uses the CPU to generate the video display signals, and the timing is not perfect. It differs from the PAL spec slightly. In addition the clock controlling the CPU frequency is a low cost resonator (see X1 in the lower right hand corner) which didn't produce the most stable frequency, and that signal is then buffered and transferred from one side of the PCB to the other which all adds jitter.
The ZX80 ROM doesn't use interrupts or timers, it simply dedicates itself to producing the video signal and runs at maximum speed in a loop while doing so. The timing is created by the execution time of the inner loops that generate the video signal.
That's why the display blanks when you press a key or do any processing. The CPU simply stops generating the video signal while it handles the keypress or executes a BASIC instruction.
answered Aug 9 at 13:13
user
1,664210
answered Aug 9 at 13:13
user
1,664210
answered Aug 9 at 13:13
user
1,664210
answered Aug 9 at 13:13
user
1,664210
1,664210
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7233%2fwhy-does-the-zx80-not-produce-a-steady-display-signal%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
