19:54 2003-06-20
Perhaps external stuff should be done without plugins, considering that the emulated platform is static and the primary reason for the plugin system in PeaCe was to provide possibility for emulation of any hardware that might exist on a PC.

03:22 2003-06-21
Todo: byteswap .dol (?)
01:41 2003-11-18
Nah. :}

21:39 2003-07-01
Thanks to Peter of www.console-dev.de and Yursoft for gamepad info in their OpenGC library.

00:06 2003-07-02
The version of fire.dol in the fireee.zip distribution (8082 bytes) got stuck in an infinite loop. I recompiled it and it seems to work fine now.
13:02 2003-12-24
Just tested that old version again and it works just fine. :)

12:27 2003-07-02
I'm not sure how to do swapd(). Do I byteswap the entire QWORD in one go or do I treat it like two separate DWORDS?

14:50 2003-06-27
Thanks to DesktopMan (DesktopMan[at]fritidsproblemer.no) and http://www02.so-net.ne.jp/~koujin/jpeg/RGB2YCbCr.html for YCbYCr conversion information.
13:04 2003-06-29
Thanks to Crazy Nation for lots of useful info.

00:04 2003-07-01
Well, finally. We now run Crazy Nation's assembler test demo at approximately 200 kHz, or 1/4 fps. I'm not sure the colors are right (the yellow and red seem a little out of place), but it's showing the entire logo and scrolling the background to the left good enough. Next stop: the version shipped with czn-psul.
00:32 2003-07-01
There may be some emulation errors due to big/little endian differences. Be ware.

18:14 2003-07-14
Pong clocked at 76 SPF, ~34 KIPS. It needs to be about 4800 times faster. :}

10:46 2003-07-23
Pong clocked at 6 MIPS. Quite an improvement. :)

12:15 2003-07-25
I think I finally got carry and overflow right. :}

11:47 2003-07-26
Thanks to CrowTRobo for his Sound demo.

17:10 2003-07-26
Emulated so far:
* 89 opcodes
* Framebuffer, using address 1
* PAD 0 digtal buttons and primary analog stick
* Audio DMA interface

18:40 2003-07-29
Breakthrough: executed first recompiled code.

