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 ... 43
1
Are you using R/B or Yellow ?
2
forsyz, are you using the US versions ?
3
Thing is, I actually never read a single GB tutorial. I actually started with programming on the TI 83+, which has the z80 processor. When I approached the GBz80, I understood it as a z80 stripped of a bunch of its instructions and with a few extra ones. Thus, I can't give you such a link. It will depend on what you need.

The custom language file is attached to this post. To install it :
  • Language -> Define you language...
  • Import... -> Select GBz80.xml
  • Close the pop-up
  • "GBz80" will be present at the bottom of the Language menu
    (Note : I configured it to be the language associated with .asm and .inc files)

BGB can't speed-up as much as, say, VBcrap, because it is less optimized. This is a consequence of better accuracy. It's a complicated topic. I got it speed up by 5x.

Now, there's just something I don't understand. What is wrong with the hex viewer panel ? The one under the code panel. This one shows raw bytes, so that's exactly what you need, yet you don't seem to notice it.
Also, if there is a byte that's misinterpreted in the code panel, note the address of the first byte of the code, hit Ctrl+G, type the address, and go. This will force BGB to interpret that byte as the first byte of an instruction. This doesn't work perfectly and may require some fiddling, but it's better than nothing.

You don't need to add a header. BGB will load even badly malformed ROMs (just telling you OH MY GOD WHAT THE f**k in the middle of the loading), and if you just put the code at $0000 it will show up at the first address in the ROM. So lol.
I'll maybe add a raw hex output to GBz80 to Items, but currently nobody requests it (aside from you and someone else) and I'm already programming something else, so I don't have a lot of time. tl;dr : I'll maybe add it, but it's not on my priority list.

The placeholder used classically is "inc b", but then there are a couple others. When you need a "filler" byte, check which registers aren't locked-up, and use an instruction that trashes another one. rlca, scf, etc. Second possibility is to use 3-bytes instructions, mostly 16-bit loads. The sky number of instructions is the limit !
4
Emulation & ROM Hacking / Re: Why i hate BGB
« on: July 20, 2017, 09:02:12 am »
How accurate is it ? Which test ROMs pass ?
5
Heya ! I'm the guy who wrote GBZ80 to Items.

The only real way of doing ASM -> hex is to use a bit of compiler, since .gb/.gbc files are just hex dumps of the ROM.
The way I do it when I need some quick and dirty stuff is using BGB's code editor, or the Big HEX List when items are also needed. (When developing 8F codes, it's not considered good practice to force the user to have invalid items, but invalid quantities are fine)

BGB has the "Run" menu, which I often use with "Call cursor" (allows calling a function easily). It also has "jump to cursor", "step" (single-step instruction), "run to next line" (single-step except if it's a call, which is entirely run), etc. It's AWESOME.

If you want to get into 8F/ws m, it's a good idea to be in touch with GB programming. I recomment Avivace's Awesome-GBDev list, which has some very good tutorials on how to program for the GB. This will help you learning the GBz80's assembly, which is very similar to the z80's, btw)
It also links to RGBDS, which is in my opinion the best platform to compile GBz80 assembly.


The "8F compatibility" list doesn't exist, but I can either suggest going the automatic way with GBz80 to Items (I recommend v3 'cause it's simpler to use, but I also have an English version of v2 lying around somewhere), or you can use the Big HEX List (link in the sidebar under "References")


To get the comprehensive list of RAM addresses, check out Datacrystal (link extracted from Flandre Scarlet's post). For the FULL list, go check out Pokéred (again, from Flandre Scarlet's), and more specifically the wram.asm file


