Gecko dotNET release thread (version 0.65 now!)

[dcx2]

An emulator is pretending to be, for example, a Super Nintendo.  Because it is pretending, all of the values are already inside the computer's memory, it doesn't need to transfer that data over USB like we do with Gecko.  So it's a lot faster for the emulator.

Another reason is that since you're emulating the processor, you know everything about it and you can change whatever you want.  According to Link, we don't know what ARM is doing, and even if we did, we still need the whole PPC, and there are some registers we can't just simply write to (like the floating point registers).

[Link]

Well, basically just compare the specs:
-the Roms for SNES are most likely like a few KB.. the SNES had less than 128 KB RAM and 64 KB VRAM of complete memory (and no seperate video memory).
So in the end.. the emulator only has to dump a few KB

If you already compare that to Project64 which emulates N64.. Project64 takes quite some time to take a memory snapshort.. although an N64 only had 8 MB of RAM (with expansion kit, without it was only 4 - video memory is shared).

Now these emulators have HI-SPEED access to the memory (as it is in your PC memory) and your harddisks are also fast. The USB Gecko connection is very slow in comparison!

Now let's go Gamecube:
-RAM: 24+16 MB
-16 MB of Video memory if I am not mistaken

Wii:
-RAM: 24+64 MB
-32 MB VRAM if I am not mistaken

So you see: we talk different numbers here!

[Dude]

I've had a quick look at the screenshots for Gecko.net and read the back posts and it seems to be shaping up to be all that WiiRD was and more :D  Not had a chance to try it out personally yet but I will in a few days.

I made a request in the GeckOS thread regarding decoding of binary bits in a byte, and since it seems that all needed work for this would be on the PC side, I thought I'd post the request here...hope that's ok.

Basically it is the ability to view a 8\16\32 bit value in binary form.  This is just for games that use binary bits for a "true or false" purpose for things like items collected and the such.  Also, the ability to modify the binary form and having the app turn it back into hex and write it back would be good :)

I'm not sure how easy (or possible) it would be to make GeckOS modify a solitary bit(s) using code-types but I think that having this function in Gecko.net would make finding the bit(s) sooooo much easier :p

Hope you don't mind the request again lol

[dcx2]

Basically it is the ability to view a 8\16\32 bit value in binary form.  This is just for games that use binary bits for a "true or false" purpose for things like items collected and the such.  Also, the ability to modify the binary form and having the app turn it back into hex and write it back would be good :)

Expanding a hexadecimal number into binary would be hard.  The text boxes aren't big enough.  Compare the relative size of the equivalent binary and hex numbers.

AAAAAAAA

10101010101010101010101010101010

I'm not sure how easy (or possible) it would be to make GeckOS modify a solitary bit(s) using code-types but I think that having this function in Gecko.net would make finding the bit(s) sooooo much easier :p

I added this as an Operation combo box beside the Poke button on the Memory Viewer tab.  You won't see it until Link releases a new build though.

PS: I've been using this thread to track Gecko dotNET feature requests so I suggest posting there instead.

[Dude]

Damn, sorry about that - I had multiples tabs open and clicked the link you posted in the other thread for bugs and feature requests.  I guess I closed the wrong thread :$  Sorry again.

