In other contexts I ran over the term NOP slide as in creating a larger entering address space for a following routine, but using it as a cycle perfect delay is brilliant. The sport of getting things to work with a absolute minimal hardware is an art on it's own. This has to be among the densest knowledge transfer on yt. Absolutely love it. And an appropriate cliff hanger, well played.
So, as per my previous comments, I already understood how the ZX80 generates the display. BUT, I have to complement you on the way you're explaining this. You're not just showing us how it works, but you're taking us on the journey from first principles (in Z80 terms) and showing how the final implementation can be developed by means of several incremental improvements in memory usage and efficiency of the hardware. Just fascinating! Thank you.
Great glad you like it. There is so much detail in the original ZX80/81 design (despite how simple it looks) that i wanted to unpack each piece and look at it in isolation.
Properly cunning. Good explanation but I did have to rewind a few times to make sure I understood some of the steps. Makes me glad I had a TRS-80 back in the day as it was so much easier to understand.
Enjoy. Yep don't be afraid to watch them a couple of times. If it were a real life lecture, i'd probably spend an hour on it and go over more exameples, but hour long YT videos tend to get 0 views.
This brings back memories as I grew up with the ZX81 a couple months after it came out. Even got a few programs published in Sinclair User and a couple other magazines from the day.
@@DrMattRegan that's the plan. I did have JLC make up some repo ZX80 boards but I've had a lot of trouble getting them to produce a video signal at all, the video it so dependant on everything else working it's hard to diagnose. I've been working on an Apple 1 compatible here in a similar way, building the video and terminal side of things up to replace the unobtainium chips of the original. Are you planning on doing the audio in/ out for this project for writing to tape.
Wow! This is a perfect example that constraints are an excellent way to stimulate the imagination and ingenuity. I never had the chance to use the ZX80. (we had a TRS80, then an apple II). I might have to buy/build one. You are (again) great at explaining how it works.
The Z80 I/O cycle actually uses A0-A15 rather than just A0-A7. Indeed the ZX80, ZX81 and ZX Spectrum use this in their keyboard scanning code. Ideally Zilog should have used IN (BC),A rather than IN (C),A for instruction ED 78 The Z80 was designed to be binary compatible with the Intel 8080. At least in terms of documented opcodes. The undocumented ones, which on the 8080 are simply duplicates, being repurposed for additional instructions and/or instruction prefixes. Back in 1976 Zilog didn't ma,ke this difference between the Z80 and 8080 especially clear. Though the current edition of the data book does. In the case of the two I/O opcodes present on both the 8080 and Z80, D3 & DB, on the 8080 A8-A15 are undefined whilst on the Z80 they contain the current contents of the A register.
@@DrMattRegan , yes 1000%. I invented that trick to save bytes in my 1K games. The display will display spaces until time has passed to update the screen. So a JP (HL) after the 9th HALT will give a 8 lines screen.
@@DrMattRegan , I use the others to store data on the screen and still show a large screen without the cost of bytes. My snake has info about taildirection, minesweeper about the mines etc....
Dear DrMattRegan, at min 4.30 it's said "Z80 can't tell the difference between 2000H and 8000H"... I think it's not correct because mirror address of 2000H is A000H, isn't it? However your video series is a masterpiece!👍
Yes, correct. I think i misspoke. 0x2000 will be mirrored at 0xA000, good pick-up. Unfortunately i can't modify the video, but hopefully people will read this comment.
I hate HEX. Growing up with the ZX81 and the ZX Spectrum was great, but I did'nt have access to books or magazines for about the first 4 years, even then it was BASIC type-ins, so I am totaly self taught through reading the manuals and breaking into software on tapes. As HEX is'nt native to these machines, I dealt exclusively in decimal. And I still do. I understand it better.
Great feedback. This channel is meant for the self taught!. Hex is tricky, but think of it as being a compact version of binary. When you're debugging hardware, it's tricky to remember a binary number, but you can read HEX directly off the pins of chips.
@@DrMattRegan I don't know how to do that as I have no understanding of HEX. I did'nt bother to learn it, and at 55 going on 56, I fear it's too late to learn. (and if maths are involved forget it. I went to after school maths classes to try to understand maths. After 2 weeks the teacher gave me an F- and we both gave up. He was a great teacher. I could'nt be taught.)
Fair enough, but if you simply memorize this table en.wikipedia.org/wiki/Nibble#Hexadecimal_representation and apply it to each 4 bits at a time. The 16 bit address bus will have 4 hexadecimal digits and the 8 bit data bus will have 2 hexadecimal digits, always. Generally, when debugging i don't convert back to decimal, unless forced to.
@@DrMattRegan it extends the number of inputs and outputs from 256 to 65526 they should have used a TMS9918 Graphics Processor like in the MEMOTECH MTX512 plus a heat sink for the TMS9918.
For OUT, either you have 256 ports with 256 values per port or 65536 ports with 1 value per port correct? Same amount of information either way. For In it looks like you can use 65536 addresses. The ZX80/81 only you 1-2 ports, so i'm not quite sure i see the point.
![[ ออกกอง ] วัยหนุ่ม 2544 โลกหลังลูกกรง..ทัวร์กองถ่ายหนังใน "คุกของจริง" | JUSTดูIT.](http://i.ytimg.com/vi/vB--aOkZCpw/mqdefault.jpg)
In other contexts I ran over the term NOP slide as in creating a larger entering address space for a following routine, but using it as a cycle perfect delay is brilliant. The sport of getting things to work with a absolute minimal hardware is an art on it's own. This has to be among the densest knowledge transfer on yt. Absolutely love it. And an appropriate cliff hanger, well played.
Excellent, glad you're enjoying it. I'm working on the next video now.
So, as per my previous comments, I already understood how the ZX80 generates the display. BUT, I have to complement you on the way you're explaining this. You're not just showing us how it works, but you're taking us on the journey from first principles (in Z80 terms) and showing how the final implementation can be developed by means of several incremental improvements in memory usage and efficiency of the hardware. Just fascinating! Thank you.
Great glad you like it. There is so much detail in the original ZX80/81 design (despite how simple it looks) that i wanted to unpack each piece and look at it in isolation.
@@DrMattRegan And you're doing it very well indeed.
Properly cunning. Good explanation but I did have to rewind a few times to make sure I understood some of the steps. Makes me glad I had a TRS-80 back in the day as it was so much easier to understand.
Enjoy. Yep don't be afraid to watch them a couple of times. If it were a real life lecture, i'd probably spend an hour on it and go over more exameples, but hour long YT videos tend to get 0 views.
I would always love more... lol. Thank you for the edutainment you give us all! ❤
You are so welcome!
Having never considered how the ZX80 video works, my mind is blown, particularly this 'compression' trick. Thank you for creating this series. :-)
Glad you like it. It's a pretty cool little circuit.
This brings back memories as I grew up with the ZX81 a couple months after it came out. Even got a few programs published in Sinclair User and a couple other magazines from the day.
Excellent, i remember typing programs in from the magazines.
I'm really enjoying this series. I've ordered some big old perf board to try my own..
Have fun! I'd recommend you bring it up in stages, i think it's more fun that way.
@@DrMattRegan that's the plan. I did have JLC make up some repo ZX80 boards but I've had a lot of trouble getting them to produce a video signal at all, the video it so dependant on everything else working it's hard to diagnose.
I've been working on an Apple 1 compatible here in a similar way, building the video and terminal side of things up to replace the unobtainium chips of the original.
Are you planning on doing the audio in/ out for this project for writing to tape.
Yeah, audio in /out should work, but i haven't tested them yet
Wow! This is a perfect example that constraints are an excellent way to stimulate the imagination and ingenuity. I never had the chance to use the ZX80. (we had a TRS80, then an apple II). I might have to buy/build one. You are (again) great at explaining how it works.
Thanks for the feed back. It's such a dense and compact design, it really makes the Z80 work.
Спасибо, отличное видео.
Thanks, enjoy!
*Superb!*
Glad you enjoyed it!
Slight inaccuracy: If OUT (C), A or IN A, (C) are used, the B register is put on the top half of the address bus, giving a full 64k of I/O space
Yes, I think I cover that later when talking about the keyboard.
I remberd that HALT was code for NEW LINE (it was ZX81 thing ?)
The Z80 I/O cycle actually uses A0-A15 rather than just A0-A7. Indeed the ZX80, ZX81 and ZX Spectrum use this in their keyboard scanning code.
Ideally Zilog should have used IN (BC),A rather than IN (C),A for instruction ED 78
The Z80 was designed to be binary compatible with the Intel 8080. At least in terms of documented opcodes. The undocumented ones, which on the 8080 are simply duplicates, being repurposed for additional instructions and/or instruction prefixes.
Back in 1976 Zilog didn't ma,ke this difference between the Z80 and 8080 especially clear. Though the current edition of the data book does. In the case of the two I/O opcodes present on both the 8080 and Z80, D3 & DB, on the 8080 A8-A15 are undefined whilst on the Z80 they contain the current contents of the A register.
True, i wanted to keeps the explanation simple, but i'll go over it again when i get to the keyboard.
The smallest zx81 screen is an empty screen and in size only 1 byte: JP (HL)
Really, i know the ZX80 needs 25 halts for a stable screen.
I'm still going over the ZX81. But are you sure that is correct for slow mode?
@@DrMattRegan , yes 1000%. I invented that trick to save bytes in my 1K games. The display will display spaces until time has passed to update the screen. So a JP (HL) after the 9th HALT will give a 8 lines screen.
Due to the bit 6 as activator for opcodes you display spaces on the screen and hide data with opcodes like LD B,B LD C,C etc.
Correct, there are a limited number of opcodes available when the NOP generator is active. I think they only use HALT which has an opcode of 0x76
@@DrMattRegan , I use the others to store data on the screen and still show a large screen without the cost of bytes. My snake has info about taildirection, minesweeper about the mines etc....
@ 13:07 I see SET 3,C but the text says B=0x08, is this a mistake?
Good video BTW
Well, spotted, it should be SET 3,B. It was on my list of fixes before i published it, but i forgot to fix it.
@0:53 It has 65536 I/O adresses but software and hardware must use it properly.
Correct, i do address this in a later video on the keyboard
Dear DrMattRegan, at min 4.30 it's said "Z80 can't tell the difference between 2000H and 8000H"... I think it's not correct because mirror address of 2000H is A000H, isn't it? However your video series is a masterpiece!👍
Yes, correct. I think i misspoke. 0x2000 will be mirrored at 0xA000, good pick-up. Unfortunately i can't modify the video, but hopefully people will read this comment.
I hate HEX. Growing up with the ZX81 and the ZX Spectrum was great, but I did'nt have access to books or magazines for about the first 4 years, even then it was BASIC type-ins, so I am totaly self taught through reading the manuals and breaking into software on tapes. As HEX is'nt native to these machines, I dealt exclusively in decimal. And I still do. I understand it better.
Great feedback. This channel is meant for the self taught!. Hex is tricky, but think of it as being a compact version of binary. When you're debugging hardware, it's tricky to remember a binary number, but you can read HEX directly off the pins of chips.
@@DrMattRegan I don't know how to do that as I have no understanding of HEX. I did'nt bother to learn it, and at 55 going on 56, I fear it's too late to learn. (and if maths are involved forget it. I went to after school maths classes to try to understand maths. After 2 weeks the teacher gave me an F- and we both gave up. He was a great teacher. I could'nt be taught.)
Fair enough, but if you simply memorize this table en.wikipedia.org/wiki/Nibble#Hexadecimal_representation
and apply it to each 4 bits at a time.
The 16 bit address bus will have 4 hexadecimal digits and the 8 bit data bus will
have 2 hexadecimal digits, always.
Generally, when debugging i don't convert back to decimal, unless forced to.
@@DrMattRegan Strangely, I can convert 8 bit binary to decimal rather quickly. I don't know how I do it, it just seems to happen. I'm odd. LOL.
can you not do ...
LD A,LOW_BYTE
LD L,A
LD A,HIGH_BYTE
LD H,A
LD DE,HL
IN A,(DE)
LD RET_BYTE,A
RET
Hmmm. Not quit sure why you would do it that way. We are tight on clock cycles and LD HL,mm takes 10
@@DrMattRegan it extends the number of inputs and outputs from 256 to 65526 they should have used a TMS9918 Graphics Processor like in the MEMOTECH MTX512 plus a heat sink for the TMS9918.
For OUT, either you have 256 ports with 256 values per port or 65536 ports with 1 value per port correct? Same amount of information either way. For In it looks like you can use 65536 addresses. The ZX80/81 only you 1-2 ports, so i'm not quite sure i see the point.
@@DrMattRegan Yes AMSTRAD was doing this on the CPC6128 and on the PCW Office machine.