Join us on Discord: discord.gg/jmf6M3z7XS Follow me on Twitter: twitter.com/WeirdBoyJim Support the channel on Patreon: www.patreon.com/JamesSharman

Feels like we are getting to the point where the VGA output is more complex than the rest of the system. Great job adding yet more features!

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!

Excellent progress! And the added bonus of you knowing the tips and tricks from the game and demo world is the spice that really ties things together.

I'm so glad the algorithm recommended this video to me, I'm tremendously excited to see how this build proceeds!

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 :)

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.

A whole hour of JAM Goodness, this is a soothing balm after battling with doctors for 6 hours straight.

Awesome! Didn't expect such smooth output from a breadboard at that resolution.

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

I particularly like the VGA videos, since I love watching things come to life on screen. The Sharmatronic... sorry, the JAM-1 is coming along! :D

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.

I always find your breadboard layouts a work of art.

Absolutely awesome, James. Well done! 👏

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

Still one of my favorite channels. Amazing, thank you so much for posting!

I love what You are doing. Waiting every next video. Don't stop and good luck!

Wow! Definitely pushing the boundaries of what breadboards can handle there! JAM-1 is looking great.

I can see how proud you are in your outro. You look chuffed to bits. 🎉 Well done!!

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... 🙃

Great stuff. I'm really looking forward to the hardware sprites.

Great stuff James, keep it up!

Such impressive work, I wish I could see it in person!

Wonderfull!! Great progress. Really enjoyed this one.

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 !

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!

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 James ! I always go straight to PCB now for complex prototypes myself as JLC are cheap and quick !

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 😊

It's incredible to watch this and to think about what it must have been like when devices like the NES PPU were made.

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!

Great episode James :)

I am a simple man; i see a new James Sharman video, i hit like. Great video, as always a delight to watch :)

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.

just brilliant.

Amazing work. :)

34:20 Oh hey, it's my Factorio base: A big pile of spaghetti!

You must be so excited doing keyboard entry to the machine directly :)

Beautiful.

that is very impressive. very nice :D

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?

Great video, thanks James. I watched this while working on my own PCBs for work :) What are your plans for the future of this design?

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.

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?

Awesome !....cheers.

Amazoid. Looks so good now. Parrot algo was already pretty dope.

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.

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?

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.

Looks awefully close to running Commander Keen on this thing, wow!

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?

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?

Really neat. :)

I love this project. So are you going to squash it in to an FPGA once you get it figured out?

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 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?

Nice sir

Your breadboards are always so tidy, mine look like someone dropped a bowl of spaghetti on the floor.

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!

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?

Doing an optimization to a set of Floyd-Steinberg tiles to display images would be awesome. 😅

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?

Have you considered paged memory? You could easily have a whole 32kB for tile data

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.

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.

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).

do you reuse old wires or not?

I wonder what is the limit of improving parrot quality with new version of hardware. Maybe adding of dithering can help with limited amount of colors?

10

Too many commercials, James.