4dsdev
Views: 616,751 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 12-13-17 03:22 PM
Guest:

0 users reading no$gba v2.8c update - with more DSi emulation and DSi specs | 1 bot

Main - Reverse-engineering - no$gba v2.8c update - with more DSi emulation and DSi specs New reply

Pages: 1 2
nocash
Posted on 05-08-16 09:36 PM (rev. 2 of 05-08-16 10:52 PM) Link | #1003
Released no$gba v2.8c yesterday: http://problemkaputt.de/gba.htm

The emulator/debugger can now boot the firmware bootcode from scratch, and passes through wifi init, and allows to start games from within bootmenu. The main requirement is having the DSi BIOS ROM images, and a DSi eMMC image. And activating DSi emulation in no$gba setup, and deactivating the Start directly option.
Yeah, needing to change that options is a bit uncomfortable, but I guess that there aren't more than a dozen of people having the ROM/eMMC images anyways - I hope those few people will somehow figure out how to get the emulation working (or let me know if not).

The built-in help text (and gbatek.htm document) contain loads of new info about the DSi hardware and sd/mmc files.

One huge news is documenting the teak instruction set (thanks to normatt for creating a list of all 65536 opcode combinations). The 'small' remaining problem is that the teak memory map (and supposedly existing teak I/O ports) are still unknown.

And a very huge news is lots of info about the atheros wifi hardware and wifi firmware... there are lots of new chapters for wifi hardware registers, and lots of more chapters for wifi software protocol... I am hoping that those new chapters are covering almost each and every aspect of the wifi unit - except, one basic detail is still missing: I've no idea how to transfer any data packets.

----

