The Game Boy, a hardware autopsy - Part 1: the CPU [PART 2 OUT NOW!]

Note: I made a few mistakes in this video which are addressed in part 1.5. Please make sure to watch it here: • The Game Boy, a hardwa...
Have you ever wondered how the Game Boy works? How the games that defined the history of the handheld world were made?
This video series hopes to answer these questions and more concerning one of the most successful gaming platforms ever.
Narration aided and recorded by the lovely Sarah - smstang.com/
Roller Coaster Tycoon Gameplay - tgnGamesDE - / channel
Sonic TAS - Played by sgrunt
Game Boy pictures - commons.wikimedia.org/wiki/Us...
Productivity icon by Gregor Črešnar
Game Boy vector art - cryoganix.deviantart.com

[@אולדסקול]

Wanted to say THANKS for making a serious video and not being afraid of delving into technical stuff. KZbin needs more intelligent content like this. Keep it up :)

[@thesuperenderdragon]

Agreed

[@zozohasme]

+‫אולדסקול‬‎ I also agree even though I struggled to understand some parts of the video. But I would rather be forced to think harder than to have it dumbed down for me.

[@thesuperenderdragon]

Yeah

[@אולדסקול]

I understood everything, well I took some courses about these topics in the past. I think they did a really good job explaining it simply. If you watch a couple of times you'll understand completely, I'm sure.

[@ganzka69]

+‫אולדסקול‬‎ I agree too, but I don't understand English very well (I am Mexican), Maybe This videos help me to understand better. Whatever, that is intersting

[@mothersbasement]

you just earned an instant subscription man. Slick video, highly educational. Love every minute of it.

[@Alex-rl2mk]

+respect

[@RedLogicYT]

Cringe basement

[@reversal]

This makes me respect the developers of Pokémon and The Legend of Zelda: Link's Awakening so freaking much! Others as well of course but these two are huge ass games.

[@pat3658]

+kittenchilly yeah right, but how does that even work. i mean assembly is different for every architecture. how can it run on different pc's?

[@goka2000]

+kittenchilly It's not just about the size of the games. Pokemon and Zelda had the Game Boy's much weaker hardware to work with, compared to your average PC running Rollercoaster Tycoon, and that's what makes them so impressive.

[@acme64]

+kittenchilly without the restriction of a gb cpu.

[@acme64]

+Rick Pat tycoon only ran on x86

[@pat3658]

acme64 ah, thats fair. thanks for the answer!

[@Gamerguy8585]

i love learning things about older tech and it makes me happier when it is a gameboy

[@OwenMorganTelltale]

I think this is a fantastic explanation. although, to add more info to it, the reason why the gameboy couldn't use a compiled language like C is because it has a function stack and the gameboy wasn't powerful enough to handle a function stack like that. C++ has a CLASS stack, and there's absolutely no hope of managing that on a gameboy. higher level languages like C, C++, etc have a lot of overhead and its just not something the gameboy was capable of handling

[@DigitalViscosity]

@@thebearslicer7736 It can be but I wrote two examples of the same program in both, the C version uses much more memory and runs much slower than my assembly version. Code generation can only do so much. The stack and heap created by creating pointers and structs is a lot less efficient than just doing it in z80dmg assembly.

[@jefflinahan5853]

What is meant by a class stack?

[@DigitalViscosity]

@@jefflinahan5853 There isn't a class stack lol he's just a moron. He means Heap memory, he doesn't realize that he's talking about reference types.

[@hectorescolar1]

I'm learning assembly code now in 2nd year of Informatic Engineering, but in this video the explanation is very clear, I liked it.

[@CoolDudeClem]

This video taught me more about Z80 machine code than I ever learned from any book back in the day!

[@pikadroo]

if their were 1000 more videos like this on this channel I would consume them all right now and not stop until I was done. Looking forward to more... which I guess means I have to subscribe. Thanks! =D

[@batlin]

