Messages

61

General Discussion / Re: Relationship Status?

« on: November 23, 2011, 04:18:15 pm »

I was married, for quite a long time. But I put an end to it. Married too young, probably all the wrong reasons, etc. I just couldn't take it anymore and while I felt this social pressure/responsibility to stay married because of my kids, it always just conflicted to what I actually felt inside/core; that I was teaching my kids that living a lie is OK. I'm much more involved and can now be the parent I've always wanted to (instead of being forced into a specific male/authority gender role). I'm much more able to connect with my kids and without the conflict of the other spouse having polar opposite beliefs (and constantly arguing). I've been divorced for about almost 7 years now, and completely single (by choice). I've turned down quite a few advances and opportunities for a relationship over the years. This is the first time in my life that I can live for ME, and not particularly for something else (well, besides my kids). I love this freedom to do whatever I want. Though I do admit, lately I've been feeling a little lonely and thinking about when my kids grow up and leave (my older son is gonna be 16 soon). And then there's the fact that I now have almost nothing in common with the women that I'm particularly attracted too (mid 20's). The older I get, the more they just seem like kids to me (immature/inexperienced). Life sucks in that respect. Women my age look like school teachers from high school/middle school. No good. Shallow of me, I know. But whatever.....

62

Programming / Re: Inquiry into supporting PNG via a faux SNES 'chip'

« on: November 23, 2011, 03:47:24 pm »

Just curious, why specifically the PNG format?

63

General Discussion / Re: Dislike Autism and Aspergers, and call them Retards?

« on: September 22, 2011, 11:17:12 am »

You get that in English too, but not so much, I've seen it used for things such as fire retardant meaning something that delays fire. 

Incidentally in the UK we're actually quite hot on this sort of stuff.  You can't really get away with saying Spastic anymore as its deemed offensive to those with Learning Disabilities or special needs.  As a kid there was this charity that was called the Spastics Society, they had what the Americans would call a thrift store but what we would call a charity shop, they changed their name to Scope in the mid nineties due to the above and people started to call the special needs kids Scopers as a result.   

 I remember, quite a few decades ago, when I was in kindergarten (and first grade) back in '81 - we would use the term "LD" instead of 'retard' to insult someone. I guess it was the abbreviation of 'Learning Disabled". When I changed schools after that, I never heard anyone use that term. Your post just reminded me of that.  Sounds strange now to call someone an "el dee", but back then it was the norm of norms.

64

Personal Projects / Re: Megaman and other NES hacks for PCE

« on: July 26, 2011, 10:54:04 pm »

Updated main page of this thread. Small update to Megaman 1 (links to build on blog site). Started work on Megaman2 project now

65

Front Page News / Re: Translations: Nadia - The Secret of Blue Water Translation Finished

« on: July 21, 2011, 04:00:12 pm »

Here's an updated IPS patch that gets it working on Regen, which is supposedly more accurate than the other emulators I used to test.
I fixed the MOVE instructions in my assembler to specifically state "byte" access mode.

 Doesn't the assembler you used have the byte/word/long dot operators like most standard 68k assemblers? I.e. MOVE.b ($A10001),D0 to force a byte operation. If you don't specify a specific operand/chunk size, then the assembler just defaults to whatever. Funny, I thought there was a thread specifically addressing this issue, a number of months back (6-8) in one of the other area of the forums. Or rather, accessing odd memory addresses in unaligned offsets (non byte) on the 68000 and relative to Genesis hacking. I personally don't care for snasm68k for hacking Genesis stuff. It has problems over writing already defined ORG addresses. The only assembler I could find that specifically allows this for 68k, was ASL (http://john.ccac.rwth-aachen.de:8000/as/). Include the original rom as a binary at the start, and just define ORG points to reassemble over. No injection or copy/pasting assembled binary code back in the rom. Clean, organized, and easy to keep track of all changes (whether opcodes or replacement data defines). But I'm rambling, sorry.

 Btw, great work   Any chance of more Genesis projects in the future?

66

Front Page News / Re: ROM Hacks: Final Fantasy VI Advance Color Restoration Patch

« on: June 22, 2011, 08:40:51 pm »

