Programming Discussion Thread - Printable Version

Programming Discussion Thread - Printable Version

+- Dolphin, the GameCube and Wii emulator - Forums (https://forums.dolphin-emu.org)
+-- Forum: Offtopic (https://forums.dolphin-emu.org/Forum-offtopic)
+--- Forum: Delfino Plaza (https://forums.dolphin-emu.org/Forum-delfino-plaza)
+--- Thread: Programming Discussion Thread (/Thread-programming-discussion-thread)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

RE: Programming Discussion Thread - Shonumi - 02-13-2013

Keep this thread alive! Big Grin

More progress. The framework for interrupt handling is set up, with VBlank interrupts currently being the only one checked for. Have to read up on the rest to see when they're generated. Also, sprites are working, so the Tic-Tac-Toe demo has a little cursor now that tells you your position. Tetris boots, but the GPU isn't perfect yet, so it only gets so far before garbage data is drawn to the screen. Won't be long before it's totally playable. Also, the CPU is ~98% emulated, just haven't implemented DAA, STOP, and HALT instructions.

Spent forever and a day trying to figure out why some sprites weren't drawing. As I said, I'm using Imran Nazar's tutorials to understand the fundamentals of the system, but he sometimes forgets to mention essential code, e.g. code that's part of the JavaScript demo, but not mentioned at all in the article itself. Apparently GBs do a DMA transfer to write some sprite data. Picture time! The fish is just some random graphical demo I decided to run.

[Image: OXQ0LGi.png]

RE: Programming Discussion Thread - Leo - 02-14-2013

Shonumi, need some help. How do you emulate the GB PPU/LCD? Is there a doc describing its internal low level functions, 'cause I just CAN'T find any one.

Do I have to do HLE?( And anyone who wants to write a GB emu? =/ )
Because I've seen so many docs about NES PPU, but for the GB, not.
( May I base myself on NES' PPU workings? )

Thanks

RE: Programming Discussion Thread - Shonumi - 02-15-2013

Just google "GB CPU Manual" and download the first PDF you find. It's a big read, but has some very thorough info. There are also the infamous Pan docs. The GB uses a modified Zilog Z80, but a handful of opcodes were changed and/or removed; it only uses the Z80's CBxx extended opcodes in addition to the regular ones, so all in all there're less than 512 instructions to emulate.

To save you the trouble, look here: http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

Not much on the GB needs HLE. The starting values of the registers and a number of MMIO registers in I/O RAM (0xFF00 to 0xFFFF) need to be set if you don't run the BIOS. I have no idea how the NES' PPU works, but I've heard an NES is around the same level of difficulty as a GB (along with the Game Gear?) though some people found the NES easier, disregarding mappers if you care about accuracy :p

EDIT: Wow, I'm such an idiot. Completely missed that you mentioned the PPU, not CPU. Now that I'm fully awake, I guess I should talk a little bit more regarding what you actually asked about Big Grin

The LCD itself is easy once you have the timings setup correctly. After the 144th HBlank (GB's screen is 160x144) you merely have to draw the data. You'll need to read the LCDC, Scroll X/Y, and BGP (background palette) registers to start. LCDC reg will tell you where to find the Tile Maps, which hold references to specific tiles. The tiles themselves take 16 bytes of space; each pixel is represented by 2 bits worth of data so you get four possible values (for four different colors, 0b00, 0b01, 0b10, 0b11). The background map is made up of 32x32 tiles, so the total size of really 256x256 pixels, but of course the GB's LCD only displays 160x144 of that. The Scroll X/Y registers tell you how far over you need to move the map. Essentially, you see which Tile Map you're supposed to use, then use the value in the Tile Map to look up a specific tile in a Tile Set, then you draw it to the screen. The only tricky part is that there are two Tile Sets, one that uses unsigned numbers and another that uses signed numbers.

Sprites can obviously be drawn above or below the background. The GB has enough memory for 40 sprites, and only 10 sprites can be drawn on any given scanline. You have to read OAM (Object Attribute Memory) from 0xFE00 to 0xFE9F. Each sprite in OAM has 4 bytes worth of data describing how and where to draw it, as well as where to find the sprite data itself (1: Y coordinate minus 16, 2: X coordinate minus 8, 3: Sprite Tile Number, 4: Various sprite options like above/below background, horizontally/vertically flipped, sprite palette). Sprite image data itself is actually held in Tile Set #1, so you just look up the Sprite Tile Number, then look up the data from that Tile Set. Just like tiles, they have the same format. Sprites, however, can have two palettes, whereas the background only has one. As I mentioned earlier, if you ever write any value to 0xFF46, this triggers a DMA transfer from RAM to OAM. Basically, you copy a large chunk of data somewhere else. I guess this is handier than actually working on OAM directly, but I've never actually made homebrew GB stuff. Additionally, sprites can be 8x8 or 8x16, but I haven't messed around with the latter yet.

I'd suggest reading the manual and taking a look at http://imrannazar.com/ for tutorials to get your head around the concepts, specifically the GPU Timings, Graphics, Integration, and Sprites sections. Imran's code isn't perfect, but at least he explains what's going on (or at least what should be going on with real hardware).

RE: Programming Discussion Thread - AnyOldName3 - 02-15-2013

TIL that in java, hashmaps are much harder to use in a for each loop than I had thought.

RE: Programming Discussion Thread - ExtremeDude2 - 02-16-2013

Learned about threading today, now I know why dolphin can't use more threads XD

RE: Programming Discussion Thread - Leo - 02-16-2013

Just another thing that I wanted to know...
It's about how to do wavy effects, like

(\spoiler)
the one on Zelda:LA: the Wind Fish, at its apparison, after beating the final nightmare.
(spoiler)

Or the one at Zelda ALTTP, when you change between Light and Dark Worlds, with the Magic Mirror.(I just love that special effect/song!!!)
(What? No spoiler formats for Dolphin Forums?)

I think it's just maintaining a sine table within the rom, and change the X Scrolling according to the amplitude values.
It's just a guessing, I just want to know how they actually did it.

Oh, and thanks for the info, Shonumi!!(Yeah, I wanted to know specifically about the Low Level LCD/PPU function, the rest...And that's why you're having problems with it, I guess...The PPU's so close to the CPU...^^)

RE: Programming Discussion Thread - ExtremeDude2 - 02-16-2013

(02-16-2013, 04:05 AM)Leo Wrote:

Spoiler: (Show Spoiler)

the one on Zelda:LA: the Wind Fish, at its apparison, after beating the final nightmare.

What? No spoiler formats for Dolphin Forums?

There are but you failed XD

RE: Programming Discussion Thread - Shonumi - 02-16-2013

@Leo - I think graphical effects like that have to do with the WX register (0xFF4B). The GB CPU Manual has small bit about that here:

Quote:WX may be changed during a scan line interrupt (to either cause a graphic distortion effect or to disable the window (WX>166) ) but changes to WY are not dynamic and won't be noticed until the next screen redraw.

The scanline interrupt is selectable via the LCDC register (0xFF40), so you'll need to make your emulated LCD capable of using the WX/WY registers and your emulated Z80/GB will need to handle LCDC status interrupts. I assume the game's code has an algorithm that produces the necessary offsets for WX so everything moves back and forth smoothly.

I'm not that far along yet, however. My emulated LCD ignores WX/WY; most of the time they're set to 0 and in the early stages of development I have other things I need to refine. Eventually though, I need to get that squared away. The only interrupts I've enabled are VBlanks; interrupt handling itself is setup (albeit commented out) I just need to generate the interrupts appropriately.

Oh, and I figured out where my troubles were. My MMU was the trouble; it kept writing to values in the first two ROM banks, essentially re-writing the game's code. How could I forget what Read-Only-Memory means? XD Additionally, my emulated LCD didn't initially handle sprites with a Priority of 1 (below the background) but that's done, so now I can fully play Tetris, with the minor caveat that all of the blocks are "T" blocks. This is expected, since I haven't yet gotten to implementing timers, which are necessary for getting more "random" blocks. Also, the score's value is displayed in hexadecimal, since I haven't yet tackled the DAA (Decimal Adjust Accumulator) instruction. Having gotten so far, I feel pretty good Big Grin

Now you've gotten me curious about NES emulation... I know a bit about the system, but not much. Maybe someday later I'll have a good look-see Smile

RE: Programming Discussion Thread - Leo - 02-18-2013

(02-16-2013, 05:48 AM)ExtremeDude2 Wrote: There are but you failed XD

Oh, god...It's within brackets, nothing to do with html notation <\spoiler>. XP

Quote: Now you've gotten me curious about NES emulation... I know a bit about the system, but not much. Maybe someday later I'll have a good look-see

I just love to make workings on this console!!! Especially on the PPU(such a pain at the beginning...but now it's so fun!!! ^^)

Witch one would you all prefer... wxWidgets, Qt or manual OS/GUI porting?
(Guy, I just CAN'T compile wxWidgets! How the developers of Dolphin can do it?)

RE: Programming Discussion Thread - neobrain - 02-19-2013

Qt!