When I was trying out different scenarios to try and get rid of the “flicker” I had commented those out. I was getting a more sporadic flicker when those were not commented but it’s possible I was using a different technique at the time to write to the buffers. I know I still get flicker when I run it in the reality boy emulator but I’ll try it on the hardware and see if it’s any different. It made sense to me that I should definitely need to write to those but after a few hours of frustration I began to try anything and everything.

Yes, and I downloaded all the source code references from it which lead me to where I am now.

To give a quick answer to how I’m patching the roms right now I use 2 tools. A hex editor currently hexcurse (I’m a linux geek) and reality_boy compiled in debug mode. So to find characters (and I’m talking about the 8×8 pixel images used for all “characters” English and Japanese alike) reality boy will show all that information through the visual debugging screens. From there you just need to put breaks on the memory areas for CHARACTER RAM, BGMAPS, WORLDS, and OBJ’s to find out what instruction is writing to it a given point in the game and from there just start editing the rom in hex to change whatever you need. In the case of the most of the dialog on Space Squash it was as simple as replacing the character index for a Japanese character with an English character index. Other spots (where they decided to store character indexes as bytes instead of words) I had to overwrite the data areas that stored the compressed Japanese Characters with the compressed English characters and then I was able to modify the character indexes. The more complicated stuff like the intro story which was an entire compressed BGMAP I just re-wrote from scratch using their compression routine and English character indexes to replace the original BGMAP.

I’ve been away from the site for a while but I figured since my bro posted the patched ROM I’d add my two cents about everything I’ve found out about patching this Rom in case somebody much smarter than myself wants to take a crack at getting the final pieces into place for the translation. Space Squash was a bit of a challenge when compared to SD Gundam for example because of a couple of reasons. 1st It appears to me that this game was probably written in straight ASM by real ASM programmers (unlike myself who am just a hack). They maximized every ounce of space they could and one way the did that was using compression. It was very simple compression but compression non the less. This usually causes for example an entire BGMAP or CHARACTER RAM area to basically be a continuous stream of bytes that you can’t just jump into anywhere. They used a simple compression routine which starts with a bitmask followed by bytes or words(2bytes) depending on the bitmask. So for example a bitmask of C0 (1100 0000) means that for the next bytes you’ll read a word for each 1 and a byte for each 0. So the next string of bytes might look like (00FF)(00FF)(01)(02)(03)(04)(05)(06). I haven’t been working on this in a while but if the bitmask is a 0 then the byte represents the CHARACTER INDEX in CHARACTER RAM. If it is a one then (and here’s were I’m a little fuzzy right now) one byte of the word plus 1 nibble of the next byte tells you how many bytes back from current position to move in memory and the other nibble tells you how many times to loop starting from that byte going forward to copy bytes into the current position with a maximum of 13h (19 decimal) bytes and a minimum of 3 bytes copied at a given time. So using this simple compression 2bytes or 1 word can represent up to 19bytes of any sequence.
2nd The other thing they did commonly was store CHARACTER INDEXES as a single byte and use a constant offset to grab them from RAM. My other issue is that since the area of RAM that stores the offset is hit by like every single loop and function in the entire game I’m having a hard time tracking down the ASM code that is placing the offset into RAM for example to alter the in game character names and use English characters since the English characters are stored at a different offset in CHARACTER RAM. It would be fairly simple to change once the instruction(s) were tracked down but you can’t just put a break or watch on the memory area because every it breaks every couple of instructions. I tried for about an hour to trace through the ASM code to try to find it and didn’t get anywhere. At this point I’m not saying that I’ve completely given up but it’s definitely not at the top of my priority list right now.

I’ll probably give that a try here next week. My first post here was simply to share my last couple days of trial and error and give a starting point for the other 3 or 4 people who use Linux exclusively and wander on to this site :). Also, since I don’t have a lot of time to read through all the posts I didn’t actually know about the VBDE. I saw it mentioned but didn’t see it under the tools section of this site so I actually just thought it was a typo for VIDE. (Can you tell I’m still wet behind the ears with this whole VB Dev thing). I’ll use your links and see if I can get it running on Linux.

Thanks.

I’ve noticed at the initial start up of the emulator there is a significant lag time before the controls start to register. It’s about 30 seconds on my machine. After the 30 seconds are up if you’re using the default controls either ‘Q’ [start] or ‘Z’ [A button] should get most games to start moving. If it’s running slow after that you can increase/decrease frame skip using +/-. I know when I first started using the emulator I didn’t think anything was working either but I just wasn’t waiting long enough for everything to initialize. As for wine. To compile using the assembler program it should be as simple as
linuxprompt> wine /directoryToAssembly/VBASM.EXE hello.asm -o hello.vb

using the gccVB version 1.0 I actually run wine in cmd.exe mode in which case it would be
linuxprimpt> wine cmd.exe

windowsprompt> /pathTogccBinDir/make.bat /pathToSource/ sourcefile

notice there is a space between pathToSource/ and the sourcefile name. Also no extension is used as the make.bat file takes care of it. It’s all in the readme for gccVB 1.0

hope this helps.

[Greg Stevens]

I use linux on all my machines. I’m able to run reality boy just fine with wine (although it’s a little slow on my netbook… but it’s a netbook). In fact I used the reality boy debug windows exe to create the SD Gundam english patch Ben and I just released. I’m not able to get the most recent version of gccVB working either. Some kind of bug with the version of GCC that gccVB was based on I think… But the VBASM (assembly) compiler works just fine through wine. I can also compile with the older version of gccVB through wine if you want to download that one. I haven’t messed with it much but it will compile and run roms in the reality boy emulator just fine. If you try them on an actual VB though it doesn’t display anything. I’ve only messed with it for about an hour so it’s probably just something needing added to to the VB INIT function but I haven’t tried to figure it out yet.

• This reply was modified 12 years, 3 months ago by Greg Stevens.
• This reply was modified 12 years, 3 months ago by Greg Stevens.