What gave you that idea?  The game's palette was intentionally altered from the SNES original to accommodate the GBA's darker screen, an accommodation that is wholly unnecessary if you are using a DS Lite or a GBA SP 2.0.  There are already similar hacks in the database for the Super Mario Advance games.

 Well... previous games, like the SMA games you mentioned, is where I got that idea from. Now that you mention it, I do remember something about certain later model SP screens being better. But the original GBA was the core system. And games released on it specifically were design around the output color range of the system (or should have been, but there will always be incorrect PAR or color space conversions in developed games). And if that's drastically different from what is being seen on emulation, well... then there you go. There was also an issue with Gameboy Color systems vs GBA playing Gameboy Color (even some emulators have 'real colors' option for Gameboy Color). But now I can see it's more than just an emulation problem. So the answer to my question than is a simple; No, because there's a discrepancy between a range of GBA backwards compatible devices and even later parent/base model output differences. This patch fixes it for those devices.

In any event, considering that at least half of the colors remained unchanged, it is safe to assume that emulation accuracy is completely irrelevant to the subject at hand.

 I think the only safe assumption from that information, is that they only thought certain parts or colors were relevant and worth changing... which implies a certain level of laziness on their part 

67

Front Page News / Re: ROM Hacks: Final Fantasy VI Advance Color Restoration Patch

« on: June 19, 2011, 05:15:13 pm »

So this is a band aid fix for an emulation issue that hasn't been dealt with yet? Has the GBA emulation scene hit a wall or something?

68

Gaming Discussion / Re: Video game songs to fit situations in life

« on: June 16, 2011, 11:16:09 am »

Sorry, don't have a track and real life situation for it to go with. But this did remind me of something funny one of my friends did many many years back. He called up another friend of mine and ask him to come over (the apartments weren't that far from each other) - and not to bother knocking but to just come in. My other friend was walking in place and have 'town' music playing in the living room. I don't remember the game, but the joke was based on the idea that you instantly knew that you were out of danger when the 'safe' music started playing in an RPG. And usually town music. And some RPGs have even more safe sounding music, like maybe for your family's house or your room, etc. Ahhh to be young, bored, and actually have free time.

69

Newcomer's Board / Re: Help cracking encrypted text

« on: June 14, 2011, 09:24:59 pm »

The disassembling/trace option makes it too easy. Where's the fun in that?

The first one is at $193 and the second one is at $1CF, so they're pretty close to each other.
I don't know what you mean by the "same piece of dialog", but the second one is displayed after a mouse click on the first one. And yeah, same font.

 I suspect he wants to know if the strings are part of the same 'string'. Because the encryption could differ string to string block (i.e. a string or block of text is connected to a pointer). A 'key' per point(er/ed) block of text or data. 

70

Newcomer's Board / Re: Help cracking encrypted text

« on: June 13, 2011, 06:39:57 pm »

You mean, more examples of dumped text like in my previous post, or the script file itself? (which is very lightweight btw)

 I think more examples would help. Especially with reoccurring groups/pairs of the same characters (including spaces).

For example:

Code: [Select]

the breakup came

t  h  e  '' b  r  e  a  k  u  p  '' c  a  m  e
27 13 1A 13 11 01 16 1A 18 02 03 45 0D 04 1B 08
    \ /         \ /                        \ /
    $7         $15                        -$13
The above 'looks' like relative encoding. But there's not enough reoccurring pattern information in the example text to know for sure. It could be a re-arranged ascii table with relative encoding, or selective table and that header is the key. Could be ring buffer/overflow instead of signed relative (which is still a method of relative encoding, you just let the value wrap back into the ring buffer. I.e. forward moving relative values only.), etc. Could be a lot of things. More example and info is needed.

71

ROM Hacking Discussion / Re: Messing around with BGB's debugger

« on: May 25, 2011, 06:53:42 pm »

I contacted the author of BGB and he got back to me surprisingly fast. He said he would look into it including it for the next release.

 Another thing that would be nice to add to BGB (used it recently), is a branch PC history window. Something like the last 20 branch addresses (the address of the instruction itself), for any instruction that effects the PC in a direct manner like; a return, jsr/call, a jump, relative branching (conditional), etc. Like what mednafen has for PCE debugger. That way when you break on something specific, you can work your way backwards through the history window easier and faster to see the higher level code that called/initiated that specific event.

72

Programming / Re: SNES DMA Question

