alloncm / magenboy Goto Github PK

Currently for every instruction Im updating the register, since it is not necessary for most of the instructions I can just update it when the cpu tries to read the joypad register.

Currently the setup described the RaspberryPi section takes about 15 seconds to boot, I want to cut it to 1-3 seconds to achieve an authentic feeling as much as I can.

I believe running bare metal could help achieve this goal.

This issue depends on this #123 and is used to collect all the resources in one place

Use the vblank as indication for an end of frame

crossbeam channel is being used in the std as of Rust 1.67 so there is no reason to import another lib

https://github.com/alloncm/GBCEmul/blob/10003cac8e0022767179bc4f5bbb38757fcd2a47/lib_gbc/src/opcodes/load_16bit_instructions.rs#L73

Tell about the different features flags during compilation

Adafruit I2S 3W Class D Amplifier Breakout - MAX98357A : ID 3006 : $5.95 : Adafruit Industries, Unique & fun DIY electronics and kits

https://www.adafruit.com/product/3006

Currently Im using vsync but for screen with higher refresh rate this wont work.

There are still uncompleted tasks:

• Merge the rpi_gpio module to the baremetal project to create a RPI project with feature to run baremetal (the peripherlas are really look alike in the code base)
• Add support for roms-folder from the image sd card
• Support proper shutdown from software side
• Add support for saves
• Support other rpi's and cpu's, currently the code is only tested on cortex-a72 (and some code assumes it compiled only for this cpu) so add support for other cpu's and arrange the code for that
  • replace the target-feature=+virtualization with target-cpu=cpu for the compiled cpu
  • Add .ifdef where necessary to add support for coretx-a53 and more
  • Add a rendering core that will handle the rendering to boost performance - Not sure if necessary (on RPI4 its not but might be on zero2)
• More testing on hardware (hopefully get another rpi zero2)

The emulator will have a port for "technician" which will allow to read logs from the uart and when choose upload new rom in the menu will allow the user to upload a rom to the gameboy.

Perhaps there will be a program from the other side which will stream the rom and communicate with the emulator

http://mydedibox.fr/rpi4-sdl2-kms-drm-compilation-no-x/

Move to 1 buffer - might also increase performance

Originally posted by @alloncm in #27 (comment)

• use trait default implementation in the mbc
• try use impl instead if dyn when passing the Memory trait to the opcodes

This will give a better emulation accuracy and I'm believe a faster emulation too.

This is the next bottleneck :)

It decrease video buffer size by x2

Originally posted by @alloncm in #125 (comment)

Add an folder that the user could add roma to and upon start could choose to be prompt with a menu to select a game.

Could use the dialoguer lib

I had those two errors on RPI linux:
When using the manual resampler:

malloc(): invalid size (unsorted)

When using sdl resampler:

free(): invalid pointer

when activating the push-audio feature the error will no longer occur

In order to do that there are a few areas that will need to change

• Detect rom target machine (CGB/DMG)
• CPU - support double speed mode, including enable and disable double speed mode
• PPU -
  • Support the CGB pallets
  • Object priority changes in CGB mode (place in OAM memory and not X value)
  • BG map priority table
• MMU
  • Support the expanded vram and ram
  • Support the new vram dma contoller
  • Support the CGB bootrom

When following an NPC the NPC flickers while leading the character.

The emulator barely runs at 120 fps without the sound implemented.

After the sound it will barely run at 60 fps (on an I7 machine)

