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

Pages: 1 2 3 [4] 5 6 7 8 9
Personal Projects / Street Figher 2 CE for PC-Engine
« on: December 29, 2013, 09:26:49 pm »
Current researching/hacking the game. I'll post info here, as I get it (making everything public).

 Also, if you're bored/curious/interested - help out. The 6280 is pretty much 65x code, so if you've done 6502 or 65816 stuffs before, then this should be second nature. Mednafen is the debugger of choice - currently. Post any info here. I'll do the same. :)

 Some info to start:

 Backgrounds are compressed. It's a simple mask+constant compression, for 8 byte chunks. Sprites are uncompressed. Palettes are bitpacked compressed;first two bytes contain the upper bit (Green) for the 9bit entry - for a block of 16 values. 16 bytes follow.

 As I get further along, I'll start putting info from here into docs and submit them to RHDN docs section.


ROM Hacking Discussion / Re: YouTube/Google Video thread
« on: December 29, 2013, 09:20:38 pm »
For now, it's just the tilemap,tile,palette data that I can hack. But I plan to do a lot more with it.

General Discussion / Re: So are you guys conservatives or liberals?
« on: December 29, 2013, 02:36:03 am »
I'm none of those. I'm not even 'other'. 

What game are you trying to work on?

 Here's the rundown:
- Most main dialogue and stuff that uses 12x12 or 16x16 font, is almost always SJIS. The reason for this, is the huge majority of the system card bios (rom) is actually just a sjis table of 12x12 and 16x16 characters. The bios has a get char function that takes a sjis value and size, as the argument.
 - most CD 2.0 games use no compression. You can see the sjis plain as day in the data tracks (usually only 1 data track is the script and code, the last being a redundant data track, and any in between are either adpcm tracks or graphics for cinemas. The reason they break them up and interleave them, is to cut down on track seeking for segmented cinema loads).
 - most CD 3.0 games and later gen games DO employ compression. All of the compression schemes that I've seen, are LZSS based. Usually nothing fancy. But you can't see a lot of the sjis text because of this compression.
 - sjis is a two byte encoding. Very few games have single byte ascii support, at least for main text routines. Japanese sjis two byte still takes up less than English 1byte encoding. So assuming the game only supports 2byte encoding, and you don't know how to do ASM hacking (which for CD games is a pain in the ass, unless you find a way to get more ram - like upgrading the 'CD' to a higher level card), you won't be able to fit the english translation back in without cutting it down dramatically. The font spacing will also look like the infamous 't e r r a  a n i g m a' translation.
 - ASM hacking for CD games (especially 3.0 games) is pretty advanced. It's not uncommon for CD games to treat different parts/load of the game as completely different game engines. I.e You have to make multiple asm hacks. And it's possible free resources that you exploited to put in the hooks and new asm code, are in different areas and/or different in size for different areas of the game (Ys IV translation had this problem. So does Spriggan Mark 2).
- There isn't always room for a replacement font, let alone for new code (we ran out of space for the Super Raiden hack and that didn't even have replacement font routines).

 What would be nice, is if there was a new system card with a few more ram space (even just 8k of ram) - for making translations. You could cheat and use the SuperGrafx for extra ram (24k extra ram), but how many people have SGX let alone SGX+CD. Myself and a handful of other people in the world.

 Not sure what you goal is, but CD hacking on the PCE is not a beginners task. There are exceptions, but you'll have to look for those exceptions.

Personal Projects / Re: Megaman and other NES hacks for PCE
« on: December 27, 2013, 12:49:46 am »
How is the color palette handled since I know the NES handles color palettes a lot differently than the PCE. The NES has no standard color palette and relies on the TV itself, whereas the PCE has a much more standard setup.

 For the color/palette upgrades? That's handled via an extension that passes the palette data directly to the PCE hardware, instead of the NES video emulation. And that format is 9bit RGB (3bit Red, 3bits Green, 3bits Blue).

 Megaman2 is about 95% complete, public,  and beatable. Again, there's no patch file - so all links are in my blog site.

