Oh BTW please give suggestions on the kind of game to make! Something with a lot of separated verticality would be best, like Space Invaders, Galaga or Breakout.
Realized something last night while taking a leak. Since all the trigger points are even numbers I could divide the line counter by 2 and make it fit inside 1 byte. It would also make double-thick vertical pixels for "free"
@@ericvest9050 I think there actually is. I mean, from an irl standpoint, it kind of makes sense. It is a short break in working, so your brain thinks over things you did before. Maybe taking a leak will find the solution to the universe?
And if you left align your line counter, the switch statement can read only the upper byte, and counting would not need bit masking to preserve the flags. Also, use 8 bit values; the for loop in drawSprite uses twice as many registers and instructions manipulating int i as uint8_t i.
Yeah.. I feel that. Considering the fact I have 5.5 TB on my desktop total (between the internal hard drive, and an external usb hard drive). Only 1.5 TB are free in both of them; 4TB / 5.5 TB. It's mostly a result of recording music, capturing video, programming projects, and many many many games from steam and epic games.
They are both giants in their way, in the same field. Would you call it Ben Squared? [I know that the Unknown Soldier is probably calling himself Ben for the pun value. 'BeNeater': He doesn't want to eat you, Mr. Heckindorm. (I have actually personally known someone called 'Heck'.)]
Remember when programmers optimized their code simply because they cared about efficiency? Ooh, I saved 2 bytes* said no one in at least 30 years 😁 Awesome work man.
I legitimately said that yesterday. I actually said, as a perfect quote, "Ooh! I saved 2 bytes!" This was while writing a program for my TI-85 graphing calculator :)
We needed more storage because programmers stopped making tiny size optimizations. Programmers stopped making tiny size optimizations because we had more storage.
@@easyaspi31415 wrong, we needed more storage because we had more data. Even for the common Joe, data itself adds up to terabytes, there is no getting around it. And big-data is several orders of magnitude further still. Cost of a gigabyte is measured in cents, cost of a programmer in tens of dollars per hour. Saving bytes is seldom appropriate anymore, and no sane company is going to throw away profit just for the sake of nostalgia.
I really got into this micro because of last year's video. I made earrings, a dev board, and a programmer and have been learning assembly as well. Great inspiration for those of us who love building tiny things simply for the challenge. Great content Ben. Keep 'em coming!
@@GreenAppelPie Place i worked clients had circuits we would connect into a working circuit then laser trim various resistor/capacitor networks to their specs and send them to another group have their cans welded. Look just like metal 339's
I'm just starting the video but these kinds of projects are my absolute favorites to see people make videos on. Gotta say I'm really enjoying where you've been going since Element 14.
Reminds me of this one PIC project back in 1990's where I had to make a subroutine and call it every 6 instructions since the processor lacked an interrupt.
I'm halfway down a bottle of cheap vodka and a crazy thought came to me. Imagine if you could give this software to Carol Shaw, David Crane, Larry Kaplan, Bob Whitehead and other old Atari developers. Imagine the crazy stuff those dudes could have come up with if they weren't limited to coding assembly. Oh, and awesome video Ben. Thank you.
Some extra detail about the garbage in mrs.Pacman on the 2600, the lines on the left of the screen are actually due to how the TIA (the atari's graphics chip) handles horizontal repositioning. The Atari had horizontal repositioning registers for all the major graphics and a separate "HMOVE" register you would strobe to commit the changes. If you didn't strobe the HMOVE at the exact right cycle, it would add that garbage to the left of the screen. If I'm not mistaken, most Atari programmers were unaware you could time it correctly and just assumed the garbage was unavoidable. (or they were like me and too lazy to time it correctly). That's why that garbage is present in most games that move the graphics in the middle of the frame.
I clicked on this video thinking I'd watch a few minutes to see if it was interesting. Wound up watching the whole thing and am looking forward to the follow-up. Excellent content! Thanks :D
I've been watching Ben's videos since 2013 (when I was 11), It's done a lot to get me through tough times and I've never felt more at home then when I turn a video of his on.
I absolutely loved this video and am waiting with baited breath for part 2. I have been playing with the smallest PIC chips for a while to challenge myself to write useful code in very little memory but until seeing this I never even thought about bit banging a video signal. I am very tempted to try this with a microchip pic chip in assembly once I get done with my other projects
4 bytes of RAM? If it wasn’t for the registers and the clock, we could run this on Ben Eater’s 8-bit computer, with 16 bytes of RAM! Maybe with a RAM and clock upgrade?
So far, Paul Carlson (of "Mr Carlson's Lab") is the only person who's managed to get me to consistently click on a video more than an hour long, so you have sympathy. Really cool that an ATTiny10 can do all of this.
Dude i barely understand a lot of the stuff you're talking about in this vid but you got a pretty funny personality, you got a good chuckle out of me here and there!
This is super cool. It's like the hardware version of the demoscene. I love minimalism. I also wish I had the EE background to do stuff like this. I feel constrained to software.
That was beautiful! You could use a range shift for the pot to allow detecting button click at same time as movement btw. Button would shift the pot response from for example 0.5-1.0v up to 1.1-2.2v so there is no overlap thus the motion and button can be consistent and simultaneous.
Ben if you partially use inline assembly you can use set bit and reset bit. TSB and RSB if I remember correctly, and there should be an instruction for checking a bit(6502 has one). That would significantly save program memory from all that bit shifting. But if I remember correctly you cant pass those instructions values, it has to be a hard coded constant.
I remember doing something similar with a ST62 microcontroller back in 93. In assembly there was barely enough cycles available to check the line counter and take a single byte output action. To make it work I needed to pre-sort and organise the bit actions (along with A/D and other logic works) in the vertical interval. Horizontal stuff was external with physical timers etc.. Cool to see you making a full video signal with that little micro.. can't wait for the complete game ;-)
in my last career, I squeezed out every possible bit of memory using peripheral registers for things I wasn't currently using on the chip. I would set those bits high or low depending on what I wanted to save. Since these are a hardware registers no ram was being utalizied.
I always assumed he was singing it in present day when the song was made - the late 80's. The car was just really old. He didn't make much money at Big Roy's Heating and Plumbing, and they spend a lot of money on those picked wieners.
To be honest, I look forward to every video on this channel and would totally sit through a feature length film starring that camcorder and a potentiometer. Can't wait for part 2!
i had a crazy dream the other day me and my wife came to your house and was taking a kinda tour of your house and all your cool projects and such and playing with that cute kitty + another kitty you had. your house was much bigger and you were kinda hiding out in a back room not wanting to interact lol. idk why but last few months been having crazy dreams only one you made your way into. love your videos hope you never stop
You may introduce a hysteresis for the analog value, thus, accept a new value only when it differs at least ±2 from the currently used one. So you get rid of potential jitter when the poti is just between two values.
Also add some filtering. If the ADC is sampled right when the button is becoming pressed you'll have a race condition. For one sample you will misread the potentiometer position, which will then get recorded incorrectly when the next sample is read as high.
Ben, to keep your code significantly more readable you should use bitfields instead of doing all the math yourself. It allows you to declare the exact number of bits you need for a variable. you do have to stuff them in a struct together though. struct { uint8_t pixelValid:1; uint8_t hSync:1; uint8_t vSync:1;uint16_t lineCount:9 }videoData; for optimization's sake i would also add a uint8_t pad:4 in the middle so the lineCount is aligned at the bottom. This may or may not make a difference depending on your instruction set or your controller but it can. All the single bit variables will generally use single bit compare, set and reset instructions so they are faster that way also. Though to be fair the compiler is likely figuring out what you're doing and using those operators anyways. Neat stuff getting a video signal in that small of a micro :)
Game suggestion: Break out defender hybrid. Catch a falling dot with the paddle and shoot the dot back up by pressing the button to destroy incoming dots. Destroy 3 incoming dots and win. Miss 3 incoming dots and loose.
Gief part 2 !! So interesting and so fun to watch, I really learned a lot, so I'm wondering what I will learn in part 2. Hope you will do more videos like this after!!
Great stuff! Dabbled with video generation on AT chips myself (ATmega328 and ATtiny84), but that's just an added challenge to make everything work on a 6 pin ATtiny10, good job. For tips on stabilizing the linestarts: 1) Make everything happen in the interrupt regarding drawing, and use the main loop for game logic (you kinda did this already) 2) add a crystal or calibrate the internal oscillator, on my own systems the line stability increased simply by using a crystal instead of the internal oscillator 3) entering an interrupt takes a variable amount of cycles in AVRs. Even if the chip was timed with an extremely precise oscillator, you'd still get line jitter depending on where in main loop your code was when the interrupt was called. It takes anywhere from 2 to 4 cycles to enter an interrupt and you almost no way of knowing how many it took this time. Luckily you are using a timer interrupt, and you know when it triggered, so waiting for a specific TCNT will take the rest of the instability out. Might require some assembly massaging though to make sure the wait/synchronize function ended on the exact same TCNT in every case. I'm sure you already knew this, or at least about this, but in case you didn't, here it is, and in case anyone else is interested in this, here you are.
I created a pong game using a PIC12F1840 (8-pin) years ago -- with two controllers, audio out, and NTSC video out ... and the PIC12F1840 creates each line of NTSC video. So, yeah, it's possible ... a pain in the ass, but possible.
I've got some attiny45 chips laying around. Gonna have to try this when I get a chance. Good palate cleanser from the 6502 stuff I've been messing with lately. 😁
48:24 Or you could try replacing that branch statement with single assign statement. For example, if(a < b) { result = 5; } else { result = 4; } Can be turned into this: result = ((a < b) * 5) + ((a >= b) * 4); In C, comparison operators always result 0 or 1, and multiplying a number to 0 always result 0. This is how above code works. Though it is also possible that compiler may have already applied this optimization.
Presumably you prefer typing out the register values as 0bXXX or doing it for simplicity, but fwiw the AVR headers define all of the bit names, so you can do stuff like: ADCSRA = (1
51:40 "I don't think people will realy want to watch longer than that" I'm personally love long videos on technical topics, when youtuber knows what to do and how to make his audience not get bored. And you are one of them) Thanks for your videos.
What I like in this video is that you squeeze that "pico"-controller to the maximum to make something amazing. I follow this project from the begining and each time you add a new feature I thought you will run out of memory but you processed video signal and sprite and movements control and you still have more than half memory space! I am excited to see how you'll complete the game with this tiny memory space?! Bravo. Won't you need to make your code as flat as possible (without functions) in order to not waste memory space in function arguments and return adress and thus recover some stack space, because you may need it for new variables for game processing?
What a great project! I love seeing just how much the ATTiny series can do with careful programming. I believe to get completely stable video, you need to put the processor into sleep mode before the end of each line, so it wakes up on the hsync interrupt. Otherwise, it finishes executing the current instruction before servicing the ISR, which takes a variable number of clock cycles.
You could use a shift register to get cheap digital I/O if you wanted to be able to hook a joystick up. Of course that might bump the price point up to using a slightly larger uC but it would still go along with the overall theme of using an ATTINY10.
This is amazing! I was wondering how you'd setup something like this from scratch. Not necessarily the ATTINY10, but a super small basic computer. Not only is this handling game computations, it's also determining how to draw the screen and react to inputs in realtime. That's insane.
Fantastic! I was disappointed when you finished the video at 50 minutes. I was thoroughly engrossed. Now I've had to _hit that subscribe button_ to make sure I don't miss part two.
I would be interested to see a single analog input used as a more complex controller. You could feasibly set a dpad and a few buttons to correspond to ranges or patterns in the analog signal
I'm using a micrcontroller to do the video timing on the Mini PET (the actual video comes out of a hardware shift register fed from font ROM indexed by video RAM). I found whatever I did with interrupts I got a bit of instability on the left hand edge. I wrote is several times in C with and without interrupts, and finally, the only way I got rock solid video every frame was to rewrite the whole thing in assembly. I unrolled many of the loops unrolled using macros to avoid start and end of loop timing differences, and the conditional statements had to be carefully written to equalise the number of cycles for yes or no outcomes. It was quite a lot of work sitting with a logic analyser adding the occasional NOP here and there to get the timing precise for every line of every frame, but I was very happy with the outcome.
I'm curious why you were seeing that. I've been working on a similar project (essentially using at AVR as a CRTC) and I just lifted the video timing and interrupt code from an Arduino TV-out sketch (not the "official" TV-out library, a self-contained one called VideoSPI) and it looks great stability-wise even at 64/80 column (eight and 7 clock ticks per character with a 12mhz pixel/cpu clock) I'm still building the project out of the Arduino IDE, although I am using embedded assembly for the actual pixel output loops so I've been thinking of moving it to Studio. I didn't have to unroll address generation and output, it just barely fits, but I am "cheating" and not using AVR code to generate the shift register loads; I have a GAL acting as a clock divider/shift register load state machine that gets synced up at the start of the pixel output spew.
You could do a vertical racer. The drawing would be quite simple as each line of the track is always the same (unless you get fancy and add the dashed line in the road) it just would have a different starting offset each line. I'm not sure if the game logic would be too complex (maybe start with no computer players and just do collision detection and have the rate of change in the track increase as the game progresses).
Nice--reminds me a bit of the Hackvision, an older Arduino-based project that also used bit-banging to generate black and white NTSC. Looking forward to seeing how you complete this project and I love that you took on as your challenge a device with only 4 I/O pins. Also wondering if you'll use your last pin--maybe for a second player, or add a couple more "colors"? As for game, would something like StuntCopter for old Mac work? Helicopter tries to drop guy onto moving cart with hay on the back. Score points or splat.
I'm currently working on an ATTiny85 handheld console. Instead of just one though, I'm attempting to use them in parallel with three powering a TFT lol. I could use SPI with a single tiny, but it's just too slow. I need parallel
"I don't want to do everything in the interrupt" - I never really got that, as long as you're not spending enough time in the ISR that it executes again while running (and doesn't block other service routines), it's just code on a cpu. Doesn't matter where it runs. I say go for it.
With what you said about switch statements, they act in whatever way the compiler believes is best (but that might not be strictly true). Modern compiles tend to output a bunch of assembly branch if statements, rather than pointer tables (which I is what used to be taught about switch statements back when I was in university). The switch statement is supposed to replace 'goto' and in some circles it is considered just as evil as 'goto'. In my eyes, it is a self-contained, easy to follow version of 'goto' with a single condition. I found some really awesome ARM assembly the other day that did the job of a switch statement by jumping the program counter forward into a bunch of aligned instructions based on a condition; the only possible way to replicate that was to use a switch statement, but no compiler (as of right now) is capable of doing such a smart bit of programming, they all default to a load of branching conditions.
A quick test showed AVR-GCC decided to use calculated jumps for 8 cases, but not 4. GCC also supports computed gotos. However, both cases produced far larger code than an assembly routine would. Funny thing about the AVR: if (bit_test) bit_set; else bit_clear; is bigger and slower than if (bit_test) bit_set; if (!bit_test) bit_clear;
This is really neat. Minor point about those black lines in the 2600 Ms Pac-Man. It's a glitch that happens when the sprite fine position adjustment registers in the TIA are updated, because of how the process involves stuffing extra clock pulses into the TIA's state machines. That's why you see those same black lines with the same widths on a bunch of games. The way the TIA was designed you were expected to set the sprite positions once before the screen started drawing, so the glitch wasn't supposed to be visible. But games started updating the position in the middle of the kernel in order to reuse sprites on different scanlines for multiplexing, or for graphical effects where they're wobbled around. Some games would either use a black background to mask the effect (eg Space Invaders) or they'd set those registers every scanline so there was a full black border that didn't stand out (eg a lot of Activision games)
Oh BTW please give suggestions on the kind of game to make! Something with a lot of separated verticality would be best, like Space Invaders, Galaga or Breakout.
Galaga would be nice, but the most simple way would be Kaboom isn't it?
Galaga please
Breakout.
You need some PET style chess on this bad boy
Circus.
Realized something last night while taking a leak. Since all the trigger points are even numbers I could divide the line counter by 2 and make it fit inside 1 byte. It would also make double-thick vertical pixels for "free"
Nice! I wonder if there's a direct correlation between success and number of pee breaks. 🤔
@@ericvest9050 I think there actually is. I mean, from an irl standpoint, it kind of makes sense. It is a short break in working, so your brain thinks over things you did before. Maybe taking a leak will find the solution to the universe?
@@randominternetbro6562 So the secret to guaranteed success is just don't stop peeing. I got this, unhold my beer
And if you left align your line counter, the switch statement can read only the upper byte, and counting would not need bit masking to preserve the flags. Also, use 8 bit values; the for loop in drawSprite uses twice as many registers and instructions manipulating int i as uint8_t i.
@@0LoneTech If he makes the line counter one byte wide then there is no upper byte.
Ben: "We saved 4 bytes!" *big party*
kids nowadays: "how can you live with only 500 gigs in your PS4?"
I live with 500gigs in my gaming rig XD
@@norjia yes but can you live with half of that?
@@waltercomunello121 i did on my laptop before i built myself my current system
Yeah.. I feel that. Considering the fact I have 5.5 TB on my desktop total (between the internal hard drive, and an external usb hard drive).
Only 1.5 TB are free in both of them; 4TB / 5.5 TB.
It's mostly a result of recording music, capturing video, programming projects, and many many many games from steam and epic games.
I'm getting an arduino uno at the end of the month, so the computer science path shall begin. Time to get to work.
Every major company in 2020: realistic graphics
Ben in 2020: crude 8-bit console with more limitations than what the 2600 had
he's catching up!
I want him to code a co-processor for Ben Eater's 6502-based breadboard computer. C'mon!
(Cross-channel media link-ups, and all, but what the frootyloops.)
They are both giants in their way, in the same field. Would you call it Ben Squared?
[I know that the Unknown Soldier is probably calling himself Ben for the pun value. 'BeNeater': He doesn't want to eat you, Mr. Heckindorm. (I have actually personally known someone called 'Heck'.)]
[if u wna know, according to Robert Rankin, it stands for Hounslow, Ealing, Chiswick and Kew. - The Brentford Triangle.]
It would be pretty cool to fit the whole thing into a yellow RCA plug housing with the knob sticking out the back.
:o
"Oh man i'm bored lets generate an NTSC signal" - God engineer Ben Heck.
What an amazing video. Psyched for more!
Remember when programmers optimized their code simply because they cared about efficiency? Ooh, I saved 2 bytes* said no one in at least 30 years 😁
Awesome work man.
I've made embedded programs for controlling hardware, and 2 bytes can make all the difference
I legitimately said that yesterday. I actually said, as a perfect quote, "Ooh! I saved 2 bytes!"
This was while writing a program for my TI-85 graphing calculator :)
Weird, almost as if saving bytes stopped being worthwhile once software exceeded billion times that amount.
We needed more storage because programmers stopped making tiny size optimizations.
Programmers stopped making tiny size optimizations because we had more storage.
@@easyaspi31415 wrong, we needed more storage because we had more data.
Even for the common Joe, data itself adds up to terabytes, there is no getting around it. And big-data is several orders of magnitude further still.
Cost of a gigabyte is measured in cents, cost of a programmer in tens of dollars per hour.
Saving bytes is seldom appropriate anymore, and no sane company is going to throw away profit just for the sake of nostalgia.
10/10 didn't learn anything about programming but i learned more about spaghetti
The program is spaghetti
I relate with your feeling, Kaworu.
Just about all of this went over my head but I still find it interesting
14:54 Even while choking to death, Ben Heck still continous to teach us mere mortals about the legacy of Video signal processing
Love atmel studio. Literally just finished a project in it and 30 seconds later I open your video and you instantly put a smile on my face.
Ina few years this project will, eventually, run DOOM
with an attiny10, that is very unlikely. maybe a watered down version like the one made for the calculator.
@@MsHumanOfTheDecade taking it too literally much?
@@MsHumanOfTheDecade I'm pretty sure an atmega2560 would run Crysis easily, with room to spare for spaghetti AND meatballs.
@@MsHumanOfTheDecade even a stripped down version like the calc-doom would be badass!
can it run cyberpunk 2077? i don't have the money for ps5 but have money for attiny10
"Hey my voice quality changed again...I don't care!" :D
That was the line when i subscribed :D
This break the 4th wall :v
The knowledge of this man is incredible. I feel so lucky just to be exposed to that mind...
And as time passes we get inevitably more and more exposed to his mind thanks to that receding hairline.
@@wesleyswafford2462 It's a joke dude, chill
Oh no, Ben's google profile picture is a picture of his cat. His cat is quickly taking over the house!
All jokes aside, great video, thanks Ben!
As no cat owner I noticed that cats run the internet.
I love this project!
Miau
I really got into this micro because of last year's video. I made earrings, a dev board, and a programmer and have been learning assembly as well. Great inspiration for those of us who love building tiny things simply for the challenge. Great content Ben. Keep 'em coming!
The good old days when ya built an opamp out of discrete transistors then 30 years later folks r selling them as high end
My boss would wait months to get metal canned op amps (lm339 I believe) just because they were 4-5% less noisy.
@@GreenAppelPie Place i worked clients had circuits we would connect into a working circuit then laser trim various resistor/capacitor networks to their specs and send them to another group have their cans welded. Look just like metal 339's
I'm just starting the video but these kinds of projects are my absolute favorites to see people make videos on. Gotta say I'm really enjoying where you've been going since Element 14.
Hey Ben. I just wanted to say how much I enjoyed this content, especially the little outro. I'm really looking forward to the next one.
Reminds me of this one PIC project back in 1990's where I had to make a subroutine and call it every 6 instructions since the processor lacked an interrupt.
The chaotic giggle as you optimise ram usage make this video pure gold
The motivation level that you have given me is really absurdly high!
Thank you! There's clearly a lot that you can stuff into 1K
*FunFACT* : The _"vertical front and back porch"_ is actually called _pre-equalisation and post-equalisation_ pulse.
I'm halfway down a bottle of cheap vodka and a crazy thought came to me. Imagine if you could give this software to Carol Shaw, David Crane, Larry Kaplan, Bob Whitehead and other old Atari developers. Imagine the crazy stuff those dudes could have come up with if they weren't limited to coding assembly.
Oh, and awesome video Ben. Thank you.
Some extra detail about the garbage in mrs.Pacman on the 2600, the lines on the left of the screen are actually due to how the TIA (the atari's graphics chip) handles horizontal repositioning.
The Atari had horizontal repositioning registers for all the major graphics and a separate "HMOVE" register you would strobe to commit the changes. If you didn't strobe the HMOVE at the exact right cycle, it would add that garbage to the left of the screen. If I'm not mistaken, most Atari programmers were unaware you could time it correctly and just assumed the garbage was unavoidable. (or they were like me and too lazy to time it correctly). That's why that garbage is present in most games that move the graphics in the middle of the frame.
I clicked on this video thinking I'd watch a few minutes to see if it was interesting. Wound up watching the whole thing and am looking forward to the follow-up. Excellent content! Thanks :D
I've been watching Ben's videos since 2013 (when I was 11), It's done a lot to get me through tough times and I've never felt more at home then when I turn a video of his on.
4:14 It's actually exactly 15750 Hz or 15734 Hz, depending on which era NTSC standard you are going for, but 15700 Hz it never was.
I cant think a world without you Ben. Thank you for years of pure enjoyment.
I'd watch an entire day's worth of this kind of content. Love your comments.
I absolutely loved this video and am waiting with baited breath for part 2. I have been playing with the smallest PIC chips for a while to challenge myself to write useful code in very little memory but until seeing this I never even thought about bit banging a video signal. I am very tempted to try this with a microchip pic chip in assembly once I get done with my other projects
4 bytes of RAM? If it wasn’t for the registers and the clock, we could run this on Ben Eater’s 8-bit computer, with 16 bytes of RAM! Maybe with a RAM and clock upgrade?
Double the Bens, Double the Ｅｆｆｉｃｉｅｎｃｙ(tm)
I tip my hat to you sir... I understood like 70% of this, but you make it very entertaining. Thanks for all the content you make, I love this channel
So far, Paul Carlson (of "Mr Carlson's Lab") is the only person who's managed to get me to consistently click on a video more than an hour long, so you have sympathy. Really cool that an ATTiny10 can do all of this.
Thank you Ben! Your videos are a wealth of knowledge, and entertainment. Thank you for all you do!
i especially liked his truth bomb on spagetthi
Dude i barely understand a lot of the stuff you're talking about in this vid but you got a pretty funny personality, you got a good chuckle out of me here and there!
Ben, your attitude, talent, and skill is just what we need during these trying times. Thanks for being you.
An hour long video oh yes!
This is the perfect Channel to eat cereal to.
It takes an hour to eat cereal? Either you must be a really slow eater, or you are a cereal killer.
Ok, wow. Just amazing - explains so well how it all works, and ‘“chasing the beam” in action. Thank you.
This is super cool. It's like the hardware version of the demoscene. I love minimalism.
I also wish I had the EE background to do stuff like this. I feel constrained to software.
Eh this is 99% software.
@@BenHeckHacks Also having an oscilloscope lol.
That was beautiful!
You could use a range shift for the pot to allow detecting button click at same time as movement btw.
Button would shift the pot response from for example 0.5-1.0v up to 1.1-2.2v so there is no overlap thus the motion and button can be consistent and simultaneous.
That's a great idea! I could just "button away" a 10k resistor and then lob the top bit off the ADC result.
Ben if you partially use inline assembly you can use set bit and reset bit.
TSB and RSB if I remember correctly, and there should be an instruction for checking a bit(6502 has one).
That would significantly save program memory from all that bit shifting.
But if I remember correctly you cant pass those instructions values, it has to be a hard coded constant.
I remember doing something similar with a ST62 microcontroller back in 93. In assembly there was barely enough cycles available to check the line counter and take a single byte output action. To make it work I needed to pre-sort and organise the bit actions (along with A/D and other logic works) in the vertical interval. Horizontal stuff was external with physical timers etc.. Cool to see you making a full video signal with that little micro.. can't wait for the complete game ;-)
in my last career, I squeezed out every possible bit of memory using peripheral registers for things I wasn't currently using on the chip. I would set those bits high or low depending on what I wanted to save. Since these are a hardware registers no ram was being utalizied.
Good trick! It may come to that yet! :)
I've been WAITING for you to make a video on this chip in a build! This is so cute
Ben writes spaghetti while also eating spaghetti. Seems like a violation of some sort of social taboo. Regardless, it was prime edutainment content!
Singing "Biggest Ball of Twine in Minnesota" while programming live on TH-cam. My kind of twisted. I'm a fan.
I always assumed he was singing it in present day when the song was made - the late 80's. The car was just really old. He didn't make much money at Big Roy's Heating and Plumbing, and they spend a lot of money on those picked wieners.
Literally one of the only channels you'd ever hear a random "Biggest Ball of Twine in Minnesota" reference. Ben is hilarious!
To be honest, I look forward to every video on this channel and would totally sit through a feature length film starring that camcorder and a potentiometer. Can't wait for part 2!
i'm never complaining about a chip not having enough pwm outputs ever again
i had a crazy dream the other day me and my wife came to your house and was taking a kinda tour of your house and all your cool projects and such and playing with that cute kitty + another kitty you had. your house was much bigger and you were kinda hiding out in a back room not wanting to interact lol. idk why but last few months been having crazy dreams only one you made your way into. love your videos hope you never stop
You may introduce a hysteresis for the analog value, thus, accept a new value only when it differs at least ±2 from the currently used one.
So you get rid of potential jitter when the poti is just between two values.
I may also use the lowest few bits of the ADC to feed a random number generator.
Also add some filtering. If the ADC is sampled right when the button is becoming pressed you'll have a race condition. For one sample you will misread the potentiometer position, which will then get recorded incorrectly when the next sample is read as high.
Yeah, median should do, probably 3 values should already work.
Ben, to keep your code significantly more readable you should use bitfields instead of doing all the math yourself. It allows you to declare the exact number of bits you need for a variable. you do have to stuff them in a struct together though. struct { uint8_t pixelValid:1; uint8_t hSync:1; uint8_t vSync:1;uint16_t lineCount:9 }videoData; for optimization's sake i would also add a uint8_t pad:4 in the middle so the lineCount is aligned at the bottom. This may or may not make a difference depending on your instruction set or your controller but it can. All the single bit variables will generally use single bit compare, set and reset instructions so they are faster that way also. Though to be fair the compiler is likely figuring out what you're doing and using those operators anyways.
Neat stuff getting a video signal in that small of a micro :)
I'll look into it!
Game suggestion:
Break out defender hybrid.
Catch a falling dot with the paddle and shoot the dot back up by pressing the button to destroy incoming dots.
Destroy 3 incoming dots and win.
Miss 3 incoming dots and loose.
This is great, would happily watch three hours of it
Gief part 2 !! So interesting and so fun to watch, I really learned a lot, so I'm wondering what I will learn in part 2. Hope you will do more videos like this after!!
50 minutes and it’s only part one? And I’m already somehow 2/3 of the way through? This is some surprisingly engaging content!
Great stuff! Dabbled with video generation on AT chips myself (ATmega328 and ATtiny84), but that's just an added challenge to make everything work on a 6 pin ATtiny10, good job. For tips on stabilizing the linestarts:
1) Make everything happen in the interrupt regarding drawing, and use the main loop for game logic (you kinda did this already)
2) add a crystal or calibrate the internal oscillator, on my own systems the line stability increased simply by using a crystal instead of the internal oscillator
3) entering an interrupt takes a variable amount of cycles in AVRs. Even if the chip was timed with an extremely precise oscillator, you'd still get line jitter depending on where in main loop your code was when the interrupt was called. It takes anywhere from 2 to 4 cycles to enter an interrupt and you almost no way of knowing how many it took this time. Luckily you are using a timer interrupt, and you know when it triggered, so waiting for a specific TCNT will take the rest of the instability out. Might require some assembly massaging though to make sure the wait/synchronize function ended on the exact same TCNT in every case.
I'm sure you already knew this, or at least about this, but in case you didn't, here it is, and in case anyone else is interested in this, here you are.
I created a pong game using a PIC12F1840 (8-pin) years ago -- with two controllers, audio out, and NTSC video out ... and the PIC12F1840 creates each line of NTSC video. So, yeah, it's possible ... a pain in the ass, but possible.
I've got some attiny45 chips laying around. Gonna have to try this when I get a chance. Good palate cleanser from the 6502 stuff I've been messing with lately. 😁
1 hour nicely spent...i need the part 2
48:24 Or you could try replacing that branch statement with single assign statement.
For example,
if(a < b) {
result = 5;
} else {
result = 4;
}
Can be turned into this:
result = ((a < b) * 5) + ((a >= b) * 4);
In C, comparison operators always result 0 or 1, and multiplying a number to 0 always result 0. This is how above code works.
Though it is also possible that compiler may have already applied this optimization.
Awesome video!! Looking forward for part 2.
Thank you for sharing your knowledge.
Thanks Ben this was great, looking forward to the continuation. 53 minutes flew by
Presumably you prefer typing out the register values as 0bXXX or doing it for simplicity, but fwiw the AVR headers define all of the bit names, so you can do stuff like:
ADCSRA = (1
I also tend to prefer Atmel parts in order to use AVR Visual Studio 7.0. My favorite microcontroller is the ATSAM3U.
51:40 "I don't think people will realy want to watch longer than that"
I'm personally love long videos on technical topics, when youtuber knows what to do and how to make his audience not get bored.
And you are one of them) Thanks for your videos.
What I like in this video is that you squeeze that "pico"-controller to the maximum to make something amazing. I follow this project from the begining and each time you add a new feature I thought you will run out of memory but you processed video signal and sprite and movements control and you still have more than half memory space! I am excited to see how you'll complete the game with this tiny memory space?! Bravo. Won't you need to make your code as flat as possible (without functions) in order to not waste memory space in function arguments and return adress and thus recover some stack space, because you may need it for new variables for game processing?
I find it funny, I just spent my afternoon watching the other one and well.. here we go with this one!!
What a great project! I love seeing just how much the ATTiny series can do with careful programming.
I believe to get completely stable video, you need to put the processor into sleep mode before the end of each line, so it wakes up on the hsync interrupt. Otherwise, it finishes executing the current instruction before servicing the ISR, which takes a variable number of clock cycles.
You can connect multiple buttons to a single analog input using resistors. That would allow you to have full controls allowing for more complex games.
Wow, and I thought working with an M0 was cheap and constrained. Lol. Fun video! I'm definitely watching the next one!
That voice quality comment earned my like before I even finished this video. Well played sir.
I love your videos and will continue to watch all of them in hopes to absorb your intelligence
I could watch these videos all day!
You could use a shift register to get cheap digital I/O if you wanted to be able to hook a joystick up. Of course that might bump the price point up to using a slightly larger uC but it would still go along with the overall theme of using an ATTINY10.
Cool video and super idea. I can't wait for part two.
This is amazing! I was wondering how you'd setup something like this from scratch. Not necessarily the ATTINY10, but a super small basic computer. Not only is this handling game computations, it's also determining how to draw the screen and react to inputs in realtime. That's insane.
NTSC - Never Twice the Same Colour I was taught :-)
Yup, tweaking that color tint control every time. Well at least on older color TV’s that is.
So, the exact statement with a redundant character no longer matching the acronym. Thanks.
NTSC - No Two Times The Same Colour. I think is correcter.
Was taught the same back in the 90s. The upside was that unlike PAL it was much easier to convert 24fps to pseudo 30fps (29.97)
On the contrary, ATSC = Always Twice The Same Color. (But with other problems like 8VSB's poor tolerance of narrowband interference unlike OFDM.)
SECAM = Something Essentially Contrary to the American Method :-)
The enlarged text definitely helps since I watch your content on a TV from a distance!
Fantastic! I was disappointed when you finished the video at 50 minutes. I was thoroughly engrossed. Now I've had to _hit that subscribe button_ to make sure I don't miss part two.
I would be interested to see a single analog input used as a more complex controller. You could feasibly set a dpad and a few buttons to correspond to ranges or patterns in the analog signal
I have no idea what's going on but god DAMN its fascinating.
I'm using a micrcontroller to do the video timing on the Mini PET (the actual video comes out of a hardware shift register fed from font ROM indexed by video RAM). I found whatever I did with interrupts I got a bit of instability on the left hand edge. I wrote is several times in C with and without interrupts, and finally, the only way I got rock solid video every frame was to rewrite the whole thing in assembly. I unrolled many of the loops unrolled using macros to avoid start and end of loop timing differences, and the conditional statements had to be carefully written to equalise the number of cycles for yes or no outcomes. It was quite a lot of work sitting with a logic analyser adding the occasional NOP here and there to get the timing precise for every line of every frame, but I was very happy with the outcome.
I'm curious why you were seeing that. I've been working on a similar project (essentially using at AVR as a CRTC) and I just lifted the video timing and interrupt code from an Arduino TV-out sketch (not the "official" TV-out library, a self-contained one called VideoSPI) and it looks great stability-wise even at 64/80 column (eight and 7 clock ticks per character with a 12mhz pixel/cpu clock) I'm still building the project out of the Arduino IDE, although I am using embedded assembly for the actual pixel output loops so I've been thinking of moving it to Studio. I didn't have to unroll address generation and output, it just barely fits, but I am "cheating" and not using AVR code to generate the shift register loads; I have a GAL acting as a clock divider/shift register load state machine that gets synced up at the start of the pixel output spew.
You could do a vertical racer. The drawing would be quite simple as each line of the track is always the same (unless you get fancy and add the dashed line in the road) it just would have a different starting offset each line. I'm not sure if the game logic would be too complex (maybe start with no computer players and just do collision detection and have the rate of change in the track increase as the game progresses).
Nice--reminds me a bit of the Hackvision, an older Arduino-based project that also used bit-banging to generate black and white NTSC. Looking forward to seeing how you complete this project and I love that you took on as your challenge a device with only 4 I/O pins. Also wondering if you'll use your last pin--maybe for a second player, or add a couple more "colors"? As for game, would something like StuntCopter for old Mac work? Helicopter tries to drop guy onto moving cart with hay on the back. Score points or splat.
Switch statements make jump tables, which, yes, are basically an array of pointers
I'm currently working on an ATTiny85 handheld console. Instead of just one though, I'm attempting to use them in parallel with three powering a TFT lol. I could use SPI with a single tiny, but it's just too slow. I need parallel
When you're done, you should put the whole thing in resin. With bare copper wires going to separated components.
"I don't want to do everything in the interrupt" - I never really got that, as long as you're not spending enough time in the ISR that it executes again while running (and doesn't block other service routines), it's just code on a cpu. Doesn't matter where it runs. I say go for it.
With what you said about switch statements, they act in whatever way the compiler believes is best (but that might not be strictly true). Modern compiles tend to output a bunch of assembly branch if statements, rather than pointer tables (which I is what used to be taught about switch statements back when I was in university).
The switch statement is supposed to replace 'goto' and in some circles it is considered just as evil as 'goto'. In my eyes, it is a self-contained, easy to follow version of 'goto' with a single condition.
I found some really awesome ARM assembly the other day that did the job of a switch statement by jumping the program counter forward into a bunch of aligned instructions based on a condition; the only possible way to replicate that was to use a switch statement, but no compiler (as of right now) is capable of doing such a smart bit of programming, they all default to a load of branching conditions.
A quick test showed AVR-GCC decided to use calculated jumps for 8 cases, but not 4. GCC also supports computed gotos. However, both cases produced far larger code than an assembly routine would. Funny thing about the AVR: if (bit_test) bit_set; else bit_clear; is bigger and slower than if (bit_test) bit_set; if (!bit_test) bit_clear;
thumbs up for singing and analyzing The Biggest Ball of Twine in Minnesota! :D
It just hit me: all the Internet is missing... is a Ben Heck... MOVIE!!! (Picard voice) MAKE IT SO
Hillbilly Ology with Solder and a more stable family life.
First time I have seen you. Immediately subscribed!
This is really neat.
Minor point about those black lines in the 2600 Ms Pac-Man. It's a glitch that happens when the sprite fine position adjustment registers in the TIA are updated, because of how the process involves stuffing extra clock pulses into the TIA's state machines. That's why you see those same black lines with the same widths on a bunch of games.
The way the TIA was designed you were expected to set the sprite positions once before the screen started drawing, so the glitch wasn't supposed to be visible. But games started updating the position in the middle of the kernel in order to reuse sprites on different scanlines for multiplexing, or for graphical effects where they're wobbled around.
Some games would either use a black background to mask the effect (eg Space Invaders) or they'd set those registers every scanline so there was a full black border that didn't stand out (eg a lot of Activision games)
Ah good to know!
It's funny you made this video. I was only just going back over you last one on this and was looking into making my own project using this.
You could probably simplify some of that bit masking with C bit fields!
I just watched the video programming this little chip this morning! What a coincidence 😁
The original video just keeps getting views. It spikes about one per year. So figured I should make more!
Thanks for this video. I thoroughly enjoyed this... :). Looking forward to part 2
Dementedly educational. Excellent. Thank you. 👍🏼