« on: April 13, 2011, 12:02:03 am »

Is the cpu halted when the DMA channels are in progress during vblank?  If not, would it be best to write a hook at the beginning of the NMI to do the transfer while the NMI code does it's thing? Or (assuming the cpu is not halted) can the cpu simultaneously write to the vram port while DMA is happening?

73

Gaming Discussion / Re: PC Engine CD emulator save states / save data formats, could use some help

« on: April 10, 2011, 10:42:48 pm »

Either the save files are compressed or encoded differently as none of these files contain the BRAM. BRAM has a start string of "HUBM". I couldn't find that anywhere in those files (tried reverse order too). I sound the BRAM file hander names and 2byte identifiers, but the bytes before (2byte for size and 2bytes for checksum) don't correspond to anything. So I think it just part of the ingame code that writes to BRAM files structure and not the BRAM context itself.

 Are you sure there are aren't any other files for the emu? Is there a BRAM file for each game or global for all games to share?

74

Gaming Discussion / Re: PC Engine CD emulator save states / save data formats, could use some help

« on: April 09, 2011, 11:44:35 am »

You have a save file right before the boss? Post a like and I'll see if I can convert to mednafen savefile format for you. (not the savestate file, the BRAM file).

75

Newcomer's Board / Re: How to hack ISOs

« on: April 08, 2011, 02:31:33 pm »

(or any other disk-based console)

 PC-Engine didn't use a CDFS system, so the ISO data tracks are just large binaries. There are no files according to a file table. You have to figured it all out on your own. Create your own extraction and insertion tools. Games access data directly as LBA sector offsets. The values are either hard coded or in a custom table in ram. Thought it has a 'track' relative offset that the LBA value is added to. SegaCD, from what I gather, works the same way. While it is ISO9660 compliant with a CD File table, I know of only 1 game that uses it. Willy Beamish, which makes it really slow (the game will load the FAT every time, then parse it, then load the data it needs). All other SegaCD games do what the PCE games to; direct LBA access via hardcoded values or some internal custom table.

 Do PSX games keep a copy of the CDFS table in ram the whole time, from boot?

76

Newcomer's Board / Re: Bonk's Adventure Tile sets

« on: April 07, 2011, 12:59:52 am »

NES, GB, or TG16 version?

77

Front Page News / Re: Translations: Kaze No Densetsu Xanadu II (PCE-CD) - Announced!

« on: March 26, 2011, 12:51:13 pm »

cpt. Misumaru Tenchi: All you're doing is repeating yourself. Your first or second post pretty much sums up your position on dubbing.

