That last demo is *very* impressive! I think I expected the text mode and the new parrot version, so those didn't surprise me, but the parallax effect is on another level!
Amazing how many old 8bit coders go into electronics, including me. I've learnt so much from you, Ben Eater, George Foot, and the guy that did the Vulcan 74 build. This is very inspiring - you are a very good teacher!
This is seriously cool. It reminds me of the arcade boards coming mainly out of Japan from the 80s with all their fancy tiling hardware that was far more powerful than the home computers we had at the time.
Really enjoying watching this project develop. It's a classic 8 bit computer from the ground up, but without the bean counters or unobtainable deadlines being shoved in the engineer's face, so you've got so much more freedom :)
These videos are always worth the wait, and such a great reference. I find myself coming back to your videos repeatedly, and always picking up a bit more each time. When the system is "complete", or you are looking for the next topic, I hope you manage to spend some time on how to develop in such a constrained environment.
Tile graphics look great already. Nice. I wrote a tile-based OSD in Verilog years ago, and it was good fun, but it's not as neat as actually building it out of TTL chips. hehe
Outstanding, so good - and the old parallax tile trick to get another playfield, very nice. Once the sprites are in you're basically there, can't wait to see a playable game on this thing
Sprites overlap. So you would need to duplicate the same circuit for each sprite. C64 had 8, pcEngine 16. What about 4 tiles per tile? The background and 4 shifted ones. So you could only overlap 3. On breadboard memory is cheap. Or basically, on breadboard rather use a framebuffer and a single blitter. Or a genesis linebuffer which is filled in the side borders? Sprites could be 1 bit for transparency. Each sprites sets a different bit so that we can detect all collision combinations. Then in a second pass fill in the winning color?
I know this project is long over, but you hit the nail on the head when you said "I swear it would be faster to just make a PCB for this", the amount of times I've seen you hook up a bunch of multiplexers to just pair all of the address or data lines together and bind all of the inputs together... I feel like you could just make one reusable multplexer DIP style PCB, that just took in two sets of 8 inputs, one set of 8 outputs, a single select line, pwr & gnd, with built in decoupling caps... You could put it in a wide DIP 28, and just reuse them over and over and save 60% of your wiring each video... 🙃
The project is not over! There are still a few parts of it left to go, only one more section that has memory in it though. There are some benefits to making some modules to use along the way, but the significant difference between the circuits is still going to be the differences in the inputs. You'll still have to see me add all those lines even if they terminate in a neat row rather than spread around the multiplexers.
What have I learned? "Wrongness" is measured in miles: And whenever you think you have seen the most packed breadboard, a James Sharman is around ... Congrats, good progress.
Hi James, great to watch the update and fab results!! Best get the 74ACT out and more decoupling caps for the sprites, that’s really going to push the breadboard.
Excellent James. Another demo idea - I remember using this tile changing and placing method to create a hi-res oscilloscope demo on my very low res VIC20 in the early 80's. The tiles made the waveform shape in low res with the hi res tile definition giving the waveform shape required. With most of an oscilloscope screen blank it was perfect when there weren't enough unique tiles to fill the screen. Perhaps a step further would be an A-D converter and you have a scope that could look at itself or the JAM1 !
I had an idea that I should have done a pcb for the core memory circuit here as I could have used it for multiple circuits as I converted the previous bit to pcb
Did I hear you say 24mhz? On a breadboard?! And you're getting such clear output! Those must be some quality breadboards! Amazing work - thank you for sharing this with us all!
Indeed, we’ll it’s 25.175mhz, the benefit of course is that as long as the sync and blanking are working issues just show as visual glitches rather than a crashed cpu you are trying to debug.
What a treat of a video! It has everything. The fact that a bug can be easier to solve in hardware that in software still blows my mind :D [49:18] The more you add, the more I'm eager for you to the next things (ahem, keyboard, ahem). Thanks for the great videos!
I have just re-watched this whole VGA mini-series while resting up nursing a bout of Covid... Clearly the planning that has gone into this has been very thorough and well thought out. Well done! Personally, I would have loved to see a larger full-resolution buffer (obviously paged into a smaller space), but for your stated needs I can see that the creation of additional layers of screen data manipulation by having both the tile and palette mechanisms available offers so much more flexibility as well as processing efficiency. I am intrigued by the possibility of how you might get back to 8 bits per pixel to fully utilise the palettes, albeit at a lower resolution.
One thing to understand is that I was prepared for the cpu to max out at a lower clock rate so the vga had some design elements to enable me to make some fun games with less computation than I have. I do have plans for future cpu+video builds that will both have flat frame buffer and the power to fill it at a decent rate.
@James Sharman Splendid! I look forward to all future updates. And yes, designing for a potentially more restricted processing power makes good sense. While watching, I was also revisiting the two computer video hardware designs that I did in the 80s, one was just character based with a 6845 controller, the second used the amazingly capable 82716, but which was quickly overtaken by PCs going down the EGA and VGA path.
It is becoming an impressive VGA, it is now even better then what I remember from the times of the IBM PC. The PCB's are getting big, almost a table full. By the time you have added 4K rotation and scaling you need two tables and some bookshelves.
as always very impressive, I don't know how you are keeping everything straight in your mind, with the timing and the all the lines that need to be held high or low. I don't know if you got weeks of research and schematics but you seem to be planning this out on the fly and that's like 3 times as impressive.
Great work as always James, it’s interesting to see your thinking as you develop the various parts of the system. I have built a number of z80 systems for various purposes over the years and understand the entire fundamentals of computing. Would love to have the spare time to do something similar to what you’ve achieved there. Almost all microcontrollers now, it’s simple and quick, gets the job done, but not much fun. Thanks for the video series 😊
@@weirdboyjim It does :) it was getting near the end and I thought “he could do a parallax layer by redefining characters on the fly” and you did :D Are you going to let each character choose a palette?
Really cool! Maybe i just have bad eyes, but would have liked some close-ups or video capture. I didn't realise the text was corrupted until you said - and after you fixed it, it still took a bit of imagination to read it. Maybe on your extras channel you could show your demos again, but zoomed into the screen?
Something I noticed: the tile data indexes directly into the global palette? I know on Nintendo's tile-based systems, the tile data generally indexes into a small portion of the full palette, and the portion is selected independently for the tile from its pattern. Regarding the parallax, while it wasn't the 8-bit system, the Super NES, as well as a few other Nintendo systems, had multiple background layers that could be scrolled independently for things like parallax. Speaking of the SNES, are there any plans for affine transformations (the famous "Mode 7" graphics)? Even if for nothing else, it would enable zooming in to that kind of tiled level to actually get a better look at the individual tiles. :P More seriously, it can also be used isometric games where each tile displays as a rhombus rather than a square, and of course changing the transformation on each scanline gives the classic 3D projection capability. (I guess I should mention that I didn't grow up with 8-bit systems and instead grew up with the GBA, so naturally I'm a bit more fond of the more complex, but still low-resolution, tile-based graphics that it has, and largely shares with the SNES, compared to the graphics of the NES.)
I'm more trying to demonstrate different principles than reproduce some specific functionality. Mode 7 was an interesting feature that could be described as stepping stone between planar graphics and primitive 3d hardware.
All of these bits should come together into a fairly coherent computing device and then I’ll develop a few games and demos for it. I’ve got some rough plans for a sequel build which will introduce some new concepts when this is all done.
Time to add a keyboard? Not a ps/2 keyboard of course (because where's the fun in that), but doing your own scanning hardware? Maybe with a custom keyboard PCB, or possibly using an existing one (if you can find one that doesn't have a built in controller).
@@weirdboyjim I can say from experience that the cheap AliExpress Outemu switches feel really nice, no need to spend a fortune on other higher end branded switches.
Just to get an indication of how long it took to wire these breadbords: what's the speed-up when you're not talking and explaing stuff? 5 times, 10 times as fast?
My go to speed up is 9x, I tend to do things in multiples of 3. But I also cut chunks out when Nothing is moving on camera, lots of wire stripping etc.
Hi, great work. So as I understand you select the Tile, select the Pixel from within the Tile, get the Color data from a particular pixel look it up in the pallet and output its RGB to VGA... would the versatility be massively improved by having a pallet index .. well ... basically per tile. So the tile data could define reoccurring shapes without having the colors locked? Or is having a pallet lookup table too much out of reach?
You could do that, but I’d need somewhere to store the data. Another idea I had was to use a few bits from tile index to offset the pallet look up, so you would have 16 different 16 colour pallets each used by exactly 16 tiles. But then I came up with a cooler idea you’ll have to wait to see.
@@weirdboyjim Ooohh... you tease you ... ;-) If I may some additional feedback. I Liked the overlays of the ICs but had wished for description not just numbers "multiplexer" or "ram" would have been sufficient. Also when we are talking about 640x480 graphics a closeup or two of the screen would be lovely ... at this size youtube compression lets only guess what is a glitch and what is a compression artifact
Great video! Was wonder if you might revisit the CPU or do you consider it done at this point? Would like to see more advance math functionality added. Like multiplication and division. An easy route would be to implement LUT in ROM. Multiply and Divide would each require 64k. This can be reduced if you remove duplications.
The cpu may get some tweaks but the core is there. I do have plans forming up for a new cpu build that will advance a few concepts, trying to evolve this in place is not the best way to do it.
8-Bit Guy should have commissioned you for the graphics interface on the Commander X16 - that way it wouldn't have ended up as an overblown FPGA-solution that has zero chances of ever ending up as discrete chips.
@@weirdboyjim I think what you are building could still be optimized, especially with some simple programmable logic arrays, which I feel is fair game still. However, the VERA module of the X16 has become its own computer entirely, which seems ridiculous for a computer built around an 6502.
Thanks Scott! It's enlightened self interest, I need to put the effort into to make them maintainable and debugable! There are far better examples from other people though!
That's awesome! How much headroom is there? Could you run the pixel fetching circuit at higher speeds? If so, you could potentially use the same circuit to generate multiple values for each pixel sequentially and latch and mix them together to create multiple background layers, without replicating the entire circuit.
Unfortunately I don’t have enough bandwidth for that. In theory I’m only using half the bandwidth for tile-data as I get 2 pixels with each read but the logic to make that work would be extensive
It seems like you could potentially add more actual background tile layers once the tile system is made into a PCB if perhaps you allow the PCBs to stack with a way to set their tile data (tiles and palette) address? If there's enough address space!
Given that a lot of what you rely on is 74L series glue logic, what is the major differentiation responsible for the amazing capability you demonstrate with your project Vs the typical capabilities of cards in the 80s? Why didn't we see more in he 80s of what you demonstrate today?
There are are a few factors there, I have the benefit of hindsight but don’t underestimate the advantage I have in low priced memory chips. I can buy SRAM easily but designers back then would have been fighting DRAM to stop the cost being prohibitive.
Astounding work James. Why do I get the feeling 2 years from now that you'll be programming EPROMs with a custom 8 Bit style video Games then putting them onto PCBs that then plug into the JAM-1?
I like your solution. a full resolution frame buffer would overwhelm the bus, no way to drive fast graphics that way. It would feel like the C64 in graphics mode. This looks more like a NES/Gameboy solution. It would not have survived Nintendo cost cut back then, due to all the SRAM required ;-) I guess you will need even more ram to drive the sprites because I doubt you can reuse the tile ram due to timing issues. Coming up next a PS2 keyboard interface?
I might've missed it, but adding an additional memory lookup would create a 1 cycle delay, which must be compensated for (as the sync pulses still use the same timing), resulting in slightly shifted pixels? How do you compemnsate for that?
I’m trying to follow (now that I’m home from work😂) exactly how this looks in memory. I’m guessing there is a 80x60 (8 bits each) region, call it the frame or cell buffer (so 4800 bytes). These 8 bits index into a tile map, each tile is 32 bytes in size (8x8 pixels x4 bbp = 32 bytes). The full tile map is then 256x32, or 8k in size. The resulting 4 bits per pixel are then used to output a colour directly? Or are they an index into a 16 entry table (of say 8x3 bits each) to give the final rgb output to the display?
I’m trying to work within some constraints, trying to solve problems can make things more interesting. My next build will have a wider native address bus.
I wonder how hard it would be to rig up a PS2 keyboard - i'd think it wouldn't be too hard. Maybe serial is preferable, but I think there would be cool factor on being able to use screen & keyboard, with no laptop attached. (You'd have to preload the roms of course). Maybe you could port an assembler or some interpreted language like basic or forth - I like like the idea of being able to use it like the old 8 bits of the day. Maybe your for focused on the console idea . . . but still.
@@weirdboyjim easily. Especially if one gets into the eye/brain interface along with colour/vision and so on. From a pure optimization perspective, it's an interesting problem (if we ignore some of the human vision aspects) on its own as well. 😄
@@NuttySwiss do you know about any method better that PSNR, which describe image quality as single number? I tried to find one and failed. Single numbers are needed because they are trivial to compare. Saying "this image looks better" will not help, because every person have his own feeling of "better".
It would be really easy to just add enough ram to have a full resolution frame buffer but I’m trying to explore the techniques, the parrots will improve though!
Taking the input Image and creating versatile tiles that can be reused within the image might be the real problem. Dithering would have to be done within the tile data, and I guess that's the real bottleneck
@@Schwuuuuup I think that some areas of image may benefit more from dithering and some areas - more from added detalisation. Also it may be interesting to try changing palette and tile data on the fly.
@@CodeBallast I get an on/off option in a few categories but I know they have been pushing it up lots. Maybe your fitting into a particular demographic being targeted lots at the moment.
Love to see the layers of progress. As systems like this evolve, the rate and quality of the changes reflect the original architecture. This one is clearly a winner. Pity that it’s hard to make a lovely 8x8 font, but that’s a very small nit,