My workflow for testing the code :
1. Write it (I use Notepad++ with a custom language on Windows, and gedit with a custom language on Linux)
2. Compile it with RGBDS or the Big HEX List, I use the latter out of old habit but you might prefer the first
3. Extract the hex
4. Paste it into your inventory with BGB
5. Save state
6. Run, maybe trace execution to check if all goes fine (#BGBsDebuggerIsMyWai)
7. If needed, load state, refine code, retry
8. Use GBz80 to Items to compile code into items
9. Publish (Using Firefox, this is totally not a product placement)


Okay, that was a huge post. But hopefully it will explain everything you need to know - oh right, I forgot : pokered is made to be compiled with RGBDS. Just so you know, that's the RGBDS syntax.

PS : I really recommend you read a tutorial on GB Dev, because that will explain how the Game Boy works, which imo is essential to understanding some things when toying with 8F/ws m.
6
Pokémon Discussion / Re: Brick the save file in R/B/Y GLITCHLESS
« on: July 18, 2017, 12:52:09 pm »
Method 3 is also defeated by trading a Pokémon that knows Teleport or Dig, if you didn't heal at Cinnabar.

I'll add a quick method to softlock even though it's not glitchless :
1. Don't obtain the badges for Surf or Fly
2. Use WTW to go to Cinnabar
3. Heal there
4. Drop any method of enabling WTW again (such as the required items for 8F/ws m)
You are now stuck ! :D
7
According to Aera, if the "Pokémon League" locations play the Pokémon Centre theme, it's all righty. You can do a BSoD test just to be sure.
Also the Jubilife-s are normal.
8
IIRC, yup. To cut down on costs, for example.
9
Arbitrary Code Execution Discussion / Re: w s m item codes thread?
« on: July 15, 2017, 11:18:28 am »
The 8F thread also contains ws m codes
10
Whoa there. Mew was indeed programmed into the game, sure. But first : it was a joke between devs. It wasn't supposed to be shown to the public.

The Mew Glitch is purely unintentional. If it allows to encounter Mew with this NPC, it's pure luck. It was never programmed in, rather, it results of a series of oversights in the games code. I can assure you, even if you can think "Yeah but to be so complex it had to be intentional", it's not. I could explain why.

But anyways, due to the very differences in the way the games are programmed, there's NO WAY such a glitch could be possible in Emerald. Also, Mew is NOT a glitch. It's some really programmed Pokémon. Fully programmed. Just not supposed to be accessed. You know, a joke. Originally, at least.

But I stress it, this memory is wrong. You probably did the glitch on Red, Blue or Yellow, but not in Emerald.
11
Has anyone ever explained why battling 'M (and others) causes the infamous "battle graphics are cut into stripes and said stripes flipped and swapped"?

What about permanently making a route laggy/outright crashing if the Trainer-Fly glitch is performed, the game is saved (by changing boxes) and reloaded, then the 2nd trainer is picked from the same route?

1. I believe it's because its sprites are too large. Same reason why it corrupts the Hall of Fame.
2. The glitch occurs because the game advances the map script after the battle, causing it to read invalid flags. This causes it to try and start a battle EVERY. SINGLE. TIME you take a step.
I can't exactly remember why, but sprites large enough will corrupt a flag that's normally only set by the Pokédex. You see, when looking at an entry in the Pokédex, the sprite is facing the opposing direction as in battle. Thus, the game has to both write the tiles flipped, but also it has to flip the order in which tiles are displayed.
However, battle animations assume this flag is reset, and put the tiles back in the "normal" order - though tiles are still flipped, hence the broken graphics.

The game does try to start a battle on every frame (even worse than every step : try opening your START menu... lol), and this makes it try to display a text box (hence disappearing sprites and, I think, random sounds).
12
Nope, AFAIK there's not. And I believe Gen II would deny the trade due to "bad Pokémon".
13
Generation I Glitch Discussion / Re: Save restoreation with 8F
« on: July 13, 2017, 06:34:43 am »
I think that was because it doesn't implement SRAM locking.

Basically, SRAM (the segment of RAM present on the cartridge that is used to store your save file) cannot be accessed unless you "write" a byte to the cartridge's ROM. When SRAM is locked, the CPU is denied access to SRAM, and the battery circuits are engaged (meaning if the cartridge loses power, the SRAM's contents will no decay). Writing any value that's not an "unlocking" one will lock SRAM again.
So, apparently the VC doesn't implement SRAM locking (because "lol what do we need it for ?"), and add to this that saving sets SRAM banks juuuust right... boom.

Also, to anyone wondering why viewing a sprite switches SRAM banks :
Sprites are graphical data, and thus take a load of space. So to fit everything in the cartridge, the developers came up with a compression system, but it requires a sizable chunk of RAM. Because the GB's WRAM is almost completely filled, the developers chose to use a bit of SRAM bank 0 - 'cause it's RAM before being "S"RAM.
Fun fact : right after the area where sprites are decompressed, is the Hall Of Fame data. Since glitch Pokémon's sprites tend to have sizes larger than what can fit in the decompression area, it overflows into Hall Of Fame data. Woopsies.
14
Problem is, interacting with NPCs has no influence over the game's RAM whatsoever (besides turning the NPC and displaying the textbox) so this isn't possible. Also the text "Myuuu..." is NOT present anywhere in the ROM as far as I know. So, I deem this impossible.
15
Generation I Glitch Discussion / Re: Save restoreation with 8F
« on: July 13, 2017, 05:12:22 am »
Because 8F makes the Game Boy's CPU run code outside of where it's usually done. If done right, you maintain the flow of code "in-bounds" (ie. the way you intended it), but if you made a mistake, the CPU can end up running any kind of code. Thus, possibly trashing your save file.
Pages: [1] 2 3 ... 43