10:30 The example is demonstrating dynamic typing (types determined at runtime, not compile-time like with static typing), while the narrator describes type inference (which doesn't require dynamic typing -- Haskell is statically typed but uses type inference to save you from having to specify types, mostly). Neither of these is the same as "weak typing", which involves implicit type coercion and often causes weird results. In fact the example of a type error being thrown by a Python program is actually *strict* typing. Assembly language is by definition weakly typed, since it has pretty much no type system at all!

[@damagednoob9102]

+1

[@thepld]

Bingo! Thanks for posting this, since that's a pretty glaring error in the video.

[@pdr.]

There are quite a few small errors like this, but overall it's still a fantastic video!

[@GimR]

This is amazing!

[@FALCONLICK]

+GimR wasn't the 20xx mod done in assembly?

[@Stormy2142]

This is beyond amazing. I've been doing some reading on old game systems and CPUs, but I lacked the technical knowledge to really get it. This video gave me exactly the kind of information I wanted! Thanks a lot!

[@mistaecco]

Wow! This was way cooler than I expected. A lot of things I already knew, but I really appreciated the comprehensive breakdowns of such complicated subjects. I'm really looking forward to the rest of this series!

[@MrBenMcLean]

This is the best video explanation of assembly programming I've ever seen. Anyone who is feeling up to the challenge portrayed in this video should get themselves a copy of TIS-100 on Steam. It gives you challenges in assembly programming to complete.

[@DevanTheMan]

+Benjamin McLean totally just bought it and am excited to see how horrible I am with assembly language !

[@MrBenMcLean]

Friend me on Steam! I'm BenMcLean. Then we can see each other's TIS-100 scores!

[@DevanTheMan]

Sounds good brother ! I will add yah up right now !

[@DevanTheMan]

Actually, having a rough go trying to find you on here, send me a PM with a link to your steam account and I will add you from there !

[@MrBenMcLean]

steam community dot com slash id slash benmclean its not hard

[@Marigio300X]

I like this. This was entertaining AND informative.

[@PaschaQ]

+Marigio300X I see what you did there, have my INC!

[@Marigio300X]

That was unintentional. That said, your response was goLD.

[@cheatmagnet]

Don't JMP to any conclusions just yet, there is still a follow up video!

[@eyeswideshut7354]

This was a good good informational segment. Can't wait to see more. I do appreciate detailed videos such as these.

[@watwattaw]

I really hope this video isn't just something like a test/demonstration and that it does continue on as a series. Good job, kept me interested through the entire video and looking forward to more!

[@chrissesock4245]

As a programming student, the comparison between Assembly and Python was insanely interesting. Really good video.

[@matthewcook7444]

This is one of the best videos I have seen on KZbin in a while. I cannot wait to see more of your work. Very clear explanations. Good visuals. Great job!

[@GetBant]

What an amazing looking video! It was a pleasure to watch, I loved all the extra work put in to get things like the circuit board without chips on. Thank you!

[@DragonDePlatino]

Amazing video. I expected some basic lectures on Gunpei Yokoi like other GB videos, but this really went into the nitty-gritty of its programming and taught me a lot.

[@CarfDarko]

Very nice and informative video, really like the pacing and the way things are explained! Keep up the awesome work, can't wait to see more.

[@edgarazaky8256]

Assembly: the Dark Souls of programming languages

[@egemenozan5641]

Try making a dark souls demake using Assembly

[@JustinKoenigSilica]

I hate you

[@honeybadger256]

Try whitespace or brainfuck langs

[@user-iu8ps1yo1w]

@@egemenozan5641 you wanna make me commit crime.

[@Violent_Ed_1317]

​@@egemenozan5641 and a guitar hero as a keyboard while coding it.

[@xxandiee]

Fantastic video Jacktech, never heard of these before, but thanks for breaking down such a complicated thing like the gameboy and explaining it so incredibly well, subscribed and looking forward to the next episode!

[@stachowi]

This is a great video about understanding how computers work in general. Wasn't expecting this level of detail. Great video!

[@peterlandry]

C# targets the CIL, not assembly. It's possible, based on the language spec, but afaik isn't used like this anywhere.

[@jasonkeene]

Python is not weakly typed, it's dynamically typed. en.wikipedia.org/wiki/Strong_and_weak_typing en.wikipedia.org/wiki/Type_system#Type_checking

[@j.thorgard]

The level of detail is more than my needs but I appreciate the huge amount of work you've done to create this. Great job.

[@thedancerofflames]

I've been studying computers and messing with programming for a few years now, i love this series, and i hope that you continue to produce content like this. I cant wait until the next episode.

[@fnvtyjkusg]

Neat video, but I think you might have mixed up the operators and operands. For example, with Add A 27, Add would be the operator and then A and 27 would be its operands

[@jacktech5101]

+Ben Chand You're right, I got them mixed up. My bad!

[@fnvtyjkusg]

+Classic Xavier nerrrrrd!

[@firestare100]

+Classic Xavier Sad that you didn't know that? Don't worry there is a lot more you don't know.

[@Kyleology]

+Ben Chand Nerd.

[@4ndr3w1431]

Y'all are nerds.

[@martin128]

I love that you showed Assembly versus python. Really nice.

[@returningwhisper]

Fantastic piece of work done here. Looking forward to the next video!

[@JohnPortfolio2010]

Holy cow this was a really good video. I've been programming now about 7 years and never could figure out how to write in assembly and this completely makes everything clear. Can't wait until part 2!

[@sems1193]

What an incredibly interesting video. Please keep them coming, and if you can, expand to other devices! You've gained a subscriber. Also, Phil sent me.

[@MyHelmetHazStickers]

Very informative, loved it!

[@dirkdirk1130]

This is brilliant to see such technical content presented so nicely, please keep making videos!

[@ayushagarwal8720]

Great Video. The Graphics and Narration are an Amazing Combination. Explanation is very good. Keep Making more of these!

[@birgirpall]

Loved this video! The high production value seems to accentuate the lack of background music though.

[@randomizer9948]

lol

[@sirmoco]

+BirgirPall I just noticed the video had no background music after reading your comment.

[@Quot_]

+BirgirPall "We Broke: Background Music"

[@TysonSPS]

+BirgirPall That voice was music to my ears.

[@cgrecommended]

Needs more dubstep interlude?

[@DannyE33]

A few people have already pointed out that it is a bad idea to jump to $8000, because this is the start of video RAM. The only way that jumping to a RAM address >= $8000 would be reliable is if a function in ROM copied a function into RAM at an address >= $8000. This is actually done in real games. There is usually a function in ROM that copies a function into HRAM. This is for OAM-DMA transfers, because no other memory (even ROM) is accessible during an OAM-DMA transfer. However, storing variables (`score` and `life`) at addresses $8000 and $8001 is also a bad idea, and not only simply because that is meant to contain video data. Sure, the first tile in VRAM would be "garbage" thanks to storing misc data variables there, but more importantly, you are only allowed to write to VRAM during a v-blank interrupt, or when the LCD has been turned off. Turning off the screen seems like a most odd requirement for updating variables. Also, I would just like to point out that the python and assembly examples are not identical. In the python example, `life` is incremented if `score` is strictly greater than 100. In the assembly example, `life` is incremented if `SUB 100` does not result in a carry. If register a is 99, `SUB 100` results in a carry, thus life is NOT incremented. If register a is 100, `SUB 100` does NOT result in a carry (however, the z flag is now set), thus `life` IS incremented. If register a is 101, `SUB 100` still does not result in a carry, thus `life` is incremented, and so on. So in the assembly example, `life` is incremented if `score` is greater than OR equal to 100. If they took the time explain the c flag in the narration, it is likely that this mistake would have been noticed while it was under the microscope. Still a great video! I'm glad Gameboy assembly is getting a bit more attention!

[@jacktech5101]

+Danny-E 33 Thank you so much for taking the time to write all of this down. I actually address these facts in episode 1.5! (except for address $8000, that's just a number I used as an example, and I'm sure by the time I'll be explaining memory mapping nobody will even remember that I used an address in VRAM as an example :P)

[@reishiramzi]

awesome video, checking out old tech makes understanding silicon much easier. Thanks for the video cant wait for part 2!

[@timanderson4348]

Quality. Keep making more. The assembly part and hardware break down was awesome.

[@jacknetarchive]

Now this is my type of video.

[@reddcube]

The horrors of assembly programing. STOP REMINDING ME.

[@halfcraft]

+B. Winky your probably 12

[@intereality]

+halfcraft His 12 what?

[@JwopDk]

+B. Winky I find assembly more relaxing than anything. It feels like you're physically moving all the numbers around yourself, instead of typing out your ideas and having them translated into code. Having said that, I can imagine if you're expected to write something like Rollercoaster Tycoon in pure assembler, especially if you've been given a deadline, it could be quite stressful. I will admit, debugging assembler is a bit annoying, but for some reason actually writing it all down makes me feel at peace. I dunno, maybe I'm just a weirdo.

[@k_xx]

+Based King Potato Debugging assembly is pretty cool in my opinion, at least you get to see the result of each instruction (which can sometimes be quite elusive if you're dealing with optimized code).

[@reddcube]

+kxx I agree optimizing the code is cool, for example using all the registers to eliminate the need to read/write to the slower working RAM. But with modern compilers and computers you are wasting your time. It's still cool to learn though.

[@Matheus-mf9nz]

I love this. Please make a playlist of this series!!!

[@Phrixos]

That was such an insightful video. Thankyou for putting the time in to make this!!

[@witeshade]

I like everything about the video except the distorted vocals. I'm not talking about the "fry", that's whatever and, I'm talking about the hiss/fuzz/muffling that is riding on top of everything she says. It almost sounds like she's recording next to a snare drum with the springs loose and vibrating along with her voice, or she recorded it in a noisy room and is using very heavy noise gating to cut the background noise, or maybe there's a multiband audio compressor on the audio track which is boosting the heck out of a frequency range it really shouldn't be. Considering how clean and polished everything else is, it's really weird how rough the vocal track sounds. I hope for part two they'll fix the levels or something and keep it crisp.

[@jacktech5101]

+Daniel G Yeah, I still have to invest in a proper mic. I tried my best to gate the noise and do some FFT magic to get rid of the rest, but I agree that the result is definitely suboptimal. We'll definitely improve for the next video!

[@Bill-Sama-Gates-Laden]

Can you explain what the Rollercoaster Tycoon royalties have to do with it being coded in pure assembly?

[@intereality]

+szivalj My assumption is that Chris Sawyer didn't have to pay royalties on third party libraries. I'm not a developer so take that with a grain of salt. Also, if Transport Tycoon is any indication RCT relied heavily on tweaking already developed code.

[@liamness]

+intereality Writing it in C (for instance) wouldn't mean he would necessarily need to use proprietary libraries though. He got huge royalties because 1. he made the entire game himself and 2. it was incredibly successful.

[@intereality]

+Liam Duffy I hadn't realized he didn't have a team of developers behind him. That's fucking impressive!

[@mattletissier9167]

+Liam Duffy Indeed. It's not like the only alternative to assembly was licensing the Quake engine. Sawyer was a computer scientist and a veteran of the 80s, so he was probably just more comfortable with assembly than the alternatives. Old (programming) habits die hard.

[@dpape39]

+szivalj Might also be that it didn't require a beefy computer because it was coded in assembly, making it accessible to a broader audience.

[@Dritch7]

Thanks a lot for doing this! This is just the kind of content we need to see more often in KZbin, something that actually informs you instead of mediocre game reactions.

[@TheStevenWhiting]

Get ready for the channel to go big. These videos are quite good and you explain Assembly really well. I could never get my head round it in college. Never knew the right most value went into the left value :)

[@AssemblyBanditChannel]

There's an error with the assembly code. It's equivalent to 'if score >= 100:' This is smaller and faster: xor a ld ($8000),a ... ld hl,$8000 inc (hl) ld a,100 cp (hl) ret nc xor a ld (hl),a inc hl inc (hl)

[@Nyocurio]

+AssemblyBandit Yeah, I just did the 2's compl substraction on paper and noticed that carry will be set even for 100 - 100.

[@zimanimation]

Hi, did you create the opening music? Can you please contact me.

[@jacktech5101]

+Zim Animation I did! I also make music as a hobby. You can check out my SoundCloud profile here: soundcloud.com/iamjackg

[@zimanimation]

Do you have an email I can contact you at? Can you pm it to me. Thx.

[@Erpatr3]

+JackTech inb4 you're sued for some remote resemblance to something they did or had in plans of doing.

[@zimanimation]

lol. you guys on KZbin are funny. I contacted jacktech to see if he'd be interested in helping me with his music skills.

[@Erpatr3]

Zim Animation And I made a joke, I suppose if you thought it was funny, it worked!

[@Alklaine]

Wow, this is impressive! Learning assembly is a challenging endeavor, but incredibly rewarding. I like this kind of stuff!

[@madferret96]

Loved your video! Thank you for the effort put on it. Can't wait for the next..

[@AnTi90d]

Some guy posted a link to this video on Voat.co and now I'm subscribed.

[@wildgoosespeeder]

99% of RCT1's code is assembly. The 1% was C (step below C++) to interface with Microsoft Windows API.

[@JwopDk]

+wildgoosespeeder Step below? I think you mean step before ;)

[@genhen]

+Based King Potato 'lower' languages that are below others are closer to machine code. Like assembly or byte-code. C is the one of the closest-to-machine-code languages out where, and it has less abstractions as C++. Just because C++ came out after C, does not mean it is above/below (close to 1's and 0's or further). The date of release of a language typically has nothing to do with how close to machine code it is

[@JwopDk]

+Henry Wl I'm not sure if you're replying to me or wildgoosespeeder, but regardless C++ is equally as low-level as C, it just has more features.

[@vickilacroix6410]

+Based King Potato Equally low level and more features are mutually exclusive. You cannot be equally low level *and* have more features.

[@JwopDk]

+Euler hopepunk As explained in the video, languages such as C and C++ are compiled in machine byte code. It doesn't really matter what kinds of features the language has, since they most C++ features are effectively shortcuts that C doesn't have. In the end, it's translated into machine code one way or another. If you take two similar programs - one written in C and the other in C++ - the generated code in both programs will look and behave fairly similarly, depending on how they were compiled. *TL;DR* CPUs don't give a shit about language features, as long as these languages have machine code compilers.

[@greghenderson1899]

Really enjoyed the video, expected it to be a higher level breakdown of the hardware but really enjoyed the assembly/python coding break downs as well. Cant wait to see the next episode!

[@3DSage]

wow it is so impressive that you put so much good information in such an easy to learn way. Thank you for making this video! :)

