galeblon / gbc_emulator Goto Github PK

Implementation of 8 bit ADD and ADC instructions

On CGB VRAM consists of 2 switchable memory banks. Implement bank selection in mem. Supply passthru API for gpu to use selected VRAM bank at any time.

After further consideration, I think it is cleaner to let the particular modules handle IO ports registers related to them.

Previously, I thought about creating whole memory blocks to be handled by outside modules, but after further examination it appears that in many cases the IO ports addresses are not consecutive and assigning a handler function on per-address basis seems to make more sense.

Implement basic input module that works with keyboard atleast.

mem_read16 returns incorrect value:

scenario:
Rom with following data:

call mem_read16(0x0102)
expected result:
function should return 0x0150
current result:
0x5001 is returned instead.

Add sprite drawing logic to _gpu_draw_sprites() in the GPU module.

Create mem interface to be used by emulator-internal functions, as opposed to the memory used by the program ran (through cpu).

• add joypad register emulation and include it in the new interface (#57)

• determine cartridge type based on value at $0147
• proper switchable memory banks implementation
  • ROM and RAM banks swapping on particular values written to ROM address space per GBCPUman 2.6 Cartridge Types
• external RAM mapping

Implement emulator state saving, which allows for dumping the state of all relevant modules along with memory into a file, which can be loaded later to recreate the exact state.

Module handling the interrupt procedure is needed.
It will be done in accordance to chapter 2.12 of Game Boy^TM CPU Manual.

I would think that rom module might be the right place to have this sort of thing. Though, I think we could do a bigger refactor and move all of the ROM-header parsing logic and make g_mem_cart_type accessible to other modules. We can make it a separate issue.

Originally posted by @mzal in #50 (comment)

It would probably be beneficial for the project to have one main way of reporting errors and the status of the programme during the error.

Most importantly, it would need to log the CPU register status, which module registered the error and some module-specific info.

Easiest way would probably be to have a single error_log function which takes some error strings and prints them to stderr with CPU status or a separate logging function set/module.

I have not added this issue to the project yet - it should be confirmed which way we should do it and whether we should do it.

In CGB mode addresses 0xD000-0xDFFF are mapped to one of RAM Banks (number 1-7)

Add to the GPU module logic that, according to:

• CGB Enable address in the ROM
• Sprite vs Background/Window drawing
• LCDC bit values
• Palette colour number

shall return the proper RGB values for use in DISPLAY module.

There are a couple of instruction left to finish the primary table. Even though they may not be closely related I see point in further delegating them into separate issues.

Implement memory interface mapping addresses to correct memory block

While testing Super Mario Land 2 ROM, the Z-priority of its sprites seems to be wrong.

Example:

Work on next batch of cpu instructions.

Implement RAM content saving with optional RTC status. Use the format compatible with BGB specification:

• MBC2
• MBC3 RTC

Implement the second instruction table.
The instructions are highly similar so it should be possible to do it under single issue.

Also coding style guidelines should probably be included somewhere in documentation.

We should decide on graphic library we want to use at least for now.
For now all it should do is set it's window title to rom name.

Open questions:

• Should we do it on wiki? It makes sense, as it probably will be our docs repository, but then how should we approach the visual identification aspect?

• Are we ultimately deciding on wiki instead of repository to store the docs?

• Also, I'm guessing we should write all of RPI related docs in Polish?

We should limit access to mem_{read/write}{8/16} functions to cpu only, so that we have one mem API that can work as an emulated memory access (emulated program view) and another one that enables memory access for other components.

e.g. right now if DMA emulation is in progress no memory can be accessed, which is desirable for program-initiated mem access, but interferes with other components' functionality.

module dependencies including #71 and intended timer module implementation

module dependencies after removing mem_{read/write} from gpu

Legend:

• rectangle component: module
• circle: common interface
• red arrow (A -> B): module A calls functions declared in module or common iface B
• blue line (A - B): common interface A exposes functions from module B
• debug and logger modules not show -- these should serve as helpers and not influence the emulation (also most of other modules include them)

Currently 4 cpu instructions tests fail.

All tests should pass.

In GPU module, in functions gpu_write_bgpd() and gpu_write_spd(), there are two TODOs.
They require finding the CGB Object (Sprite) Color Palette Memory and CGB Background Color Palette Memory addresses and putting them in defines, if constant, or in MEM/ROM modules as a get() function, if not.

AND, XOR, OR and CP (compare).

Implementation of 8 bit SUB and SBC instructions.

Some of Memory Bank Controllers support Real-Time clock functionality accessible through memory mapping of some RAM Bank numbers.

During the Legend of Zelda: The Link's Awakening's intro, there are 3 places, where, starting from some X, some tiles seems to have moved on the Y axis. Those places are:

• Second to last lightning bolt, the middle one before we see high-quality Link's face with the rope, right side of the screen.
• When Link is found on the beach, right side of the screen, starting from about the middle.
• Egg.

Bug does not appear when intro is skipped (important for the Egg).

Example:

Remove any stray printfs, add #define to enable/disable non-critical logging

When loading up a GameBoy game, user could manually select their palette for the game, using key combinations during startup.

Sources:

• https://tcrf.net/Notes:Game_Boy_Color_Bootstrap_ROM
• https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Game_Boy_Color

Some GameBoy games, when put into a CGB, gain preassigned palettes, based on their hashes. They should be added.

Source: https://tcrf.net/Notes:Game_Boy_Color_Bootstrap_ROM

Sprites in GPU module show themselves, but not correctly.

Examples with approximate comparisons:

Gameplay source:

• https://www.youtube.com/watch?v=wLLrqrHlc0A

Related Issues:

• #38
• #43

Related PRs:

• #51

Add build target with alternative entry point to the program running selective functionality tests.
Add the target as automatic github action executed on pull request

Implement all instructions considered miscellaneous by this:
Gameboy CPU (LR35902) instruction set

Current code seems too slow for our liking. Basic profiling indicates that the DISPLAY module is the culprit. It should be optimised, for example using a locked/unlocked bitmap rather that al_draw_rectangle().

Add background drawing logic to _gpu_draw_background() and window drawing logic to _gpu_draw_window() in GPU module

Implement those operations and measure time it took,
this will help us approximate time/efforts needed to add all operations

Determine the way memory read/write errors are handled on GBC and implement emulation of it

• add return status to mem_block_write_t if needed
• check struct mem_block->write calls return value and handle error if occurred

There are still some common Memory Bank Controllers which are not implemented in mem.

The ones which need to be supported are:

• MBC5
• MBC6
• MBC7
• HuC1
• HuC5

Investigate and implement Sprite Attribute Table support in mem module

Emulator should have a verbosity flag. If enabled, it should print every instruction it executes, this will be useful in future development and debugging.
The output in console should look something like this:
Address Mnemonic Operands
0x0100 LD A, 0xFC
At this point instead of mnemonic we could print just the hex code of the instruction, but we should think about a way of mapping the hex codes to mnemonics.

We should also think whether this should be printed in separate console window.
(Maybe one window shows instructions and second current registers values)

Also the option of step by step execution should be considered
(Not high on priority list, we can just use breakpoints when debugging to achieve the same result)

This issue will be probably split into smaller tasks.

Create timer module to handle DIV(0xFF04), TIMA (0xFF05), TMA (0xFF06), TAC (0xFF07) registers and request timer interrupt (INT 50)