pret / pokegold Goto Github PK

Since I am not that familiar with how things are going but just a suggestion but should the way pokegold should build just similar to how pokecrystal builds where it processes all the images slowly and then builds the ROM together. I think this may have something to do with the Makefile.

As of 8a924f1, there are 1058 pics committed by my count. Up to this point, I have just been adding .1bpp/.2bpp/.lz extracted from the baseroms, and only creating pngs as a bonus. I have yet to bother attempting using pngs as the source for creating these files (as well as .gbcpal/.dimensions files, for pokemon and trainers).

Eventually, we'll want to do this. Places that will need to be updated to match how things are done in pokecrystal:

• Update Makefile with all necessary targets (see here for what it currently looks like in pokecrystal; also add a tidy target and update the clean target)
• Fix any pngs that don't happen to produce correct uncompressed binary files (i.e. anything not a .lz file)
• Update data/pokemon/palettes.asm and data/trainers/palettes.asm to INCBIN .gbcpal files, rather than INCLUDE the current .pal files
• Update all the files in data/pokemon/base_stats.asm to INCBIN a front.dimensions file rather than dn two nybbles with the frontpic dimensions
• Suffix existing .lz files with their md5 hashes (to signal whether the generated .lz file matches the binary in the baserom)
• Add lzcomp.c, md5.c, palette.c, and png_dimensions.c to the tools directory to support the above changes (currently assuming pokemon_animation.c and pokemon_animation_graphics.c are only relevant to Crystal)
• Update .gitignore to ignore all .1bpp/.2bpp/.lz files, and remove any remaining redundant files from the repo

There are a few mutually exclusive parts to this, so all of these need not be done in one step.

Edit (3-Jun-2020): I had some work started on this branch for the new lzcomp, which matched every PNG that existed at the time, except for Alakazam's backsprite in Silver. Will revisit soon.

See pret/pokecrystal#626 for more discussion.

162ea54c6a3cff374642e6dd842f9bffac847e7b *pokegold-es.gbc
9254195d461ea942eaaa08cc4b83de3cf82aea0d *pokegold-de.gbc
c147c0d8c2b71b7628a7233436f5c052b5b17081 *pokegold-fr.gbc
032608fe8947b627584a4a0eccc7bf9ad3588426 *pokegold-it.gbc
05bd978ab2cb104b0aff3f696896e30885203a18 *pokesilver-es.gbc
8ecc58d621faaedf2a934bd2583d527220df7bb9 *pokesilver-de.gbc
a4a7e8079b7a53e4d9ef43382bbb1090b9d45d1a *pokesilver-fr.gbc
c9eca9d0a837beb9137bb7d779e469c54e9f8d77 *pokesilver-it.gbc

The Japanese and Korean ROMs probably deserve separate projects:

8814f1039450a5d3684b1389f588ccd7ee7c3436 *pokegold-jp.gbc
c0ff3999e1093e1af59ef3eea3f1bfd7c1f18a65 *pokegold-ko.gbc
fa8c51059c1642faa570db56ef089f54d1d2011f *pokesilver-jp.gbc
cb22d7e03a74dc3a563fde6be8626626b2b392e7 *pokesilver-ko.gbc

As does the demo, it too deserves a separate project:

76fa60d66b2f22a035adc54c61aad9a415c894cd *pokesilver-de-demo.gbc

English versions were also leaked in the gigaleak yet I'm unsure what the filenames/hashes are for those

https://discord.gg/d5dubZ3

This is the last code file with more than one or two "unnamed" labels left. (There may still be others that aren't named after their own ROM address.)

Note that wram.asm also has unnamed labels relating to Mystery Gift and to link.asm.

Currently being disassembled by @libjet here: https://github.com/libjet/pokegold-debug

It builds the following ROM:

• MONSGD.gbc sha1: 539245e162123ceac77f0615e0eabddd8efb8b7d

The original build date is the 3rd February 2000, at 21:50 and the ROM was leaked on the 11th April 2020

*Silver TBD

A golddebug target that passes -D _DEBUG should work, since this is presumably the final release simply with Game Freak's debug build flag enabled. (Or -D _GSDEBUG to clarify that it's an "official" debug ROM, not a pret debugging feature.)

