News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

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 - MarchHare

Pages: [1]
Programming / Re: SuperFX Assembler Reverse Engineering Project
« on: October 18, 2020, 01:53:46 pm »
Worth a look, for sure. I was hoping to at the very least be able to port the original tools to a more modern platform, since they're stuck as binaries, on DOS, using protected mode, with a DPMI server that wasn't even all that common, etc.

Programming / SuperFX Assembler Reverse Engineering Project
« on: October 18, 2020, 01:59:38 am »
So, I'm working on reverse engineering the SuperFX assembly tools with Ghidra. While I've made a little progress on my own, I think it might go faster with:
  • More hackers on it
  • Hackers with more RE experience
The goal here is to get the assemblers used for Star Fox and Star Fox 2 (diff assembler/linker pair for SF1 than SF2) reversed to some basic C code that can be ported to modern systems.
These programs were written by a C beginner (Dylan Cuthbert states that he was learning C at the time), so I don't expect it's especially complex or even obfuscated.

Why not simply write my own assembler and linker, you ask? Well, put quite simply, I don't know the exact specification of the ASM he's using, and I believe it also incorporates a 65C816 assembler as well, based on what I'm seeing. Also, I've never written an assembler.

So if anyone else wants to help out with this project, Ghidra DOES have a nice decompiler, so with more than one person, it might not take too long. Just message me here if you're interested, or privately if you prefer not to be known publicly ::).

Programming / Re: Building Leaked Source Code?
« on: October 18, 2020, 01:49:31 am »
I figured out how to fix the issue, but I still don't understand why the problem itself was happening. I'm guessing it might be an assembler bug.

Programming / Re: Building Leaked Source Code?
« on: September 08, 2020, 02:56:46 pm »
Yeah, I realised the tools were all in it. I successfully built Starfox 1, in particular after recovering a missing file that didn't get included with the dump.

Starfox 2 seems to have some issues in the macros involving public symbols or including files or something. I'm wondering if anyone has figured out what's causing the problem.

September 08, 2020, 02:57:32 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Where's the discord invite? Not so long ago, I would have been using IRC.

Programming / Building Leaked Source Code?
« on: September 05, 2020, 03:28:16 pm »
Has anyone had any luck building anything from the recently leaked gigaleaks source code?

I've successfully built Star Fox, but Starfox 2 is giving me some issues. IF anyone has built SF2, I'd love to hear from you.

I also noticed LttP sources. I haven't tried to build this yet.

