5:53 Matt:"boring bit, boring bit, boring bit, cut this out, cut this out, cut this out" Sean: "Nah man, screw you, I find this interesting! I won't cut this out!!!!!!!!!"
I love seeing assembly code. I wrote a graphics driver for the TI-84+CSE in Z80 Assembly. There was no software-level stuff for graphics in the slightest nor was there a GPU. You had to directly write bits to the input pins of the LCD controller chip (ILI9335). The Z80 assembly chip only could address at maximum 16-bit values, this means that you couldn't even control the entire screen at one time. Instead the chip supported a "window" feature where you give it coordinates and a width and height and it gives you control of a little portion of the screen called a "window". You could use this to draw sprites by selecting the coordinates and width and height of where you wanted the sprite to be and then outputing all the pixels of the sprite into the window. I've never seen anyone use an actual GPU tho through assembly so this is definitely pretty interesting, figuring out how to use a GPU is hard enough as it is in C lol.
+BertyFromDK No. The original TI-84+ and the Silver Edition (2004) have monochrome 96x64 displays. 16-bits is enough to map them to RAM, so you don't have to control the LCD controller directly (although it's possible if you want). The TI-84+CE (2015, the most recent one) upgraded the processor from a Z80 to an eZ80 chip which has 24-bit registers so it can support much more RAM and can map the video memory to RAM. It's only the TI-84+CSE (2013) specifically that you need to control the chip directly because it has a color screen but does not have the upgraded eZ80 processor.
amihart Wow, i didn't know there are now color versions of the TI-84! All i have is a TI-85 and a TI-86, but the TI-84 color sounds very intriguing, i may have to get me one of those :D
+BertyFromDK I find them interesting to program for because to my knowledge they're the only modern computers that still use Z80 CPUs, and again to my knowledge the TI-84+CE is the only computer on the market that runs the upgraded eZ80 processor.
I always remember flicking the switch on my Genesis and seeing that first flicker of initilization just before the SEGA logo would pop up. Now I know why. Thanks!
I used to code 68000 assembly for Amiga demos ~30 years ago. It's amazing how much I forgot. I never used macros, and I think I didn't even use constants that much, certainly not for addresses. Not sure if i wanted to learn it again. But the video certainly pulled back nice memories. Thanks!
I once took a class that had us build a MIPS-type CPU in VHDL. When the whole thing was done, you could run little assembly programs on it, which was just mind blowing to me. You really had to fiddle with everything kind of like this, because it also obviously didn't have an OS to help you with memory, etc. In a weird way, its all way simpler than you think and waaay more complex at the same time.
goeiecool9999 yeah, I remember seeing a colleague's senior-level compiler writing project that targeted 6502 assembly and it didn't seem elegant at all to work with by comparison.
Could indead be some trickery by the assembler. Wouldn't be suprised if some assemblers are able to 'simulate' the behaviour and just replace it with a specific set of instructions for the architecture.
The 68K CPU and support chips had an almost perfectly orthogonal programming model which gives the code a much cleaner look compared with what Z80 and 6502 code looks like. In this context, being orthogonal means that you can (theoreticaly) apply any desired addressing mode to any of the user registers.
Same! I get this little thrill when I can make the mental connection to what exactly what the hardware is doing with the code. I don't get the same feeling from higher level languages because its too abstracted for me to really see it.
20 years ago, I wrote a blaster game in assembly. It was CGA. I was so proud of myself. My parents always wonder why I always look at my computer screen and worry I will be socially dysfunctional.
Sega: "hah you will never guess the security pass code to make ROMs!" Coder from 2018: "Its just 'SEGA' isn't it?" *Sega would like to know your location*
I barely understand what he's explaining (I think) and I don't know any programming language at the moment, but I still find this interesting to watch.
I wonder what the equivalent number of lines of assembly source would be for the average game nowadays. Amazing how there's so much involved in doing something so simple!
Hey, kids: If you're working in Assembly, are doing the memory management & code optimisation yourself, have an inner loop that gets called a lot, that is always going to have the same number of iterations, and you have the memory to hold the code, consider unrolling your loops; It might save you the overhead of the code for alloc'ing and handling and dealloc'ing for a loop.
Even Java 8 still has newly introduced loop-unroll optimizations ... also: don't call subs in a tight timing loop, but inline it instead (could be a macro)
IDE??? really? i thought Notepad++ was an editor that you could combine with other elements such as a compiler or assembler to form a complete programming environment.
In case anyone misses it there is an extra video on what macros are mentioned in the description. Here is the link so you don't even have to look: EXTRA BITS: ua-cam.com/video/vRni1-KY0MQ/v-deo.html Great video again Matt, thanks for sharing.
Nice one! I did the same on the same CPU inside the Amiga. Those were the days...no internet, few docs & examples. You needed a high level of raw natural talent to succeed in games programming. I wonder how things would be today if the internet stopped working.
Natural Tangent The value used in the video is (0xFFFF/2)-1 which evaluates to 32766, correct me if I'm wrong. So, how many times will the loop execute? (we need 32768 times)
Ciao, secondo te è possibile imparare a programmare (intendo a scopo didattico) in assembler senza la conoscenza dell'architettura del calcolatore ? Oppure in alternativa cosa è necessario saper conoscere e mi riferisco all'architettura per poter affrontare la programmazione in assembler ?
8:50 "Each palette entry is 9 bits" 9:13 "EEE is red green and blue all at maximum" I'm confused. If each entry is 9 bits and red, green, and blue all get 3 bits, how is E their max value? Shouldn't 7 be their maximum value, because (2^3)-1=7? Also, doesn't 0x0EEE take up 12 bits if you ignore the unused 0? Shouldn't that be invalid given that each palette entry take 9 bits?
Each palette entry is 9 bits but it is stored in a 16 bit word: 0b0000RRR0GGG0BBB0. Three bits is 0-7 but they are shifted one bit to the left in each nibble, so the values are just the eight even numbers 0, 2, 4, 6, 8, A, C, E.
You should hook this guy up with the GameHut channel. He's an ex megadrive programmer showing all the tips and tricks and how-to's under the hood for the official megadrive games he and the team at Traveller's Tales made.
I dunno. I found the process of creating a small program that turns the screen purple on a SNES pretty straightforward. And I had no assembler to work with, just a hex editor and an emulator with a debugging feature. Had to write out the code, manually convert it to hexadecimal (you do NOT wanna code jump instructions manually, believe me. Especially not relative jumps). OK, granted there were about 80 instructions worth of initialisation code (most of which is just used to set initial values in VRAM and various registers), and then it took about 3 instructions to set a background colour. That sounds like a lot of work, and of course, the highly manual method I was using made it more difficult than it should've been, but frankly, doing the equivalent using DirectX, the windows Api and all of that stuff was an order of magnitude more work than doing it 'bare metal' on a SNES... So in all honesty... Meh. I mean, in creating DirectX code I had to perform manual RGB conversions, deal with palettes, VRAM pitch and stride, manually setting each and every pixel. (because there is no 'background' in a DirectDraw surface - just some virtual VRAM) It's a lot more work than the assembly code on a 16 bit console ever was...
Having said that, from looking at your code it seems as though the Mega Drive's VDP has an extra layer to it that's a bit annoying; Having to write to a port to access VDP registers sounds like a pain; SNES PPU registers are mapped into the CPU's address space at 0x2100. While there are ports for VRAM, CGRAM and OBJ attribute memory, all other registers are mapped directly into this address space. - The Audio data ports are also mapped in this range. (you also find some stuff mapped at 0x4200 - these registers are all CPU extensions. Features that the 65816 CPU core itself lacks, such as multiply/divide hardware, timers, DMA control registers, game controller registers, etc. The SNES of course has two address buses, bus A and bus B. Everything is on bus A, but bus B is effectively an alias for all the stuff that is mapped at 0x2100 to 0x21FF The DMA controller works by transferring data from a Bus A address to a Bus B address, or vice versa. Anyway, the point of this being that for the vast majority of features, dealing with these registers is no different to simply reading or writing to any memory location. It's not a complex task at all. Writing to VRAM (or CGRAM) presents an extra step in that you have to specify a starting address, but from there it auto-increments, so it's only if you need to do complex out of order VRAM access that it gets a little messy. Only OAM presents a complication, and only in that you have to write 544 bytes, and the data for a single sprite is broken between 2 bytes in one part of OAM and an additional 2 bits in the last 32 bytes of OAM. That's a bit of a pain. (but with careful planning writing to the upper 32 bytes of OAM is only needed on rare occasions, since it contains the OBJ size bit, and the high bit of the x-coordinate - which only needs to change if the object goes off the left edge of the screen.) Kind of ironic the Mega Drive would add an extra layer of complication, since as a general rule the Mega Drive's VDP seems less capable but more consistent and orthogonal. - the SNES PPU has a bunch of features and capabilities the VDP does not, but you can't use them in arbitrary combinations. It depends on which modes and settings you have enabled. The VDP lets you throw together basically any feature it has in any combination. Sprites on the VDP are also more flexible, since you can have any sprite be any size from 8x8 to 32x32, including stuff like 32x8, and each sprite can be it's own size - SNES sprites can be 8x8 to 64x64, but must always be square. Additionally only two sizes can be active at once. Eg, 8x8 + 64x64, or 16x16+32x32. You can pick any combination, but it's always only two sizes... Possibly the single most painful limitation the SNES has, since it makes optimising sprite use very tricky. (pick a size that's too small and large objects have to use way too many sub-sprites, which you then all have to move individually, slowing performance. Pick a size that's too large, and you waste huge amounts of VRAM, and potentially also limit how many sprites you can show since transparent areas of sprites still count towards limits on the number of sprite tiles you can draw in a line) Mega Drive sprites, even though technically smaller and there being only 80 instead of 128 are simply much more flexible and easier to use efficiently...
I fail to see the point of these comments... Maybe you should start a blog and post this there instead... DirectX is more work than taking on the task of an assembler? That makes no sense lol.
Well yeah, it's not like assembly is unimportant nowadays. Higher level languages were really just invented to make programming easier, and faster. By the time someone finished working on a program in assembly, the person working in a higher level language would've completed their program and iterated upon it several times.
Silly question but I'm curious... why does the Mega Drive's VDP chip have 4 unused registers? I know it was based on one of their arcade boards during development, would it have something to do with being a less powerful derivative with fewer functions?
I didn't quite understand the bit of the move.w #(0xFFFF/2)-1. I get why we take 1, but I don't get why we have to divide 64 by 2. Thanks in advance to anyone willing to answer!
If you have access to large whole numbers you can use them as fake decimals (i.e. 7.65 = 765) and if you only can use positive, you can consider half your range as 0.
NotMarkKnopfler I think, and I'm not a professional programmer by any means, but I think that if he didn't predecrement, he would be counting to the 25th register, which doesn't exist. Remember that computers are zero indexed, that is, they count from 0, not from 1, which would make the 23rd iteration from a humans perspective, be the 24th iteration for the computer. Effectively he's doing the same as the following "for (int i = 0; i < 24; i++) { //Set the value of register 7 here }" As for your second question, I'm not sure when he did because he set up a lot of macros that abstract a lot of that stuff away, but then again I don't fully understand assembler, so it may be that I missed it through my lack of knowledge.
The hardware just works that way. And actually the zero flag isn't set in the status register for a DBRA at all. DBRA stands for "decrement and branch always" which means "subtract 1 from the register at 16-bit length, and if it doesn't now equal 0xFFFF, jump back.
5:53
Matt:"boring bit, boring bit, boring bit, cut this out, cut this out, cut this out"
Sean: "Nah man, screw you, I find this interesting! I won't cut this out!!!!!!!!!"
??
MORE OF THIS PLEASE
I love seeing assembly code. I wrote a graphics driver for the TI-84+CSE in Z80 Assembly. There was no software-level stuff for graphics in the slightest nor was there a GPU. You had to directly write bits to the input pins of the LCD controller chip (ILI9335). The Z80 assembly chip only could address at maximum 16-bit values, this means that you couldn't even control the entire screen at one time. Instead the chip supported a "window" feature where you give it coordinates and a width and height and it gives you control of a little portion of the screen called a "window". You could use this to draw sprites by selecting the coordinates and width and height of where you wanted the sprite to be and then outputing all the pixels of the sprite into the window. I've never seen anyone use an actual GPU tho through assembly so this is definitely pretty interesting, figuring out how to use a GPU is hard enough as it is in C lol.
Is that feature shared between all the Z80-based calculators from TI?
+BertyFromDK
No. The original TI-84+ and the Silver Edition (2004) have monochrome 96x64 displays. 16-bits is enough to map them to RAM, so you don't have to control the LCD controller directly (although it's possible if you want). The TI-84+CE (2015, the most recent one) upgraded the processor from a Z80 to an eZ80 chip which has 24-bit registers so it can support much more RAM and can map the video memory to RAM. It's only the TI-84+CSE (2013) specifically that you need to control the chip directly because it has a color screen but does not have the upgraded eZ80 processor.
amihart
Wow, i didn't know there are now color versions of the TI-84!
All i have is a TI-85 and a TI-86, but the TI-84 color sounds very intriguing, i may have to get me one of those :D
+BertyFromDK
I find them interesting to program for because to my knowledge they're the only modern computers that still use Z80 CPUs, and again to my knowledge the TI-84+CE is the only computer on the market that runs the upgraded eZ80 processor.
ok?
Bruh how is this dude so chill? He’s a good teacher too.
"The two hardest problems in computer science are naming things, cache invalidation, and off-by-one errors" (with apologies to Phil Karlton)
0, 1, 2...
Yup, story checks out.
I have 0 problem with starting evert court at 0.
You gotta be consistent, though, or that's where the problems start.
@@killfalcon Yo, I got 99 problems and a buffer overflow ain't one.
Love this assembly series.
What is the name of this assembly language
I always remember flicking the switch on my Genesis and seeing that first flicker of initilization just before the SEGA logo would pop up. Now I know why. Thanks!
This guy is totally to the METAL! more videos with megadrive guy pls! :)
These vid's are fantastic. The end bit was the perfect ending as well lol
I used to code 68000 assembly for Amiga demos ~30 years ago. It's amazing how much I forgot. I never used macros, and I think I didn't even use constants that much, certainly not for addresses.
Not sure if i wanted to learn it again. But the video certainly pulled back nice memories. Thanks!
13:32 “fingers crossed it should be red” *press keyboard, screen goes orange “there we go”
xD
maybe the given light is just too bright that it made the image more green
I work in real estate. Why am I up late watching videos about programming game graphics in assembly? Damn youtube rabbit holes.
That's what makes youtube awesome :D
_It's free real estate_
A lot of work for changing the background screen, really appreciate it.
This brings back memories.
He is a better man than me.
I don't see myself deliberately going back to old CPUs and using Assembler.
Good luck.
Good job leaving the 'cut this out' bits in, Brady - it made me smile. Plus it's interesting to see what he's doing anyway. :)
I once took a class that had us build a MIPS-type CPU in VHDL. When the whole thing was done, you could run little assembly programs on it, which was just mind blowing to me. You really had to fiddle with everything kind of like this, because it also obviously didn't have an OS to help you with memory, etc. In a weird way, its all way simpler than you think and waaay more complex at the same time.
The assembly looks pretty clean compared to what I'm used to from Z80 or 6502.
Is that really what m68k assembly looked like? It feels "modern" compared to what I remember of it.
I'm not sure. I was particularly surprised seeing the LEA instruction. Maybe it's some trickery handled by the assembler.
goeiecool9999 yeah, I remember seeing a colleague's senior-level compiler writing project that targeted 6502 assembly and it didn't seem elegant at all to work with by comparison.
Could indead be some trickery by the assembler. Wouldn't be suprised if some assemblers are able to 'simulate' the behaviour and just replace it with a specific set of instructions for the architecture.
The 68K CPU and support chips had an almost perfectly orthogonal programming model which gives the code a much cleaner look compared with what Z80 and 6502 code looks like.
In this context, being orthogonal means that you can (theoreticaly) apply any desired addressing mode to any of the user registers.
there's a great feeling of freedom when coding this way for a system you become deeply in-tune with. no messy API red tape to deal with.
Once the hard work's done...the hard work's done
The first rule of the tautology club is the first rule of the tautology club. :-)
Rejoice! /r/tautology is a thing
If (hardwork == done)
hardwork = done;
while hardwork == done :
hardwork += done
Facey Neck
That will add value of done and might stop the function
While (hard work == done) {
hard work = hard work;
hard work = done;
}
Assembly; always fun.
Big fan of this guy and the 16bit game era. Please do more videos about this.
I absolutely love assembly.
Assembly is the biggest horror for dumbasses like me :(
Same! I get this little thrill when I can make the mental connection to what exactly what the hardware is doing with the code. I don't get the same feeling from higher level languages because its too abstracted for me to really see it.
20 years ago, I wrote a blaster game in assembly. It was CGA. I was so proud of myself. My parents always wonder why I always look at my computer screen and worry I will be socially dysfunctional.
Which assembly language is most very useful in this 2024
Sega: "hah you will never guess the security pass code to make ROMs!"
Coder from 2018: "Its just 'SEGA' isn't it?"
*Sega would like to know your location*
Man, how far we've come.
Not as far as you think, unfortunately.
I remember doing this kind of graphics assembly programming 13 years ago with an Atari ST. Good memories, a lot of fun.
Stunning, this channel is a godsend, thank you so very much.
Sean is learning a lot of programming. So much that he could help debug the program :D
Alright, this was incredible. I'd like to see more of this guy!
68000 was the best Assembler Language Ever. I miss it so much. I use to program Graphics in Assembler on the Atari ST decades ago. Loved that machine.
Are you guys giving this guy the money for these videos? He deserves it. Maybe should set up his own channel!
This is so awesome, keep up with the assembly language videos, I wouldn't mind to get to know about other assembly languages.
Genius at work. Absolutely blowing my mind! 🤯
I barely understand what he's explaining (I think) and I don't know any programming language at the moment, but I still find this interesting to watch.
This is real programming, Machine/Assembly coding, none of this slow language compiling code, C++ or Java, Great Stuff.
Loved the video :o)
Real programmers program using hardware! None of this garbage machine code/assembly
@@justinhughes7483 real programmers bitbang electric signal directly into the bus
This is a great series. Thank you!
The dreaded off-by-one error. Been there. A lot ...
There are two major problems in computer programming.
1) Handling cache.
2) Naming things.
3) Off by one errors.
What about buffer-overflows?PhLULZX5LULZXACBKJI
root@localhost: ~$
@Evi1M4chine There are 10 kinds of people in the world. Those who understand binary and those who don't.
@@quintrankid8045 0x10 year olds should not be allowed to drive.
I wonder what the equivalent number of lines of assembly source would be for the average game nowadays. Amazing how there's so much involved in doing something so simple!
Love the old school stuff. Great vid guys.
You need to get this guy in contact with the person running the GameHut channel; that would be a great collaboration :D
I think he said that he has worked at Travelers Tales so they probably know each other.
And yes that'd be great if it happened!
It's insane to think this is how people used to program, mind blowingly awesome...
Look up stuff on the altair 8800, the first PC. Then stare in confused wonder at how far we have come.
This dude is fantastic and an awesome teacher.
awesome to see some assembly language programming
Hey, kids: If you're working in Assembly, are doing the memory management & code optimisation yourself, have an inner loop that gets called a lot, that is always going to have the same number of iterations, and you have the memory to hold the code, consider unrolling your loops; It might save you the overhead of the code for alloc'ing and handling and dealloc'ing for a loop.
But YMMV.
Even Java 8 still has newly introduced loop-unroll optimizations ... also: don't call subs in a tight timing loop, but inline it instead (could be a macro)
Holy cow, you'd need superhuman patience and dedication to work with this. No thank you! I'll stick to writing my little programs in BASIC.
Notepad++ best IDE for assembly
redaxxx really?
Probably not, but I bet there is nothing comparable/better which is compatible and still downloadable for Windows 95/98
IDE??? really? i thought Notepad++ was an editor that you could combine with other elements such as a compiler or assembler to form a complete programming environment.
Vim exists
I use visual studio
Just use MS Paint and the bucket tool
I love the use of tractor-feed paper
Matt, more assembly please!
congratulation for 1M
Thanks!
your dev unit is freaking cool!
Writing device drivers is where the fun is.
More of this please!!!
i love the way he explain assembly language
REAL SOFTWARE ENGINEERING. *thumbsup*
Cool vid! Gotta Bit' Em All!
Excellent info. I appreciate the video, great stuff.
How the hell did Chris Sawyer write the whole of RollerCoaster Tycoon in assembly
How many years of experience so I need to actually understand a word of what this man is saying
about a month should be fine.
You just need to read MrJester's 68k Assembly guide. Should take maybe a couple weeks of practice.
digging the winston t-shirt
Brings back the days when writing drivers was cool.
Nice editing
this is the most interesting video ive ever seen...
:)
Excellent!! Please keep up the work!
A fun trip down memory lane. A little over the top to explain that simple loop 3 or 4 times though.... :-)
In case anyone misses it there is an extra video on what macros are mentioned in the description. Here is the link so you don't even have to look: EXTRA BITS: ua-cam.com/video/vRni1-KY0MQ/v-deo.html
Great video again Matt, thanks for sharing.
30 years ago i wrote motorola 68000 assembly programs on the Atari ST computers
Me too!
Nice one! I did the same on the same CPU inside the Amiga. Those were the days...no internet, few docs & examples. You needed a high level of raw natural talent to succeed in games programming. I wonder how things would be today if the internet stopped working.
This is awesome! I really like the idea of games made for the mega drive using procedurally generated levels! Are there any currently available?
9:40 you said bit, but it seems you were talking about a byte if I saw it correctly, didn't I?
More of this please! :) - Any update on how Matt is doing?
This is fascinating.
that was more a legal challenge rather than a technical one :D
The fact he's using a Razer Krait from 2006.
Cool video, however while clearing the VRAM you should loop from 0x7fff (0x10000/2 - 1) to 0, not from 0xffff/2-1, which is 0x7ffe.
Yeah i found his technique somewhat odd as well. I assumed he did the final operation immediately after the loop finished.
68000 dbra loops terminate when the counter reaches -1 rather than 0.
Natural Tangent The value used in the video is (0xFFFF/2)-1 which evaluates to 32766, correct me if I'm wrong.
So, how many times will the loop execute? (we need 32768 times)
Also: keep in mind that 0xFFFF is already one less than 65536 (64 »Kibibyte«); off-by-two error, anyone?
I only just learned the basics to motorla 68k assembly last semester so this was a bit tough to follow (why divide by 2?) but was very interesting!
Because he's clearing the GPU's memory a Word at a time, rather than a Byte at a time
that makes sense!
Ciao, secondo te è possibile imparare a programmare (intendo a scopo didattico) in assembler senza la conoscenza dell'architettura del calcolatore ? Oppure in alternativa cosa è necessario saper conoscere e mi riferisco all'architettura per poter affrontare la programmazione in assembler ?
8:50 "Each palette entry is 9 bits"
9:13 "EEE is red green and blue all at maximum"
I'm confused. If each entry is 9 bits and red, green, and blue all get 3 bits, how is E their max value? Shouldn't 7 be their maximum value, because (2^3)-1=7? Also, doesn't 0x0EEE take up 12 bits if you ignore the unused 0? Shouldn't that be invalid given that each palette entry take 9 bits?
Each palette entry is 9 bits but it is stored in a 16 bit word: 0b0000RRR0GGG0BBB0. Three bits is 0-7 but they are shifted one bit to the left in each nibble, so the values are just the eight even numbers 0, 2, 4, 6, 8, A, C, E.
meowsqueak ah, this makes sense. Thanks!
You should hook this guy up with the GameHut channel.
He's an ex megadrive programmer showing all the tips and tricks and how-to's under the hood for the official megadrive games he and the team at Traveller's Tales made.
I dunno. I found the process of creating a small program that turns the screen purple on a SNES pretty straightforward.
And I had no assembler to work with, just a hex editor and an emulator with a debugging feature.
Had to write out the code, manually convert it to hexadecimal (you do NOT wanna code jump instructions manually, believe me. Especially not relative jumps).
OK, granted there were about 80 instructions worth of initialisation code (most of which is just used to set initial values in VRAM and various registers), and then it took about 3 instructions to set a background colour.
That sounds like a lot of work, and of course, the highly manual method I was using made it more difficult than it should've been, but frankly, doing the equivalent using DirectX, the windows Api and all of that stuff was an order of magnitude more work than doing it 'bare metal' on a SNES...
So in all honesty... Meh.
I mean, in creating DirectX code I had to perform manual RGB conversions, deal with palettes, VRAM pitch and stride, manually setting each and every pixel. (because there is no 'background' in a DirectDraw surface - just some virtual VRAM)
It's a lot more work than the assembly code on a 16 bit console ever was...
Having said that, from looking at your code it seems as though the Mega Drive's VDP has an extra layer to it that's a bit annoying; Having to write to a port to access VDP registers sounds like a pain;
SNES PPU registers are mapped into the CPU's address space at 0x2100. While there are ports for VRAM, CGRAM and OBJ attribute memory, all other registers are mapped directly into this address space.
- The Audio data ports are also mapped in this range.
(you also find some stuff mapped at 0x4200 - these registers are all CPU extensions. Features that the 65816 CPU core itself lacks, such as multiply/divide hardware, timers, DMA control registers, game controller registers, etc.
The SNES of course has two address buses, bus A and bus B. Everything is on bus A, but bus B is effectively an alias for all the stuff that is mapped at 0x2100 to 0x21FF
The DMA controller works by transferring data from a Bus A address to a Bus B address, or vice versa.
Anyway, the point of this being that for the vast majority of features, dealing with these registers is no different to simply reading or writing to any memory location.
It's not a complex task at all.
Writing to VRAM (or CGRAM) presents an extra step in that you have to specify a starting address, but from there it auto-increments, so it's only if you need to do complex out of order VRAM access that it gets a little messy.
Only OAM presents a complication, and only in that you have to write 544 bytes, and the data for a single sprite is broken between 2 bytes in one part of OAM and an additional 2 bits in the last 32 bytes of OAM.
That's a bit of a pain. (but with careful planning writing to the upper 32 bytes of OAM is only needed on rare occasions, since it contains the OBJ size bit, and the high bit of the x-coordinate - which only needs to change if the object goes off the left edge of the screen.)
Kind of ironic the Mega Drive would add an extra layer of complication, since as a general rule the Mega Drive's VDP seems less capable but more consistent and orthogonal. - the SNES PPU has a bunch of features and capabilities the VDP does not, but you can't use them in arbitrary combinations. It depends on which modes and settings you have enabled.
The VDP lets you throw together basically any feature it has in any combination.
Sprites on the VDP are also more flexible, since you can have any sprite be any size from 8x8 to 32x32, including stuff like 32x8, and each sprite can be it's own size - SNES sprites can be 8x8 to 64x64, but must always be square. Additionally only two sizes can be active at once. Eg, 8x8 + 64x64, or 16x16+32x32. You can pick any combination, but it's always only two sizes...
Possibly the single most painful limitation the SNES has, since it makes optimising sprite use very tricky.
(pick a size that's too small and large objects have to use way too many sub-sprites, which you then all have to move individually, slowing performance. Pick a size that's too large, and you waste huge amounts of VRAM, and potentially also limit how many sprites you can show since transparent areas of sprites still count towards limits on the number of sprite tiles you can draw in a line)
Mega Drive sprites, even though technically smaller and there being only 80 instead of 128 are simply much more flexible and easier to use efficiently...
::slow claps::
I fail to see the point of these comments... Maybe you should start a blog and post this there instead... DirectX is more work than taking on the task of an assembler? That makes no sense lol.
Love the Astro Wars in the background. Is the other game there Scramble by any chance?
so glad they invented high level languages 😂😂😂
He IS programming in a high level language. It's called C++.
Lzhe Dmitriy where did you see any C++ in this video??
It's assembly. C++ is still quite low level, but definitely not as hard as assembly which is shown in this video.
I think Assembly programming is more fun, but that's just me i guess ;)
Well yeah, it's not like assembly is unimportant nowadays. Higher level languages were really just invented to make programming easier, and faster. By the time someone finished working on a program in assembly, the person working in a higher level language would've completed their program and iterated upon it several times.
Really interesting stuff there, good job.
Also is there any own made or finished game from Matt?
Tanglewood. (He also worked on other games for other companies but Tanglewood is his own game.)
Nice Winston Shirt :D
❤ Mr Megadrive and his Megadrive.
5:00 0xFFFF/2 is not 64kB, but 64kB-1.
Silly question but I'm curious... why does the Mega Drive's VDP chip have 4 unused registers? I know it was based on one of their arcade boards during development, would it have something to do with being a less powerful derivative with fewer functions?
There is an off-by-one error in your VRAM clearing loop.
This is so cool.
So funny because the 68000 was a BREEZE to code for compared to previous CPUs. But I’m sooooo glad I don’t have to write games in assembler anymore.
I didn't quite understand the bit of the move.w #(0xFFFF/2)-1.
I get why we take 1, but I don't get why we have to divide 64 by 2.
Thanks in advance to anyone willing to answer!
He's doing 2 bytes at a time, so he has to divide by 2.
distracted by that godly tattoo the whole video time to go back and watch again
I've done some 6800 but never any 68000... that's quite a fascinating assembler.... all that move.b and move.w is kinda unusual.
Im making a game in assembly for a school project and i have no idea how the hell can i detect collision by using only whole numbers😕
For simple sprites, Google AABB collision detection, you can detect if 2 rectangles overlap.
If you have access to large whole numbers you can use them as fake decimals (i.e. 7.65 = 765) and if you only can use positive, you can consider half your range as 0.
Can you do another assembly one but with Commodore 64? 6502/10
If you define enough macros, do you kind of end up with a programming language on top of assembly?
No, too many macros just creates a mess.
Yes. Until you take a 2 month break and forget what they all do and have to start over
Excellent example of asm
Anyone know what the writing paper he is using is?
Pfft. Sixteen-bit consoles with loads of RAM and a dedicated GPU. The ZX Spectrum is where it’s all at. :D
Where can I get the Sega Dev Kit?
Why are the loop counters pre-decremented by one? I don't get it. When does the zero flag get set in the status register?
NotMarkKnopfler I think, and I'm not a professional programmer by any means, but I think that if he didn't predecrement, he would be counting to the 25th register, which doesn't exist.
Remember that computers are zero indexed, that is, they count from 0, not from 1, which would make the 23rd iteration from a humans perspective, be the 24th iteration for the computer.
Effectively he's doing the same as the following
"for (int i = 0; i < 24; i++)
{
//Set the value of register 7 here
}"
As for your second question, I'm not sure when he did because he set up a lot of macros that abstract a lot of that stuff away, but then again I don't fully understand assembler, so it may be that I missed it through my lack of knowledge.
The hardware just works that way. And actually the zero flag isn't set in the status register for a DBRA at all. DBRA stands for "decrement and branch always" which means "subtract 1 from the register at 16-bit length, and if it doesn't now equal 0xFFFF, jump back.