Glad you picked up on that! It was meant to be a pun, but there's actually a second twist. I use the Dr title from my PhD in computer science, but as it just so happens, i also have a medical degree and actually work as a doctor.
Hi Matt. The Sinclair QL was actually originally a basis for a new zx spectrum, but only the business machine was pursued with some spurriou (sorry laid up in bed this comment might be a little difficult to write fluently) spurious design choices. What about stripping off those design choices and incorporating the improvements into a z80 spectrum design? The QL gate array logic has been redesigned giving a 16 colour 256 mode, and better 512 mode. The same person is working on a better version with sprites, but I think there is a simpler way that discrete logic could be used. Here are a few ideas: A simpler serial network bus that can be broken out into whatever peripheral format needed (the most advanced part of this proposal, which could even be made into a sub standard USB bus port, to support a subset of peripherals using more recent versions of the processor and memory. Where, whatever function just requires programming to the controls that the basic generic USB device requires. We only need a few game controllers, a mouse, maybe a keyboard, printer and USB stick. If there is any generic printer functionality. Other things like generic hub, speaker, microphone and scanner support are other things that maybe desirable, but optional). But, this ties in with the second most difficult feature (below). So, such a serial port would have raw Async and time division modes to support all devices. The time division mode also allowing data to be sent asynchronous across it's time slots, to service Async port usage (I can't currently remember other modes, but these are enough). But one idea, is to off load performance draining Async polling through a small discrete logic circuit. The list of peripherals above, covers everything needed for a super Spectrum 0.5, which could have been done in those days with USB devices today substituted for Sinclair branded serial devices and parallel port converters, similar to what Commodore did with the HP serial bus, but faster and simpler. No keyboard controller, no micro drives, no QL expansion ports. No Atari game controllers, with a keyboard game controls, to game controller, user configurable configuration files. No tape or external audio. The USB substituting for, microdrive, rom card, and cheap 3 inch floppy, like the deal Amstrad got, which Sinclair could have pursued out of the many alternative 3+ inch formats out there (this being a spectrum, we assume they would have shipped tape and card on the basic version (personally, I would have just looked at incorporating micro cassette with fast seek and lookup table that could be copied into memory from the start of cassette, so seeking is non contact). I did suggest to Clive, a way of retro fitting a micro disk into the microdrive slot years later to give a more durable format). No keyboard controller, but using a faster z80 and a register to keep track. Graphics timing, to allow up to 256 colour (first model, in the 256 mode, second model more and pelleted) and 16 colour 512 mode, and optionally, maybe a proper programmable colour character graphics 80 column 640x240+ mode for word-processing etc, with 8 bit character 4 bit fore ground background colours). Maybe a 16 colour pallet. Maybe a 256 colour 320 mode. To keep memory usage down, maybe 16 and 256 colour character modes. Even though using the increased bandwidth of modern parts it is easier, this is how a QL could have been done, and how 1984-1986 Spectrums could have gone. The important part is, only a portion of memory and 256 or 16 colour characters are needed. Complexity here, is based on what features are chosen from these modes. The second most complex thing is the simplified DMA controller with simplified blitter to overlay objects into bitmap or character set. If we presume the first 9 or 16 characters are 16 or 256 colours for the main character object, the blitter has a known configured character space. If we presume every 9 to 16 characters, a segment, can be used for other main animated objects, the blitter can easily render by prescribed layout rules to those characters at that position. The programmer only needs to have a 3x3 or 4x4 characters from one of the segments of characters at that space before they call the blitter. The 3x3 or 4x4 is only in the blitter's understanding of things. Otherwise, the characters can be used anywhere individually. It's for the simple games of the day rather than mega big graphics objects. The blitter is not even needed, except it's faster. It could be implemented without blitter, but any pure bit mapped mode would be slower. Using the multi coloured character scheme, even a 16KB machine could take advantage of 16 and 256 colour character graphics. But, without any of that, the simplest machine becomes your spectrum design with 16 and 256 colour programmable character modes, and maybe 512/640 80 column mode. Which is similar to what I had wanted to do in the past, as a proof of concept of how the zx81 could have been designed, except 16 and 4 colour character modes and a pallet, and maybe 512 width support.
Wow, i think that qualifies as the longest comment ever! I think i'm heading off in a different direction on the Spectrum. My next goal after this series is to replace the Z80 with a TTL-CPU. Something along the lines of the Turing6502 series. I haven't looked too closely at the QL, if i ever do a SAP68000/Turing68000 TTL built CPU, i think the QL would be a natural target. I'm not super familiar with it, but it looks like the easiest target of the 68000 series machines. SD cards replacing the microdrives etc. I'm more interested in the basics than building out a graphics system. I previously worked as a computer architect at NVidia, so building an 8-bit graphics system feels a bit underwhelming.
@@DrMattRegan :) Thanks. Nowhere as underwhelming as Spectrum and QL graphics. An easier target, is something like the My4th discrete logic computer. Minimal instruction set microprocessors offer a lot more for the same complexity as 8 bit designs. As for the Spectrum/QL, it's more about function for me. I still want to one day, get a team together to do a Jupiter Ace replacement. Something like 16-32 bit misc Forth processor, retro style upgrade computer. I'm over here to get some similar ideas. Anyway. Look up the HEC computer design. Andy is doing a protected mode Z80 system with MSX 2 graphics. A lot of components to make the protected mode work off of an old undocumented Z80 feature.
@@DrMattRegan Here are the two systems: th-cam.com/video/Kn0MxHlima0/w-d-xo.html Andy has some newer live videos. He certainly is a whirlwind of activity. With this, being only one of his projects: th-cam.com/video/rpTXft1GNQ0/w-d-xo.html
I build zx with static ram from 486/pentium mainb. cache chips. With assync VGA. From z80 side all RAM was always ready. It was too fast for games. As it was assync design I boosted CPU to ~7MHz. And it was working fine. I used old altera cpld for logic.
Excellent info, this is going to be very useful for a crazy idea that I started tinkering. I got some dual port SRAM and I'm planning to replace the lower 16Kb with these and decouple the CPU and the ULA, with a port for each one and an isolated clock for the CPU it should remove the contention and also even be able to add a 8Mhz variant of the Z80 :)
12:13 Wait, the Z80 has a single-phase clock, and M1 without _WAIT states is always 4 T-states = CPU clock cycles. The RAS/CAS as seen is _MREQ during T1-T2 for the fetch, or T1-T3 for other M-cycles. The page-mode timing is as tight fit as can be.
Two of the T states in M1 are for refresh, which we don't need for scan out. The raster itself will refresh the memory. (slightly out of spec at 2.05ms). I didn't see any refresh RAS cycles during scan out on the scope. So we only need two T states available for CPU access, in the 16 pixel scan (8 T-states). We need wait to co-ordinate this, but interestingly, the spectrum actually stops the clock. Admittedly i haven't tried this solution, but it fits in theory.
That was a very well thought out explanation! I think I am with you on the "Cheaper is Better" option for Sir Clive. Absolutely no doubt in my mind that they just wanted to use cheaper drams. IIRC didn't the 16K spectrum use its ram chips at half capacity so they could even use ram chips witch only tested partially good (assuming they were cheaper?) anyway love the series so far!
Glad you liked it. I think it was the 32K expansion in the 48K machine that used the faulty chips. They were made as 64K chips which failed QA. But if half the chip was good, they passed them off as a 32 K chip. Very clever business man!..
On another note. This makes me wonder. The speccy screen memory is overcomplicated, taking many instructions to do anything. Betting someone has built a hardware expansion to convert sequential into real screen layout. Would be a cool H/W accelator expansion.
@@DrMattReganthe 64K DRAMs were tested and marked depending on if the lower or upper half failed. Then there was a link on the motherboard which defined whether the upper or lower half of the installed chips were to be used. More famous scrimping. Saying that, it’s common to de-rate chips these days depending on how well they test out. AMD CPUs for example, beyond being speed binned, are fabbed based on an 8 core chiplet. If one or two of the cores are bad then they mask off two and ship them in 6 or 12 core parts (2 chiplets for the 12 core version obviously).
With the C64 I understand that their cache fixed the to 40 characters, but with the ZX spectrum I now don’t understand why it does not have a turbo button like a PC to increase the clock up to the limit of whatever the manufacturer got for DRAMs that day. Though I guess that 14 MHz signal processing is on the technical edge of the ULA. Is this CMOS? NMOS ?
I think old Sir Clive was more interested in price than performance! I'm not sure what technology the ULA was made with, but i don't think it was CMOS. CMOS was originally quite slow (4000 series logic). 14Mhz was a fast signal back then.
@@DrMattRegan with DRAM you pay more out of the sweet spot. Extra slow or small or defect DRAM went out of stock at large retailers fast and became expensive vintage hardware. Can you show me any IC that does not use MOSFETs? TTL logic! But for some reason those chips seem to be very primitive and only used for glue logic. Since nMOS became TTL compatible, I wonder if a TTL chip really uses bipolar transistors internally. RCA 1802 hit 3 MHz before 1980. Maybe some hand optimization and fab improvements would bring that to 14 MHz in 1982 ? I could imagine to do double illumination: use a microscope objective to etch the fast part of the chip with shorter FET channels.
The Z80 was tightly coupled with RAM speed. SRAM cache didn’t exist, so pretty much you were limited to whatever parts you could get at reasonable prices. They were also limited by the fact that the Z80A was only rated to 4MHz and the later B model only ran to 6MHz, so a simple speed doubling turbo wasn’t going to happen.
The Z80 was initially fabbed in NMOS technology. Later versions were CMOS. The ULA may have been CMOS, but was limited by the CPU. The 6502 was designed such that the RAM could be easily split between the CPU and the video controller by simple time diversion multiplexing with memory running at double speed. This is how the C64 and BBC computers worked. The Z80 memory timing was much more complex so couldn’t be split in the same way.
@@stevetodd7383 why would nMOSFET be faster than CMOS? And early versions of ICs were actually pMOSFET due to some fab limitations. NMOSFET has twice the electron mobility than PMOSFET. So that gives us a factor of two in speed? But nMOSFET already had a power problem (and heat). And hence the pull up current source was throttling everything. No such thing in CMOS. They did not have spare transistors to equalise latencies. 6502 actually had precharge transistors. So aggressively pull up all busses before the next cycle. Maybe they even included some feedback to compensate the previous bit pattern. But every sender then needs to stick to its values. No edge trigger stuff possible. 6502 was not designed to share memory with video. This was more an accident because SRAM was so fast. ZX spectrum shows how to share memory on Z80 . It looks clean to me. I found some discussion, that the ZX spectrum killed RAM because it ramped up the 3 supply voltages in a wrong way. But the RAM itself and the sharing is a good design.
Great analysis, thank you. I am with you that there might still only be one access in the available spare time in the video memory timing sequence. But a wider window for the RAM access will slightly reduce the time the CPU waits for the window to be available. Of course, the CPU will also be spending time elsewhere, accessing ROM mostly, and also sometimes I/O, etc. so the time when the RAM isn't available won't always be lost. But I am of the same view as you that this arrangement was most likely to allow slower RAMs to be used. 150ns parts would have been at a premium compared to 200ns, although I doubt they would have used parts much slower than that. At the time, 150 and 200 were the most common commercially available, as I recall (it's been a while). Thanks again.
Thanks, it was actually your comments that inspired this video (hope you don't me quoting them). I did actually have some slides on the wider window, i suspect the latency will go down from 22 -> 20 cycles (for a 3-byte, 10T cycle instruction). But these slides ended up on the cutting floor. I agree that 150ns and 200ns parts were most common, but knowing Sir Clive, when they were designing it, i'm sure they'd aim for the slowest parts possible, even if they were just 200ns parts that missed timing.
![[LIVE] : ONE ลุมพินี 72 วันนี้!! คู่เอก "ก้องศึก vs โจอาคิม"](http://i.ytimg.com/vi/hT1EOSsRPac/mqdefault.jpg)
![BOWKYLION - เจ้านายคะ (work-life imbalance) [Official MV]](http://i.ytimg.com/vi/6bFj8G2pOi4/mqdefault.jpg)
Loved The Clash reference. I hear Casbah now every time you say CAS-bar :P
Haha, i did have a longer clip initially, but youtube detected it.
You could say they Clocked The CAS-bar. 😊
I simply clicked this video to comment on the thumbnail. What an interesting vision with a user name containing "Dr." Well done.
Glad you picked up on that! It was meant to be a pun, but there's actually a second twist. I use the Dr title from my PhD in computer science, but as it just so happens, i also have a medical degree and actually work as a doctor.
Great. Now I got that song clash song, "rock the cas bar," stuck in my head.
Love this series, great work, thanks for sharing it with us.
Thanks for the feedback. Enjoy!
I’m definitely going go have to rewatch this, but I totally will, because this is super interesting! Thank you so much for sharing this! ❤
Please do!
Just came here to say, “great thumbnail!”
Thanks, thumbnails can be tricky.
Hi Matt. The Sinclair QL was actually originally a basis for a new zx spectrum, but only the business machine was pursued with some spurriou (sorry laid up in bed this comment might be a little difficult to write fluently) spurious design choices. What about stripping off those design choices and incorporating the improvements into a z80 spectrum design?
The QL gate array logic has been redesigned giving a 16 colour 256 mode, and better 512 mode. The same person is working on a better version with sprites, but I think there is a simpler way that discrete logic could be used. Here are a few ideas:
A simpler serial network bus that can be broken out into whatever peripheral format needed (the most advanced part of this proposal, which could even be made into a sub standard USB bus port, to support a subset of peripherals using more recent versions of the processor and memory. Where, whatever function just requires programming to the controls that the basic generic USB device requires. We only need a few game controllers, a mouse, maybe a keyboard, printer and USB stick. If there is any generic printer functionality. Other things like generic hub, speaker, microphone and scanner support are other things that maybe desirable, but optional). But, this ties in with the second most difficult feature (below).
So, such a serial port would have raw Async and time division modes to support all devices. The time division mode also allowing data to be sent asynchronous across it's time slots, to service Async port usage (I can't currently remember other modes, but these are enough). But one idea, is to off load performance draining Async polling through a small discrete logic circuit.
The list of peripherals above, covers everything needed for a super Spectrum 0.5, which could have been done in those days with USB devices today substituted for Sinclair branded serial devices and parallel port converters, similar to what Commodore did with the HP serial bus, but faster and simpler. No keyboard controller, no micro drives, no QL expansion ports. No Atari game controllers, with a keyboard game controls, to game controller, user configurable configuration files. No tape or external audio. The USB substituting for, microdrive, rom card, and cheap 3 inch floppy, like the deal Amstrad got, which Sinclair could have pursued out of the many alternative 3+ inch formats out there (this being a spectrum, we assume they would have shipped tape and card on the basic version (personally, I would have just looked at incorporating micro cassette with fast seek and lookup table that could be copied into memory from the start of cassette, so seeking is non contact). I did suggest to Clive, a way of retro fitting a micro disk into the microdrive slot years later to give a more durable format). No keyboard controller, but using a faster z80 and a register to keep track.
Graphics timing, to allow up to 256 colour (first model, in the 256 mode, second model more and pelleted) and 16 colour 512 mode, and optionally, maybe a proper programmable colour character graphics 80 column 640x240+ mode for word-processing etc, with 8 bit character 4 bit fore ground background colours). Maybe a 16 colour pallet. Maybe a 256 colour 320 mode. To keep memory usage down, maybe 16 and 256 colour character modes. Even though using the increased bandwidth of modern parts it is easier, this is how a QL could have been done, and how 1984-1986 Spectrums could have gone. The important part is, only a portion of memory and 256 or 16 colour characters are needed. Complexity here, is based on what features are chosen from these modes.
The second most complex thing is the simplified DMA controller with simplified blitter to overlay objects into bitmap or character set. If we presume the first 9 or 16 characters are 16 or 256 colours for the main character object, the blitter has a known configured character space. If we presume every 9 to 16 characters, a segment, can be used for other main animated objects, the blitter can easily render by prescribed layout rules to those characters at that position. The programmer only needs to have a 3x3 or 4x4 characters from one of the segments of characters at that space before they call the blitter. The 3x3 or 4x4 is only in the blitter's understanding of things. Otherwise, the characters can be used anywhere individually. It's for the simple games of the day rather than mega big graphics objects.
The blitter is not even needed, except it's faster. It could be implemented without blitter, but any pure bit mapped mode would be slower.
Using the multi coloured character scheme, even a 16KB machine could take advantage of 16 and 256 colour character graphics.
But, without any of that, the simplest machine becomes your spectrum design with 16 and 256 colour programmable character modes, and maybe 512/640 80 column mode. Which is similar to what I had wanted to do in the past, as a proof of concept of how the zx81 could have been designed, except 16 and 4 colour character modes and a pallet, and maybe 512 width support.
Wow, i think that qualifies as the longest comment ever!
I think i'm heading off in a different direction on the Spectrum. My next goal after this series is to replace the
Z80 with a TTL-CPU. Something along the lines of the Turing6502 series.
I haven't looked too closely at the QL, if i ever do a SAP68000/Turing68000 TTL built CPU, i think the QL would be a natural target. I'm not super familiar with it, but it looks like the easiest target of the 68000 series machines. SD cards replacing the microdrives etc. I'm more interested in the basics than building out a graphics system. I previously worked as a computer architect at NVidia, so building an 8-bit graphics system feels a bit underwhelming.
@@DrMattRegan :)
Thanks.
Nowhere as underwhelming as Spectrum and QL graphics.
An easier target, is something like the My4th discrete logic computer. Minimal instruction set microprocessors offer a lot more for the same complexity as 8 bit designs.
As for the Spectrum/QL, it's more about function for me. I still want to one day, get a team together to do a Jupiter Ace replacement. Something like 16-32 bit misc Forth processor, retro style upgrade computer. I'm over here to get some similar ideas.
Anyway. Look up the HEC computer design. Andy is doing a protected mode Z80 system with MSX 2 graphics. A lot of components to make the protected mode work off of an old undocumented Z80 feature.
@@DrMattRegan Here are the two systems:
th-cam.com/video/Kn0MxHlima0/w-d-xo.html
Andy has some newer live videos. He certainly is a whirlwind of activity. With this, being only one of his projects:
th-cam.com/video/rpTXft1GNQ0/w-d-xo.html
спасибо, хорошая работа.
Enjoy!
I build zx with static ram from 486/pentium mainb. cache chips. With assync VGA. From z80 side all RAM was always ready. It was too fast for games. As it was assync design I boosted CPU to ~7MHz. And it was working fine. I used old altera cpld for logic.
Excellent. Did you wait the CPU, or didn’t it matter?
Excellent info, this is going to be very useful for a crazy idea that I started tinkering. I got some dual port SRAM and I'm planning to replace the lower 16Kb with these and decouple the CPU and the ULA, with a port for each one and an isolated clock for the CPU it should remove the contention and also even be able to add a 8Mhz variant of the Z80 :)
Excellent, sounds good. Let me know how you go with it. I'm keen to hear how you integrate a faster z80.
12:13 Wait, the Z80 has a single-phase clock, and M1 without _WAIT states is always 4 T-states = CPU clock cycles. The RAS/CAS as seen is _MREQ during T1-T2 for the fetch, or T1-T3 for other M-cycles. The page-mode timing is as tight fit as can be.
Two of the T states in M1 are for refresh, which we don't need for scan out. The raster itself will refresh the memory. (slightly out of spec at 2.05ms). I didn't see any refresh RAS cycles during scan out on the scope.
So we only need two T states available for CPU access, in the 16 pixel scan (8 T-states). We need wait to co-ordinate this, but interestingly, the spectrum actually stops the clock. Admittedly i haven't tried this solution, but it fits in theory.
Just another data point: I opened up the issue 4S Spectrum I have here and it's fitted with TI 4116-15NL for the lower RAM, so 150ns.
Thanks, i'm interested to see what the spread of speed ratings will be.
That was a very well thought out explanation! I think I am with you on the "Cheaper is Better" option for Sir Clive. Absolutely no doubt in my mind that they just wanted to use cheaper drams. IIRC didn't the 16K spectrum use its ram chips at half capacity so they could even use ram chips witch only tested partially good (assuming they were cheaper?) anyway love the series so far!
Glad you liked it. I think it was the 32K expansion in the 48K machine that used the faulty chips. They were made as 64K chips which failed QA. But if half the chip was good, they passed them off as a 32 K chip. Very clever business man!..
On another note. This makes me wonder. The speccy screen memory is overcomplicated, taking many instructions to do anything. Betting someone has built a hardware expansion to convert sequential into real screen layout. Would be a cool H/W accelator expansion.
Interesting. I'm sure some of the Soviet clone makers tried everything!
@@DrMattReganthe 64K DRAMs were tested and marked depending on if the lower or upper half failed. Then there was a link on the motherboard which defined whether the upper or lower half of the installed chips were to be used. More famous scrimping.
Saying that, it’s common to de-rate chips these days depending on how well they test out. AMD CPUs for example, beyond being speed binned, are fabbed based on an 8 core chiplet. If one or two of the cores are bad then they mask off two and ship them in 6 or 12 core parts (2 chiplets for the 12 core version obviously).
With the C64 I understand that their cache fixed the to 40 characters, but with the ZX spectrum I now don’t understand why it does not have a turbo button like a PC to increase the clock up to the limit of whatever the manufacturer got for DRAMs that day. Though I guess that 14 MHz signal processing is on the technical edge of the ULA. Is this CMOS? NMOS ?
I think old Sir Clive was more interested in price than performance! I'm not sure what technology the ULA was made with, but i don't think it was CMOS. CMOS was originally quite slow (4000 series logic). 14Mhz was a fast signal back then.
@@DrMattRegan with DRAM you pay more out of the sweet spot. Extra slow or small or defect DRAM went out of stock at large retailers fast and became expensive vintage hardware. Can you show me any IC that does not use MOSFETs? TTL logic! But for some reason those chips seem to be very primitive and only used for glue logic. Since nMOS became TTL compatible, I wonder if a TTL chip really uses bipolar transistors internally.
RCA 1802 hit 3 MHz before 1980. Maybe some hand optimization and fab improvements would bring that to 14 MHz in 1982 ? I could imagine to do double illumination: use a microscope objective to etch the fast part of the chip with shorter FET channels.
The Z80 was tightly coupled with RAM speed. SRAM cache didn’t exist, so pretty much you were limited to whatever parts you could get at reasonable prices. They were also limited by the fact that the Z80A was only rated to 4MHz and the later B model only ran to 6MHz, so a simple speed doubling turbo wasn’t going to happen.
The Z80 was initially fabbed in NMOS technology. Later versions were CMOS. The ULA may have been CMOS, but was limited by the CPU.
The 6502 was designed such that the RAM could be easily split between the CPU and the video controller by simple time diversion multiplexing with memory running at double speed. This is how the C64 and BBC computers worked. The Z80 memory timing was much more complex so couldn’t be split in the same way.
@@stevetodd7383 why would nMOSFET be faster than CMOS? And early versions of ICs were actually pMOSFET due to some fab limitations. NMOSFET has twice the electron mobility than PMOSFET. So that gives us a factor of two in speed? But nMOSFET already had a power problem (and heat). And hence the pull up current source was throttling everything. No such thing in CMOS. They did not have spare transistors to equalise latencies.
6502 actually had precharge transistors. So aggressively pull up all busses before the next cycle. Maybe they even included some feedback to compensate the previous bit pattern. But every sender then needs to stick to its values. No edge trigger stuff possible.
6502 was not designed to share memory with video. This was more an accident because SRAM was so fast. ZX spectrum shows how to share memory on Z80 . It looks clean to me. I found some discussion, that the ZX spectrum killed RAM because it ramped up the 3 supply voltages in a wrong way. But the RAM itself and the sharing is a good design.
Great analysis, thank you. I am with you that there might still only be one access in the available spare time in the video memory timing sequence. But a wider window for the RAM access will slightly reduce the time the CPU waits for the window to be available. Of course, the CPU will also be spending time elsewhere, accessing ROM mostly, and also sometimes I/O, etc. so the time when the RAM isn't available won't always be lost. But I am of the same view as you that this arrangement was most likely to allow slower RAMs to be used. 150ns parts would have been at a premium compared to 200ns, although I doubt they would have used parts much slower than that. At the time, 150 and 200 were the most common commercially available, as I recall (it's been a while). Thanks again.
Thanks, it was actually your comments that inspired this video (hope you don't me quoting them). I did actually have some slides on the wider window, i suspect the latency will go down from 22 -> 20 cycles (for a 3-byte, 10T cycle instruction). But these slides ended up on the cutting floor. I agree that 150ns and 200ns parts were most common, but knowing Sir Clive, when they were designing it, i'm sure they'd aim for the slowest parts possible, even if they were just 200ns parts that missed timing.
@@DrMattRegan Not a problem, although I did have to explain my reaction to my wife... 😁