What is a stack and how does it work? - 6502 part 5
ฝัง
- เผยแพร่เมื่อ 31 ม.ค. 2020
- Schematics, datasheets, kits, and more at eater.net/6502
Part 1: • “Hello, world” from sc...
Part 2: • How do CPUs read machi...
Part 3: • Assembly language vs. ...
Part 4: • Connecting an LCD to o...
Part 5: This video!
Part 6: • RAM and bus timing - 6...
Part 7: • Subroutine calls, now ...
Support these videos on Patreon: / beneater or eater.net/support for other ways to support.
------------------
Social media:
Website: www.eater.net
Twitter: / ben_eater
Patreon: / beneater
Reddit: / beneater
Special thanks to these supporters for making this video possible:
Adam Lininger, Adrien Friggeri, Alex Catchpole, Andrew R. Whalley, Anthony Cuccia, Armin Brauns, Austin Grant, BakerStaunch, Beau-James Erion, Ben Dyson, Ben Kamen, Ben Williams, Bradley Pirtle, Bryan Brickman, Carlos Ambrozak, Christopher Blackmon, Clayton Parker Coleman, Daniel Tang, Dave Walter, David Boardman, David H. Friedman, David House, David Turner, Dean Winger, Debilu Krastas, Dmitry Guyvoronsky, Dušan Dželebdžić, Dzevad Trumic, Eric Brummer, Eric Busalacchi, Eric Dynowski, Eric Twilegar, Erik Broeders, Eugene Bulkin, Foaly, fxshlein, HaykH, Ian Tait, Ingo Eble, Ivan Sorokin, Jason DeStefano, JavaXP, Jay Binks, Jayne Gabriele, Jeremy A., Jeremy Wise, Jimmy Campbell, Joel Jakobsson, Joel Messerli, Joel Miller, Joern Heidenreich, Jon Dugan, Jordan Scales, Joshua King, Justin Duch, Kefen, Kent Collins, Lambda GPU Workstations, Lucas Nestor, Maksym Zavershynskyi, Manne Moquist, Marcus Classon, Mats Fredriksson, Matt Alexander, Matthäus Pawelczyk, Michael, Michael Burke, Michael Garland, Michael Tedder, Miguel Ríos, Nathan Wachholz, Nicholas Counts, Nicholas Moresco, Örn Arnarson, Paul Pluzhnikov, Paul Randal, Philip Hofstetter, Randy True, Ric King, Richard Wells, Rob Bruno, Robert Blackshaw, Robert Butler, Ross, Sachin Chitale, Sam Rose, Samuel E Joseph, Scott, Sergey Ten, Sever Banesiu, SonOfSofaman, Stefan Nesinger, Stefanus Du Toit, Stephen Riley, Stephen Smithstone, Steve Jones, Steve Gorman, Steven Pequeno, Thomas Ballinger, Tom Burns, Vladimir Kanazir, Warren Miller, xisente, Ziggy L
Ben Eater is like Bob Ross for computer engineers.
engineers or 80s kids did this after school 😋
"There are no errors, just happy stack overflows"
"We're going to insert this happy little RAM chip over here!"
The most perfect description!
just that ben is still alive.
Dude, your videos are something else, the amount of effort you put into them is unbelievable
Agree completely. Might I recommend vim macros for the replacing of code, though? :)
Agree completely.
@@VACatholic We won't hear the pleasent sound of the keyboard.
+1 Ben Eater's a beast.
ndirish Might I recommend you realize he is using his time to explain something else to all of us, though? :)
now THIS is full stack programming
carterisonline Ahaha 😅😅😅
Not yet it isn't, need to install some RAM before we can have a full stack to work on.
Just download a bit of RAM
xD
@@nadie9058 wow! You know
I want to let you know that you are one of the reasons why I as an electrical engineer student chose the specialization of computer engineering
I enrolled in computer engineering back in 1988... left the program in 1990 and switched to programming because of a) terrible part-time "teachers" who were full time engineers but couldn't explain b) tired of everyone in the class getting 40's on exams and then getting 70's thx to a curve. I felt like I was learning ANYTHING related to actual computer engineering nor could I understand what was going on.
Fast forward to 2020 and I just learned more in a 25 minute video than in an entire semester of college! The internet and access to info has changed learning... if I had these tools, I probably would have stuck with the program all those years ago! Thank you for doing what you do.... very clear explanation and well presented!
Can we use another eeprom as our ram?
@@zulqarnayeenschaftler9323 No, because ROM is read only memory. Can't write to it.
Okay, but how do we programed the first ROM?
@@zulqarnayeenschaftler9323 theoreticlly
This is top-notch pedagogy. How you kept the mystery of the malfunction alive as long as possible and acted surprised about it!
Having grown up programming the 6502 (I am watching these videos for nostalgia), I knew where this was headed as soon as he typed the JSR instruction. However, he played it quite convincingly. I guess he wants to show people how to work through problems and not get discouraged. This makes him not just a good teacher, but a good mentor as well.
Don't over-encourage the surprise... That's how you get cheesy action lab videos
@@MadScientist267 I think Ben Heck called it "regrettable acting". 🤣 It's fair enough to go ahead and do it wrong and have people who figured it out going "ooh ooh ooh!" like they did when they were kids in school though…! 😉
@@TheGuyThatEveryoneIgnores I had much the same reaction. I'm watching thinking, "isn't he going to need a stack for that?" He played it so straight that I was kind of convinced he was going to pull a clever trick out of his hat. But nope. Just a "well that didn't work". Kind of satisfying to know _why_ it didn't work, though.
I had forgotten about the return stack, but a very good explanation.
Awesome breakdown. The time spent on the highlight boxes was definitely worthwhile. I'm watching this in the morning before I'm 100% focused. Without the boxes I would probably shrug it off as something to rewatch later while trying to replicate it. With the highlight boxes I followed completely. Thanks! I know something apparently small like this requires an enormous amount of editing effort.
"Please insert RAM to continue and press ENTER"
or just download some...
**Presses F**
or just PRESS PLAY ON TAPE
@@dav1dsm1th first he would have to build a wifi module.
@@carlos2004 HEY THAT'S A GREAT IDEA! I'd like to watch him build a Wi-Fi module, maybe a bare bones but a working one.
14:36
"Our computer doesn't actually have any RAM in it"
Never thought I'd ever hear that.
After he fixed up the code and plugged the ROM chip in, I started yelling "No no no no!! Not gonna work!" at the screen like it's a damn football game! LOL.
@@markjones5973 lmao, yeah I didn't actually consider that the system didn't have RAM yet, but it took me rather little to figure it out after the fact
Well, it has memory, it's just read only...
@@joshuawalker7054 well it is an EEPROM so not really read only. Also I think that the EEPROM can be used instead of a RAM here?
@@noether9447 Except you really don't want to do that.
20:09 stack overflow, I wonder were I’ve heard That before
Its trash
many places e.g. stackoverflow.
The website took its name from the concept, not vice versa.
@@paulstelian97 I think most of us figured that out already, there is a chance that you whooshed.
@@lexibigcheese You'd be surprised how many I've seen that don't know that.
The 'now why didn't this work as expected' autopsy is the best way to get a deep understanding of a subject. I learn more in each video than I did in 2 years of studying Computer Science.
A newbie interne programmer : real man programs in "C"
Ben eater : hold my 6502 please
Gold :)
Real Programmers don’t use Pascal, also they use FORTRAN for calculation, FORTRAN for string processing, FORTRAN for artificial intelligence. But of course they have no problem writing in machine code or just fixing already compiled programs.
see also “Real Programmers Don’t Use Pascal”
@Lenny69 シ i just imagined a great painting to it, shame i cant draw it that way XD
Well when you see an intern position where they want you to know IoT WiFi BLE Embedded Linux, you kinda become overwhelmed and don't learn asm.
@PolySakenearly ROMs were hand made by little old ladies who had been knitting for decades and could thus handle working with wire at tiny scales. No joke.
I am software engineer with MSc and over 15 years of professional experience. 6502 Hello world was like click bait for me, since I just recently started playing with Arduino and ESP32.
I would like to send BIG thank you to you Ben Eater. I should have learned that during my MSc, but it was not part of it.
I also need to say, I am admiring when you have printed data sheet (instead of displaying PDF), but the thing that makes me smile every time I see it in your videos is the paper with all the addresses, codes, etc. written manually. It is not just that you use paper to show that off (actually SP pointer as a little arrow "forced" me to write this comment). You actually did handwrite all of the 0's, 1's and other HEXes. It is not printed it is hand written. WOW !!!
no one ever showed this.....while teaching these concepts.....
these videos are out off the world
Yup, Ben is on a whole nother level.
I learned this in university, but yes not many people go in detail
I learned all of this in my CS program
How I wish I'd had access to these videos back when I was trying to understand 68000 assembler on the Atari ST. Before the Internet, and with crappy tech sections in the local library I had one pretty opaque book as a resource, and I really struggled.
These videos are absolutely brilliant - thank you for putting them out there. I have no doubt that in 10 years time some really accomplished engineers will owe a lot of their success to you.
if we had that back then we could have programmed some nes game (kinda same chip afaik) ;D . wish i had a library that had tech books XD .
The other issue back when I was trying to learn this was the SDK for the Commodore Amiga was £130 (in 1987!) and so completely out of reach. As soon as you wanted to do something beyond print to the CLI you didn't have the includes, offsets, vectors to call routines you needed. There were some "sandbox" environments but they weren't worth much.
By the time I got to an OS with and open stack it was a Celeron CPU with a modern OS (Linux) and a lot harder to understand and code for.
I found the arduinno (or other MCU) is a nice little place to learn assembler, though a little different than a 6502/68000, it still small and simple enough and not bogged down in the details of the OS.
It's really heplful to see Ben apply this to a real CPU on a BB.
That is exactly what i thought. I wish we had this videos back in Amiga times 🙄
@@DarthZackTheFirstI NES uses the 6510, a 6502 variant, while OP talks about a 68k (Amiga, Mac, ST, Mega Drive) :) so indeed _these videos_ could help get started with an NES. But the core concepts can also help to understand any machine-specific assembly, you just have to go look at the data sheet to find specific behaviour (ie the Z80, used in the Game about, initialises quite differently to the 6502)
2:08 “assuming they’re correct”, I felt that in my soul.
I always wondered what the "stack" part of "stack overflow" was, this was very educational. Thank you!
You know what's crazy? I always wondered what the "overflow" part was!
I understood it as a consequence for running out of stack, but this is a whole new level of understanding
Ben's effort is unbelievable. His videos are breathtaking and I cannot recommend them enough.
What I wouldn't have given to have had access to tutorials like this 30 years ago. I understand more in 20-30 minutes on TH-cam than I did in an entire lifetime of tinkering, education, and life experience.
Every time you upload another video in the series I realize I completely forgot everything you showed in the previous videos
Could be the spacing out of videos. Just go back and binge watch
@@GerardMenvussa XD
You know what time it is then
_Rewind Time_
@@GerardMenvussa Well played, Sir or Madam, well played. :D
@@benjamindragon598 Well sure but each video is 30 minutes and ain't nobody got time for that
This man is debugging by tapping into the data pins of a CPU and I had to deal with teammates in college who complained that debugging was too hard to do.
This video is SUPER satisfying and makes me happy that I have a debugger in so many IDE's.
Been meaning to get into code like this, been having a lot of fun in C on my Arduino and for fun in Linux.
I'm an embedded systems design engineer and University professor for digital systems, I recognize the awesome job you do with your videos, I recommend your videos to my students due to the way you explain the topics, your videos keep teaching and never start boring, that's an important fact, and you always contrast the practical way of things, keep up the good work!
My fav series on youtube
Great! Now I have to wait another month for Ben to put ram chip into 6502 computer.
Yeah, while I enjoy the 30 minute primer, I would have appreciated a warning that this was purely concept/theory and that we'd have to wait for the next vid to get to the actual RAM installation. I pulled out and setup all my kit to follow along with this video for...well...nothing, as everything I needed to learn this time was in the video. No real hands-on needed. I would have released this video AND the RAM install video at the same time...even if that meant withholding this one just a couple weeks longer.
You could try to put it in yourself. Just check the data sheet for that ram to see which pins do what, and see if you can figure out how it goes together. That type of independent exercise is enormously educational. Even if you fail, it's just a teachable moment.
When Ben comes back with the next video, his way might be a little different than your way, but there are many different ways to connect these together (logic processing of the address lines I mean).
Just make sure you are careful with your output enable line and r/w line so that your ROM, RAM, and CPU never have their outputs enabled at the same time on the data buss. You will burn out something if you do that.
I kept wondering why the stack pointer started at 0124 and was about to look it up but of course I should have known that Ben would cover it (21:02). These are some of the most informative videos on these topics that I've ever seen. A+
It's probably the result of some random leftover current, or capacitance, that S started with that value.
If you're adding RAM, I'd like to suggest 640k of it. That'll be enough for everyone.
Unfortunately we don't have enough address space unless we do some fun segmentation/swapping to work with >16 bit pointers. 16 bits is 65536 addresses, or 64K, not 640K.
@@timh.6872 I know. It was a joke. ;-)
Bill gates reference !
@@MaxTheDragon yo
@@andrevc85 xD
0:00 was the moment I anxiously have been waiting a month for. I really love the story-arc presentation style. You tell us there is a problem and then keep the tension on until the moment of resolution. You have successfully figured out a way of teaching computer science in a story format.
At 9:41 I had this crazy moment when I realized the call stack (which, as a python/JS programmer I think of as this abstract thing that exists somewhere in virtual memory) is a literal physical object in this system - that is missing - and as a result the poor microprocessor has dementia and doesn't know where to come back to. I've never been able to get into low level systems before, but your guides make it approachable and easy to follow. Thanks!
I'm dying to see the next episode already. Your videos compressed about 2 years of university lectures in a few hours. This is what multiple lecturers couldn't coherently explain to us in class. Insane how all of a sudden everything fell into place in my mind.
you are a blessing, thank you for existing.
Very nice. I've known this stuff for decades, but listening to you is like hearing a live performance of a favorite tune. Thanks.
23:18 I don't think you drew it upside down - its a stack so things get piled on top of each other to build a stack!
Really insightful video - thank you
When I was in high school my dad bought me an AIM65 single board 6502 computer. Watching these videos brings back so many good memories of when I first started into computers.
I'm second year computer engineering, and these videos affirm that I am doing what I love!
Ben, please... never stop making videos. You are awesome
I cannot explain , how much of benefit it is to me to watch these , not financially but intellectually.
Ben is the best instructor ever! Also my kits have arrived and it is perfect. Thank you!
Being (or having been, back in the days) a fairly experienced 6502 assembly programmer, I have always thought the stack were inside the processor. It is amazing to learn everything anew even a level of abstraction less - or two. Keep up the amazing work!
That’s not surprising, reserving some RAM for the stack was one of the 6502’s (and 6501 before it got pulled for patent infringement) cost cutting measures against the 6800. 6800 had a lot more registers too! Since programmers were accustomed to separate stacks, the machine code still acts as if it’s an onboard location. Indeed some latter interface chips had enough RAM for the stack so it could operate even without proper system RAM, which no doubt further pushed that perception!
This is mind boggling. I was a contractor at Apple back in the eighties. I remember one of the engineering teams at Apple getting a fancy HP buss analyser that cost thousands of dollars. They were doing just about the same thing you are doing with a ten dollar Arduino mega. We live in an age of digital wonders.
I’m completely ignorant when it comes to this stuff, but I’ve been following the series and I love it. Thank you for making great content.
this is the best intuitive explanation for RAM i ever heard
I love how you‘re producing high quality, often also relatively long, videos instead of this 10 minutes clickbait ad-spam stuff which can be found all over youtube.
Your content is extremely interesting (though complicated xD) and unique to your channel.
Keep up the good work!
I know everything on this video and I still love watching
Same here. I'm currently writing assembly code for a C64, but I can't help smiling and nodding as he explains.
With a computer science degree, this isn't new to me, but I didn't know about the 6502 and how similar it is to "good old" x86. The basics are the same. What was a bit frustrating for me during my studies, was that I knew roughly how it all related to the electronics, but I didn't know how to bridge electronics with microprocessors in practice. Modern processors are made in laboratories, and the other hardware is also much too advanced for a hobbyist. Thanks to videos like these, that show how easy it can be with a processor like 6502, ROM and RAM chips, that seemingly impossible barrier is no longer impossible. I can sit down and make my own computer, just like that, and that just feels awesome. Hopefully I'll find the time to do just that.
Microcontrollers are a good way to get into hobby computing. If you don't want to go too deeply into the hardware then you can use one of the Ardunio computers, but it's also perfectly possible to build something simple with a PIC chip.
Not so long ago, I programmed a 8-pin PIC to act as a white noise generator using one of its pins as the output and using a 32-bit pseudo-random number generator adapted from a software implemented shift register. That was fun.
One of the best bits is that because of the voltage tolerance, I can run it from a single lithium-ion rechargeable cell. I only needed to add a speaker to get the output, but with a buffer transistor I get more volume since it acts like an amplifier. Exactly four components in the end: PIC, transistor, speaker and battery, and I now have something I could use to make white noise to sleep by.
I cannot tell you how happy I was to see someone using paper in technical videos. I constantly diagram and outline with pen and paper. Very effective presentation! Also, I never knew what stackoverflow meant. 😅 Thank you!
Now this is the content I want to see on TH-cam!
The best explanation of stack overflow that I've ever heard. Thanks, Ben)
I took a class, "integrated circuits with computer applications" and this is the sort of stuff we did but on a very very fundamental level and ive been trying to find a channel just like this. Thanks for your work.
Your channel is a gift from God.
You deserve nothing but the best.
Thank you!
there is something extremely relaxing about his videos, I do not know what it is
You are right; i would put it down to his calm voice, and the thoroughness with which he explains how things work.
Agree with Berty.
As a fairly experienced (modern c/c++) programmer but comparatively inexperienced in electronics, he explains everything in the right level of information and depth for me.
I'm not building a computer like this (yet), but has helped me understand electronics, computers, and programming at a lower level than I had.
And understanding something the first time its explained is very relaxing :^)
Amazing video! I'm a software developer by trade and it's been fascinating to gain better understanding of the inner workings of computers.
Tip: Press single quote (') twice to jump to last edit location.
I became inspired and wrote a 6502 emulator in C from scratch, something I always wanted to do. Your videos keep me focused.
Man, I wish there was a TH-cam Ben Eater channel back in the 70s when I was learning this stuff. Back then there wasn't even anybody you could ask about stuff. You figured it out the same way you figured out the hardware: by making endless mistakes and trying stuff over and over and over and over and.. aw, you get the picture. Anyhow, thanks Ben. Young fellows today don't know how lucky they are! Much less head-bashing required and many long miles walking back and forth to the library in the pouring rain. Ha ha! Cheers.
Worst part about your videos is that once they end you end up with emptiness and you have to wait a month for a new one :(
Great work, thank you for that!
I've been really looking forward to this video. I wanted to see how you explained the stack to the layperson. I think the stack, with the JSR and RTS instructions are the neatest concepts of the 6502, or any processor for that matter.
I wrote a 6502 emulator a while back. Coding the stack related functions was some of the most fun parts of the sub-project.
Ooh. Is it open source? I'd be interested in checking it out.
@@kneesnap1041 Not at the moment. I want to put it on Git Hub. I just haven't gotten around to it.
This is so deeply relaxing. There are so many things that I wanted to see working long long ago.
The way you sync ur monologue and the video is amazing! It makes u think its a one cut for real!!!
So, after seeing the GPU videos, my only remaining wishes would be a multi-core CPU and a self-built FPGA.
Your work is truly amazing.
I've heard the word Stack Overflow for years and years and somehow I've never once wondered what that actually meant. Now I understand sort of.
this is definitely something else bruh.. duuude you take a concept like stack overflow and you make it look like it's ease.. and you actually make it easy to understand.. bro you're a genius
Level 11 educational genius.
Complex topic broken down into digestible and memorable chunks.
I'm not even 15 minutes into this video, but it's so amazing... I love the stuff you make Ben. I want to do some of these projects so bad. I will have to free up some time in the future to do so.
I love you channel, seriously.
Ben...you've earned another Patreon supporter. Your videos are helping me get back into small electronics hobbying and the information i learn at this level has helped me at my job immensely. The way you explain things just "clicks" for me and the pace keeps me interested. Your format of allowing mistakes and walking us through the thought process is huge and helps keep my brain trained in critical thinking mode even as I dip into my mid thirties!
After facing so much trouble with teachers in my own style of learning I find your videos a reason not to lose hope. I plan on trying to become an electrician and then use that money to write books on my fictional story novels. Then once I am confident in my own inventions I will write DIY books and patient my own stuff to go with the DIY books. Even if I have to pick up an average pay job to get there I will do it. I am just glad there are people like you Ben that has shown it is infact possible to learn. I am not a lost cause.
Interesting, I always thought the stack was part of the CPU, like the stack pointer register is too. In modern CPU's the stack is still part of your internal RAM?
Ironically, stackoverflow has an answer for you. stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap. So the stack is in RAM but due to the cache system in modern CPUs, it's probably stored inside the CPU cache most of the time.
Not only is it in RAM, you can manipulate it from inside your own program. This is how green threads work.
Yep. In modern computers, the stack pointer can be adjusted to point anywhere in RAM. Multitasking OSes create a stack for every process, in fact. And that RAM can be accessed like any other parts of RAM, and even moved around or shifted out to long term storage if memory gets low, and shifted back in when needed.
The stack will always be a part of the ram, in multi thread/process operating systems like windows each thread or process gets its own stack and heap
@@Selicre Great care should be taken if you "mess around" with the stack, though; an "unbalanced" stack is a recipe for disaster.
Please add a ZIF socket for the ROM chip while you're adding RAM :)
That seems like a very good idea.
Yeah it is somewhat irritating to have to pry and then push back a large chip in a breadboard.
Fantastic Video Series. I grew up in the 80 computer boom and never quite understood assembler code. You explain it so well, really wish my computer science teacher explained it like this. I'm getting the urge to pull my BBC out of storage and play around with 6502 assembler.
You drew the stack memory locations properly. In computers we consider (and list) the lowest memory address first and list the increasing address locations progressively under them, just like when we count: 0, 1, 2, etc. Now what you have to remember is the address at the top of the "list" is LOWER in memory and the address at the bottom of the list is HIGHER in memory.
So, sometimes we call the lower values listed at the top address (listed first) BOTTOM (where they start), and the higher values listed at the bottom address (listed last) TOP (where they end). So, no matter how we "list" our memory addresses, BOTTOM is toward lower values, and TOP is toward higher values (which looks inverted at first glance). However, when we look at Stacks, the lowest address (0FF in this case) is still listed first, and the highest address (1FF in this case) is still listed last. But the highest address is called the BOTTOM of the stack and the lowest address is the TOP of the stack. Why is it reversed (and not inverted so to speak)? Because the Stack works backwards in memory starting from the highest address (1FF) and works backwards towards the lowest (0FF). Why? Simple. Because we call it a "stack" and we "list" memory starting with the lowest address first, we can visualize the stack the same way we list memory. So we start at the BOTTOM of the stack at 1FF, then we "stack" the next value (1 address back in memory) at 1FE "on top of that" visually. Just like a stack of books.
RAM:
Address 0000 RAMBOT
Great insight, would learning about stack help newbies understand pointers? Thanks
@@hf2138 Note: I have simplifed this to use 8 bit addresses, the 6502 uses 8 bit addresses 0x00 to 0xFF and 16 bit addresses 0x0000 to 0xFFFF, but you should get the idea. Also, I am not using the exact 6502 Assembly Language here - I don't have the book in front of me and it has been decades for me, but it should give you an idea - we call this "Pseduo Code": not exact code, just an informal notation for discussion.
The Stack is a good place to introduce pointers. The CPU has a Stack Pointer. A pointer is merely 'something' (like a register in a CPU), that does not hold a value, per se, but rather holds the "address" (the place in memory where some other value is stored) that is... it "points" to something rather than "holding" something.
For example:
The Stack Pointer (SP) contains 0x82 (that is how we write Hex values, 82 in this case, in some languages). This means the SP is "pointing to" memory location 0x82 and that is where the next "thing" you "push" onto the Stack will go. Note: MEM is Memory (specifically RAM in this case) and ACC is the Accumulator register inside the CPU.
Say we have:
MEM 0x82 = 0x?? Which is anything left over from the last time the Stack used this location, we sometimes call "anything" or "unknown" simply "garbage".
SP = 0x82
ACC = 0x44
PUSH ACC Push the contents of the Accumulator onto the Top of Stack,
The 0x44 from the Accumulator will be placed at memory location 0x82,
The CPU will then decrement the Stack Pointer by 1 to "point" to the
Next free location on the Stack.
The Accumulator is still 0x44 but a "copy" of it is now on the Stack.
So now:
MEM 0x82 =0x44
SP = 0x81
ACC = 0x44
Now you can use the Accumulator for what ever you want and it's value can change
all you want.
ACC = 0x00
ACC = X + 1
and whatever...
Then, when you are done and want to "restore" the Accumulator to what it was before you mucked with it...
POP ACC Pop the contents off the Top of the Stack into the Accumulator. The CPU will increment the SP by 1
First (the SP goes from 0x81 to 0x82), then the contents of memory location 0x82 (which is still 0x44 from when
we pushed it there before) is moved into the Accumulator.
MEM 0x82 = 0x44
SP = 0x82
ACC = 0x44
The Accumulator is now just like it was before.
The 0x44 is still at memory location 0x82, but it is now considered garbage and that is where the next thing pushed on the Stack will go
because the SP now has 0x82 in it (that is the SP is pointing to memory location 0x82).
You can see how this is very powerful, we can keep things on the Stack and not worry exactly where they are, as long as we Pop them off
in the reverse order we Pushed them on.
It is good practice to make sure you always Pop off the exact number of things you Push on the Stack. Failing to do this can lead
to a condition called "Stack Missaligment" or even "Stack Overflow" or "Stack Underflow".
You can do a lot of fancy things with the SP, but normally you let the CPU "manage" it for you.
One thing you will see (and do) often is called "Context Switching". This when we need all or almost all of the CPU Registers and Flags to do something, then we need to get the CPU back to the same state (context) when we are done. In this case, you Push everything inside the CPU onto the Stack, one thing at a time, and when you are done you Pop all those things off of the Stack back into the CPU... and end up just like nothing changed. You will see and use context switching in "Interrupt Routines".
The CPU can be told to "interrupt" what it is doing, do something else, and come back and pick up where it left off. Since we may never know "what" the CPU is doing or has inside it when an Interrupt occurs, "Saving the Context of the CPU on the Stack" allows the Interrupt routine - called the Interrupt Service Routine (ISR) - to do whatever it wants to the CPU, then just before it returns from the ISR, it can "Restore the Context of the CPU from the Stack" and go back to what it was doing like it never left (except some time has elasped).
Then you can go on to "indiection". This is where you use a register, say the X register, not as a place to hold a value but treat it as if it holds the "location" of a value. Does this sound familiar? Yes, you can use the X register as a "Pointer". We could say, Load the Accumulator Indirect by X:
MEM 0x56 = 0xF3
ACC = 0x??
X = 0x56
LDAIX Load the Accumulator Indiect by X: The CPU will use the contents of the X register as a Pointer and load the Accumulator with the contents in memory from where the X register is pointing.
MEM 0x56 =0xF3
ACC = 0xF3
X = 0x56
The X register is pointing to memory location (address) 0x56, address 0x56 contains value (data) 0xF3, and that data 0xF3 was moved (copied actually) into the Accumulator.
Do you get the idea?
Thanks, I guess I assumed that the stack was part of the cpu. Learned something new.
Isn't it weird the processor stores the return address on stack BETWEEN reading the lower and higher byte of the jump address?
It is also weird, that it actually stores the address of the lower byte of the jsr address.
I would have expected to see a 0x800F on the stack as this is the address of the next instruction.
@@kallewirsch2263 that's actually because the processor increments the PC before each instruction. so after fetching the return address and before running the next instruction it will increment the program counter and thus resume in the correct place
@@piotraniola5393
I thought that too (That the Von Neumann cycle would start with incrementing the PC) and I did a check.
It is indeed an exception for the jsr and ret instructions.
You can see it with the jump instructions. In the opcode the target address is coded without subtracting 1.
This was the point when I became unsure and I used the "last resort" - google. It is indeed a well known exception for jsr and ret instructions. jsr pushes the address of the last address byte and ret compensates for that by adding 1 before assigning to the PC.
Which begs the question: how does it work with interrupts. Well, a reti (return from interrupt) does not add 1 to the address poped from the stack. :-)
I can only guess: The designer had some troubles in the jsr instruction to get his hands onto the address of the next instruction before performing the call by assigning the target address to the PC. Thats why he used the last known good value for PC he had, which was the address from where to load the low byte of the target address.
But this is only a guess. I am not very familier with the inner workings of a 6502. I always prefered a Z80
Piotr, the timing of the storing of the return address on the stack within the execution of the JSR is about selecting the time when the internal mechanisms have the correct value (of the PC register) able to be saved before it gets re-written by the JSR's target address.
This is so utterly wonderful! The brilliance of the step button for the clock completely demystifies what's happening. Every software engineer who leverages high level languages should watch these videos to understand what's really happening inside the machine!
The world of academia and higher education can make concepts like this very intimidating, but something about the way Ben Eater composes his videos makes each concept simple and enjoyable. When I'm getting a bit worn out on my computer engineering journey I love watching this series and reminding myself why I love this kinda stuff.
I love seeing how adding the flags made the size of the file smaller and how using recursion in your computation can shrink the program while keeping the same result. It would maybe be cool to see some stuff about brainfuck lambda calculus or turing complete languages that are minimal in their construction but they can achieve the same results as something more "static". I know you're more of a digital electronics channel though. Just a thought love your videos!
That's not recursion, just function calls
Recursion is when a subroutine calls itself. Very much possible but you'd have to make sure you have enough stack to do so.
In this case, you can recurse 128 times assuming nothing else gets pushed on the stack.
Adding flags? What flags?
Quick question: how did you know the address for the subroutine lcd_instruction was 805d?
the compiler takes care of that
Can find where it compiled to at 3:23
@@mfaizsyahmi *assembler ;p
At that point in the video I didn't know it was exactly 805d. But I knew the program started at 8000, and was ~130 bytes long, so 805d seemed like a reasonable address for the subroutine.
That said, I could have looked through the assembled binary to figure it out. For a larger program that wouldn't be very fun, but the assembler can also probably generate a symbol table, though I'm not sure off the top of my head how to get it to do that.
For vasm it looks to be -L . It shows what it parsed from the source, what op codes it generated, and the address it put them at. Then at the end it has a table of the addresses of the labels in the program.
17 minutes in and I have a very clear understanding of what a stack overflow is
@6:20 I'VE BEEN CHASING THAT BUG FOR MONTHS! lol. Thanks for the fix and the 6502 kit. Keep oooon teachin' man.
20:08 stackoverflow 😆 nice.
The Z80 has a 16 bit SP so the stack can be anywhere and any length. And "anywhere" of course means 64 kB because these 8-bit CPUs only have 16-bit addressing for memory. It is interesting to see the differences between the Z80 (which I know very well) and the 6502, two 8-bit processors of the same era. The 6502 can be classified as a RISC and therefore much more limited in the programmer's view but also slightly faster per instruction, and the Z80 a CISC.
So that's why it's called a stack, ive always wondered why it needed that structure to it. Awesome video!
The stack has always been something mystical to me. Thanks for clearing things up in this logical and basic manner!
6502 Part 5: Optimization and O Crap Need RAM
why is "jump to subroutine" -> jsr
and "return from subroutine" -> rts and not rsr ?
*Acronym characters*
*Jump*
To
*Sub*
*Routine*
*Re*
*Turn*
From
*Subroutine*
because the return instructions in the 68xx series start with RT
@@Mostlyharmless1985 aahhh ok, thanks :)
btw i am not a coder, just wanted to know.
Because there are other jump instructions, so "emphasising" that it's to a subroutine makes sense. But there only is one return instruction so there is no reason to emphasise that it's to a subroutine. In some assembly languages, the return instruction is even just called "ret".
@oH well,lord! The Z80 uses the mnemonic RETI for the RETurn from Interrupt instruction
I want to thank you for the content you make. I watched a lot of videos, but only YOU could (for me) explain the logic of the processor in such a way! Thank you so much for your work! I wish you further development of your channel!
Who is Stack and why does he always overflow?
You could have added a buzzer to the processor... this way when the processor starts and detects that there is no ram, you end up getting 3 consecutive beeps... Oh the joys of making a BIOS or CMOS...
Never understood why stack overflow could lead to arbitrary code execution until now. Thank you for a clear explanation!
Your videos are as close to perfection as humans can get. Super clear, super informative, super super super :)
Also am I the only fan here that gets a bit of good ASMR to keyboard clicking when you go into fast forward mode in these awesome vids :)
Forgot to download the ram, rookie mistake
Wow... I've always wondered as a programmer what was actually happening during a stack overflow. Great breakdown and explanation as to what happens on a hardware level when stack overflow occurs. A sincere thank you!
Very nice videos Ben! I am grateful for the content, and I still enjoy listening to the podcasts you did with Ben and Grant a couple years ago
Thanks for your videos, Ben!
As a part of my astrophysics graduate research I'm doing lots of high performance computing, which involves writing and optimizing codes that work on thousands of nodes.
During workshops, lectures and trainings on these topics we used to learn lots of rules on what compilers do to minimize the number of floating point operations, efficiently exploit resources etc, and what we as (quasi-)developers should do to help compilers make our life easier (and our research cheaper ofc, because we pay for node-hours). This advices/rules sometimes come in a pretty handwavy almost magical manner: "use this particular # of threads on these GPU-s, or inline functions when vectorizing because ... well just because."
I have almost zero CS background, so these advices sometimes come as magic unwritten rules to which I have to believe (I studied theoretical physics my whole life, and I learned to code maybe a few years ago). So your videos help a lot in seeing and justifying why some of these rules actually work, and how the high-level code is then translated into a basic machine language.
And also, the format you chose is amazing, unlike a boring documentation or a lecture series. I love the "reinvent the wheel, make it yourself from scratch, and then learn by interacting" format. I know for lots of people this might be something very basic which they learn in the first year of their undergrad. But for me it's very enlightening! So thanks a lot :)
The way you navigate through code just using keyboard! Wow!! Just awesome!!
i like how he legit is so smart, that he planned all of the stuff in his videos and making it so seamless that it's fun to watch
Excellent explanations, as usual. The amount of effort, planning and thought you put into your videos is admirable. Thank you for doing this. I can’t wait to get stuck in with the kits I’ve ordered from you!
Dang dude, that stack overflow explanation was like a eureka moment for me!
Your videos are something else man ! The effort you put in mind blowing.
Handsoff 👋
Lately been finding lot of good channels on TH-cam, definitely loving these videos, gonna look up more and catch up with whatever you have done so far
That S icon flashing up at 9:37 is SnagIt, in case someone else was wondering.
There also was a similar-looking C icon that flashed up in an earlier video, which was for Camtasia.
It is interesting to see what tools people are using.
I really love the style of your videos - you obviously know in advance what hitches you're going to find, but I love that you explain it in a way that the audience 'discovers' the solutions with you.
This series is incredible - thank you!