Support cartridges that can receive in the external ram a memory mapped file and use it (probably a pointer or &mut [u8]

Current state

The sound gets de-synced from the video over time.

In order to solve this every time Im pushing new sound to the sound device (right now to SDL) Im blocking until the samples queue is almost empty and only than pushing the buffer.

Reasons

I believe the de-syncing happens for 2 reasons:

• Right now Im calculating the ratio of Emulator samples per actual sample with the original GB frequency.
  The problem is that since Im not stepping this amount of cycles per second but slightly more (since Im running at 60 fps and not 59.7... fps like the original GB) Im producing more samples than I have time to output.
• Another reason for this is that Im saving the amount of samples to skip as an integer and no floating point, cause of that I might lose precision when skipping samples and could have more samples than necessary.

Proper solution

Running the emulator at the correct original fps and using float to calculate the samples to skip.

Currently the PPU is almost ready (line based not pixel based)
The CPU is not ready and once is ready needs to pass the passed cycles to the PPU

Note to self:

Once ready fix the MMU to block VRAM and OAM

The code never disables the sound terminals
The line Im taking about

I think could be done with two matches ine for the to get opcode type enum and one to run the the specific enum with the func pointer

Added one here, needs to be added correctly - #27 (comment)

The game boots correctly but wont return gracefully from dialogues and menus.

Originally posted by @alloncm in #97 (comment)

Sync the sound using the callback api of sdl and not the push api.

It will grant a better performance at the cost of another thread.

When playing this game the score section is blinking upon moving right.

I believe this is due to not accurate enough fifo ppu implementation.

Docs and tests to help

• https://github.com/mattcurrie/mealybug-tearoom-tests
• https://mgba-emu.github.io/gbdoc/

The opcodes that fails the test are:

• 0xCB26 - SLA (HL) code - https://github.com/alloncm/GBCM/blob/b0911395a5d7092d8c3331f140369cf51fe8b207/lib_gbc/src/opcodes/rotate_shift_instructions.rs#L215
• 0xCB2E - SRA (HL) - code - https://github.com/alloncm/GBCM/blob/b0911395a5d7092d8c3331f140369cf51fe8b207/lib_gbc/src/opcodes/rotate_shift_instructions.rs#L275
• 0xCB36 - SWAP (HL) - code - https://github.com/alloncm/GBCM/blob/b0911395a5d7092d8c3331f140369cf51fe8b207/lib_gbc/src/opcodes/rotate_shift_instructions.rs#L253
• 0xCB3E - SRL (HL) - code - https://github.com/alloncm/GBCM/blob/b0911395a5d7092d8c3331f140369cf51fe8b207/lib_gbc/src/opcodes/rotate_shift_instructions.rs#L297

Unit tests -
https://github.com/alloncm/GBCM/blob/master/lib_gbc/tests/rotate_shift_tests.rs

The failed test output

The idea

In order to save the state of the game some games have an battery packed MBC that allow them to save the sate of the game to the MBC.

I want to support that and for this Ill need some way of access to the MBC from outside the gameboy (that should be multi platform).

Solution

I can drop the gameboy as the program receive close signal and only pass the MBC as & mut so Ill still have access to it after.

The problem

The screen is tearing

The frame isnt being drawn in the end, but all over the place (not LY = 153 but all kinds of LY's).

Solutions

• Accurate emulation could solve it, only the amount of opcodes needed would run until the screen would be drawn.
• Double buffering could help with the tearing, switch the buffers only when finishing to draw.
• Fetching the buffer only when finishing the PPU finishes to draw.

Right now the dma is inside the gb_mmu, mainly because it needs access the mmu and needs to be under the io_bus in order to expose its memory interface to the mmu.

I think that by making another bus for regular memory (addresses 0x0 - 0xFDFF) we can separate the dma implementation to its own independent structure.

Hopefully it wont harm performance :)

For some reason the audio is missing samples on linux and sounds horrible

Add the option to save the state of a game anywhere I want (also support for saves in games that do not support it).

libretro/ludo#383

In order to run on weaker hardware I want to improve performance as much as I can.

In order to do that I opened a new branch called feature/mt, a PR will be opened soon.

In this branch I will convert the program to 2 threads (or maybe 3) in order to move the IO from the logic thread.
When doing this I need to figure out how to draw properly without busy waiting in the IO thread for new frame buffer from the emulation thread while not making the window unresponsive in case the PPU is turned off.

This be achievable with blocking function that has a timeout, when the timeout is set the function will update the UI (accept new events) and than block again for the amount of time.