Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ISSOtm

Pages: [1] 2 3 ... 44
1
Debate Wars / Re: Riots
« on: Today at 11:42:21 am »
I don't see how this slipped from "anti-racism" to "communist", but please fill me in.
2
Emulation & ROM Hacking / Re: Emulating the Mobile Adapter GB
« on: Yesterday at 05:40:49 pm »
Maybe when Mobile Adapter GB emulation is finished, a patch should be distributed to modify the ROM to add some checking ?
Also, is there any chance to allow homebrew games to use the Adapter ? I know I'm getting ahead of everything, but...
3
@Háčky So you run the Python script, launch BGB, connect and transfer ?
Nice.
4
General Discussion / Re: The Member's Guide to Topiclessness
« on: Yesterday at 05:29:19 pm »
helooo
5
I guess it'd be possible to edit a Pokémon to be valid for GS purposes, if caught data has to be added that'd require ACEing Crystal. Complicated matters.
6
@harvey :
The thing with the game's save file is that there's a system to check if they have been tampered with. Thus, when modifying your save file, you need to change a few other bytes to make it valid to the game's save file loader.
The other option relies on the fact that the "main" data (ie. all saved data but Pokémon boxes) is transferred to WRAM when loading your save, and back to SRAM when saving.
Thus, you can :
1. load your valid save file
2. edit the byte in WRAM (RAM, if you want) containing the bit controlling the event
3. save your game (optional, since the event will be active, but for the sake of safety it's a good idea)
4. you got it !
Because there's no protection against modifying WRAM (and for a good reason : the game always modifies WRAM because it's its "workspace" !), you can freely edit it and have the game's saving code perform the checksum calculation for you by clicking that "SAVE" option !
7
Normally, there is a flag in the save file that controls whether the event is active or not. I don't think the JP version of Crystal has been disassembled, so you'd need to figure which offset the flags are stored at.
For the next part, I'd assume flags are laid out in the same way in the JP and US versions, so the flag would be at the same distance (from the base offset figured earlier). Then you just set the bit, and modify the checksums to avoid a "yer file is darn corrupted, sonny !".

Another solution is to simply edit the flag in the game's WRAM while it's running (which should be as simple as a GameShark code).
Again, this should be figured out fairly simply, I think memory in the JP and US versions is laid out quite similarly.
8
We need the tutorial.
9
forsyz, Coin Case ACE uses Echo RAM (since it basically runs code from there), and it didn't work with VBA because it didn't emulate Echo RAM.
The VC is known to emulate Echo RAM (as seen here), so Coin Case had to work.
10
Emulation & ROM Hacking / Re: Pokemon Crystal version korean translation
« on: August 07, 2017, 07:57:28 am »
There is http://github.com/pret/pokecrystal if you already used pokeyellow.
11
Generation I Glitch Discussion / Re: Editing VRAM
« on: August 03, 2017, 07:51:50 pm »
I'd recommend you join our Discord server, I'd be able to help more over there.
I'm pretty fluent with BGB and creating GB ROMs, so I could help there. Just make sure you're using RGBDS as your compiler suite, lol
12
Generation I Glitch Discussion / Re: Editing VRAM
« on: August 03, 2017, 04:09:25 am »
BGmotherf*inB.

BGB is definitely the way to go if you want to do shtuff of that sort.
You can either run a compiled ROM if that's what you want, or, if trying 8F thingies, the memory edition box supports
- Hex
- Strings
- Direct assembly code (yessss)

You can trace exec, modify registers on-the-fly, re-route exec wherever and whenever you want... and it's free.
(And the dev is a very nice guy)
13
Generation I Glitch Discussion / Re: Editing VRAM
« on: August 02, 2017, 05:43:30 pm »
It's also specifically tailored for the TI-8x+ calculators, so it explains a lot of things that don't matter on the GB, such as IO port,s BCALLS, etc.
14
Generation I Glitch Discussion / Re: Editing VRAM
« on: August 02, 2017, 04:21:53 pm »
If you're doing this via ACE, use what Parzival said above.
If you're wondering how to switch VRAM banks, you have to write to the VBK register, located at $FF4F.

If you're doing this via BGB, it's fairly easier due to the VRAM viewer.
Editing VRAM from the memory viewer can be done at any time, even when it's locked. To let you see locked VRAM, right-click locked VRAM or SRAM in the memory viewer and check "Force memory visibility".
To get a VRAM location, you can use the "BG map" tab.
Also, you can edit palettes directly in the VRAM viewer, just click on a color slot and edit the three shades on the right.
Want the memory viewer to go to VRAM bank 1 ? Easy, open the "Goto" box (Ctrl+G, or right-click -> "Goto") and type something like "1:9C00". Same for bank 0.
15
They aren't though the title of your topic is misleading : their behavior can be controlled. Without any complex manipulations.
Pages: [1] 2 3 ... 44