It is currently Sun Oct 22, 2017 1:02 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Sat Feb 09, 2013 8:12 pm 
Offline
User avatar

Joined: Mon Aug 16, 2010 4:48 am
Posts: 183
I've been messing around with the gameboy colorizer working to convert marioland into colour. I got the rom with colour and glitch free, except on real hardware it refuses to run. On the gba the rom runs in gbc mode and after the bios screen it goes white. On the sgb I get to the title screen and then it just refreshes over and over. Here's the rom:

http://www.mediafire.com/?q3438655bk680hy

What I did manage to do was I found a way to recreate what's going on in an emulator. Using the bgb emulator I click on options, exceptions, then I click on "cart troubleshooting mode". I load the rom and it gets to a couple of empty code spots which I just fill with "nop" or skip past. Once I'm past those few spots I get the same white screen as my real gba. If I go into options, system, and tell it to run as a "super gameboy" then I get the same thing happening as the real super gameboy. With the emulator in troubleshooting mode set to run as a super gameboy it gets to the title screen and gets stuck occasionally refreshing the title screen just like the real super gameboy. I could really use some help with figuring out what's causing the rom to get stuck.


Last edited by Drakon on Sat Feb 09, 2013 9:27 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Feb 09, 2013 8:52 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
If you really want an old game boy game in color, I think the only way to do it is true ASM hacking. Find where the rom writes background tiles to Video RAM, then do something else:
Write the byte to video ram as normal.
Look up the tile number in a lookup table to see what attribute byte (color selection) you should write.
Switch from regular VRAM to attribute VRAM doing the proper register write
Write the attribute byte to video ram.
Switch back to regular VRAM.

There might be several pieces of code responsible for writing to background tiles.

Also change the code for when the game writes to the sprite table memory if you need to assign colors to particular tiles.

Also, Super Mario Land is a terrible game, it looks like a programming experiment or technical demo that got shoved out the door. Releasing that game in its state told other developers that it's okay to release crap games on that system. Mario Land 2 is a lot better.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Sat Feb 09, 2013 9:18 pm 
Offline
User avatar

Joined: Mon Aug 16, 2010 4:48 am
Posts: 183
Haha I love marioland, it was one of my favourite games as a kid. Plus I'm horrible at rom hacking so I wanted to start with the simplest game I could find. Anyway asm hacking is above me which is why I'm posting here. The gameboy colorizer made a mess of the rom, I managed to hex edit away bugs and glitches. It runs stable on emulators with colour now it just looks like it's getting stuck in a loop somewhere when trying to run on the real thing. I don't know a thing about asm programming / hacking.

I wouldn't have a clue how to find where it writes tiles to video ram. Probably something to do with breakpoints, and knowing what to look for.

One of these perhaps?

http://nocash.emubase.de/pandocs.htm#videodisplay


Top
 Profile  
 
PostPosted: Sun Feb 10, 2013 11:05 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1306
On a related note, I'm curious about:
Quote:
CAUTION: Stopping LCD operation (Bit 7 from 1 to 0) may be performed during V-Blank ONLY, disabeling the display outside of the V-Blank period may damage the hardware. This appears to be a serious issue, Nintendo is reported to reject any games that do not follow this rule.

Does anyone know why that happens?

And also,

Quote:
Even though GBA is described to be compatible to CGB games, most CGB games are completely unplayable on GBAs because most colors are invisible (black). Of course, colors such like Black and White will appear the same on both CGB and GBA, but medium intensities are arranged completely different.

What in the hell is he talking about? Does he mean to say that the gamma curve is too dark? This makes it sound like there are missing palette entries like the NES with an 2C03B...


Top
 Profile  
 
PostPosted: Sun Feb 10, 2013 11:54 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6293
Location: Seattle
mikejmoffitt wrote:
On a related note, I'm curious about:
Quote:
CAUTION: Stopping LCD operation (Bit 7 from 1 to 0) may be performed during V-Blank ONLY, disabeling the display outside of the V-Blank period may damage the hardware. This appears to be a serious issue, Nintendo is reported to reject any games that do not follow this rule.

Does anyone know why that happens?
Liquid crystal is very easily damaged by an non-zero DC voltage on it. All LCDs have to drive any given segment one way and then the opposite repeatedly, or else the actual chemical inside that changes polarization will somehow physically damaged. All LCDs I've seen have a "field" control, that unlike television fields, instead just specify whether the screen is common-negative or common-positive for that refresh.

This is just a guess, but: maybe if you disable the screen in the middle of rendering, it fails to disable the horizontal raster drivers, causing one line of pixels to be drawn with the same voltage over... and over... and over... and also never flipping the field control.


Top
 Profile  
 
PostPosted: Sun Feb 10, 2013 1:50 pm 
Offline
User avatar

Joined: Mon Aug 16, 2010 4:48 am
Posts: 183
I got an e-mail response from the author of the bgb emulator. Here's what he said:

"i looked at the rom. it does not work on your flashcart, bgb's cart
troubleshooting mode, or really anything but a mbc1, because it uses mbc1
specific behavior: it writes 01 to 4xxx to choose the "high bank" (as in, it
sets bank 21), then it jumps to a bit of code you've added.

so in short, your rom says it needs a mbc1, and bgb emulates a mbc1
correctly, but this is not what you want.

recommendations:

- move your own custom code earlier (bank 1f or less), and make the whole
rom smaller (in this case, 512 kiB, or less if possible), this lets you use
the cart more efficiently.

- use a normal bankswitch (a write to 2000) to reach your code.

- set your rom to use mbc5 (type $19) in the header."

He says I need to do all of these steps. Except I didn't add the code so I have no idea how to change to rom to do all of this stuff. All I can do right now is change the header to mbc5 which doesn't help at all.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group