Right now it gives the classic "no rule to make target" error. This should probably also be fixed (see pokecrystal).

Placeholder for things we'll want to address soon after disassembly is complete and the baseroms are no longer required. We'll want to complete these tasks before any other changes are made to the repo. (Using pokegold for asm-based hacks also isn't recommended until these are complete.)

• Add Travis CI files
• Update INSTALL.md to remove instructions about baserom requirement
• Remove unnecessary tools / dr macro
• Ensure there are no remaining artifacts that interfere with shiftability, etc.
• Make decision on whether or not to sync macros/legacy.asm with pokecrystal
• Setup toolchain for building binary gfx files from PNGs (see #31)

(Will add more, if/when necessary.)

pokecrystal's tilepal macro takes a 0 or 1 as its first parameter, the VRAM bank. pokegold lacks this since it's SGB-compatible and only has bank 0.

Two disadvantages to not having this parameter. One, it has to be manually added if someone wants to drop SGB compatibility and use the CGB's VRAM bank 1. Two, it's not currently supported by Polished Map:

Supporting it would not be complicated, but I think it would be neater to add the always-0 parameter in pokegold, so it's easier to share tilesets between it and pokecrystal, and users can set it to 1 if they want to use the extra VRAM (or have some other use case for picking from 16 values instead of 8).

Any tips?

tools/unnamed.py lists just 13 labels that are still named after their addresses, all in wram.asm, all used only by engine/link/link.asm:

• wc508
• wc512
• wc80f
• wc8f4
• wc8f9
• wc9bf
• wca0e
• wca13
• wca84
• wcae8
• wcb4a
• wcb9e
• wce57

Closer reading of just what chunks of data are exchanged for battling, trading, and the Time Capsule should help identify at least some of them (they may be offsets within a multi-purpose exchange buffer).

data/pokemon/palettes.asm derives its .gbcpal color files from the back.png sprites, since there are separate front_gold.png and front_silver.png ones. But a few back sprites (like Jigglypuff) do not use all four colors, so those are special-cased to just use front_gold.png.

However, I'm not sure if this is actually necessary. When I run rgbgfx -c embedded -p back.pal -o back.2bpp back.png, using rgbgfx 0.6.1, the 2bpp and its palette correctly uses white, light gray, and black, as expected, and the palette even contains the unused fourth color:

$ xxd back.pal
00000000: ff7f 1f7e 067e 0000

Without -c embedded, rgbgfx packs the three used colors into the first three palette slots, sorted by lightness (with the fourth unused slot filled in as ffff):

$ xxd back.pal
00000000: ff7f 1f7e 0000 ffff

To do: see if this is reliable and we can use back.gbcpal with -c embedded even for cases like Jigglypuff. And, does it require 0.6.1 or 0.6.0?

 %.gbcpal: %.png
-	$(RGBGFX) -p $@ $<
+	$(RGBGFX) -c embedded -p $@ $<

Corresponds to pret/pokecrystal#1010

#define PROGRAM_NAME "stadium"
#define USAGE_OPTS "pokegold.gbc"

#include "common.h"

// A matching ROM has 128 banks
#define NUMBANKS 128
// ROM banks are 0x4000 bytes
#define BANKSIZE 0x4000
// A matching ROM is 2 MB
#define ROMSIZE (NUMBANKS * BANKSIZE)

// The Game Boy cartridge header stores a global checksum at 0x014E-0x014F
#define GLOBALOFF 0x014E

// ASCII "N64PS3" header (Stadium G/S was the third Japanese Stadium release for N64)
#define N64PS3SIZE 6
uint8_t n64ps3[N64PS3SIZE] = {'N', '6', '4', 'P', 'S', '3'};
// "N64PS3" + 2-byte CRC
#define N64PS3HEADERSIZE (N64PS3SIZE + 2)
// "N64PS3" + 2-byte CRC + per-half-bank 2-byte checksums
#define N64PS3DATASIZE (N64PS3HEADERSIZE + NUMBANKS * 2 * 2)
// The Stadium data is stored at the end of the ROM
#define N64PS3DATAOFF (ROMSIZE - N64PS3DATASIZE)

// The CRC polynomial value
#define CRC_POLY 0xC387
// The CRC initial value (also used for checksums)
#define CRC_INIT 0xFEFE

#define SET_U16BE(file, off, v) do { \
	file[(off) + 0] = (uint8_t)(((v) & 0xFF00) >> 8); \
	file[(off) + 1] = (uint8_t)(((v) & 0x00FF) >> 0); \
} while (0)

uint16_t calculate_checksum(uint16_t checksum, uint8_t *file, size_t size) {
	for (size_t i = 0; i < size; i++) {
		checksum += file[i];
	}
	return checksum;
}

void calculate_checksums(uint8_t *file) {
	// Initialize the CRC table
	uint16_t crc_table[256];
	for (uint16_t i = 0; i < sizeof(crc_table); i++) {
		uint16_t rem = 0;
		for (uint16_t y = 0, c = i; y < 8; y++, c >>= 1) {
			rem = (rem >> 1) ^ ((rem ^ c) & 1 ? CRC_POLY : 0);
		}
		crc_table[i] = rem;
	}

	// Clear the global checksum
	SET_U16BE(file, GLOBALOFF, 0);

	// Initialize the Stadium data (this should be free space anyway)
	memset(file + N64PS3DATAOFF, 0, N64PS3DATASIZE);
	memcpy(file + N64PS3DATAOFF, n64ps3, N64PS3SIZE);

	// Calculate the half-bank checksums
	for (size_t i = 0; i < NUMBANKS * 2; i++) {
		uint16_t checksum = calculate_checksum(CRC_INIT, file + i * BANKSIZE / 2, BANKSIZE / 2);
		SET_U16BE(file, N64PS3DATAOFF + N64PS3HEADERSIZE + i * 2, checksum);
	}

	// Calculate the CRC of the half-bank checksums
	uint16_t crc = CRC_INIT;
	for (size_t i = N64PS3DATAOFF + N64PS3HEADERSIZE; i < N64PS3DATAOFF + N64PS3DATASIZE; i++) {
		crc = (crc >> 8) ^ crc_table[(crc & 0xFF) ^ file[i]];
	}
	SET_U16BE(file, N64PS3DATAOFF + N64PS3HEADERSIZE - 2, crc);

	// Calculate the global checksum
	uint16_t globalsum = calculate_checksum(0, file, ROMSIZE);
	SET_U16BE(file, GLOBALOFF, globalsum);
}

int main(int argc, char *argv[]) {
	if (argc < 2) {
		usage_exit(1);
	}

	char *filename = argv[1];
	long filesize;
	uint8_t *file = read_u8(filename, &filesize);
	if (filesize == ROMSIZE) {
		calculate_checksums(file);
	}
	write_u8(filename, file, filesize);
	return 0;
}

Not sure if there is a need for a long-term miscellany issue, but there were two small blemishes I noticed glancing through the current state of the disassembly that I figured I'd note:

• Mangled address comment that never got removed here.
• Crystal-only happiness constant here.

The filenames and contents of audio/cries.asm and audio/sfx.asm are backwards. Cry_3A in this repository is Sfx_LevelUp in Crystal.

pokecrystal still needs the 24 for its "base" data.

-	unsigned int stadium_size = 24 + 6 + 2 + (rom_size / 0x2000) * 2;
+	unsigned int stadium_size = 6 + 2 + (rom_size / 0x2000) * 2;

https://github.com/pret/pokegold/blob/master/data/wild/johto_grass.asm#L1299

In this specific case, the encounter table for Route 33 matches Crystal, but not Gold or Silver.
This is the only issue I have so far.

The following sources appear to not be used in the build.

• data/pokedex/entries_crystal.asm
• data/pokedex/entry_pointers.asm
• data/pokedex/order_alpha.asm
• data/pokedex/order_new.asm
• data/pokemon/base_stats.asm
• data/pokemon/base_stats/*.asm
• data/pokemon/egg_move_pointers.asm
• data/pokemon/egg_moves.asm
• data/pokemon/evos_attacks.asm
• data/pokemon/evos_attacks_pointers.asm
• data/pokemon/names.asm
• data/sprite_engine.asm
• data/wild/fish.asm
• data/wild/johto_grass.asm
• data/wild/johto_water.asm
• data/wild/kanto_grass.asm
• data/wild/kanto_water.asm
• data/wild/swarm_grass.asm
• data/wild/swarm_water.asm
• engine/sprite_anims.asm
• engine/sprites.asm
• engine/sprites_dump.asm
• gfx/pics/animation.asm
• gfx/pics/anim_pointers.asm
• gfx/pics/anims.asm
• gfx/pics/bitmask_pointers.asm
• gfx/pics/bitmasks.asm
• gfx/pics/extra_pointers.asm
• gfx/pics/extras.asm
• gfx/pics/frame_pointers.asm
• gfx/pics/johto_frames.asm
• gfx/pics/kanto_frames.asm
• gfx/pics/pic_pointers.asm
• gfx/pics/trainer_pic_pointers.asm
• gfx/pics/unown_anim_pointers.asm
• gfx/pics/unown_anims.asm
• gfx/pics/unown_bitmask_pointers.asm
• gfx/pics/unown_bitmasks.asm
• gfx/pics/unown_extra_pointers.asm
• gfx/pics/unown_extras.asm
• gfx/pics/unown_frame_pointers.asm
• gfx/pics/unown_frames.asm
• gfx/pics/unown_pic_pointers.asm
• gfx/pics/*/anim0.asm
• gfx/pics/*/anim1.asm
• gfx/pics/*/bitmask.asm
• gfx/pics/*/frames.asm
• home/double_speed.asm
• home/mobile.asm
• macros/event.asm
• macros/sound.asm
• maps/GoldenrodDeptStoreRoof.asm

Full list obtained via:

# top-level sources listed in Makefile
toplevel='audio.asm data/text/common.asm data/pokemon/dex_entries.asm wram.asm main.asm home.asm'
for asm in $toplevel; do echo "$asm"; python scan_includes.py "$asm"; echo; done | tr ' ' '\n' | sort -u > includes
git ls-files | grep '\.asm$' | sort -u > sources
comm -23 sources includes

Including:

• The intro animation
• The title screen
• The credits
• The Burned Tower and Tin Tower scripts (Burned Tower has the Firebreather who turns gray)

It does not find "common_gold.o" in order to make gold rom. The following message appears after make:

$ make
make: *** No rule to make target 'baserom-gold.gbc', needed by 'data/text/common_gold.o'. Stop.

I have seen that this has been asked already but there has not been any resolution to this issue.

@PikalaxALT while you're at it, rename it pokegold.link to match red/yellow/crystal

e.g. BurnedTowerB1FEusineText in maps/BurnedTowerB1F.asm is some unused Entei text.

Please, can you find the real IsApokemon routine? I succesfully removed the isapokemon routine in Crystal to enable the view of the ????? pokémon's frontpics, but didn't work in Gold, I think 'cause isn't the same Crystal routine. Can you please find it to successfully remove the ????? pokémon's limitation to use them at least to see their pics?

That includes:

• the Coin Case glitch

; BUG: "done" is not a valid terminator here, needs to change to "text_end"
_CoinCaseCountText::
	text "Coins:"
	line "@"
	text_decimal wCoins, 2, 4
	done

• In HallOfFame (pokecrystal adds HallOfFame_InitSaveIfNeeded):

; Bug: Gold/Silver fail to (conditionally) erase the previous save and
; initialize the current save, if the player did not save on this playthrough.

• In CheckForLuckyNumberWinners (pokecrystal uses NUM_BOXES):

	; BUG: fails to find winning mon in boxes 10-14 if not the active box
	cp NUM_BOXES_JAPANESE
	jr c, .BoxesLoop