ROM Hacking Discussion / Re: Necromancer text compression scheme
« on: September 06, 2013, 08:47:50 pm »
If I understand it correctly, it sounds like a table-based Huffman tree.  The ones I've seen before were hard coded, so it's hard to tell.  :-\

 There appears to be a 4 byte header that sets all of this up, but the intro to the game puts hard/immediate values into place of reading from a header table. But in game, appears to be all called from a header table. Hopefully not too many areas/events are hardcoded.

 Edit: Ok, what was throwing me for a loop, was the offsets inside the huffman tree. I figured only variable/values would be there. But that's not the case. Weird. Guess I've never seen it implemented like this (or rather, I never wrote a huffman tree like this). If bit is 1, add the value from the tree to the pointer. If clear, skip two bytes in the table. Actual 'character' is encoded in 3 bytes in the table (pointer accumulators are 2 bytes) and this 'character' also preceded by #$01 - so that the pointer is incremented to align with the char (and not a terminator value of #$ff).

 They kind of missed an optimization. They could have added 'words' to the table entries as well, but appears only single characters are in the entry (once a valid character is read, the position into the tree is reset). Maybe 2 and 3 char groups don't lend well to Japanese/hiragana?

ROM Hacking Discussion / Necromancer text compression scheme
« on: September 05, 2013, 09:59:00 pm »
I've done quite a bit of work with compression schemes in the past, but this one is pretty unfamiliar to me. It appears to be some sort of binary tree compression scheme.

 There's two varaibles; a down counter (always re/load with a value of $07, check looks for $ff value) and an byte bit mask.

 There's also a table/block. Each entry is either 2 or 3 bytes long (though there might be an entry that is 4 bytes long, IIRC). The ending byte is always $FF. So something like $97,$ff,$07,$ff,$85,$ff. #$ff is the terminator of each entry (which means skip to the next). The mask corresponding bit determines whether to skip 1 byte or two bytes. If two bytes, then the value from the 'block' or tree is added to the tree/block pointer, helping incrementing it. When a non termination value is read, it's passed to the string build routine, and then the tree pointer is reset back to the beginning of the block.

 There's also another block and pointer. When the down counter expires, this pointer is incremented and the mask is reloaded. Neither the base nor the index of the tree access system is reset at this point.

 There's another layer of mechanism in place as well. At the very start of the call, there's a variable that stops the string routine from accumulating. When this variable expires (decremented; 00 = expired), then it will copy valid string data to the string build routine. Else, it just accumulates the second pointer position.

 Soo... does this description sound familiar? Sound like a binary tree compression scheme? I'm on the verge of figuring it out; just need to trace back to the top layer function calls and hopefully begin test (and text) extract trials. Any advice or comments?


General Discussion / Re: Leaving the house
« on: September 01, 2013, 08:46:13 pm »
"All the time!"
I kinda hate staying at home/in house. I go out every chance I get; except for coding. Coffee, book/reading, thrift shops, lunch, breakfest, to just ride my motorcycle around, etc. I'll drag my laptop around with me, if I need to do 'puter stuff.

Script Help and Language Discussion / Re: [PCE] Nazo no Masquerade
« on: September 01, 2013, 08:41:33 pm »
Hey MooZ! Nice work ;)

Personal Projects / Re: Mega Man 9 NES
« on: September 01, 2013, 08:38:03 pm »
If this gets completed, I'd definitely do a nes2pce conversion :)

Nice work :D Do you have the actual music format figured out as well?

General Discussion / Re: Steak Preference
« on: May 15, 2013, 07:54:14 pm »

I just superheat the pan for three minutes (applying a nice layer of aerosol butter before and after), then plop the steaks on for 90 seconds a side. When that's over, I use tongs to sear the edges for 10 seconds apiece; done!

Bloody steaks are yum.

 Yup. That's how I cook my steak. Unless I grill it, but it's the same way; super heat the grill and sear each side for 60-90 seconds (depending on the thickness). You have to eat it pretty soon afterwards, before it cools too quickly.

 That said, Outback Steak house makes some disgusting steaks. I had one where I couldn't even finish it, and I've eaten my share of shit-ass-food before.

ROM Hacking Discussion / Re: Rondo of Blood Audio tracks editing
« on: May 07, 2013, 01:50:31 pm »
Yeah, some PCECD games LBA for audio tracks and some use track #'s (the bios call excepts both arguments).

Personal Projects / Re: Megaman 1 and 2 for PC-Engine upgrade/hack
« on: October 25, 2012, 01:48:35 pm »
That is amazing, Mega Man 2 is by far the greatest entry in the series, can't wait to eventually play it on my Duo. Wily Wars was so shit with that delay between control input and action. Also excited about the PCE version of the soundtrack, I love the PCE's sound chip and can't wait to hear Wily's Theme pumped out through it!

 You mean remade PCMPSG tracks using the PCE upgrades? I'd have to find someone willing (and capable) of remaking the tracks for PCE's PCMPSG, but CDDA/redbook hack would be cake to do. Otherwise, it sounds the same (for the most part; I still need to complete the audio emulation): https://www.youtube.com/watch?v=ljtxuk9KDCg