[@gabrieleriva651]

You forgot to turn on the red led near the screen of the Gameboy ;)

[@d00mch1ld]

Programmer back in those days were amazing.

[@theantithesis1]

This is a very good video. it explains the technical details in a manner that is understandable that by the end, I felt like I could program a Game Boy (ha!) I was so impressed, i checked the channel to see what other videos you had and was heartbroken to find there weren't any, save for 1.5 and the other language versions. I hope you continue making these videos because this was enjoyable and informative.

[@soviut]

Really fascinating stuff and one of the simplest explanations of assembly I've ever seen. I'd love to see more about the audio system as well as the networking capabilities with the link cable.

[@BlazeFireXERO]

Well this is a damn bit of fresh air in the KZbin world. A female programmer who knows her stuff talking about programming on KZbin. WE NEED MORE CONTENT LIKE THIS.

[@2xsaiko]

this

[@KuraIthys]

Judging by the description of the video she merely narrated it. That doesn't mean she doesn't in fact know how to do this stuff, but unfortunately it doesn't mean she does either. (as long as you pay attention, reading technical stuff from a script isn't exactly impossible). Still an interesting video though.

[@mcspankyweinerjohnson1974]

+Blaze Fire More than likely she's just a voice actress hired for an English translation.

[@BlazeFireXERO]

