HTPTSMS Part 6: Labels

Okay, I'm a little timed right now, but let's see what all I can get done.

So, some of you probably know what labels are, but some don't. They look like this:
IAmALabel:
and are handy ways to jump and call places in memory, or at times just for organization.

What's so handy about them, anyway?

Well, before labels were around, programmers had to figure out the points in memory on their own, and shift them around whenever any new code was added in. So basically you'd have to figure out what call $43 meant, instead of call DoThisAndThat.

Another reason labels are useful, is because of sections. See, a section in WLA DX would be isolated and untouched if it didn't have any labels in it, because that's how the section communicates with other ones. So this:

.section "lfvn sljcnfvglknv" free
.db $44 $44 $44
.ends

Wouldn't mean anything.

Doing this, however:

call Boogie
.section "???" free
Boogie:
.db $44 $44 $44
ret
.ends

Would mean something, since the code inside the section is being accessed.

Well, that's the end of this part. Sorry for its short length, but I'm in a bit of a hurry and if I were to wait then this part would be here 12 hours from now.

HTPTSMS Part 5: jp's 'n jr's ('n more)

Woohoo! I'm happy that finally looking through all that code is over with, and now we can really go in depth.

So, about the title...you may have noticed that at the beginning of the code, I jumped with jp main. Everywhere else, though, I jumped with jr. What's the difference between them, anyway?

Well, it actually has to do with spacing. You see, if a point in memory is 128 bytes forward or behind the point in code you're in, then you can use jr. If it's further away, then you have to use jp.

The reason for this is because jp is jump, and jr is jump relative. While jp uses two bytes for the location (which can contain values up to 65535,) jr is smaller, and only uses one byte (up to 255). So that's out of the way...

What about call, though? Oh, wait, I didn't even tell you about call, did I? It's sort of a modified version of jp. You see, just like a higher language such as C, z80 assembly can have functions. The standard function would go like this.

Name:
; code
ret

Name is the label, so you'd call the function using call Name. The code goes in the middle, and ret is what signals that the function is over. There's no call relative, although if there were one it wouldn't be very useful.

So that's all you really need to know about jr's, jp's, and calls. That's not all I wanted to cover, though. Another concept I wanted to get out of the way, is numbers.

Did you notice that I kept saying $0404 and %01010101? What do these mean? Well, they're actually WLA syntax. You see, putting $ before a number makes it hexadecimal. Hex is basically the counting system that goes 0-9,a-f,10-19,1a-1f, and so on.

The percentage symbol makes binary. Binary is what computers run off of on the lowest of levels, and can only contain two values per bit: 1 and 0. A bit is the smallest piece of memory in existence, and there's 8 bits in a byte. That's why when you usually see binary, it's in sets of 8.

That's pretty much everything I wanted to get done in this little lesson. Next time we'll be covering...I don't know.

HTPTSMS Part 4: A Look Into The Depths [2]

Hope you got a good rest since last time, because we're going to keep it up with the coding.

What's going on, is we're loading hl with $c000, the VDP location for the palette. What we're doing, is we are loading a with hl's lower digits ($00) and throwing them at the VDP, then doing the same with the higher bits ($C0). Note that we had to throw them in reverse order.

This is the same as what we did at some point last time when initializing the VDP. Remember that $be is the port for writing, $bf for setting the address.

What the loop is doing, is it's making a label called -. This is an anonymous label, which we'll cover later on. a is treating hl's value like a point in memory, and getting data from that point. It then feeds the data to the VDP. hl is incremented (hl=hl+1,) bc is decremented (bc=bc-1,) and what happens next is a bit complicated. A takes b's value, and or c basically says, "Check if both a and c are equal to 0". The flag z means true, the flag nz means false. jr nz, - is saying "If not true, go back to -". It's a good way to check if bc is 0.

The reason we're loading hl with $3800|$4000, is because the first two bits of h have to be both 1's. %11000000 = $40, so or'ing them makes the first two bits of 38 equal to 1, turning it to $7800.
There's more than one reason we can't use otir. The text data is set as each letter is one byte, but the screen expects two bytes per tile. otir wouldn't give that extra 00 between each letter, and so it's useless in this case. We could just do it on our own with .asc "H e l l o ! " but it isn't good looking.
So, instead we had to make a loop. It's similar to before, except we also have to throw an extra zero at the VDP. To do this, we set a to 0. A fast way to do this is xor a, which compares a with the accumulator (a, so...itself) and sets it to 0 if it's equal. djnz - means "Decrement b, and if it isn't zero then go back to -".

This is something we'll cover later on, when we actually look at the VDP init data.

This is simple. Enables interrupts, waits a frame and jumps back just to wait another frame.

There's nothing interesting right here. I'm just requiring myself to post all the code.

