Fantastic demo for Z80 programming and integration to actuality electronics !! What kind of video display processor chip do you sintetize with FPGA ?? Texas TMS ?? Thanks !!!
What do you mean by "the VGA palette"? In VGA you can set your own colors in a 256 color palette as RGB with 6 bits for each channel (not 8 bit like modern computers) making it possible to select 256 colors of 262144. Impressive work, btw!
Thank you for your comment! I tool a shortcut, I meant (and should have said) the "Mode 13h" palette. In the future, I would like to add this feature to my video card implementation too: customize the 256-color palette, where each color can be 16-bit (565RGB).
Do you think it would be possible to interface your board with a Compact flash card with the 40 pin extension port? I think it would be cool to build a DOS like operating system so you could develop software on the board directly.
Thanks for your comment. I have already planned to make a CF card extension board (I have already bought a 64MB one with an SMD socket), it should not be a problem. Regarding the OS, you also guessed right, I am developing an operating system which will be able to run text/code editor, a Z80 assembler and/or higher-level langages, so definitely, my goal is to have an OS that will also make Zeal a development platform
Could you make a video that describe the graphic capabilities in details? Here you have constants and code that suggest more complex elements - like more then 1 layer, Also you have 1byte in the tilemap, and only 7 bits as index, do you plan to add more bits for H/V-flip. Also if you add more VRAM you can increase the index size to 8-10 bits Also I didn't understand is it possible to change the colors in the palette? If so what is the RGB resolution like 444, 555, 666,...?
I plan on describing the graphics in details as soon as the implementation is finalize. I haven't implemented custom (4-bit & 8-bit) palettes yet, so at the moment, it's not possible to change the colors, but it is planned! The resulted colors would be 16-bit, in 565 format. I am only having 7-bits as index becuase of the lack of VRAM I have in that Altera FPGA. In fact, I have at most 128 tiles. I have changed my FPGA already, I now have more VRAM, I am now able to use all 8 bits as an index. So, we have 256 tiles. I will now also be able to implement sprites. The sprites will have attributes for H/V flip. Tiles don't have attributes. It would be possible to add some, but it would require another attribute array (like the sprites), or 16-bit indexes, in both cases it means more CPU time to setup a tile. Indeed, there is no DMA on the board so all the writes to VRAM must be done by the CPU. In any case, I may consider adding attributes to tiles if time allows
@@Zeal8bit Excellent, I'm looking forward! Thank you in advance for 565 RGB :) If you add 4bpp then you will be forced to extend the tilemap to 16bit, because you will need extra 4b for selecting a palette (to cover all 256 colors). So why not add 2 bits for H/V-flip. And you will have 10 bits for a tile index. P.S. I would strongly suggest to not use real 640x480, rather doubled 320x240. That will reduce 4 time the VRAM requirement and CPU overload. This also will allow you to use 8x8 tiles instead 16x16 and this has so many benefits. Ideally you might even allow the developer to chose 8x8 or 16x16.
@@SquallSf I was thinking, at first, to have a single 4-bit palette for all the sprites in 4pbb mode. When optimized properly, 16 colors is already pretty good. I am wondering if having 16 palettes of 16 colors will bring a lot to the final implementation considering that it's already possible to have 256 colors. Again, I put myself in the hardware implementation side, not software side😄 The reason I would like to avoid 10/12-bit indexes (and prefer 16-bit) is that I would like to be able to modify a single tile data without modifying the neighbour's. If we use 10-bit indexes, we would have to read (from VRAM/RAM/ROM) the word containing the highest 2 bits of the 10-bit index, modify these bits only and then write them on the bus to the VRAM. Similarly, modifying the neighbour's would mean modifying the higher 6 bit only. Shifts/masks are a bit of a pain on the Z80 as only the accumulator can perform them and it's only possible to shift 1 bit at a time. Thus, it would be faster to use 16-bit indexes. Another possibility would be to have all the extra bits (let's call them attributes) in a different array, that would be a good tradeoff. You have already guessed what I am working on. I have already implemented 320x240 (double pixel) for the text mode. I will continue by implementing it for graphics mode. Both will be available at the same time. It will be possible to switch between both resolution thanks to a single write on the I/O bus. 640x480 is very handy for text mode as we get 80 columns! For graphics mode we have a 40x30 tiles mode which would let us have HUD on games, without hidding too much the "playground". But again, up to the developer to choose the resolution that will fit him better. At the moment, I have only planned to support 16x16 tiles for both modes.
@@Zeal8bit Yes the visual difference between having 1 pal with 16 colors for all 4bb and selecting 16 pals with 16 colors is huge, almost like watching EGA and VGA graphics :) What I mean by 10 bit index is that your tile-map 40x30 consist of 16 bit values. Inside you have 4 bits for palette selection, 2 bits H/V - flips and 10 bits for tile index. This way every new entry in the map will start on every second byte. That is (almost) how SNES is, the VERA that I mentioned, ... It is easy to manipulate. P.S check this out: th-cam.com/video/BUE3dVsew0w/w-d-xo.html every sprite uses its own 4bpp palette. Imagine it if they all share the same palette :) The VERA also uses 2 bytes (16 bits) for the tile maps. It is fast and easy enough.
@@SquallSf Oh my bad! My question was poorly formulated...Of course 1 palette vs 16 palettes differs a lot 😄 I meant, I wonder if having 16 palettes of 16 colors differs a lot compared to having 256 colors directly (16 palettes 4bpp vs. 1 palette 8bpp). In any case, it's a good idea to have multiple palettes for 4bpp, I will add this to my to-do list😉
You talked a lot about the software side of things but I've wondered how the vram works. For example. In Ben Eater's "world's worst video card", the reason for its name is that it wastes 71% of the the time wait stating the cpu while it transfers data from the vram to the screen and the cpu can only operate during screen blanking - when data isn't being transferred from vram to the screen. This is obviously a very bad way to make a video card but it was the industry standard for many years just because overcoming this design issue is relatively difficult. The easiest way to get around this issue is to have 2 banks of vram between 2 ram chips. Or 2 "pages" if you will. 1 page is accessible by the vga port at all times, the second page is accessible by the cpu at all times. You can switch which bank is being displayed on the monitor and which bank is accessible by the cpu at any time. The main disadvantage of this method is that you need 2x as much vram for this to work but at least using it doesn't slow down the cpu. Designing a video card that doesn't have the issues of the "worlds worst video card" and is better than a bank switched buffer card is difficult. However this approach seems to be what you did here. All I can make out on the video card is 1 fpga, (two?) spi eeproms, enough resistors to probably output 16 bit color and 5 chips near the expansion port that could be anything including ram, bus transceivers or discrete logic chips. I would think one of the better ways of implementing this would involve a 4kb or so vga buffer to buffer data between the vram and the vga port but judging by the placement of chips, that's probably not what you did. so lol how does this work? Do you have a block diagram somewhere?
Sorry for the very late reply! Your question is very interesting, and indeed I haven't explained it a lot here (I did explain more on Discord). As you said, one problem I wanted to avoid is memory contention between the CPU and the FPGA, I also wanted to avoid allocated a part of the motherboard's RAM for video. As such, the easiest and best solution for me was to use another RAM for the video. It's not a dedicated chip though, it's the FPGA RAM itself. I choose this FPGA because it has ~120KB of BRAM. I use this BRAM for storing the tilemap, the tileset, the characters pixels and the palettes (I'll also use some for the sound and SD card). Moreover this BRAM can be used in a dual-port configuration, which is what I used. Used in a 4-stage pipeline, I am able to natively output 640x480 pixels at 60Hz independently from the Z80. This dual-port configuration also lets the Z80 write a byte in it while the FPGA is reading from it for output. Overall, this gives me two separate RAM: one for the FPGA, one for the Z80, no more contention. The Z80 is free to use its whole 512KB of RAM. Of course, the VRAM must be mapped to the physical address space so that the Z80 can virtually map it and write to it (tilemap, tileset, palettes, etc...)
How would you recommend handling scrolling, given that the video ram is read only (although you may have changed that in an earlier video, I'm not sure)
Thanks for your comment! You guessed right, I changed it in a previous video: the one talking about CP/M. I implemented an MMU, which can address 22-bits/4MB of physical RAM. It will be possible to read back the VRAM. However, I am also considering implementing hardware scrolling. I already did it for the text mode, it's possible to scroll text-line by text-line (each text line is 12px height), this is what the monitor uses currently. For the graphics mode, scrolling would make sense if it can be done pixel by pixel.
Thank you for your comment! I do plan to sell them, ideally, as a finished product, something ready-to-play. But I am also considering making kits as some people also informed me they would like the possibily to have it as a PCB kit. Out of curiosity, what would you prefer?😄
Thank you for you comment! Indeed, I use Linux for all the tools: GIMP, python, xxd, z88dk, ghex, serial monitor, minipro, etc... Nothing for convenient than Linux for this 😄
Hello @Programador Visionario, at the moment, everything is explained in the videos as I haven't finalized the board and the software. Once they are finalized, I will start making a proper documentation
it's very impressive what you have made. do you plan to make it more user friendly by implementing a program language? haha - basic would be nice for a retro computer
Thanks for your comment! Currently, the OS supports assembly and C, I also wrote a text editor and an assembler, to code directly on the Zeal 8-bit Computer. I plan to implement a more user friendly language, maybe BASIC, but that's not my highest priority since I still have some drivers to implement. But if anyone is willing to help, I would be happy haha
Is it possible to show FOGA code you are making in details please? It would be very interesting to see, how all that works under the hood, sprites, memory organization, practically everything. I have seen very few videos of that kind.
![Rare 8-bit computer from China review! [SB-2000]](http://i.ytimg.com/vi/kp4Rr7CJBAI/mqdefault.jpg)
![Rare 8-bit computer from China review! [SB-2000]](/img/tr.png)
you wrote fluently Z80 assembly language! BTW, very useful and interesting website ;D
haha, thank you, as you can see, the code isn't too difficult😄
Fantastic demo for Z80 programming and integration to actuality electronics !!
What kind of video display processor chip do you sintetize with FPGA ?? Texas TMS ?? Thanks !!!
Thanks for your comment!
It's a custom display processor I made myself. I am not emulating any existing one.
What do you mean by "the VGA palette"? In VGA you can set your own colors in a 256 color palette as RGB with 6 bits for each channel (not 8 bit like modern computers) making it possible to select 256 colors of 262144.
Impressive work, btw!
Thank you for your comment!
I tool a shortcut, I meant (and should have said) the "Mode 13h" palette.
In the future, I would like to add this feature to my video card implementation too: customize the 256-color palette, where each color can be 16-bit (565RGB).
Do you think it would be possible to interface your board with a Compact flash card with the 40 pin extension port? I think it would be cool to build a DOS like operating system so you could develop software on the board directly.
Thanks for your comment.
I have already planned to make a CF card extension board (I have already bought a 64MB one with an SMD socket), it should not be a problem. Regarding the OS, you also guessed right, I am developing an operating system which will be able to run text/code editor, a Z80 assembler and/or higher-level langages, so definitely, my goal is to have an OS that will also make Zeal a development platform
@@Zeal8bit Sounds great!
Could you make a video that describe the graphic capabilities in details?
Here you have constants and code that suggest more complex elements - like more then 1 layer,
Also you have 1byte in the tilemap, and only 7 bits as index, do you plan to add more bits for H/V-flip. Also if you add more VRAM you can increase the index size to 8-10 bits
Also I didn't understand is it possible to change the colors in the palette? If so what is the RGB resolution like 444, 555, 666,...?
I plan on describing the graphics in details as soon as the implementation is finalize. I haven't implemented custom (4-bit & 8-bit) palettes yet, so at the moment, it's not possible to change the colors, but it is planned! The resulted colors would be 16-bit, in 565 format.
I am only having 7-bits as index becuase of the lack of VRAM I have in that Altera FPGA. In fact, I have at most 128 tiles. I have changed my FPGA already, I now have more VRAM, I am now able to use all 8 bits as an index. So, we have 256 tiles. I will now also be able to implement sprites. The sprites will have attributes for H/V flip. Tiles don't have attributes. It would be possible to add some, but it would require another attribute array (like the sprites), or 16-bit indexes, in both cases it means more CPU time to setup a tile. Indeed, there is no DMA on the board so all the writes to VRAM must be done by the CPU. In any case, I may consider adding attributes to tiles if time allows
@@Zeal8bit Excellent, I'm looking forward! Thank you in advance for 565 RGB :)
If you add 4bpp then you will be forced to extend the tilemap to 16bit, because you will need extra 4b for selecting a palette (to cover all 256 colors). So why not add 2 bits for H/V-flip. And you will have 10 bits for a tile index.
P.S. I would strongly suggest to not use real 640x480, rather doubled 320x240. That will reduce 4 time the VRAM requirement and CPU overload. This also will allow you to use 8x8 tiles instead 16x16 and this has so many benefits. Ideally you might even allow the developer to chose 8x8 or 16x16.
@@SquallSf I was thinking, at first, to have a single 4-bit palette for all the sprites in 4pbb mode. When optimized properly, 16 colors is already pretty good.
I am wondering if having 16 palettes of 16 colors will bring a lot to the final implementation considering that it's already possible to have 256 colors. Again, I put myself in the hardware implementation side, not software side😄
The reason I would like to avoid 10/12-bit indexes (and prefer 16-bit) is that I would like to be able to modify a single tile data without modifying the neighbour's. If we use 10-bit indexes, we would have to read (from VRAM/RAM/ROM) the word containing the highest 2 bits of the 10-bit index, modify these bits only and then write them on the bus to the VRAM. Similarly, modifying the neighbour's would mean modifying the higher 6 bit only. Shifts/masks are a bit of a pain on the Z80 as only the accumulator can perform them and it's only possible to shift 1 bit at a time. Thus, it would be faster to use 16-bit indexes. Another possibility would be to have all the extra bits (let's call them attributes) in a different array, that would be a good tradeoff.
You have already guessed what I am working on. I have already implemented 320x240 (double pixel) for the text mode. I will continue by implementing it for graphics mode. Both will be available at the same time. It will be possible to switch between both resolution thanks to a single write on the I/O bus. 640x480 is very handy for text mode as we get 80 columns! For graphics mode we have a 40x30 tiles mode which would let us have HUD on games, without hidding too much the "playground".
But again, up to the developer to choose the resolution that will fit him better. At the moment, I have only planned to support 16x16 tiles for both modes.
@@Zeal8bit Yes the visual difference between having 1 pal with 16 colors for all 4bb and selecting 16 pals with 16 colors is huge, almost like watching EGA and VGA graphics :)
What I mean by 10 bit index is that your tile-map 40x30 consist of 16 bit values. Inside you have 4 bits for palette selection, 2 bits H/V - flips and 10 bits for tile index. This way every new entry in the map will start on every second byte. That is (almost) how SNES is, the VERA that I mentioned, ... It is easy to manipulate.
P.S check this out: th-cam.com/video/BUE3dVsew0w/w-d-xo.html every sprite uses its own 4bpp palette. Imagine it if they all share the same palette :) The VERA also uses 2 bytes (16 bits) for the tile maps. It is fast and easy enough.
@@SquallSf Oh my bad! My question was poorly formulated...Of course 1 palette vs 16 palettes differs a lot 😄
I meant, I wonder if having 16 palettes of 16 colors differs a lot compared to having 256 colors directly (16 palettes 4bpp vs. 1 palette 8bpp).
In any case, it's a good idea to have multiple palettes for 4bpp, I will add this to my to-do list😉
You talked a lot about the software side of things but I've wondered how the vram works. For example. In Ben Eater's "world's worst video card", the reason for its name is that it wastes 71% of the the time wait stating the cpu while it transfers data from the vram to the screen and the cpu can only operate during screen blanking - when data isn't being transferred from vram to the screen. This is obviously a very bad way to make a video card but it was the industry standard for many years just because overcoming this design issue is relatively difficult.
The easiest way to get around this issue is to have 2 banks of vram between 2 ram chips. Or 2 "pages" if you will. 1 page is accessible by the vga port at all times, the second page is accessible by the cpu at all times. You can switch which bank is being displayed on the monitor and which bank is accessible by the cpu at any time. The main disadvantage of this method is that you need 2x as much vram for this to work but at least using it doesn't slow down the cpu.
Designing a video card that doesn't have the issues of the "worlds worst video card" and is better than a bank switched buffer card is difficult. However this approach seems to be what you did here. All I can make out on the video card is 1 fpga, (two?) spi eeproms, enough resistors to probably output 16 bit color and 5 chips near the expansion port that could be anything including ram, bus transceivers or discrete logic chips. I would think one of the better ways of implementing this would involve a 4kb or so vga buffer to buffer data between the vram and the vga port but judging by the placement of chips, that's probably not what you did.
so lol how does this work? Do you have a block diagram somewhere?
Sorry for the very late reply!
Your question is very interesting, and indeed I haven't explained it a lot here (I did explain more on Discord). As you said, one problem I wanted to avoid is memory contention between the CPU and the FPGA, I also wanted to avoid allocated a part of the motherboard's RAM for video. As such, the easiest and best solution for me was to use another RAM for the video. It's not a dedicated chip though, it's the FPGA RAM itself. I choose this FPGA because it has ~120KB of BRAM. I use this BRAM for storing the tilemap, the tileset, the characters pixels and the palettes (I'll also use some for the sound and SD card).
Moreover this BRAM can be used in a dual-port configuration, which is what I used. Used in a 4-stage pipeline, I am able to natively output 640x480 pixels at 60Hz independently from the Z80.
This dual-port configuration also lets the Z80 write a byte in it while the FPGA is reading from it for output.
Overall, this gives me two separate RAM: one for the FPGA, one for the Z80, no more contention. The Z80 is free to use its whole 512KB of RAM. Of course, the VRAM must be mapped to the physical address space so that the Z80 can virtually map it and write to it (tilemap, tileset, palettes, etc...)
How would you recommend handling scrolling, given that the video ram is read only (although you may have changed that in an earlier video, I'm not sure)
Thanks for your comment!
You guessed right, I changed it in a previous video: the one talking about CP/M. I implemented an MMU, which can address 22-bits/4MB of physical RAM.
It will be possible to read back the VRAM. However, I am also considering implementing hardware scrolling. I already did it for the text mode, it's possible to scroll text-line by text-line (each text line is 12px height), this is what the monitor uses currently. For the graphics mode, scrolling would make sense if it can be done pixel by pixel.
Do you plan to sell these? Even as kits or mounted units? I would buy some of them, for sure! Great work!
Thank you for your comment!
I do plan to sell them, ideally, as a finished product, something ready-to-play. But I am also considering making kits as some people also informed me they would like the possibily to have it as a PCB kit.
Out of curiosity, what would you prefer?😄
@@Zeal8bit I'd take the ready-made unit, as I'm not good at soldering! Thanks!
@@igorperuchi2114 Thanks for your feedback
Wow! You make this look easy. I assume you are using a Linux machine for all of the tools.
Thank you for you comment!
Indeed, I use Linux for all the tools: GIMP, python, xxd, z88dk, ghex, serial monitor, minipro, etc...
Nothing for convenient than Linux for this 😄
do you have a pdf abot text mode, graphics mode and semi graphics mode?, i want to learn about that, good video!
Hello @Programador Visionario, at the moment, everything is explained in the videos as I haven't finalized the board and the software. Once they are finalized, I will start making a proper documentation
@@Zeal8bit I love your videos! Thanks
@@programadorvisionario9679 Thank you for your support 🙏
it's very impressive what you have made. do you plan to make it more user friendly by implementing a program language? haha - basic would be nice for a retro computer
Thanks for your comment!
Currently, the OS supports assembly and C, I also wrote a text editor and an assembler, to code directly on the Zeal 8-bit Computer.
I plan to implement a more user friendly language, maybe BASIC, but that's not my highest priority since I still have some drivers to implement.
But if anyone is willing to help, I would be happy haha
哈哈在B站关注了你，没想到在这里也见到了
哈哈谢谢支持！很好的惊喜！
Is it possible to show FOGA code you are making in details please? It would be very interesting to see, how all that works under the hood, sprites, memory organization, practically everything. I have seen very few videos of that kind.
Thanks for your message! I plan to have more detailed videos too about the graphics and FPGA but the implementation is still not finished
书架的游戏:I've come to subscribe to you,Things are done well.(*¯︶¯*)我英语不是很好
哈哈，你英语已经很好！谢谢支持！
That is nearly like a RTX 4090 ngl