Yeah, I figure that much. But it's still good, whoever wrote it anyways.

[@GoldenJoe]

+Blaze Fire That is a narrator lol.

[@jarrad2000]

This is not called weak typing, it's called dynamic typing. With weak typing the error would not have been detected and something else would have happend, like incrementing the memory position of the first letter.

[@jacktech5101]

+jarrad2000 You're correct. There is still some confusion about the terms (particularly between different languages) of which I was clearly a victim. Thanks for pointing it out!

[@jarrad2000]

+JackTech You're welcome. It's a great video nevertheless, and I like especially the assembly part a lot.

[@chaoticoscar]

Awesome vid. The whole technical stuff was unexpected and I think I learned something totally new. Thanks and keep up the good work.

[@Pichuscute]

Wow, this goes much deeper than I thought it would. It's awesome to see a breakdown of how the coding worked on Gameboy. Great work guys!

[@acme64]

you lost me at roller coaster tycoon? how does writing in ASM vs C amount to a 30mil check?

[@jacktech5101]

+acme64 The game was programmed single-handedly by Chris in Assembly, a feat so incredible for the time that it made the execs decide to reward him for his efforts. It was basically a bonus for being awesome.

[@chadc437]

+acme64 If programmed with C the required PC specs would have been higher limiting his customer base. Programming in assembly allowed the game to be run on less powerful devices which meant more customers which meant bigger royalty checks.