I had covered earlier on that you should have some fun with the text, so if you weren't paying attention, then hopefully you are now.

While most of this is technical stuff that you shouldn't really worry about, what you should pay attention to is .db 100000,$81. Later on when we wanted to turn the screen on, we set the second bit, in the form of loading a with %01100000 and outing it to $bf, then loading a with $81 and outing it again. This is a more interesting part of how the VDP works. Also notice that VBlank interrupts are on. If they weren't then halt wouldn't wait a frame, and instead would wait for you to manually create an interrupt.

Notice that I was able to get the font data's size with a simple fsize. That's an advantage to the use of raw binary data. .ends is just a directive to end a section.

Yup, that's it. We've looked through the entire source. Before we begin making a slightly more advanced game, however, we'll need to learn some syntax! That will begin next time, in HTPTSMS Part 5: jp's 'n' jr's. Cya then.

HTPTSMS Part 4: A Look Into The Depths [1]

Keep that source file open, because it's time we dive into what all is going on in the code!

Now, I may have placed almost 100 lines of comments inside the code, but there's a large change you still don't understand exactly what's going on in some places. So let's go piece by piece. You most likely won't need to read every little bit of this post, but if there's something you don't understand then this will be a nice place to head back to for tips.

I had started off a little lazy, without thinking to give too good an explanation of what goes on inside the memory map and rom bank map. So here's a little bit of information.
See, the rom is built up of banks containing data. You can only see so much of one bank at a time on the SMS, which is why later on you'll be learning the concept of paging. Each bank comes with the exact same slots, located in the memory map. Slot 0 is the main code, and slot 1 is the ram built into the console. You'll learn why ram gets its own slot later on.

We won't be getting into this, as, well, it's true. SDSC is something that was originally made on the SMSPower forums, and these days people use it just to stay organized. If you make a rom smaller than 32 kilobytes, you can't use an .sdsctag, which is fine.

This clearly wasn't explained too well. See, the standard ASCII table goes from " " to "~". Our font does the same thing. Since " " is equal to 0 in .db (raw data) format and "!" is equal to 1, we can easily say .asc "Hi" and it would be automatically translated to its corresponding numerical values. Isn't WLA wonderful sometimes?

There isn't much to say about this, as it's true. .bank 0 slot 0 puts the following code in bank 0 and slot 0. Need I say more?

Now THIS is one big chunk of data. .org $0 puts the following code at location 0, which is simple. di does what the comments say. Keep in mind, however, that this is only true if VBlank interrupts are turned on. We'll cover this later on.

This is a little complicated. Remember earlier, when we used ld sp, $dff0? Well, $dff0 is the location where af's data will be pushed to, and popped back out of. It's called the stack, and man will it come in handy. $bf is the hardware port for the VDP's control, and it's where interrupts are basically made. in a,[$bf] is placing the port's data into a, which tells the VDP that the interrupt has been handled. Not doing this could cause bad things to happen, but I'd rather you try that out on your own time.

Ever wonder what happens when you press the pause button on the SMS? Me neither. What happens, though, is that the system goes to $66, and placing retn there is basically saying to go back to the code that was being run before. So, basically nothing.

There's not much to say about this. It's true.

Do you recognize $bf from earlier? Yup, I know I do. It's VDP stuff. VDPInitEnd-VDPInit basically subtracts the end of the init code from the beginning, which loads b with the exact amount of bytes that need to be loaded into the hardware port $bf.


Is anyone else kind of coded out right now? I know I am, so let's go ahead and split this up into 2 parts. I suggest you read over this a few times. Anyway, see you next time, in HTPTSMS Part 4: A Look Into The Depths [2].

HTPTSMS Part 3: What is This!?

Greetings. I find myself writing this as a storm brews on outside. Apparently my dog hates storms, as he despises me, yet he's laying on my bed...

Okay, enough personal stuff. Let's get to coding. So, on the last post I threw a bunch of stuff at you, like a text editor, an assembler...all that good stuff. Now that you have your first piece of code in hand, however, shouldn't we be moving on to the actual code?

So, if you're using ConTEXT and followed the steps correctly, then you should be able to open up the code in it and see some pretty colors on the text. Awesome, I know. But the question is, how do we turn this thing into a game?

Simple! Go to Options > Environment Options, and a little box should pop up. Go to "Execute Keys", press Add, and type in "s,asm,inc,z80". Those are the file types we'll usually be working with.
Now the window should look like this:

So that's just wonderful. Now let's try and set up the actual compile button.

Simply copy off of this photo down here for this one.

If you do everything correctly, then just press OK, open up the code file, press F9, and voila.

But wait a second...How are we going to open up an SMS file??? We don't have an emulator...
Yup, that's right, because I didn't give you one yet. Go ahead and get MEKA here.