07 May 2016 - no$gba version 2.8c
- webpage: added some dev forum links (http://4dsdev.org and http://gbadev.org)
- help: added "us" to known dsi-regions (including its countries and languages)
- dsi: re-ordered wram as C-then-B (fixes 3780000h boundary issue on us/sysmenu)
- dsi/wifi/help: added specs for WMI commands/events (and for BMI boot-commands)
- dsi/sdmmc/help: added sd/mmc state info (specs when/which command can be used)
- dsi/softreset: allows rebooting dsi firmware via NUM-* (reinit DSi registers)
- dsi: can boot NDS games from within DSi mode (tweaks non4MB via fake_scfg_ext)
- dsi: supports NDS-backwards-compatibility-touchscreen mode (for NDS games)
- dsi: supports NDS-bios-mapping in DSi mode (for NDS games booted via sysmenu)
- dsi: supports firmware-coldboot (when bios_intro enabled with nds_mode=DSi)
- dsi: bugfixed jumps in new wram via addr_code_table (fixes many DSi problems)
- dsi/help: added DSi Atheros Wifi I2C EEPROM info (access and partial content)
- debug/gui: fixed system colors used for cpu-flag checkboxes (swapped red/blue)
- dsi/help: added notes on dumping wifi bios, and on dumping dsi keys from 3ds
- dsi/help: added flipnote fileformat, added notes on \shared2\0000 file
- nds7: emulates disabled bios area being FFh-filled (define_nds7_bios_rom)
- aes: forces instant completion on aes-body-len-zero (boot sysflaw via sysmenu)
- sdio/wifi: initializes 0500458h to ZERO (indicating not firmware yet uploaded)
- dsi/bugfix: moved "sdmmc_try_drain_write_buffer" after status/state handling
- dsi: wifi init mimmicked good enough to run bootcode without WLFIRM 2 error
- dsi/sdmmc: supports card_irq
- dsi/i2c: omits ACK response on non-existing devices (especially A0h/E0h cams)
- dsi/misc: omits arm7 warning on 4004001h access, sets DSi flag in cart.chip.id
- dsi: emulates SCFG_MC register (else hangs after starting a game in bootmenu)
- xtensa: auto-resolves special registers mov opcodes to symbolic sfr_xxx names
- dsi/loader: supports loading AR60xxG.rom (for disass at atheros:8E0000h)
- dsi/mapping: supports MBK mapping to TEAK memory space (for teak disassembler)
- dsi/sdmmc: supports WRITE_MULTIPLE command (requires eMMC image with CID+ID)
- dsi: supports 32bit 4004D00h read, and more 16bit/32bit access for other ports
- dsi/jpeg/help: added notes on computing jpeg/exif MAC signatures (via AES-CCM)
- dsi/sdmmc: emulates fifo16/fifo32, irq-edge-triggering, fixed bits, etc.
- dsi/help: added lots of details on sd/mmc/sdio controller's I/O ports
- dsi/help: updated dsi exploits chapter (notes on resurrected dsiware hax, etc)
- dsi/help: addded teak instruction set specs (encoding, syntax, params)
- dsi/help: added atheros/wifi registers specs (for sdio side and xtensa side)
- dsi/debug: added teaklite II disassembler (see menubar, window, teak)
- dsi/wifi/debug: added xtensa disassembler (see menubar, window, atheros)
- dsi/wifi/help: added xtensa/cpu instruction set and xtensa/cpu register map
- dsi/sdio: partial sdio/atheros simulation (passing most of "PRE-AUTH" phase)
- dsi/help: added sdio specs (cmd52/cmd53 and cccr, fbr, cia areas)
- dsi/boot: fixed initialization of emmc-info in main ram
- dsi/help: added various details (initial ram, etc.)
- nds/debug: optional IPC fifo send/recv logging (in tty debug message window)
- dsi/bptwl: supports writing BPTWL registers (except invalid/readonly ones)
- debug/tty: displays sd/mmc command names, and resolves sdio func:addr's
- debug: accepts mirror of 3800000h at 3FF0000h without warning (common on dsi)
- dsi/help: details on tmd, tickets, and big-endian aes-cbc decryption

Normmatt
Posted on 05-08-16 09:58 PM (rev. 2 of 05-08-16 10:03 PM) Link | #1004
You put "http://4dsbrew.org" instead of "http://4dsdev.org/" in the change log.

I'm also still getting some debug prompts like "aes key ZERO" and trying to load anything from the menu results in an error has occured power off the system prompt
[image]

nocash
Posted on 05-08-16 11:10 PM (rev. 2 of 05-08-16 11:11 PM) Link | #1006
Posted by Normmatt
You put "http://4dsbrew.org" instead of "http://4dsdev.org/" in the change log.

Oops, thanks! Fixed it.

Posted by Normmatt
I'm also still getting some debug prompts like "aes key ZERO"

That message is shown when decrypting something with an AES keys that consists of all zeroes, which normally shouldn't happen - unless the key is "missing" somehow (like due to incomplete BIOS ROM image; there is some info in gbatak about which areas of the DSi BIOS can be dumped: http://problemkaputt.de/gbatek.htm#biosdumping ).

And what exactly were you doing? Did you have the "Start cartridge directly" option disabled? If yes, then the boot process should go through these disturbing steps:
- blank/white screen
- health/safety screen
- bootmenu with icons
There should be no "aes key zero" message during that steps (nor when clicking an icon).

Normmatt
Posted on 05-08-16 11:16 PM Link | #1007
It shows up during the health/safety screen.

I will verify that my BIOS dumps include all the keys... I must have missed one...

Opposing Force
Posted on 05-08-16 11:39 PM Link | #1008
Posted by Normmatt
It shows up during the health/safety screen.

I will verify that my BIOS dumps include all the keys... I must have missed one...

Post some hashes too please! Like to see if we're on the same page here.
BIOSDSI7.ROM - 2e17b63fc7ad43763f11226c96240ef1
BIOSDSI9.ROM - 3fbb3f39bd9a96e5d743f138bd4b9907
(md5)

I'm simply getting a black bootrom error screen:

[image]


Normmatt
Posted on 05-09-16 01:47 AM (rev. 3 of 05-09-16 02:57 AM) Link | #1009
I missed the
ROM:00008308h / 3DS:01FFD200h 80h some AES keys

however it still shows that error same as before on any software i try to load from the menu.
Posted by Opposing Force
Post some hashes too please! Like to see if we're on the same page here.
BIOSDSI7.ROM - 2e17b63fc7ad43763f11226c96240ef1
BIOSDSI9.ROM - 3fbb3f39bd9a96e5d743f138bd4b9907
(md5)

I'm simply getting a black bootrom error screen:

[image]


Make sure you do both both lists
First list search for the bytes in 3ds itcm and copy them across.
ROM:FFFF87F4h / TCM:1FFC400h (400h) (C3 02 93 DE ..) Whatever, 8x80h RSA?
ROM:FFFF9920h / TCM:1FFC800h (80h) (30 33 26 D5 ..) Whatever
ROM:FFFF99A0h / TCM:1FFC894h (1048h) (99 D5 20 5F ..) Blowfish/NDS-mode
ROM:FFFFA9E8h / TCM:1FFD8DCh (1048h) (D8 18 FA BF ..) Blowfish/unused?
ROM:00008188h / RAM:3FFC400h (200h) (CA 13 31 79 ..) Whatever, 32x10h AES?
ROM:0000B5D8h / RAM:3FFC600h (40h) (AF 1B F5 16 ..) Whatever, "common key"?
ROM:0000C6D0h / RAM:3FFC654h (1048h) (59 AA 56 8E ..) Blowfish/DSi-mode
ROM:0000D718h / RAM:3FFD69Ch (1048h) (54 86 13 3B ..) Blowfish/unused?

On a 3DS, the following "DSi ROM data" can be dumped from the 2470h-byte DSi key area in 3DS memory at ARM9 ITCM 01FFD000h..01FFF46F (via 3DS exploits that are capable of executing code on ARM9 side):
ROM:FFFF87F4h / 3DS:01FFD000h 200h RSA key 0..3
ROM:00008308h / 3DS:01FFD200h 80h some AES keys
ROM:FFFF9920h / 3DS:01FFD280h 80h whatever
ROM:0000B5D8h / 3DS:01FFD300h 40h AES keys and values (common etc)
ROM:? / 3DS:01FFD340h A0h misc "Nintendo" string etc.
ROM:0000C6D0h / 3DS:01FFD3E0h 1048h Blowfish for DSi-mode
ROM:FFFF99A0h / 3DS:01FFE428h 1048h Blowfish for DS-mode

my bios md5's are

BIOSDSI7.ROM - 559DAE4EA78EB9D67702C56C1D791E81
BIOSDSI9.ROM - 87B665FCE118F76251271C3732532777

EDIT:
Look like if I don't use my WIFI-DSI.BIN it works properly :)

EDIT2:
no$gba doesn't appear to like the sdmmc code used in sudokuhax I get
"notyet supported sd/mmc command 00000000"
"notyet supported sd/mmc command 00000008"
"notyet supported sd/mmc command 00000037" <-|
"notyet supported sd/mmc command 00000029" --| loops these last two over and over

nocash
Posted on 05-09-16 11:26 AM Link | #1012
Error: 1-2435-8325 is said to be "Invalid signature or partition type in MBR, invalid starting LBA"... ie. some problem decrypting eMMC data. The message is thrown by the code in eMMC bootsector, so it looks as if you DO have an eMMC image, and the bootsector loading step seems to have worked okay.
Do you have the Footer (see "DSi SD/MMC Images" chapter in no$gba) appended to the eMMC image? Most of the eMMC data (except bootsectors) need the console IDs from the footer for decryption.

Posted by Normmatt
no$gba doesn't appear to like the sdmmc code used in sudokuhax I get
"notyet supported sd/mmc command 00000000"
"notyet supported sd/mmc command 00000008"
"notyet supported sd/mmc command 00000037" <-|
"notyet supported sd/mmc command 00000029" --| loops these last two over and over

Yes, but the main issue there is that I don't have the external SD card emulated at all yet.
Current version supports only the sd/mmc commands for internal eMMC storage.

Posted by Normmatt
Look like if I don't use my WIFI-DSI.BIN it works properly :)

Hmmmm, did you dump the file from real Wifi FLASH chip on real wifi daughterboard? And is it from a DWM-W015 or DWM-W024 board? And is it from a 128Kbyte FLASH chip, or from one of those "smaller" FLASH chips?
DWM-W024 would have wifi type "02h" at flash offset 001FDh, causing the DSi to try to load the AR6013G wifi-firmware (problem is there is that I don't have one of those newer wifi boards, and so, can't really emulate that hardware revision).
And the "smaller" FLASH chips, I don't have one of those too, and don't even know what size they have.

nocash
Posted on 05-09-16 07:13 PM (rev. 5 of 05-09-16 07:17 PM) Link | #1013
Posted by Opposing Force
Post some hashes too please! Like to see if we're on the same page here.

Would depend on how much data you've dumped: The TCM/WRAM areas (from DSi main ram hack), or the TWL area (from 3DS), or (ideally) a combination of that dumps.
Here are CRC32's for the separate dump-able areas (you can use the "HxD" hex editor to compute CRC's on selected areas, for example), and the final CRC32's for the 'whole' file (as far as memory is dump-able yet)...

