VGA Sprites on a 6502 breadboard computer
Вставка
- Опубліковано 11 лип 2021
- How can we move and animate a large sprite at 60Hz? Here are the main details of my first pass sprite add-on for the Simple 6502 VGA project, which supports just a single 256x256 3-colour sprite at the moment.
This also includes some clock line ringing/reflection issues and mitigations. This website seems to have good information about these techniques: www.marvintest.com/KB/Q200196...
Do let me know if I skipped any details you'd have been interested in, or if anything was unclear! - Наука та технологія
I'm considering explaining separately how the counters work together to define the region of the screen, as I put that together before I started filming properly and realised later that I didn't really cover it properly here - let me know if you're interested in that!
That sounds like a good #shorts topic
@@minnerlas1730 It might need to be longer than a minute though! I could probably do something similar about techniques for chaining counters and propagation delay within a minute, that could be interesting to try
@@GeorgeFoot that's still an interesting topic so go ahead
@@GeorgeFoot to more detail the better, George. Love this series of videos.
Yep. deffo.
This project is basically a re-enactment of the development of the personal computer.
Very cool that you show the mistakes and failure modes so that we can learn to recognize them as well.
I'm going to need to watch this at least 5 times to get my head around what you've achieved here. Great job showing the practical issues encountered when designing and building stuff on breadboards.
Thanks, and yes there's a lot going on. I was on the fence about cutting it into two pieces and going a bit slower, but I didn't want to leave it without something interesting on the screen by the end!
I'm on my second watch through it... Nope still lost :). I'm just dumb I think.
@@genxtech5584 me too 🤧
All the mystery of graphics , decades of “black box” is suddenly so clear to me!!! Thank sir!! Cheers!!
Great video! I really like that you include all the stages in your implementation process and talk through how you fixed things when they didn’t go as planned.
Thanks! I don't always do that as it can be confusing, but I did try to in this case.
Simply awesome man, very cool stuff your doing
Thanks Ken!
Wow, this was a labor of love. I used sprites during the eight bit era and always wondered how they worked. It gave me much more respect for the video chips of that era.
Been watching your stuff intently as I'm learning options for my homebrew CPU called SPAM-1
Thanks for the work
I've been working on/off on my own VGA with discrete logic for a long time now but suffer from both a lack of knowledge and trying to make it overly complicated too soon. I'm going back to the drawing board after watching some of your videos. Amazing work here, keep publishing.
My 160x100 circuit was a very good starting point, it helped on the software side that the coordinates fitted into a single byte and there was one byte per pixel because the 6502 is well suited for that. 320x200 is also a great sweet spot and is the resolution that most of games used until 3D hardware acceleration, so it's high enough to do a lot of interesting graphics and usable text. Realistically with the era of technology I'm using that's about as high as you got as well; 640x200 was also a CGA resolution I think, with only two colours except in text mode. Anything later than CGA was using custom ICs of one kind of another.
Very nice! That's a circuit that could be easily done in a very small CPLD or a big PLD, but I'm liking the discrete method you're using for the prototype. Thanks, also, for the info about transmission line termination. It's not really a very scientific method, but it gets the job done quickly and effectively without the need to do any extremely complicated math. Thanks for this video. It's great stuff!
Extremely impressive! My knowledge on homebrew design and prototyping is allot more limited than yours, But.. One way I've thought of implementing VGA on homebrews is driving an ISA card. (I know it has been done a few times before, But it seems the most straight forward way). To see you simplify it with that IC really means allot to the homebrew community. Just subbed and looking forward to more content.
I was trying to do this a year or two ago. Thanks for sharing.
Thank you for teaching me how hardware sprites work. Never understood before now.
This is one way at least - I'm glad it was useful!
Brilliant :) Funny enough, I never didn't get how the sprites were done. Your explanation makes it crystal clear now. So simple, so obvious... now that I know ;)
And from the whole serie, I get why the video cards started to change paradigm, from shared memory with the cpu to a complete different system with some registers as intf. From being tightly coupled with the cpu clock to autonomous system. I hope you will continue this serie as it is very entertaining and informative
Yes absolutely, I am hoping to gradually shift to a command-driven interface and build more assists into the video circuit, as an analogue to what happened in the PC world.
I also have some sketches of designs for a system to support fairly large numbers of smaller sprites on the screen simultaneously, but I'll only pursue it if I can do it without needing huge numbers of extra components. I think I can but it needs more thought.
I'm going to have to have a read-up on line termination... when digital stuff starts to get too high frequency, we get dangerously close to RF black magic. ;)
A topic like this, especially with "failures included", will probably always be "a little bit long" in the final edit. I'm surprised you got it down to 30mins, so (IMHO) dont worry about that too much
Nice work. A fun, educational (and visually rewarding) project. But, you really should have made this into perhaps a 3 part (or more) series, so that those without good existing technical understanding would also be able to follow along, step-by-step, and thus be educated. Keep up the awesome work!
Thanks for the feedback!
I hope you will revisit this exciting project in the future.
A single 32x32 sprite (or even just 16x16) would be usable as a pointer. It may be nice if you could consolidate the circuit into a PCB. Maybe with connectors for future expansions. A true TTL based "graphics card" is something that i have not seen implemented anywhere.
The following features are needed for a retro-computer graphics card in my opinion.
mandatory:
- direct text mode (40x25 or greater)
- direct graphics mode (320x200 or greater)
- sprite(s) (one 32x32 pointer or greater)
optional:
- direct memory mapped frame buffer (optionally windowed)
- hardware 'zoom' via pixel/line doubling (like 640x480 -> 320x240 -> 160x120) for different "video modes"
- fill mode (hold a color per line until another color is selected - optimization for line drawing on a solid background)
- multiple layers
Thank you for your hard work and documentation on this project
Glad you liked it! The single huge sprite is not very useful, I am interested in getting a large number of small sprites to work though. The challenge is doing so without having separate timers and ROMs for each sprite. I have some designs in mind though that could do this. I'd also say the 8-bit Atari designs were very interesting.
@@GeorgeFoot Ooh, I've been trying to figure out how that would work too. Have you by chance made any progress on this? Or know of a place I could look to for inspiration?
I’m so happy I finally got around to watching this! The tempo was a bit too high for me to grasp everything in one go, so in my case you could’ve chopped it into three 20 min to half hour videos with a few more details. For instance I didn’t understand how exactly the 6502 controls the sprite location - though it is plenty of help if I wanted to add sprites to my own build and then I’d watch it a few more times anyway.
I know it’s been a year but kudos on this one!
Oh, and edit P.S: Always have 100nF per IC - you won’t always be lucky and catch it at the right time. Also I had a lot of success moving from breadboard to PCB on a module to module basis. Less mess on the desk and you can still breadboard the problem at hand - and PCB’s are a lot cheaper than time these days :D
Thanks, good feedback - I didn't split it up because it was hard to find a point where there would be a satisfying conclusion. Perhaps it's worth going back and explaining some of that in a bit more detail, in shorter recap videos.
I don't generally bother with per-IC capacitors because it's rarely made a significant different, on the breadboard - I've had a lot of success without using them, and generally when there has been instability, adding per-IC capacitors alone hasn't particularly helped. As you see in this video, when push comes to shove other techniques like adding terminating resistors, or rerouting wiring (star topology rather than daisy-chaining signals) have been what's made the difference. My general conclusion is that the breadboard environment is so uncontrolled, the electronic signals will never be particularly high quality, so the lack of decoulping capacitors is a drop in the ocean!
I hear you regarding PCBs though. The reason I don't generally do that is that I don't like the waste of having to order 5 and throw 4 away. Also my designs tend to evolve rather suddenly, and it's hard to stomach the lead time on making PCBs. I ought to get better at consciously drawing a line under a project, and saying it's done!
I'm waiting for him to design an HDMI 2.1 circuit ok a breadboard.
Very interesting! I have had a lot of trouble in my project from counters glitching and certainly timing issues, nothing that bigger capacitors could fix. So the use of these terminator resistors is interesting. I wonder did you never use an oscilloscope to debug any of this? I don't have a storage scope so for me it's very hard to debug glitches, bouncing, and ringing. It's cool to see that you didn't need any scope to debug your issues. You really don't?
I had an old analog scope when developing these things but it wasn't much help for this sort of thing. More recently I got a modern DSO which is useful, but still not very convenient as I didn't have a decent dedicated space to set this sort of thing up in. Moving forwards I have more room now and may be able to set up a better workspace!
To get the best results, the impedance of the signal source and the impedance of the load should be matched (= the same).
Look up "impedance matching".
So if your oscillator has 50 Ohms output impedance, use a 50 ohms resistor at the load.
Or just use some buffers to distribute the clock signal (buffers inputs get fed from the clock, the output of each buffer goest to one or more ICs that need the clock signal)
If you want to get fancy, there are specialized ICs for clock distribution.
Wow again! This is inspiring. When it's finished, it's going to be an awesome VGA card. I can only imagine the next step will be text, and hardware scrolling? Here's to hoping. ;-)
Those are good features, yes. I don't have a specific plan for the end point though. There are a few other things that could be next - multiple sprites, palette control, maybe tiled backgrounds, and I really want to change the interface to make it faster and have fewer address lines. I'm also interested in hardware acceleration. I also read about the Atari 800, wow what an interesting design.
@@GeorgeFoot Hardware scrolling is surprisingly simple. It's just matter of offsetting the address location before the sync signals start.
@@bobweiram6321 I've done it like that in another circuit, but it wouldn't work in this one right now because the sync signals are embedded in the image memory. One of the overhauls I'm planning is to move them back into EEPROM so that I can be more creative with the image memory addressing.
I never would have thought of chaining the three shift registers so you'd only have to address the first one. Back in 1982 (I think) I used a 74LS574 (or an LS573) to quickly build a parallel interface adapter for a printer I had bought. I debated on whether or not I should spend the money to use a 6821 PIA but the LS574 worked fine and somehow the latch enable pin even worked for the "strobe" pin to the printer to tell it there was a byte to read. I couldn't believe I had my printer running in just an hour or two.
Wow, what kind of printer was it and what were you plugging it into? I had a Citizen 120D around that era, but it was Epson-compatible so no weird interfacing was needed.
The flip flop shift register idea came from this forum post: stardot.org.uk/forums/viewtopic.php?p=325574#p325574
It's referencing the original ARM Evaluation System that was the first ARM-based product sold, it plugged into a BBC Micro and used it as an I/O interface to allow development of first generation ARM software.
@@GeorgeFoot The printer was some piece of junk that was advertised in Byte I think and took almost *a year* to arrive. My 6502 computer was an Ohio Scientific C1P which was something like the PET computer.
I assume that the sprite data replaces the current pixel data from the framebuffer as the horizontal lines are being drawn? If so, how do you avoid have a mixed colour pixel of framebuffer/sprite?
There’s a multiplexor circuit shown at 4:02 in the video, it switches to the sprite color during the sprite active time on each line
Yep, the multiplexer picks between two sets of 4 inputs, based on a "select" input on pin 1. If pin 1 is low then inputs I0a, I0b, I0c, I0d are routed to the output pins; if pin 1 is high then I1a, I1b, I1c, I1d are passed through instead. In the audio I misspoke and got the letters and numbers backwards compared to the schematic, apologies if that was confusing.
Seriously cool. Are you planning to somehow make this work with shared memory?
Possibly - a complication is that these counters don't have tristate outputs, so we would need extra transceivers. It's also less useful as the point of sprites is really to move large static images around efficiently, and being dynamically updated isn't really the focus. But I agree there is value in being able to load into sprite RAM from SD card for example, at least on startup.
@@GeorgeFoot One easy solution might be to use a register to select a bank of sprite RAM that is visible to the sprite generator while a second bank of RAM is visible to the CPU and just toggle the bank selection to allow changing sprite images while the other bank of images is being displayed. Doubles the ram requirement and adds several chips, though. But the results would allow very fluid and fast updating of sprite memory. Just a thought...
@@Dave5281968 One of the things I try to avoid is excessive wiring and transceivers. Every time a memory IC needs its addresses driven by two different things, you need multiple transceivers or similar to isolate them, and it puts the chip count (and wire count) up a lot. Same for the data buses. Though I am wondering if there's a way to use the sprite counter address outputs somehow even when the CPU is writing. Maybe it's like a second mode in which the address increases with each write, as an alternative to the usual triggers.
is there a github for this project?
would it be worth it to move sync generation to dedicated hardware and get RGBI style 16 colors instead?
I think I will move the sync back to EEPROM like in the initial circuit, and leave the RAM for image data only, to get the same result
@@GeorgeFoot that works too yea
Which chip(s) are you using for the counters? Very enthralled by all this.
These are 74ACT163s, the schematic said HC but it was wrong. Ben Eater uses '161s in his VGA circuit I think, the difference is subtle, I think it's just whether the preset is synchronous or not? Synchronous is probably better here but maybe not a big deal.
@@GeorgeFoot I still have trouble wrapping my head around VGA timing.
@@GeorgeFoot is the act necessary? I have a ton of hct
@@JohnLonerganProjects It's borderline - according to the datasheet it'd be ok at room temperature though. The frequency required is 25.175MHz. I'd guess any of the variants with an A would be fine. Also this only matters for the horizontal counters - the vertical ones can be slower as they never see the fast clock. You could probably make a 16V8 or 22V10 PLD emulate it if you have those available.
M O I R E
Yes, the camera and the screen don't get on very well! It's interesting how the pattern is rotated, and looks a bit like woven fabric.
@@GeorgeFoot for the record, I love moire patterns.
@@GeorgeFoot also, Moire, noun: silk fabric that has been subjected to heat and pressure rollers after weaving to give it a rippled appearance.
(I only found this out when making sure I spelled it correctly.)
What if you shrink the ball down to 50% size to give it more space to bounce? 😉
And also change the background image to something else than that bird? 😉
Yes I could do that, the circuit already supported halving the dimensions with just a single wire changed. For practical use though it needs to support multiple smaller sprites really.
@@GeorgeFoot I thought if the ball be half size, there will be more space for it to bounce freely.
@@zsombor_99 yes, it could look nicer that way
Sounds like it takes even longer just to edit the video as it does to record while troubleshooting/building the circuits.
Haha, it does indeed. Partly due to rewatching the same sections over and over while editing. I enjoy it through.
Maybe add a bus driver, put vga clock on all the inputs for 8 independent outputs?
Yes, or maybe just an inverter driven from the crystal oscillator. The topology there is awful at the moment - there are a few things like this that I'd like to plan into a rebuild, committing to some more concrete specs as well.
DVD screensaver
Now, we just need some sound and we could crank out some simple games! I mean, no sound is fine, but boring.