Personal Projects / Re: Megaman 1 and 2 for PC-Engine upgrade/hack
« on: October 23, 2012, 12:38:54 am »
Megaman 2 is up and running (and beatable).

No front page news about this? Sad.....

Personal Projects / Re: Megaman 1 for PC-Engine upgrade/hack
« on: March 09, 2012, 04:25:31 pm »
I was getting a little dismayed by the lack of doc/info on the game. I mean, the partial disassembly doc is great (and that other one too that gives offsets to specific data) - but they're not complete. I had found the routine that takes the map meta-tile and gets the real tiles from - but not the upper level format. Thanks to Rock and Roll Megaman editor by Dan, I was able to binary compare mods and fill in the missing gaps of info I needed. So I think I have everything I need to hack the tilemap format to extend the total tiles from 256 (8x8) to 768. I should be able to run a hook that'll access alternate room format data to add extended attribute functions (upper tiles, higher number BG subpalette, etc) as it decodes. Hmm.. gonna see if I can get rid of the NES attribute block with something cleaner. Just gotta figure out how I'm gonna break it...


 Ok, I think I got this figured out. The tilemap routine writes a packet of data to a buffer. The buffer contains X number of packets to update vram with during vblank. Format: ppu address, tilemap data (16bytes), ppu attribute address, attribute byte. The hook reads an alt room data that shadows the current selected room, and if the alt room data points to extended tiles and/or attribute data - it alters the ppu *addresses* in the packet. I will use invalid ppu address that the backend emulation code would read and alter the tilemap and attribute data on the fly as it converts it to native PCE tilemap data. So for example: address $279f would become $479f or 679f etc.

Personal Projects / Re: Megaman 1 for PC-Engine upgrade/hack
« on: March 07, 2012, 09:59:58 am »
Neither : When I click on the exe, nothing happens. I think I've also tried to do it from the command line and nothing happened either. I haven't tried this for a while and I don't think I've tried to attach file extensions, so I should maybe try again.

 Ahh, yeah. Running without any parameters on the command line (or having windows run it with file associated with it), it'll do nothing, Like someone else mentioned, there is a GUI frontend program for it, but to be honest it's pretty minimal and once you setup the file extension to be associated with the mednafen executable - it's not even needed. So yeah; just right click the PCE file and clock 'open with', then select browse and find the mednafen.exe file. If you never associated a project for the file type windows, then 'open with' won't show up as an option. In that case, just double click the file and choose 'select from program list', then proceed to browse for file the mednafen.exe and choose it.

 Most stuff can be setup in the .CFG, but gamepad setup can be done in the emulator itself once it's running a rom. Just press F1 for directions once it's up and running. Alt+d gets you into the debugger and alt+1, 2,3, or 4 switches the viewable window/overlay (there's a document explaining all the debugger options and such).

Personal Projects / Re: Megaman 1 for PC-Engine upgrade/hack
« on: March 06, 2012, 11:46:06 pm »
Medfaden is probably the best PCE Emulator, it's just that for some unknown reason it completely refuses to run on my PC, not even an error message or anything, it just does nothing when I try to launch it.

 For hucard roms or for CD ISO games? For roms, I just associate the file extension in windows to the exe file. Cutting out the need for command line options. Of course I have everything setup in the CFG file for filtering and scanlines too.
For CD games, you need to setup the command line just once, or at least manually edit the CFG once - for the BIOS rom to run them. Then, do like with PCE files and just associate CUE files with the mednafen.exe file in windows. Instant launch when you double click the CUE file. If the emulator itself has a problem trying to load/run a game, it outputs a std.txt or err.txt or some file like that. And it's usually placed in the directory of the file you're trying to run (assuming you've setup the EXE as an association file type for the rom).

 Yeah, that emulator Bizhawk looks like it's for TAS type stuff - not a debugger. I recognize one authors on the project too, that hangs out in the mednafen channel.

 A little demo of the sprite work:

 I originally was hacking the meta tile related stuff for the sprites, but I've decided that I'm just gonna put a hook in there instead and read from my own tables - to write to $200 for sprite DMA (NES side).

Pages: 1 2 3 [4] 5 6 7 8 9