Checksums for BiosDSi.rom (20000h bytes)
Offset Size CRC32
00000h 8000h 5434691Dh ;\
08000h 188h ? ;
08188h 180h E5632151h (not 3ds) ;
08308h 80h 64515306h ;
08388h 3250h ? ;
0B5D8h 20h 85BE2749h ; ARM7
0B5F8h 10h 180DF59Bh (3ds only) ;
0B608h 10h E882B9A9h ;
0B618h 10B8h ? ;
0C6D0h 1048h 3B5CDF06h ;
0D718h 1048h 5AC363F9h (not 3ds) ;
0E860h 18A0h ? ;/
10000h 8000h 11E7C1EAh ;\
18000h 7F4h ? ;
187F4h 200h 4405D4BAh ;
189F4h 200h 2A32F2E7h (not 3ds) ;
18BF4h D2Ch ? ; ARM9
19920h 80h 2699A10Fh ;
199A0h 1048h A8F58AE7h ;
1A9E8h 1048h E94759ACh (not 3ds) ;
1BA30h 45D0h ? ;/
? A0h 180DF59Bh (3ds only) ;-whatever, "Nintendo" string etc.
Checksums for the 'whole' 20000h-byte file (with unknown/missing areas zerofilled):
180DF59Bh (tcm/ram dump) (missing 10h bytes)
03A21235h (3ds dump) (missing 180h+200h+1048h+1048h bytes)
CDAA8FF6h (combined dump) (missing only the unknown "?" areas)