12:15 2003-07-31
Recompilation going slow, but well. RCB Translation Buffer introduced to help with branches, but so far it only works with backwards ones. RCB Translation Request Buffer proposed to handle forwards branches. The RCBTRB would contain the RCB position of a DWORD to be filled with the RCB Translation of a specified Gekko EIA. (that's two fields, the RCB pos and the EIA). The RCBTRB would be checked and handled at the same time as the standard RCBTB.

19:37 2003-07-31
The recompiler buffer has finite size. Be Ware.

14:59 2003-08-01
Found/fixed bug in CPU::_andi().

13:17 2003-08-02
Found/fixed big muthaf**kin' bugs in CPU::_cror() and _crxor.

17:34 2003-08-06
Todo: Profiling in VS .NET.
Todo: Multiple recompiled blocks.
NOT Todo: Make sure INI, degub files and screenshots end up in executable directory.

16:27 2003-08-10
Found/fixed disassembly errors in ori(s), xori(s) and andi(s).

00:43 2003-08-26
Thanks to or9, for low memory(0x00000000 - 0x000030FF) dump through Dolwin 0.06 running Freeloader 1.06b.

18:08 2003-09-25
01:49 2003-10-01
Weird. I wonder what I was gonna write.
23:00 2003-10-02
Maybe that I don't use the lowmem dump from Dolwin anymore.

12:37 2003-10-01
Copying the entire register struct every time a single reg changes is really slow. So I fixed it. See Register::degub().

22:57 2003-10-02
CPU() still has a memsize argument because we might want to emulate a development console, which has 40MB, more than the standard 24MB.

01:19 2003-10-11
Sappharad's DVD browser finally emulated! :)

20:53 2003-10-11
Fixed über-bug in swapd().
21:19 2003-10-24
Did I really?...

21:19 2003-10-24
Fixed über-bug in lfsx.

02:28 2003-10-30
Fixed major bug in fmul and fmuls.

20:40 2003-10-30
Fixed major bugs in cror and similar functions: getflag was used were getbit should have been. Beware of this!

01:00 2003-11-07
In WhineCube, Undefined opcodes are different from Unknown ones in that they are not defined in the Gekko Reference Manual and will probably never be defined in WhineCube.
13:45 2003-11-07
When all known opcodes are defined, all others will be undefined and this mechanism will not be necessary.

20:30 2003-11-08
Finally figured out that it was the cache mechanism which causes the graphical error in czn-test. I'd hoped that it be fixed by modifying Memory::read() and write() to work with both cached and uncached memory seamlessly, but that didn't work.

21:11 2003-11-08
It's impossible to catch an an exception thrown from inside recompiled code. Take care to see that none are thrown.
21:17 2003-11-08
An error occurs in optipong (possibly in pong and soundpong too) that results in an Unemulated hardware read: 0xF3347500 as the 10-10 score occurs. Since getting there takes a few minutes even in recompiler mode, checking this error with the interpreter will prove difficult.
17:40 2004-05-02
This ain't true no more. Forget it.

00:32 2003-11-21
now3D's Balls demo finally runs in the recompiler. At 65 FPS, too. Yay! :)

20:51 2003-11-25
A program that runs in a single function, without using the B opcode, will appear frozen in recompiler mode.
11:57 2003-11-26
Fixed.

20:47 2003-11-25
Put stop and errorcode in registers instead of directly into memory. This makes smaller code.
UNKNOWN DATE
Undoable. You'd have to zero the register used for stop after any other instruction accesses it. Besides, code that isn't executed can be as big as it wants.

18:34 2003-11-27
The release build stores variables in registers but fail to push them onto the stack before jumping into the recompiled code. We'll have to do it for them. :}

19:00 2004-01-19
New TB/DEC scheme. The time they were last updated is stored (as a HRPC value) and the update functions compare with the current time and inc/decrement them accordingly.

04:36 2004-02-08
Progress report:
Gekko: 126 opcodes. Most integer and floating-point opcodes done. Paired Single and some cache and interrupt opcodes left todo. *Very* simple cache system, no interrupts.
Graphics: XFB implemented, but not exactly. Screen update timing and the dual buffer address thing is still off.
Audio: Very simple DMA support. I think a real Cube loops the sound; WhineCube does not.
3D GX: FIFO implemented, some interpretation done. I see a thread in the near future. Textures is an enigma.
EXI: Basic EXI implemented. No DMA yet. Tentative, but working, BBA support.

12:38 2004-03-01
Major reorganization of hardware memory hook system. Additional rewrites of the hardware side may become necessary.

14:40 2004-03-02
DynaRec underway. DynaRecBlock usage notes: One block per recompile(). I think not knowing how exactly big the block is going to be at the start of recompile() will be possible. recbuf and the rcbtb will be copied from the current_ vectors at the end of recompile(). A bunch of requests will be needed.
02:53 2004-03-03
Cross-block static jumps defeats the idea of a 'current' block at runtime... well, not necessarily.
03:40 2004-03-03
I'm starting to think it may be a good idea. :}
00:03 2004-03-06
It was. However, there is considerable fragmentation of the blocks in certain DOLs, which may considerably degrade performance. I have three ideas on how to improve this:
*Instead of always creating a new block at the end of recompile(), the new block may be appended to an existing one if the new start address matches the existing end address. This method will probably have a margin ofa single PPC instruction, 4 bytes.
*The reverse of the above, an old block appended to a new one, or and old block appended to a recently fused block.
I now realize that all of these methods requre reallocation and thus re-responding to old Requests, which in turn would require storing those requests permanently, which would probably be best managed with a temp_drbv, which would be used to regenerate the entire executable drbv at the end of a recompile(), or possibly a complete_recompilation().
*If there is a small gap between blocks and the gap is small enough, it may be force- or pseudo-recompiled and used to further reduce the number of blocks. There would have to be a maximum size for this, probably some percentage of the total number of recompiled PPC instructions.
These schemes seem complicated and should not be implemented until proof of their need/efficiency are created.
14:12 2004-03-06
The DynaRec is up and running. :)

16:38 2004-03-19
I have an idea of an exception catcher for the recompiler. It involves considerable overhead, though, and quite possibly an intermediary for every different function called. Not fun. :}
16:26 2004-04-30
No need. Regular exceptions work now...

15:13 2004-04-28
testdemo4 works!

20:51 2004-04-30
v0.3 should introduce the Thread.

09:01 2004-02-03
BBA: Maybe I'm thinking too low-level. Maybe it can be done using IP_RAW, emulating Ethernet and ARP, forgoing WinPCap <== good thing :)
01:26 2004-05-25
Nope. IP_RAW is teh 3vil.

17:15 2003-08-04
BE WARE of absolute relative jumps when changing ANYTHING in the recompiled assembly. They often need to be changed.
10:28 2004-06-11
Labels implemented. Much better. :)

23:45 2004-06-13
OMG Weeee, texture decoding works!

19:08 2004-06-15
Loading is separate from the constructors since it may fail and we must handle it gracefully.
10:39 2004-06-17
Actually, no constructor should ever be able to fail, except perhaps for memory allocation.

10:40 2004-06-17
In Beta release history.txt, * denotes a beta note, which should be removed on full release.

22:25 2004-06-29
Improved DMA audio timing, now the sound in Snowlords works almost flawlessly. Tetris still needs some work, though.
15:38 2004-06-20
Tetris music works perfectly now, even in-game! :DDD Of course, all other sound demos doesn't work anymore, but I'll fix that in a jiffy.

12:47 2004-06-30
As for how to use it, if you're a programmer ,it's self-explanatory. If you're not, you have no need for it.

20:42 2004-07-19
	The interpreter reads and decodes each instruction as it's executed.
	This method is slow, but compatible with all sorts of self-modifying programs.
	The recompiler translates the GameCube program code to native x86 code before executing it,
	providing a massive performance boost at the cost of memory.

16:06 2005-05-27
XOR blend mode might be aproxximated by a lerp in a pixel shader.
19:30 2005-06-01
No it might not. Blender != shader.
