Page 121 of 121 FirstFirst ... 2171111119120121
Results 1,201 to 1,204 of 1204

Thread: Game Boy

  1. #1201
    EmuTalk Member
    Join Date
    Jun 2013
    Posts
    19
    Mentioned
    0 Post(s)
    Quote Originally Posted by Shonumi View Post
    Pokemon Blue - May be related to STAT interrupts. I would imagine that one type of interrupt (likely H-Blank) is being triggered so the game can safely modify SCX for the scanline for the wave-like effects. Seems like all the GB Pokemon games (Red through Crystal) don't make the very first scanline move when attacks make those wave-like effects (LY=LYC test maybe? Perhaps the effect just couldn't be done when testing for LY=0). If it loops forever rather than crashing, it's usually a sign that you're not feeding it input it expects (an interrupt, a certain value in the MMIO registers, stuff like that). The best thing to do is look at the GB assembly in a debugger and compare it in an emulator. Time consuming, but effective, since eventually your emulator will diverge from a correct, working emulator and you can then pinpoint where exactly.
    That was one of the reasons I wrote the profiler, just didn't have the time and motivation to dig through the output.
    I also noticed that it does not move the second scanline, which looks weird and should probably not happen.
    Edit: The issue was easy to find, he checks for LY==143, but LY resets after reaching 142.
    A closer look at my code revealed that I triggered the Vblank interrupt at the end of scanline 143 instead of 144.
    This fixed the loop but now the topmost 3 scanlines don't move...



    This apparently fixed Pokemon Crystal too.

    Quote Originally Posted by Shonumi View Post
    As for double-speed, I kinda struggled to implement it correctly too, in fact, I only knew my implementation was broken because the Oracle games were messed up. I solved it by simply halving the CPU cycles the LCD acknowledged after each instruction (my emulated APU is not cycle-based, not yet), but by sending the original amount of CPU cycles to the timers. The CPU runs at 2x its normal operating speed (meaning all timers run twice as fast too) but LCD operations, DMA transfers run at the same speed. The setup I just described follows that, but it took me a while to figure it out.
    Three new lines and it seems to work fine .
    Edit: Some palette issues and the map corruption in Zelda DX is now fixed,
    but remains in the DMG Zelda.

    Quote Originally Posted by Shonumi View Post
    Other stuff - Sprite palettes in DMG games are off. You may know how to fix it already, but just make sure you're correctly reading OBP0 and OBP1. Also, seems like you still have BG/Sprite priority issues (Suicune in the intro of Crystal should be behind the grass). For reference, there are only 4 cases where a sprite's pixel will prevail over the BG's pixel (GBC only):
    The color issues probably happened when I swapped color channels around to fix GBC games, but the palette lookups seem fine.
    I check the OBJ-to-BG priority but not (yet) the BG-to-OBJ, so that could explain it.
    Last edited by Rüdiger; April 20th, 2014 at 11:48.


    • Advertising

      advertising
      EmuTalk.net
      has no influence
      on the ads that
      are displayed
        
       

  2. #1202
    EmuTalk Member
    Join Date
    Mar 2014
    Posts
    16
    Mentioned
    0 Post(s)
    Only two tests are finished at the moment. Apparently I didn't have as much free time as I imagined, thanks to my urge to play games rather than program stuff :p

    The first test, LYC.gb works using the STAT interrupt, specifically the LY=LYC test. It draws exactly 16 lines of the background before disabling the background altogether. This test was based on Super Mario Land which gave me some headaches. A real Game Boy always performs a comparison of LY and LYC after LY is modified in any way. You have to 1st render the current scanline, then increment LY and do the comparison. I noticed some emulators were rendering, comparing, then incrementing LY. This isn't documented clearly as far as I know, but from a hardware perspective, the first (and correct method) is the most logical. This test basically makes sure the order is correct. Output should be 16 lines of alternating color (last color should be the lighter one of the two) and after that the rest of the screen should be blank (white basically in a pure B/W monochrome palette).

    The second test, sprite_suite.gb, focuses mainly on sprites. It's still a WIP with only 1 test programmed (the 10 sprites per line limitation), but more are expected. This ROM does rely heavily on STAT interrupts (OAM interrupts) as an early warning for the program to abort writing to VRAM before it becomes inaccessible and continue on the next VBlank. Basically the 11th sprite just scrolls vertically over an over again, and every time the Game Boy has to render a line with more than 10 sprites, the 11th sprite's lines disappear.

    Both have been verified on real hardware (CGB-001 if you're interested, but I have a Game Boy Pocket, Game Boy Advance, and Game Boy Player that can be tested as well).
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	LYC.png 
Views:	7 
Size:	731 Bytes 
ID:	39006   Click image for larger version. 

Name:	sprite_suite.png 
Views:	4 
Size:	929 Bytes 
ID:	39007  
    Attached Files Attached Files
    Last edited by Shonumi; April 20th, 2014 at 23:54.

  3. #1203
    EmuTalk Member
    Join Date
    Jun 2013
    Posts
    19
    Mentioned
    0 Post(s)
    I found a rather stupid bug thanks to AddressSanitizer. I did not limit VBK to 1 bit which caused Oracle to write all over the memory.
    This fixed the ingame graphics but the opening and some menus are still garbled.

    The wrong colors in DMG mode were easy to fix but it took a lot of time to find the actual issue.
    As it turned out, the two bits of all colors were swapped, completely messing up the otherwise correct palette lookups...

    While the overall compatibility with DMG games is pretty good, I still found some additional games that have more or less serious issues:
    Prehistorik Man: I know that this game does some mid-scanline changes that I can't handle at the moment, but besides that the game shows flickering and occasionally broken sprites.
    Mystic Quest: Flickering between sequences.
    Parodius: Does a JP HL straight into the character RAM and hits an invalid instruction.

    Shonumi: Your test roms look good so far. Disabling the background on my emulator currently fills the scanline with color 0 from BGP instead of white so it is not really visible, but it turns off after 16 lines.
    Did you write them in C or assembly and are there any good toolchains around? So far I only looked at gbdk, but the newest release is from 2002.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	23-04-2014 18:35:16.png 
Views:	1 
Size:	5.1 KB 
ID:	39013   Click image for larger version. 

Name:	24-04-2014 18:16:19.png 
Views:	0 
Size:	409 Bytes 
ID:	39012   Click image for larger version. 

Name:	24-04-2014 18:17:02.png 
Views:	0 
Size:	600 Bytes 
ID:	39011   Click image for larger version. 

Name:	24-04-2014 18:18:37.png 
Views:	1 
Size:	3.0 KB 
ID:	39014   Click image for larger version. 

Name:	24-04-2014 18:21:52.png 
Views:	1 
Size:	5.3 KB 
ID:	39015  


  4. #1204
    EmuTalk Member
    Join Date
    Mar 2014
    Posts
    16
    Mentioned
    0 Post(s)
    Congrats on your progress. I myself have been extraordinarily lazy as of late, and haven't put the finishing touchs on GBC support. It's ready to merge, almost. :p

    I heard about Prehistorik Man being a pain to emulate. Perhaps the VBA-M source code has some comments in the code. It may give you a clue. I haven't tested that game. The scanline pixel data itself shouldn't be able to change after a certain point in the LCD's operation (i.e. VRAM access from the CPU is disabled), but I don't know how changing things like SCX or SCY affect rendering mid-scanline. Coming up with a test for that might be tricky.

    As for the tests, I'll see if I can add more this weekend. It's not coded in anything but the GB's Z80 assembly. I opened a blank 32 KB file in a hex editor, then started plugging away hexadecimal values. I've been doing it this way for a while, and I've just gotten used to it. It's not very readable, but it works

Page 121 of 121 FirstFirst ... 2171111119120121

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •