Its Jamie Davies will I ever be able to make a video game I mean in the same way this guy develops video games WATTgames mate? I really like to be a game programmer and game design and game developer WATTgames mate.
Learn how to program and then eventually you will be able to make video games with graphics libraries as OpenGL or with game engines as Unity or unreal Engine.
Its Jamie Davies I live in the UK can you tell me again please that there's more than billions people all over the world and more than millions people in Great Britain that love living on their own and love having their own independence and love having their own freedom and love having their own personal space too just the same as me please text me back yes Deffo that's true please cpp bear mate.
68000 machine code, brings back memories of 5am coding sessions on my beloved Amiga, bleary eyed with a half empty cup of coffee staring at devpac. Brilliant video!
@@mp-lv8bw Ah yes, so true. The only useful thing about DevPac was the fact it supported doing proper Workbench stuff better. Like the WaitPort() and DupHandle() you had to do for proper CLI/Icon start code. I must have used it initially, it's all just such a blur now.
I can't quite wrap my head around a lot of it, but it's super interesting that he's literally demonstrating how developers had to program Genesis games back in the early-90s, especially when you look back and consider some of the more mechanically and visually impressive titles on the system at the time. To me, it's very significant to the history of game development and industry history in general. Also helps that it's my all-time favorite console, hehe.
It's basically like any basic programming, just without any frameworks or complex APIs, it will literally only do exactly what you tell it. Have a look at Game Maker if you want to get a feel for this yourself, it's a much higher level programming language obviously, but you can build up a lot of the same kinds of logic as is used here to get a feel for it.
Yes Python gets complicated a lot faster. Not because Python is difficult, but you get faster to the difficult problems vs playing with registers all day to get basic "movement" :P
@@okie9025 .. "strict" (you meant static, or strongly typed but the contrast to strongly typed would be weakly typed) and "dynamic" refer to the typesystem your language uses. You're confusing it with "higher level" languages that don't reify memory management like Python, and to a slightly lesser extend Java/C#. There are languages with type systems that don't abstract memory management such as CPP. CPP has both static type checking and support for dynamic typing. Seriously, for the sake of your own growth, check up on basic terminology and principles before you get opinionated on anything.
indeed, you can also see why one should and must, admire that every single behavior in all programs are written by some considerate programmers I mean if the programmer didn't do the implementation, you can't even close a window by clicking the close button.
@@AsilarWindsailor No. # is referred to as Pound only in the US/Canada. in RoW it's hash and probably 1 other term I am unable to recollect at the moment.
@@reckz420 Interesting. I've never heard anyone refer to it as anything but pound until now. Does the # mean something in code? I cant remember now why he used it in this video as I hadn't watched since my previous comment
I think it's great when Matt does videos on the Megadrive Devkit/Assembly. It's brilliant how instead of simply vaguely explaining how Assembly works (which he may have done in another video (?) not sure), they're actually showing a snippet of what coding in assembly is actually like in essence.
why would you want to be "one" with a machine? I used to write / debug linux device drivers in C and asm. I never once felt "one" with the machine. Was just a job to me. Its basically a more complex version of programming a VCR. I find women MUCH more interesting than computers.
@@lordoftheflings We women also can relate to what Jeremiah said, you know? "why would you want to be "one" with a machine?" For you It's just a job but for others is some awesome interesting stuff that we want to learn for fun. It's just a matter of interests I guess.
And coding is tough NOW, but when you look at Assembly, you instantly realize how much easier we have it these days for sure lol. He truly is a wizard to keep retain this all. Also the ultimate flex in this all is he is showing the demo, with a large EXPO marker, on PAPER. Not even a white board or laminated paper. This guy is so damn casual in his confidence
Just excellent! I would really love to see more in this series. The real beauty of a system like this is when the complexity increases and you start to understand how all the different parts are working together.
This demo was really interesting. I like that 1 guy was 'doing' and the 'voice' was asking probing questions, so as to not assume the viewers were familiar with the jargon. Very cool and I'm gonna 'casually' retry my hand at ASM again like it's 1989.
All the videos on Numberphile(math), Objectivity(history), Sixty Symbols(Physics) , Periodic Videos(chemistry) and Deep Sky videos (Astronomy) are like that. The voice makes it easier for the host by sticking to simpler themes
I think the LD (load) mnemonic is much less confusing than MOV (move). You don’t _move_ values into registers as such; you _load_ registers _with_ values. Additionally, you can load registers with values of other registers or memory locations. Since the original values remain unchanged, the notion of _moving_ values is at best misleading. Keep up with the series! Make Assembly Great Again!
Ast A. Moore I suppose. Depends on the processor and it's instruction set though. If you were dealing with an snes or a commodore 64 you'd find what you're allowed to do with registers is quite restricted, and there is no generic instruction to move values from memory into a register, but rather a bunch of more restricted ones. Then again the majority of operations on these processors are register+ memory operations. For insantance, to add two numbers you load a value into the A register, then pass a memory location to the ADD instruction. (possibly using the x register to store a partial adress, though aince there are about 27 addressing modes there's lots of odd variations). the result of the ADD instruction has then overwritten the contents of the A register. Which you can store somewhere in memory.... I guesx that doesn't really say much about mov vs ld really. XD neither truly makes sense because the implication of mov is that the value is erased from the source. It's really a logic thing. load implies 'load a value from ...', move implies 'move a value to ...' Yet the reality of course is that you need both a source AND destination for such instructions to make any sense... as mnemonics, either of those only really truly makes sense if one of the two is implied. lda makes sense (load from the specified location to register a), mva would sort of seem like a store instruction rather than a load. But of course if you have a generic load, store or move instruction that specifies both source and destination it all amounts to the same thing, but with different emphasis. load (x)(from), store (x)(to), move (x)(to). move has the disadvantage of implying that the source is erased, which it pretty much never is, so in that sense, mov really doesn't work logically. but mnemonics are arbitrary anyway. two assemblers can use completely different mnemonics and if they produce the same binary instruction codes in the end it doesn't matter which you use.
Well, you are not wrong, and different architectures indeed work slightly differently. But consider these two CPUs: Z80 and 8080. The Z80 is 100% backward compatible with the 8080 (to the point of having identical opcodes). Nevertheless, conventionally, the Z80 uses the LD mnemonic, whereas the 8080 uses MOV (or variations of STORE). For example: MOV A,B vs LD A,B MVI A,byte vs LD A,byte LHLD word vs LD HL,(word) SHLD word vs LD (word),HL STAX B vs LD (BC),A These are identical instructions and after assembly, the resulting machine codes will be 100% compatible. Yet, Zilog decided to make the instruction set more uniform and straightforward (and, extended it quite a bit, naturally).
Writing code equally in Z80, 6502, 68000 and 8086 for multiple platforms just used to make my head hurt ;-) I learnt Z80 first (Zaks!) on my ZX81 but then came across the 6809 at university. Always preferred t e 6502, 6809, 68000 family over the Z80 and the horrible 64k banked 8088/8086. The key problem was that you could write a routine in 6502 and assuming your algorithm was sound, the first attempt was pretty much as fast it'll ever get. With the Z80, there were loads of tricks of which the main one was trying to keep everything in registers as compared to the 6502, accessing memory was real slow. So with Z80, you might re-write that all important "WriteSprite" routine on the Specky three or four times. The 68000 was a dream to work with. Loved it. Shame that Motorola didn't win the CPU wars. Intel's CPU line held the industry back quite a few years.
I also started on the Z80 (on the Speccy, though; skipped the ZX80 and ZX81). Then there was some 8086, then the PIC, then the 68k and the PowerPC (both on Macs). Loved the PowerPC architecture. I must admit that optimizing my Z80 code was, arguably, the most satisfying part. Sure, it wasn’t always straighforward, and I occasionally resorted to self-modifying code (which is a no-no on modern systems, because of security reasons), but that was the _exciting_ bit. Counting the bytes and T-states, shaving off a couple here and a couple there, working around the Spectrum’s quirky screen memory addressing, sprite flickering, etc., there’s was a great deal of thrill in it. I still write a little bit of Z80 code from time to time, just because I enjoy it so much.
Button inputs are just hardwired to the hardware in such a way that when you press a button, there's a register somewhere in the system that changes value accordingly. Then you can read that register value and do what ever you want with that in your program. The "input register" might not be located on the main processor itself but on a peripheral IO device that's behind a bus of some sorts (SPI, I2S) in which case you might need to write the routine to get the values from the pheripheral to the processor/RAM and then use them as you wish. But it's all the same, twiddle registers and use the values.
You're ignoring debounce requirements, and most inputs are not mapped to a register but have to be read in to a register. Perhaps the peripheral already debounces and you just need to read over the bus in to a register.
Assembly codes are superfast! C complier unnecessarily extends the length of the code, but by organising the registers so that none of them is wasted and placing of the instructions, we can get max out of the CPU performance. This basic programming reminded me of my graduation years when we used to do the programming in assembly and analyse the entire operation through machine cycles and its waveforms. Amazing to see how higher level languages and highly resourceful CPUs have abstracted the process and relieved user from this lengthy process.
Mayur Balwani I think it's worth noting that all popular and large C compilers have been designed for maximum performance of the resulting assembly (with proper settings of course) for years. This means that most programmers won't be able to create more efficient assembly code than those compilers.
gaby de wilde But there is something called maximum value of a function and optimisation techniques in the mathematics and also in real life. I have seen programmers optimizing their code to make the processor do what seems very difficult or even impossible to do with such least resources.
There's a digital guitar amplifier called a Kemper. You plug it into any other guitar amplifier and it copies its tone almost perfectly. Apparently all its algorithms are written directly in assembly code.
It is difficult to write assembly language on modern x86 processors (with speculative pipelines, etc) but those considerations don't apply to 68000. You can write code 50% to 300% faster in assembly language (I needed an interrupt driver for sampled sound on the ST, and so I used the USP as a temporary register that was used to keep track of the sample address, that saved 8 cycles, and since that code was executed 8000 times a second, it was 8% more efficient with just that one change). I wrote a 68000 to C converter for Sonic 3D and I had to work out whether the condition codes would be checked, in order to reduce the code size and get the code to run fast enough.
This was awesome! Would love to see more assembly themed videos. For example a video explaining how you write an assembler from binary, if that's how that works.
Slight nitpick: this video should be titled *Game Physics (in assembly)*. Assembly refers to the actual language being used, and an assembler is the program used to convert assembly language into machine code. Nonetheless, this is an excellent video as always!
Microprocessor Systems Design - Alan Clements. Great book on the 68k processor, for those who are interested, and would like to get into this. I picked it up for less than $10 shipped, amazing. Great addition to my library.
Loving these videos, Matt is awesome. :) To anyone who's goal is to learn 2d game mechanics, if your specific goal isn't learning assembler, then don't start with assembler. You would be much better off starting with something like Python and PyGame or even C#/Mono and Xna/MonoGame. One of the main reasons that programming languages exist is so that people don't have to use assembler and worry about things like assigning registers and dealing directly with buses.
@@shubham.1172 Glad to hear it. Judging by the number of engineers I've met from India, they've always taken their technology education quite seriously there.
Ah the memories come flooding back to when I coded in assembly on the 68000 & 68030. Move.l #x,d0 = 16 cycles and move.b or move.w #x,d0 = 8 cycles (on the Atari STe). Spent many hours trying to optimise my code run in one vsync cycle.
Different CPUs call the same things with different names. In most architectures it's called a program counter, on intel x86s it's called an instruction pointer.
@rerunturbografx that's amazing! I never knew Assembly could be used to write CPU agnostic software! I mean, I thought each CPU had it's own Assembly. I'll look into it. Thanks a lot!
I wish I had an explanation like this back in the day. It would have made me want to learn more and make me keep going with the idea of, "I can actually understand/do this." I the hang of Assembly with an Apple IIGS at a young age in a fairly short amount of time. That said, I also approached (and still do if I'm being honest) a lot of things with the result of hitting a brick wall figuratively over and over and over until at one moment it's like a switch is turned on, everything I've been taking in makes perfect sense, and I can easily do what I was attempting to do. That might be a learning problem, though; the same thing happened when I was learning to type, learning other languages, etc. When I teach mathematics now on the side I try and use as many descriptive word problems as I can to explore the processes in ways that relates to the student. I find I don't "hit a brick wall" nearly as often when presented in this way (like this player example) versus boring problems with no attachment or visual elements past just numbers.
That BGT is the same in ARM assembler. I write code for embedded ARM processors and it's the same. BLT (Branch if less than), BGT (Branch if greater than)
Cre8tvMG _West coast generally said 'scuzzy'_ And Gulf Coast, since the 80s. _east coast generally said 'sexy'_ I've worked professionally with people in NY/NJ since 2GB drives were common in the mid 1990s, and never once herd them say that they needed to install or replace "sexy" drives.
Assembly is very easy to understand-Anyone must rearrange your brain to think about the program from the most simple (+,-,*,/) to complicate TN/STN LCD Driver.I focused on assembly over 30 years and prepared to introduce H/S for some in Taiwan.
I have been coding a vector graphics rasteriser on one of the industrial control processors at work. It takes a long time to do seemingly small stuff but it feels so damn good when it finally works!
And this is just the very beginning and nothing visible on the screen - I can barely contemplate the fact that the original Roller Coaster Tycoon game was written almost purely in Assembly. Hats off to that developer
I think Carry Flag is when the value is bigger than the available current registry space that it's in, so that the flag tells it to carry the leftover (bigger) values of the whole value to the next registry space, because of it's size it can't be saved in one registry space. And for that of what he describes at around 4:45 is called the Negate/Negative flag. Otherwise nice video :)
This was a really well made video. It'd be awesome to see more of this kind of stuff - programming physics in 2d games is brutal when you write the physics yourself. It took me 3 weeks to figure out how to teach my program the difference between a collision with a wall and a collision with the floor / ceiling. And guess what, by the time I had a working prototype, I stopped working on it because the code was getting too long for me to jump back into. I'd definitely want to see a professional show how it's supposed to be done.
Off topic question; In old versions of windows why when it crashed and you moved the window, it would leave a trail of where the window was?, always struck me as an odd error.
If you do that on Twitch it would be good to also have the videos afterwards on UA-cam, so to have them available at any time and people can find them after some time.
This all makes sense in terms of establishing all the game's parameters- I need to keep digging until I discover how Assembly is used to plot graphical points. Years and years ago I wrote complete games in Basic and have been intimidated by Assembly for as long as I can remember. Looking at it like this, it make a lot of sense.
Drawing pixels is not really part of languages, it depends on the computer hardware and operating system. He's developing for a Sega console so he can probably just write pixels to a character map and then characters into a tile map using direct memory writes. On a modern desktop PC you would have to call OS functions to do that instead.
Anyone casually interested in assembly should check out the game "Shenzhen I/O" on steam. It's a puzzle game where you write assembly for fictional microprocessor chips and interconnect the chips on a circuit board to get them all working together to solve a problem. It's a lot of fun and gets quite challenging. I highly recommend it.
Is this how a, say C++ compiler, would implement a similar loop in a high level language (presumably with some sort of standard framework wrapping around it)? Or is writing it directly in assembly less processing intensive?
The couple of times I attempted to make things move across the screen in BASIC, as I remember it it was always necessary to "clean up" after every incremental step or I'd wind up leaving a trail of whatever shape or object I was trying to animate. Is this kind of process just built in here, or is he including such instructions into his code like - draw, erase, move, draw, etc.? It didn't seem like he had to code any "erase" instructions, or am I mistaken?
Great video. When you realize that games for NES, SNES and SEGA where done like this: one processor instruction at a time and no game engines like today's, you start to look at those games in whole different way. And for me at least is really surprising what those people did with just bare assembler. Just amazing.
I id my assembly a while ago. As I understand by this example gravity and florHeight are constants that are replaces in byte code during compilation. But shouldn't you move them in registry at first. I understand in more advanced cpus you have abundance of registers and assembly compiler does that for you. but in this case. Where gravity value is stored in cpu when subtraction is done? Is there extra hidden registry?
Most CPUs have 'immediate operands', so an instruction like ADD #3, D0 Means the #3 value is encoded into the instruction itself, so no need for special loading from RAM to get the value into a register. On RISC architectures because of fixed instruction size there are limitations to the number of bits you can use for these. MIPS for instance was limited to 16bit immediate operands.
SerBallister ok. Found one cpu architecture scheme where one of data inputs of ALU is wired not only to registry bank but also to instruction decoder. Then it makse sence.
This is a fantastic little video series! Its too bad I don't have a sega system anymore, it would have been sweet to try to get a cart. I'll just have to settle for the PC port.
Really? Because his Kickstarter mentions being able to release a cart for the Genesis. Besides, if it's a developers tool, surely they would be used to develop games to be released to a console and not sit there upon completion.
Some time correct, some time not correct, MC68000 use 32 bit inside for calculation but only 16 bit for data transfer and address, people say it is 16 bit CPU.
I’m working in Y86 right now and soon moving to x86, any suggestions on a basic project I can do to improve my skills? I’m familiar with register conventions (caller saved, callee saved, parameter, etc.) and working with the stack as well as with writing procedures but I still feel like I only know the basics.
I love how this legacy dev kits are just a press on the power switch and a serial cable to the PC, no extra probes or debug bridges needed, it's all built into software. I still have an IS_NITRO_EMULATOR at the office, which is the development hardware used for the original NTR Nintendo DS. It plugs in using a USB cable or serial connector, and (as long as you're running Windows 2000 or up) you can configure GDB to read your arm-T9 elf binary and step through the C/C++ code using a modern interface like Code::Blocks or even VSCode. Though the drivers are proprietary, that's the only thing to keep in mind if you lost your installer CD (and the original warioworld portal has been shut down for years now)
Nothing but respect for how knowledgeable this guy is, brilliant teacher too
Its Jamie Davies will I ever be able to make a video game I mean in the same way this guy develops video games WATTgames mate? I really like to be a game programmer and game design and game developer WATTgames mate.
Its Jamie Davies yeah but how do you programme trees and scenery into the video game joshua gollaher mate?
Its Jamie Davies could you teach me how develop video games for my computer joshua gollaher mate?
Learn how to program and then eventually you will be able to make video games with graphics libraries as OpenGL or with game engines as Unity or unreal Engine.
Its Jamie Davies I live in the UK can you tell me again please that there's more than billions people all over the world and more than millions people in Great Britain that love living on their own and love having their own independence and love having their own freedom and love having their own personal space too just the same as me please text me back yes Deffo that's true please cpp bear mate.
I want more of post malone to do some graphics in assembler
i thought he was batman
ProSurviver bahaha
What you talking about, thats Aphex Twin
haHAA Real funny
lol
I always start watching vids like this at 3am.
same, 4am here
same, 02:26 here
4 am here. ♬~ Maybe the dreams will come, maybe they'll visit me ~♬
3 am session here too
lol 2:45 here
"I got my environment setup" -> notepad++
xD
hes a real programmer
I mean yeah
Haha xD
Notepad++ is a decent tool for programming
This guy is so clearly knowledgeable about this. This is a truly great host to have on the show!
"let's define gravity" - things that prove programmers are gods
You left out the best part!
"Let's define gravity .. as 8" 😅
🎵 Kiss me goodbye, I'm defining gravity 🎵
LOL
high school physics will teach you that gravity is 9.8 m/s^2
false.
68000 machine code, brings back memories of 5am coding sessions on my beloved Amiga, bleary eyed with a half empty cup of coffee staring at devpac. Brilliant video!
You weren't a proper coder if you used Devpac, Asm-One was the only way to go!
@@thewelder3538 In 1988 Asm-One was not yet available.
@@mp-lv8bw Ah yes, so true. The only useful thing about DevPac was the fact it supported doing proper Workbench stuff better. Like the WaitPort() and DupHandle() you had to do for proper CLI/Icon start code. I must have used it initially, it's all just such a blur now.
I can't quite wrap my head around a lot of it, but it's super interesting that he's literally demonstrating how developers had to program Genesis games back in the early-90s, especially when you look back and consider some of the more mechanically and visually impressive titles on the system at the time. To me, it's very significant to the history of game development and industry history in general. Also helps that it's my all-time favorite console, hehe.
*Megadrive
It's basically like any basic programming, just without any frameworks or complex APIs, it will literally only do exactly what you tell it. Have a look at Game Maker if you want to get a feel for this yourself, it's a much higher level programming language obviously, but you can build up a lot of the same kinds of logic as is used here to get a feel for it.
@@Musikur I would say that the hardware itself was a framework. You had to play by its rules
Wow. You make it sound easier than Python.
Yes Python gets complicated a lot faster. Not because Python is difficult, but you get faster to the difficult problems vs playing with registers all day to get basic "movement" :P
chadestioco ikr? I thought it would take thousands of lines to get basic player movement in assembly
assembly is really, the most simple language out there. But it's also the most tedious language. Assembly isn't hard, it's tedious and time consuming.
Indeed, asm is very simple because you can only do a few things. What's complicated about it is making complex things out of those basic things
@@okie9025 .. "strict" (you meant static, or strongly typed but the contrast to strongly typed would be weakly typed) and "dynamic" refer to the typesystem your language uses. You're confusing it with "higher level" languages that don't reify memory management like Python, and to a slightly lesser extend Java/C#. There are languages with type systems that don't abstract memory management such as CPP. CPP has both static type checking and support for dynamic typing. Seriously, for the sake of your own growth, check up on basic terminology and principles before you get opinionated on anything.
13:20 - "Let's add to that: let's define gravity."
...moments that make you stop and realize what you're capable of as a programmer...
And if you defined it as a CPU address pointing to RAM, you could have variable gravity. Great for a level gimmick or whatever.
indeed, you can also see why one should and must,
admire that every single behavior in all programs
are written by some considerate programmers
I mean if the programmer didn't do the implementation,
you can't even close a window by clicking the close button.
He called the POUND a "hash," I wonder if he is younger than me? (Soon to be 29)
@@AsilarWindsailor No. # is referred to as Pound only in the US/Canada. in RoW it's hash and probably 1 other term I am unable to recollect at the moment.
@@reckz420 Interesting. I've never heard anyone refer to it as anything but pound until now. Does the # mean something in code? I cant remember now why he used it in this video as I hadn't watched since my previous comment
This is one of the best intros to Assembler I've ever watched. Thank you!
One of my favorite channels on youtube. We need more videos from this guys focused on game development! Pure gold! Awesome guy
I think it's great when Matt does videos on the Megadrive Devkit/Assembly. It's brilliant how instead of simply vaguely explaining how Assembly works (which he may have done in another video (?) not sure), they're actually showing a snippet of what coding in assembly is actually like in essence.
ok?
Assembly is so much fun. It's tedious, but it makes you feel like you are one with the machine, knowing it's every breath.
why would you want to be "one" with a machine? I used to write / debug linux device drivers in C and asm. I never once felt "one" with the machine. Was just a job to me. Its basically a more complex version of programming a VCR. I find women MUCH more interesting than computers.
@@lordoftheflings Then you failed as a programmer
@@lordoftheflings whyd you bring women into it
@@lordoftheflings We women also can relate to what Jeremiah said, you know?
"why would you want to be "one" with a machine?" For you It's just a job but for others is some awesome interesting stuff that we want to learn for fun. It's just a matter of interests I guess.
i felt the bulge of assembly last night
And coding is tough NOW, but when you look at Assembly, you instantly realize how much easier we have it these days for sure lol.
He truly is a wizard to keep retain this all.
Also the ultimate flex in this all is he is showing the demo, with a large EXPO marker, on PAPER. Not even a white board or laminated paper. This guy is so damn casual in his confidence
I like him, can we keep him?
nope.
Matt_Phillips.Dispose();
RIP
name: dc.b 'matt phillips'
movea.l name, a0
jsr revive
Isn't that from "heroes"?
Just excellent! I would really love to see more in this series. The real beauty of a system like this is when the complexity increases and you start to understand how all the different parts are working together.
The amount of information I've learned from Computerphile videos is invaluable.
This demo was really interesting. I like that 1 guy was 'doing' and the 'voice' was asking probing questions, so as to not assume the viewers were familiar with the jargon. Very cool and I'm gonna 'casually' retry my hand at ASM again like it's 1989.
All the videos on Numberphile(math), Objectivity(history), Sixty Symbols(Physics) , Periodic Videos(chemistry) and Deep Sky videos (Astronomy) are like that.
The voice makes it easier for the host by sticking to simpler themes
Gives an insight on how much programming languages have evolved
I think the LD (load) mnemonic is much less confusing than MOV (move). You don’t _move_ values into registers as such; you _load_ registers _with_ values. Additionally, you can load registers with values of other registers or memory locations. Since the original values remain unchanged, the notion of _moving_ values is at best misleading.
Keep up with the series! Make Assembly Great Again!
Ast A. Moore I was just thinking the same thing
Ast A. Moore I suppose. Depends on the processor and it's instruction set though. If you were dealing with an snes or a commodore 64 you'd find what you're allowed to do with registers is quite restricted, and there is no generic instruction to move values from memory into a register, but rather a bunch of more restricted ones.
Then again the majority of operations on these processors are register+ memory operations.
For insantance, to add two numbers you load a value into the A register, then pass a memory location to the ADD instruction. (possibly using the x register to store a partial adress, though aince there are about 27 addressing modes there's lots of odd variations).
the result of the ADD instruction has then overwritten the contents of the A register.
Which you can store somewhere in memory....
I guesx that doesn't really say much about mov vs ld really. XD
neither truly makes sense because the implication of mov is that the value is erased from the source.
It's really a logic thing.
load implies 'load a value from ...', move implies 'move a value to ...'
Yet the reality of course is that you need both a source AND destination for such instructions to make any sense...
as mnemonics, either of those only really truly makes sense if one of the two is implied.
lda makes sense (load from the specified location to register a), mva would sort of seem like a store instruction rather than a load.
But of course if you have a generic load, store or move instruction that specifies both source and destination it all amounts to the same thing, but with different emphasis. load (x)(from), store (x)(to), move (x)(to).
move has the disadvantage of implying that the source is erased, which it pretty much never is, so in that sense, mov really doesn't work logically.
but mnemonics are arbitrary anyway. two assemblers can use completely different mnemonics and if they produce the same binary instruction codes in the end it doesn't matter which you use.
Well, you are not wrong, and different architectures indeed work slightly differently. But consider these two CPUs: Z80 and 8080. The Z80 is 100% backward compatible with the 8080 (to the point of having identical opcodes). Nevertheless, conventionally, the Z80 uses the LD mnemonic, whereas the 8080 uses MOV (or variations of STORE). For example:
MOV A,B vs LD A,B
MVI A,byte vs LD A,byte
LHLD word vs LD HL,(word)
SHLD word vs LD (word),HL
STAX B vs LD (BC),A
These are identical instructions and after assembly, the resulting machine codes will be 100% compatible. Yet, Zilog decided to make the instruction set more uniform and straightforward (and, extended it quite a bit, naturally).
Writing code equally in Z80, 6502, 68000 and 8086 for multiple platforms just used to make my head hurt ;-) I learnt Z80 first (Zaks!) on my ZX81 but then came across the 6809 at university. Always preferred t e 6502, 6809, 68000 family over the Z80 and the horrible 64k banked 8088/8086. The key problem was that you could write a routine in 6502 and assuming your algorithm was sound, the first attempt was pretty much as fast it'll ever get. With the Z80, there were loads of tricks of which the main one was trying to keep everything in registers as compared to the 6502, accessing memory was real slow. So with Z80, you might re-write that all important "WriteSprite" routine on the Specky three or four times. The 68000 was a dream to work with. Loved it. Shame that Motorola didn't win the CPU wars. Intel's CPU line held the industry back quite a few years.
I also started on the Z80 (on the Speccy, though; skipped the ZX80 and ZX81). Then there was some 8086, then the PIC, then the 68k and the PowerPC (both on Macs). Loved the PowerPC architecture.
I must admit that optimizing my Z80 code was, arguably, the most satisfying part. Sure, it wasn’t always straighforward, and I occasionally resorted to self-modifying code (which is a no-no on modern systems, because of security reasons), but that was the _exciting_ bit. Counting the bytes and T-states, shaving off a couple here and a couple there, working around the Spectrum’s quirky screen memory addressing, sprite flickering, etc., there’s was a great deal of thrill in it.
I still write a little bit of Z80 code from time to time, just because I enjoy it so much.
Matt Phillips thanks you for sharing your knowledge on your blog, finally learning about programming games in Assembly, thank you.
Congrats on accomplishing your Kickstarter needs! Fantastic work
this is what my family thinks i do when I'm restarting the laptop to solve a problem.
I hope this is a full series; I'd love to learn about how this flavor of assembly interacts with I/O, like buttons and graphics :)
Button inputs are just hardwired to the hardware in such a way that when you press a button, there's a register somewhere in the system that changes value accordingly.
Then you can read that register value and do what ever you want with that in your program.
The "input register" might not be located on the main processor itself but on a peripheral IO device that's behind a bus of some sorts (SPI, I2S) in which case you might need to write the routine to get the values from the pheripheral to the processor/RAM and then use them as you wish.
But it's all the same, twiddle registers and use the values.
You're ignoring debounce requirements, and most inputs are not mapped to a register but have to be read in to a register. Perhaps the peripheral already debounces and you just need to read over the bus in to a register.
ok?
Assembly codes are superfast!
C complier unnecessarily extends the length of the code, but by organising the registers so that none of them is wasted and placing of the instructions, we can get max out of the CPU performance. This basic programming reminded me of my graduation years when we used to do the programming in assembly and analyse the entire operation through machine cycles and its waveforms. Amazing to see how higher level languages and highly resourceful CPUs have abstracted the process and relieved user from this lengthy process.
Mayur Balwani I think it's worth noting that all popular and large C compilers have been designed for maximum performance of the resulting assembly (with proper settings of course) for years. This means that most programmers won't be able to create more efficient assembly code than those compilers.
there is no such thing as maximum performance
gaby de wilde But there is something called maximum value of a function and optimisation techniques in the mathematics and also in real life. I have seen programmers optimizing their code to make the processor do what seems very difficult or even impossible to do with such least resources.
There's a digital guitar amplifier called a Kemper. You plug it into any other guitar amplifier and it copies its tone almost perfectly. Apparently all its algorithms are written directly in assembly code.
It is difficult to write assembly language on modern x86 processors (with speculative pipelines, etc) but those considerations don't apply to 68000. You can write code 50% to 300% faster in assembly language (I needed an interrupt driver for sampled sound on the ST, and so I used the USP as a temporary register that was used to keep track of the sample address, that saved 8 cycles, and since that code was executed 8000 times a second, it was 8% more efficient with just that one change). I wrote a 68000 to C converter for Sonic 3D and I had to work out whether the condition codes would be checked, in order to reduce the code size and get the code to run fast enough.
Nice work!
By the way, I've always loved the animations you use as part of explanations. What do you use for that?
+Tamas Zsebe Adobe After Effects >Sean
Assembly
Valerio Bertoncello yes
@@Computerphile yes I was expecting something complicated here too
ok?
This guy was probably like, "finally some recognition for this project I've been working on for 3 years."
like that bit at the end.. nice to know there are channels that still read the comments
ok?
This was awesome! Would love to see more assembly themed videos. For example a video explaining how you write an assembler from binary, if that's how that works.
He did it! He finished making the game! Congratulations to Matt. :)
Slight nitpick: this video should be titled *Game Physics (in assembly)*. Assembly refers to the actual language being used, and an assembler is the program used to convert assembly language into machine code. Nonetheless, this is an excellent video as always!
My first contact with assembly was on atari 65xs. I bought a book which was very hard for me to follow. This guy makes it so clear and easy! Thanks
i would enjoy a 1 hour video of him explaining everything in detail
Microprocessor Systems Design - Alan Clements. Great book on the 68k processor, for those who are interested, and would like to get into this. I picked it up for less than $10 shipped, amazing. Great addition to my library.
This was great! A very clear presentation of advanced technical material. Thanks again!
Ah the beauty of 68k assembly, did a lot of that back on the Amiga and enjoyed it greatly.
Loving these videos, Matt is awesome. :)
To anyone who's goal is to learn 2d game mechanics, if your specific goal isn't learning assembler, then don't start with assembler. You would be much better off starting with something like Python and PyGame or even C#/Mono and Xna/MonoGame. One of the main reasons that programming languages exist is so that people don't have to use assembler and worry about things like assigning registers and dealing directly with buses.
ok?
0:40 “So if you can imagine back to your BASIC days...” Uh what age is the target demographic of this video?
@B3ro1080 We used to write QBasic in the 6th grade (2010) :)
@@shubham.1172 No way. I can't believe it was still used that recently. I remember learning on QuickBASIC way back when.
@@tiny_toilet haha, it's still there in school curriculums in India!
@@shubham.1172 Glad to hear it. Judging by the number of engineers I've met from India, they've always taken their technology education quite seriously there.
false.
Ah the memories come flooding back to when I coded in assembly on the 68000 & 68030. Move.l #x,d0 = 16 cycles and move.b or move.w #x,d0 = 8 cycles (on the Atari STe). Spent many hours trying to optimise my code run in one vsync cycle.
Matt is very knowledgeable, so much so that he moves and sounds like he is part of the assembly.
The 'pc' register I've only ever heard called the IP (Instruction Pointer). Are they different things?
They're the same, the Program Counter register on x86 (amd style) assembly is %eip (IP being a mnemonic for instruction pointer).
PC stands for program counter and they are the same
I read somewhere somebody called it the "Reading Head" or something like that.
"Reading Head" sounds more like a turing machine thingy.
Different CPUs call the same things with different names. In most architectures it's called a program counter, on intel x86s it's called an instruction pointer.
could you make a video going through and explaining how someone could be as mad as to write RollerCoaster Tycoon in x86 assemble ?
Was it, really??
@@danielf950 yep.
@@adrianflo6481 Thanks, I didn't know that. What a patience!
Merry Christmas, Adrian.
@@danielf950 merry Yule!
@rerunturbografx that's amazing! I never knew Assembly could be used to write CPU agnostic software! I mean, I thought each CPU had it's own Assembly. I'll look into it. Thanks a lot!
I wish I had an explanation like this back in the day. It would have made me want to learn more and make me keep going with the idea of, "I can actually understand/do this." I the hang of Assembly with an Apple IIGS at a young age in a fairly short amount of time. That said, I also approached (and still do if I'm being honest) a lot of things with the result of hitting a brick wall figuratively over and over and over until at one moment it's like a switch is turned on, everything I've been taking in makes perfect sense, and I can easily do what I was attempting to do. That might be a learning problem, though; the same thing happened when I was learning to type, learning other languages, etc. When I teach mathematics now on the side I try and use as many descriptive word problems as I can to explore the processes in ways that relates to the student. I find I don't "hit a brick wall" nearly as often when presented in this way (like this player example) versus boring problems with no attachment or visual elements past just numbers.
I resemble your comment. Thanks for sharing.
combining my two favourite topics!
word.
Using music sheet paper to explain assembly code. A true gentleman.
This guy knows a lot!
false.
Ahh you're so close with your Kickstarter, I really hope you get it. Game looks like it could be really fun.
assembly language is so fukin cool. I loved every single bit of my microprocessor architecture course in college sem 2
An invaluable vid no matter which language you program in
Did Matt have own channel where he teaches these things in depth?
Thank you so much for the video. You guys are making youtube useful again. Thumbs up!
I wish you were my teacher when I was taking machine programming.
That guy has a really nice shirt.
Invader Zim Merch is awesome, i know. Just poke the wound.
It's Sips O'clock... Oh wait wrong channel.
false.
That BGT is the same in ARM assembler. I write code for embedded ARM processors and it's the same. BLT (Branch if less than), BGT (Branch if greater than)
19:14 Didn't realize it was widespread? But SCSI has been around since the early 1980s. Almost all of the M68K Macs used it for hard disk IO.
+RonJohn63 he meant how widespread saying "scuzzy" was instead of saying "S. C. S. I."
***** And people have been saying "scuzzy" that long.
West coast generally said 'scuzzy' and east coast generally said 'sexy', from my experience in the 80s and 90s.
Cre8tvMG _West coast generally said 'scuzzy'_
And Gulf Coast, since the 80s.
_east coast generally said 'sexy'_
I've worked professionally with people in NY/NJ since 2GB drives were common in the mid 1990s, and never once herd them say that they needed to install or replace "sexy" drives.
Brillant video. Thank you very much. I love this channel! -- Bill
false.
And everyone said assembly was hard. Maybe we just need this guy to explain it.
Assembly is very easy to understand-Anyone must rearrange your brain to think about the program from the most simple (+,-,*,/) to complicate TN/STN LCD Driver.I focused on assembly over 30 years and prepared to introduce H/S for
some in Taiwan.
I have been coding a vector graphics rasteriser on one of the industrial control processors at work. It takes a long time to do seemingly small stuff but it feels so damn good when it finally works!
And this is just the very beginning and nothing visible on the screen - I can barely contemplate the fact that the original Roller Coaster Tycoon game was written almost purely in Assembly. Hats off to that developer
Very cool video, I like the straightforward explanatory style.
I think Carry Flag is when the value is bigger than the available current registry space that it's in, so that the flag tells it to carry the leftover (bigger) values of the whole value to the next registry space, because of it's size it can't be saved in one registry space.
And for that of what he describes at around 4:45 is called the Negate/Negative flag.
Otherwise nice video :)
To think that 30 years ago this was how you made games.
I cant watch these videos. I will never be on the level of this guy..genius.
Hey it's the guy who made Tanglewood, what a G
"lets define gravity" has a really shocking and awe inspiring tone there.
Very nice introduction to both assembly and game programming!
Cool Video - I hope his game gets funded, It's so close!
I haven't been doing Assembly in a while, but seeing this video makes me want to get back to it and make a little raycaster. So, I will do that now.
I tried that once...in a high level language...and failed. I’m working on a true 3D engine, and somehow I’m better at that than a raycaster...
This guy needs to be a teacher. Sheeh.i learn so much more from this video than my assembler language course in college lol
Excellent video, from basic concepts, a detailed explenation of assembly language...
This was a really well made video. It'd be awesome to see more of this kind of stuff - programming physics in 2d games is brutal when you write the physics yourself. It took me 3 weeks to figure out how to teach my program the difference between a collision with a wall and a collision with the floor / ceiling. And guess what, by the time I had a working prototype, I stopped working on it because the code was getting too long for me to jump back into. I'd definitely want to see a professional show how it's supposed to be done.
Off topic question; In old versions of windows why when it crashed and you moved the window, it would leave a trail of where the window was?, always struck me as an odd error.
This video means so much to me.
Great job on explaining assembly! I wish I had this video when I was trying to create my “bear in a maze” game in assembly language!
Oh I recognise that place, it's the NVA in Nottingham, I used to work there, haha. Unfortunately it closed down last year.
Will we get a video where this will be connected to some graphics? Even just a moving square or so will be nice.
If you do that on Twitch it would be good to also have the videos afterwards on UA-cam, so to have them available at any time and people can find them after some time.
11:02 Wow! Such luxury! Keeping track of a variable in a register. That's really nice. It's kind of inconvenient having to push and pop all the time.
This all makes sense in terms of establishing all the game's parameters- I need to keep digging until I discover how Assembly is used to plot graphical points. Years and years ago I wrote complete games in Basic and have been intimidated by Assembly for as long as I can remember. Looking at it like this, it make a lot of sense.
Drawing pixels is not really part of languages, it depends on the computer hardware and operating system. He's developing for a Sega console so he can probably just write pixels to a character map and then characters into a tile map using direct memory writes. On a modern desktop PC you would have to call OS functions to do that instead.
Basically this is what a real life wizard looks like
I would love if universities taught microcomputing by making a video game on a SEGA mega-cd.
Good video. Interesting. This guy should feature more often.
wow I knew assembly was hardcore, but it's insane, dude you are amazing
Honestly it's first grade of faculty level
ok?
Just crazy how they get from this to a graphical end product where you see none of this. Mindblown.
Anyone casually interested in assembly should check out the game "Shenzhen I/O" on steam. It's a puzzle game where you write assembly for fictional microprocessor chips and interconnect the chips on a circuit board to get them all working together to solve a problem. It's a lot of fun and gets quite challenging. I highly recommend it.
Is this how a, say C++ compiler, would implement a similar loop in a high level language (presumably with some sort of standard framework wrapping around it)? Or is writing it directly in assembly less processing intensive?
The couple of times I attempted to make things move across the screen in BASIC, as I remember it it was always necessary to "clean up" after every incremental step or I'd wind up leaving a trail of whatever shape or object I was trying to animate. Is this kind of process just built in here, or is he including such instructions into his code like - draw, erase, move, draw, etc.? It didn't seem like he had to code any "erase" instructions, or am I mistaken?
Huh. Interesting, thanks!
He didn't got into the drawing part yet, he was just manipulating numbers.
Great video.
When you realize that games for NES, SNES and SEGA where done like this: one processor instruction at a time and no game engines like today's, you start to look at those games in whole different way. And for me at least is really surprising what those people did with just bare assembler. Just amazing.
Much of this is not about the assemblyr but about how you discretize and solve differential equations. You do the same steps whatever your language is
I id my assembly a while ago. As I understand by this example gravity and florHeight are constants that are replaces in byte code during compilation. But shouldn't you move them in registry at first. I understand in more advanced cpus you have abundance of registers and assembly compiler does that for you. but in this case. Where gravity value is stored in cpu when subtraction is done? Is there extra hidden registry?
Most CPUs have 'immediate operands', so an instruction like
ADD #3, D0
Means the #3 value is encoded into the instruction itself, so no need for special loading from RAM to get the value into a register.
On RISC architectures because of fixed instruction size there are limitations to the number of bits you can use for these. MIPS for instance was limited to 16bit immediate operands.
SerBallister ok. Found one cpu architecture scheme where one of data inputs of ALU is wired not only to registry bank but also to instruction decoder. Then it makse sence.
*Assembly
An Assembler is the tool used to compile Assembly language.
No dual monitors. No wide-screen. No VS code. This guy!
Awesome!!!
I would love to see more on this, especially the sprites
This is a fantastic little video series! Its too bad I don't have a sega system anymore, it would have been sweet to try to get a cart. I'll just have to settle for the PC port.
I do believe the system he has was modified by Sega to do development on. You're old Sega machine you bought from the store would not work.
Really? Because his Kickstarter mentions being able to release a cart for the Genesis. Besides, if it's a developers tool, surely they would be used to develop games to be released to a console and not sit there upon completion.
Yes, look at all the other addons on the system box. Does your game system have those?
I think if the game developer is literally telling me that hes creating the game to run on my system, then I'll believe him. >_>
So, when you talk about CPUs being 32/64 bit, are you referring to the size of those registries?
Kaas Christiansen
Yes. The amount of bits defines the amount of bits in the registers, and also how wide the buses between each part of the cpu are.
This is not exactly true anymore, 64 bits cpu now have 128 bits register and even bigger ones for some of them
Some time correct, some time not correct, MC68000 use 32 bit inside for calculation but only 16 bit for data transfer and address, people say it is 16 bit CPU.
Normally in x86 and x64 it refers to the size of the address bus
I’m working in Y86 right now and soon moving to x86, any suggestions on a basic project I can do to improve my skills? I’m familiar with register conventions (caller saved, callee saved, parameter, etc.) and working with the stack as well as with writing procedures but I still feel like I only know the basics.
Thanks so much for this. I loved it. I have been learning some assembly from a book and this really helped me get the context.
I'd be interested to see more on this topic.
I love how this legacy dev kits are just a press on the power switch and a serial cable to the PC, no extra probes or debug bridges needed, it's all built into software.
I still have an IS_NITRO_EMULATOR at the office, which is the development hardware used for the original NTR Nintendo DS. It plugs in using a USB cable or serial connector, and (as long as you're running Windows 2000 or up) you can configure GDB to read your arm-T9 elf binary and step through the C/C++ code using a modern interface like Code::Blocks or even VSCode.
Though the drivers are proprietary, that's the only thing to keep in mind if you lost your installer CD (and the original warioworld portal has been shut down for years now)
I haven't seen Assembler before, thanks for the video.