Search found 1382 matches
- Thu Oct 22, 2015 9:43 am
- Forum: Uzebox Emulator
- Topic: Too many stuff going on
- Replies: 9
- Views: 12357
Re: Too many stuff going on
I propose we merge this and you can proceed with any further optimizations (like CunningFellow's table approach). Can we evaluate the performance of Jubatian's uzem140-hacks branch combined with CunningFellow's uzem140-fast-pre-decode branch first? My hope is that when combined we at least end up f...
- Thu Oct 22, 2015 7:57 am
- Forum: Uzebox Emulator
- Topic: Too many stuff going on
- Replies: 9
- Views: 12357
Re: Too many stuff going on
Edit: Just noticed I can't run T2K full speed on any version on SDL2. Just short though. :( Two things that could be. Either SD card related. T2K hits the SD card very hard obviosuly. The other thing is - if the changes that Jubatian made for cycle accuracy improvements slowed down 2 cycles instruc...
- Thu Oct 22, 2015 7:00 am
- Forum: Uzebox Emulator
- Topic: Too many stuff going on
- Replies: 9
- Views: 12357
Re: Too many stuff going on
Hi guys, I can't follow all those topics, to many stuff going and there's seems to be different views on how to optimize. I have receive a pull request from Jubatian which seems good to me since it simplified the code by implementing emulation by cycle instead of by instruction. I loose between 2-5...
- Wed Oct 21, 2015 6:49 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 96991
Re: Get that emu faster
I though about doing the same in my run of performance optimizations, but I discarded it. This is far from being a trivial change, and I have experience on it (my RRPGE emulator's 16 bit CPU's ALU is realized with 32+ bit unsigned integers). For most part it works, but there are a few instructions,...
- Wed Oct 21, 2015 3:45 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 96991
Re: Get that emu faster
This change makes it 6.5 MHz faster for me: diff --git a/tools/uzem/avr8.cpp b/tools/uzem/avr8.cpp index ae90524..1e73f9f 100644 --- a/tools/uzem/avr8.cpp +++ b/tools/uzem/avr8.cpp @@ -1059,14 +1059,14 @@ u8 avr8::exec() currentPc=pc; const instructionDecode_t insnDecoded = progmemDecoded[pc]; - co...
- Wed Oct 21, 2015 3:21 am
- Forum: Off Topic
- Topic: Merging with Git without a loss of sanity
- Replies: 2
- Views: 5078
Re: Merging with Git without a loss of sanity
That sounds like good advice. It also seems to matter from which end the merge is approached. Merging a lot of changes into something, or doing the merge "backwards" and merging a small number of changes into a pre-existing set of larger changes. As an example, your change touched a lot of...
- Tue Oct 20, 2015 9:55 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 96991
Re: Get that emu faster
Some merging should probably be done beforehand, I also submitted a pull which again did some larger messing around in the instruction decoder to achieve cleaner cycle perfection. Does your PR fix cycle perfection bugs, or does it just make the code cleaner? These changes slowed it down for me ~5MH...
- Tue Oct 20, 2015 9:00 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 96991
Re: Get that emu faster
This change makes it 6.5 MHz faster for me: diff --git a/tools/uzem/avr8.cpp b/tools/uzem/avr8.cpp index ae90524..1e73f9f 100644 --- a/tools/uzem/avr8.cpp +++ b/tools/uzem/avr8.cpp @@ -1059,14 +1059,14 @@ u8 avr8::exec() currentPc=pc; const instructionDecode_t insnDecoded = progmemDecoded[pc]; - con...
- Tue Oct 20, 2015 5:26 am
- Forum: Uzebox Emulator
- Topic: Get that emu faster
- Replies: 90
- Views: 96991
Re: Get that emu faster
OK - I have made a branch of Uzem140 that reduces the switch statement in the AVR8 exec function down to a single level. It does this by pre-decoding the 32768 FLASH locations into a 32 bit structure of Operation Number (and arbitrary number that us uint8) Argument 1 ( the first argument of the ins...
- Mon Oct 19, 2015 10:42 pm
- Forum: Uzebox Emulator
- Topic: Timing issues in uzem140
- Replies: 26
- Views: 32722
Re: Timing issues in uzem140
One thing I noticed was that git merge wanted to put the part "//draw pixels on scanline" in the wrong spot That's exactly why merging should be left to the inventor! ;) I immediately knew how to resolve that conflict proper (since of course I got the same) as I did that part of the code,...