This! I hate running make as it never works for me. Some library doesn't import properly and I have to manually install everything and I'm on a debian based distro. This is why I prefer cargo.
@@gljames24 There's always a way to get there with make: if you can figure out the command line to do compile or assemble a program, that's what you put in your Makefile. Then you can make it more flexible if you like. To me, make is the easiest way to get all of those compiler and linker switches right, and never have to mess with them again. The hardest part, really, is getting the linker to find any libraries, which is often different for every OS. But that's the OS's problem, not make's.
Absolutely not the first try. I don't know Ben, but from his videos I would guess that he records the process he goes through to get something running, THEN writes ths script to cover how to troubleshoot the pitfalls. But however he does it, he is certainly the best teacher I've seen for this subject.
@@BrightBlueJimbut doesn't he always show the errors and fix them? Yes it's most likely that he already knows how to fix the errors but he again simulates the fixing scenario
I thought the same for a while but back in the breadbaord days, those jumper wires were exactly the right length and pre-bent, so he did a ton of work ahead of time.
First of all, it IS Christmas for Orthodox Christians. Secondly, producing quality content requires a lot of time, research and effort. I'd rather get consistently great videos from him, and hope he gets enough rest in between.
I've said it before and I'll say it again, your teaching style is PERFECT. By incrementally showing things that don't quite work and gradually approaching the correct answer, you leave us with an understanding of WHY things are the way they are. This is how new knowledge can be retained. Oh how I wish all my teachers in the past taught this way!!! THANK YOU, BEN!
Well, it could be a problem, if the computer that you built isn't just a duplicate of a popular machine. This to me is what makes Ben a giant. He points out what the problem is, and then goes immediately to the solution. To me, this is much better than just showing how to set up a .cfg file for the linker. You get a sense of why the linker HAS .cfg files, and teaches you not to fear the "magic" files.
@@bobhillier921 80s also, but more 90s. PCs were already blackboxes to me. Add virtual memory, accessible C compilers instead of ASM, hardware abstraction and... boom, black magic.
I was building 8086 embedded systems in the 90s. Different memory layouts, but I remember many battles with the linker. Honestly, this is one of the best introductions to linking I've ever seen. Great work, Ben!
Wow, this is an amazing introduction to compilers AND linkers working together. I'm using linux as my daily driver OS and I was wondering how it all worked, and I am very thankful for your awesome explanations. Truly amazing!
Wow. Where was RUclips in the 70s when I was figuring all this stuff out in my room?! Ben does a great job with these videos and elegantly brings these concepts together. Thanks!
Same! I was struggling way too much with this trying to make a C64 cartridge with a custom program on it. Maybe I just looked in the wrong places in the docs, but this video explains the linking and mapping so cleanly.
Crazy for me that my first real experience with assembly coding was 6502 on the BBC back in 80-something when I was a teenager and here I am dredging memories back through 40+ years of mist. Thanks.
Following Ben's videos has given me great hands-on experience and including these projects on my resume actually helped me land an internship at HP (which turned into a full-time engineering role). Thanks for these wonderful videos and kits Ben!
I literally have 0 idea what I just watched and understand like none of it but for some reason I watched the whole thing and will be watching the follow up. Thumbs up 👍
Another big winner, Ben! At first I said, "meh, I don't need to know how to make a BIOS", but then I looked at some of the comments, and realized this is more of a "how to get started on software development for a new machine" video! Swiping Wozmon was one thing, but showing how to navigate between assembler, linker, and symbol table files, and setting up the configurations for the linker was really essential information that is rarely seen in such a concise form. I can't wait until you have a disk emulator for your machine, so the assembler and linker can be loaded from an SD card and run on the 6502 itself, rather than having to do the development stuff on a Windows machine and flashing EEPROMs.
I love the layout of these videos. It's very much how I deal with problems every day; work through errors as they come, adding information until it's happy, and balance it with what I learned from articles on the matter. Love this series, thank you for sharing your project with such detail and quality.
Do you immediately have a clear and concise solution to every problem you face in a way that supports a narrative and gives an opportunity to highlight a concept ? cool
@fjkldhakljf Oh no, there's a lot of headscratching and cursing lol. I'm sure Ben also takes his time in working it all out, but he presents it in that programmatic way minus the thinking time.
Ben, I've got to say - I've learned more for your videos about microelectronics and low level coding than through my CS classes. Thank you for doing wonderful work
Wow, now as a retired man I simply see a way of education, I missed so badly in the 80's-90's! This is a description in 20 minutes for what I needed days or weeks to understand so long ago, when I started my migration from a kind of breadboard Z80 with less than 1KB of RAM to "THE REAL" C-64! As I never was much interested in the Basic language, I always appreciated the clarity and power of Assembler code. At first I had to literally assemble "in my mind" and the input was in pure HEX codes. So assemblers and linkers were completely new and difficult things to understand.
I love that you're making these videos. You have a great style of explaining the concepts. Back in the 80's when I was learning this stuff, this would have been absolute gold to have on a VHS tape. While not useful or accurate for today's computers, it's still a great basic education on how computers used to work. Thank you!
Thank you for this one. Ive done IT for decades, started back with 8 bit computers. I learned basic, cobal, pascal, then moved over to scripting in perl and python. I never did understand C past some basics. Ive always wondered what the linker did and how the symbol table worked and this did a great job explaining it.
It is extremely interesting: following the process is much more understandable than when youtubers just show the results. Because when you follow the process each step feels more managable and thus the video feels motivating.
Just mind blowing. Outstanding well made explanations. There are not many people around, making understanding basic computer knowledge so easy. Every IT student should watch those videos.
6502 is something I've wanted to get into for a while, but none of the tutorials did a good job of explaining what was actually going on. This video clears everything up lol. Although my experience with compilers and linkers has increased a lot since I last tried.
I've programmed on my Atari with ca65 and the key to using it is understanding the memory mapper configuration as explained on here. Programming on these old architectures forces you to do things more manually and learn about things that are done similarly on modern computers but handled automatically by the compiler and linker so you can get away with not knowing it.
Ben you are the best. I've been "watching" you for some time and your job is at least to speak amazing. keep the good job. The content you are doing, making is teached on collage studies. keep the good work on. You have my support. Cheers and big love.
Worked about 10 years with compilers and linkers and never know whats really in the object-file and how the linker does it's magic ... until now ... thank you Ben ✨
thank you for your rudimentary tutorial on git and i use the term "rudimentary" rather loosely because it was far more useful than basically any tutorial ive ever watched and any book/manual i've read.
This really is nerdpron. But it reminds me of something I went through back in the mid-80s: a friend of mine bought four broken "graphics terminals" made by a company called ISC, who also sold the Compucolor II home computer. He offered one of these to me, if I could help him get them working. And we did get all four to work. But that was just step 1. The terminals had 8" floppy drives on them, and were meant to run CP/M, but he didn't have an ISC CP/M disk for them, just a generic CP/M with BASIC disk. So just as Ben did, we had to write BIOS functions so that CP/M would know how to read the keyboard and put characters on the screen, as well as how to turn a given pixel a given color, which we accomplished in a day or two, leaving us with four fully functioning CP/M graphics computers! They even had light pens for graphical input, which we also had to write CP/M "drivers" for, which was another fun project - all of this was with no documentation at all, since Google was still 15 years away.
It isn't necessary to create a separate memory region for wozman, just use an overwrite segment, like " WOZMON: load = ROM, start=$FF00 type = overwrite;"
You do get more controllable behavior with a separate memory region though as you'll avoid accidentally overwriting anything if something has a different size than you expect.
@@celeron55 Respectfully, this isn't really much of a concern. And creating many such memory regions for every segment, quickly becomes inflexible and error-prone.
@@tux1968 I used to be a CS teacher. Most often you need to carefully decide what to include in a lecture. Too little slows things down, but too much has students confused and overwhelmed. These are big decisions and they are invisible to the students. -- Ben has tons of these decisions to make for every single episode, because there's so much more to tell at every point.
@@georgwrede7715 None of that changes the facts. The fact is, it's more appropriate to use an override segment than to manually carve up the memory regions. And I hope my comment might help someone who is learning. That fact doesn't diminish the great work Ben does, or the utility of his fabulous videos.
Back in the 90's there really only was TASM with a MOS6502 table (afaik) to do that. It was a DOS program and did by default just output an amorphous blob. I used it to write programs for the C-128 and transferred them over a lpt>userport cable i soldered together. Seeing how there are whole tool chains now that would let you in a wacky way compile anything you can translate to C is just mind blowing.
Woop! I've been watching your videos for years and I've learned some 6502 through them; then recently I made a game for the NES and used the cc65 to compile it :) so cool to see you using the same tool! Btw, instead of defining a separate vectors memory location, you can define a segment with a start adress into the ROM memory :) like so: "SEGMENTS { ... VECTORS: load=ROM, type=ro, start=$FFFA; ... }
Wow. Very cool, Ben, very cool. It just keeps getting more and more sophisticated... I've really gotta get back to building out my 8-bit kit, and then maybe get the 6502 kit, too. :)
Awesome as always. When you said you were going to rearrange the code a bit for when the project gets larger, your approach wasn't quite what I expected. My assumption was that you were going to have separate bios.s and wozmon.s files that assemble to separate bios.o and wozmon.o files (and eventually resetvec.s and resetvec.o), and let the linker handle combining them based on the segments they define. Then you could extract your address constants to a shared constants.h file that both bios.s and wozmon.s include. That would keep the dependencies more visible, because as-is wozmon.s only implicitly inherits the constants by being included into bios.s. Keeping track of what order files are included-and thus what constants they can see-will get more complicated as the project grows. My only experience is with C, though, so I don't know if assembly has different conventions. And at any rate it's hardly a problem! I'm looking forward to the rest of the series.
That's quite a hassle to achieve by manually invoking the compiler and linker. I can imagine him showing such an approach and then slowly working towards creating a makefile, but I think it would be a bit much for in this single video.
While probably not a bad idea (especially if he were planning to build an os for commercial use...), the bios has to be referred to, anywho, for anything else. If you have to replace it, you're probably going to be making another constant set. Even working with C I might do the same...but only cause I see it as apart of the same function.
@@rya3190 Yeah, for me it's more just about understanding dependencies. When you're implicitly accessing symbols through your importers, it's just a bit harder to keep track of what's using what, and what symbols are safe to change/move/remove/repurpose. It's definitely not vital, but just also not where I thought things were going.
Always a good day when Ben posts a video 👍 It's almost like he knew I should stop procrastinating and do some more on my DIY Acorn Electron that he inspired 🤦♂️
Awesome! I was wondering where you’d be going with this. I’ve been studying FPGAs since you last videos on WOZMON. I’ll have to get back into this when I get to a good break point. This reminds me of learning the linker for an IBM PC clone back in the ‘80s when I had to create pixel plotting routines in assembly language so I could plot data in FORTRAN. It took a while to figure that out since that was pre-internet and there weren’t any tutorials on it. I had to work from the obscure reference manuals. Fun stuff. Thanks for all your work.
If not, keep the BOMs Ben's posted to his website. It's not too difficult to piece these kits out yourself if you have to, as everything he uses is likely to be made far into the future. But yeah, if I ever adopt or have kids, I'd like to introduce them to electronics like this too.
These videos make me wish I still wrote software whose stack wasn't a million billion lines of code, a database and multiple parsers of multiple languages. The Web.
(I know your comment is getting a little old, bust I wanned to give a some info) The 6502 didn't have suport for the instructions DEC and INC to work on the A register, that feature was added in the 65c02 version of the cpu. the original could only decroment and incroment a number in ram by one using DEC and INC, even though there's a variant of them for the X and Y registers being DEX, INX and DEY, INY respectively
He should hire someone to design a case for thia thing once its done and make it look like an actual tower PC (And maybe program a basic OS for it at well :D )
Most impressive part of this is that running `make` worked on the first try.
This! I hate running make as it never works for me. Some library doesn't import properly and I have to manually install everything and I'm on a debian based distro. This is why I prefer cargo.
@@gljames24 There's always a way to get there with make: if you can figure out the command line to do compile or assemble a program, that's what you put in your Makefile. Then you can make it more flexible if you like. To me, make is the easiest way to get all of those compiler and linker switches right, and never have to mess with them again. The hardest part, really, is getting the linker to find any libraries, which is often different for every OS. But that's the OS's problem, not make's.
It was super likely to have not been the first try...
Absolutely not the first try. I don't know Ben, but from his videos I would guess that he records the process he goes through to get something running, THEN writes ths script to cover how to troubleshoot the pitfalls. But however he does it, he is certainly the best teacher I've seen for this subject.
@@BrightBlueJimbut doesn't he always show the errors and fix them? Yes it's most likely that he already knows how to fix the errors but he again simulates the fixing scenario
I like to think Ben shoots these videos without a script, live, in one shot, having never approached the subject before.
I thought the same for a while but back in the breadbaord days, those jumper wires were exactly the right length and pre-bent, so he did a ton of work ahead of time.
No he just look at the breadbord and cut and bend them perfectly the first try@@brianmiller1077
@brianmiller I believe that you can buy those breadboard wires pre-shaped.
@@ellettdavis6066 Where?
😂
Ben Eater is literally the Bob Ross of electronics
There are no bugs, only happy little accidents
Happy little black red tree
I have said that already years ago ;)
@@Oli1974I remember that comment
@@Oli1974I literally said it.
A new Ben video is like Christmas for computer engineers. Please post more often!
First of all, it IS Christmas for Orthodox Christians. Secondly, producing quality content requires a lot of time, research and effort. I'd rather get consistently great videos from him, and hope he gets enough rest in between.
@@guiorgy he just needs to try harder, bro
@@guiorgy 🤓☝
@@guiorgy my words were intended as encouragement and appreciation. I obviously do not demand anything from Ben :)
@@guiorgyuMmMmM aCtUaLlY
I've said it before and I'll say it again, your teaching style is PERFECT. By incrementally showing things that don't quite work and gradually approaching the correct answer, you leave us with an understanding of WHY things are the way they are. This is how new knowledge can be retained. Oh how I wish all my teachers in the past taught this way!!! THANK YOU, BEN!
"...unfortunately none of those are the computer that i built"
what a problem to have
Well, it could be a problem, if the computer that you built isn't just a duplicate of a popular machine. This to me is what makes Ben a giant. He points out what the problem is, and then goes immediately to the solution. To me, this is much better than just showing how to set up a .cfg file for the linker. You get a sense of why the linker HAS .cfg files, and teaches you not to fear the "magic" files.
The hardware version of 'stackoverflow thread does not exist'. That's when you are really screwed.
Sir you are really doing the Lord's work here. Where were you in the 90s?!
Looks closer to an EE's work. Impressive nonetheless!
In the 80s?
@@bobhillier921 80s also, but more 90s. PCs were already blackboxes to me. Add virtual memory, accessible C compilers instead of ASM, hardware abstraction and... boom, black magic.
I was building 8086 embedded systems in the 90s. Different memory layouts, but I remember many battles with the linker. Honestly, this is one of the best introductions to linking I've ever seen. Great work, Ben!
@@KevinNHaw 8086 embedded in the 90s, didn't know those exist at all!
Your teaching method of incremental modification is really good! Thank you for sharing your gift of educating others with us using a subject we love!
Wow, this is an amazing introduction to compilers AND linkers working together. I'm using linux as my daily driver OS and I was wondering how it all worked, and I am very thankful for your awesome explanations. Truly amazing!
So true, I remember using 'Blinker' back in the day and this video shows exactly what 'linker/loader' are all about.
I've been writing and compiling c/c++ programs for years and never really understood object files. Now I know!
The only question I have why use a linker at all if you're going to include source files into another source files...
I still remember the first video I watched of Ben programming an eeprom by hand.
This man is a hero. I'm so glad he's still making videos.
I really appreciate how you're not just showing how it is done, but also all the errors that can occur in the process.
Wow. Where was RUclips in the 70s when I was figuring all this stuff out in my room?!
Ben does a great job with these videos and elegantly brings these concepts together. Thanks!
This is the clearest explanation I have seen on how the linker works with segments arrange where all the parts of your program go in ROM . Thank you
Wow! This was everything I was trying to dig into with CC65, but in a way I finally understand. Thank you so much!
Same! I was struggling way too much with this trying to make a C64 cartridge with a custom program on it. Maybe I just looked in the wrong places in the docs, but this video explains the linking and mapping so cleanly.
how is this comment 6 days old?
@@r3sist197 Privately listed video as an early release for Patreon subscribers probably.
@@r3sist197 Time travel ... *roll eyes*
@@charlesdorval394 ben is working on the next project for this computer: time travel
A guy using Vim to code his own bios for his own 6502 breadboard computer.
This has to be the biggest programming flex of all times.
Crazy for me that my first real experience with assembly coding was 6502 on the BBC back in 80-something when I was a teenager and here I am dredging memories back through 40+ years of mist. Thanks.
Following Ben's videos has given me great hands-on experience and including these projects on my resume actually helped me land an internship at HP (which turned into a full-time engineering role). Thanks for these wonderful videos and kits Ben!
I literally have 0 idea what I just watched and understand like none of it but for some reason I watched the whole thing and will be watching the follow up. Thumbs up 👍
Another big winner, Ben! At first I said, "meh, I don't need to know how to make a BIOS", but then I looked at some of the comments, and realized this is more of a "how to get started on software development for a new machine" video! Swiping Wozmon was one thing, but showing how to navigate between assembler, linker, and symbol table files, and setting up the configurations for the linker was really essential information that is rarely seen in such a concise form. I can't wait until you have a disk emulator for your machine, so the assembler and linker can be loaded from an SD card and run on the 6502 itself, rather than having to do the development stuff on a Windows machine and flashing EEPROMs.
I love the layout of these videos. It's very much how I deal with problems every day; work through errors as they come, adding information until it's happy, and balance it with what I learned from articles on the matter.
Love this series, thank you for sharing your project with such detail and quality.
Do you immediately have a clear and concise solution to every problem you face in a way that supports a narrative and gives an opportunity to highlight a concept ? cool
@fjkldhakljf Oh no, there's a lot of headscratching and cursing lol. I'm sure Ben also takes his time in working it all out, but he presents it in that programmatic way minus the thinking time.
This guy is such a legend! Making such technical content so accessible is a true masterwork.
I just bought the 6502 kit for Christmas and I couldn’t be happier to see this come out. Thanks Ben, fast shipping, great parts, and a joy to watch.
This is a real NerdPorn for me, this video returned me to C64 assembler and Amiga C days.
Ben, I've got to say - I've learned more for your videos about microelectronics and low level coding than through my CS classes. Thank you for doing wonderful work
Wow, now as a retired man I simply see a way of education, I missed so badly in the 80's-90's! This is a description in 20 minutes for what I needed days or weeks to understand so long ago, when I started my migration from a kind of breadboard Z80 with less than 1KB of RAM to "THE REAL" C-64!
As I never was much interested in the Basic language, I always appreciated the clarity and power of Assembler code. At first I had to literally assemble "in my mind" and the input was in pure HEX codes. So assemblers and linkers were completely new and difficult things to understand.
I love that you're making these videos. You have a great style of explaining the concepts. Back in the 80's when I was learning this stuff, this would have been absolute gold to have on a VHS tape. While not useful or accurate for today's computers, it's still a great basic education on how computers used to work. Thank you!
I've been programming since 1987, and this is the first time I've understood what the linker does. Thank you!
Nice, I was itching for a new video. Glad we are getting into CC65 stuff.
Thank you for this one. Ive done IT for decades, started back with 8 bit computers. I learned basic, cobal, pascal, then moved over to scripting in perl and python. I never did understand C past some basics. Ive always wondered what the linker did and how the symbol table worked and this did a great job explaining it.
It is extremely interesting: following the process is much more understandable than when youtubers just show the results. Because when you follow the process each step feels more managable and thus the video feels motivating.
Looking forward to the port of Unix!
Thanks!
BASIC.. uurrh, feeling nostalgic and brings back memories of late 80s for me!
Welcome back, Ben.
Happy New Year.
Just mind blowing. Outstanding well made explanations. There are not many people around, making understanding basic computer knowledge so easy.
Every IT student should watch those videos.
Wake up, Ben Eater just dropped an awesome
Awesome video, as always! Thank you and a happy New Year to you and to all fellow followers of your channel
Stellar pedagogical progression, as always! I have been recently confused about cc65 configuration and this cleared up a lot. Thank you!
6502 is something I've wanted to get into for a while, but none of the tutorials did a good job of explaining what was actually going on.
This video clears everything up lol. Although my experience with compilers and linkers has increased a lot since I last tried.
That is the clearest explanation of memory, assemblers and linkers I've ever seen. Your content is next level!
I've programmed on my Atari with ca65 and the key to using it is understanding the memory mapper configuration as explained on here. Programming on these old architectures forces you to do things more manually and learn about things that are done similarly on modern computers but handled automatically by the compiler and linker so you can get away with not knowing it.
Thanks for taking me back to the 80s
Ben you are the best. I've been "watching" you for some time and your job is at least to speak amazing. keep the good job. The content you are doing, making is teached on collage studies. keep the good work on. You have my support. Cheers and big love.
Impossible. Sheer skill and talent right here. You sir are a treasure. 🥹
Yet another stunning piece of art. Hope that I can slowly adapt to this way of working, in order to keep my project relocatable and linkable. Thanks.
Happy and Healthy New Year to you Ben and all the Ben Eater viewers! Who's watching in 2024?
amazing work Ben!
Fantastic video, Ben! I am really excited to see where you go with this! Don't keep us waiting too long! 😍
My goodness this is easy to follow, thanks very much! Always wanted to dabble into assembly.
Worked about 10 years with compilers and linkers and never know whats really in the object-file and how the linker does it's magic ... until now ... thank you Ben ✨
thank you for your rudimentary tutorial on git and i use the term "rudimentary" rather loosely because it was far more useful than basically any tutorial ive ever watched and any book/manual i've read.
Cool, I like when things are broke down to the very basic stuff and presented without any "spam".
A new Ben Eater video? 2024 is going pretty well.
Really nice, clear and amazingly valuable. Thanks.
my man is back. Love to this guy!
Great video. One of the very few videos about programming AND hardware that is understandable.
Really great work and a profound explanation how compilers and linkers work together. Thank you Ben.
Thank you for your brilhant tutorials, I really enjoy every minute. As a Apple ][ early fan, since 1981, this subject is fascinating.
This really is nerdpron. But it reminds me of something I went through back in the mid-80s: a friend of mine bought four broken "graphics terminals" made by a company called ISC, who also sold the Compucolor II home computer. He offered one of these to me, if I could help him get them working. And we did get all four to work. But that was just step 1. The terminals had 8" floppy drives on them, and were meant to run CP/M, but he didn't have an ISC CP/M disk for them, just a generic CP/M with BASIC disk. So just as Ben did, we had to write BIOS functions so that CP/M would know how to read the keyboard and put characters on the screen, as well as how to turn a given pixel a given color, which we accomplished in a day or two, leaving us with four fully functioning CP/M graphics computers! They even had light pens for graphical input, which we also had to write CP/M "drivers" for, which was another fun project - all of this was with no documentation at all, since Google was still 15 years away.
Another riveting Installment of breadboard computing! Thanks Ben!
You made my day Ben, glad to see you are making new videos again!
It isn't necessary to create a separate memory region for wozman, just use an overwrite segment, like " WOZMON: load = ROM, start=$FF00 type = overwrite;"
You do get more controllable behavior with a separate memory region though as you'll avoid accidentally overwriting anything if something has a different size than you expect.
@@celeron55 Respectfully, this isn't really much of a concern. And creating many such memory regions for every segment, quickly becomes inflexible and error-prone.
Thanks I was wondering about this. Do you happen to know ld65's behavior when the output overlaps?
@@tux1968 I used to be a CS teacher. Most often you need to carefully decide what to include in a lecture. Too little slows things down, but too much has students confused and overwhelmed. These are big decisions and they are invisible to the students. -- Ben has tons of these decisions to make for every single episode, because there's so much more to tell at every point.
@@georgwrede7715 None of that changes the facts. The fact is, it's more appropriate to use an override segment than to manually carve up the memory regions. And I hope my comment might help someone who is learning.
That fact doesn't diminish the great work Ben does, or the utility of his fabulous videos.
THANK YOU FOR WHAT YOU DO BEN
Literally just mind-blowing
Every time we think you died you post another video.
literally today i rewatched your 6502 series from ep1 to 7 lol
I just binged some videos about low level code AND THEN THIS VIDEO DROPS IN MY INBOX LETSGO
as always another AMAZING video from Ben!
I credit you for my ability to now read Assembly. Can’t write it worth a shit, but I’ll be damned if I can’t understand what everyone else did.
Back in the 90's there really only was TASM with a MOS6502 table (afaik) to do that. It was a DOS program and did by default just output an amorphous blob.
I used it to write programs for the C-128 and transferred them over a lpt>userport cable i soldered together.
Seeing how there are whole tool chains now that would let you in a wacky way compile anything you can translate to C is just mind blowing.
Woop! I've been watching your videos for years and I've learned some 6502 through them; then recently I made a game for the NES and used the cc65 to compile it :) so cool to see you using the same tool! Btw, instead of defining a separate vectors memory location, you can define a segment with a start adress into the ROM memory :) like so: "SEGMENTS { ... VECTORS: load=ROM, type=ro, start=$FFFA; ... }
Wow. Very cool, Ben, very cool. It just keeps getting more and more sophisticated...
I've really gotta get back to building out my 8-bit kit, and then maybe get the 6502 kit, too. :)
Awesome as always.
When you said you were going to rearrange the code a bit for when the project gets larger, your approach wasn't quite what I expected. My assumption was that you were going to have separate bios.s and wozmon.s files that assemble to separate bios.o and wozmon.o files (and eventually resetvec.s and resetvec.o), and let the linker handle combining them based on the segments they define. Then you could extract your address constants to a shared constants.h file that both bios.s and wozmon.s include.
That would keep the dependencies more visible, because as-is wozmon.s only implicitly inherits the constants by being included into bios.s. Keeping track of what order files are included-and thus what constants they can see-will get more complicated as the project grows.
My only experience is with C, though, so I don't know if assembly has different conventions. And at any rate it's hardly a problem! I'm looking forward to the rest of the series.
That's quite a hassle to achieve by manually invoking the compiler and linker. I can imagine him showing such an approach and then slowly working towards creating a makefile, but I think it would be a bit much for in this single video.
While probably not a bad idea (especially if he were planning to build an os for commercial use...), the bios has to be referred to, anywho, for anything else. If you have to replace it, you're probably going to be making another constant set.
Even working with C I might do the same...but only cause I see it as apart of the same function.
@@rya3190 Yeah, for me it's more just about understanding dependencies. When you're implicitly accessing symbols through your importers, it's just a bit harder to keep track of what's using what, and what symbols are safe to change/move/remove/repurpose.
It's definitely not vital, but just also not where I thought things were going.
Happy New Year Ben.
You keep amazing, Ben, looking forward to the BASIC integration video!
Beautiful. Just beautiful 🙂
Always a good day when Ben posts a video 👍
It's almost like he knew I should stop procrastinating and do some more on my DIY Acorn Electron that he inspired 🤦♂️
Awesome! I was wondering where you’d be going with this. I’ve been studying FPGAs since you last videos on WOZMON. I’ll have to get back into this when I get to a good break point. This reminds me of learning the linker for an IBM PC clone back in the ‘80s when I had to create pixel plotting routines in assembly language so I could plot data in FORTRAN. It took a while to figure that out since that was pre-internet and there weren’t any tutorials on it. I had to work from the obscure reference manuals. Fun stuff. Thanks for all your work.
It amazes me how you take what seems like voodoo and make it understandable.
So much fun to watch this evolve.
I hope you sell these kits for a long time. I'd love to give to my future kids.
And also myself when I get a chance. They seriously make awesome Christmas gifts imo
don't have kids, it's a death sentence
Buy now, put in box, label box - avoid the rush later.
If not, keep the BOMs Ben's posted to his website. It's not too difficult to piece these kits out yourself if you have to, as everything he uses is likely to be made far into the future. But yeah, if I ever adopt or have kids, I'd like to introduce them to electronics like this too.
Hell yeah some CC65 love, finally! One of the greatest 8-bit tools ever devised. A software engineering masterpiece.
I absolutely appreciate the way you present this information to us.
Beautiful, looking forward to basic and even more glorious would be writing and running simple C programs all on the 6502 system
I always wanted this. Thanks a lot for your knowledge, Sir.
These videos make me wish I still wrote software whose stack wasn't a million billion lines of code, a database and multiple parsers of multiple languages. The Web.
Such a nice new year surprise. Thank you for the great videos Ben!
This stuff is fantastic and reminds me of working directly on an Apple II in the early 80’s. Thanks Ben
Really need to get a zif socket on that motherboard. That ROM chip has gone in and out far too many times! Love the content!
I understand nothing but i can watch these all day, so cool
Well done, Sir. Great video.
Awesome video! Wish I completely understood everything. It’s good to see that you’re still adding to the 6502 computer. Happy new year!
2:30 I believe (but correct me if I'm wrong) that the original 6502 only lacked the ROR instruction. Not sure why you'd be having issues with DEC.
(I know your comment is getting a little old, bust I wanned to give a some info)
The 6502 didn't have suport for the instructions DEC and INC to work on the A register, that feature was added in the 65c02 version of the cpu.
the original could only decroment and incroment a number in ram by one using DEC and INC, even though there's a variant of them for the X and Y registers being DEX, INX and DEY, INY respectively
Sometimes I barely understand why and what are you doing something but still I love it! :)
He should hire someone to design a case for thia thing once its done and make it look like an actual tower PC (And maybe program a basic OS for it at well :D )
Awesome video Ben! Thank you very much ❤
Ben eater is like the 8bit Guy but way more advanced, like a PhD vs a bachelor degree
Currently waiting for few parts to arrive and will build this
Nice summary of working with the cc65 compiler tools. Now, I'm just waiting for Ben to have it print "Hellorld!". :)
Great work Ben! Looking forward to the next one.