Stephen Epp's Spring 2019 Journal
Keep reading and you may find something useful… Just kidding! You are simply wasting your time reading this. You may move on now if you like. Since you are still wasting your time, I'll keep talking. Stuff. NASCAR is really cool. I like it. So is baseball. I like it, too. Football is okay. I don't watch any other sports. Programming is FANTASTIC! I certainly hope that I will be able to do it for the rest of my life. More stuff! And even moar! Blah Blah Blah. Alright, now I'm bored.
Hello again. It's me.
I'm not sure what to say this time.
Oh well. I'm cool.
Well, it's time for PEACE OUT, GIRL SCOUT!
Get it? Ha ha!
Now I'm just really tired and want sleep.
Bed time. Good night!
Stuff happened! This week has been busy, but with other classes, so I haven't made a whole lot of improvements this week. There are a few things, however! I have two major accomplishments this week that I will share with you. First of all, I implemented having a title on my title screen! I looked up the logo for MORTAL KOMBAT, and used that as my base to create the sprites that make up PORTAL KOMBAT. It was kinda interesting finding how to use a grid of 8 x 8 pixels to make letters. In the end, I made each letter two sprites high, and one sprite wide. Except for the M. I had to stretch it into the boxes before it, so I made the blank sprites in between the words include a little bit of the K, with the next sprites over including the rest of the K and a bit of the O, and the next sprites over including the rest of the O and a piece of the M. That was fun. I'm pretty happy with the way I did the colors too. I had the top be one color and the bottom half another, and there were a few pixels in the middle section where I would mix the colors together. I think it looks really cool. There is an optimization I'm thinking about doing at some point. After I wrote out the code for assigning tile index and x and y coordinates to every individual sprite in the title, I realized that the lines of code are so similar, I could probably create an array of the sprites and use a loop to assign everything. I'll have to look into it, but I've already done the individual coding, so it's not of the utmost importance. Just a side project I might do later to make it look neater (not to mention shorter!).
My second thing to tell you about this week is someone in the class finally figured out how to clear the screen and redraw the background correctly. This was great because now, I can have no portals showing on the title screen! Then, I just redraw the screen and make the portals appear when I get to the actual game! I was pretty happy. I have run into a bit of an issue with clearing the portals off when I go back to the title screen, but I'm sure that's a simple fix. I'm so happy right now!
There is one thing I also wanted to briefly mention. I found out that there is a student expo going on in the commons on May 10th, and apparently, there aren't a whole lot of entries for it. There are cash prizes for winning certain categories, so I've decided I will try to get Portal Kombat entered into this contest. I feel pretty confident I can win the people's choice award if I can set everything up right. I'll have to talk to Matt Haas about a few things…
Unfortunately, I did a whole lot of nothing over break, so I don't have anything to put into this. :(
This week has been even less eventful than last week in terms of making improvements to Portal Kombat. So, you know how last week I said I'd got it all figured out? Well, unfortunately, there was one change that I'd made that I thought was harmless. When I came back to P K this week, I found that there was a bug somewhere in the choosing character stage. After a lot of trial and error, I discovered that the issue had something to do with the first player choosing. The second player could choose whoever they wanted, but the first player had to stick with the Fire Squid. After that, I discovered that it was more specific than that. The first player couldn't change character at all, including circling back to the Fire Squid, so I then knew that it had something to do with the logic of pushing the over key. As it turns out, I'd implemented an optimization suggested to me by Matt Haas that had a little too much math for one line. I've since decided that the changes necessary to make it manageable for one line aren't worth saving one line (which is all this optimization will be doing at this point). It was a really cool way of doing it, but in the end, it's not going to help much. Oh well. I've kept it (commented out) because I like it too much to take it out. And I have also added one more feature to the game. The names of the characters now appear under them when you have the arrow over them during the selection screen. That was fun! I ended up getting a few slight glitches, but I've worked them out. Now, I'm just trying to think of more things to add. I'll let you know if I do!
Also, do you remember how last week I said that I'd accidentally forgotten/procrastinated on our only project for this semester? Well, it turns out that I received a blessing from Haas. He extended the deadline to Thursday! With the extra time, I easily fully wrote and completed the files for the main puzzle as well as the bonus puzzle! But guess what happened? I decided to step away from it after I'd finished so then I could come back and do some final editing to make it look nice. Unfortunately, my mind did not return to pct0 until 1:30ish AM, and so I STILL ended up turning it in late. Since so much of my grade hangs on projects, and I just lost a significant portion of those points, I'm going to see if I can get a bonus project to make up for it. It's worth a shot! I kinda want some project with assembly since we haven't had a project on that, only some in class stuff where we were copying someone else's work. It would a be nice challenge to have to come up with something on my own.
Also, I did decide to actually look to see if Portal Kombat was an already used idea, and of course, it was. WHY CAN'T I COME UP WITH SOMETHING ORIGINAL!!! Apparently, there's some video or something called that. I hope I don't run into any copyright issues. Well, it's spelled Combat, so I think I'll be okay.
That's all for now, folks!
I actually don't have much to talk about this week. Probably the biggest thing development that I have to talk about is our most recent project. We were given a project called pct0 (practicing critical thinking). What this project entailed was where there was a long division problem where the numbers had all been replaced by a letter. Our task was to use pure logic and critical thinking to deduce which number was represented by which letter. I enjoyed the puzzles immensely, as I have always enjoyed doing puzzles that require critical thinking. I am really glad that I was able to watch Matt Haas do one out in the UNIX/LINUX class that I happened to be invading to use the computers for my NES ROM. The one done in class was a much more in depth one than the puzzle given for the project. By watching this one done out, I got a much better idea of how to attack a puzzle. The puzzle I was given for the actual credit wasn't that hard. I ended up finding the order in which five of the letters were supposed to be, and I also figured out which two letters were 0 and 1. The only hiccup along the way was when I accidentally subtracted incorrectly and said that 8 - 5 was 2. Thankfully, it was an easy fix as it didn't cause much devastation to my solution.
That being said, I unfortunately didn't spend enough time writing up my solution into a text file, and what I'd written down as I went was pretty minimal, so it didn't provide much of a narrative. So therefore, after a full day of going from one thing to the next, and then coming home and thinking that I can relax, I realized just after 11:00 that I had less than an hour to write up the solution in a text file. I got a decent way into it, but unfortunately, most of the actual figuring out of values came at the very end, so I only showed how I actually got 2 of the letters before I had to save and submit. I got it in with 7 seconds to spare.
That was kinda frustrating for me because that was the first time I'd been unable to turn in my best work due to a combination of procrastination and forgetfulness. I'd even thought about it during the day; I'd psyched myself up partway through the morning telling myself not to forget to work on it, but it apparently didn't completely work. I wonder if I can separately submit the bonus project… Even if it's a day late, I wonder if it will balance out the points I lose…
Anyway, the progress I've made for Portal Kombat is significant! I finally figured out a method for being able to allow the first player to do the FINISH HIM scene correctly. I'm pretty sure I was just overusing labels and gotos, so I fixed that and now it works perfectly! I also added in a feature that allows the winning player to reset the game where you can rechoose your character. After I'd done all that, I decided that it was high time I started putting in comments for my code. I got a little less than half way through that before I had to leave last class. My code is about 2500 lines, so there's a lot of commenting that needs to be done, especially with how I set up movement, attacking, and game phases. It's been really fun!
That's all for now, folks!
I'm going to be pretty brief here. There haven't been nearly as many developments in Portal Kombat this week as has been in the past few. This is largely due to the fact that all the changes I've been working on have been small. On top of this, a lot of times I've run into a problem somewhere and have had to spend hours trying to fix it. So, this is all I have accomplished so far. I first set up the code so that when player 1 lost all its life points (the swirl disappears!), they move to the center of the screen and the words, “FINISH HIM” appear above the sprite. I later added a few extra if statements so that it said “HER” instead of “HIM” for the Gal sprite. All this was relatively simple, and all I did was make it so that the computer checks if they are in the center of the screen, and if not, move them up, down, left, right, or some combination to get them closer each cycle. The sprites are also unresponsive to keyboard inputs at this point, so there isn't any interference. Once the loser is in the center of the screen, the winning player is unfrozen, and they can go deal one finishing blow to the loser. This is my favorite part. Depending on which way the winner was “facing” when they dealt the blow, the loser goes flying off the screen in a corresponding direction, and “P[# of winning player] WINS!” appears on the screen. One little bug that happens in this that I really like happens when the winner is facing right for the final blow. The losing sprite doesn't just fly off the screen; it goes into an endless loop of zipping around the screen! I am not getting rid of that.
And now we come to the part where I list what still needs to be done. Currently, the only change bug I know of right now that needs to be fixed is that when player 1 wins, there is no pause between the “FINISH HIM” appearing and the “P1 WINS!”. For some reason, it must be assigning the variable that keeps track of whether the sprite can move or not to the value that triggers the end screen. Or, it is just falling through somewhere. I've worked on that a while already, but I can't seem to find the problem. However, one problem I have found is that my code is so long that it can be hard to keep track of where everything is and what the path the computer takes is. So, I might need to clean up my code a little (or actually put in comments like I should be doing anyway…). Other than that, I really can't think of anything that I want to add to this. It's pretty sad knowing that I am almost done with this. And the semester. Oh dear, I need to stop thinking of depressing things. More next week!
That's all for now, folks!
There seems to be a pattern developing. Each Wednesday night, I go to bed, and just as I'm about to go to sleep, my mind suddenly reminds me that I haven't done the journal for the week. Upon realizing this, I jump out of bed and race to my computer and pray desperately that Matt Haas isn't sitting at his computer waiting for it to turn to the next day, because then I'd be in horrible trouble. Anyway, that pattern has continued. Maybe one of these times I'll just do the journal before it's due.
So, in class Thursday, we continued our adventure into hooking up wonderful devices to the raspberry pis and breadboards. This time, we decided to hook up a seven segment digital display (with a decimal point, so technically it is an eight segment display). Our goal was to get it hooked up so that we could write code that would display all the values for hex (0-9, a-f). One group did manage to get theirs working, however, the wiring has become so complicated on the boards at this point that it is difficult to keep everything straight, and thus a little frustration ensued in which people thought they had the displays hooked up properly (only to find that the program they wrote for it to do something completely different). One group did manage to get the display working perfectly, and the other two managed to overload the pis and make them shut off. :) I wonder what will be happening tomorrow (technically today now).
And now… PORTAL KOMBAT!!! This week, I struggled and worked hard to get some kind of progress with the workings of the game. Last week, I mentioned that I was in the midst of creating a title screen and had several bugs to work through. I am proud to say that the bugs related to the title screen have been completely worked out. Let me tell you all about it! For the title screen, even after hours of Matt also trying to solve it, we couldn't come to a point where the title screen could be exited and the game screen would come up correctly. So, I cheated my way out of it. I had the PPU draw the background for my game screen, and then I did my selection screen. This way, the background is already there, and when the players are done selecting, all I have to do is clear the extra sprites off! As for the game only ever selecting the guy sprite, this was due to one of the stupidest errors known to man: in the if statement regarding the selection, something in me thought it would be a good idea to put '=' instead of '==', so I was therefore assigning the sprite tile to the same sprite every time. How wonderful! Fortunately, though, that was an easy fix.
Unfortunately, now I have to take care of some of the logic errors in my game. Remember that scoring system I told you about in my last entry? Well, I created the sprites for those, and then decided that I'd make it a life bar instead (it might be something to do with the fact that Mortal Kombat uses health bars… probably just coincidence). So, I have a nice swirl that represents each character's life, and each time the sprite gets hit, the swirl decreases in size. Pretty sweet, huh? This is where the logic errors come in. I had to change the way I handled what happened after a hit to accommodate this addition, and now it only works under very specific conditions for player 2, and not at all for player 1. I'll definitely be working on that some more.
Once I get all that worked out, some of the things I still need to do are make a section of code that will run when the player loses their last bit of life, and therefore loses the game. I'm not sure, but maybe it will involve something with the words “FINISH HIM” on the screen (I'll have to do “HER” for the gal). That sounds really good, and I think I'm a genius for creating that unique phrase. I definitely came up with it on my own. And I think this is where I call it GE.
That's all for now, folks!
http://www.raspberry-pi-geek.com/var/rpi/storage/images/media/images/gpio/4965-1-eng-US/gpio_lightbox.png This is a picture corresponding to the pin layout for the raspberry pi.
http://wiringpi.com/pins/ This shows you the relation between the pin name and the gpio number.
To copy a file from one of the pi1b places to another, use scp -r pi1b_[number of place you want it from]:[the directory you want to copy] [location to copy to]
You will have to know the password for the server you are copying from.
Time for another last minute journal entry! This past Thursday, we did something I have never done in a class before: played with raspberry pis! Our stupendous professor, the great Matt Haas, was wondering what to have us do in terms of learning new material, when he realized that he'd wanted to have a raspberry pi set up. He also knew he had the smartest group of students he'd ever taught with him for comporg and sysprog, so he brought out some raspberry pis and a breadboard to go with each one. In addition, he brought out a whole bunch of LEDs, wires, and other miscellaneous things. He already had one system set up at his table, and after giving us the ability to write code to the raspberry pi, he instructed us to create a binary counter using the eight LEDs he had hooked up to the system. After we figured out which pin went to each light (by trial and error) we all managed to devise our own methods for making a binary counter (mine was definitely the best :) ). After that, there was a bit of time where we could mess around, so another student and I set up another system at one of the tables (since I have had previous experience with these, I helped the other student get a better understanding of the whole thing). Good thing the set up worked in the end. That would have been embarrassing if it hadn't. And that's all we did for that class! I can't wait for more fun in tomorrow's class!
Now, on to the part that I'm sure you are much more interested in: what progress have I made in PORTAL KOMBAT THIS WEEK?! That is a good question, so I'm glad you asked. I finally got around to creating the logic for the four sprite weapon of the Thing. The spear is now fully functional, and I also managed to rig up the collision detection for both players with all weapons! Oh yeah, I should probably say that I got all the weapons working for the second player as well. So, in short, I have a fully functional p v p game! However, that doesn't mean that I have a lot to do. There are so many things that I can do to continue to improve the game, and I also have two or three weeks left before the project is due, so I definitely will continue to add stuff. The first big change that I am adding to the game is a “Title Screen”. Well, at this point, it's less of a title screen and more of a screen where the players get to pick which characters they want to play as. To this point, I have been able to set it up so that the four character sprites appear in a row with an arrow above them. By pushing the right or left arrow key, the player can move the arrow to whichever character they would like to play as. Then, they hit the select button, and the current sprite will disappear, and will be saved as the player's choice. At least, that's how it's supposed to go.
What has happened so far is that there is a bug so that the only sprite to ever disappear is the guy, so I still have to fix that, and the arrow moving logic for p2 is still a little messed up. There are a few bugs that I will have to clean up. However, those bugs are not my greatest concern at the moment. For some reason, doing all that stuff and then going into the normal game doesn't work very well. What I mean by this is that now the screen for the actual game is completely messed up, so I'm not sure what is going on there. It works if I just skip the Title Screen part, but something in the Title Screen messes up the way the PPU creates the background for the level. Another bug I will have to fix.
Now, I can't leave without first mentioning how much I am in the debt of my illustrious professor, the great Matt Haas. When I first started making the Title Screen logic, nothing would appear. After working on it for at least fifteen minutes, I gave up and asked him for help, and within another half an hour, the problem had been solved. As it turns out, when you want to write stuff to the screen, you must make sure that the PPU is given permission (ResetScroll() and EnablePPU()). We also decided to just not use standard loops and instead made a label for the section we wanted to run over and over, and then had an if statement at the end that would tell the computer to goto the label. I've actually never used goto or labels in my own code before, so that was a good learning experience. Thanks, Matt!
I realize that I didn't mention any of my other mini-projects to work on to make my game better. The first one that I should work on is to fix a bug that is created if the player uses their weapon at the side of the screen. Currently, the weapon goes into an endless loop because the logic I currently have is never satisfied, so I definitely need to fix that. The next mini-project I have is to put a scoring system into the game so that players reach a point where there is a clear winner. I have created a little sprite to represent scoring, but I am holding off on incorporating it into the game until I have the whole selection/Title Screen bug worked out. Hopefully, that will be soon! That is all I can think of to talk about right now, so I think I will call that GE (Good Enough).
That's all for now, folks!
When you are in Mednafen, if you press Alt + d, it will bring up the debugger. Then, if you press 2 or 3, it will show you something else. 2 takes you to the sprite sheets currently in use. 3 shows you all the bytes in the game. If you happen to have a cheat sheet of what each byte represents (say you hypothetically had the link https://datacrystal.romhacking.net/wiki/Super_Mario_Bros.:RAM_map ), you can change things in the game. Some important ones: 016 is enemies, 039 toggles the power-up currently on screen, 704 is swim when set to 0, 754 is the size of the current player. 0 is big, 1 is small, and there are other values that do weird things. 756 is power-up state. 75A is lives, 75F and 760 represent world and level. 79F controls how long you will be invincible. There are many other fun things, but these are the ones that you will probably tinker with the most.
Update time! So, this week, we looked at how each byte in memory can control different parts of a game. As you can guess from the paragraph above, we did this on Super Mario Bros. (Oh, quick note, this may cut off abruptly, because I am writing this past 12, and I don't know if Matt is at this minute rolling everything back; if he does, this will be an interesting entry.) It was pretty cool to see a goomba just suddenly turn into a piranha plant. The best part was typing in random values for the world and level, so you would get worlds that aren't normally in the game, but are still playable. Some are extremely interesting. If at all possible, you should try it out! I also enjoyed making myself invincible for as long as I wanted; I suspect that this could make the levels boring if over used… Oh well!
Now, what have I accomplished in Portal Kombat this week? Well, I'm glad you asked. What I have done is get a major chunk of those aforementioned if statements done! For the first player, I have managed to get the Firesquid's weapons working perfectly well, in addition to the Guy and Gal's sword. I can't tell you how much time I spent troubleshooting why the weapon froze at a certain part or moved in the wrong direction. It was quite the challenge (and quite a lot of code) to be able to get the two sprites making up the sword to move in unison. Once I got all those sprites to work well for player one, I decided it would be a brilliant idea to just copy/paste those sections into the player 2 part. Well, it might still be, but I should probably make sure next time that I change all the player specific variables to the right person before trying it out next time. I ended up freezing player 1 while player 2's weapon was active because of this. More work! Yay!
But that's not all! As I hinted at above, the player 1 sprite now freezes whenever their weapon is in use. It makes sense to me! The longer your weapon, the longer you're stuck. I also have the basics of collision detection set up. At the moment, all it does is send player 2 straight to the point (100, 100). I've also realized that due to the way the code runs, player 1's stuff always goes first, so unless we go over synchronicity soon (maybe still not even then), player 1 will have a distinct advantage. Although, I could just overcome that with some more if statements… AHHHHH!! FRUSTRATION!!!!
That's all for now, folks!
Oh man. I completely forgot about my journals and now I'm over a week behind! Let's fix that…
Remember: If that value starts with a # then it means use the actual number. If the value doesn't have then # then it means use the value at that address. So LDA #$05 means load the value 5, LDA $0005 means load the value that is stored at address $0005.
Remember: to edit a sprites file, you do NOT wine the file itself. You must first wine the yychr.exe file, then open the file you want to edit.
So! What has been going on since my last entry? I unfortunately completely forgot that journals were a thing, so I didn't get the last done at all, and I even missed out on the bonus points for the break week journal. Such a waste! It's amazing how things can fall apart during and after break week.
Anyway, what we have been up to since I last made a real entry is making our own game! The second class after my last entry, our great professor Matt Haas decided that he would let us use the Tuesday classes to work on making our own games using the knowledge of C we have gained so far from class. We have until the next break week to accomplish this task (maybe after?). After that, we will have the same task, but we must then create the game using pure assembly! That sounds like it will be interesting.
What I have done so far in my game is to work on applying what I thought would be a good idea to have in that previous project I had: Portals! Since I didn't feel like coming up with my own boring game name, I decided to rip off a pre-existing one that is well established. Therefore, I present to you Portal Kombat. (I thought that was so clever. However, something between you and me, I've never actually played Mortal Kombat; I've only seen it played. However, it doesn't matter since I won't be expected to come up with anything near that complicated.) So far, I've managed to get the portal logic actually working! It took a while to set up, and required some generous assistance from the great Matt Haas, but sprites can now teleport from one portal to another (“randomly”) when they press the “A” button while hovering over one of the portals. Probably the most important thing I learned from the set up of this logic is that the point in which you increment a variable to keep track of where a sprite travels to. That was a the biggest challenge I ran into there, because the way I was originally doing it caused my sprite to only ever teleport to the first or second portal. It also caused there to be a significant delay between the time when I could teleport. But that's all out of the way! Thanks, Matt!
Now, you may have noticed how I mentioned sprites. I actually made my own sprites! Using yychr and wine, I took a sprite file and added four different characters and weapons to go with each of those characters. Two of the weapons will be able to go in all four major directions, but the longest will only go left and right. The sprites (in order of creation) are the Fire Squid, the Guy, the Gal, and the Thing (I ran out of super creative names for this one). Their corresponding weapons are fire (NO REALLY?!?!?!?!?!), sword (for guy AND gal), and spear (the long weapon). I may change the spear only going left and right when I can test how this affects the Thing's usability compared to the other characters. I want it to be mostly fair. Although, if that character is the hardest to win as, maybe it can be a show of skill to be able to win with that character. Okay, I'm just going to leave it how it is then!
Now, that I have the fun stuff out of the way, it's time to work on the hard stuff: collision detection and making the weapons do their thing! I can't tell you how many hours I spent trying to make a while loop to control making the weapon go out and back when the “B” button was pressed, but this just didn't work because then it stopped everything else from working. Yeah, I have to figure out how to make a weapon work, keep only the sprite using the weapon from moving, and detect whether the weapon touches the other sprite. THIS IS GOING TO BE SO MUCH FUN COMING UP WITH ALL THOSE IF STATEMENTS!! I CAN'T WAIT!!!! I think I have an idea of how to do it, but I'm going to be spending a lot of time working it out… Oh boy. Oh well. You can't have a fun video game without a whole lot of work! I just hope I can actually do it. I have faith. LET'S DO THIS!!!
That's all for now, folks!
This week wasn't extremely eventful. In class, we did do some really interesting things in class! We've actually started to take the first few steps towards making a real working game! This built on what we did last week. If you read my previous journal entry, you'll see that we were able to start making a usable second sprite that you have the option to change the color of. Now, the obvious next step is to turn this beautiful looking thing into a shooting game! It was pretty cool and interesting to be able to figure out how to make a character (the alphanumerical characters) start out at the position of the sprite currently using it and move in the desired direction. Now, after this, different people took different paths. After all, there are so many different ways to get creative with this game. My professor decided to make it so that the projectile for one of the players got bigger after a certain distance; one of my classmates made one players projectile fast, while the sprite moved slow, but reversed that for the other sprite. Another classmate made it so that there was a score counter, and if the projectile entered the space of the other sprite, a score counter would change.
I JUST HAD A BRILLIANT IDEA! Using the same logic I used to allow sprites to screen clip, what if I made portals on the screen? THAT WOULD BE SO COOL! I think it would be easier to make a method where you could pass the current location and the current sprite, and the method would return the new location! I really want to do this now… Maybe next week during break.
That's all for now, folks!
NTSC and PAL are display systems for televisions, and some countries will use one, while others on a different continent will use another.
“extern” can be used at the front of a variable to basically say “Hey, this variable exists, but I haven't declared it yet.” EG extern uint8_t FrameCount;
This week, we have worked on many different things. Last week, which was actually part of this current Haasian week, we messed around with making words appear on the screen! Kinda like last week, but more! Instead of having the letters all boring and unchanging, we made a pretty cool modification: the color of the letters in the words alternated between three different colors, and it kinda had a conveyor belt look to it. But wait! There's more! After that, our illustrious professor Matthew Haas issued a challenge: could we figure out how to make an additional line of words appear? That definitely wasn't in the tutorial. However, by studying the logic used to create the original line of words, one could indeed figure out how to add a second line of letters to the screen! And if one decided to add the letters in the same section as the pre-existing line, the shifting colors transferred to the new line as well. It took me a little bit to figure out how to do all this, but I was eventually successful in my endeavor. I am also pretty happy that I can look at my stuff at home. It's pretty nice to be able to show off my work to my family and to make myself look like a total wizard. :)
Things only got better at the next class. We began working with sprites! These are basically 2-D figures that can represent characters or objects and often have multiple poses that can be triggered by different events. (In Systems Programming, we've used a cat as our sprite, and there were different poses to make it look like it was walking in different directions depending on how what arrow key you pressed. I'm sure Mario has a few different poses to represent walking, jumping, and DYING!!! Often a group of sprite poses are shown on a “sprite sheet”.) We figured out how to control our sprite with keys, and then Matt the Great issued another challenge: could we create a second sprite and make it a different color than the one that already existed? As it turned out, the making of a second sprite wasn't too difficult, but the changing of the color proved to be a difficult undertaking for someone with the limited knowledge I have. Thankfully, I received mercy from my fabulous teacher. By using some bitwise logic to slightly modify the attributes portion of the struct controlling the sprite, we were able to change the color of the second sprite. In addition to that, we added some very patriotic red, white, and blue borders around the edge of the screen! Now we just need to build walls to protect those borders…
I can't wait to see what new adventures we will embark on next! All we've accomplished, and it's only the third week! LET'S DO THIS!!!
That's all for now, folks!
In the olden days, the system couldn't use all colors it knew. If it had a memory of 24-bit basis but only had access to 8-bits at a time, it would mix colors to stay in the limit. The system could recognize say several thousand colors, but could only render 256 at a time.
Accessing RAM has a cost. Using registers is better!
Different systems are either big endian or little endian; this determines whether the upper byte or lower byte is entered first. A way to see this is echo “ABCDE” > filething od (octal dump) -x filething. It shows the bytes as 4241 4443 0a45 (BA DC enterE). lab46 is little endian! That is so cool…
It took all class to reach the point where we could make “Hello World!” appear on a screen using a NES simulator. Normally, it would take one line to do that in C, but it took approximately 43 here. Also, I decided to write “World Up!” instead because everyone writes “Hello World”, so why should I do what everyone else does? :)
This was the place I got it from: https://timcheeseman.com/nesdev/2016/01/18/hello-world-part-one.html
When having .h and connected files, you will need to compile each .c file, but not the .h files. However, you must first do compiling (same thing, but with -c instead of -o). Then you compile the main file normally.
If you want to compile a C program, but you want to stop when the file has been made into assembly language, you can do gcc -S file.c. This will give you file.s.
lda - load accumulator (loads from memory and stores in a register) sta - store accumulator (loads from register and stores in memory) These are the basic math things in the 6502
bcs - Branch if Carry is Set This is basically an if statement at a lower level. It decides whether to branch or to continue on.
jmp - unconditional jump. Basically goto from C. Most common jmp _main (jump to the start of the program!).
There are three registers. One to do basically everything, and then two more for storing random stuff.
A quick note: I really enjoy the fact that I can play Super Mario Bros. through this class. I will continue to use it for years to come! It is pretty cool to be able to have immediate access to a game that will live forever in the memory of gamers everywhere. My day was made when Matt brought out a box of Nintendo Entertainment System controllers with USB cords, so that I could play the game with its original setup! I found that holding the remote in a rather unconventional way was the most comfortable for me, but maybe once I get better at the game I'll see the advantages of holding it in the standard fashion. I am also super proud that I can make it to world 8-1 with no problem at this point. Now, I haven't quite yet managed to get past that world yet, but I will eventually! I will bring ruin upon Bowser's head! He will go back to the lava from whence he came!
That's all for now, folks!
Fetch - Grabs the instruction from an address in memory Decode - Figures out what it just fetched. Execute - The circuitry necessary to carry out the instructions is activated. Store - The results are stored somewhere.
^ That is the execution of an instruction.
Complex Instruction Set Code (CISC) Basically, putting a whole bunch of functions together or having twenty different ways to do one task.
RISC (Reduced ISC) There was one way of doing each thing, and you had to call individual tasks separately.
ALU (Arithmetic Learning Unit)m, RA (Register Array)m, CU (Control Unit)