Hats off to you with this. What you are doing graphics wise is beyond my pay grade, but impressive to see your progress. Retro Recipes showed a few weeks back an FPGA replacement for the VIC chip, which slots into the socket itself, and does all of the graphics. Let me see if I can find that video...
Happy to see you again, thanks for your comment! 😄 I believe that FPGAs in the future will be the best replacement for non-working or obsolete chips. They are getting smaller and more and more popular.
@@Zeal8bit Firstly, I found the video in question: ua-cam.com/video/o5alg64hxb0/v-deo.html The portion of interest is from 12:55 or so. It might be an idea for you, as it would put the unit more together, and would be easy to swap out, if you are building a better FPGA. FPGA is getting more and more interest. I remember Coreteks talking about them, have to see what it was about exactly. I seem to recall it was about crypto mining.
@@horseradishpower9947 Nice! I like the form factor. I was also considering making an FPGA board that would be connected on the top of my main board when designing my first FPGA PCB. The problem I encounter was that the FPGA PCB would be too close to the chips on the main board. I didn't want to have any overheating problem. In his video his puts a socket inside a socket to add some height, I wanted to avoid such workaround. Moreover, it also meant that you cannot debug the chips that are below that PCB when the computer is on, that's another reason. So I had two solutions: make my main PCB bigger, with a blank spot with sockets to plug the FGPA board, or have the FPGA board as an external one, as I did already. The first solution would be the best if the VGA port, the SD card port, the 3.5mm jack and the pot were on the main board. Thus the FPGA board would "only" receive signals and send back other signals for these different peripherals. It would mean that the board would be exclusively meant to output a VGA signal, which is not what I wanted. This is why I decided to go with the second solution.
Just found this channel, and I hope the project is still going well. I'd love to get one of these computers once the graphics adapter becomes available. Oh, and a half-decent case option would be great as well. Regarding the feature set, I'd like to request the addition of one important (IMO vital) function, which probably won't be too hard to implement: Hardware scrolling. Scrolling tilemaps is a major pain without hardware support. Ask anyone who's worked with the original MSX1 standard, or indeed any of the many other systems built around the Texas Instruments TMS99x9 VDC (ColecoVision, Spectravideo 719/729, etc). The VIC-II in the C64 solved this very elegantly by having horizontal and vertical shift registers, making it easy to shift the display tilesize-1 pixels in one direction. The shift registers did not affect the positioning of the sprites, only the background. In order to smoothly scroll a tile-based picture, you'd first use the shift register to shift the image 1, 2, 3, 4, 5, 6, and 7 pixels, and then quickly reset the shift register and move the contents of screen RAM (the tilemap array) one position in the desired direction during VBlank. The VIC-II also included a feature that would increase the border area, effectively shrinking the visible tile area 1 tile vertically and/or two tiles horizontally, thereby hiding the empty area that would otherwise appear at one end when the picture was shifted. (The reason two horizontal tiles were hidden instead of just one was simply to preserve picture symmetry.)
Thank you very much for your support! The project is still on-going! The motherboard is finalized, I am currently developing the FPGA-based video card. I have been considering making a custom case too, I even tried printing one I designed already😄 I do plan to have hardware horizontal and vertical support in the FPGA for the tiles (for the sprites it's less of an issue). Not sure if it'll be easy to implement in 640x480 graphics mode but for 320x240 graphics mode, it'll be possible for sure. I haven't reached this point yet as I am currently tackling the hardest part: the sprites. But it is planned!
Look into the Amiga's Copper, it had 3 instructions (move, compare and skip, I think) and allowed to update any register in the machine. You could change the palette per scan line, which created the HAM modes. You could program it only using 2 instructions, I did that. The spectrum next has an implementation of it.
+1 on the Copper - I added an implementation of it in the badge for the Hackaday and it's really powerful. Someone wrote a demo that used the ever-loving crap out of it - ua-cam.com/video/Gll31o0D6ic/v-deo.html
I'm pretty sure the HAM was unrelated to the copper. HAM has no pallet, it's just delta RGB relative to the previous pixel. But I'm no amiga person so maybe the copper is relevant even so.
Thanks for your comment! I had never looked into the Amiga's graphics, but waw, that's interesting and a bit complex too! I wonder how "expensive" in terms of bytes are the Copper instructions list, for example for rendering an image. How usable, in terms of simplicity, would it be to display tiles and sprites for 2D games? In my project I would make such co-processor are the main graphics rendering but that could be another advanced to add. I will try to read more about the copper to understand it fully.
@@Zeal8bit You don't use it for sprites or to render an image, you use it to add 'flavour' to an existing set of graphics. For instance, the wobbly logo in the demo is done using a copper list containing of instructions that wait for a line and then on-the-fly modify the offset of the image, and that once per line. If you program those offsets into a sine, you get a single-frame of sinodial distortion. Animate the offsets that the copper applies, and you get a 'wavey' image. The main menu also uses that trick, but it uses a static (non-animated) copper list to re-shape the list of menu items into a more cylindrical form. The menu item list is actually a set of tiles, like you have in your hardware, but the copper list changes the (0,0) position of the tileset on-the-fly once per line in order to make that distortion.
@@Zeal8bit The copper is more for changing the palette or bitfields on specific scan lines, etc., without putting any load on the 68k processor. The future was here has a nice high-level discussion of amiga graphics.
@@Zeal8bit The RISC one got finished, but it was my first attempt at VHDL (have yet to learn Verilog), so it's not very good. It did run however, including a tile-based video card implementation and PS/2 keyboard input. The current one is still under development, currently busy with making the instruction size determining and decoding a bit more streamlined, as the first attempt was a bit unwieldly.
Very exciting project! Your custom FPGA board seems very neat and nicely done. I didn't know the advantage of Lattice compared to Altera until now. Look forward to see your next graphic demo on Zeal8bit computer;D
@@tutoriais5266 That's a good idea, I haven't though about that but there are several things to keep in mind if someone would want to implement such video card for Zeal 8-bit computer: the SNES was a 16-bit console, not 8-bit; by default on Zeal, no RAM from the main chip is reserved for the video, the FPGA has its own (V)RAM; there is no DMA on the mainboard either, so the video board should implement it. I am not too familiar with the PPU, maybe it wouldn't be that difficult, I don't really know but that would be an interesting side project
@@Zeal8bit got it!! :) I really hope you figure it out cuz with a GPU it will be effectively a game console. The audio is probably simpler to do for sure 😃
Thanks for your comment! I will, after implementing them. The easiest way to do is to attribute the index 255 for the transparency as the VGA palette presents an unused color there.
Just wondering, is this going to be a kit or maybe a detailed write-up so others can also make this project? This looks like it would be lots of fun to put together.
Thanks for your comment! As you might know, Zeal 8-bit computer is made of two boards, the motherboard and video board. The option 1 is to make them as a finished product: you can plug it and start using it directly. Then anyone can develop software or hardware extensions. This is also my ideal option. The option two is to make the motherboard as a PCB kit, to allow anyone interested to practice soldering. (Soldering the video board is another issue as it embeds small SMD and BGA components) Let me know your preferences or ideas
I'm really interested in your FPGA video solution. I've built my own 8-bit computer (centered around a 6809 CPU) and have really hit a brick wall regarding video. I hope you are able to get the sprites added but I also hope you would agree to release the FPGA code and board design to the public so other people like me might be able to benefit from that work! (Hopefully it would still work ok with a different architecture than the Z-80...) Thanks for the videos!
Thanks for you comment! The FPGA board has a rather simple interface/connector I would say: 22-bit ADDR lines, 8 bit DATA, WR, RD, MREQ, IOREQ, VBLANK, HBLANK,... Moreover, the FPGA uses its own RAM, it also doesn't require DMA, which reduce the dependency on the main board. Thus, it should be possible to interface it with any 8-bit computer. With a different arch than the Z80, extra logic may be necessary for IOREQ line for example. Do you have a blog or videos talking about your computer?😄
@@Zeal8bit I'm still new to this, currently working on my 4th prototype board. I have a short video up that I made after getting keyboard & sound working, here: ua-cam.com/video/clt6r0-w0Ik/v-deo.html Regarding the interface... 22 address lines: well I only have 16 total so that might be a problem :) I suppose I could use two PIAs (MC6821 programmable interface adapter) together to give me 32 lines to play with. Or, you could add 4-bit color, 320x200 display mode and I'd only need 32K or so to make stuff work :) 8 data bits: check! WR, RD: On the 6800, 6502, and 6809 there is only RD/!WR (one pin, active-low write.) I might be able to throw in an inverter (74LS04 or something) to address that... MREQ, IOREQ: I'm pretty sure address decoding works very differently. Typically for a peripheral I will have one single active-low line for it (a chip-select line) and when that line is pulled low the peripheral should switch its data bus from Hi-Z to input (or output). But if I have PIAs in-between I can probably generate those signals (albeit slowly.) Generation of the chip select line level happens through address decoding (e.g. accessing address $8000 turns off the ROM and enables a specific peripheral instead.) VBLANK/HBLANK: Are you saying you are generating these signals from the CPU?? :O
@@aqualung2000 The 22 lines are here because I have an MMU, but the video board itself doesn't need more than 17 lines currently, so we can consider the upper ones as CE pins. In fact, my first video board is using banking, so maybe it would be interesting to keep both functionnality (either 22-lines, either banking with 16 lines) and activate them either in hardware or software. If you plan on adding banking on your board, having 22 lines won't be a problem, you could use a 74HC574 for example for this. #WR, #RD: an inverter should do the trick indeed as both are active low. #MREQ, #IOREQ: Address decoding is not that different from the Z80, what happens is that the Z80 has 2 buses: 16-bit memory space and 8-bit I/O space. In your case, both buses are the same, your I/O space is only 1 byte long and addresses at $8000, right? You could imagine having regular memory from $0000 up to $FEFF and I/O memory from $FF00 to $FFFF, in that case, #IOREQ will be active if A15-A8 is 0xFF. I don't know how you are doing your logic decoding, if you are using a CPLD, that's pretty straightforward, if you're using 74Hc chips, you could add a Dual 4-input NAND gate, 74HC20, with an OR gate, they would give you that signal. Similarly, we can generate MREQ# out of #IOREQ. VBLANK/HBLANK: I am sorry, I wasn't clear, these are 3.3V output signal, they are provided from the FPGA. I am connecting them to the PIO to generate interrupts when activated
@@Zeal8bit That makes sense. After reading your reply, I feel more confident it could be made to work. I am using 74-series logic for the address decoding. Not 74HC but "old-school" 74ALS series, which are around as fast as the HC. My original design was just a 74ALS139 followed by a 74ALS138; that method only left me 16K of address space for the ROM, but I've since found a better way (that I stole from this guy's video here: ua-cam.com/video/J7koxM_TKq0/v-deo.html ) that gives me 28K of address space for the ROM (huge improvement!) The logic is mostly as you describe I think. Having interrupts for for VBlank & HBlank is a fantastic feature! I'm even more excited for your FPGA design and I hope you have good fortune in your design! Thanks again!
The ESP32 is a 240MHz 32-bit computer, it's a beast of power that would make the Z80 completely useless. It would even be able to emulate the Z80 faster than the real Z80. Moreover, the ESP32 cannot be addressed on the parallel bus without several tweaks. the best case would be to address it via SPI or UART, which is slower that parallel (the original Z80 doesn't have an SPI controller) The ESP32 has several demo for using it as a VGA controller but in my opinion, that's not very stable compared to using an FPGA, which is time accurate. As soon as the ESP32 becomes overloaded, there might be problems on the screen since the software cannot update the framebuffer anymore.
You say characters like "ca actors" with an r in the middle. Can you say it with less emphasis on the second syllable like carrot. I'm not trying to nitpick, just help.
![How 8-bit graphics work on homebrew retro computer [Part 2]](http://i.ytimg.com/vi/eUkJ6oQvLLQ/mqdefault.jpg)
![How 8-bit graphics work on homebrew retro computer [Part 2]](/img/tr.png)
Yay :) Both channels working now :)
Bro I'm so happy that you came back!!!
Haha, thank you!
I never left😄
Hats off to you with this. What you are doing graphics wise is beyond my pay grade, but impressive to see your progress.
Retro Recipes showed a few weeks back an FPGA replacement for the VIC chip, which slots into the socket itself, and does all of the graphics. Let me see if I can find that video...
Happy to see you again, thanks for your comment! 😄
I believe that FPGAs in the future will be the best replacement for non-working or obsolete chips. They are getting smaller and more and more popular.
@@Zeal8bit Firstly, I found the video in question: ua-cam.com/video/o5alg64hxb0/v-deo.html
The portion of interest is from 12:55 or so. It might be an idea for you, as it would put the unit more together, and would be easy to swap out, if you are building a better FPGA.
FPGA is getting more and more interest. I remember Coreteks talking about them, have to see what it was about exactly. I seem to recall it was about crypto mining.
@@horseradishpower9947 Nice! I like the form factor. I was also considering making an FPGA board that would be connected on the top of my main board when designing my first FPGA PCB. The problem I encounter was that the FPGA PCB would be too close to the chips on the main board. I didn't want to have any overheating problem. In his video his puts a socket inside a socket to add some height, I wanted to avoid such workaround. Moreover, it also meant that you cannot debug the chips that are below that PCB when the computer is on, that's another reason.
So I had two solutions: make my main PCB bigger, with a blank spot with sockets to plug the FGPA board, or have the FPGA board as an external one, as I did already. The first solution would be the best if the VGA port, the SD card port, the 3.5mm jack and the pot were on the main board. Thus the FPGA board would "only" receive signals and send back other signals for these different peripherals. It would mean that the board would be exclusively meant to output a VGA signal, which is not what I wanted. This is why I decided to go with the second solution.
It is known as the "VIC-II Kawari" Randi Rossi has several videos on how he made it.
Thank you for taking time explaining how graphics work!!!! It was like dark magic to me
Thanks for your comment! I am glad you enjoyed the video, another one is coming with more details about how to do in practice 😄
Just found this channel, and I hope the project is still going well. I'd love to get one of these computers once the graphics adapter becomes available. Oh, and a half-decent case option would be great as well.
Regarding the feature set, I'd like to request the addition of one important (IMO vital) function, which probably won't be too hard to implement: Hardware scrolling.
Scrolling tilemaps is a major pain without hardware support. Ask anyone who's worked with the original MSX1 standard, or indeed any of the many other systems built around the Texas Instruments TMS99x9 VDC (ColecoVision, Spectravideo 719/729, etc).
The VIC-II in the C64 solved this very elegantly by having horizontal and vertical shift registers, making it easy to shift the display tilesize-1 pixels in one direction. The shift registers did not affect the positioning of the sprites, only the background.
In order to smoothly scroll a tile-based picture, you'd first use the shift register to shift the image 1, 2, 3, 4, 5, 6, and 7 pixels, and then quickly reset the shift register and move the contents of screen RAM (the tilemap array) one position in the desired direction during VBlank.
The VIC-II also included a feature that would increase the border area, effectively shrinking the visible tile area 1 tile vertically and/or two tiles horizontally, thereby hiding the empty area that would otherwise appear at one end when the picture was shifted. (The reason two horizontal tiles were hidden instead of just one was simply to preserve picture symmetry.)
Thank you very much for your support!
The project is still on-going! The motherboard is finalized, I am currently developing the FPGA-based video card. I have been considering making a custom case too, I even tried printing one I designed already😄
I do plan to have hardware horizontal and vertical support in the FPGA for the tiles (for the sprites it's less of an issue). Not sure if it'll be easy to implement in 640x480 graphics mode but for 320x240 graphics mode, it'll be possible for sure. I haven't reached this point yet as I am currently tackling the hardest part: the sprites. But it is planned!
Look into the Amiga's Copper, it had 3 instructions (move, compare and skip, I think) and allowed to update any register in the machine. You could change the palette per scan line, which created the HAM modes. You could program it only using 2 instructions, I did that. The spectrum next has an implementation of it.
+1 on the Copper - I added an implementation of it in the badge for the Hackaday and it's really powerful. Someone wrote a demo that used the ever-loving crap out of it - ua-cam.com/video/Gll31o0D6ic/v-deo.html
I'm pretty sure the HAM was unrelated to the copper. HAM has no pallet, it's just delta RGB relative to the previous pixel. But I'm no amiga person so maybe the copper is relevant even so.
Thanks for your comment! I had never looked into the Amiga's graphics, but waw, that's interesting and a bit complex too! I wonder how "expensive" in terms of bytes are the Copper instructions list, for example for rendering an image. How usable, in terms of simplicity, would it be to display tiles and sprites for 2D games?
In my project I would make such co-processor are the main graphics rendering but that could be another advanced to add. I will try to read more about the copper to understand it fully.
@@Zeal8bit You don't use it for sprites or to render an image, you use it to add 'flavour' to an existing set of graphics. For instance, the wobbly logo in the demo is done using a copper list containing of instructions that wait for a line and then on-the-fly modify the offset of the image, and that once per line. If you program those offsets into a sine, you get a single-frame of sinodial distortion. Animate the offsets that the copper applies, and you get a 'wavey' image.
The main menu also uses that trick, but it uses a static (non-animated) copper list to re-shape the list of menu items into a more cylindrical form. The menu item list is actually a set of tiles, like you have in your hardware, but the copper list changes the (0,0) position of the tileset on-the-fly once per line in order to make that distortion.
@@Zeal8bit The copper is more for changing the palette or bitfields on specific scan lines, etc., without putting any load on the 68k processor. The future was here has a nice high-level discussion of amiga graphics.
Fun, it looks a lot like the FPGA video card I made for my own home-brew retro computer.
Thanks for your feedback! How far have you been with you FPGA core?
@@Zeal8bit The RISC one got finished, but it was my first attempt at VHDL (have yet to learn Verilog), so it's not very good. It did run however, including a tile-based video card implementation and PS/2 keyboard input. The current one is still under development, currently busy with making the instruction size determining and decoding a bit more streamlined, as the first attempt was a bit unwieldly.
Very exciting project! Your custom FPGA board seems very neat and nicely done. I didn't know the advantage of Lattice compared to Altera until now. Look forward to see your next graphic demo on Zeal8bit computer;D
Haha thank you!
@@Zeal8bit why don't you use a FPGA version of SNES GPU or the nes, maybe it will save you some time (I don't know if it's possible btw)
@@tutoriais5266 That's a good idea, I haven't though about that but there are several things to keep in mind if someone would want to implement such video card for Zeal 8-bit computer: the SNES was a 16-bit console, not 8-bit; by default on Zeal, no RAM from the main chip is reserved for the video, the FPGA has its own (V)RAM; there is no DMA on the mainboard either, so the video board should implement it.
I am not too familiar with the PPU, maybe it wouldn't be that difficult, I don't really know but that would be an interesting side project
@@Zeal8bit got it!! :) I really hope you figure it out cuz with a GPU it will be effectively a game console. The audio is probably simpler to do for sure 😃
Nice video! In future videos, will you be discussing how to handle transparency in sprites?
Thanks for your comment!
I will, after implementing them. The easiest way to do is to attribute the index 255 for the transparency as the VGA palette presents an unused color there.
amazing
Thanks😄
Just wondering, is this going to be a kit or maybe a detailed write-up so others can also make this project? This looks like it would be lots of fun to put together.
Thanks for your comment! As you might know, Zeal 8-bit computer is made of two boards, the motherboard and video board.
The option 1 is to make them as a finished product: you can plug it and start using it directly. Then anyone can develop software or hardware extensions. This is also my ideal option.
The option two is to make the motherboard as a PCB kit, to allow anyone interested to practice soldering. (Soldering the video board is another issue as it embeds small SMD and BGA components)
Let me know your preferences or ideas
would both be possible?@@Zeal8bit
Most impressive!
Thank you!
I'm really interested in your FPGA video solution. I've built my own 8-bit computer (centered around a 6809 CPU) and have really hit a brick wall regarding video. I hope you are able to get the sprites added but I also hope you would agree to release the FPGA code and board design to the public so other people like me might be able to benefit from that work! (Hopefully it would still work ok with a different architecture than the Z-80...)
Thanks for the videos!
Thanks for you comment!
The FPGA board has a rather simple interface/connector I would say: 22-bit ADDR lines, 8 bit DATA, WR, RD, MREQ, IOREQ, VBLANK, HBLANK,...
Moreover, the FPGA uses its own RAM, it also doesn't require DMA, which reduce the dependency on the main board. Thus, it should be possible to interface it with any 8-bit computer. With a different arch than the Z80, extra logic may be necessary for IOREQ line for example.
Do you have a blog or videos talking about your computer?😄
@@Zeal8bit I'm still new to this, currently working on my 4th prototype board. I have a short video up that I made after getting keyboard & sound working, here: ua-cam.com/video/clt6r0-w0Ik/v-deo.html
Regarding the interface...
22 address lines: well I only have 16 total so that might be a problem :) I suppose I could use two PIAs (MC6821 programmable interface adapter) together to give me 32 lines to play with. Or, you could add 4-bit color, 320x200 display mode and I'd only need 32K or so to make stuff work :)
8 data bits: check!
WR, RD: On the 6800, 6502, and 6809 there is only RD/!WR (one pin, active-low write.) I might be able to throw in an inverter (74LS04 or something) to address that...
MREQ, IOREQ: I'm pretty sure address decoding works very differently. Typically for a peripheral I will have one single active-low line for it (a chip-select line) and when that line is pulled low the peripheral should switch its data bus from Hi-Z to input (or output). But if I have PIAs in-between I can probably generate those signals (albeit slowly.) Generation of the chip select line level happens through address decoding (e.g. accessing address $8000 turns off the ROM and enables a specific peripheral instead.)
VBLANK/HBLANK: Are you saying you are generating these signals from the CPU?? :O
@@aqualung2000 The 22 lines are here because I have an MMU, but the video board itself doesn't need more than 17 lines currently, so we can consider the upper ones as CE pins. In fact, my first video board is using banking, so maybe it would be interesting to keep both functionnality (either 22-lines, either banking with 16 lines) and activate them either in hardware or software. If you plan on adding banking on your board, having 22 lines won't be a problem, you could use a 74HC574 for example for this.
#WR, #RD: an inverter should do the trick indeed as both are active low.
#MREQ, #IOREQ: Address decoding is not that different from the Z80, what happens is that the Z80 has 2 buses: 16-bit memory space and 8-bit I/O space. In your case, both buses are the same, your I/O space is only 1 byte long and addresses at $8000, right? You could imagine having regular memory from $0000 up to $FEFF and I/O memory from $FF00 to $FFFF, in that case, #IOREQ will be active if A15-A8 is 0xFF. I don't know how you are doing your logic decoding, if you are using a CPLD, that's pretty straightforward, if you're using 74Hc chips, you could add a Dual 4-input NAND gate, 74HC20, with an OR gate, they would give you that signal. Similarly, we can generate MREQ# out of #IOREQ.
VBLANK/HBLANK: I am sorry, I wasn't clear, these are 3.3V output signal, they are provided from the FPGA. I am connecting them to the PIO to generate interrupts when activated
@@Zeal8bit That makes sense. After reading your reply, I feel more confident it could be made to work.
I am using 74-series logic for the address decoding. Not 74HC but "old-school" 74ALS series, which are around as fast as the HC. My original design was just a 74ALS139 followed by a 74ALS138; that method only left me 16K of address space for the ROM, but I've since found a better way (that I stole from this guy's video here: ua-cam.com/video/J7koxM_TKq0/v-deo.html ) that gives me 28K of address space for the ROM (huge improvement!) The logic is mostly as you describe I think.
Having interrupts for for VBlank & HBlank is a fantastic feature! I'm even more excited for your FPGA design and I hope you have good fortune in your design!
Thanks again!
I like your Into :)
Why don't you use an ESP32 controller for the graphics chip as the Agon Light 8-bit computer based on a Z80 too?
The ESP32 is a 240MHz 32-bit computer, it's a beast of power that would make the Z80 completely useless. It would even be able to emulate the Z80 faster than the real Z80.
Moreover, the ESP32 cannot be addressed on the parallel bus without several tweaks. the best case would be to address it via SPI or UART, which is slower that parallel (the original Z80 doesn't have an SPI controller)
The ESP32 has several demo for using it as a VGA controller but in my opinion, that's not very stable compared to using an FPGA, which is time accurate. As soon as the ESP32 becomes overloaded, there might be problems on the screen since the software cannot update the framebuffer anymore.
Argh. No, not the right-sound channel issue again :/
You say characters like "ca actors" with an r in the middle. Can you say it with less emphasis on the second syllable like carrot. I'm not trying to nitpick, just help.
Haha, thanks for the tip, I will be careful next time!
4:50 the index is 40.
Good catch! Indeed, it should be 40!
Yikes. The video is only using the right sound channel :/