Thank you James for taking the time to build your computer and record and edit these videos. I find all your work both fascinating and inspiring. Keep at it and know you have lots of fans. Don't let life get you down, we all are behind you 100%! Many thanks.
Flashbacks to Fractint palette cycling .... it's like it's 1992 all over again. :) The vortex is superb! (And this is an upvote for anextras video of how it's done)
I had no computer at home and someone noticed I had one of the few VGAs at work and said "you've got to see this" and I was all "wow! I thought you needed a supercomputer" and within a couple of weeks I had my first 286 at home! I first started to learn C by studying a printout of the Fractint source.
What an insane achievement. Like, INSANE! It's just hard to imagine how proud you must be of reaching the milestones. A sincere congratulation on this amazing achievement
Just discovered this series and I'm seriously impressed. Love the explanations, lots of great practical stuff from someone who has had immense experience in design and software engineering. Even as a game and hardware dev from way, way back, I learned a few neat tricks there.
It's all magic !!!! Looks brilliant, and even better than the demos was the beautiful breadboard wiring... You should photograph that and stick it on the wall !!!!!
And with this simple RAMDAC you built, you have surpassed the color capabilities of the original VGA which in Mode 0x13 only had 6Bit/Channel (~260k Colors) in their palette IIRC
Yeah, the earliest ones were 6 bit, far easier to make a 6 bit ladder with tolerance actually. I did think about 565 for a while but didn’t want to short cut.
Your use of the prototype board is super clean! I've started very slightly tinkering with electronics, and I currently just use a bunch of jumper wires! It's terrible! :D
Thanks! I usually have a mix, on this one you can see a few signal interconnects use jumper wires. This circuit is running at just over 25mhz though so it's benefits from being careful with the wiring.
Brilliant work James. Love how you also include some of the hardware issues you need to resolve, like excessive propagation delays etc. It would be good to also walk us through some aspects of your software development as well, although I appreciate your concerns about video length. Maybe, a seperate video taking us through your demo software development? Covering the software development that compliments the hardware development, would be awesome. But brilliant work either way. 👍🏼
Thanks Digicool, programming can be a hard sell but I'll probably include a bit more when I make the extras video to describe how the vortex effect works.
Really love how all this is all turning out. Oh, and there are many more effects that can be done with palette changes, such as an image dissolve with a static image.
Very nice. If you have spare ram, maybe you can give each sprite its own palette - that would surly open up options for graphic effects. The last demo looks like pallet swapping plus beam racing. With perhaps a bit of horizontal scroll? Nice effect.
Thanks! I have an ultra simple plan to use the extra ram (It's just one chip), I don't want to talk about the sprite plans until I get to that video but there is a reason why that would be a bit more complex.
It was neat to see the parrots as you messed with the wires and chips. Something that *seems* so digital is analog in spots. Sorry if that doesn't make any sense lol.
Indeed, It's just the last little bit that is supposed to be analogue but when I was swapping the multiplexers around there were also floating lines on some of the inputs.
Hi James, that’s absolutely stunning stuff! Have to mention old arcade boards with various small (22pF-100pF) tagged on to slow an enable signal down and without all sorts of horrid mistiming contentions.
Nice work James! This should be able now to run a version of the bad apple demo without just showing frames out of memory! I‘m thinking of implementing your build in an UpDuino this winter as I finally want to learn and tinker with VHDL/Verilog on those small affordable Ice40 FPGAs. Keep up your work! Thanks for this great series.
Thanks James. I just got back from visiting family and catching up on videos. Looking fantastic. One of these days perhaps you can shoot a video discussing the various things you've learned about setting up breadboards. Take care.
That is just very cool, well done. My first thought with the extra address lines for the ram would be to have multiple pallet banks, so you could just swap between them. That could make for some interesting effects as you could swap the whole pallet every line. Maybe make it so any write to the 4th byte a color set a latch for the pallet bank, as that might be fairly easy to add to what you already have in the circuit.
Wonderful, beautiful work. WRT: the color pallet... A lot of the colors are very close together and many resemble "black." I wonder if you can get more colors on-screen at one time taking advantage of the fact that so many are close together (effectively reducing the color pallet from 16M to a few hundred thousand)? Also, if you know that the color to the left of a pixel is "close" to the color to the right (on a scan line), there's no need to change THAT pixel. If you reduce the color pallet from 16M down to a few hundred thousand (because so many colors are similar), and only update the 3-4 pixels on a scan line that are "furthest off", you might be able to get an Amiga "HAM" effect. Very interesting work. Continued Success!
I as reading your comment thinking “he’s reinventing ham”. You have to remember that the palette itself a a way of reducing the massive range of colours down to a working set that is more useful.
With so much unused RAM for the palette i could imagine a register and some logic providing multiple palettes. That way you do not need to change all the colors between the scanlines, but just select the preinitialized palette using the register byte.
Some very nice parrots there! One thought I had, with connecting the scope reducing the number of glitches, maybe some extra capacitance in the right places would help? Probably not worth it on the breadboards anyway... I imagine one of the ideas to make use of the extra RAM would be to allow multiple palettes and quickly switch between them? I'd be very interested in an extras video explaining how the vortex demo works.
The difference with the scope attached is interesting, the capacitance was pushing the rising edge back slightly, in theory we could get a little bit more speed out of the system by delaying the output latch signal such that it allowed the ram lookup to overlap the address for the next pixel passing through the multiplexer, but that would mean we would be accounting for fractions of a cycle later stages in the circuit. Yeah, that's my thinking on the palette ram, I think I can add that with just one extra 574'.
Yes... instead of double buffering a screen it would be the same principle just instead switching the palette. So you'd have double, double buffering. 🤣
Looking good James! I did similar programming on the C64 writing code synchronized with the TV's electron beam. Man did yopu have to count processor cycles!
This is getting very interesting. The results are fantastic. I am hoping to see a high rez version of this. Is that something you are looking to accomplish and are you going to eventually shrink the size of this setup? Have you thought about using programmable logic chips like PAL's and GAL's to minimize the number of logic IC's?
@@cj09beira However, he is already using ROMs to decode instructions through the pipeline, and to produce graphic card signals, which is also kind of “cheating”, if you concede that, because that’s ultimately a brute force way to get custom combinational logic. Also a simple PAL was part of the 6502 instruction decoding hardware, so I wouldn’t see using them in this project as going too far. In fact, I regard PLAs configured as simple PALs as far less cheating than ROMs, just look at the level of integration and number of transistors of just one single chip of the latter, which may be far greater than the rest of chips in this processor combined!
Ah, I finally understand the reason you get snow on the screen if updating the palette at the wrong time - even if the colour you’re updating isn’t in use.
You mean on regular PC vga cards? Yeah, back in the 90's I hit that issue. It was the first time I started to have to synchronize code with the blanking intervals.
@@weirdboyjim Your detailed explanation of the design is especially appreciated. I'd like to build my own one of these and follow along with you - are your CPU PCB designs available by chance? I'm still early in the CPU playlist so my apologies if you have already covered that question before.
Nice result! I think the vortex animation is done by palette cycling and the movement is done with hardware scrolling. There's a GDC talk called 8 Bit & 8 Bitish Graphics, showing some really impressive palette cycling demos, maybe you can show some of them on your cpu?
The underlying effect is obviously palette manipulation but it's more than a simple cycling, the grid moves in two dimensions. Once I had that working I added the scrolling on top for extra variation (because why not!). Yeah, lots of nice tricks about, I saw one like this in the early 90's and it stuck in my head so I had to try it.
Some random palette trivia I came across this week: Terminal Velocity / Fury 3 had additional look up tables to shading and alpha blending within a fixed palette.
I used a similar technique back in the day. I documented it in my dissertation (1994) but commercially it was first used in Swiv3D (1996). My system did a translation between a virtual pallet and the screen palette which gave me better intensity gradients.
Love it, very very cool. You could use the rest of the ram for 7 more palettes and then a 3 bit selector for each row of the display - sort of copper list style...?
Thanks Charlie! There is actually space for 32 palettes, I worked out a circuit that only adds one extra chip. Interesting idea to make them row selected, would take a bunch of extra circuitry. My thought was just for quick change.
Nice work! I've shied away from using multiplexers for this kind of thing for speed reasons. My main plan there is to use transceivers as usual, so that the framebuffer can drive the palette address directly without extra propagation delay, but turning off the framebuffer's output enable during palette updates. I don't mind if palette updates cause glitches when they occur during the visible part of the frame. Or just use dual port RAM for this part!
Thanks George! Yeah you could replace the address multiplexers with a pair of 541's driven by the same enable lines as used for the data. Chip count would be the same but there is a significant size different between so-16's and so-20's. You actually used to get exactly this kind of screen fuzz on older vga card's when you did a palette update, discovering that was the first time I had to start worrying about the blanking intervals in a practical way.
@@weirdboyjim So I thought - however in really small sizes it does seem to be less horrific! The other thing I was considering for reducing the amount of wiring and bus sharing was using the overscan framebuffer memory to provide the palette write addresses, just like it normally does, so that no sharing is needed there. Maybe the even bytes during the overscan provide data to write, and odd bytes provide addresses to write them to. It's getting a bit silly then, but would also mean "copper" effects would not require active cpu intervention.
Amazing work! Have you thought about using a planar layout for the palette instead of the current packed pixel layout? That'd remove the padding byte between each entry, thought maybe updating the palette would become more complicated
You mean having 256 bytes of red then 256 bytes of green etc… that would indeed make it easier to use the remaining bytes but it would be a pain to update the individual entries.
if you want to be fancy, you could hook the extra address lines from the palette rams to a latch and have the ability to 'cycle' 32? different palettes just by writing a different value into the latch. obviously you have to setup the data in the palette rams before you can cycle them but it allows rapid switching of on screen colors for things like different images or even fancy color swapping effects all by changing a single byte
@@weirdboyjim just a latch using the extra write enable from the demux yeah? means the latch is duplicated many times over the address space and means you lose the line for other things, but is a single chip solution. unless you were thinking of something else?
You could theoretically add a fairly low cost high resolution output mode (double horizontal resolution) by changing the way those final line drivers work coming out of the palette circuit. Normally they just let through the whole 8-bit palette value. However, if you take a double pixel clock, and in "hi-res mode" you output either the high 4 bits or low 4 bits of the palette value to the top 4 bits of each DAC, you can fiddle the palette to essentially pick 4 bits of each pixel byte on odd/even hi-res pixels. Half the colour bit depth, but double the pixel resolution - good enough for a text mode? It'd involve switching from 1x8 bit line driver to 3x4 bit (faster?) line drivers, but would avoid making any changes to the rest of the video circuitry. Since you've got 8K palette chips, you could also switch palettes on each horizonal line (use a register to drive the top few bits of the palette RAM), and with a bit more palette tweaking, double the vertical resolution (again, half the colour bit depth - you'd be down to a 4 colour mode). The advantage being for minimal changes (and without having to speed up the rest of the video circuitry), you've got a big step up in resolution. Really enjoying the series - it's nice to see the old-school demo tricks being played with.
Indeed you could. The plan is to have some tile data containing 8x8 tiles that the current "pixels" in the tile map will select. You could create a 16 color psudo 160x60 or 80x120 display of the type you describe just by setting the correct tile data. You could even make a 160x120 4 color mode. Glad you are enjoying the series.
I remember the Amiga HAM mode. That was a 256 color table but the primary color was set in the first pixel. The color was then changed in the three other pixels. Although the resolution was lower as a result, it looked as if more colors could be displayed. In this way, an 8-bit color palette became a 12 or 16-bit color palette. But it wasn't really 16 bit color because 4 pixels always determined the color. A new color could only be set in the 5th to 8th pixel.
you do a constant increase in some rotation value and map a decrement against the distance from the center to get your next spiral position, I am wondering if you map the transition of the pixels form left to right somehow into the vertical handling hardware to get that "sucked down forever" effect. This is kind of similar to a Sheppard effect in sound. The output goes to the input making a seemingly endless falling or rising cycle.
you do some extra wiggling of the hardware with wraparounds turned on to do the "wiggling around Brownian motion" probably two simple randomised sine functions overlaid
@@weirdboyjim It looks like a set of block /B/ being repeated, are you feeding the output of the 'B type' block into multiple points at once? and scrolling the opposite way on one of the hardware buffers, or maybe going one bit across in position? damn clever stuff anyway. I award myself several "trier" points ;)
As a (semi)-educated guess, I think there's an underlying bitmap with a static image and you're just turning a few colours in the palette on per frame to give the general impression of animation. But I see that the vortex moves around so perhaps you're also moving the displayed window around with the hardware scrolling feature in at least the x direction.( Maybe y too!)
Amazing final effect! You ended up with mostly what IBM did with VGA in mode 13h 🙂 Too bad you don't have the bandwidth to go higher resolution though 😞 Maybe there is some place for CPU opcode optimization if you would resign from using some opcodes to do IO stuff and move to a completely memory mapped system. Or maybe some simple DMA controller IO to move unaligned (page aligned would be probably easier to build, but unaligned DMA would be simpler to use when programming?) 256 byte blocks around in 'one go' (synchronized to access memory when CPU isn't)?
Glad you like it. Actually the resolution is more about the addressable memory, that final effect isn't changing the core buffer contents so higher resolution would have worked fine, it would have needed a paging schema to address a larger frame buffer though. The next build will be able to address more memory.
My guess at how the final demo works: I think you are using the palette to animate the swirl animation. My guess is that you have several different palette slots dedicated to the vertical bars, and several dedicated to the swirling lines. then you update the palette so that the active frame of the animation is brightest, falling in brightness on both sides. I think you are also using the scroll buffers to animate side to side and very slightly up and down, which hides the fact that the swirl pattern repeats quite rapidly.
Ha the last one is pretty easy, you are using the scroll registers to move the vortex around and you shift palette to make it appear rotating. As a fun fact the SEGA logo on the genesis in Sonic 3d used a similar palette technique to output a video at reduced color depth but fast enough to make it look smooth.
Yes to the scrolling, it is indeed palette manipulation but I intended the question to be more specific about what the image contained and what was being done to the palette.
Each “square” mapped onto the vortex is made up of 256 individual colours (8x8) so you could potentially map any repeating pattern onto the tube. Depending on how you arrange the indices, scroll left/right and up/down is some relatively simple offsetting of the palette data. But you have to fill all 1kb in the vertical blanking interval, right? With some pre-calculated palettes you could rotate the pattern, morph it, etc. limited only by ram.
Bingo! I like to think of it as an 16x16 texture mapped onto the surface. yeah I have to update the entire pallet each frame. The code runs lightly over (hence the fuzz) but I could probably optimize it slight to get rid of that.
@@weirdboyjim Perhaps use that unused RAM area to store the next palette, like one would do with double buffering the screen. You could then update the next palette in line during the screen draw and simply switch it out on the vsync.
@@GORF_EMPIRE That's clever! You could even have several palettes set up and dynamically switch between them. Those 7164 RAMs would not be such a waste after all.
Not exactly what you are commenting here but most normal maps encode a normal vector so have only 2 degrees of freedom, Blue normally encodes the component pointing away from the surface so negative values are unusual. This means the colour cube is reduced to points on a hemisphere which gives the image a distinct look that anyone who has worked with them can spot a mile away.
For the fourth channel, you could use it for alpha/intensity information, it might be overkill and registers might have more utility. And of course implementing alpha would mean more chips and a fair bit of rethink of the circuit, I'd imagine.
@@weirdboyjim I know, I realized that after a while... What "new" color could be made. Think we are so used to the incredibly complex computers that are our graphics cards that we just see "Alpha" as something that just happens. It might be used for some HW color blending, but I now think Alpha is a bit of a red herring. And using it for control signalling (if needed) is probably easier and better utility. But I can't really figure out what those controls might be... I have a half formed idea, can we reverse the data flow? Can we use the "4th byte" read back info? Of what, I am not really sure, but it was an idea I had.
I wonder how difficult hardware antialiasing would be. For horizontal, surely a small capacitor on the DAC outputs would do it, but for vertical you'd have to get tricksy.
Wait until the tiledata is there before you worry about that! What you are describing is likely to end up as a blur at best which is not what you want in most circumstances.
My guess on the vortex demo: I think the vortex demo is color cycling palette entries (obviously) but the visible image is a subset of a larger bitmap, which is being scrolled left and right and at a faster rate but with less amplitude, scrolling up and down.... (essentially the x,y offset of the origin of the region of the larger image is being moved around, with the new image being blitted to the video memory?)
ref: 44:28 Technically not the same, but this method of changing color give me a feeling of the HAM mode on the Amiga graphics and it is very close to the way the old C64 manged to add a lot more color to the sprites. 🙂
Are you perhaps animating it by using a mix of packed frames with continuous indices (ex 0-3 frame 0, 4-7 frame 1.. etc) in the palette and some stupidly fast memory copying going on? :)
@@weirdboyjim No news there. I'm horrible at describing stuff lol. It's an old trick from the console days. You'd pack four frames into one and animate it by changing the palette while at the same time update the hidden buffer with a new batch of data, switch buffer, animate that and so on :)
In that vortex demo, do you have an animation of a sort of tunnel with the far end moving back and forth and the color indices going from low to high in a banded spiral (or vice versa) based on distance down the tunnel? Then just cycle a soft-edged green band through the palette every frame for the spiral animation effect?
Oh my god it has shading... Can it shade a coloured image though? Seriously, how cool can this get... I suck at original programs, but I'll port something cool for sure
What about a Class A buffer amp like the 5W Class A amplifier but with a supply of 9V to buffer the output of the R2R Ladder network and not burn out the transistors.
I talk about maybe using a buffer op amp in the DAC video but I wasn’t really worried about 0.7 volts pulling too much current through 75 Ohms on a line driver output.
Ha, I almost skipped this video, thought I'd seen it already :) So that pic is pre-rendered (like the normal map, but max double width? or 1.5 width?), it has color palette cycling, where "black" adds to the _illusion_ of a background (space), but the center of the "vortex" is moving (wobbling up and down too, by my eyes), so there is a _screen shift_ left & right, and every time it moves (shifts left or right) you add the missing _vertical pixel line_ (s), with a similar technique used to "wobble up and down" (if thats what its doing) but limited to (say) 2 _horizontal pixel line_ s in movement (instead of 70% of the screen width). Yeah? Very cheesy, and very retro technique (especially @ 4MHz, if so used), and I am pretty sure I saw a (purple?) _torus_ doing the same at some point in the early days of VGA (EGA?) demos (circa 87/89 in NZ, took a while to make it into the local computer shop) ..
Why do we need line drivers? Why can't we simply get data straight from the RAM? It comes with its own output enable, so, what are the drivers for then?
The line drivers are for writing data to the RAM chops. The data lines are both output AND input so during a write we disable output enable on the ram and enable it on the line driver to put the contents of memory data onto the inputs.
What about reducing each board to a FPGA and put the FPGAs onto one board connect up in a way that replicates the way your graphics card build was working.
Hi James, possibly off topic question, I recently designed a discrete TTL circuit to replace a unavailable custom IC for an arcade board, and then went on to design/order a PCB (JLCPCB if course) I decided on SOIC packages… PCB arrived and only then (DOH!) realised some parts were hens teeth in SOIC… Any suggestions?
Well, my big bit of advice is that I add items to my shopping basked as I add them to the schematic. That's actually why the bus control board ended up with 2 138's replacing a 139.
@@weirdboyjim 74LS191,541,157 Yes a real pain, but I have the TTL version arrive today, will be testing shortly, hopefully the transition from breadboard thru EasyEDA/JLCPCB will be a happy one :) Thanks James
Yeah, there is scrolling layered on top adds a little easy variation. The underlying effect is obviously palette manipulation but it's more than a simple rotation (you can see the grid moving in two dimensions).
Join us on Discord: discord.gg/jmf6M3z7XS
Follow me on Twitter: twitter.com/WeirdBoyJim
Support the channel on Patreon: www.patreon.com/JamesSharman
The no-nonsense, practical, calm and restrained way with which you deliver your explanations is excellent.
High praise, glad it’s working for you. Better than the comments that just complain about my long hair 🤣
Thank you James for taking the time to build your computer and record and edit these videos. I find all your work both fascinating and inspiring. Keep at it and know you have lots of fans. Don't let life get you down, we all are behind you 100%! Many thanks.
Thanks Anthony! Glad you are enjoying the videos!
Flashbacks to Fractint palette cycling .... it's like it's 1992 all over again. :)
The vortex is superb! (And this is an upvote for anextras video of how it's done)
I loved Fractint! Glad you liked it!
I had no computer at home and someone noticed I had one of the few VGAs at work and said "you've got to see this" and I was all "wow! I thought you needed a supercomputer" and within a couple of weeks I had my first 286 at home! I first started to learn C by studying a printout of the Fractint source.
The normal mapping demo was crazy!
Yeah, I like it. Got some interesting plans for that technique.
You are simply amazing my dude. Never ceases to amaze me what you're doing on your custom hardware.
Glad you are still enjoying the videos!
If Ben Eater didn't inspire hobby builders, you definitely will !! Thanks for the exposition !
High praise thank you!
What an insane achievement. Like, INSANE! It's just hard to imagine how proud you must be of reaching the milestones. A sincere congratulation on this amazing achievement
Thanks! I’m happy people are finding it interesting!
nice achievement, I understood only half of it but learned a few things. I am still amazed how clean a breadboard can look like.
I was really pleased with this one, took a bit of time though.
Seriously, impressive results. I always come away learning something and thinking about what is possible.
As always, thanks for this.
Thanks! Good to hear
Just discovered this series and I'm seriously impressed. Love the explanations, lots of great practical stuff from someone who has had immense experience in design and software engineering. Even as a game and hardware dev from way, way back, I learned a few neat tricks there.
Thanks Andy, glad you have been finding it interesting!
It's all magic !!!! Looks brilliant, and even better than the demos was the beautiful breadboard wiring... You should photograph that and stick it on the wall !!!!!
Thanks Seon! It is indeed quite rewarding to make a really tidy breadboard up!
And with this simple RAMDAC you built, you have surpassed the color capabilities of the original VGA which in Mode 0x13 only had 6Bit/Channel (~260k Colors) in their palette IIRC
Yeah, the earliest ones were 6 bit, far easier to make a 6 bit ladder with tolerance actually. I did think about 565 for a while but didn’t want to short cut.
Your use of the prototype board is super clean! I've started very slightly tinkering with electronics, and I currently just use a bunch of jumper wires! It's terrible! :D
Thanks! I usually have a mix, on this one you can see a few signal interconnects use jumper wires. This circuit is running at just over 25mhz though so it's benefits from being careful with the wiring.
I want to make Lo-Fi soft and today i started to soft soft tutorials. I see that you are teacNice tutorialng us very carefully and simple, i like that
Not sure I understand
Brilliant work James. Love how you also include some of the hardware issues you need to resolve, like excessive propagation delays etc. It would be good to also walk us through some aspects of your software development as well, although I appreciate your concerns about video length. Maybe, a seperate video taking us through your demo software development? Covering the software development that compliments the hardware development, would be awesome. But brilliant work either way. 👍🏼
Thanks Digicool, programming can be a hard sell but I'll probably include a bit more when I make the extras video to describe how the vortex effect works.
Really love how all this is all turning out.
Oh, and there are many more effects that can be done with palette changes, such as an image dissolve with a static image.
You can do fades easy enough but dissolves often look a bit ropey since index use is rarely even.
Very nice. If you have spare ram, maybe you can give each sprite its own palette - that would surly open up options for graphic effects.
The last demo looks like pallet swapping plus beam racing. With perhaps a bit of horizontal scroll? Nice effect.
Thanks! I have an ultra simple plan to use the extra ram (It's just one chip), I don't want to talk about the sprite plans until I get to that video but there is a reason why that would be a bit more complex.
It was neat to see the parrots as you messed with the wires and chips. Something that *seems* so digital is analog in spots. Sorry if that doesn't make any sense lol.
Indeed, It's just the last little bit that is supposed to be analogue but when I was swapping the multiplexers around there were also floating lines on some of the inputs.
Awesome video! I'm looking forward to the PCB build and test!
So am I! Partial because there is an annoying bit of backplane planning I need to do before hand
as always i'm blown away by the performance of your build. 🙂
Thanks Kirk
You could have named this "Palette and Wiring Top Tips" - some really good stuff here! Thank you, James.
Thanks! It's always worth putting the effort into a good breadboard!
Wonderful! Yet again I am stunned! Looking forward to see games running on this jewel!
Thanks! Good to hear you are still enjoying!
Another spectacular result in expanding the capability of your VGA circuitry! Thank you so much for these videos.
Thanks! Great to hear you are finding them interesting!
Your work is awesome. I'm really enjoying these videos and, I'm learning a lot. Thanks for sharing!
Thanks! Glad you enjoyed!
Excellent work, even more wonderful is that you reply to comments, that’s more and more rare on YT these days.
Thanks! I try and reply to everything but.if the level of comments grows much more i might have to cut back a bit.
Hi James, that’s absolutely stunning stuff! Have to mention old arcade boards with various small (22pF-100pF) tagged on to slow an enable signal down and without all sorts of horrid mistiming contentions.
Those kind of things have indeed been done to fix issues like this, I'm trying to get it right before converting to pcb though.
Nice work James! This should be able now to run a version of the bad apple demo without just showing frames out of memory! I‘m thinking of implementing your build in an UpDuino this winter as I finally want to learn and tinker with VHDL/Verilog on those small affordable Ice40 FPGAs. Keep up your work! Thanks for this great series.
Thanks! I'll have to take a look at what data is around for that. I fear it will still be too much until I have some storage I can stream from.
You might be interested in this: th-cam.com/video/Y1_MUXKX-oY/w-d-xo.html
@@weirdboyjim nice 👍
This reminds me the days of PC demo scene in 1990s. Great work!
Those were the good old days!
Seeing that demo was an instant subscribe for me. Looks like I've got a lot of videos to catch up on!
Ha Ha! I hope the rest of my project(s) live up to expectations!
Thanks James. I just got back from visiting family and catching up on videos. Looking fantastic. One of these days perhaps you can shoot a video discussing the various things you've learned about setting up breadboards. Take care.
Thanks! I’ll add it to the video ideas list.
Nice video showing warts and all in prototype wiring, and now we can see it in better detail and colour. :-)
What warts? 😜
Wow! This series is amazing and I love your pacing and gentle tone as well. Keep this up!!!
Thanks! It's good to hear you are enjoying the series!
This is insane, you are really skilled. Thanks for sharing this, great stuff.
Thanks! Glad you are finding it interesting!
That is just very cool, well done. My first thought with the extra address lines for the ram would be to have multiple pallet banks, so you could just swap between them. That could make for some interesting effects as you could swap the whole pallet every line. Maybe make it so any write to the 4th byte a color set a latch for the pallet bank, as that might be fairly easy to add to what you already have in the circuit.
Why yes, you could do that. 😎
I always wondered what a RAMDAC was. Very cool series and great demos of the power of the palette! Subbed!
Welcome! Glad to hear you are finding it interesting!
Thanks for the video. Fascinating with what you achieved so far with discrete components.
Thanks Johan, glad you are finding it interesting.
Wonderful, beautiful work. WRT: the color pallet... A lot of the colors are very close together and many resemble "black." I wonder if you can get more colors on-screen at one time taking advantage of the fact that so many are close together (effectively reducing the color pallet from 16M to a few hundred thousand)? Also, if you know that the color to the left of a pixel is "close" to the color to the right (on a scan line), there's no need to change THAT pixel. If you reduce the color pallet from 16M down to a few hundred thousand (because so many colors are similar), and only update the 3-4 pixels on a scan line that are "furthest off", you might be able to get an Amiga "HAM" effect. Very interesting work. Continued Success!
I as reading your comment thinking “he’s reinventing ham”. You have to remember that the palette itself a a way of reducing the massive range of colours down to a working set that is more useful.
With so much unused RAM for the palette i could imagine a register and some logic providing multiple palettes. That way you do not need to change all the colors between the scanlines, but just select the preinitialized palette using the register byte.
That was my thought, I actually think I can do that with just one extra chip
Some very nice parrots there! One thought I had, with connecting the scope reducing the number of glitches, maybe some extra capacitance in the right places would help? Probably not worth it on the breadboards anyway...
I imagine one of the ideas to make use of the extra RAM would be to allow multiple palettes and quickly switch between them?
I'd be very interested in an extras video explaining how the vortex demo works.
The difference with the scope attached is interesting, the capacitance was pushing the rising edge back slightly, in theory we could get a little bit more speed out of the system by delaying the output latch signal such that it allowed the ram lookup to overlap the address for the next pixel passing through the multiplexer, but that would mean we would be accounting for fractions of a cycle later stages in the circuit. Yeah, that's my thinking on the palette ram, I think I can add that with just one extra 574'.
Yes... instead of double buffering a screen it would be the same principle just instead switching the palette. So you'd have double, double buffering. 🤣
Incredible work. Really well explained as well.
Thanks Neil, glad you enjoy!
Looking good James! I did similar programming on the C64 writing code synchronized with the TV's electron beam. Man did yopu have to count processor cycles!
You do realize that part would be trivial with hardware interrupts though? Just saying! 😁
Got you on that, the best beam racing I've done on other platforms was using polling rather than interrupts. You can avoid latency that way.
This is getting very interesting. The results are fantastic. I am hoping to see a high rez version of this. Is that something you are looking to accomplish and are you going to eventually shrink the size of this setup? Have you thought about using programmable logic chips like PAL's and GAL's to minimize the number of logic IC's?
James said before that he thinks using pals and gals on this build to be some sort of cheating.
Thanks GORF, no plans to use programmable devices like PAL's/GAL's maybe on future builds to shortcut things I've already done.
@@cj09beira However, he is already using ROMs to decode instructions through the pipeline, and to produce graphic card signals, which is also kind of “cheating”, if you concede that, because that’s ultimately a brute force way to get custom combinational logic. Also a simple PAL was part of the 6502 instruction decoding hardware, so I wouldn’t see using them in this project as going too far.
In fact, I regard PLAs configured as simple PALs as far less cheating than ROMs, just look at the level of integration and number of transistors of just one single chip of the latter, which may be far greater than the rest of chips in this processor combined!
Ah, I finally understand the reason you get snow on the screen if updating the palette at the wrong time - even if the colour you’re updating isn’t in use.
You mean on regular PC vga cards? Yeah, back in the 90's I hit that issue. It was the first time I started to have to synchronize code with the blanking intervals.
Yes, exactly that. VGA mode 13h.
As everyone else says, this is really amazing work.
Thanks rinner, I appreciate that!
@@weirdboyjim Your detailed explanation of the design is especially appreciated. I'd like to build my own one of these and follow along with you - are your CPU PCB designs available by chance? I'm still early in the CPU playlist so my apologies if you have already covered that question before.
Nice result! I think the vortex animation is done by palette cycling and the movement is done with hardware scrolling.
There's a GDC talk called 8 Bit & 8 Bitish Graphics, showing some really impressive palette cycling demos, maybe you can show some of them on your cpu?
The underlying effect is obviously palette manipulation but it's more than a simple cycling, the grid moves in two dimensions. Once I had that working I added the scrolling on top for extra variation (because why not!). Yeah, lots of nice tricks about, I saw one like this in the early 90's and it stuck in my head so I had to try it.
yeah I thought the same. Nice one james!
Some random palette trivia I came across this week: Terminal Velocity / Fury 3 had additional look up tables to shading and alpha blending within a fixed palette.
I'm fighting the urge to raycast some terrain.
I used a similar technique back in the day. I documented it in my dissertation (1994) but commercially it was first used in Swiv3D (1996). My system did a translation between a virtual pallet and the screen palette which gave me better intensity gradients.
Plasma field fractal shows palette shifting off really well.
Indeed, but don't underestimate the benefit of having the mandlebrot code already written. ;-)
Always a pleasure to watch, thanks for sharing!
Well, thank you for watching!
Love it, very very cool. You could use the rest of the ram for 7 more palettes and then a 3 bit selector for each row of the display - sort of copper list style...?
Thanks Charlie! There is actually space for 32 palettes, I worked out a circuit that only adds one extra chip. Interesting idea to make them row selected, would take a bunch of extra circuitry. My thought was just for quick change.
@@weirdboyjim Circuitry is what you do best James, and think of the possibilities!
Although if you could change it with the CPU in the hblank that gets you kind of there I guess, less sexy tho...
Oohh 49min of goodness! 🎉
Hope it lives up to expectations!
Nice work! I've shied away from using multiplexers for this kind of thing for speed reasons. My main plan there is to use transceivers as usual, so that the framebuffer can drive the palette address directly without extra propagation delay, but turning off the framebuffer's output enable during palette updates. I don't mind if palette updates cause glitches when they occur during the visible part of the frame. Or just use dual port RAM for this part!
Thanks George! Yeah you could replace the address multiplexers with a pair of 541's driven by the same enable lines as used for the data. Chip count would be the same but there is a significant size different between so-16's and so-20's. You actually used to get exactly this kind of screen fuzz on older vga card's when you did a palette update, discovering that was the first time I had to start worrying about the blanking intervals in a practical way.
Ha! Dual port RAM is a great answer to all memory contention questions that don't include the words "part cost". 😧
@@weirdboyjim Yes! Now FPGAs are everywhere, physical dual port RAM is a sales code for "legacy hardware hackers will accept any BOM cost!"
@@weirdboyjim So I thought - however in really small sizes it does seem to be less horrific!
The other thing I was considering for reducing the amount of wiring and bus sharing was using the overscan framebuffer memory to provide the palette write addresses, just like it normally does, so that no sharing is needed there. Maybe the even bytes during the overscan provide data to write, and odd bytes provide addresses to write them to. It's getting a bit silly then, but would also mean "copper" effects would not require active cpu intervention.
Amazing work! Have you thought about using a planar layout for the palette instead of the current packed pixel layout? That'd remove the padding byte between each entry, thought maybe updating the palette would become more complicated
You mean having 256 bytes of red then 256 bytes of green etc… that would indeed make it easier to use the remaining bytes but it would be a pain to update the individual entries.
Just a reminder to add this latest "VGA from scratch" video to your TH-cam playlist for this series
I always wait a while before adding videos to play lists. It's annoying but the TH-cam algorithm can be tricky.
if you want to be fancy, you could hook the extra address lines from the palette rams to a latch and have the ability to 'cycle' 32? different palettes just by writing a different value into the latch.
obviously you have to setup the data in the palette rams before you can cycle them but it allows rapid switching of on screen colors for things like different images or even fancy color swapping effects all by changing a single byte
That was my ideas as well, I worked out a way to do it with just one extra chip.
@@weirdboyjim just a latch using the extra write enable from the demux yeah?
means the latch is duplicated many times over the address space and means you lose the line for other things, but is a single chip solution.
unless you were thinking of something else?
Why hammer the keys on the keyboard every time you type?
I don’t
Nice demo effect. I assume it starts with a static image and you do palette cycling. Then I guess there is some scrolling in various directions?
Yes to the scrolling, the pallete manipulation is a bit more complicated than regular cycling but that's the general principle.
You could theoretically add a fairly low cost high resolution output mode (double horizontal resolution) by changing the way those final line drivers work coming out of the palette circuit. Normally they just let through the whole 8-bit palette value. However, if you take a double pixel clock, and in "hi-res mode" you output either the high 4 bits or low 4 bits of the palette value to the top 4 bits of each DAC, you can fiddle the palette to essentially pick 4 bits of each pixel byte on odd/even hi-res pixels.
Half the colour bit depth, but double the pixel resolution - good enough for a text mode? It'd involve switching from 1x8 bit line driver to 3x4 bit (faster?) line drivers, but would avoid making any changes to the rest of the video circuitry.
Since you've got 8K palette chips, you could also switch palettes on each horizonal line (use a register to drive the top few bits of the palette RAM), and with a bit more palette tweaking, double the vertical resolution (again, half the colour bit depth - you'd be down to a 4 colour mode). The advantage being for minimal changes (and without having to speed up the rest of the video circuitry), you've got a big step up in resolution.
Really enjoying the series - it's nice to see the old-school demo tricks being played with.
Indeed you could. The plan is to have some tile data containing 8x8 tiles that the current "pixels" in the tile map will select. You could create a 16 color psudo 160x60 or 80x120 display of the type you describe just by setting the correct tile data. You could even make a 160x120 4 color mode. Glad you are enjoying the series.
I remember the Amiga HAM mode. That was a 256 color table but the primary color was set in the first pixel. The color was then changed in the three other pixels. Although the resolution was lower as a result, it looked as if more colors could be displayed. In this way, an 8-bit color palette became a 12 or 16-bit color palette.
But it wasn't really 16 bit color because 4 pixels always determined the color.
A new color could only be set in the 5th to 8th pixel.
It was a cool system though. Some of the best static images of there time!
I was just asking about HAM... I should have read before I typed.;)
you do a constant increase in some rotation value and map a decrement against the distance from the center to get your next spiral position, I am wondering if you map the transition of the pixels form left to right somehow into the vertical handling hardware to get that "sucked down forever" effect. This is kind of similar to a Sheppard effect in sound. The output goes to the input making a seemingly endless falling or rising cycle.
you do some extra wiggling of the hardware with wraparounds turned on to do the "wiggling around Brownian motion" probably two simple randomised sine functions overlaid
The scrolling is a couple of sine waves , I’ll explain the spiral in a video.
@@weirdboyjim It looks like a set of block /B/ being repeated, are you feeding the output of the 'B type' block into multiple points at once? and scrolling the opposite way on one of the hardware buffers, or maybe going one bit across in position? damn clever stuff anyway. I award myself several "trier" points ;)
@@weirdboyjim Are you lighting that? I mean it's not like I am obsessively watching it frame by frame or anything, that would just be weird
Marvelous, I love this graphics stuff !....cheers.
Thanks andymouse!
As a (semi)-educated guess, I think there's an underlying bitmap with a static image and you're just turning a few colours in the palette on per frame to give the general impression of animation.
But I see that the vortex moves around so perhaps you're also moving the displayed window around with the hardware scrolling feature in at least the x direction.( Maybe y too!)
Pretty much, but for palette animation's the challenge is to decode what the image contains and what is being done to the palette.
Amazing final effect! You ended up with mostly what IBM did with VGA in mode 13h 🙂
Too bad you don't have the bandwidth to go higher resolution though 😞
Maybe there is some place for CPU opcode optimization if you would resign from using some opcodes to do IO stuff and move to a completely memory mapped system.
Or maybe some simple DMA controller IO to move unaligned (page aligned would be probably easier to build, but unaligned DMA would be simpler to use when programming?) 256 byte blocks around in 'one go' (synchronized to access memory when CPU isn't)?
Glad you like it. Actually the resolution is more about the addressable memory, that final effect isn't changing the core buffer contents so higher resolution would have worked fine, it would have needed a paging schema to address a larger frame buffer though. The next build will be able to address more memory.
@@weirdboyjim I'm loving the series from day one. For a handful of 74xx logic the end result is amazing.
The way you can just remove and add chips while the VGA is running (39:20) is crazy interesting! I mean look at the screen!
I like the immediate feedback, to be clear though this is not a recommended way to treat chips. 😅
My guess at how the final demo works:
I think you are using the palette to animate the swirl animation. My guess is that you have several different palette slots dedicated to the vertical bars, and several dedicated to the swirling lines. then you update the palette so that the active frame of the animation is brightest, falling in brightness on both sides. I think you are also using the scroll buffers to animate side to side and very slightly up and down, which hides the fact that the swirl pattern repeats quite rapidly.
I do use the schooling like that, sounds like you are part way there with the palette operations.
Ha the last one is pretty easy, you are using the scroll registers to move the vortex around and you shift palette to make it appear rotating.
As a fun fact the SEGA logo on the genesis in Sonic 3d used a similar palette technique to output a video at reduced color depth but fast enough to make it look smooth.
Yes to the scrolling, it is indeed palette manipulation but I intended the question to be more specific about what the image contained and what was being done to the palette.
Thank you James for this awesome video.
Glad you enjoyed it Leonardo.
Each “square” mapped onto the vortex is made up of 256 individual colours (8x8) so you could potentially map any repeating pattern onto the tube. Depending on how you arrange the indices, scroll left/right and up/down is some relatively simple offsetting of the palette data. But you have to fill all 1kb in the vertical blanking interval, right?
With some pre-calculated palettes you could rotate the pattern, morph it, etc. limited only by ram.
Bingo! I like to think of it as an 16x16 texture mapped onto the surface. yeah I have to update the entire pallet each frame. The code runs lightly over (hence the fuzz) but I could probably optimize it slight to get rid of that.
@@weirdboyjim Perhaps use that unused RAM area to store the next palette, like one would do with double buffering the screen. You could then update the next palette in line during the screen draw and simply switch it out on the vsync.
@@GORF_EMPIRE That's clever! You could even have several palettes set up and dynamically switch between them. Those 7164 RAMs would not be such a waste after all.
How about putting the remaining memory in the colour table RAM chips to good use by storing multiple palletes and allowing switching between them?
I’ve worked out a way to do exactly that with only one chip
"What you normally expect to see in a normal map"... :D
Not exactly what you are commenting here but most normal maps encode a normal vector so have only 2 degrees of freedom, Blue normally encodes the component pointing away from the surface so negative values are unusual. This means the colour cube is reduced to points on a hemisphere which gives the image a distinct look that anyone who has worked with them can spot a mile away.
For the fourth channel, you could use it for alpha/intensity information, it might be overkill and registers might have more utility. And of course implementing alpha would mean more chips and a fair bit of rethink of the circuit, I'd imagine.
Alpha is everyone's first thought for the 4th color byte but what would it be blending with?
@@weirdboyjim I know, I realized that after a while... What "new" color could be made. Think we are so used to the incredibly complex computers that are our graphics cards that we just see "Alpha" as something that just happens.
It might be used for some HW color blending, but I now think Alpha is a bit of a red herring. And using it for control signalling (if needed) is probably easier and better utility.
But I can't really figure out what those controls might be... I have a half formed idea, can we reverse the data flow? Can we use the "4th byte" read back info? Of what, I am not really sure, but it was an idea I had.
I wonder how difficult hardware antialiasing would be. For horizontal, surely a small capacitor on the DAC outputs would do it, but for vertical you'd have to get tricksy.
Wait until the tiledata is there before you worry about that! What you are describing is likely to end up as a blur at best which is not what you want in most circumstances.
@@weirdboyjim lol, that's fair, especially with such large pixels!
Love this project and your presentation of it. :D
Glad you are enjoying it! Thanks!
My guess on the vortex demo: I think the vortex demo is color cycling palette entries (obviously) but the visible image is a subset of a larger bitmap, which is being scrolled left and right and at a faster rate but with less amplitude, scrolling up and down.... (essentially the x,y offset of the origin of the region of the larger image is being moved around, with the new image being blitted to the video memory?)
You learned me lot. Thank you, good work!
Glad you found it interesting!
Can you run DOS on this machine
Nah, dos started out on 16 bit x86 machines, I’m still only 8-bit
ref: 44:28
Technically not the same, but this method of changing color give me a feeling of the HAM mode on the Amiga graphics and it is very close to the way the old C64 manged to add a lot more color to the sprites. 🙂
Other people have talked about HAM, but on the Amiga this kind of beam racing is exactly the kind of work the Copper list was added to automate.
Are you perhaps animating it by using a mix of packed frames with continuous indices (ex 0-3 frame 0, 4-7 frame 1.. etc) in the palette and some stupidly fast memory copying going on? :)
Not 100% sure what you are describing there, the core effect is done just by updating the palette without modifying any of the main framebuffer.
@@weirdboyjim No news there. I'm horrible at describing stuff lol.
It's an old trick from the console days. You'd pack four frames into one and animate it by changing the palette while at the same time update the hidden buffer with a new batch of data, switch buffer, animate that and so on :)
This is soooooo amazing !!!!!!!!!!!!!!!
Glad you like it!
In that vortex demo, do you have an animation of a sort of tunnel with the far end moving back and forth and the color indices going from low to high in a banded spiral (or vice versa) based on distance down the tunnel? Then just cycle a soft-edged green band through the palette every frame for the spiral animation effect?
The spiral itself is a static image, I move the image around with the scroll registers but the spiraling effect is created by animating the palette.
@@weirdboyjim Nice. I love this kind of art and effect.
NICE! love to see the progress
Glad you like it!
Oh my god it has shading...
Can it shade a coloured image though?
Seriously, how cool can this get... I suck at original programs, but I'll port something cool for sure
It’s all trickery!
What about a Class A buffer amp like the 5W Class A amplifier but with a supply of 9V to buffer the output of the R2R Ladder network and not burn out the transistors.
I talk about maybe using a buffer op amp in the DAC video but I wasn’t really worried about 0.7 volts pulling too much current through 75 Ohms on a line driver output.
Really love the series, but you mentioned a simulator does this allows you to simulate the chips or the entire machine? Is this something open source?
The simulator is just binary at the moment, mostly due to code quality shame
Implement the parrots using palette switching to get closer to 2k colours? 😎
I actually ran a test doing that, it doesn’t look much different without looking very closely.
@@weirdboyjim interesting. I’m guessing that the pixel density is what’s holding back fidelity at this point then.
Love this. Very very nice.
Thanks Tobias! Nice that people find it interesting
Fantastic video
Thanks!
As always, awesome work! 😎
Thanks!
Ha, I almost skipped this video, thought I'd seen it already :) So that pic is pre-rendered (like the normal map, but max double width? or 1.5 width?), it has color palette cycling, where "black" adds to the _illusion_ of a background (space), but the center of the "vortex" is moving (wobbling up and down too, by my eyes), so there is a _screen shift_ left & right, and every time it moves (shifts left or right) you add the missing _vertical pixel line_ (s), with a similar technique used to "wobble up and down" (if thats what its doing) but limited to (say) 2 _horizontal pixel line_ s in movement (instead of 70% of the screen width). Yeah? Very cheesy, and very retro technique (especially @ 4MHz, if so used), and I am pretty sure I saw a (purple?) _torus_ doing the same at some point in the early days of VGA (EGA?) demos (circa 87/89 in NZ, took a while to make it into the local computer shop) ..
I’ll definitely do a video explaining it, not that difficult but easier to show then explain in text.
@@weirdboyjim I bet I'm over thinking it, there is a technique where you can draw single pictures that produce the same visualization
Would it be possible to build a second CPU unit and make this thing multicore?
I definitely want to do some multi-processing experimentation at some point but it would be time consuming to multiply out the circuitry.
Why do we need line drivers? Why can't we simply get data straight from the RAM? It comes with its own output enable, so, what are the drivers for then?
The line drivers are for writing data to the RAM chops. The data lines are both output AND input so during a write we disable output enable on the ram and enable it on the line driver to put the contents of memory data onto the inputs.
Hello James. Did you ever wonder if this computer could interface with a 3D Printer?
Wouldn’t be too tough through the serial port.
What about reducing each board to a FPGA and put the FPGAs onto one board connect up in a way that replicates the way your graphics card build was working.
You could, but personally I’d either fpga it all or want to keep it like this.
20:36 nice chip face lmao
A little pareidolia?
Don't you need a CLUT so that that you get the expected color out for the code that was input.
This video is me making a CLUT
Impressed!
Glad you like!
Do you think this setup could handle Bad Apple?
I’ve promIsed someone else I’ll take a look when I get some time.
Hi James, possibly off topic question, I recently designed a discrete TTL circuit to replace a unavailable custom IC for an arcade board, and then went on to design/order a PCB (JLCPCB if course) I decided on SOIC packages… PCB arrived and only then (DOH!) realised some parts were hens teeth in SOIC… Any suggestions?
Since redesigned in TTL, but of course it’s much bigger… bugger lol 😅
Well, my big bit of advice is that I add items to my shopping basked as I add them to the schematic. That's actually why the bus control board ended up with 2 138's replacing a 139.
That's a pain, what did you have trouble finding?
@@weirdboyjim 74LS191,541,157 Yes a real pain, but I have the TTL version arrive today, will be testing shortly, hopefully the transition from breadboard thru EasyEDA/JLCPCB will be a happy one :) Thanks James
I would say palette rotation and hardware scrolling
Yeah, there is scrolling layered on top adds a little easy variation. The underlying effect is obviously palette manipulation but it's more than a simple rotation (you can see the grid moving in two dimensions).
Welcome back!
I was never gone, this video took much longer than the average to make and life has left me with less free time for the last couple of months.
Fun. :-)
Glad you liked