For dumping the complete ROMs (without decapping), one could theoretically install debug exception vectors in RAM, and then reset the DSi, and then do something to provoke a debug exception (like sinking the power supply, or heavily overclocking the CPU for a moment - and then hoping that the CPU will react by throwing an invalid opcode exception).
Don't know how difficult it would be to do that - and if it would really succeed.
That possibly approach has been mentioned somewhere else, but I guess nobody has ever actually tried doing that yet?

Normmatt
Posted on 05-09-16 07:16 PM Link | #1014
You can also probably dump them using an IS-TWL-DEBUGGER as that seems like a full jtag debugger.

nocash
Posted on 05-13-16 07:50 AM (rev. 3 of 05-13-16 07:52 AM) Link | #1020
For SD Card emulation, does somebody know a utility for creating empty SD/SDHC Card images (with MBR and FAT)?
A .zip with several empty SD/SDHC Card images (with different sizes) would be nice, too.
For testing, I would currently need some small image with 16MB or so. But bigger images with more MB or GB might be also useful at some point.

Hmmmm, aside from the raw image, I would also need to have (or create) the ID/capacity info stored in CID, CSD, OCR, SCR registers. Preferably with authentic values that could be also found on real SD/SDHC cards with same capacity.
I am afraid that there's no utility (or dataset) for getting that values, or is there something... maybe in another emulator that emulates SD cards?

