Gekko Gamecube Emulator
http://www.gekko-emu.net/
http://code.google.com/p/gekko-gc-emu/
http://www.gekko-emu.net/
http://code.google.com/p/gekko-gc-emu/
Quote:After many years of work, we are releasing gekko into the public. It is behind Dolphin in terms of what is possible and functional though.
This release is due to a variety of reasons. Most of it is due to myself being the sole developer at the moment. I've been moving along on it however the pace is slowing down due to various issues in increasing speed and other events in my life, going for my BS degree for instance on top of family and work.
I may continue to peck away at it or I may not, I am uncertain at the moment. The code is also being released. If it is useful to anyone or further's Dolphin then great. I developed the code using just publicly available information prior to Dolphin's source being publicly released so I can not speak as to wether or not there is any benefit to them as I have not looked at their code since I started on this project.
The code and public exe is being hosted on Google's code at http://gekko-gc-emu.googlecode.com. If you have questions please email me. If you find the code useful, please email me. I enjoy seeing others benefit from my knowledge and things I have created.
The exe can be found at http://code.google.com/p/gekko-gc-emu/downloads/list. There are a few enhancements since the v0.3 release, mostly in the DynaRec but I can't recall what all of the updates are.
Quote:The code that is being made public was a large work between Lightning and Shizzy with a few others like Chrono chipping in.
Shizzy did most of the work on the graphic code and quite a bit of the original underlying code for low level and the interpreter cpu.
Lightning's main focus was the dynarec. He also rewrote the HLE code while also reimplementing and reworking other parts of the code for speed.
Here are some rough notes about the code.
* The dynarec has implemented most functions. It could use a few other enhancements to increase speed
* There is commented code in the gx_vertex file to quickly do a vertex list. It is disabled as it doesn't care about memory changes and did not increase the current speed of the emulator
* The HLE function names were generated by the zelda map file. The same info was used to generate the HLE crc values
* Sound does not work at all
* There is a bug in the code somewhere resulting in the memory cards showing up as damaged that hasn't been solved
* The dynarec uses an internal memory manager to avoid the slowness of window's memory manager
One idea for the dynarec was to re-scan thru the internal instruction list and make use of instructions like LEA to combine values instead of dealing with mov/add. Jumps were never implemented into the cache code so benefits could be seen by SHL and SHR if a known shift amount was being used.
The dynarec could also compile in a jump instruction to jump to the next code block to run. The issue that this would cause in the current code is no method of the wndproc to be checked for user interaction and the current compile function auto-executes the code. If the wndproc issue was solved, threading the cpu for instance, then the compile function can just compile and exit without needing to execute. It would just have to be called from a common compiled block that calls the compile function then re-executes the block. Any block compiled would just jump to another compiled block or jump to the function in memory that calls the compile function then re-jumps to the compiled block.
I have no issues with others using this code. I do ask that people let me know what they think or areas they use as I'm curious if any of this is useful to anyone. If you do use it in a project, please give credit where it is due.
-Lightning
![[Image: 1913820.png]](http://valid.canardpc.com/cache/banner/1913820.png)