belial wrote:

I know the problem . It took me months to write this tutorial because its so boring to fire on latex after your regular work, create the figures, etc.

At the risk of losing face, what does "fire on latex" mean? I would google this but it seems potentially NSFW.

It means putting on your rubber suit and being kinky.

...

Actually, LaTeX is a document format that is popular in the academic world.

http://www.latex-project.org/

nitro2k01 wrote:

Maybe I should get my ass off the couch and actually write a tutorial myself. I've been wanting to do this for a while

I know the problem . It took me months to write this tutorial because its so boring to fire on latex after your regular work, create the figures, etc.

At the risk of losing face, what does "fire on latex" mean? I would google this but it seems potentially NSFW.

http://gameboy.mongenel.com/asmschool.html

this site helped me alot when I moved into the gb asm arena.

ohhh..... thanx!
bookmarked for this weekend ;D

nitro2k01 wrote:

Maybe I should get my ass off the couch and actually write a tutorial myself.

I would love to see one. I'm just about to start off a GB programming project myself and have only limited knowledge of assembler programming.
Btw, did you have some documents up on 8bc, the gameboygenius site, on GB programming? If so, are they up on another site these days?

http://gameboy.mongenel.com/asmschool.html

this site helped me alot when I moved into the gb asm arena.

And of course, as I said before:
http://gameboy.mongenel.com/  <- and click GBC ASMSchool

Maybe I should get my ass off the couch and actually write a tutorial myself.

I would love to see one. I'm just about to start off a GB programming project myself and have only limited knowledge of assembler programming.
Btw, did you have some documents up on 8bc, the gameboygenius site, on GB programming? If so, are they up on another site these days?

Maybe I should get my ass off the couch and actually write a tutorial myself. I've been wanting to do this for a while

I know the problem . It took me months to write this tutorial because its so boring to fire on latex after your regular work, create the figures, etc.

nitro2k01 wrote:

An integer table, even 16-bit integer, is better than that float table

I bet i misunderstand you and maybe this should be discussed somewhere else, but why using an integer table? An integer table of sine values would contain exactly 3 entries {-1, 0 1}.

Oh, you need to scale it, of course. If you want an object to swing 40 pixels from side to side in a sinusoidal curve, you could pre-calculate y=int(20*sin(x)). Actually you could probably get away with calculating 10*sin(x) and multiplying the table values by 2.

Which brings me to another point... Integer multiplication and even division by 2 and multiples of 2 is cheap. It can be easily written as a shift operation. y=4*x is equivalent to y=x<<2 for example.

Another trick, which I don't think the C compiler has support for, is fixed-point arithmetic. You could for example define that in an 8-bit number, the lower two bits are the decimal part and the upper six bits are the integer part. So, for example, you could represent a number like 5.75 without rounding:

Bin: 0001 01.11

This would of course be stored in an 8-bit register as hex: $17 (Bin: 00010111)
The logic is that bits below decimal point get the values 1/2, 1/4, 1/8 etc.

Adding two of these numbers works all the same like any other number of that bit size. If you multiply two numbers fixed-point numbers however, you must realign the number. Consider that you multiply 2*3 in the notation above:

"2.00" = Bin: 0000 10.00 = Hex: $08
"3.00" = Bin: 0000 11.00 = Hex: $0C

$08 * $0C = $60
Bin: 0110 0000 = Hex: $60

Here you need to divide by 4, or as it can also be done, shift right twice, to get the correct answer:

Bin: 0001 10.00 = "6.00"

However, when you multiply fixed-point * actual integer, you don't need the realignment step.

I think any tutorial to programming an 8-bit CPU should talk about binary numbers and 8-bit math tricks. Not as a thing that you need to go through by necessity, but as something that is actually useful. But maybe that scares people off?

Oh, and you're right that there's seems to be a lack of GB tutorial. There's one though...
http://gameboy.mongenel.com/ <- and click GBC ASMSchool
It's geared towards ASM however. Which I personally think is the way to go in the long run.

Maybe I should get my ass off the couch and actually write a tutorial myself. I've been wanting to do this for a while, but lazy and stupid in the same as being an elitist dickhead is almost a guarantee that you'll never manage to write something you're satisfied with.

Just a few words: This document wasn't written as a "school project" . It started it when i created the homebrew cartridge and wanted to document it. In the Atari 2600 homebrew scene is a big community named "atariage.com" with lots of beginner friendly tutorials. On the game boy side, those beginner tutorials are missung. All you can do is to google and find technical documentation or dead links. So i decided to create a tutorial which collects all the useful links and ideas i have found.

I bet i misunderstand you and maybe this should be discussed somewhere else, but why using an integer table? An integer table of sine values would contain exactly 3 entries {-1, 0 1}.

No problem, its not the first paper review im reading about my stuff . Ill try to adept your improvoments.

Now I'm going to sound like a massive dick, but I don't like this paper at all...

No not at all (at least not to me)!
I'm not really knowledgeable on this sort of thing, I just took a quick look at it and was curious what relevance it might have here. Something for the pros and people who might use it to discuss.

It's actually mostly factually correct as far as I could tell when skimming it through, but it feels very rushed. There are a few couple of small things that are wrong, like calling the MBC BSC, but that less important. But what I'm more worried about is that I'm wondering if the complete noob is actually going to learn anything substantial from the paper. It's written in such a way that I'm getting the feeling it was made to meet a school deadline, not out of a genuine will to teach. A lot of things could be probably be described in more understandable ways.

I'm bothered by the theory sections about transistor/logic and NTSC. They don't really fit in. The transistor/logic section could probably be scrapped. If you know about these things, you do. If you don't, that short text isn't going to make much of a difference for you. The NTSC section could probably be replaced with an actual diagram of how the screen is drawn, and when you can and can't write to it.

Then there's the coding guidelines. The first 3 points are sound advice, but last one isn't really. The <=, < etc operators typically have no or a very small overhead compared to == and !=. we only have a limited time window to perform our calculations (vertical synchronisation phase) <- That's not really correct. Just because you can't write freely to the display during most of the time doesn't mean you can't do math. And why make a float table of sine values? An integer table, even 16-bit integer, is better than that float table. And even so, theres no explanation on how you're actually supposed to use the lookup table.

The whole idea that the Gameboy is well documented but it is difficult to collect all the distributed informations on the internet. is largely untrue. There are a couple of good collected sources. Most importantly PANDocs which is a collection of a lot of small documents (some of them quoted in the paper) that was assembled about 10 years ago. It's both more informative and accurate than the quoted sources. (No undocumented GB cart pins etc...) Then there's devrs.com/gb which has many dead links nowadays but is still a good starting place. A little more research would've revealed those.

The paper doesn't at all mention that there are in fact commercial flashcarts for sale to this date. See here for example.

So uhm yeah... I'm sorry for the complete smackdown, but I honestly think a lot of things in the paper could have been better. Forward this post to Belial (or maybe not.)

http://belial.blarzwurst.de/gbpaper/paper.pdf

Someone can repost this under tutorials or move it there if it makes sense to. I didn't, because it's not mine and I can't vouch for all of the content. Just figured I'd post it here for people to check out first! He warns that there's probably typos or some grammatical errors since English isn't his first language. He also says suggestions are welcome.