(Note: This thread is intended to compare notes and help people get things building if they want to, not to share the leaked source. I don't want anyone getting shut down over it)

ROM Hacking Discussion / Re: Star Fox Object Dumper
« on: July 24, 2018, 02:32:19 am »
Interesting application of the idea. I don't know why, but it didn't work for me. I have a whole list of the models and their addresses and stuff. All but three of the referred-to data lumps were valid, with one minor exception where whoever programmed the model made a mistake when they entered the number of frames (the value in the rom is 0x20, but it should have been 0x14, which is 20 in dec).

Is your viewer working for the headered or unheadered rom?

ROM Hacking Discussion / Re: Star Fox Object Dumper
« on: July 04, 2018, 12:44:52 am »
So, more progress on this project. I've successfully extracted the textures, as well, based on information provided by VL-Tone and Dyson ( This isn't set up as a proper object just yet, but it's not particularly hard task.

I'm not sure if there are other texture lumps like this elsewhere in the 1.0 rom. Probably? Does anyone else know anything about these?

Does anyone know how one can make an animated material from static image frames? I am at loathe to collate multiple frames into a gif or video for blender or something. Especially for simple animated texs like flashing colors.

How does one attach a file to these posts? I would like to attach the real palette in gimp format (the palettes from the original VL-Tone gifs was jumbled around (colors seemed fine, but the color indices were different. Maybe they were from the 1.2 version?)

Edit: No, the 1.2 version has exactly the same texture data in the same place. I'm thinking that perhaps VL-Tone jumbled the palette when he created the gifs.

Include hash numbers for the unzipped/uncompressed files. Makes it easier to spot if one actually has the real file they want.

ROM Hacking Discussion / Star Fox Object Dumper
« on: June 19, 2018, 05:17:51 am »
Okay, so after a few years of off and on tinkering, along with a lot of wayback machine, I've managed to contact a few authors of older code (dyson and stef), and couldn't contact VL-Tone (Metroid Cubed, I think I read he died) who were working on RE the Star Fox data so they could implement their own engine. Those projects got reasonably far, and looked very good. However, much of that code was lost.

The Shockwave file by VL-Tone definitely purported to output the objects in obj format, but for whatever reason could not. Not only that, the interface had some major issues on every system I managed to get it running on. It looked great, but was barely a demo for practical uses.

Stef's code was great in that it gave access to the actual mesh data. However, it was unable to directly export to a model file. I could massage the original data it output to be useful, but this was labor intensive. Eventually I was able to reach out to Stef, who was able to provide me with his Java code that could probe down into the Star Fox objects. That was very good code. Once I had the java code, modifying it to not only output triangle and vertex data for be in stanford ply format was a breeze. However, the triangles were only used for the normals, as far as I could tell (each object also contains proper polygon face data in addition to the triangle list (!), and most objects, if reconstructed from the Tri List, would usually wind up missing a portion of a face somewhere (typically a square that had been triangulated in the tri list). Since I needed the regular face data (which also had the normals and textures), I needed to one up this.

Fortunately, he gave me permission to re-publish his code under GPL 3, and I was able to use portions of his code to create my own object dumper. Why? Well, partly because I could, partly because I know C/C++ and prefer it, and I wanted to reduce framework dependencies and improve portability. For now, this outputs the bare vertex and face data in Wavefront Obj format, suitable for use in Blender or any other model program you like. It outputs animated objects as filename_nn.obj, where nn is the frame number. You can use these as shape keys, with 00 being the base shape. I have successfully done exactly that with a few objects, just to see how they look (they would look much better with texturing).

You only need to know a few things: The actual addresses of the vertex data and facedata in the rom (and they are not required to be contiguous, some vertex lists are referred to by multiple different face data lists (essentially the same object, but in wireframe, different textures, etc, e.g. the arwing, the shadow arwing, the wireframe "shielded" arwing).

Future additions to the output will be the normals (which are per-face, so I need to see how this will pan out if I use different vn's on each face which shares vertices). For now, blender seems to compute the normals reasonably nicely. I would also like to implement scaling, since the game itself does scale these models. As part of that, I'd like to fix the models between -1 and 1, rather than the -127 to 127 they use now (not sure if anything used -128. I could probably add a test for that.) Further along, will be the textures and face colors. See my next note about this.

I'm still working on ripping textures. This will probably be a new object, since each palette is referred to by multiple objects, and each has multiple entries. If anyone wants to contribute to this project, let me know. My preference is to keep everything as clean as possible, while involving a minimal number of external dependencies.

Another thing I may try to do is implement a bare test that allows testing if the vertex list is valid separately from the face data. That might allow one to iterate through a rom specifically looking for model data. The changes to the object should be minimal, and the driver code can do the iterating.

You can pull my code from

So to summarize, I have posted the code. It works. I'm not making any guarantees. If you know where the model data is in other argonaut software games (various versions of star fox, star fox 2, vortex, stunt race fx, more?), please feel free to post your results using this dumper on them. Even better, please post your discoveries, data addresses, notes etc so I can try to incorporate them. The information I found seemed to indicate star fox 2 at least used the same format (the object headers used 30 bytes instead of 28 bytes {I found my rom used in the header list mostly 28 bytes, several 33 byte headers, and one 38 byte header. I'm working on that now})

Let me know what yall think!

Edit: Here are some objects to try out. AFAIK they're only valid on the headered 1.0 rom. You may want to paste them into libreoffice calc. All values are in hex.

Object Name   Object ID   Object ID (Std Hex)   Vertex Data Rom Address   Face Data Rom Address   Palette Rom Address   Scale (*2^n)
Shadow small high poly arwing   98BC   BC98   66201   66242   1827C   0
Small high poly arwing   B4BC   BCB4   66201   66242   18413   0
Big high poly arwing   D0BC   BCD0   66201   66242   18413   1
Helicopter   C4CD   CDC4   7B393   7B415   18413   0
Phantron (Transformation)   88C7   C788   75B16   76142   18413   2
Phantron (closed)   A4C7   C7A4   76324   7635C   18413   2
Andross Face morph   44D1   D144   7E49E   7EA86   18794   4
Andross Face morph 2   60D1   D160   7ED81   7F25B   18794   4
Andross 2 Evil Face   B4E6   E6B4   8E3FE   8EC22   18794   4

Pages: [1]