Game Boy

[aprentice]

Yes, it helped a great deal, thank you very much! With that information, I solved my Earthworm Jim and Super Mario Land 2 problems! :happy: SML2 freezes before the first level at the moment, but that should be nothing now that I solved that problem(Which I'd rather not mention, as it's pretty embarassing :blush:.) Once again, thank you, aprentice. That's been a plague on me for weeks!

no problem, glad i could help

 

[ShizZy]

Thanks for checking it over bcrew. One little error which I noticed was that my 8bit registers weren't even pointing to the 16bit ones :blush: That could cause a problem.

Anyways, fixed that. Finished my interpreter (well, I'm sure it only half works... but hopefully enough of it is right to run something). Interrupts should be mostly set. Last thing before I test it is finishing the timings, and doing the scanline drawing.

Anyone have any tips or good documents for these? I havn't really quite grasped the concept of getting and displaying images from the rom, this is one of the things which gave me a lot of trouble with my chip8 emu.


Big thanks-

 

[bcrew1375]

Okay, drawing can be a little confusing. Each 8x8 tile is 16 bytes(2-bit color encoding). Okay, first you need to get a tile number from the Tile Map Table(0x9800 or 0x9C00). You then use that tile number as an offset from the tile data table at either 0x8000 or 0x8800(0x8000 is 0 to 255, 0x8800 is -127 to 128). Make the tile number unsigned or signed depending on the Tile Data Table location, then multiply the number by 16 and add it to the Tile Data Table address(example: tile number is 240. 0x8000 + (240 * 16) = 0x8F00). Each line of the tile is made up of 2 bytes. You take the bits in the first byte and add them with the bits in the second byte. If a bit in the first byte is on, it is 1. If a bit is on in the second byte is on, it is 2. So, if bit 0 of byte 1 is on, and bit 0 of byte 2 is off, the value is 1. If bit 0 of byte 1 is off, and bit 0 of byte 2 is on, the value is 2. If both are on, it's 3. This value is used with the BGP I/O register. If it 3, the color is gotten from bits 6-7. If it is 2, bits 4-5. 1 is bits 2-3. 0 is bits 0-1. The value you get(0-3) determines the color to draw. 0 is white, 1 is light grey, 2 is dark grey, and 3 is black. Hope that was clear That should be everything you need to know starting out.

 

[ShizZy]

That's a mouthful :bouncy: Thank you though - that makes a whole lot more sense now. And things like whether to use the 0x8000 or the 0x8800 location or what size the sprite is can be gotten from the bits of the LCDC, correct? Does all of this also apply the same for backgrounds? Thanks!

 

[bcrew1375]

ShizZie: Yes and yes.

Dark Stalker: I tried lameboy out. I notice that the Win32 version is horribly slow(as in, won't run full speed on a 2.0 GHz.) whenever dealing with sprites. The Super Mario Land 2 map or just about any part of Zelda: Link's Awakening are good examples.

I noticed that Dark Stalker and my emulator run the Interrupts Demo the same, but it's different than NO$GMB or VisualBoy Advance. How about you aprentice, what does the Interrupt Demo look like?

 

[aprentice]

ShizZie: Yes and yes.

Dark Stalker: I tried lameboy out. I notice that the Win32 version is horribly slow(as in, won't run full speed on a 2.0 GHz.) whenever dealing with sprites. The Super Mario Land 2 map or just about any part of Zelda: Link's Awakening are good examples.

I noticed that Dark Stalker and my emulator run the Interrupts Demo the same, but it's different than NO$GMB or VisualBoy Advance. How about you aprentice, what does the Interrupt Demo look like?

it looks exactly like the vba one except mine has the garbage on the bottom of the screen too and not only the top...

 

[Dark Stalker]

Dark Stalker: I tried lameboy out. I notice that the Win32 version is horribly slow(as in, won't run full speed on a 2.0 GHz.) whenever dealing with sprites. The Super Mario Land 2 map or just about any part of Zelda: Link's Awakening are good examples.

That seems a bit strange, but I've only tested it in vmware actually (and it seemed to run 3-4 times normal speed in GBC-games iirc). I've actually never experienced any notable slowdown related to sprites in any version. You could try running it with 16-bit colours. Anyway, the upcoming release will likely improve on this, and more at that...

I'm not sure if this is correct but i guess it goes to 1 at pc 0x3ac3, but before it did that for me, it ran a few frames with the lcdc screen off so ly stayed at 0 for awhile, and ly starts at 144 on boot. hope this helps

This reminds me that I forgot to mention that I was wrong about not setting modes while the screen is disabled. You are actually supposed to set them, as you would for a normal non-vblank line it seems. Bubsy 2 won't run if you fail to do this.

 

[HyperHacker]

The slowdown might be due to hardware incompatibility or system settings. For example, it might not be able to do whatever it would normally do for video and have to use a slower method instead. (Ever try using SetPixel? Slooooooow. )

 

[aprentice]

This reminds me that I forgot to mention that I was wrong about not setting modes while the screen is disabled. You are actually supposed to set them, as you would for a normal non-vblank line it seems. Bubsy 2 won't run if you fail to do this.

So whats the difference between screen mode on and off besides the screen being actually off? Got any other secrets you hiding as well?

 

[Dark Stalker]

Like you said LY stays at 0, and there's no LYC of course. As for secrets, there's way too many to list them all

Any specific game(s) you've got problems with?

 

[ShizZy]

My core is done Well, done *enough*. I still don't have cartridges coded, and my memory write function is little more than "memory[address]=value;", but technically, it should be enough to boot a few simple demos, I'd imagine. So now I'm nitpicking and trying to find our where all my typos are, based on how badly it loads the roms. None have worked yet, but I'm getting the first good chunk of opcodes right, so I'm assuming it's only a matter of time before I fix enough things for something to give me some results.

Edit: I'm getting very excited. Just fixed another major error, and now I'm getting through many many more opcodes properly hone:

 

[bcrew1375]

Congratulations, ShizZie! I remember getting very excited when I saw my first demo. I couldn't believe I'd actually made it work! :happy: In case you're interested, the first one to show anything for me was "Big Scroller Demo."

 

[HyperHacker]

Am I the only one whose first game to run was commercial? (Tetris; not the first to actually run, but the first to properly display graphics. One attempt after the first to display any sort of recognizeable graphics, which was also Tetris but with lines on the screen.)

I oughta start working on this again. <_<

 

[aprentice]

Am I the only one whose first game to run was commercial? (Tetris; not the first to actually run, but the first to properly display graphics. One attempt after the first to display any sort of recognizeable graphics, which was also Tetris but with lines on the screen.)

I oughta start working on this again. <_<

no, if you've actually read this whole thread (and i really doubt you did) you'd notice i got super mario land running as my first game

 

[bcrew1375]

Yeah, that's because aprentice was afraid of the Gameboy's graphics . I solved a few more bugs, including a major input bug. That seems to be the cause of the distorted SGB graphics, so most games no longer have that. Though, they still show up in Donkey Kong for some strange reason. Right now I seem to have a bug in the LYC. Certain things in games(like status bars) are getting offset by 1 pixel.

 

[ShizZy]

Thanks bcrew. I think I'm getting closer and closer... I can almost feel victory :-D Just found a really stupid error. I didn't realize there was a difference beween x++ and X+=1. I'm guessing one of them only increments a single byte, while the other increments both bytes for a 2byte variable? By changing all my increments and decrements to -= and += instead, it seemed to make a big difference.

Cheers... and hopefully I'll have a screenshot soon

 

[HyperHacker]

Odd... x++ and x += 1 should do exactly the same. I can see how the compiler might assemble them as 'inc x' and 'add x,1' (or whatever the x86 has for that), but I would think it would optimize 'add x,1' into 'inc x' anyway.

Of course, in the case of x *= whatever, it could be a matter of not having spaces between x and *, since x* is a pointer... Doesn't sound like that's what you're working with though.

 

[bcrew1375]

Hmm, I think I'm missing something here. My LYC check isn't working unless I do it before LY is incremented. Is it supposed to work like that? It screws things up if I do it right after LY is incremented.

 

[bcrew1375]

Edit: Um, this post was intended for ShizZie. How it got above his when he had already posted I may never know :huh:. The time of my post is even earlier than his! Did I just see into the future? :huh:

Hex Workshop will compare files byte-by-byte.

Have you implemented the V-Blank yet? If so, are you turning on and off the bits in the IF register? Are you properly incrementing the LY register? You should be able to get SOMETHING just having those things and the opcodes programmed. Not to question your programming skills, but are you sure the graphics routines are being called properly, and being given the correct arguments .

 

[ShizZy]

Hmmm... still stuck with a blank screen. I think I'm getting there, but error checking is starting to get very tedious. Just spent about an hour fixing things, and yet I think I've created more errors :blush:

Does anyone know of any programs that compare files? Finding errors that are hidden within thousands of lines of spit out logs is like trying to find a needle in a hay stack lain: