I love how these videos demystify what I could never understand back in my zx81 childhood! There was always a gap between combinational logic and microprocessors and memory and being a computer, so this pulls them all together.
In our house we had a ZX80 built from a kit, and the great thing about it was that it came with a full circuit diagram. Unlike the ZX81 there were no custom chips so it was a real education for the 12-year old me, figuring out how it worked.
My memory is rusty, but my understanding of why the Spectrums screen buffer has such an odd address layout is down to simplifying the work the ULA needed to address both the pixel data and colour data at the same time. I decided to double-check, and here's what was on "Break Into Program": "When the ULA is drawing the screen, it needs to make two fetches from DRAM, for the pixel data and the attribute data. In order to make this more efficient, the ULA uses DRAM page read mode. The advantage of this mode is that the bytes can be read quicker, but there is a limitation: the least significant 7 bits of the address being read must be the same."
Yeah. We had a discussion about page mode before on a different video. It doesn’t really buy you much, there is still only enough time for a single z80 access per 16 pixel block. It may have simplified the ULA design though and relaxed the timing on the DRAM.
@@DrMattRegan There's another reason that's often cited, namely that when rendering a character to the screen, if the start address is in HL, the next row of the character can be simply obtained with INC H.
@DrMattRegan There's another reason that's often cited, namely that when rendering a character to the screen, if the start address is in HL, the next row of the character can be simply obtained with INC H.
@@DrMattRegan It’s on my watch list, as I attempt to gain enough understanding of this subject to consider building a super-simple retro console with the idea of making on-board tools to enable anyone to create their own games. Most of it I can handle, but the output to a standard TV is proving to be stubbornly opaque to me. Your content certainly helps me to get some of it, I probably just need to watch it a hundred more times or so 🤪
Excellent adaptation, this could be used for many other retro video system, I am thinking of the TMS9929/18 TI chip, inspiration is only one Eprom away, Great explanation and concise timing, thanks for posting.
I finally found the time to watch this. Some really clever ideas for multiplexing the RAM and using the EEPROM for raster generation. When I watch videos using digital logic to generate raster scans, I also am amazed that the original TV engineers did it using vacuum tubes and analog circuits. Analog circuits still seem like magic to me.
Good idea, using static RAM allow to discard all refresh logic (ULA) and earn more time to operate with video functions (no refresh cycles). In some solutions video output acts as refresh due cyclic access to memory addresses.
Yep, that certainly happens in the Apple 2. I think the Spectrum memory sweep, will just keep the DRAM refreshed. To sweep through 128 rows when video is active it takes 2.048 ms, and the DRAM spec is for less than 2 ms. In the non active region, the Z80 will keep it refreshed, but i don't think we can guarantee every row will be hit with the Z80 when video is active.
In the late 70s (pre zx80) in the UK there was a company that produced eurocard sized boards for homebuilt computers - Reading based if I recall correctly. One card was a clever video card which used a program on a 2048 bit ROM to cause a Z80 MPU to generate the required signals for a video output. Sadly I had to dispose of the computer that I built around these boards many years ago.
In 1975 I designed the first of a homebrew computer based on the soon to be released Z80 1MHz CPU. 120GBP in 1976. I still have the original manual and the associated "Programming Reference Card" which, at the time, I'd practically memorized. Of course I'd used data from magazines etc. to guide me. Life intervened. So I thank you for the reminders of went through my mind nearly 50 years ago.@@DrMattRegan
I advise you to look at the design of the Soviet Spectrum, Zonov’s version - although of course all our Spectrums had 14 MHz quartz - but it was Zonov who made the minimal version using TTL logic and a single memory field where the video adapter did not conflict with the processor
Sounds interesting i'll have a look. I'm planning on going the whole hog and getting rid of the Z80 as well. Have a look at this video. th-cam.com/video/y04AH5Q3Z3I/w-d-xo.html
15:52 looking at the address bits for raster and attribute like this, or rather in reverse, with focus on the low 8 bits, the V5:3 shuffle actually makes sense, because the low 8 bits are identical and stays the same for a full video read cycle, saving precious logic cells and timing constraints in the ULA. raster-V7:6 has to go where it is to avoid overlapping the raster and attribute buffers, and V2:0 goes where there's space left, in the middle. This also enables the RAS-CAS-CAS read pattern to fetch 16 bits of raster/attribute in 3 cycles, and still refreshes the video RAM fast enough while the Z80 is running uninterrupted in high RAM.
Yep, i think it saves code in the ULA, but I'm not sure page mode saves that much over full random access fetches from a bandwidth perspective. For a state machine running at 7 MHz in the ULA (an assumption), over a 16 pixel block, full random access take 3 clocks each (12 clocks in total), leaving 4 clocks out of 16 for the Z80. In DRAM page mode, we're looking at 5 clock for a RAS-CAS-CAS access (3 for the initial RAS-CAS and 2 for each CAS after that), so doing 2 of these will take 10 of the 16 clocks. We would save 2 clocks out of 16, but this isn't enough (going from 4->6) to do another z80 memory access is that short window. Even if you put all 4 access (per 16 pixel block) in the same page with some more address swizzling, i think we still have 9 video clocks and 7 for the Z80 per 16 pixel cycle. 7 pixel clocks is 3.5 CPU clocks, and i don't that's enough for back to back reads, so we still stuck with one CPU access per 16 pixel block. Would be interesting to have a look with a logic analyzer.
I was stationed in England and had both the Spectrum and the ZX81. I brought my Spectrum back to the States and tried like hell to get it working. I even wrote Timex to see if somebody could help. ::sigh:: I wish I still had that.
Just got you channel recommended by TH-cam, loving all this series! Now, I am intrigued: how does this SRAM sharing approach affects the overall performance? I understand this circuit leaves the CPU pretty much free of wait states (unless I missed some important caveat). Can you make some comparative benchmark with an original ZX Spectrum ?
Yes, the machine will be faster operating out of the lower 16K RAM. I have a video where i go into this in more detail. th-cam.com/video/mL0K5u1zkko/w-d-xo.html I'll probably implement the wait circuit described in that video.
I'm really interested in the use of look up tables to emulate logic, in a similar way to using an eeprom. I'm thinking that a simple table look up is quicker than implementing a series of gates in code, particularly something like a counter or a flip-flop. I have started work on an Atari Pong emulated as look up tables which maybe one day can output a composite signal using a microcontroller. Only issue I can see is that this method won't take into account gate propagation delays which are integral to Pong.
This is a very well used technique especially these days with eprom so cheap. You can essentially simulate any combinational logic using this method. Back in the 8 bit days eproms were however quite expensive and slower than today's so it was less useful.
If your interest in pushing EPROMs to do more, have a look at this series. th-cam.com/play/PLjQDRjQfW-84j-jLvrbEeDvGl0QrhX9p7.html The CPU is basically a big EPROM and RAM.
As schrodingerscat1863 says, certainly EPROMs were (maybe still are) a lot slower than logic gates, which take 10s of nano-seconds to switch verses hundreds of nano-seconds for EPROMs in the old days. Additionally each calculation needs to be clocked, so if you have logic in series (and the complete answer can't be calculated and implemented in the logic) you will need multiple clock cycles to perform the calculation.
I personally use Jaycar in Australia www.jaycar.com.au/black-wire-wrap-wire-on-spool/p/WW4345?pos=2&queryId=a6e2bf71cf03fc3c034a21396ba9608a It's not cheap, but you want the Kynar. I've found the cheap stuff from China doesn't work as well.
It's a pity, looks like number of chips does grow. Do you have plans to reduce it in next version? Using two separate SRAM chips could reduce total number? If just replace ULA with few parallel FLASH chips and replace DRAM chips with 2 SRAM chips?
Ha ha, well yes. I did work on the raster generator used by NVidia about 20 years ago and it was hideously complex even then. It's all proprietary, so we can only really talk about what is in the patents. I personally think any discussion about how these modern systems work is going to be somewhat superficial.
I love how these videos demystify what I could never understand back in my zx81 childhood! There was always a gap between combinational logic and microprocessors and memory and being a computer, so this pulls them all together.
Excellent. If you want to dig a bit deeper, you might want to watch this playlist.
th-cam.com/play/PLjQDRjQfW-84j-jLvrbEeDvGl0QrhX9p7.html
In our house we had a ZX80 built from a kit, and the great thing about it was that it came with a full circuit diagram. Unlike the ZX81 there were no custom chips so it was a real education for the 12-year old me, figuring out how it worked.
@@davidnash4393 yeah, from a learning perspective, the zx80 was a winner. Custom logic hides so much!
My memory is rusty, but my understanding of why the Spectrums screen buffer has such an odd address layout is down to simplifying the work the ULA needed to address both the pixel data and colour data at the same time.
I decided to double-check, and here's what was on "Break Into Program":
"When the ULA is drawing the screen, it needs to make two fetches from DRAM, for the pixel data and the attribute data. In order to make this more efficient, the ULA uses DRAM page read mode. The advantage of this mode is that the bytes can be read quicker, but there is a limitation: the least significant 7 bits of the address being read must be the same."
Yeah. We had a discussion about page mode before on a different video. It doesn’t really buy you much, there is still only enough time for a single z80 access per 16 pixel block. It may have simplified the ULA design though and relaxed the timing on the DRAM.
A mystery that has been bugging me since the first time I got my hands dirty with a ZX Spectrum, 40-ish years ago. It all makes sense now.
Excellent. If you haven't seen it i go into more detail in this video
th-cam.com/video/mL0K5u1zkko/w-d-xo.html
@@DrMattRegan There's another reason that's often cited, namely that when rendering a character to the screen, if the start address is in HL, the next row of the character can be simply obtained with INC H.
@DrMattRegan There's another reason that's often cited, namely that when rendering a character to the screen, if the start address is in HL, the next row of the character can be simply obtained with INC H.
It is so satisfying watching these videos. I love the way you explain everything so clearly as well as the diagrams you provide.
Thank you very much!
Absolutely amazing, I wish I understood half of this, but fascinating all the same.
Glad you enjoyed it!
Try watching the ZX81 version,
th-cam.com/play/PLjQDRjQfW-84WG47-5UjPz1BrXxc1acvd.html
@@DrMattRegan It’s on my watch list, as I attempt to gain enough understanding of this subject to consider building a super-simple retro console with the idea of making on-board tools to enable anyone to create their own games. Most of it I can handle, but the output to a standard TV is proving to be stubbornly opaque to me. Your content certainly helps me to get some of it, I probably just need to watch it a hundred more times or so 🤪
I love your videos TTL has always fascinated me.
Glad you like them!
This is really impressive.
Do you plan to publish the documentation of the project once you finish it?
Yep! I’ll certainly put out a schematic and probably a board as well
@@DrMattRegan Excellent! Im really interested in the approach you have taken for the video system, it opens a world of possibilities :)
Excellent adaptation, this could be used for many other retro video system, I am thinking of the TMS9929/18 TI chip, inspiration is only one Eprom away, Great explanation and concise timing, thanks for posting.
Great idea. Thanks for the feedback.
I finally found the time to watch this. Some really clever ideas for multiplexing the RAM and using the EEPROM for raster generation. When I watch videos using digital logic to generate raster scans, I also am amazed that the original TV engineers did it using vacuum tubes and analog circuits. Analog circuits still seem like magic to me.
Yes, particularly the PLLs for color burst is amazing analog magic !
Good idea, using static RAM allow to discard all refresh logic (ULA) and earn more time to operate with video functions (no refresh cycles). In some solutions video output acts as refresh due cyclic access to memory addresses.
Yep, that certainly happens in the Apple 2. I think the Spectrum memory sweep, will just keep the DRAM refreshed. To sweep through 128 rows when video is active it takes 2.048 ms, and the DRAM spec is for less than 2 ms. In the non active region, the Z80 will keep it refreshed, but i don't think we can guarantee every row will be hit with the Z80 when video is active.
Ah, so THAT might be the reason why classic Spectrum clones from the GDR use SRAM instead of DRAM for the video circuit.
Incredible, so glad the TH-cam algorithms highlighted this. Beautiful explanations.
Glad you like it!
Awesome work.
Thank you! Cheers!
In the late 70s (pre zx80) in the UK there was a company that produced eurocard sized boards for homebuilt computers - Reading based if I recall correctly. One card was a clever video card which used a program on a 2048 bit ROM to cause a Z80 MPU to generate the required signals for a video output. Sadly I had to dispose of the computer that I built around these boards many years ago.
You might like this series
th-cam.com/play/PLjQDRjQfW-84WG47-5UjPz1BrXxc1acvd.html
where i start with a Z80 and an EPROM to generate video.
In 1975 I designed the first of a homebrew computer based on the soon to be released Z80 1MHz CPU. 120GBP in 1976. I still have the original manual and the associated "Programming Reference Card" which, at the time, I'd practically memorized. Of course I'd used data from magazines etc. to guide me. Life intervened. So I thank you for the reminders of went through my mind nearly 50 years ago.@@DrMattRegan
Great, glad you got some value from it.
Might that company have been Green bank?
I advise you to look at the design of the Soviet Spectrum, Zonov’s version - although of course all our Spectrums had 14 MHz quartz - but it was Zonov who made the minimal version using TTL logic and a single memory field where the video adapter did not conflict with the processor
Sounds interesting i'll have a look.
I'm planning on going the whole hog and getting rid of the Z80 as well.
Have a look at this video.
th-cam.com/video/y04AH5Q3Z3I/w-d-xo.html
lmao glad to see I'm not the only one using that song
I also suggest "The darkness - Seemed Like a Good Idea at the Time" when appropriate ;)
Thanks, will have a look at it.
спасибо, хорошая работа.
Thanks.
Очень хорошо всё объяснено, спасибо. Только цвета чернил и бумаги перепутаны. Белый фон, черные буквы
Thanks, yes, the colours will be corrected in the next video.
15:52 looking at the address bits for raster and attribute like this, or rather in reverse, with focus on the low 8 bits, the V5:3 shuffle actually makes sense, because the low 8 bits are identical and stays the same for a full video read cycle, saving precious logic cells and timing constraints in the ULA. raster-V7:6 has to go where it is to avoid overlapping the raster and attribute buffers, and V2:0 goes where there's space left, in the middle. This also enables the RAS-CAS-CAS read pattern to fetch 16 bits of raster/attribute in 3 cycles, and still refreshes the video RAM fast enough while the Z80 is running uninterrupted in high RAM.
Yep, i think it saves code in the ULA, but I'm not sure page mode saves that much over full random access fetches from a bandwidth perspective.
For a state machine running at 7 MHz in the ULA (an assumption), over a 16 pixel block, full random access take 3 clocks each (12 clocks in total), leaving 4 clocks out of 16 for the Z80.
In DRAM page mode, we're looking at 5 clock for a RAS-CAS-CAS access (3 for the initial RAS-CAS and 2 for each CAS after that), so doing 2 of these will take 10 of the 16 clocks. We would save 2 clocks out of 16, but this isn't enough (going from 4->6) to do another z80 memory access is that short window.
Even if you put all 4 access (per 16 pixel block) in the same page with some more address swizzling, i think we still have 9 video clocks and 7 for the Z80 per 16 pixel cycle. 7 pixel clocks is 3.5 CPU clocks, and i don't that's enough for back to back reads, so we still stuck with one CPU access per 16 pixel block.
Would be interesting to have a look with a logic analyzer.
Amaxing
Thanks. Glad you liked it.
I was stationed in England and had both the Spectrum and the ZX81. I brought my Spectrum back to the States and tried like hell to get it working. I even wrote Timex to see if somebody could help. ::sigh:: I wish I still had that.
You might like this series on the ZX81 as well then.
th-cam.com/play/PLjQDRjQfW-84WG47-5UjPz1BrXxc1acvd.html
Just got you channel recommended by TH-cam, loving all this series! Now, I am intrigued: how does this SRAM sharing approach affects the overall performance? I understand this circuit leaves the CPU pretty much free of wait states (unless I missed some important caveat). Can you make some comparative benchmark with an original ZX Spectrum ?
Yes, the machine will be faster operating out of the lower 16K RAM. I have a video where i go into this in more detail.
th-cam.com/video/mL0K5u1zkko/w-d-xo.html
I'll probably implement the wait circuit described in that video.
I'm really interested in the use of look up tables to emulate logic, in a similar way to using an eeprom. I'm thinking that a simple table look up is quicker than implementing a series of gates in code, particularly something like a counter or a flip-flop. I have started work on an Atari Pong emulated as look up tables which maybe one day can output a composite signal using a microcontroller. Only issue I can see is that this method won't take into account gate propagation delays which are integral to Pong.
This is a very well used technique especially these days with eprom so cheap. You can essentially simulate any combinational logic using this method. Back in the 8 bit days eproms were however quite expensive and slower than today's so it was less useful.
If your interest in pushing EPROMs to do more, have a look at this series.
th-cam.com/play/PLjQDRjQfW-84j-jLvrbEeDvGl0QrhX9p7.html
The CPU is basically a big EPROM and RAM.
Correct, it was cheaper to use the logic back then. But a 27C322 is pretty cheap and if you're hind wiring things, it's much easier.
As schrodingerscat1863 says, certainly EPROMs were (maybe still are) a lot slower than logic gates, which take 10s of nano-seconds to switch verses hundreds of nano-seconds for EPROMs in the old days. Additionally each calculation needs to be clocked, so if you have logic in series (and the complete answer can't be calculated and implemented in the logic) you will need multiple clock cycles to perform the calculation.
Appearing long after I was tinkering with Z80s and logic gates, an FPGA is probably the way to go these days rather than an EEPROM.
Your wiring technique looks interesting. Where do you get the AWG 30 bare wire? Is it also possible to source the sleeve for it on a roll? Thanks.
I personally use Jaycar in Australia
www.jaycar.com.au/black-wire-wrap-wire-on-spool/p/WW4345?pos=2&queryId=a6e2bf71cf03fc3c034a21396ba9608a
It's not cheap, but you want the Kynar.
I've found the cheap stuff from China doesn't work as well.
Very interesting!
Any change you might throw in a Timex hi-color mode?
Not for now, but i might expand it later.
Would it be possible to program an eeprom to replace the real ula in a speccy as replacing them is silly prices or maybe use a pico
Not really. Pins are very different and we need the DRAM controller etc
There are VGA monitors that support 50Hz, can you make a version for that?
Yes, just a matter of programming the EPROM to do that. I’ll give it a try.
It's a pity, looks like number of chips does grow. Do you have plans to reduce it in next version?
Using two separate SRAM chips could reduce total number?
If just replace ULA with few parallel FLASH chips and replace DRAM chips with 2 SRAM chips?
I'm planning on going in a different direction. Next step is to replace both the ULA and Z80 with EPROMs, octal d-type flip flops and SRAM.
@@DrMattRegan Waw, interesting what will be the final tip count!
it s 2024....just saying
Ha ha, well yes. I did work on the raster generator used by NVidia about 20 years ago and it was hideously complex even then. It's all proprietary, so we can only really talk about what is in the patents. I personally think any discussion about how these modern systems work is going to be somewhat superficial.
Actually, do you mind if i quote this in an upcoming video, i'll leave you name off it to make it anonymous.