Wonderful! I am so glad you're going down this rabbit hole. Back in the summer of 1980, when I had my ZX80, I figured out enough about how the CPU generated the display to be able to design and build hardware to generate 63 user-defined characters and their inverses. That required a hardware decode of the Halt instruction, a 1k byte RAM, and a bit of logic. The ZX80 video system is the work of a genius in terms of its efficient use of hardware. I look forward to seeing how this series develops.
Yep, the use of Halt to generate the NOPs and the refresh counter to generate the interrupt is very impressive. I think they've out done Steve Wozniak!
@@DrMattRegan Yes. The trick with the NOPs and the Halt instruction allowed the timing to be preserved, but in the small memory of the basic ZX80, a line with only (say) 10 displayed characters would use only 11 bytes of memory space, so there was still space remaining for programs and variables; a blank line used only a single byte.
Yep, i only actually found out recently that it used display lists. The schematic look crazy when you first look at it without the software. For a long time i was wondering what is so special about D6, but it is set for halt but none of the character codes.
Great video of this great machine. It was: The computer. And Apple ][ too. I fainted, this wiring diagram was familiar from somewhere. I know every inch of it. It's been over 40 years since I last saw this 1:17 schematic. This was displayed as a poster above my desk. I've built a lot of these machines for friends. With 17 TTL ICs, the Slow/Fast circuit on a separate panel, that's another 5 ICs, 22 in total. Those were incredible great times. Speech synthesizer program we made it in 1 kbyte size, we won a programming competition with it an original ZX-81 computer. It was a great gem. The machines we built didn't have a box, but their keyboards had a Hall generator, which is still considered professional today. Later, the ZX-80 was built with the cheap ICE4000 FPGA in 1 chip.
Cool, thanks. It's such an interesting circuit, it really flexes the Z80. Slow mode will require a column counter, so i'll probably do that last. I want to get it to work in ZX80 mode first.
Great video - I've followed you for a while, and having started my home computer learning with a ZX80, it's interesting to look back and understand now what I didn't then!
Good thinking, those jumper PCB's saved you a lot of wiring time. I watched this twice to really understand it. Using instruction op codes as control signals and a data signal was clever and a bit crazy. You aren't really interested in what the instructions do, just their bits and execution times.
Thanks Martin. Very crazy and completely impractical, but don't worry, i'll be weaning the design off the use data bits for sync and video in the upcoming videos. I mainly wanted to show that the z80 alone can generate the timing required to drive a display.
I took a course in Atari 2600 programming in 6502 assembly, and yes racing the beam is exactly how the TIA works, the instructions have to be timed so that the other side of the screen on the playing field is different (ie not mirror or repeat). I found this to be quite challenging! D Matt Regan, you are very knowledgeable! I have to admit a lot of this is still so far above my head, but I like the videos and I'm looking forward to learning more from you!
Ive took a look at doing a atari2600 emulator and when i realized about its video TIA and how the screen is rendered as the game code is squeezed in were you can with cycle accurate emulation to pull it all of. Kinda scarred me of trying the emulation. Programmers who produced games then in my opinion truly were special. I can only take my hat of to them. I think there was 1 player, 2 enemy sprites and a bullet sprite all being rendered in time. Hence racing the beam! as well as squeezing in the game logic. I take my hat of to those guys! Kudos
Awesome. Just discovered your channel. Ive written a ZX81 emulator in BlitzMaxNG. Took me a couple of years before the DFILE break down and how its emulated works just to to get my emulator to produce Video output. I still haven't fathomed Hi-res etc. Keep up the good work.
Great project. Back in the 1980s I got interested in how computers worked and started with a ZX81 kit assembled by myself. Looking forward how your project progresses and subscribed. Maybe sometime I try it out by myself using my old ZX81
Me and a guy from work figured out how the ZX80 video worked back in 1982. We didn’t like the shouting capitalized font, so added our own memory, and filled it with our own font. Because the Z80 was doing all the work drawing the screen, it was dog slow. But it was cheap so could do computing at home.
"And we generally just round this down to 312" Rounding down to 312 is fundamentally what makes this a progressive signal. If you left the line count at 312.5 (or anything else with an extra half line per field) then you would still end up with an interlaced signal (though, line doubled unless you actually added support for extra vertical resolution and alternating between odd and even lines) The extra half line is fundamental to an interlaced video signal. Early CRT TVs (up until the late 90s) didn't have any electronics to count the lines or anything special handling of interlaced or progressive signals. They didn't even understand the concept. It's hard to explain in text, but what's actually happen with interlaced signals is that the horizontal and vertical flyback transformers are independent from each other. The vertical position of the beem doesn't move once a line during hblank. It's actually moving down continually, the right side of a line is slightly lower than the left side (and only slightly above the left side of the next line) To get a progressive video format, the horizontal and vertical sync pulses need to be a whole ratio of each other, so that at the start of each field the horizontal and vertical positions are consistent. Interlaced video formats use a sync pulses that are slightly out of phase, resulting in an extra or missing half of a line in each field. Because of the extra half of a line and the vertical position moves continually, at the start of the second field's first line, the vertical position of the beam is actually half a line lower (or higher) than the previous field. This half-line offset allows all the lines of the second field to sit in-between the lines of the first field. And you get interlaced video without any special electronics at the receiving end. It also raises the possibility of other exotic video formats. If you adjusted the ratio so you had an extra ⅓ or ¼ of a line, you could create a triple or quadruple interlaced video format (not that anyone would want that, and CRT was designed to display an interlaced video format.... but you could)
Yes, you are completely correct. But i was trying to avoid the details of interlaced video (which is a bit of a long topic as you know). The round down to 312 comment was meant in the context of NTSC, where most round to 262 but other do round to 264.
Huh, I recently finished reading Dan Lancaster's Cheap Video books (I know I'm about 40 years late to the party) but some of the stuff that was a bit harder to get my head around in those (because I haven't actually got to the point of actually implementing any of it, usually that's where stuff finally fits into my brain) is now making a lot more sense...
Those early computer engineers really had to struggle to make the hardware do what they wanted at minimum cost. It amused me when I realised while watching this that if you substituted a 1-bit RAM with separate input and output to store the data bit, you could then change the data in the RAM in order to change what was displayed on the screen. If I were making something like this nowadays, I'd probably just assign the Z80 to be dedicated to making the display and use a separate CPU for actually running programs. That would have been an expensive option "back in the day," though.
It really is amazing when you think about it. Getting it cheap probably enabled a million people to have access to a machine with BASIC whenever they wanted it.
Great project. I have been investigating the Jupiter Ace composite video generation, which takes the ZX81 video one step further by adding circuitry for the sync and pixel shifting output. Also note that some TVs/monitors don't like the composite signal generated by these machines, as they are not strictly to spec.
Interesting. I just had a quick look at some Jupiter Ace schematic diagrams (i'm not super familiar with it). Looks a bit like a hybrid or ZX81 and ZX Spectrum.
@@DrMattRegan Wow someone who remembers the Jupiter Ace! Yes what a brilliant little Forth machine. Myer Melbourne used to have a computer department where all the machines of the day were out to trial and the little Jupiter Ace wasn't getting any love as it was so weird ... so I played with it quite a bit. I would have been about 13 I think and it inspired me to combine my knowledge of 6502 assembly via the VIC 20 and the Jupiter Ace's Forth and build a custom machine based on the Rockwell R65F12 which had a Forth kernel built right in. Does that make me weird? I guess so.
@@AndyGraceMedia I never owned one, but I do have an original sales brochure for the machine in my collection. Forth is fascinating, and later used as the basis for Ample on the BBC Micro (the language that supports the Music 500 / 5000).
The ZX80/81 had "pixel shifting hardware" as well. In part also horizontal sync hardware. Only the vertical sync was fully software generated. The really special thing in the ZX80/81 was that they fooled the Z80 to address the character codes to be displayed, using its program counter as a character pointer (for about 70% of the time, the rest is normal program execution). This was done by jumping into the "display file" (but with A15 set) and "execute " these character codes as Z80 NOPs, as long as they are in the character range. The refresh register was thereby used as a column counter; by connecting A6 to INT it will halt the CPU when 32 characters are output (for each scan line, so repeated 8 times per character line). However, to save space, lines can be shorter in memory than 32 positions. So for these, it's instead halted by an actual HALT instruction at the end of the line. That's why they used the HALT instruction code as newline!
Well done! My cousin had a ZX-80 and he didn't know how to program. He asked me to come and write a PONG game, which I did. It was an ordeal because of the BASIC keywords being mapped to function keys and the membrane keyboard is awful to work with. I decided then that if a software engineer doesn't lead a clean life, and isn't a good person, then when he dies his hell will be to have to code software on a ZX-80. for all eternity. (ʘ_ʘ) If I could, I would rewrite the ZX-80 ROM to allow typing in of keywords manually AND I would install a proper keyboard. Then I would take that membrane keyboard out to my fire pit and set it ablaze.
Yes, i remember the frustration with the automatic keywords. Damn it, i want to type my own words, but alas, it probably saved a few bytes or ram, which was gold back then.
I had gotten a 65C02 for comparison for when I finally complete the SAP-6502 (I knew it had extra instructions including a working RoR, but discovered after the fact that for a few instructions cycle lengths... oh, I've acquired some used 27c322s, though saving them until after I finish the SAP-1 in the meantime going with the 27c1024s); any thoughts to the difference of effort of completing this using that 65c02? Outside the one in my old GameBoy, I don't have a spare Z80 floating around. I know I'll likely need to find a different set of opcodes and timings.
There is certainly space in the microcode to do it. I haven't looked at all the illegal/undocumented instructions, but to make it Apple IIe compatible, they probably should be done at some stage.
Some truly crazy circuits. I have a ZX80 clone board, that I should probably get going, I just need a keyboard 'sticker' for it. However the fact that it all but cannot do any processing while it's generating video kind of discourages me.
Awesome video! I wonder - is it possible to create a simple circuit that will generate DVI digital signal, at least in "low pixel format" display mode at 25.175 MHz?
@@DrMattRegan I saw that video, too, but it is about the analog output part for the DVI (can be used to connect the D-sub connector). My question is about the purely digital output, like the one that can be converted to HDMI connector...
@@mikafoxx2717 right, but both use "serial" data transmission, compared to "parallel" in VGA D-sub, thus require much higher clock rates, although provide pure digital signal. I was wondering if it is possible to get such high clock rates with discrete logic components...
@@DrMattRegan Sir Clive did some incredible work. The constraints of designing for cost/mass production really forced some creative solutions. It really helps that your explination started with a more technically optimal solution and then showed the very clever approach that was used in the ZX80. What trade offs were made for this approach? What possible capabilities did the ZX give up with this lower cost solution?
why to differeniate VSync signl and HSync signal if at the end they are mixed together? if you use the same bit you don't need two bit to start from and you don't need to mix the signal to the end, isn't it?
In hardware, HSync and VSync use the same signal, which is D5 clocked on M1BAR. In software, they are asserted at different times, so that is why there is different code for HSync and VSync,
Vsync & Hsync were earlier combined into one on D5 then clocked out together through the lower '74. Not later combined at the emitter follower. Routing separate uncombined signals is useful during development & troubleshooting. It's a tradeoff between reducing component count vs. understandability.
True, indeed the ZX80 has a different circuit for HSYNC and VSYNC, which i'll go over in video 4. I want this to be a journey where we start with the very simple and get more complex.
Good plan. Structured step by step. I look forward. I've noticed during a career in design is something can be acheived very ingeniously and efficient but doesn't catch on .... because only the designer knows how it works. So to avoid dead-ending one gets into this habit of adding redundant functions, extra circuit complexity - just to make it understandable. Or take the extra effort to explain clearly as you're doing 👍
its not quite the same , the zx81 only did 32 visible chrs (256 pixels) per line and had 2 H76 (halt) at the very start and 1 H76 at the end of each line and if you changed any of them the machine crashed , i do like the video though 🙂
@@DrMattRegan thats good , i worked out the soft ware side of things but never worked out how the hardware worked 🙂 are you going to do the speccy as well , that had a strange arrangement for the pixels ? 🙂
I designed a Z80 video system in the 70s, accessing the video memory on the refresh cycle to prevent video glitches. Perfect solution.
Excellent. It's a clever system.
Wonderful! I am so glad you're going down this rabbit hole. Back in the summer of 1980, when I had my ZX80, I figured out enough about how the CPU generated the display to be able to design and build hardware to generate 63 user-defined characters and their inverses. That required a hardware decode of the Halt instruction, a 1k byte RAM, and a bit of logic. The ZX80 video system is the work of a genius in terms of its efficient use of hardware. I look forward to seeing how this series develops.
Yep, the use of Halt to generate the NOPs and the refresh counter to generate the interrupt is very impressive. I think they've out done Steve Wozniak!
@@DrMattRegan Yes. The trick with the NOPs and the Halt instruction allowed the timing to be preserved, but in the small memory of the basic ZX80, a line with only (say) 10 displayed characters would use only 11 bytes of memory space, so there was still space remaining for programs and variables; a blank line used only a single byte.
Yep, i only actually found out recently that it used display lists. The schematic look crazy when you first look at it without the software. For a long time i was wondering what is so special about D6, but it is set for halt but none of the character codes.
@@DrMattRegan Exactly. 👍
Why have I never seen your channel reccomended before ?
Subbed. 👍
Excellent, enjoy!
Great video of this great machine.
It was: The computer. And Apple ][ too.
I fainted, this wiring diagram was familiar from somewhere.
I know every inch of it.
It's been over 40 years since I last saw this 1:17 schematic.
This was displayed as a poster above my desk.
I've built a lot of these machines for friends.
With 17 TTL ICs, the Slow/Fast circuit on a separate panel, that's another 5 ICs, 22 in total.
Those were incredible great times. Speech synthesizer program
we made it in 1 kbyte size, we won a programming competition with it
an original ZX-81 computer. It was a great gem. The machines we built didn't have a box,
but their keyboards had a Hall generator, which is still considered professional today.
Later, the ZX-80 was built with the cheap ICE4000 FPGA in 1 chip.
Glad you;re enjoying it. It's a fun project.
What a nice project, The ZX81 in slow mode uses the Hsync and Vsync area to do work, All other time is used to build the display. 👍
Cool, thanks. It's such an interesting circuit, it really flexes the Z80. Slow mode will require a column counter, so i'll probably do that last. I want to get it to work in ZX80 mode first.
Great video - I've followed you for a while, and having started my home computer learning with a ZX80, it's interesting to look back and understand now what I didn't then!
Great to hear! Enjoy.
Good thinking, those jumper PCB's saved you a lot of wiring time. I watched this twice to really understand it. Using instruction op codes as control signals and a data signal was clever and a bit crazy. You aren't really interested in what the instructions do, just their bits and execution times.
Thanks Martin. Very crazy and completely impractical, but don't worry, i'll be weaning the design off the use data bits for sync and video in the upcoming videos. I mainly wanted to show that the z80 alone can generate the timing required to drive a display.
I took a course in Atari 2600 programming in 6502 assembly, and yes racing the beam is exactly how the TIA works, the instructions have to be timed so that the other side of the screen on the playing field is different (ie not mirror or repeat). I found this to be quite challenging!
D Matt Regan, you are very knowledgeable! I have to admit a lot of this is still so far above my head, but I like the videos and I'm looking forward to learning more from you!
Thanks, it's actually a kind of favourite topic for me, i once build a whole machine along these ideas
dl.acm.org/doi/pdf/10.1145/192161.192192
Ive took a look at doing a atari2600 emulator and when i realized about its video TIA and how the screen is rendered as the game code is squeezed in were you can with cycle accurate emulation to pull it all of. Kinda scarred me of trying the emulation. Programmers who produced games then in my opinion truly were special. I can only take my hat of to them. I think there was 1 player, 2 enemy sprites and a bullet sprite all being rendered in time. Hence racing the beam! as well as squeezing in the game logic. I take my hat of to those guys! Kudos
Awesome. Just discovered your channel. Ive written a ZX81 emulator in BlitzMaxNG. Took me a couple of years before the DFILE break down and how its emulated works just to to get my emulator to produce Video output. I still haven't fathomed Hi-res etc. Keep up the good work.
Cool. I'd do pseudo-hi res a bit like video 2, but you have to choose a ROM character generator address that gives you the biggest range.
Okay. need to watch video 2 a few more times cheers. @@DrMattRegan
Great project. Back in the 1980s I got interested in how computers worked and started with a ZX81 kit assembled by myself. Looking forward how your project progresses and subscribed. Maybe sometime I try it out by myself using my old ZX81
Sounds great! You may be able to rebuild it!
you earned a subscriber !!
Wonderful project.
cheers !!
Thanks for the sub!
Me and a guy from work figured out how the ZX80 video worked back in 1982. We didn’t like the shouting capitalized font, so added our own memory, and filled it with our own font. Because the Z80 was doing all the work drawing the screen, it was dog slow. But it was cheap so could do computing at home.
Excellent, glad it's bringing back some memories.
great video!
Thanks!
Thanks!
Way beyond me, but cool and educational! I'm just happy I can program ASM on my Zeddy lol.
More z80 assembly to come !
"And we generally just round this down to 312"
Rounding down to 312 is fundamentally what makes this a progressive signal. If you left the line count at 312.5 (or anything else with an extra half line per field) then you would still end up with an interlaced signal (though, line doubled unless you actually added support for extra vertical resolution and alternating between odd and even lines)
The extra half line is fundamental to an interlaced video signal. Early CRT TVs (up until the late 90s) didn't have any electronics to count the lines or anything special handling of interlaced or progressive signals. They didn't even understand the concept.
It's hard to explain in text, but what's actually happen with interlaced signals is that the horizontal and vertical flyback transformers are independent from each other. The vertical position of the beem doesn't move once a line during hblank. It's actually moving down continually, the right side of a line is slightly lower than the left side (and only slightly above the left side of the next line)
To get a progressive video format, the horizontal and vertical sync pulses need to be a whole ratio of each other, so that at the start of each field the horizontal and vertical positions are consistent.
Interlaced video formats use a sync pulses that are slightly out of phase, resulting in an extra or missing half of a line in each field.
Because of the extra half of a line and the vertical position moves continually, at the start of the second field's first line, the vertical position of the beam is actually half a line lower (or higher) than the previous field.
This half-line offset allows all the lines of the second field to sit in-between the lines of the first field. And you get interlaced video without any special electronics at the receiving end.
It also raises the possibility of other exotic video formats. If you adjusted the ratio so you had an extra ⅓ or ¼ of a line, you could create a triple or quadruple interlaced video format (not that anyone would want that, and CRT was designed to display an interlaced video format.... but you could)
Yes, you are completely correct. But i was trying to avoid the details of interlaced video (which is a bit of a long topic as you know). The round down to 312 comment was meant in the context of NTSC, where most round to 262 but other do round to 264.
great explanation of zx81 video!
Glad you liked it! Enjoy.
Huh, I recently finished reading Dan Lancaster's Cheap Video books (I know I'm about 40 years late to the party) but some of the stuff that was a bit harder to get my head around in those (because I haven't actually got to the point of actually implementing any of it, usually that's where stuff finally fits into my brain) is now making a lot more sense...
@@SomeMorganSomewhere excellent, glad you got some value from it!
Very easy to follow as always 😊
Thank you! Cheers!
Those early computer engineers really had to struggle to make the hardware do what they wanted at minimum cost.
It amused me when I realised while watching this that if you substituted a 1-bit RAM with separate input and output to store the data bit, you could then change the data in the RAM in order to change what was displayed on the screen.
If I were making something like this nowadays, I'd probably just assign the Z80 to be dedicated to making the display and use a separate CPU for actually running programs. That would have been an expensive option "back in the day," though.
It really is amazing when you think about it. Getting it cheap probably enabled a million people to have access to a machine with BASIC whenever they wanted it.
Great project. I have been investigating the Jupiter Ace composite video generation, which takes the ZX81 video one step further by adding circuitry for the sync and pixel shifting output. Also note that some TVs/monitors don't like the composite signal generated by these machines, as they are not strictly to spec.
Interesting. I just had a quick look at some Jupiter Ace schematic diagrams (i'm not super familiar with it). Looks a bit like a hybrid or ZX81 and ZX Spectrum.
@@DrMattRegan Wow someone who remembers the Jupiter Ace! Yes what a brilliant little Forth machine. Myer Melbourne used to have a computer department where all the machines of the day were out to trial and the little Jupiter Ace wasn't getting any love as it was so weird ... so I played with it quite a bit. I would have been about 13 I think and it inspired me to combine my knowledge of 6502 assembly via the VIC 20 and the Jupiter Ace's Forth and build a custom machine based on the Rockwell R65F12 which had a Forth kernel built right in. Does that make me weird? I guess so.
I'd heard of the jupiter ace, but i think in the back of my brain i think i'd put it in the same basket as the vz200. I didn't know it ran forth.
@@AndyGraceMedia I never owned one, but I do have an original sales brochure for the machine in my collection. Forth is fascinating, and later used as the basis for Ample on the BBC Micro (the language that supports the Music 500 / 5000).
The ZX80/81 had "pixel shifting hardware" as well. In part also horizontal sync hardware. Only the vertical sync was fully software generated. The really special thing in the ZX80/81 was that they fooled the Z80 to address the character codes to be displayed, using its program counter as a character pointer (for about 70% of the time, the rest is normal program execution). This was done by jumping into the "display file" (but with A15 set) and "execute " these character codes as Z80 NOPs, as long as they are in the character range. The refresh register was thereby used as a column counter; by connecting A6 to INT it will halt the CPU when 32 characters are output (for each scan line, so repeated 8 times per character line). However, to save space, lines can be shorter in memory than 32 positions. So for these, it's instead halted by an actual HALT instruction at the end of the line. That's why they used the HALT instruction code as newline!
Brilliant!
Enjoy!
You need to relabel those jumpers as Turing Z80....
Ha ha yes. They just happened to be handy. I used them in this playlist th-cam.com/play/PLjQDRjQfW-84aOLT33kzoZghRofK-uL1F.html
Well done! My cousin had a ZX-80 and he didn't know how to program. He asked me to come and write a PONG game, which I did. It was an ordeal because of the BASIC keywords being mapped to function keys and the membrane keyboard is awful to work with. I decided then that if a software engineer doesn't lead a clean life, and isn't a good person, then when he dies his hell will be to have to code software on a ZX-80. for all eternity. (ʘ_ʘ) If I could, I would rewrite the ZX-80 ROM to allow typing in of keywords manually AND I would install a proper keyboard. Then I would take that membrane keyboard out to my fire pit and set it ablaze.
Yes, i remember the frustration with the automatic keywords. Damn it, i want to type my own words, but alas, it probably saved a few bytes or ram, which was gold back then.
I had gotten a 65C02 for comparison for when I finally complete the SAP-6502 (I knew it had extra instructions including a working RoR, but discovered after the fact that for a few instructions cycle lengths... oh, I've acquired some used 27c322s, though saving them until after I finish the SAP-1 in the meantime going with the 27c1024s); any thoughts to the difference of effort of completing this using that 65c02? Outside the one in my old GameBoy, I don't have a spare Z80 floating around. I know I'll likely need to find a different set of opcodes and timings.
There is certainly space in the microcode to do it. I haven't looked at all the illegal/undocumented instructions, but to make it Apple IIe compatible, they probably should be done at some stage.
Very neat using CPU /ROM. The CPU jammed full of features mass produced and very cheap
The ZX80/81 still uses a bunch more of the Z80 features, it's pretty impressive really.
Some truly crazy circuits. I have a ZX80 clone board, that I should probably get going, I just need a keyboard 'sticker' for it. However the fact that it all but cannot do any processing while it's generating video kind of discourages me.
Go for it! You can add the ZX81 slow option later.
Liked and subscribed!
Welcome, enjoy. Thanks for commenting.
Awesome video! I wonder - is it possible to create a simple circuit that will generate DVI digital signal, at least in "low pixel format" display mode at 25.175 MHz?
low pixel format should work with this th-cam.com/video/seyHAFpsoP8/w-d-xo.html
@@DrMattRegan I saw that video, too, but it is about the analog output part for the DVI (can be used to connect the D-sub connector). My question is about the purely digital output, like the one that can be converted to HDMI connector...
Fundamentally, DVI-D and HDMI are the same protocol. HDMI just has extra security stuff so it's harder to capture.@@cyberkexx
@@mikafoxx2717 right, but both use "serial" data transmission, compared to "parallel" in VGA D-sub, thus require much higher clock rates, although provide pure digital signal. I was wondering if it is possible to get such high clock rates with discrete logic components...
In the software variable Z80MEMORYSIZE doesn't result defined. So the listing, as is, cannot work. Isn't it?
Yeah, it's defined elsewhere. I don't always put all the code in every video, but i generally make it available on Github if people want it.
How much complexity would be needed to use dual port RAM instead of the ROM as the data source?
Yes, sir Clive had a very clever solution to this which I’ll reveal in the next video or two
@@DrMattRegan I can't wait!
What do you think of the dual use data bus?
@@DrMattRegan Sir Clive did some incredible work. The constraints of designing for cost/mass production really forced some creative solutions. It really helps that your explination started with a more technically optimal solution and then showed the very clever approach that was used in the ZX80. What trade offs were made for this approach? What possible capabilities did the ZX give up with this lower cost solution?
why to differeniate VSync signl and HSync signal if at the end they are mixed together? if you use the same bit you don't need two bit to start from and you don't need to mix the signal to the end, isn't it?
In hardware, HSync and VSync use the same signal, which is D5 clocked on M1BAR. In software, they are asserted at different times, so that is why there is different code for HSync and VSync,
Vsync & Hsync were earlier combined into one on D5 then clocked out together through the lower '74. Not later combined at the emitter follower. Routing separate uncombined signals is useful during development & troubleshooting. It's a tradeoff between reducing component count vs. understandability.
True, indeed the ZX80 has a different circuit for HSYNC and VSYNC, which i'll go over in video 4. I want this to be a journey where we start with the very simple and get more complex.
Good plan. Structured step by step. I look forward.
I've noticed during a career in design is something can be acheived very ingeniously and efficient but doesn't catch on .... because only the designer knows how it works. So to avoid dead-ending one gets into this habit of adding redundant functions, extra circuit complexity - just to make it understandable. Or take the extra effort to explain clearly as you're doing 👍
its not quite the same , the zx81 only did 32 visible chrs (256 pixels) per line and had 2 H76 (halt) at the very start and 1 H76 at the end of each line and if you changed any of them the machine crashed , i do like the video though 🙂
Yes, i'm going to try get the ZX80 version to work first, then upgrade it to ZX81.
@@DrMattRegan
thats good , i worked out the soft ware side of things but never worked out how the hardware worked 🙂
are you going to do the speccy as well , that had a strange arrangement for the pixels ? 🙂
@@YTANDY100 yep, also planning to do the speccy. It’s actually a bit more straightforward than the zx80/81
@@DrMattRegan
that is a surprise , it is a really strange arrangement , cant wait to see how it works 🙂