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!!
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.
@@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 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.
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.
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.
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)
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.
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.
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 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.
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.
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 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.
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.
@@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!
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.
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.
@@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.
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
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.
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.
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.
Back when around 1980 when Digital Research was working on prototypes of their MP/M operating system, I built a system to test it on out from an Northstar chassis, a 4 MHz Z80 CPU card, 256K of STATIC RAM (4 boards), a quad UART board, and 2 Shugart 13" hard drives using the at the time new "Winchester" technology. My BIOS performed so well that we moved our company's (Micro Data Base Systems) technical typist's terminal over to it permanently. She could sustain 100 wpm; I've never before or since seen anyone like her; and that 4 MHz Z80 system not only kept up with her, but at the same time was running my compilations and assemblies. I have a lot of respect for the humble Z80's capabilities when they are unleashed by good software.
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.
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.
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.
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.
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!
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.
I did not mind your "click bait", very informative and enjoyable and impressed with your ability. Brings back my memories of the early days of microprocessor based electronics.
I don't know how long you've been on RUclips, 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.
Hi Andy. I'm a dinosaur programmer. I'd like to correct a statement made around 2:00 in your video because there was no protected mode, "No MultiTasking". In 1985 I used the QNX operating system. All versions of this OS up to the last 2.21 would run on an Intel 8088 which had no protected mode, but which ran a preemptive, multi-tasking OS which can be virtualized. As you say, it provided no memory protection nor security when run on an 8088. That's not to take anything else away
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!
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.
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.
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.
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.
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.
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.
You've impressed me man. I was programming Z80 assembler in the early 80's. Never imagined something like this. Though I'm not sure what use it may be to us in 2024. But great job anyways.
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.
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)
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.
@@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?
You are right, the Z80 was not designed for personal computers or an O/S that was multitasking in a multi user environment (like a main frame). It was designed to run one program in an embedded system. I always imagined that maybe two Z80s could be used, one for the kernel and one for the users. You seem very versed in the Z80 and I haven't designed with one for decades. Can you see using 2 Z80's to allow protected or supervisor modes along with user modes?
re: "I always imagined that maybe two Z80s could be used, one for the kernel and one for the users. " YOU do know the Z80 has **two** register sets? I used the 2nd set for interrupt handling back when I did a Motorola trunking receiver that handled the incoming trunking control channel 3600 baud data plus control button scan/debounce and LCD display I/O and serial I/O via the Z80 SIO ...
@@uploadJ Yes, it's been decades, I think I called them the base and prime register sets. I only gave it fleeting thoughts to use the Z80 in protected modes. When the Motorola 68040 came out, it became my goto CPU for system and embedded designs at the time. Now, my Raspberry PI is fine my home project needs.
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?!!!!!
@@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.
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.
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.
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!
Nice to see that somebody is still playing with these old toys ;-) Maybe I'll just disappoint you a bit but features you mentioned were known and used back in 80's. Even by commercial products, for instance ZX Interface 1 employs capturing of the rst #8 instruction to remap the ROM page with service routines for the microdrive etc. There were also NMI button peripherals remapping the memory at the same time to allow easy modifications of running code (game cheating). I end up with total 1MB of RAM "tower mounted" (chips soldered on top of others) with 7489 serving as a paging register for both, CPU and ULA independently. It allows significant time savings on loading of programs from cassette tapes (1200 bits/s) as long as no power glitch occurred 🙂
Excellent. Thank you. Allowed me to walk down memory Lane. Exactly 40 years ago in 1982 I was completing one of my 3rd year computer science projects... adding a clock signal to NMI to Z80 CPU in Sorcerer computer to allow for multitasking and wrote a simple multitask OS in Z80 assembler. Of course, not exploring a pseudo Protect mode like you have done so well here... super impressed! I really enjoyed what you did ... the Z80 and the 6809 (dual Program and Data stacks) CPUs are my favourite 8 bit processors (apology 6502). However, the 6809 was too late to the party, a "perfect" chip but 16 bit CPUs were being released and it never got the traction it deserved. Thank you, Andy!!!
Yeah, Motorola effectively shot the 6809 in the head by announcing the 68000 about 9 months before it was available. The 6809 did make it into a number of designs, but with the announcement of the 68000, a number of companies that were considering it for a "desktop" design decided to wait for the 68000. Then GM was allocated the majority of initial 68000 production for ECUs, and the peons had to wait for production to catch up. It's a crying shame, because the 6809 is a seriously cool architecture.
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.
After studying programming in college, in the 1980s, and not quite grokking what was going on, I bought a ZX-81 and started really learning programming. Am enjoying the trip down memory lane and loving learning so much about the beloved Z80 chip. Thanks for clickbaiting me here. :)
I had a ZX80 retrofitted with a EEPROM twice the size. The upper address bit of the EEPROM went to a switch. It could boot in either the ZX80 of the ZX81 code depending on the setting of the switch. I also had a 16K RAM expansion I built myself. Back then this was "hot stuff"
I remember those chips way back in the 1980s ,they used to talk about them and the old "transputers" at colleges until about 2007 as a discussion point during lessons mentioning the history of processors..
Andy, every RUclipsr 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!
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...
I worked a tiny bit with Z-80 systems long after their video-game-box life. I thought the class was so retro for using Z-80s when they were already so old. But looking back, there were probably countless systems still using it, so it was relevant to my line of work. Also looking back, it's important to know where the basics are in order to build upon them.
This is excellent work, very well done! I've done address translation, write protect and no-execute, and multitasking with multiple consoles with the 6502 before, but this IO protection didn't come to my mind. I have to note that reacting on the NMI is not trivial, as you have to analyze what data and address was used from interpreting the opcode executed when the NMI got triggered. That may be easier with the Z80 than with the 6502 due to the Z80's separate IO instructions. Again, very well done!
I have worked on a 1980s system that used the Z80 with it's original chips to protect the room where it was made. But I also worked with Z80 based PCs running CP/M. I can't see why the proposed design wouldn't work with all the features. Key thing is having an external protection bit that is only unlocked by executing an interrupt whose address and code is read only. Then once unlocked, the protected code can adjust other protection features not controlled by the external mode bit. The dual register set can be used to save context for returning to user mode after interrupts (but the content cannot be protected from user mode software), the rule is that the other register set isn't protected across interrupts, making it useless for user mode variables. Alternatively, the interrupt handlers need RAM to save registers. Having page 0 in ROM is an alternative to a soft write protection, but we still need some protected memory for kernel mode state like the list of processes. Use a gate to disable all write protection in kernel mode as a faster solution than doing step by step unprotection on kernel entry.
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.
@@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.
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.
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.
Impressive! What you did is entirely in keeping with how the TRS-80 was used. People were always doing imaginative upgrades--reverse video by adding a NOT gate, using the many ports to control a home security system, using the interference from the system to create music on a nearby radio, putting assembly language programs into character strings and creating fast video games.
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.
In the late’70s Ramtek had a FEP, Front End Processor, to their high end graphic systems" The FEP ran a graphics based BASIC. It was a Z80 with 1/2 Meg of Ram with memory protection and 3 different address spaces, System, User, & DMA.
Holy crap that was a lot of memory back then. I had a couple of bench tech jobs, in the mid '80's, where I would double the 64K memory by stacking 64K mem chips on customer machines. I suppose it could be done with 128K RAM and 256K RAM using an 8080. In came the IBM 286. It changed the world.
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.
Fascinating to see the protected mode of the Z80 being explored after so many years. Although there are already microcontrollers like the ARM Cortex-M0 that can replace it and support multitasking more effectively. Congratulations on the research work and detailed presentation!
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...
You brought back memories of when I programmed a S-100 bus machine with a Z80 running CP/M (had MP/M as well but only ran it briefly to see it working).
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.
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
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.
@@MatthewKanwisher Don't think so (although I don't know Amstrad stuff). Many embedded systems (including some designed by me) of the 1980s and 90s implemented preemtive multitasking on the Z80 and Z180. Even ordinary interrupt routines (used in both embedded and personal computers) are preemtive, strictly speaking. As the process being interrupted for a few ms does not have to know anything about it.
@@MatthewKanwisher Yes, it's cooperative. And an application / process can give the control back to the multitasking manager (Caruh) in case there's nothing to do at the moment. So, it's saving lots of time too. It's not completely preemptive in the classical sense - again to have some gain in speed. 🙂
Not a bad video, even if it *was* clickbait... however, I wanted to add a couple things that you could not know... the Z-80 chip was used in FAR more applications than the consumer market and some of those users did NOT want certain things known and were left "undocumented" and even hidden, unless you worked for those clients. The Z-80 was truly a workhorse far and above some of what was generally known and used by most programmers. Unfortunately there are still some "legacy" systems out there that prevent me from saying any more than that.
Adding hardware memory mapping was pretty common - you mentioned quite a few. Add-on MMU's were also common in mini-computers - for example the PDP-11. Why didn't we see these in 8-bit micros? I think the major hurdle was price - RAM was still relatively expensive, and even the cost of an extra circuit was calculated into the cost of most consumer machines. Until the C64 came along, it was common to see home computers ship with 16K or less RAM, which of course wasn't that useful beyond a demonstration. The Apple ][ could be expanded in various ways thanks to its open slots - the so-called language card was a good example of this. There would have been nothing really stopping someone from expanding most Z80 systems beyond the natural 64K limit and adding protected and maybe even page-swapable memory - but mostly nobody did because by the time it was really possible in price, the world had moved on to other system architectures.
Title of the video: The Z80's secret feature discovered after 40 years! The video: "Is this really a secret Z80 feature that's been hidden for years? No, it's not"
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.
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!
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)
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.
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.
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.
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?
Awesome video mate!
Didn't think I would see you here.
@@edug1168 My thoughts entirely.
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!
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.
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.
(RUclips 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
Technically, it was a 16 bit process er,
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.
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.
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.
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.
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.
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.
I designed the Z80 into several systems, but I had no idea about this - Good job Andy!!!
Back when around 1980 when Digital Research was working on prototypes of their MP/M operating system, I built a system to test it on out from an Northstar chassis, a 4 MHz Z80 CPU card, 256K of STATIC RAM (4 boards), a quad UART board, and 2 Shugart 13" hard drives using the at the time new "Winchester" technology. My BIOS performed so well that we moved our company's (Micro Data Base Systems) technical typist's terminal over to it permanently. She could sustain 100 wpm; I've never before or since seen anyone like her; and that 4 MHz Z80 system not only kept up with her, but at the same time was running my compilations and assemblies. I have a lot of respect for the humble Z80's capabilities when they are unleashed by good software.
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.
This is entirely over my head, but I'm still impressed that you've solved a 40-year-old hardware mystery!
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
My guy this is not clickbait - you have something genuinely interesting here. This is far beyond trying to farm attention.
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.
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.
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.
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!
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.
I did not mind your "click bait", very informative and enjoyable and impressed with your ability. Brings back my memories of the early days of microprocessor based electronics.
I don't know how long you've been on RUclips, 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.
Hi Andy. I'm a dinosaur programmer. I'd like to correct a statement made around 2:00 in your video because there was no protected mode, "No MultiTasking". In 1985 I used the QNX operating system. All versions of this OS up to the last 2.21 would run on an Intel 8088 which had no protected mode, but which ran a preemptive, multi-tasking OS which can be virtualized. As you say, it provided no memory protection nor security when run on an 8088. That's not to take anything else away
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"?
if it wasn't for the Z80 i wouldn't be alive right now, thank you Andy.
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!
Didn't the 48k ZX spectrum have a Z80? ahhh...the good old days of gaming, when it was actually an affordable hobby.
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.
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...
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 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.
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.
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
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.
You've impressed me man. I was programming Z80 assembler in the early 80's. Never imagined something like this. Though I'm not sure what use it may be to us in 2024. But great job anyways.
You and a lot of people. It doesn't have practical use, but it can be made into a fun little computer of 'what could have been'.
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)
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?
We need a new version of CP/M now.
You are right, the Z80 was not designed for personal computers or an O/S that was multitasking in a multi user environment (like a main frame). It was designed to run one program in an embedded system. I always imagined that maybe two Z80s could be used, one for the kernel and one for the users. You seem very versed in the Z80 and I haven't designed with one for decades. Can you see using 2 Z80's to allow protected or supervisor modes along with user modes?
re: "I always imagined that maybe two Z80s could be used, one for the kernel and one for the users. "
YOU do know the Z80 has **two** register sets? I used the 2nd set for interrupt handling back when I did a Motorola trunking receiver that handled the incoming trunking control channel 3600 baud data plus control button scan/debounce and LCD display I/O and serial I/O via the Z80 SIO ...
@@uploadJ Yes, it's been decades, I think I called them the base and prime register sets. I only gave it fleeting thoughts to use the Z80 in protected modes. When the Motorola 68040 came out, it became my goto CPU for system and embedded designs at the time. Now, my Raspberry PI is fine my home project needs.
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.
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.
Hey , you have made a super video!!! Super interesting , well done (the boss key idea made me laugh 😂)
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!
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
We always saved before a run, loved this chip and learned assembly on it.
The noise it makes is lovely
Good work. I favoured 6502 back in the day, but the Z80 was also highly adopted.
Nice to see that somebody is still playing with these old toys ;-) Maybe I'll just disappoint you a bit but features you mentioned were known and used back in 80's. Even by commercial products, for instance ZX Interface 1 employs capturing of the rst #8 instruction to remap the ROM page with service routines for the microdrive etc. There were also NMI button peripherals remapping the memory at the same time to allow easy modifications of running code (game cheating). I end up with total 1MB of RAM "tower mounted" (chips soldered on top of others) with 7489 serving as a paging register for both, CPU and ULA independently. It allows significant time savings on loading of programs from cassette tapes (1200 bits/s) as long as no power glitch occurred 🙂
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
Excellent. Thank you. Allowed me to walk down memory Lane. Exactly 40 years ago in 1982 I was completing one of my 3rd year computer science projects... adding a clock signal to NMI to Z80 CPU in Sorcerer computer to allow for multitasking and wrote a simple multitask OS in Z80 assembler. Of course, not exploring a pseudo Protect mode like you have done so well here... super impressed! I really enjoyed what you did ... the Z80 and the 6809 (dual Program and Data stacks) CPUs are my favourite 8 bit processors (apology 6502). However, the 6809 was too late to the party, a "perfect" chip but 16 bit CPUs were being released and it never got the traction it deserved. Thank you, Andy!!!
Yeah, Motorola effectively shot the 6809 in the head by announcing the 68000 about 9 months before it was available. The 6809 did make it into a number of designs, but with the announcement of the 68000, a number of companies that were considering it for a "desktop" design decided to wait for the 68000. Then GM was allocated the majority of initial 68000 production for ECUs, and the peons had to wait for production to catch up. It's a crying shame, because the 6809 is a seriously cool architecture.
@@JCWren Couldn't agree more! Exactly!
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.
After studying programming in college, in the 1980s, and not quite grokking what was going on, I bought a ZX-81 and started really learning programming.
Am enjoying the trip down memory lane and loving learning so much about the beloved Z80 chip.
Thanks for clickbaiting me here. :)
I had a ZX80 retrofitted with a EEPROM twice the size. The upper address bit of the EEPROM went to a switch. It could boot in either the ZX80 of the ZX81 code depending on the setting of the switch. I also had a 16K RAM expansion I built myself. Back then this was "hot stuff"
for newbie, certainly a good video, but the elephant in the room is, did you build it to validate that it works?
I remember those chips way back in the 1980s ,they used to talk about them and the old "transputers" at colleges until about 2007 as a discussion point during lessons mentioning the history of processors..
Andy, every RUclipsr 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.
Fascinating bit of ingenuity! It's a shame someone didn't figure this out 35 years ago.
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...
I worked a tiny bit with Z-80 systems long after their video-game-box life. I thought the class was so retro for using Z-80s when they were already so old. But looking back, there were probably countless systems still using it, so it was relevant to my line of work. Also looking back, it's important to know where the basics are in order to build upon them.
I enjoyed this video, it was presented well, good use of humour, and solid technically. Thank you 😊
This is excellent work, very well done! I've done address translation, write protect and no-execute, and multitasking with multiple consoles with the 6502 before, but this IO protection didn't come to my mind. I have to note that reacting on the NMI is not trivial, as you have to analyze what data and address was used from interpreting the opcode executed when the NMI got triggered. That may be easier with the Z80 than with the 6502 due to the Z80's separate IO instructions. Again, very well done!
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 have worked on a 1980s system that used the Z80 with it's original chips to protect the room where it was made. But I also worked with Z80 based PCs running CP/M. I can't see why the proposed design wouldn't work with all the features. Key thing is having an external protection bit that is only unlocked by executing an interrupt whose address and code is read only. Then once unlocked, the protected code can adjust other protection features not controlled by the external mode bit.
The dual register set can be used to save context for returning to user mode after interrupts (but the content cannot be protected from user mode software), the rule is that the other register set isn't protected across interrupts, making it useless for user mode variables. Alternatively, the interrupt handlers need RAM to save registers. Having page 0 in ROM is an alternative to a soft write protection, but we still need some protected memory for kernel mode state like the list of processes. Use a gate to disable all write protection in kernel mode as a faster solution than doing step by step unprotection on kernel entry.
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.
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.
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
Impressive! What you did is entirely in keeping with how the TRS-80 was used. People were always doing imaginative upgrades--reverse video by adding a NOT gate, using the many ports to control a home security system, using the interference from the system to create music on a nearby radio, putting assembly language programs into character strings and creating fast video games.
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
In the late’70s Ramtek had a FEP, Front End Processor, to their high end graphic systems" The FEP ran a graphics based BASIC. It was a Z80 with 1/2 Meg of Ram with memory protection and 3 different address spaces, System, User, & DMA.
Holy crap that was a lot of memory back then. I had a couple of bench tech jobs, in the mid '80's, where I would double the 64K memory by stacking 64K mem chips on customer machines. I suppose it could be done with 128K RAM and 256K RAM using an 8080. In came the IBM 286. It changed the world.
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.
Fascinating to see the protected mode of the Z80 being explored after so many years. Although there are already microcontrollers like the ARM Cortex-M0 that can replace it and support multitasking more effectively. Congratulations on the research work and detailed presentation!
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...
Just connecting the /NMI to the input of an OR gate is nonsense. You first of all have to connect it to an output, like you eventually did.
Still a clever hack based on the unique features of the hardware. 👍
You brought back memories of when I programmed a S-100 bus machine with a Z80 running CP/M (had MP/M as well but only ran it briefly to see it working).
Nice video! I don't mind the click-bait!
Thanks a lot!
It's not 'really' a click bait title to people that know the answer already, since they worked on the Z80 from the 1980s ! :-)
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.
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
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.
Multitasking on the Z80 CPU is no problem. You got Caruh for FutureOS on Amstrad CPC for example (and other solutions too). Nice Video. Thanks!
Guessing that’s cooperative multitasking.
@@MatthewKanwisher I'm pretty sure you could do it either way, but you'd need an OS. You couldn't really do it just with the built-in BASIC.
@@MatthewKanwisher Don't think so (although I don't know Amstrad stuff). Many embedded systems (including some designed by me) of the 1980s and 90s implemented preemtive multitasking on the Z80 and Z180. Even ordinary interrupt routines (used in both embedded and personal computers) are preemtive, strictly speaking. As the process being interrupted for a few ms does not have to know anything about it.
@@MatthewKanwisher Yes, it's cooperative. And an application / process can give the control back to the multitasking manager (Caruh) in case there's nothing to do at the moment. So, it's saving lots of time too. It's not completely preemptive in the classical sense - again to have some gain in speed. 🙂
Not a bad video, even if it *was* clickbait... however, I wanted to add a couple things that you could not know... the Z-80 chip was used in FAR more applications than the consumer market and some of those users did NOT want certain things known and were left "undocumented" and even hidden, unless you worked for those clients. The Z-80 was truly a workhorse far and above some of what was generally known and used by most programmers. Unfortunately there are still some "legacy" systems out there that prevent me from saying any more than that.
Adding hardware memory mapping was pretty common - you mentioned quite a few. Add-on MMU's were also common in mini-computers - for example the PDP-11. Why didn't we see these in 8-bit micros? I think the major hurdle was price - RAM was still relatively expensive, and even the cost of an extra circuit was calculated into the cost of most consumer machines. Until the C64 came along, it was common to see home computers ship with 16K or less RAM, which of course wasn't that useful beyond a demonstration. The Apple ][ could be expanded in various ways thanks to its open slots - the so-called language card was a good example of this. There would have been nothing really stopping someone from expanding most Z80 systems beyond the natural 64K limit and adding protected and maybe even page-swapable memory - but mostly nobody did because by the time it was really possible in price, the world had moved on to other system architectures.
Title of the video: The Z80's secret feature discovered after 40 years!
The video: "Is this really a secret Z80 feature that's been hidden for years? No, it's not"
You for making a clickbait video! But I'm glad I watched it great video.
Having learned programming on Z80 computers (TRS 80 and Sharp MZ80k) this totally blows my mind! Andy, You definitely have a bright future ahead 👍
clickbait
I saw you have less than 1000 subs and was shocked! Great production quality and interesting subject, looking forward to more videos form you!