[@olafurbjarki]

@2:37 This makes no sense. First off bits don't "hold numbers", they are simply one way of encoding them.. Secondly a memory address space defines a range of addresses, some which correspond to memory cells, other to network hosts etc. A 16-bit address space has a range of addresses between 0 to 2^16-1 while 8-bit one has a range of numbers from 0 to 2^8-1. You also say that each cell in the memory address can contain a number between 0 and 2^8 (256) while you refer to 2^8 as 255 throughout the video. Great presentation and production but these mistakes are unnecessary and will make it harder for newcomers to understand the concepts.

[@jacktech5101]

+olafurbjarki Which is why I made a follow-up correction video :) Memory mapping will be the topic of another video, so talking about the specifics of the memory layout would have been a bit premature. Thanks for your feedback!

[@AllMyAlliesAreDead]

Subscribing immediately, thanks for your and everyone else's work done on the video. I like the education style of focusing on the principles of instruction architecture, which you can then applicate on analyzing other hardware than the original Gameboy one. Looking forward to your future contributions to this series and hopefully,others.

[@casvanmarcel]

This is so good! Please continue this series! Best regards

[@victoragudelo1085]

llegue antes de los "like si estas aquí por Alex" si llegue antes u.u... que puta maravilla

[@MaximilianoChirino]

+Victor Agudelo Pues no hay nadie que diga lo de "like si estás aquí por Alex", como se nota la diferencia entre su público y los demás youtubers :)

[@cormano64]

u.u

[@azai.mp4]

Hey. I'm curious how this channel exploded all of a sudden. I have my theory that it was mentioned by a popular youtuber and then picked up by youtube's algorithms but that's only a hypothesis. So here's a strawpoll to test it: strawpoll.me/6954772

[@jacktech5101]

I actually shared it on reddit and people really liked it. That's what gave it its initial boost :)

[@Amstroid]

+JackTech You also got linked by Nerd³ at the end of his video (under the RANDOM button) here: kzbin.info/www/bejne/hWiZkphtotVlg9E

[@azai.mp4]

JackTech Ah, of course, the power of Reddit. (With a little help of it actually being interesting content too.)

[@azai.mp4]

JackTech Though, if you look at the poll results, you see something slightly different. strawpoll.me/6954772/r I'm guessing that after you shared it on Reddit, which I'm guessing is where the "Some external website." group comes from, it got picked up by popular channels and youtube's algorithms. That looks a lot like my original hypothesis, though, so I'm not sure whether I'm undergoing some kind of confirmation bias. In any case, the poll results aren't the best data. Only people checking the comments after the point in time where I posted mine, have a chance of seeing the poll. This means an original influx of Redditers could be missing, because they saw the video so early. Furthermore, it's a small sample size, yada, yada, yada. But at least I feel I have a general idea of what happened now.

[@jacktech5101]

+Azai According to the analytics, 64% of the views originate from external websites, of which 31% are from reddit. KZbin's home page/subscription system and suggested videos make up for the following 24% of the total views!

[@funposting8912]

This video’s not only a great look at how the gameboy works, but also a wonderful and concise way of explaining assembly to people. Too many times I hear people say “programming languages are like stuff you can read and it gets converted into ONES AND ZEROS for the processor!”, leaving it at that, and not teaching anyone anything. As someone who has programmed 6502 machine code, both in assembly and binary toggled into a minicomputer with switches, I appreciate the acknowledgement of how these systems realistically work, and that ASM and even hex aren’t completely beyond human comprehension. I’ll be using this video from now on, as a quick reference for people curious about assembly, and for any time I hear someone talking about machine code just being ones and zeros.

[@beanjeangreen]

I just looked up "Nintendo Gameboy Analysis" and came across this high quality video. Very impressive work! I'll be checking out more of your stuff :)