So tell Windows that you want to open up the SMS file with MEKA, and if all goes well, the game screen should look like this:

What if it didn't compile, though? Well, the only big mistake I can think of is that you didn't read in the last part about editing the compile.bat file. Open it up in Notepad, and make sure that the paths to your WLA binaries are both correct. Message me at nicklausw@programmer.net if you can't quite figure things out.

So now we've gotten a good code file working. There's something I would like you to try. Go to this area in the code (line 186):

And change "Hi, retro friends!" to whatever you want it to be. It's always fun to mess around with the classic hello world examples.

Anyway, that's all for this part! Next time, we'll be looking further into the code, and seeing what all is going on. Until then, cya.

HTPTSMS Part 2: Let's Get Rollin'

Alright, let's get fired up, because this is the time when we get rolling! Get to learn some good ol' programming aspects, get our first program running, and all of that.

First off, though...what on earth should we use to do it?

Well, let's go ahead and get this out of the way.

The Text Editor

You're gonna want a good one. In this tutorial, we're going to be setting up ConTEXT. You can get it here.
There's obviously alternatives out there, but I don't plan on going over them.

The Assembler

Wait...assembler? What is that? Well, basically it's what takes our code and turns it into a big fat ROM for us to play with. Now, I have some binaries for download here, but if you're using a different OS then you'll have to build from source. The GitHub page is here.

The Text Highlighter

Yes, it's never fun to look at code when it's all in one color. That's what this highlighter is for. Go to where you installed ConTEXT, and place this in the Highlighters folder.

The Batch File

Um, what? I'm sure most of you are wondering what I am talking about. Well, the batch file is basically what we'll use to compile our code. Download mine here.
BEFORE YOU CONTINUE! Right click on the batch file, click Edit, and where it shows in quotes where WLA-DX is located, change it so that it shows where your WLA DX binaries are located, or else nothing will work right.

Our first piece of code

Yup, it's time to look at our first ever piece of code. Here it is!

What do I do with all of this!?

Well, that's what we'll be covering next time, in HTPTSMS Part 3. See you there.

HTPTSMS Part 1: What is a Sega Master System!?

Well, isn't this ironic. At the end of the intro, I wrote "coming soon", yet already I'm posting this.

Ah, that title...it contains a question that not everyone has to ask. I, however, am someone who had to ask this, as when trying to get into old game programming, the Sega Master System sounded like an old pile of junk to me! As, well, I'm not someone who has some heart-warming story of how I grew up with my ol' Sega System. What can I say? I'm a 2000's kid.

So, let's go ahead and answer this question.

The Sega Master System was originally released in Japan as the Sega Mark III, but proceeded to be released overseas in order to further compete with Nintendo's NES. In North America, Sega fell behind by far with its rival taking over 90% of the market. Europe and Brazil, however, had something much different going on: Sega took the market by storm! Master Systems were selling left and right, with Nintendo having no idea what to do about it.

So that's the story of the console's early years. Of course, its history stretches on much further, but that's not really the point of this post. I never was one for little pieces of trivia, anyway.

Yes, I know the real reason you all are here, and it's because you want to learn how to program for this beast. So let's go ahead and dig into the lowest of technical aspects here and find out what this thing's processor is.

Yup, this ol' thing uses the Zilog Z80 processor. The processor is basically what gets everything going on a machine. So, my computer's Intel Pentium is to the Master System's Zilog.

Unless you're playing around with hardware, though, then this is information that isn't considered entirely needed to work with.

So now we know a little bit about what this thing works on, but how are we going to program it? Well, no stalling, let's jump right on into it in part 2 of HTPTSMS!

So You Want to Learn to Program a Game?

Hello, everyone reading this. I'm NicklausW, a high school freshman with nothing better to do than to just make this post. Yup, that's actually a good summary of myself.
Anyway, the reason you're here is probably because of the title: you want to learn how to program, and how to be good at it.

There's actually lots of tutorials like this out there that show how to answer that question, which is usually to teach you some C++ or Visual Basic or something like that. Are video games actually made that way these days? Usually, yes. There's been a strong foundation of programming languages set out there for you to use, yet no one feels the need to think back on this question: How did they make games before all of this was around?

Well, my dear friends, that's what makes this little blog special. We aren't just going to be making a game for a game system; instead, we're going to set a strong foundation for ourselves that so many programmers had to set on their own back in the day. Most people who can comprehend how stuff like this works (arrogance aside) don't have the time on their hands to make a tutorial out of it, however. That's why I've decided to give in a quick helping hand in attempts to expand this retro community of game devs.

So come on in and get some fresh air, because we're about to learn some new stuff, coming soon in the first part of NicklausW's How to Program the SMS.