Should I post (again :(  I feel like a nub lol) in this forum?  I think any more posts would be seen as harrasment lol

I did think that there would be a space limitation.  But it's just an issue with displaying?  Perhaps using a box with a bottom scroller and adjustable columns for codes would work?
I don't want you guys stressing or using up time that would otherwise be used for more important updates and additions, so this can be placed low on the list if it's considered worthy for inclusion :p

[Panda On Smack]

Link, I have found that the new search refining system is working fine but 1 problem I'm having is as the search jumps from 1 block to the next the game briefly continues to run in the background.

I noticed this initially with PES. I searched for a value mid game and as I refined the search the game skipped along slightly in the background. I just wanted to flag this up as I presume values will be changing if the game is in play and what may have matched your search criteria initially could be omitted by the time it finishes?

ta

[dcx2]

I can corroborate Panda's discovery.  I also noticed that the game runs a few frames inbetween the different blocks of the Block Search.  Therefore I almost always pause the game when doing searches.

Would it be as simple as pause and resume calls wrapped around the search algorithm?  Unless Link has a better idea, I'll try to implement that tonight.

Oh, by the way, be careful with the second search if your first search was unknown.  There are two bugs in that code path (I fixed both, but you gotta wait for the new build).  In the mean time, if your first search is unknown, do a search equals while the game is still paused so you can "skip" the second search (neither bug affects the equals search).  Subsequent searches after the second search are safe.  Also, I'm pretty sure all non-unknown searches are safe.

[Link]

I can corroborate Panda's discovery.  I also noticed that the game runs a few frames inbetween the different blocks of the Block Search.  Therefore I almost always pause the game when doing searches.

Would it be as simple as pause and resume calls wrapped around the search algorithm?  Unless Link has a better idea, I'll try to implement that tonight.

Oh, by the way, be careful with the second search if your first search was unknown.  There are two bugs in that code path (I fixed both, but you gotta wait for the new build).  In the mean time, if your first search is unknown, do a search equals while the game is still paused so you can "skip" the second search (neither bug affects the equals search).  Subsequent searches after the second search are safe.  Also, I'm pretty sure all non-unknown searches are safe.

OH wait.. pause, resume.. I forgot about that *lol*

[Link]

changes since 0.42 are (why 0.51 - because 0.42 accidently read 0.5 in the About tab) - all changes this time by dcx2:
-cancelling searches
-no more complete form deactivation during breakpoints
-Pause bug fixed for searches
-Searches can be stored and loaded
-Double clicking a pointer value in Memory Viewer will jump to the given address
-removing search results
-many under-the-hood bug fixes
-and some more

@dcx2: point to even more things if they are important to you..

Source and binary links have both been updated!

[dcx2]

Additional points of interest

-Re-sizable at last!
-Can sort search results by column
-Increased Memory Viewer auto-update performance to match WiiRDGUI
-Right-click in Memory Viewer now selects the cell before popping up the context menu
-Operation (write/AND/OR/XOR/add/sub) for Poke on Memory Viewer tab
-Poke during auto-update
-Up/down/pageup/pagedown working Memory Viewer and Disassembly
-Double click a branch in disassembly to jump there
-Always on Top checkbox (About page, will probably move in the future)
-Custom FPS adjustment to slow the game down (About page, will probably move in the future)
-Remembers some Memory Viewer/Breakpoint/Disassembly fields in case of shut-down or crash
-Auto-Preview with screenshots

There may be more, I have to check the svn log when I get home, but I think that's it

[Link]

dcx2 noticed some major bugs in the watch list (possible stack overflow).. so I quick updated the binary pack.. the sources have not been updated though ( I lack the time personally but the binaries should be fixed)

[dcx2]

FYI: 0.52 also has other small fixes, but the watch list stack overflow was a biggie...it would hit even if you weren't using the watch list.   :eek:

-Search results decreasing by 1 fixed
-Deleted search results bug fixed
-Dec -> Hex bug fixed (use right-click context menu)
-Various controls were becoming enabled when they shouldn't be fixed
-Search-Pause bug fixed, again...
-Added "MUL" and "DIV" to Poke Operations box on the Memory Viewer tab

[Dude]

I'm really liking the way Gecko.net is coming along.

Thanks for update!  :D  The search results decreasing by 1 on every search was an irritant and made me go back to using WiiRD since there was a good chance that I'd miss an important address.

Looking forward to trying out the update later.  As always, I'll be keeping my eyes peeled for bugs, etc.

Thanks for the effort you guys are putting into this software!  ;D  Keep it up.

[Jackal]

I think there is some bug with 0.52
I modified a line from the disassembly tab, something like "add r0,r0,r5" to "li r0,500"
or change it by GCT codes
the game would sometimes crash at the same point
however the crash doesn't occur when I use the old wiird

I am not sure how to provide you the details to pin point the bug
please tell me and I will post them here

[dcx2]

That is really odd, because I've used the disassembly tab a lot and I've never seen it freeze a game.

Let me see if I understand.  You went to the Disassembly tab, and found an instruction "add r0,r0,r5".  You changed it to "li r0,500", and hit apply.  Sometimes, but not always, the game freezes.

Does it freeze immediately?  After a specific amount of time?  After a random amount of time?  After doing a certain event in the game?  Have you tried pausing the game before applying the new instruction?  (it should be pausing it for you behind-the-scenes, but I'm trying to cover all the options)

You have also tried this using GCT codes.  Are there any other codes, in particular any C2 codes?  WiiRDGUI and Gecko dotNET 0.52 both have issues with applying codes after applying a C2 code (the first time always works though).  If you don't apply any C2 codes then you won't experience this issue.  I think I have a fix for that in the next release of Gecko dotNET, though.  However, you said WiiRDGUI doesn't have any problems.  So I'm not sure this is it.

What game are you using?  After the game freezes, have you tried reconnecting with Gecko dotNET?

You could also try using Poke to overwrite the instruction with the machine code for li r0,500.  If the bug is specific to the disassembly tab, this would work fine.