[@PropaneCoke]

There is an error in your video, computers do not understand assembly. The computer can only understand binary. Assembly can be converted to binary through a linker.

[@jacktech5101]

+MusicalLifeGamer Of course, but I felt like that was a bit too detailed for a cursory video about assembly, and assembly is close enough to binary machine code that the parallel still stands.

[@genkiadrian]

+MusicalLifeGamer Actually, that's wrong, too. Machine code is translated from assembly language by the "Assembler". A "Linker" links object files, that is already compiled binary code, together and eventually creates the final executable or library. Hence the name. An alternative method of getting assembly code into the computer is a monitor program.

[@lmactanssc2]

genkiadrian I thought it's some dark magic... Kappa

[@robertcarlson8867]

+JackTech I find that's usually the best way to explain assembly to someone who doesn't know a thing about it yet. Over-precision in correctness can actually lead to misunderstanding depending on your audience. Excellent video!

[@אולדסקול]

+MusicalLifeGamer Correct me if I'm wrong, but Instruction codes are basically numeral representations of the assembly codes and parameters.

[@ericedmond9751]

This video gives an incorrect definition of Weak Typing. A weakly typed programming language would not complain about an operation between two different types. Python is in fact strongly, dynamically typed. Otherwise, fantastic video

[@jasondoe2596]

Well-said.

[@vuurniacsquarewave5091]

+Eric Edmond So... what would come out at the end if you added numbers to a text string?

[@midrangemonroe1]

+za909returns A strongly typed language (like Python) would report an error saying incompatible types. A weakly typed language (like Javascript) would implicitly convert the two variables to the same type, potentially producing very strange output. You might see "hello" + 1 = "hello1", but you might also see "hello" + 1 = 1496.

[@jasondoe2596]

To be fair, though, when one says "strong typing" most people tend to think of strong *static* typing, for pretty good reasons. So there's often this misconception, that dynamic typing is "weak". Personally I'd call Python a language with "medium strength typing". I'm half-kidding :P

[@ltjbr]

+Jason “cyberspace entity” Doe And those people would be would be incorrect. dynamic/static & weak/strong typing are separate things.

[@TheGrooseIsLoose]

I clicked on this expecting someone sitting at a desk with a gameboy, waving their hands around as they spoke like some sort of unboxing video, opening up the gameboy and just looking at all the parts and briefly mentioning what each thing was in passing. This was so much better and very well made!

[@LeandroR99]

Interesting. And nicely done! Smooth 60fps transitions, nice animations and narration too.

[@GoldenJoe]

Alright, I have to say it. Video makers around the world, please please PLEASE cut the A.D.D. visualization crap. We don't need a picture of a hand every time you say "hand". Fucking ridiculous, it really drags what is otherwise a great video down by bookending it with nonsense. That said, very nice programming lesson. I imagine even a beginner can kinda sorta follow along if they pause the video, and the visual cues for that portion are excellent. Wasn't much in the video about hardware, though. Maybe you should have named it Part 1: introduction to CPU logic.

[@jacktech5101]

+GoldenJoe Hahaha, I'm pretty sure that the hand only appears one time, and it was clearly intended as a visual pun ;)

[@GoldenJoe]

JackTech That was just one example. The video is riddled with it. I nearly turned it off in the first minute. It's too bad, because the programming bit is very well explained, and I can see how some people might never get to it.

[@GoldenJoe]

***** You should be concerned that reasonable criticism that isn't even directed at you bothers you this much.

[@scottwanthony]

+GoldenJoe And here you come, criticizing his criticism. CRITCEPTION

[@GoldenJoe]

Scott Anthony Please, there was already enough A.D.D. in the video.

[@Neceros]

Woman speaking: vocal fry is not sexy. Please don't. After watching it though, I liked the video.

[@_blawnk]

+Neceros Looking through your videos, it's not surprising to see that you're a very avid vocal fry-er yourself, heh. Nothing wrong with vocal fry at all, but it's a bit strange of you to criticize somebody on a vocal feature you yourself exhibit.

[@Neceros]

shawnbeonkey I don't make videos anymore. Can't change things from a while ago. Peace

[@_blawnk]

+Neceros Peace to you as well. The peace to not judge others for an arbitrary linguistic feature that has been in use for millennia (and one that I'd wager my life on you still exhibiting to this day...shaking vocal fry in a few years is as likely as suddenly adopting a brand new accent as an adult. Not happening.).

[@Neceros]

shawnbeonkey Well actually it does damage your vocal abilities to 'fry' for too long. And I do fix my fry, as everyone should. Strive to be better.

[@_blawnk]

Neceros Vocal fry damages nothing. Do you know anything about the physiology of linguistics? I'm a linguist myself, and I hope this open letter from a fellow linguist is enlightening to you: dl.dropboxusercontent.com/u/13239702/FreshAirResponse.pdf

[@dshw]

This is one great entry into the multi part series about the Game Boy. Seriously. I found it very informative, easy to follow, but not shallow and absolutely not boring. And that you did a correction video just shows how dedicated you are. Hat's off! I also don't agree with the harsh critic on Sarah's voice ;) All in all I can't wait for the second part. You deserve every view and a lot more on top of them :)

