LGBA Release Notes ----------INDEX------------ 1 Compiling 1.1 Compiling under Windows 2 Developing LGBA 3 ToDo List 4 Known Bugs --------------------------- 1 - COMPILING Compiling LGBA is rather easy. These libraries are needed: -libGL (OpenGL Base) -libglfw (OpenGL exstension similar to GLUT) -libGLEW (OpenGL Exstensions Wrangler) -libncurses (ncurses) -libpthread (UNIX pthread implementation) You can compile using the Makefile that comes with the source and full distributions or, if you have Codelite (a C++ IDE), you can easily compile loading the workspace file that you can find in the distributions. You also need a C++ compiler. g++ will be fine. 1.1 - COMPILING UNDER WINDOWS To compile under Windows you need to link the same libraries. The only problem might be libpthread, even if some implementations of it for Windows exist. You can change the code into main.cpp to use standard Windows threads (you only need it to start the VideoOutput Window thread). 2 - DEVELOPING LGBA LGBA is written in C++. While developing, you have to follow some commenting format conventions to automatically generate documentation after with NaturalDocs. You can have more informations about it here -> http://www.naturaldocs.org/ If you want to develop LGBA you probably want to do one of these things: -Expand the PPU. In this case you have to work into PPU.cpp file. Many of the functions needed to develop the unimplemented render functions are already there into existent classes (Tile4, Tile8, Palettes, OAMSprites) and in utility functions in PPU.h (like unpack_rgb, render_bg_textmode). -Expand the Emulator with additional modules. The rule of thumb in these cases is to create a class that represent the module (e.g. "SoundCard"). Add this module then into the GBA class. You probably want to add a pointer to Memory (to access registers and ram(s)), and a pointer to the CPU (to generate interrupts) in the constructor of your class. Use inline as much as you can (when it makes sense) to lower overhead, performance is a must. The debugger will be you best friend to understand how things work. -Fix little bugs. The debugger will help spotting errors. Try to locate the critical instruction/event and then mail me or check the documentation to try to fix it by yourself (then mail me anyway to push your version!). You might find interesting to give a look at some additional documentation about GBA registers and hardware here: - http://problemkaputt.de/ - https://emu-docs.org/Game%20Boy%20Advance/CowBiteSpec.htm 3 - TO-DO LIST -Sound, the ideal is to put it into another thread (with openAL) -Cross platform versions of CPU_ASR. It is implemented as a >> (right shift) of a cast to (int) which is undefined behavior in c++ (in most compilers it is treated as Arithmetic Shift Right) -Increase Performance of CPU -Increase Performance of MMU -Rewrite the rendering engine so that it support per-line rendering -Expand the rendering engine to render in all modes -Expand the rendering engine to support 3D renders -Expand the rendering engine adding post-processing filters -Corrects small errors in the CPU (testing roms) -Increase performance in dma transfers with some sort of prediction -Increase cycles count precision (without decreasing performance) -Compile under Windows (only pthread shall be a problem) -Add Multithreading support for Windows -Fix the input once for all (I've not totally understood how it works) -Add a decent limiter for FPS and speed. -Add an emulated bios via software (it is already in little parts done) -Add Save/Load Machine States (easy to do) -Transform it into a NintendoDS emulator (you'd have to add Coprocessor instructions in the CPU, input register and make the ppu render in two buffers) 4 - KNOWN-BUGS -The video output shall be rendered line per line, indeed, often to achieve particular effects, a DMAChan changes BG registers every HBLANK and every line has different effects. The current rendering engine draws all the layers directly and then compose them in a final pass. -In Final Fantasy VI when trying to start the first fight it crashes. I've given a look to it and found where the problem is: the routine at the address 0x030031C0. Try to locate where this memory zone is written and you might find an error in the cpu near there. Little note: the memory zone is empty before the start of the fight, so the breakpoint shall start between the start of the fight and the crash point.