gc-forever - Gamecube/Wii Forums

To recompile GXPAND, I need cygwin on Windows, and DMD (D language) on 32bit systems (preferably, 64bits has a bunch of hurdles, and no support for mac.) I'm sure there are some Linux distributions that work with 32 or 64bit version. The problem is I can't get anything to work (I'm all 64bit ATM), and I need to test to see if increasing the ring buffer's size will solve the current issues. I've fiddled around for hours but can't get it run in the prompt. Anyone have some suggestions?

If you have such a setup, would you mind making a build with the following changes? Download GXGMA & GXPAND

Inside gxpand/src/lz.d

• Change size of ring buffer to 8192 or higher.

I could suggest virtualbox and running your desired bit. It's a very efficient way of emulating an operating system. No bugs, and works as if it was natively.

It's not emulation, it's virtualization. I know this is nitpick but it's not really the same.

I have a 64bit VM of W7. Might as well go pick up a copy XP for this kind of thing.

XP is dead. Use Win7 32 bit.

@iamdablasta

Holy shit, thanks! You just turned my shitty day into a milestone! I'm very happy to see this:

;)

StarkNebula wrote:@iamdablasta

Holy shit, thanks! You just turned my shitty day into a milestone!
;)

No problem, had the same problem once.

Streetwalker wrote:It's not emulation, it's virtualization. I know this is nitpick but it's not really the same. :P

ಠ_ಠ

iamdablasta wrote:

Streetwalker wrote:It's not emulation, it's virtualization. I know this is nitpick but it's not really the same.

ಠ_ಠ

bad example but:
GC emulates NES, SNES, Genesis hardware....
with Gameboy Player, GC uses the hardware (and a software disc) to virtualize the GBA....

Wii/Wii U backwards compatibility is virtualization.

megalomaniac wrote:

iamdablasta wrote:bad example but:
GC emulates NES, SNES, Genesis hardware....
with Gameboy Player, GC uses the hardware (and a software disc) to virtualize the GBA....

No, I completely understood that. Thanks.

It's kind of hw accelerated emulation actually.

Streetwalker wrote:Wii/Wii U backwards compatibility is virtualization.

Not really. There's no virtual hardware involved, the existing hardware is simply reconfigured.

Oh well you learn things everyday.
What about GBA/GBC ?

You mean the Gameboy Player add-on or GBAs connected as controllers?

No, the GBC hardware in the GBA SOC, like the Wii GPU in the Wii U's.
Another thing I thought about is Devolution.

I'm guessing it should be possible to use a Hex editor to manually change the ring buffer size in the gxpand.exe file:


lz.d

/// Size of the ring buffer.
private immutable size_t N = 4096;
/// Maximum match length for position coding. (0x0F + THRESHOLD).
private immutable size_t F = 18;
/// Minimum match length for position coding.
private immutable size_t THRESHOLD = 3;
/// Index for root of binary search trees.
private immutable size_t NIL = N;


gxpand.exe

0009BAB0: 50E04900 67782E62 696E6172 79737472 |P.I.gx.binarystr|
0009BAC0: 65616d00 00100000 12000000 03000000 |eam.............|
0009BAD0: 00100000 67784C7A 4465636F 64653A20 |....gxLzDecode: |
0009BAE0: 496E7661 6C696420 73747265 616D2E00 |Invalid stream..|


Little endian (32bit)

0x00100000 = 4096
0x12000000 = 18
0x03000000 = 3

0x00200000 = 8192

You fucking genius you :P
I seriously can't believe I didn't think of that considering how much time I've spent in HxD last month. I'll give it a go, thanks! :3
//
Nope didn't work :/
Well, to specify, it runs fine without the edit (maybe it's on of those "I thought" it didn't work things.) However, it cannot unpack Super Monkey Ball 2 stage files (yet to try with SMB1.) Odd :/

Hmm, I don't think that the "not enough data in stream" problem is caused by the size of the ring buffer:


F-Zero GX (Pal) st07.gma.lz

000000: D7AD0600 805C1300 BEEDF041 000004C0
000010: E7F714BD 80EDF00B 00005CF5 F116EF00
...
06ADC0: A780BF09 870073A8 070F70A7 FDA1C2EA
06ADD0: 4EB4B2A9 470F0096 BB07CD56 CF0CB2

Input stream size = D7AD0600 (little endian) = 0x06ADD7
Output stream size = 805C1300 (little endian) = 0x135C80

st07.gma.lz file size = 0x06ADDF = 0x06ADD7 + 0x08

-> Input stream size = st07.gma.lz file size - 8 bytes


F-Zero AX (Jap) st07.gma.lz

000000: 66A40600 60451300 BEEDF041 00000480
000010: E7F714BE F5F10B00 005CC0ED F016EF00
...
06A450: 8F5037DD 3100A27A 2E449239 279F764B
06A460: E74D365F EC32

Input stream size = 66A40600 (little endian) = 0x06A466
Output stream size = 60451300 (little endian) = 0x134560

st07.gma.lz file size = 0x06A466

-> Input stream size = st07.gma.lz file size !!!


So I'm pretty sure that the F-Zero AX Input stream size value is the main cause of the problem. For a simple
test to prove my theory, subtract 8 bytes from the Input stream size value (little endian!) of a F-Zero AX .lz
file with a Hex editor and try to decompress it with GXPAND.

I did some of those tests; not working. The prompt appears to be throwing an "Invalid Stream" error. (It would be helpful if I knew how to have the prompt always present rather than disappearing right away.) It has it's own debug though, with about 10-12 lines spewed out.

I just ran a test of adding 8 bytes to working .lz files, and it does get the "not enough data in stream" error. Why this does not work in reverse is rather perplexing.

I think I'm on the right way... I have dumped the RAM and found the entire extracted .gma there. You can find the .gma in the area of 0x80600000 to 0x80700000.

here's a screenshot of st110.gma's model listing:



EDIT: BG_TMP is the huge background object in st110. I scrolled down a bit (to the first gcmf flag) and changed the texturing information of 0x00020002 to 0x00000000. And the background went black! Yes, it's really the extracted .gma

EDIT: here's everything that's differently on the ram dump. it should be possible to get the actual .gma out off a sum dump, now.

I just stumbled over this ...

http://jul.rustedlogic.net/thread.php?pid=437519

I haven't tested it yet to see if it works with F-Zero AX/GX, but this LZSCdec tool looks like it might be worth a try.

The formatting of the GMA looks the same. I can't see any differences from here other than the added RAM values.