The other option would be dumping the SD card image AND the CID/CSD/etc from real SD cards. I have some 128MB, 1GB, 2GB, 4GB cards around - so I could dump those cards.
The advantage would be getting real authentic values. The disadvantages would be not getting clean/empty images (if the original card wasn't empty).
And, when releasing no$gba with SD Card support, it would appear quite foolish to prompt users to create the SD card image "by dumping a real SD card".

Posted by Normmatt
You can also probably dump them using an IS-TWL-DEBUGGER as that seems like a full jtag debugger.

Would be nice, but probably very difficult to find somebody who has the required hardware & software & knowledge on using it - for at least confirming if ROM dumping is possible or not. But yeah, would be great if somebody could check that!

gudenau
Posted on 05-15-16 10:56 AM Link | #1023
Posted by nocash
For SD Card emulation, does somebody know a utility for creating empty SD/SDHC Card images (with MBR and FAT)?
A .zip with several empty SD/SDHC Card images (with different sizes) would be nice, too.
For testing, I would currently need some small image with 16MB or so. But bigger images with more MB or GB might be also useful at some point.

Hmmmm, aside from the raw image, I would also need to have (or create) the ID/capacity info stored in CID, CSD, OCR, SCR registers. Preferably with authentic values that could be also found on real SD/SDHC cards with same capacity.
I am afraid that there's no utility (or dataset) for getting that values, or is there something... maybe in another emulator that emulates SD cards?

The other option would be dumping the SD card image AND the CID/CSD/etc from real SD cards. I have some 128MB, 1GB, 2GB, 4GB cards around - so I could dump those cards.
The advantage would be getting real authentic values. The disadvantages would be not getting clean/empty images (if the original card wasn't empty).
And, when releasing no$gba with SD Card support, it would appear quite foolish to prompt users to create the SD card image "by dumping a real SD card".

Would be nice, but probably very difficult to find somebody who has the required hardware & software & knowledge on using it - for at least confirming if ROM dumping is possible or not. But yeah, would be great if somebody could check that!


You could use dd and parted to make a formatted disk image from scratch.

nocash
Posted on 05-15-16 05:28 PM Link | #1024
Posted by gudenau
You could use dd and parted to make a formatted disk image from scratch.

That tools are available for windows?
If not: no$gba is a dos/windows utility, so prompting users to install linux for creating no$gba sd-card-images would be a bit weird ;- )

I've meanwhile dumped the MBR, FAT, and CID, CSD, OCR, SCR registers from my 128MB SD card, so I've at least some values to start with - and could probably modify them to simulate other SD card capacities (and hope to get that right).

Btw. I've been always wondering if it's possible to use more than one SD card.
For MMC cards, multiple cards are handled via the ALL_SEND_CID command (CMD2): Upon that command, the card with the smallest CID number is switched to "ident" state (and any other cards stay in "ready" state until sending futher CMD2's).
For SD cards, CMD2 does exist too. But the public SD card specs appear to refuse to mention if it's supporting multiple SD cards in same fashion as for MMC. But just came across this datasheet, http://www.altec-cs.com/downloads/Produkte/Flash_Speicherkarten/SD_Cards_miniSD_microSD/SanDisk_SD_Card_I-G_PM_1.0.pdf - which says "The host repeats the identification process (i.e., the cycles with CMD2 and CMD3 for each card in the system)." It doesn't really say WHAT happens upon CMD2, but it sounds as if CMD2 might be actually working as on MMC.
Did anybody ever try such a thing? Would be interesting if it's working technically (although I doubt that the DSi firmware/games support it). I'll need to gather components for making some SD/MMC Y-cable.

profi200
Posted on 05-15-16 05:38 PM Link | #1025
I'm not sure why you want to do that. Pretty sure neither the DSi firmware nor the 3DS one support that. But it might work with homebrew fine.

nocash
Posted on 05-15-16 06:13 PM Link | #1026
Don't know why, too. Or well, I just want to understand the SD/MMC protocol (and to get it documented in gbatek.htm). And the SD specs do contain some sentences that hint on supporting multiple SD cards (with different RCA's), but without explaining how to wire-up and initialize multiple cards - so that's somehow shouting for reverse-engineering.

In practice it would be rather clumsy and useless to attach an Y-cable to the DSi, and one could probably buy a SD card with bigger capacity at the same price as using two smaller cards with Y-cable.

profi200
Posted on 05-15-16 06:24 PM Link | #1027
PC less file copy jk :P

gudenau
Posted on 05-15-16 11:20 PM Link | #1028
Posted by nocash
That tools are available for windows?
If not: no$gba is a dos/windows utility, so prompting users to install linux for creating no$gba sd-card-images would be a bit weird ;- )

