The Z80's secret feature discovered after 40 years!
Vložit
- čas přidán 30. 04. 2024
- For years, it's generally accepted that 8 bit microcomputer CPUs does not have hardware support for protected mode. However, my recent discovery shows otherwise. In this video, I will show you how to implement memory and I/O protection on a z80 with minimal external circuit.
Links:
General Introduction to the Z80: • Looking at the Zilog Z...
The history of Zilog and Z80: • Intel’s worst Nightmare
Z80 assemnly tutorial: • Z80 Assembly Language ...
CPU timeline: www.vgamuseum.info/index.php/cpu
Support this project on Patreon: / andy18650
Join our discord server: / discord
GitHub repo for the project: github.com/Andy18650/HEC-Mode...
Chapters:
0:00 The Z80 has a protected mode
0:32 Literally the worst intro video ever
0:52 What is Z80
1:52 Why is protected mode important?
3:10 Undocumented? Really?
4:10 How to implement protected mode
10:34 Final Conclusion
12:10 Clickbait?
12:54 Applications of the protected mode
14:27 An interesting story
Edit: this video is the third release! I managed to iron out all problems in the second one, which includes:
1, CRT noise everywhere
2, intro video footages are not muted (you can hear computer noise over the music)
3, 0:55 the (absolutely terrible) B-roll is not muted (You can hear me watching a video about the Mindset computer in the background... I thought it was fine since I could just mute that, obviously I did not...)
4, 1:56 my voice is strangely 'doubled' making me sound like the Borg Queen (this does not happen at all when I'm editing the video! In my editing software the two voices just overlap entirely and become louder)
5, 2:13 that B-roll (and the horrible CRT noise) is not muted
6, 2:45 a weird 'ding' caused by speeding up the video to hide a long blank
7, music is still too loud, but my editing machine probably have a voice enhance feature enabled somewhere too. This problem is much less pronounced on it (and maybe some other computers but probably not all). - Věda a technologie
As a retired IBM engineer who started working in 1980 I am impressed with your ability here, and also in your interest in this topic. I used to wire-wrap 8085 systems together and programmed them using asm, reprogramming them after a short 20 minute erase process using an UV light! Spent most of my career in the bare metal space. You have a bright career ahead of you, my friend.
@MR PawPaw -- OMG, that's the same kind of work I did back in the mid 1980's!
I spent countless hours (including evenings and weekends) writing asm code for the 8085. If memory serves me (no pun intended) the 8085A supposedly had four undocumented op codes which allowed some much-desired operations such as a 16 bit subtract, and I believe a couple of indirect memory access operations (my memory is very volatile!). Unfortunately we programmers were not allowed to use those undocumented op codes because Intel did not guarantee they would work in every new lot of chips they produced. We had to be very clever with our coding because of the limited 65K memory that we had to work with.
I still have factory new z80 cpu, CTC (COUNTER TIMER) AND PIO (Parallel input/output. PLUS my wire wrap guns. I did a lot of work with this chip set.
I started out in 1971, had one of the very first HP RPN calculators, actually held in my hands, one of the original Intel 8008 cpu that was fabricated by Texas Instruments. Too bad I wasn’t as financially smart as I watched, from within the industry, the entire microprocessor revolution. I’d be rich!
Yep... I still own my first computer -- Z80 with 256 bytes of ram. Cassette recorder to save programs via Z80's SIO chip. The terminals at school had a bug in them. I reverse engineered the terminal (8085 based) as well as its code, found the bug, re-blew the EPROM and fixed the issue. All without any test equipment at all.
The 6809 (if I recall correctly) was the most beautiful 8 bit chip I ever saw.
If National had been a year closer to working samples you would have been wrapping 16032 (later rebranded 32032) as the folks in Boca Raton loved it and hated the Intel architecture. But that's coulda woulda shoulda!!
Liar.
You lie about your real name.
You can absolutely do preemptive multitasking without protected memory, it's just a lot less stable since all software has bugs. The Amiga may be the most well-known example of a computer with preemptive multitasking without protected memory.
True
and early macs
@@spakkajack I was going to say that, but early Macs didn't have preemptive multitasking but cooperative multitasking. Correct me if I'm wrong. I have a Mac knowledge gap between System 7.1 and the M1 (-:
@@andrewdunbar828 that is correct
@@andrewdunbar828 The only thing that sort of qualified with Macs was installing an interrupt task. Some programs did this, e.g. MacIntercomm's downloading via interrupt callbacks in the background. It was a niche thing.
I disagree that this is clickbait, because in the end; you achieve protected mode and without a huge amount of external hardware. Very cool.
In the early 1980s a whole UK army signals system used a single Z80 in a shielded casing. Impressive.
I built a phone system using a microcontroller using less RAM and ROM than the Z80 could handle. I had 1.5 KB of RAM and around 30KB of ROM.
Clansman?
@@nsp265 LoL, I do know of Clansman. No, this was a custom built system for a non UK army.
@Tarik B. lol sound chip and vga chip has near nothing to do with either Z80 or PC XT... so im not sure what you are trying to say
@@effexon What do you mean you're not sure? He's just saying dumb shit to diss the PC, obviously.
A protected mode isn't necessary to develop preemptive multitasking. All you need is a clock interrupt that handles task swapping through a scheduler. Once the scheduler has determined what the next eligible task is, it saves the context (stack, IP) of the current task on the task's own stack, restores the context of the next eligible task from the new task's stack, and finally resets the processor Instruction Counter with the new task's saved instruction address. In modern OS, this is done in protected mode, but it doesn't have to be for this mechanism to work.
Some old DOS task schedulers worked this way. Protected mode is more about easying it and creating virtual separated CPU and memory areas with ease for the developer but it must follow a set of strict rules and limitations
Came here to say the same thing. I've built pre-emptive multi-task schedulers for 6502 and z80 hack in the day. Good times :-) Still, he gets full marks for trying.
of course it isn't. it's software -- we can do anything!
Pretty cool how programmers push things to their limits. Technology has made us lazy.
pmode and virtual memory are merely required to _enforce_ the task switching and isolation. If you trust the code you’re running then you can run everything in kernel mode and bypass those isolation mechanisms (e.g. JavaOS, which JITs everything and runs everything in the same address space, with isolation coming merely from the Java memory model and no escape hatch being available)
To be honest I don't consider this kinda format clickbait, as pointed out you delivered well and clarify everything through the process. Nice content, well presented, thank you for sharing.
I second that. Hear hear, good stuff!
Excellent work! You're a very good engineer! I used to code professionally in 8080 Assembly. Also, my father and I wrote the famous Games Pack 1 for the TRS-80 back in '79. We used BASIC with Z-80 assembly subroutines and it was great stuff. Good times. All good wishes.
The first thing I coded that shipped to users was on an 8080 machine. It had a multitasking OS as part of it. In those days one person could know it all.
What games were in the Games Pack? I might have had this!
Awesome 👍
Hey there, @Anton Nym. Looks like we both get around! My first experience on microprocessors was 8008 in a homebrew system, then the 8080. Hand-assembled code for both. Man, were they slow! These tricks of adding Protected Mode, more address space and RAM etc., are cool. I can see it making a very flexible computer. *But it will take slowness to a whole new level.* :/
@@capnzilogCard games like Draw and Stud Poker, Blackjack, Battleship (I think we called it Sea Battle) and a few other games that were not card games. Separately, we wrote the first ever Monopoly game for the Model I. It drew the board, handled the deeds and mortgages, the banking, managed auctions, threw and displayed the dice, handled the chance and community chest cards, and even played against you as a computer opponent. All in 48K of RAM.
z80 was a pleasure to use with its architecture and large instruction set for the time. one thing that sticks in my mind was the companies would put color microphotographs of the chips in their publications and one time i called a distributor to try and get a large one of a z80 to use as a poster. the person answering the phone thought i wanted to use the picture to solve some problem i was having with it, she was like there are better ways, when i wanted it for decoration
Ah those were the days. I remember writing to a number of graphics chip companies in the early days of accelerated Super VGAs trying to get info - nobody was interested except Cirrus Logic, who sent me free (via international post from the USA) a hand written letter and a set of physical datasheets. Years later I contacted Cirrus trying to track down some data sheets after they were out of the graphics business and they were still really kind and helpful. Great company.
I can totally see you being up there with those top-tier you tubers if you started a whole series based on this concept! Start with a breadboard prototype and simple kernel, and work up to a full pcb and multitasking virtualization kernel. I see at least a dozen or more episodes that I think people will really enjoy.
I actually stopped watching a youtuber that switched to click bait titles, i though he changed the content and wanted nothing of it, Like 4 years later i accidentally saw one video and it turns out it was the same good old content, but he just switched to click bait tiles. So yeah, you can be backfiring and alienating your user base seriously doing that. The best youtubers are not in for the money and don't care if they monetize less and honestly do the stuff they are passionate about regardless, and some actually are able to monetize and keep themselves, tho some simply add patreon and other more reliable sources of income, to not fall the death spiral of click baits or obnoxious advertising; some even went to subscription based streaming services which i don't use, so when they start showing half content here and then promise "better" content there, those i also stop watching. It is what it is.
@@freeculture I stopped watching Linus tech techs for similar reason. Went from being geeky/technical nerd seemingly genuinely fascinated by what he's seeing to feeling like someone on QVC or my local news station pushing local products.
Never Go Full Eater!
;-)
@@IdleByte He still has some good content from time to time but yes, I agree.
would be interesting if this was still possible in latter chips like the eZ80; am saying that because their are SBC designs aimed at retro computing hobbist that use this chip (like the Min-eZ or the Agon Light).
A protected mode on the eZ80 would actually be useful as that CPU has 24-bit registers and can address 16MB. That's enough memory to make a pretty reasonable Unix-like muli-tasking OS.
The eZ80 can be clocked up to 50MHz and exectutes several times faster than a Z80 at the same clock speed because of internal pipelining. It's intended to be used only with static memory as that is cheap enough in last few decades. And it does not use internal caching to achieve its performance improvements.
I'm just a software engineer and had to get my dad to watch this video with me. He says that this is ingenious. I subbed. Great video!
Even before the camera zoomed in and out of his CRT monitors I hit the Subscribe button.
Not clickbait. What you showed demonstrated a very solid understanding of 1970s though early 1990s digital logic. Your solution was nontrivial and it is most certainly educational for those that have not worked through similar problems back in the day. Discrete, and even (hand-rolled) lookup digital logic is, imho, becoming a lost art. Thanks for putting it together!
P.S. the first CPU-based machine I designed centered around a Z80. It was a non-trivial, embedded system and decades later, it remains one of my favorite projects (at least, for its time).
It is clickbait. It's a great little MMU implementation, but a non-clickbait title would be something like, "I built an MMU for the Z80."
The current title, "The Z80's secret feature discovered after 40 years!" contains at least one outright falsehood (being able to build an MMU for an 8-bit processor is far from a "secret feature") and probably a second one (it's very likely several people have done something similar in the past, even in the long past; e.g. similar but more sophisticated techniques for were used for Jeff Laughton's 6502-based KimKlone which was built in the 1980s).
@@Curt_Sampson oh no. so sue him. 🤨
@@Curt_Sampson yeah, the “secret feature” part 100% is clickbait- I completely agree. But the video still delivers genuinely interesting and useful information about the Z80 (and other, similar CPUs) for the intended audience, so I support that aspect of it. Yep, it’s an MMU, but if the viewer doesn’t know how one works, on a logic level, or why one might be useful, it’s obviously novel (“secret”) to them. Basically, I see both angles, but I also see no harm.
@@pmcgee003 I'm not going to sue him; it's up to Andy whether he wants to put up clickbait or not. But nor am I going to subscribe, or trust the titles of any videos of his that happen to come up in my feed. I simply don't like channels that don't tell me what I'm getting. I guess Andy will see if turning of folks like me is compensated for by whomever else he gains as viewers from the clickbait.
(Aside from the clickbait , the video had some good stuff in it; I was conflicted about whether to down- or up-vote it.)
@a1nelson Yes, the flip-flop to disable/enable "user mode" is clever. Using just I/O address space to trigger the MMU is reasonable, but certainly nothing special; you could just as well decode an area of memory address space for this. What the video doesn't (but should) mention is that the Z80 I/O address space is basically just a bit of convenient built-in decoding; it doesn't offer anything you can't do on other CPUs that use memory-mapped I/O. Admittedly if you're really trying to minimise chip count it can be handy, but that's when you're talking about 5-6 chip systems and don't want to use a GAL.
And of course there's a lot more to do to get real protection; you need to have a separate bank-switched memory area for each application, you need to switch on interrupts as well, you need a timer interrupt on NMI, and so on. (Much of this is pointed out in the video.) At that point, now that I think about it, having a separate I/O address space makes things no easier at all; in fact this might be easier to implement on a CPU with a single address space, such as 6502 or 6809.
@@Curt_Sampson1. "I'm not going to sue him". Pretty sure it's only in america that someone would feel this isn't obvious. 😉
2. As for "didn't know whether to down vote" .... are you dreaming?
Down voting is an extreme unction resulting from receiving a personal injury from watching the video. "There was some good stuff" is completely incompatible with any consideration of down voting.
3. The thing is, you've told us of your reaction as if we somehow need to know about it.
This was what you needed to get people watching such a great idea and well produced - look forward to seeing the prototype working!
I remember looking through the documentation of the 6800, and I found that the software interrupt instruction created a unique set of signals on the pins, and, as a result, I thought at the time that a simple external circuit could permit adding a supervisor mode to that processor.
Can I ask why you didn't pursue the idea?
Modern Historian. Great explanations as I enjoyed your run through of the chip and its features. We stand on the shoulders if giants that came before us. This helps me appreciate hoe far we've progressed on the last 50 years.
Might be a click-bait video, but it got noticed by the Algorithm. Good Job.
Algorithm is not fair by itself, so not surprising.
When it passes the "not garbage" and "I'm glad I watched it" tests... It's not clickbait, it's inspired.
The clever thing with this video is that most viewers will need to watch it 5 times before they understand it all :) Great work.
I’m on my 6th go and nothing
Very clever indeed. It will take time to digest it while he blows up his channel's views.
Brings back memories, all the cool things we were doing on Z80 and 8080 processors. We did not implement protected mode since there was little need for that, viruses and malicious access were not a thing in conditions we had back then. But things like paging memory into the address space and running CP/M system with multitasking capabilities were there. We also had to write pretty much all the software we used, not like today.
Not to mention that multitasking was an esoteric thing (unless you were on Unix and mainframes), thus in the home computer world protection against other processes wasn't especially relevant.
@@henriksundt7148 - Not that esoteric. In the 80s, the company I worked for, did embedded design, and most of it around a Z80. The company designed its own RTOS. Multitasking came in real handy. We also adapted Forth (the programming language) to the chip, and wrote most of our code in it. We did some complex stuff, around this little 8-bitter.
@@henriksundt7148 Some of it was economics too - Z80 systems were often CPU bound so it made more sense to have several Z80 boxes (possibly sharing an expensive hard disk via CP/NET) than multi-task one of them
Your avatar is insane where is it from
I miss the old days. I loved the way things used to be, simpler.
Awesome video mate!
Didn't think I would see you here.
@@edug1168 My thoughts entirely.
Great video and easy to follow, even though it's been years since I last touched the Z80. Would be very interesting to see your diagram turned into an actual PCB. Do not let the 100k> subscriber count of other channels discourage you. Im looking forward to your next videos.
Be very careful with NMI on Z80. The CPU is not fast and these interrupts can easily swamp the routine code (as you indicated). Anything in NMI must be very brief. How do I know? Multi Z80 control systems design in the 80s. It extended to multi CPU with a shared paged RAM for batching systems (mixers and the like) for animal feed, concrete etc. I also did a coveyor sending system which used an encoder to get the destination. A spring sorter for keyboard spring manufacture and several others in hogh speed use. THAT was a Loooong time ago!
It's interesting to refresh my memory (ha!) as it isn't static like the Z80, by watching your video 🙂
If your worried about the NMI speed then you've entered the realm of real-time programming. A whole of other ball of wax itself and subject of books and maybe another video lol
@@metatechnologist re: " A whole of other ball of wax itself and subject of books"
Yeah ... that's not really going to 'teach' anybody though. Book learning is good to a degree, but NOTHING beats actually doing it, even in prototype stage and then 'learning' the ropes like the rules one learns when doing critical real-time interrupt service routines ...
@@metatechnologist The observation is very relevant and has nothing to do with real-time programming. Setting the hardware up so that every single I/O request generates an NMI is idiotic at best. The processor services an NMI by essentially doing an RST instruction to the fixed address 66H, which takes 11 T-states (clock cycles). The shortest possible NMI routine is an immediate RETN instruction (RETurn from Non-maskable interrupt), which takes an additional 14 T-states. An OUT instruction already takes 11-16 T-states to perform, which means that each OUT is now *at least* 35-40 T-states, and that is without any "protection" code even executed! All I/O will be slowed down by *at least* 3 times.
@@bennylofgren3208 Here's something that will make you cry just.a tiny.bit. Zilog just announced they're ending production of the Z80 this coming summer. It was a good run though. Thanks for responding! Edit: Apparently it's just the 40 pin dip that's going away not the newer embedded versions. But it's still pretty notable!
@@metatechnologist Yeah, I read that too, with some sadness in my heart. I started programming the Z80 in 1979 and as you saw some of it still is still stuck in my head. :) Those were some good days.
My first computer was a TRS-80 and with help from a College professor friend I learned Z80 assembly language on this machine. Thanks for the look back. Sometimes I miss the days of hardware and software hacking to make the computer do things it wasn't intended to do. These days I get my hardware and software fix with Arduino's and Raspberry PI's.
But it's almost impossible to get a pi now
@@nosuchthing8 Really? In the uk they are available.
@@G-ra-ha-m well of course.
@@nosuchthing8 It's disappointing that they have become scarce, I have a few pi 3B+'s and one pi 4 with the pi 3b+'s dedicated to running 3d printers.
@@electronron1 Yes, the Pi400, overclocked to 2.2GHz, is doing a good impression of a pretty usable PC, silent too, they are becoming very capable.
I use an (cheap, small) HDMI to DVI-D adapter which makes older monitors useful too!
Very interesting - thank you! I have programmed the Z80 for almost 40 years, and I still do occasional programming on retro hardware. A great 8-bit CPU.
Keep an eye out for a Cidco Mailstation, quite a fun Z80 email device from 1999.
(CZcams just destroyed deleted my long reply to you on this device)
@@joefish6091 I saw it before it vanished, Joe - thank you. 👍 Will check it out - looks like an interesting device. I'm very familiar with CP/M, so that part interests me.
Aren't the Rabbit microcontrollers really just dressed up Z80s
I designed the Z80 into several systems, but I had no idea about this - Good job Andy!!!
You are forgiven for using a clickbait title. I'm not even a Z80 guy, but this is absolutely amazing!
Edit: I subscribed
I subscribed = inventiveness must be supported, and maybe someday a Moder nized Z80 5nm CPU running at top speed will be commerically available ?
It would have the great benefit of worldwide available, decades of software, hardware, and firmware support - and thousands of people who already know how to program it's now updated and advanced hardware.
@@SeaJay_Oceans Check out the eZ80.
This is entirely over my head, but I'm still impressed that you've solved a 40-year-old hardware mystery!
The Morrow MP-Z80 and the InterSystems XPU-80 for S100 bus had full protected mode and an MMU. It's worth reading the manuals for these devices as actual protected mode on a Z80 is *much* more complicated than this little trick. You have to manage a bogus stack pointer on NMI and all sorts of other stuff (like infinite prefixes).
It's actually much easier to do these tricks on a later 65C02 as you've got vector pull and stuff and I've actually done board designs that provide a very basic protected mode setup. There were also historic 6809 setups for this kind of thing - which are even trickier.
Awesome documentary! I am glad that you are knowledgeable with systems older than the internet. And a nice touch of nostalgia playing Macross in the background. This made me subscribe.
I saw you have less than 1000 subs and was shocked! Great production quality and interesting subject, looking forward to more videos form you!
I had a DEC Rainbow - the beast had a Z80 AND an 8086 and you could boot it into either DOS or CP/M. It was SWEET!
Then there was the DECmate -- A PDP/8 (Intersil 6100) and a Z80 :)
I have not thought about that machine since the maybe’85 when it was provided to me and other financial analysts at my company. I had used the Apple][ and IBM PC and had bought a MacIntosh; and the Rainbow was nice; replacing green lined paper spread sheets and long overdue. We only used DOS; and it was annoying that the 5 1/4” floppy discs though higher capacity at 400 kb were not compatible with the IBM PC 360 kb disks.
Loved this video! I remember how excited I was when I found those undocumented instructions back in the late '80s. I made the core of a Z80 disassembler for my A-level Computer Science project that could disassemble all the undocumented instructions and ran under CP/M. No user interface, though. That was plenty for a teen doing an A-Level! I never really tinkered with the hardware, other than zapping the reset pin on the back of my ZX81 to restart it.
Crikey, the most difficult thing I did on my A-Level Comp Sci project was code a bubble sort routine in visual C++. (I grew up with the Z80 though, having been a Spectrum nerd in the '80's)
@@paulleach3612 I wrote a version of Othello in BBC Basic for my GCSE back in 1992 I think it must have been. I'm certain it was the most awful inefficient code imaginable, but it worked! I was an 80s Speccy kid too but needs must and had to slum it using the Beebs at school!
Great video! It's great to get a bit of technical stuff for us 8-bit CPU nerds without it hurting the pacing of the overall video!
Instant subscribe from me.
Amazing video, I tought it would be boring at the beginning and you managed to awake me up. Congratulations.
I worked at a company in 1993 that used the Hitachi 64180 cpu to create a smart thermostat before anyone had heard of IoT. Awesome chip for the task.
That's pretty cool, which company was that?
What makes it "smart"?
Heya! Do make sure to take care of those drooping AKB Feedback lines on the PVM. If left unattended to, you'll end up with an inoperable monitor.
It's just a few capacitors that have drifted from spec.
if it wasn't for the Z80 i wouldn't be alive right now, thank you Andy.
We always saved before a run, loved this chip and learned assembly on it.
The noise it makes is lovely
I worked at a POS manufacturing company around 2000 and we used an external Xilinx chip to protect Z80 memory ranges and do bank switching. It worked well.
Hey , you have made a super video!!! Super interesting , well done (the boss key idea made me laugh 😂)
Andy, you're the man! Loved the video. It's refreshing to see a vid like this that actually admits what it is and why. Liked, and subed!
Fascinating explanation of the theoretical in application usage.
Thank you for sharing this with us!
I don't know how long you've been on CZcams, but as a first time viewer, I enjoyed this deep dive into the Zed 80's secrets. Thanks! PS: No need to apologize for "clickbait" because it's only unfair if we didn't enjoy it -- I enjoyed it.
Clickbait forgiven. Just don't get addicted to it. :)
BTW, this method around the NMI was used back in the 80s to implement step-by-step debugging. There are some old books describing it.
This was very cool - and well presented with great graphics and explanation. It reminded me a little of the way that the Sinclair ZX80 generated display info, which involved tying A6 on the Z80 to the interrupt so that it would interrupt itself at a specific value of the refresh address register - quirky hardware and software working together. It also took me back to when I wrote a single stepper for a 16 bit processor in the 1980s that interrupted the code under test after every single instruction. It was slow, but got the job done.
This blew my mind. Great job describing such an esoteric topic!
FWIW the ability to implement pre-emptive multitasking does not depend on the presence of a protected mode, millions of embedded systems run a preemptive RTOS on small microcontrollers.
Yes, Intel sold one for the 8080 processor called RMX8080. It would run on their 8020 PCB that you could buy.
And Amigas... :)
@@capnzilog
And QLs
Designing embedded systems 40 years ago, I switched from x86 to Z80 as soon as it launched. The built in RAM refresh, on alternate clock cycles made graphics so easy.
Did you mean the 8080 ? The 16bit 8086 showed up a few years later.
No you didn't. The 8088/8086 (x86) wasn't introduced until 1979, when the Z80 had already been out in numbers for almost three years.
Wow! That's awesome!!
I don't consider it click-bait, because although the title might not be literally exactly accurate, the tech talk you delivered didn't disappoint. Actually probably even more interesting than one could reasonably expect!
Your obvious love for your subject compliments your expertise. More power to you. :)
This is cool and brings back memories for sure. When I started my career, I was exposed to the 8088 and 68000, 68030/40. I enjoyed the 8088 more. It was more fun to work with limited memory ( 64KB), the 8255A and 8259, and EEPROM ( as a commentor before me mentions the 20 minute UV erasure), coding in C (remember K&R?), and ASM. I recall using an editor named Brief, by UnderWare. I had a blast .... but am glad I am retired now.
I enjoyed your video and your enthusiasm.
Memory Mappers - the concept that made the 6502 based NES such a powerful and extendible platform. That decision, as well as the decision to bring out all the I/O lines to the cards were ingenious. That basically allowed you to extend the NES beyond it's physical limitations. You could have as much RAM as you want on your card, and by flipping pages via the mapper you could use that extended RAM very effectively. Many later games did this, including Star Fox. It allowed you to have coprocessors - a few titles did this - and it allows you to store a HUGE program that would never fit in ROM normally and through that page flipping technique bring in executable code from that extended ROM. It's one of the most genius solutions I've seen in 30+ years of computing.
You mean the SNES...
This video was so entertaining and informative. I'm glad I found your channel. I subscribed immediately.
We had a debug board for our Z80 system back in the day. It was much like you just described. It had a ribbon cable to a 40pin plug which replaced the Z80 in the system. It had LED displays for data and address bus, a button for single step and a knob for slow speed running.
I enjoyed this video, it was presented well, good use of humour, and solid technically. Thank you 😊
I like your video. The Z80 is a powerful little CPU, even today.
A couple of things to keep in mind though. On the platform you're demonstrating most prominently, the MSX (thanks for that btw - it is way underrated), the Z80 memory addressing space is divided up into 4 pages of 16kB, each of which can be in 1 of 4 so-called slots. Which page is in which slot is governed by port A of the PPI (8255). In theory, this allows for a total of 256kB of address space without any additional circuitry. The main BIOS and BASIC ROMs are usually in port 0, with RAM and additional ROMs in one or more of the other slots. At least one slot is also taken up by a cartridge interace. For instance, the Philips VG-8020 has its ROMs in slot 0, two cartridge slots in slots 1 and 2, and depending on the specific model 64kB of RAM in slot 3 or in a so-called expanded slot 3-2 (expanded slots are a standard way of increasing the capabilities of the MSX platform even further, and later standards such as the MSX2 standard typically feature at least one expanded slot).
The MSX standard also provides for a so-called memory mapper interface. This interface allows for 1 of up to 256 16kB segments (4MB!) to be selected for a given page in a given (sub-)slot. Any device adhering to at least the MSX2 standard has a memory mapper unit built-in. This is how most non-Japanese MSXes squeeze in more than 64kB of RAM. The Philips NMS-82xx series, for instance, all provide 128kB of RAM in this way, but even MSX2 systems with only 64kB of RAM provide this through a memory mapper. The MSX BIOS in these systems will scan for each and every mapper in the system at boot-up and often, but not always, display the amount of RAM in the largest mapper. Both the MSX BIOS and MSX-DOS 2.x provide memory mapper routines that an application can use to manage this memory. There are a couple of good mapper circuit designs to be found on the world-wide web.
The final thing to take into account is a peculiarity of the Z80 that is not officially documented, but is important to know, especially with the circuit you describe in your video, namely that, in spite of the Z80 being documented as having an 8-bit I/O addressing space, every I/O instruction does in fact assert the entire address bus. For simple I/O instructions such as in A, (imm8) and out (imm8), A it is the contents of the A register, and for more complex I/O instructions such as in reg, (C) and out (C), reg it is in fact the entire BC register.
[The MSX standard also provides for a so-called memory mapper interface. This interface allows for 1 of up to 256 16kB segments (4MB!) to be selected for a given page in a given (sub-)slot.]
That means that, if you put in 64K, you would have 16 MB of RAM?!!!!!
BUILD IT!!!!
@@Atheist7 It means that each page can be set to a specific (sub)slot and to a specific segment in that slot. Think of it as a simple paging mechanism. So, theoretically if you fill each slot with RAM, you could theoretically have up to 16MB of RAM, but then you would not have any room for ROMs, which you will need in order to have a working system. On a typical MSX2 computer with two cartridge slots, you could install a 4MB memory mapper in each of them and have a total of 8MB of RAM, plus the amount of built-in ram. On a NMS 82xx (excluding the 8220), this would amount to a total of 8192 + 128 = 8320kB of RAM. However, then you would not have room for any additional expansion hardware left. So it's a balance between what's practical and what's possible. In my setup, I have one slot in use for a Carnivore 2 (which is a multipurpose device which provides a 1024kB of mapper and a CF card slot among other things) and another for a slot expander, which expands the slot into 4 subslots, each with its own cartridge connector.
@@damouze [So, theoretically if you fill each slot with RAM, you could theoretically have up to 16MB of RAM, but then you would not have any room for ROMs, which you will need in order to have a working system.]
Computers are SOOOOOO baffling.
Can't you give up ONE of the 256 ---> 64K "slots" to put the ROM into?
@@Atheist7 Theoretically? Probably, but that would not be compliant with the MSX standard. With the MSX2 standard and above the picture becomes even more complicated.
For instance, in the NMS 82xx, the MSX BIOS and main BASIC ROMs are put in slot 0. Slot 1 and 2 are typically available as cartridge slots and slot 3 is expanded into 4 subslots, labelled 3-0 through 3-3. Subslot 3-0 contains the so-called SUBROM, subslot 3-1 is "empty" (but not fanned out anywhere), subslot 3-2 contains the 64/128kB memory mapper and subslot 3-3 contains the DISK-ROM with the floppy disk firmware and BASIC.
However, it is possible to fashion a cartridge that internally expands to 4 subslots and then put a memory mapper in each subslot. However, such a device would only work in a primary slot and not in one of the expanded slots of a slot expander (of which each cartridge port would consist of a single subslot). Also, addressing the the so-called mapper register in each subslot would be a big hassle and switching between RAM segments in a page would be painstakingsly slow and involve mapping the slot into the proper page in Z80 address space by programming the PPI, then mapping in the specific subslot in that page and finally mapping the specified segment into that subslot. And there is no guarantee that it would work at all, since some MSX2 computers play fast and loose with the standard, especially where mappers in expanded slots are concerned.
Wow man, where have you been all my life? Incredible skills and video. Please keep it up!
Not really a computer guy but I do enjoy the content from the others you flashed up. You linked to places I can get further context before your video which is rare so good job there. Well presented with good slides and didn't really notice the errors listed. Music could be turned down just a tiny bit but I found it fine. Keep up the good work.
This would have been big news back in the 70s when I was playing with my 8080 and Z80. I think a lot of older engineers will love this! Thanks!
No, you can't virtualize the v99x8, DI & EI do not works for NMI, most game don't include DI EI in fast graphics routines as they works hooked from rst38 anyway, v99x8 has atleast internal 16bits shiftable buffer, by example outputing to 0x99 and then another 0x99 will complete a 14bits address plus mode bit, if you place a third 0x99 and don't complete that output with a fourth 0x99 imagine the state of that buffer address, it will be a mess.
Wow. I have some great memories of coding in Z80 assembly back in 1977 and later. Great video. Keep up the great work!
A wonderful idea Andy. And your sense of humor is appreciated. Please consider a follow-up with a prototype and a logic analyzer. All the levels and timing involved with bench-marking your idea would be helpful to enthusiasts.
Good work. I favoured 6502 back in the day, but the Z80 was also highly adopted.
Nice idea but I believe the NMI signal can't trigger until the currently running instruction finishes, e.g. in that scenario after the IO request that you think you're intercepting... Only then can the processor perform all the logic to "CALL" the NMI routine at 0x0066... And if you consume the IORQ line to feed the NMI how would a peripheral know to accept an IO request? The part that does have some merit is having an MMU and banking out "protected" code and data... One interesting hardware product for the Sinclair ZX Spectrum was a speech synthsizer addon. In hardware it checked for access memory access to the IM1 maskable interrupt memory address, and as soon as there was an MREQ for that address it would assert a control line that mapped it's own ROM or go back to the computer own ROM by using a flip-flop. Every maskable interrupt (50 times a second) the add-on ROM would execute it's own code then jump back to the start of the code and the original ROM would then continue... an MMU circuit can "redirect" memory signals any way you want.... ZX Spectrum 128 did that on a basic level in the mid 80s though not for the reason you give. As for undocumented features, most of them are bugs or just gaps in the decode logic the designers didn't design.
Yup, there is quite a bit of romanticising going on in this video….
Also, the 6809 was generally more favoured to this kind of hardware hackery, which is why it was the preferred choice for 8 bit Unix-like systems. You could almost do a full protected mode, but like the Z80, the synchronous nature of the bus was the principle flaw.
He added a line to block the I/O from really happening by disabling the I/O decoder.
@@kensmith5694 But now there's no IORQ going out to tell IO devices to decode the address bus to actually do any I/O.... And the performance hit is IMMENSE... You waste the 11/12 cycles of the "original" in/out, then it takes the CPU 11 cycles to reach the NMI routine, then you SOMEHOW have to work out what the instruction was while preserving the registers because ANY of the main register set could be involved... Then you have to consider block I/O... Takes 14 clock cycles to come out of the NMI too... Just not practical... Notice too a complete lack of a demonstration of this theory...
@@zombieman81 He is basing the design (in part) on the idea that I/O instructions are rare in real code. In most cases, this is reasonable.
Working stuff out is not a mystery. Once in the NMI code, he can store the registers into the OS's workspace RAM and then grab the return address to go look to see which I/O instruction it was. On the Z80 there are not a lot of them and no, not any register can be involved. Take a look at the instruction set. You get to do I/O with the A register using either an inline constant for the address or the BC register pair.
What he is suggesting is practical for his intended purposes and need not be demonstrated to be studied to see that the idea works.
@@kensmith5694 back in the z80 days this was not reasonable since everything you did was on a port, serial terminal, floppy controller. Doing IO instructions all day long, I'm not convinced this design works as intended but maybe you guys know more than me. That NMI will be after the IO instruction has completed, it may not have been allowed to do anything if the Chip was disabled but it still exectues, then the NMI triggers and you jump to that routine, when its over it returns to the next instruction. What am i missing?
I have goosebumps this is so exciting. So happy to be here on your channel so early! Hope you Share More and More with us, Friend~!
I built a PolyMorphic System 88 computer kit, with a Z80 chip in it.
My first electronics project, when I was still in high school.
Led to a career in electronics.
This brings back good memories.
Thanks for sharing, and best wishes for your continued success.
On the ZX80/ZX81 (my first computer was a ZX80) I have the suspicion that some of the undocumented instructions were used as there were Z80 clones that didn't work in those computers while the original Zilog CPU did work.
One interesting thing with the Z80 is that there's an indirect I/O mode where you can address the I/O through the HL register (if I remember correctly) and the high 8 bits of the HL register is then put out on the upper 8 bits on the address bus. Something that can be used to create an extended I/O addressing range or do a mask read of an 8x8 keypad.
You should also look for the Swedish Luxor ABC80 / ABC800 computers. The former one uses the PIO chip while the latter one uses the Zilog Z80 CTC and SIO. The Monroe OC-8800 computer was also Z80 based with a multitasking OS called OS8MT. That computer had a Z80 DMA and also boasted 128K or RAM.
So now you have something to dive into for the world of Zilog based computers.
Zilog had two kinds of licenses. Some second sources got the physical design. NEC did a licensed redesign from the data sheet, but unlike Zilog they fully decoded the instruction set, as documented. And they filled in the undocumented codes with NOP. So depending on whether your compiler used undocumented instructions, you couldn't always use the NEC chip.
@@drdischord That seems to match my observations wirh the real Z80 and the D780C on the ZX80.
@@ehsnils I learned about second sourcing and licensing in general, when I was working with the Am2901 and Z-80 at an electronic warfare company, in 1979. But I got the specifics on the Z-80 and MC68000 situation when I was working at Motorola a few years later, and I got it in face to face meetings with Zilog and Motorola field support engineers. Zilog's exact physical second sources were Mostek and ST. Second sources for MC68K were Mostek, Signetics, Hitachi, and TI. Each one contributed a peripheral device, but they were all buggy as hell and weren't widely used.
Where can I find that chart at 0:14 showing CPU evolution?
here is where to get the MICROPROCESSOR CHART - www.vgamuseum.info/images/doc/cputree.png
Grear video, Andy! Love to see more from you
Great work, I hope that someone eventually has a go at implementing a system like this, the idea of a system virtualising various different z80 systems would have seemed impossible to my younger self. I guess the peripherals on some of these systems all had their own weirdness, e.g. how screen memory was organised, whether there are sprites etc - but that's another challenge.
For the record, Protected Mode isn't required to support multitasking. OS-9 (Microware, not Apple's BS) ran on 6800's without any Magic(tm). Yes, a misbehaving program could do bad things. (hint: also allowed the debugger to know it was watching itself...) It didn't work on the 6502 because the lack of registers.
Yes! I know what a Z80 is. It still has a place in my heart. It was the first chip I wrote blazingly fast assembly language programs for - when I was 14 year old. I taught myself from a (paper!) book from the library. A magical time for me...
Absolutely brilliant analysis, Andy!
This brought back memories! I. Wrote a lot of Z80 code (embedded communications systems) in the early 80s. Thanks for sparking those memories!
Maybe a dumb question, but just as the 8088 didn't have a protected mode, and the 386 did, why not just use the 16 bit protected-mode supporting version of the z80... like the Zilog z280? It's binary compatible with the z80 even in protected mode ( well, a few instructions missing in protected mode ) and it's z80 circuit compatible too... And has the built in MMU and Cache Memory like a 486, but came out mid 80's.
This is a retro design video. It explain how it COULD have been done with commodity hardware back in the day. Why would one built a new Z80 sytem nowadays from scratch?
Even military equipment goes commodity ARM and/or FPGA today.
@@michaelrenper796 I do understand that, and credit where due, it's a very clever idea to build the missing CPU elements into the hardware, as often happened back in the day. But the z280 also existed back in the day, and had all of this functionality. There really was a z80 that did all of this without needing to externalise it... It would have performed a bit like a 386DX with cache memory, and could have done so in the mid 80s. I guess I'm wondering why, even back in the day, anyone would have created a protected mode z80 when you could just buy a protected-mode-capable z80 off-the-shelf anyway?
@@CJ7Hawk There could be some cost savings using external hw for the few systems that need a protected mode while the majority of systems could be identical except for that circuitry.
With how expensive and limited memory was at the time, multitasking, virtualization, and emulation were probably not in high demand.
@@CJ7Hawk You are right, the time window for this to make sense is very small.
For me and other its the retro aspect here that is fascinating.
Helps understanding microprocessore design basics as I have only theoretical knowledge of modern CPU design and no time and intention to go out tinkering.
@@michaelrenper796 More than several people have built and are planning to build homebrew retrocomputers. The author of this video is one of them as you'll see if you watch some of his other videos.
Andy, every CZcamsr starts small. You seem to have what it takes to get there. I liked your video. Can you just let me know where I can find that cpu history timeline you used at 0:14? Thankx
Ho, and I would really like to see a video from you presenting your collection! You seem to have some very nice computers there!
Came here to ask the same question about the CPU history timeline. First time seeing one of your videos. Very interesting topic.
This is amazing. Thanks for sharing.
Very enjoyable and interesting Andy. No shame in clickbait with content this good. Well done.
I don’t have the EE chops to understand this all fully, but it’s interesting that you feel the MMU can be pretty trivially implemented with a technique similar to a game mapper. I know a lot of computers got kinda hamstrung by the fact that they didn’t implement any kind of MMU, it’s funny if it really was that simple.
Well, MMUs ARE a bit more involved.
Like the MC 68881(?) for the 6809E.
But I like that at least he is THINKING.
MMU means memory *mapping* unit. They both run on the same concepts, but of course modern MMUs have more features.
Have no EE or even electronics tinkering skills, but I'm a software developer and could understand everything just fine. Okay, I already wrote a rudimentary Z80 emulator.
@@metroid031993 In my mind the key distinction between a simple 8 bit styled memory mapper and a proper MMU like the mc68851 is that the page tables are held in main memory and not in the mapper itself. This of course massively ups the complexity of the mappings possible. This is tricky on most 8 bit MPUs which have ridged timing requirements. The other complex thing required is faulting so pages (and tables) do not have to be in main memory at all times.
Well simple and simple. The cartridge mappers were thought of as anything but simple in early 80s(also a simplest mapper is just a bankswitcher anyway)
By the way, this is well produced content on a topic which interests me, and clickbait isn't clickbait if you actually deliver. Subscribed
I don't know how after one year you published this amazing video I got it suggested to me by the Algorythm. This is the type of video that I lime to watch! Good work!
I'm surprised at the sudden uptick in view counts too!
Congratulations to your presentation! Well done!
I fell in love with the Z80 as a teenager. Loved my ZX81 as well. I did a tech project for school where I made a Z80A trainer. Years later I examined an video gaming device where it would switch between running the game and the input devices and had this seperate video board it would switch back and forth with to run to provide the screen output. It seemed over the top to me but that is what it had. For it to generate random numbers it would access the refresh register as a seed. Always thought that was nifty.
Do check out the ZX81 ROM disassembly books, some seriously devious code in there to squeeze every last gram of potential from such a simple circuit.
for newbie, certainly a good video, but the elephant in the room is, did you build it to validate that it works?
I saw this was clickbait early in the video, but I stayed anyway. I’m glad I did.
What a great video. Great work! Some nostalgia for sure.
what exactly is the secret feature discovered? as someone who literally grew up with Z80s and wrote and published my own virt386 machine monitor with EMS emulation (that later ended up in freeDOS IIRC) I don’t get this video. Bank switching was well-known and x286/386 protected mode has dedicated descriptors, a multi-level ring architecture, and the infamous descriptor/segment caches. Can people here help me with that the new thing actually is in this video and what the reference to protected mode means?
Not a lot. Basically wrap the IORQ pin back through to generate an interrupts on IO ops so they can be monitored/changed etc. I don’t honestly see how this is can be called protected mode. But it does seem to have some utility by making it so “user” code can’t generate IO ops directly, though I suspect the performance hit would give it limited practical use.
@@lawrencemanning and there's the question how do you signal real IO if IORQ is fed to NMI... ;)
This IS a clickbait video. Basically "Z80 has a PM" then goes to build shit entirely outside of Z80, using none of Z80 builtin "undocumented" features. Exactly the same thing could be done with 8080, 8086, or 6502 - just setup external memory banking/address capture and hit NMI for some software emulation.
Where did you get that chart shown at 0:15 ?
here is where to get the MICROPROCESSOR CHART - www.vgamuseum.info/images/doc/cputree.png
I never saw your videos before but I really like it. Music is on point! Subbed
Ni hao, Andy. Your attic looks cool a hell. Thanks for the great video!
The original NASCOM-1 used flip-flops, gates, the NMI and one of the RST instructions to implement breakpoints and single stepping. It would drop a RST in place of the orginal opcode at the breakpoint, which would call into the OS, there it would replace the original instruction and arm the flip flops and RETI, raising an NMI after the second M1 cycle (ie. after the stepped to instruction had executed) handing control back to the OS again.
That’s what she said
We need a new version of CP/M now.
amazing job you deserve the growth friend. I love the complete nerd out here. It's about time this blew up
This was an awesome video - I really enjoyed it!
It would be amazing if someone would make a Military Grade Z80A clone chip on 7nm wafer process, with a 64K L1 Buffer so all code and data can run at full speed !
Consider the SGS Z80 6 MHz vs Zilog Z80 4 MHz - the SGS military grade Z80 can work at below freezing and above boiling temperatures: -55°C - 125°C .
Even the Zilog Z0840008PEC runs at 8 MHz and operates at temperature of -40°C - 100°C.
The Z80 isn't memory bound like modern CPUs, it doesn't have to wait for memory to catch up, it's actually "slower" than the RAM in 8-bit micros. That's what allows the video circuits to also access RAM. So code already runs at full speed.
Of course, modern fab technology could speed it up. You can integrate a Z80 into an FPGA at hundreds of MHz. Zilog sell Z80s at around 20MHz. If you really wanted faster, you could go up to GHz with modern tech. Nobody has, though, because Z80s nowadays are used as microcontrollers, integrated into a larger chip, to control hardware, so it just doesn't need to be so fast. If you wanted the power of GHz you'd also benefit from a modern 64-bit chip.
But it would still be cool though!
While there is indeed still systems and code in mil-space targetting the Z80, re-making the old hardware is no longer the preferred approach for maintaining and upgrading those old weapons.
Nowadays people go for FPGAs. More flexible, interchangeable and available. Got this confirmed by somebody working in the space at a conference recently.
So if you have a (sub)-system that has Z80 code and needs an upgrade one would plugin in a FPGA synthesize the Z80 on it and whatever other upgrades are required.
@@greenaum :-) I'm saving my money up for when the first 128 - Bit CPUs get released... Still . . . Waiting . . . :-D
This is not a secret feature but just a clever use of the processor’s NMI capabilities to implement support for a protected mode
10:38
Great video, I’m subbed can’t wait to see more!
This is an awesome video. Brought back memories of a mis-spent childhood playing with ZX81s and spectrums.
I knew the Z80 was a CPU with lots of tricks buried in the silicon, but I hadn't expected some mad engineer to come along and squeeze even more features out of it by now...
Handling a interrupt for each I/O operation will decrease the performance a lot.
It might be better to have an additional bit in the MMU address translation memory indicating if the memory page which is accessed as I/O should cause an interrupt or not
Having learned programming on Z80 computers (TRS 80 and Sharp MZ80k) this totally blows my mind! Andy, You definitely have a bright future ahead 👍
I worked with the Z80 as a student. I was pretty familiar with every register, flag, interrupt, and command of that processor. I never knew about this. I'm impressed. Good job.