[@avenyet7478]

Stunning video explained the CPU and how to use it really well. The video itself is better than some uni programming lectures I have been forced to sit through.

[@Mr_Wallet]

0:00 - 1:30 summary of the game boy. Longer than necessary, but forgivable. 1:30 - 4:10 (generously) The content actually promised by the video title, "hardware autopsy" 4:10 - 11:00 The video goes completely off the rails and starts talking about assembly language, slowly drifting farther and farther from any mention of the Game Boy specifically 11:00 - 11:35 The video is now about Roller Coaster Tycoon and how that relates to assembly language. We have abandoned the topic in the video title and introduction completely at this point. 11:35 : "To sum up this first round of information: Game Boy; CPU; cartridge; RAM." Is this video a satire of some kind?

[@jacktech5101]

+Mr. Wallet It's part 1 of a series that will eventually go into all the details of the inner workings of the Game Boy (while still keeping it on a level that won't bore people out of their mind), and a crash course in assembly is absolutely fundamental to be able to understand the next parts, so I decided to explain it in the video. I hope you'll find the next episodes more interesting!

[@slicex3408]

+Mr. Wallet Don't try to look smart. Doesn't suit you.

[@ssvenno]

+Mr. Wallet Unnecessarily harsh with minor points and overly-analytical. This isn't Metacritic.

[@Boxcow45]

+Mr. Wallet You get what's on the tin

[@RyanSmithPhoto]

+Mr. Wallet This video was awesome, I loved that it got into assembler, I don't know what your problem is.

[@yumri4]

you made a coding mistake on JP C, AFTER as you did not set anything into C so C = 0 you also did not declare anything for RAM location 8000H which is another mistake as Hex only goes up to F not then restarts at 0 little mistakes like this will cause 2 errors that i can se outright with assume the part of " ... " is written correctly based on how a 16-bit ARM processor works anyways error 1 syntax error in LD A, (8000H) as H does not exist as a number nor a command as it is assumed to be hex error 2 you need to load a value into C before using the JP command error 3 you are assuming 16-bit addressing from a 8-bit CPU which you shouldn't do unless you said to do a bit shift to 16-bit first error 4 is in you also have 8-bit numbers not 16-bit numbers so 255 is the max you can use i do however agree with you that assembly is hard and probably wont be used in any modern game anymore as long as we have standardized x86 32-bit processors anyways cell processors in the PS3 worked much better than a x86 processor would have but cell processors are not mainstream and harder to program for as they needed to use assembly and not alot of people new how to with the large book of commands in how to use assembly for a cell processor very good video many coding mistakes if you read to far into it but the main points were hit in it

[@jacktech5101]

+yumri4 I'm sorry, but you're actually wrong about all the points you make: 1) the postfix H is an alternative syntax to indicate that a number is in base 16, another way is to put $ before the address 2) in a jump instruction C is the carry flag, not a register 3) I said in the video that the GB's cpu is an 8-bit CPU with a 16-bit address space 4) where do you see numbers greater than 255?

[@yumri4]

JackTech 1 yes i know so it was sudo code i assume then 2 as "C" was a register in her video thus why i assumed C would be a location used 3 i do not understand it enough to answer as they some how made a 8-bit CPU work with 16-bit RAM in most likely the same concept as a x86 instruction x86_64 for a 32-bit CPU to understand 64-bit instructions this however is not listed on the ARM instruction manual as it only lists how to go down not how to go up but ARM is not Nintendo 4 you can increment to a number higher than 255 so without a stop loop condition it will make an infinite loop

[@2thinkcritically]