I've meanwhile dumped the MBR, FAT, and CID, CSD, OCR, SCR registers from my 128MB SD card, so I've at least some values to start with - and could probably modify them to simulate other SD card capacities (and hope to get that right).

Btw. I've been always wondering if it's possible to use more than one SD card.
For MMC cards, multiple cards are handled via the ALL_SEND_CID command (CMD2): Upon that command, the card with the smallest CID number is switched to "ident" state (and any other cards stay in "ready" state until sending futher CMD2's).
For SD cards, CMD2 does exist too. But the public SD card specs appear to refuse to mention if it's supporting multiple SD cards in same fashion as for MMC. But just came across this datasheet, http://www.altec-cs.com/downloads/Produkte/Flash_Speicherkarten/SD_Cards_miniSD_microSD/SanDisk_SD_Card_I-G_PM_1.0.pdf - which says "The host repeats the identification process (i.e., the cycles with CMD2 and CMD3 for each card in the system)." It doesn't really say WHAT happens upon CMD2, but it sounds as if CMD2 might be actually working as on MMC.
Did anybody ever try such a thing? Would be interesting if it's working technically (although I doubt that the DSi firmware/games support it). I'll need to gather components for making some SD/MMC Y-cable.

I *might* be able to make a stack that makes a directory act like a FAT partition.

Normmatt
Posted on 05-15-16 11:48 PM Link | #1029
Posted by gudenau
I *might* be able to make a stack that makes a directory act like a FAT partition.

DeSmuME already does that... so he could look at how that works and re-implement it.

nocash
Posted on 05-16-16 09:21 AM Link | #1030
Posted by gudenau
I *might* be able to make a stack that makes a directory act like a FAT partition.

Posted by Normmatt
DeSmuME already does that... so he could look at how that works and re-implement it.

Yeah, something like that is planned - sooner or later. At the moment I am focusing on getting the SD card CMD's and ACMD's working (and stick with a SD card image for now).

And creating a "virtual" SD card image from a directory: The creation wouldn't be too difficult.

Creating a "full" image (with actual data files in it) would be probably quite slow, so I would prefer to create only the FAT+directory (and keep the actual data file at their original locations) (ie. using some list that tells which "cluster" is in which file, and at which file offset).

The problems would be handling changes to the files...

The first issue would be if the file gets changed on the PC (by some other application). I guess one couldn't do much against that(?) or would it be possible (and desired) to "lock" all files in the directory?
Otherwise one could just tell the users not to touch the files during emulation.
Or maybe trap timestamp changes and force the emulator to eject-recreate-reinsert the SD card.
Any ideas how to handle that? Or info how DeSmuME is doing it?

And the other issue would be handling changes by the emulator: Changing/adding/deleting files, and somehow reflecting that changes to the directory when the emulation stops.
Or maybe even instantly reflecting it upon any changes to FAT or directory, so a file would get instantly deleted in the directory when the emulated software is deleting it in the SD image.

gudenau
Posted on 05-16-16 10:27 AM Link | #1031
Posted by nocash
Yeah, something like that is planned - sooner or later. At the moment I am focusing on getting the SD card CMD's and ACMD's working (and stick with a SD card image for now).

And creating a "virtual" SD card image from a directory: The creation wouldn't be too difficult.

Creating a "full" image (with actual data files in it) would be probably quite slow, so I would prefer to create only the FAT+directory (and keep the actual data file at their original locations) (ie. using some list that tells which "cluster" is in which file, and at which file offset).

The problems would be handling changes to the files...

The first issue would be if the file gets changed on the PC (by some other application). I guess one couldn't do much against that(?) or would it be possible (and desired) to "lock" all files in the directory?
Otherwise one could just tell the users not to touch the files during emulation.
Or maybe trap timestamp changes and force the emulator to eject-recreate-reinsert the SD card.
Any ideas how to handle that? Or info how DeSmuME is doing it?

And the other issue would be handling changes by the emulator: Changing/adding/deleting files, and somehow reflecting that changes to the directory when the emulation stops.
Or maybe even instantly reflecting it upon any changes to FAT or directory, so a file would get instantly deleted in the directory when the emulated software is deleting it in the SD image.

Should be able to make all the block operations operate on the files themselves.

Jhon591
Posted on 05-24-16 05:02 PM (rev. 7 of 05-25-16 08:58 AM) Link | #1034
Hi guys!

Can anyone help nocash with the annoying sound/cracking issue with certain games only ?, http://ngemu.com/threads/no-gba-v2-8c-released-07-may-2016.183657/#post-2481449

Some sort of noise suppression are Memory.dll sound - maybe ?

No$Gba Noise Remover (Author:?) posted by mateczko
Makes new super mario brothers playable with sound (Maybe it works for other games too)
http://www.wikihouse.com/ndsemu/index.php?plugin=attach&pcmd=open&file=Tool.7z&refer=NO$GBA

See a folder in rar archive ^ Only works with "no$gba 2.6a", if you are good!, that I'm NOT xd, Maybe you can edit it for latest version on no$gba ?

a.exe and a.ini - ini translated as

[Common]
Sleeptime=250 ; It will affect the frequency of the repetition processing. The default value is 250. The unit is milliseconds.
; When something processing time of the iterative process is waiting milliseconds a few minutes was four times to this value.
; Please try to increase the individual value, such as when it becomes heavy because of this tool.
: It might not be well making them too small.

Base=0x0100 ; Is the value you think that the last four digits of the base address. The initial value is 0x0100.
; If not found, if so to find the ultra-appropriate base address and this on the basis of
; I'm sorry in justification by faith, but try to find the address in the other tool, please try to change the value of here which was based on

ResetKey=0x01FB ; Which button to set what should you press when manually reset the sound (← turn off the noise process).
; And on the game you press this button for a while, and then reset the sound unconditionally.
; It is such a generally felt since the last decision of the iterative process because for a while.
; The initial value is L + SELECT at 0x01FB.
; It does not correspond to the X and Y buttons because somehow troublesome.
; I think that somewhere something like correspondence table of the button is listed in


[AutoDetect]
AutoDetect=1 ; When 1 noise handles freely to find a by likely sound riding (unfinished). The initial value is 0.
; How to find is because it is quite aggressive and very poor accuracy, because the extra sound well erroneous detection and treatment failure may become badly
; That time please try over again processing manually or try to turn it off.

ToggleKey=0x02FB ; If you leave for a while pressing the button of the value set here on the game, make the ON · OFF switching of automatic detection.
; Please try to use because it may become a thing terrible at detecting multiple erroneous by the game.
; The initial value is R + SELECT at 0x02FB.

Printf=1 ; It will be quite heavy so funny characters come out a lot and a 1. The initial value is 1.

SkipLevel=65 ; There is a possibility that extra processing also picked up for like a sound effect when a small increase.
; And I may be 0 Apart Nevertheless, part of the game (Toka Soma Bringer), the If you do not put a relatively large value
; Resulting in noise processing number of abnormally large number will increase.
; I think that is good about 65 in the rough game. 127 is the maximum.

FreqCheck=1 ; Initial value'll try to check a frequency appropriate
; Quite the process when set to 1 will increase, but not very effective. It is superfluous become badly

FreqSkipVoice=1 ; The initial value is 1; might skip Maybe you finely divided voice



; Because it does not check against the extreme numerical value when changing the value watch out!


Hope somethink could be done with it since no$gba 2.6a

Thanks guys all best in future!.

PS: my video is in link to view on this issue ^
Pages: 1 2

Main - Reverse-engineering - no$gba v2.8c update - with more DSi emulation and DSi specs New reply

Page rendered in 0.023 seconds. (2048KB of memory used)
MySQL - queries: 26, rows: 101/101, time: 0.012 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.