As for dubbing, I'll never understand zero tolerance on matters like this. Sure, I don't care for a crappy dub. But crappy is relative. And if you never heard the Japanese originals, then you don't have a bias towards it. I watched all of BGC back in the day subbed. The english dub is horrible. And even if it was great, I was exposed to the original so much that an English one will never compare. That's unfortunate IMO. Because I don't actually understand Japanese (yes, I can read subs without problems just fone. But if you can't understand the language, even if you can hear the emotional infliction in the spoken language, you're still not getting the full experience). Many other shows I watched in English dub first and have no problem not watching them in Japanese original dialogue. Cowboy Bebop, Ghost In the Shell series, Paranoia Agent, Mushishi, etc. Not only do I prefer the English dub, I can also put the series on and just listen to it while doing other stuff (like coding, etc). I don't even have to watch it (or always be looking at it). That and my sons can at least enjoy the shows/movies too.

 That said, hey SamIam. Hope this works out. I think the PCE community would be fairly open to this (at least the original gamers that had Turbo CDs back in the day. There were plenty of bad dubs in CD games, be endured anyway. It has charm nowadays). Plus, it's not like one is forced to used the dub. As long as it doesn't sound like Final Zone 2. And hell, even if it does sound exactly like FZ2 I'd still play through it at least once with the dub and then decide for myself afterwards

 Really wish the best of luck on this. Many have tried to pull together a dub crew for some PCE CD games (Ys IV being the most infamous in attempts).

 For the record, my younger son beat this game. He was 7 (almost when he beat it. I only had to help him out a few times (via a walk through we had to look up). At his age at the time, he was just learning to read English words. So he actually was able to remember and recognize some of the japanese kana words. As in what they corresponded to, without my help. I was impressed. The young learn fast.

78

Personal Projects / Re: Megaman and other NES hacks for PCE

« on: March 23, 2011, 12:19:23 am »

http://pcedev.wordpress.com/ <- the download and links section. I took down the hucard version. Only the CD version of MM is up there.

79

Personal Projects / Re: Megaman and other NES hacks for PCE

« on: February 28, 2011, 12:17:20 am »

 flamepanther: This might help:

I built all the sprite frames into 32x32 unique frames into vram (flipped frames are handled via the OAM table). This allows for 24 unique 32x32 detailed frames. I think that covers all of them (minus flipped versions). If not, I might be able to make room for more. The 32x32 sprite frames are stored as two rows of 32x16 (as seen in the above pic).

Piotyr: "on nes"? You mean the PCE version running on the NES?

80

Personal Projects / Re: Megaman and other NES hacks for PCE

« on: February 25, 2011, 06:24:11 pm »

Is there any info on CNROM, MMC1, and limited MMC3/FME7 mapper conversions with CHR-ROM yet?

 You mean, have I done anything with them? I did one MMC1 game, but it was originally UNROM. All other conversions I've done are UNROM so far.

Like to see that if so, Otherwise good luck,

Reason for Asking: I tried redoing your NES code in SNES ASM, But the comparsion with 65816 instructions (like used in your PCE version of $2002) needed have no equivelent!

 The instructions themselves could probably be converted over to 65816 itself. But that's not the problem. The problems is the system architecture. You'd pretty much have to re-write the video and audio emulation core for the SNES, among other things. Though you could probably use some of the same techniques. I dunno. My emulation core is writing to VRAM during active display. I'm not sure that kind of approach is gonna work out on the SNES. You might have to do something like a 1 frame base delay or such, to keep things/updates in sync (NES is updating vram during vblank, the realtime conversion/emulation to SNES side is going to take it out of vblank range. So you could just convert it to ram and then DMA it on the next frame. That complicates things though). That, or completely re-write all the tile/sprite/map routines to be native SNES format. That also means it'll be game specific. I purposely didn't take that approach, so that I could reuse my emulation cores for other games and gettings results very quickly (getting the game up and running within a few days work).



Update:

 I've traced, RE'd, and documented quite a bit of MM object/tile/map routines. I started adding a few hooks. Bisqwit's doc helped quite a bit, but it wasn't easy enough just to follow along by itself. I used it as a reference point to look at the code running in the game. But it was a big help. Many thanks to him and his doc.

 Update:
 
 After going back and forth about how to implement the sprite upgrades, I've decided to do it on an emulation level. That is to say, I upgraded the original NES OAM table since there was three unused bits:

Code: [Select]

    NES OAM attribyte byte:
   
          76543210
          ||||||||
          ||||||++- Palette (4 to 7) of sprite
          |||+++--- Extended
          ||+------ Priority (0: in front of background; 1: behind background)
          |+------- Flip sprite horizontally
          +-------- Flip sprite vertically
         
          Extended:
                  D2 = High palette bit
                  D4-D3: Sprite size
                        00b = 8x8   NES flipping based on 8x8
                        00b = 16x16 Native PCE flipping  (if upper palette bit set)
                        01b = 32x16 Native PCE flipping
                        10b = 16x32 Native PCE flipping
                        11b = 32x32 Native PCE flipping
 So now normal NES sprite behavior can co-exist along side extended sprites. This also means you can show more sprites on screen since the OAM table will be more efficient with the new sprite sizes.  There's also 8 subpalettes now instead of 4. Using any of the upper subpalette automatically puts you in extended sprite mode (i.e. no 8x8 cell size relative to flipping X/Y. If the sprite cell is left as 8x8, it'll be flipped as if it was in a 16x16 cell - whether you see the extra data or not). You don't need to use the extended sprite cell format to use 4bit pixel mode either.

 As for 4bit sprite cells (15colors VS 3colors), that support was always there just no NES equiv function. I'll make a pseudo sprite DMA command for transferring sprite pixel data to tile banks (for both 8x8 in 16 colors and native 16x16 cells in 16color format).

 Basically, making it so that you don't need to know any PCE hardware. Just hack it as if it were an normal NES game, just a with extended functions and graphics.