+yumri4 I'll apologise in advance on this one. My response seems exceedingly large and yet I've barely scratched the surface on this one. Suffice it to say that programming in assembly language is quite different from programming in a high level language like C or Python. However it's pretty straight forward to read and write once you understand how it works. 1) It's not pseudo code, but rather monikers for the machine code instructions the CPU uses. Different CPU manufacturers use different ways of denoting hexadecimal numbers. Zilog and Intel use a *h* suffix, Motorola traditionally used a *$* prefix. The prefix/suffix is used by the assembler to identify whether a number is in decimal or hexadecimal (or octal or binary in some cases). The assembler produces machine code that the CPU can then run. Machine code is traditionally rendered as hexadecimal numbers although that's purely for our reading comprehension. A more accurate representation would use binary. 2/3) The accumulator is an 8 bit register so it only handles numbers from 0-255 that's true. However every operation that makes changes to the accumulator value as well as the CMP (compare) instruction alters the Status Flag register. In this case SUBtracting 100 will cause the carry flag to be set if the result is less than 0. So if score - 100 < 0 then the code sets the PC (program counter) to a point in memory AFTER the section that sets score to 0 and increments lives. Note that the SUBtraction was done after the updated score was stored back in memory so it doesn't actually affect the score. The carry flag is how you work with 16 bit numbers using an 8 bit accumulator. Think of the carry flag as the unofficial most-significant-bit of the accumulator. If it's set, then you know you need to increment the most-significant-byte by 1. If you're adding two 16 bit numbers together, add the two least-significant-bytes together and add the carry (if set) to the most-significant byte of one of those two values you're adding (or add it at the end). Then add the two most-significant-bytes together. If the result of that operation also sets the carry flag then the answer is greater than 65535. *It should also be noted that the Z80 can pair registers together to make them into pseudo 16 bit registers: BC, DE and HL. HL is the 16 bit equivalent of the Accumulator.* Thus you could do the following to add two 16 bit numbers together: LD HL,1234H LD BC,5678H ADD HL,BC At the end of this, HL would have the value 68AC The PC program counter is 16 bit. This is the register that stores the memory location the processor will access next, either to load the next instruction or the value that goes with it. That's how an 8 bit CPU like the Z80 can access 65536 bytes of RAM. You seem a little confused regarding x86 and x86_64. 32 bit x86 processors cannot be made to understand 64 bit processor instructions. The x86_64 instruction set essentially extends the 32 bit instruction set, allowing 64 bit CPUs to run 32 bit code. The 16 bit 8086 was based in part on the 8 bit 8080, the 80186 and 80286 on the 8086, the 32 bit 80386 on the 80286. The 80486, Pentium and so on were extensions to the 80386 instruction set and x86_64 is built on top of those. Incidentally, the Zilog Z80 was a close copy of the Intel 8080. 4) To stop an infinite loop situation you just: INC A JP Z, breakout (or you could use JP C in this situation as well) If A has the value 255 and you increment it then A will be set to 0, and the Zero flag and the Carry flags will be set. If you wanted a loop to run from 0 to 99 then you'd use the CMP instruction like so: LD A, 0 loopstart: ... do stuff ... INC A CMP 100 JP NZ, loopstart ... stuff to do after the loop has finished ... Hopefully that's made things a little clearer for you :)

[@yumri4]

it did and i think you got what i said about a x86 processor and 64-bit instructions wrong but ok as it seems this is a topic for a ASM forum and not youtube i will stop here as i am probably wrong and it will take you another long post to explain why so i will ask that on a x86 asm forum

[@KR4iD751]

This was an awesome hardware awareness video. Greatly appreciated. Really Can't wait for Part 2 :) Plus the commentator really soothes the learning :)

[@greob]

Wow this is a super high quality and very well produced video. I'm learning programming and always was curious about Assembly. I just had a nerdgasm! Thank you very much! Please continue being technical like that, because that's what we all want now! :D

[@Mmouse_]

Nicely put together video... I'll look forward to more

[@refarliang1773]

really nice videos, hoping to watch other parts as soon as possible ☺

[@jwbartle]

Fantastic video. Took me right back to my old Computer Architecture class. This would be great for educational purposes. Can't wait to see more from this channel.

[@Yoshi-zt5df]

+jwbartle I'm in a similar college class right now!

[@FlorisStoicaMarcu]

Great video! I loved it through and through, I can't wait for your next video!

[@silasmayes7954]

great video I've been trying to learn more about how CPUs work this was very helpful.

[@IngwiePhoenix]

Very accurate and nice video! Also that narrator voice is really friendly and nice - makes it very pleasant to listen to the video. Not to mention the very well done sound mastering =) Thumbs up!

[@s3bbe1337]

You have a great, clear voice! It makes the video really enjoyable to watch and easier to focus. Good video!

[@McLoganM]

I'm thrilled to see more! Very 'to the point' and simple to understand.

[@3DSage]

I really enjoyed this! I can't wait to see more of your videos in the future. :)

[@sglasgow99]

As someone who loves games, and computers, but only has a passing familiarity with how they work, this is SUCH a cool video. I only just realized that this is your first posting on this channel. I'm really looking forward to more of this. I've heard programmers talk about Assembly in passing but I've never researched how it works. This is so awesome and instructional. I hope you find it as inspiring to create as it is to learn watch and learn from!

[@Desmaad]

There were a couple of goods with the script: it says operator when it should say operand and weak typing when it should say dynamic. That said, very informative and well produced.

[@angelalordi1917]

Back in the 80's I built a 5Mhz Z80 system (wire-wrapped) and wrote a cross-assembler and linker for the Z80 which ran on a DEC VAX 780. In that assembly language, I wrote a real-time multi-processing kernel, and on that kernel wrote a digital music synthesizer. I built a keyboard interface and the digital wave generators. It worked great. I still have the hardware - cant throw it away even after all these years.

[@VideoAmericanStyle]

+Angela Lordi You should do a video! Seriously.

[@Adilson123xds]

Amazing video! This would even help me some months ago when learning assembly :) Nice and cool animations!

[@mjmac87]

Really enjoyed the video, looking forward to seeing the next!

[@danrenfroe2016]

really enjoyed your video! hope your channel takes off. very high quality content.

[@MageJohnClanner]

Bloody awesome. I can't wait for the next episode. Keep it up!