I have been thinking about DMA. I did have have a book on all the CPUs available (this was back in the 70s ... yes I am old) It included the Z80 and its ancillary ICs Including the DMA. The book is long gone , fallen to pieces from frequent browsing. Back to DMA, I seem to remember (not the most reliable start to a sentence) that in addition to memory to memory moves (though, strictly speaking, copying) it also performed input to memory and memory to output transfers and, mysteriously , I/O to I/O transfers (not sure what that would be for). The Z80 accessories where very expensive in those days, so I didn't delve further into the use of DMA. Now, of course, the expensive electronic equipment have thermionic tubes and the ICs are cheap. So, I can now fantasize about DMA. Coupled with banked memory and SD mass storage, I can see that moving data and code from bank to bank (ROM to RAM) and SD to bank and vice versa could DMA looks very attractive. Most of the work in a CPU is moving data, Oh! and dividing.
Interrupt Mode 2 is actually quite powerful, if you use chips that properly support them. Because it takes the CPU right to the start of the right routine without extra work. With a simpler IRQ scheme, you would get one interrupt for your serial port for example. The CPU would then have to figure out what to do, if there is a byte to be read or a ring signal coming in or whatever. But the Z80 compatible peripherals generate individual addresses for each condition. Which means you don't just have a single large interrupt handler, but multiple smaller and faster ones.
Great videos, I just discovered this channel few minutes ago and I'm impressed with the quality and originality of the content like using an Arduino to see how the z80 works. Definitely the UA-cam algorithm sucks, this channel should have been come in my suggested videos years ago
Excellent video. I know it is only intended as an introduction to the issues it covers but the switching of memory banks: was this performed programmatically via system routines (living in a bank that could always be available)? I remember getting my first 64 bit system, I felt the only limit to what I could do with that machine. Then I started to deal with the cost of moving 8 byte variables around (including i/o to and from storage) and don't get me started on cache misses. The attraction of retro computing is curious but understandable on many levels. When it comes to programming the little devils, I suspect it actually the limitations of resources (rather than in spite of) that is the attraction. The creativity required to get a reasonable performance is so much more rewarding than being presented with a virtual plethora of resources in a modern system (if it gets too tough, let the cloud do it). I remember my first 4 bit (yes four) development system, a Hex keyboard and 8 7-segment numbers really did present many challenges . When I graduated to a Model II TRS-80, I was in 7th heaven. Ok, you have a new subscriber .
I have been thinking about DMA. I did have have a book on all the CPUs available (this was back in the 70s ... yes I am old) It included the Z80 and its ancillary ICs Including the DMA. The book is long gone , fallen to pieces from frequent browsing. Back to DMA, I seem to remember (not the most reliable start to a sentence) that in addition to memory to memory moves (though, strictly speaking, copying) it also performed input to memory and memory to output transfers and, mysteriously , I/O to I/O transfers (not sure what that would be for). The Z80 accessories where very expensive in those days, so I didn't delve further into the use of DMA. Now, of course, the expensive electronic equipment have thermionic tubes and the ICs are cheap. So, I can now fantasize about DMA. Coupled with banked memory and SD mass storage, I can see that moving data and code from bank to bank (ROM to RAM) and SD to bank and vice versa could DMA looks very attractive. Most of the work in a CPU is moving data, Oh! and dividing.
Looking forward to the DMA video.
Interrupt Mode 2 is actually quite powerful, if you use chips that properly support them. Because it takes the CPU right to the start of the right routine without extra work.
With a simpler IRQ scheme, you would get one interrupt for your serial port for example. The CPU would then have to figure out what to do, if there is a byte to be read or a ring signal coming in or whatever.
But the Z80 compatible peripherals generate individual addresses for each condition. Which means you don't just have a single large interrupt handler, but multiple smaller and faster ones.
I love all your technical videos. Thank you. even the Solar DIY project. :)
Love your presentation style, and really enjoying the videos.
Great videos, I just discovered this channel few minutes ago and I'm impressed with the quality and originality of the content like using an Arduino to see how the z80 works. Definitely the UA-cam algorithm sucks, this channel should have been come in my suggested videos years ago
Excellent video. I know it is only intended as an introduction to the issues it covers but the switching of memory banks: was this performed programmatically via system routines (living in a bank that could always be available)? I remember getting my first 64 bit system, I felt the only limit to what I could do with that machine. Then I started to deal with the cost of moving 8 byte variables around (including i/o to and from storage) and don't get me started on cache misses. The attraction of retro computing is curious but understandable on many levels. When it comes to programming the little devils, I suspect it actually the limitations of resources (rather than in spite of) that is the attraction. The creativity required to get a reasonable performance is so much more rewarding than being presented with a virtual plethora of resources in a modern system (if it gets too tough, let the cloud do it). I remember my first 4 bit (yes four) development system, a Hex keyboard and 8 7-segment numbers really did present many challenges . When I graduated to a Model II TRS-80, I was in 7th heaven. Ok, you have a new subscriber .
Excellent interesting content but the background music is way too loud, fast and distracting making it difficult to watch.
It's not too bad on my mobile, but I do agree that it's a bit superfluous. The spoken content is good enough on its own merits :)
I quite liked the background music. Did not get in the way for me.
@@robingrosset6941Very good bgm. Do you know the names of them?