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 ... 9
Out Live (PC Engine) SRAM Hack instead of password.
You mean BRAM (external module for saving games). There is no SRAM on cards for saving. BRAM is a file system, so who ever hacks their own routines to access it - they better be 100% compatible else they'll screw up the file system and the player will have reformat it on the real system - losing all their other save game data from other games. This is no simple hacking matter. For CD games, you have a bios to make the calls (it's safe) - but for hucard games, without support for it, you'll have to write these routines yourself. Even some commercial games are known to have some bugs that will corrupt the BRAM system.

 I actually have BRAM interfacing code that I wrote and tested, but it wasn't design for hacking.

General Discussion / Re: How often do you use a dictionary?
« on: November 27, 2016, 10:02:13 pm »

But the ID number is what you're looking for.  And that's actually bad news.  This would be easier to edit if the palette assignment was in a separate table like the TSA.  But... since it's tied to the ID, you'll have to change cherries to be represented internally by a different ID.  Unfortunately that will likely mean updating all the maps, as well as any other code/data that uses ID numbers (which will be everything that interacts with the tile)

 Putting aside the assumption he's going to probably change the maps anyway (to add coins to whatever places), why not just write a hook in the appropriate place that looks for this (as it's passing through) and change it on the fly? On the "ID" level.

So far what I thought was going to be a piece of cake has been a bit troublesome, but I'm confident that I can find the result.

 Yeah, but it builds character ;) It all depends on how comfortable and capable you are with ASM. Break on the map update routine and work your way backwards to see how and where the game adds the object to the tilemap grid (or strip). There are probably two routines for this (build whole screen on respawn/start/etc, and one for map column strip updates). Else, you can also try corrupting areas in ram as you scroll the screen to see what triggers changes in the cherries being updates on screen (well, scroll into view).

There's no free area in rom that he can move stuff around? If that's the case, I'd check to see if someone hasn't already provided a patch to upgrade the rom to a different mapper - giving that support.

If you already know how to modify the attribute table, and specifically the byte entries, then it should be obvious that there are no background "objects". There are only tiles in a tilemap, as far as the NES ppu is concerned. If you're looking for game specific "object" data related to the background, well.. then that's game specific not anything to do with the PPU.

 There are only three things when it comes to palettes: palette attribute blocks that define/associate/set a 16x16 tile group to a specific palette set in a tile map (the byte entry represents 4 16x16 blocks), the palette ram where you load color associated "numbers" into the appropriate color slots (both for sprites and bg tiles), and lastly the sprite palette attribute in OAM. That's it. Anything else is higher level than that, and is game specific. Since you didn't mention any specific game, but your last post says you understand all of this, then I really suggest you go back over everything mentioned. Because it doesn't sound like you have a solid understanding of what you say that you do, by the direct of your question.

Look at the code posted, find the hex values for the opcodes and operands - then do a binary search for those values.

Those are quite harsh words so I went back over the thread. Questions were asked, they were then answered if they were sensible questions and if not the reasons why they might not have been the right path either in general or because a lack of experience would make it pointlessly hard were given. There were no insults and aside from a side still fairly relevant side conversations it was all pretty much on point.

I guess this is one of those "if you can't see the problem then you are it" situations. Though I am  quite content to call this a good thread and a good example of the forum doing what it does, if that is bad then meh I will stick around as long as it continues.

Anyway to the person who is starting out with hex editing, stop as it is not a skill or at least not a great way to frame things. You can learn to use a hex editor well and know the features of one, much like you can learn to use a word processor to do text formatting and layout, but if you lack a foundation in other aspects, or language if we are continuing the word processor analogy, then you are at best going to be able to hex edit at the direction of someone else, dictation being the word processor equivalent.
By all means learn what hex is (it is a numbering system, as computers tend to work in binary it is just 4 binary digits stuck together and as that means 16 combinations A through F get stuck on the end to represent 10 through 15 decimal) but there is a reason everything else is framed by what you might want to do (edit text, edit levels, edit graphics, edit music...).

 I kind of agree with this view point. As some point, a hex editor without knowledge of the system's processor or debugger (as in how to properly step through code and understand what it's doing), is going to be beyond inefficient. It amazes me to the lengths a lot of hackers go to in avoiding using something with soo much more efficiency like an emulator debugger, but instead limit themselves to dabbling around in hex editors. The fact that hackers also tend to avoid using an assembler, is also right up there. Then again, most hackers here aren't programmers. I'm not baggin on anyone in particular, it's just that hacking takes such dedication and figuring stuff out (self learning), and a whole range of intellectual skill and effort, that it makes me cringe when I see more than not - "backyard" approaches every where; bad habits learned early on.

What's the name of the game?

Because my problem IS solved.  I got the game to do 2K switches.  The reason why it wasn't working is because there was a conflict with the CHR modes, which was causing the CHR problems.  $5130 wasn't needed at all.
It's not really a conflict at all, when you think about it. Rather, it makes perfect sense. If you're in 4k mode, why would the mapper care about values in the regs of the lesser 2k sub segments, etc? I mean, you're in 4k mode because you want to swap in/out 4k at a time. The value in $5121 is irrelevant in 4k mode, so it's ignored and $5123 is read from instead (and as a 4k bank number) - etc. So when you switch modes, everything gets re-initialized for the correct mapping. Though, 're-initialize' is probably the wrong description for how it actually works on a low level, because those memory mapped regs are probably thee very same regs (not copies) that are used for the full address calculation in real time (no need to over engineer things).

ROM Hacking Discussion / Re: Help with hacking Dracula X (Rondo)
« on: February 11, 2015, 08:36:58 pm »
For the extra stage? I dunno. But this guy, and all his assets, are in the first stage.

 Yeah, I wasn't specifically asking for PCE hacking help (though hey, that would be great). I just mean in general hacking terms. Maybe it's something simple that I'm over looking.

 That, and I figured Konami probably reuses game engines and such, so maybe from the 16bit games they did have a similar engine (and by some luck someone has documented this). I have a few ideas, but it looks like this is going to be a major task trying to figure this out. Well, if it gets tedious or such, then I can concentrate on documenting the tilemap data at least. Maybe someone could implement that into an editor. 

ROM Hacking Discussion / Help with hacking Dracula X (Rondo)
« on: February 09, 2015, 10:07:23 pm »
I've had this info/knowledge for a bit: I found what appears to be a hidden super large monster in Dracula X for the PC-Engine CD.
Here's a few pics:

And some pics for what it might look like assembled:

I've messed around with the game and found the 'map' screen layout. This mini boss-ish character, is located right after the stage exit room: 01,02,03,04,05,06,05 ... with the first 05 entry being the sub-stage exit, and 06 being this boss character. Unfortunately changing this order does not effect any 'objects', AI, or any other attributes normally associated with that screen number.

 I can't seem to figure out the level engine/format. And to make matters worse, the game takes segments of ram in between code - so there is no specific section dedicated for 'ram' that I can spy on.. per se.

 Anyway, just trying to get some ideas. I spent quite a bit of time corrupting the ram areas that I know about, and found some related variables (but I haven't fully figured them all out; there are a lot of 'jump' table mechanisms for relative stage behavior). This being Konami, I figured that maybe they shared some design stuffs - that maybe someone could clue me in on? Or just different ideas to approach this. I've already spent a good amount of time tracing through asm, but my time is pretty minimal for this sort of thing at the moment.

February 11, 2015, 01:37:12 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
No one, huh? Hmm.

General Discussion / Re: Whatever happened to fan translations?
« on: January 12, 2015, 07:34:29 pm »
Outside NES/SNES there's a huge body of work left, especially on Sega consoles (except the SMS, that's close to 100% translated except for Korean games). The Genesis has hundreds of untranslated games, both Japanese and Chinese. Sega CD has dozens of RPGs and adventure games that haven't been localized. The 3DO has close to 150 Japanese exclusives, and while many of those are garbage, quite a few are very interesting games.

 Or the PC-Engine CD? Thee top rated RPG series for it, Tengai Makyou, still left untranslated.

ROM Hacking Discussion / Re: NES to Sega MD
« on: January 12, 2015, 07:25:14 pm »
Opps. Misread.

General Discussion / Re: NEW Super Mario Bros. 3 Returns
« on: January 06, 2015, 02:32:14 pm »

Gaming Discussion / Re: Donkey Kong Country Retrospective?
« on: January 06, 2015, 02:26:27 pm »
I was pretty excited when I got DKC the week that it came it out. But not far into the game, I found the gameplay and stage layout.. and everything - just kinda boring/repetitive and off putting - hollow? Something was seriously missing. The graphics and music were great, for the time, but it never felt even close to a 'Nintendo' brand game. It was more flash than anything else. It wasn't until years later, that I realized this wasn't a traditional Japanese Nintendo developed game, but game with it's roots from the Euro style of the time (which I can't stand, even to this day. Those games feel soulless to me, and so does the DKC series). SMW, a release game for the system at that, is far superior of a game to the whole DKC series on the SNES.

 Sorry for being a Debbie Downer, but DKC for me particularly represents a point in 16bit gaming era (SNES and Genesis), where I just lost faith in game developers and gamers/consumers in general. Where flash/style was far out weighing substance, becoming more predominate, and western developers seemly ever behind this push onto the masses. /Bows out...

ROM Hacking Discussion / Re: NES to Sega MD
« on: January 06, 2015, 01:48:52 pm »
Did you see the Video? So far I was Able to Run Metroid and Mario Bros on My Gopher using the Method above. Does it lag and Flash like crazy? Yes, but I am sure that it can be done. BTW I am willing to Reprogram Metroid (Nes) to work on the MD. I dont care How long it Takes. I just need the Instructions. OR willing to Perfect the Program above to Make it Work.

 I'm going to assume this isn't a troll post, and that you're actually serious about this endeavor. Here's what you need to do: 1) Learn how to program for the Genesis pretty much inside and out. 2) Then learn how to program for the NES inside and inside, or at least have a very solid understanding of how it works. Only then, can you attempt to formulate a realistic approach to this problem. Yes, there is more than one approach. If you want playable speed, it's not going to be emulation unless you can somehow seriously overclock the 68k cpu emulation on this handheld device. So with that in mind, you need to look at replacing pieces of original game code with native 68k code. You'll need to do this as well for graphic and sound functions - be it real time or replacement, or something in between.

 I doubt you'll do this, because unless it's solely for the sake of challenge - you could easily use a fraction of the amount of time it takes to do this, and just work/earn money to purchase a device that could emulate a lot more platforms on a handheld setup. But feel free to prove me wrong (I rather you would, to be honest. Because things like this are super cool).

 You're also in the completely wrong kind of forum for this sort of thing, because this out completely out of the scope of 'romhacking'. You need to be asking these kind of questions at retro based development forums (such as spritesmind and nesdev).

Personal Projects / Re: Game-2014 (homebrew game for PC-Engine/TG16)
« on: August 24, 2014, 06:40:23 pm »
232 pixels for height, because some emulators clip the screen (and some older TVs too). Same for status bar, 56 pixels in height instead of 64.

Gaming Discussion / Re: Homebrew related stuffs
« on: August 24, 2014, 12:25:43 pm »
Thanks, man. I've gone real in depth on the graphics end, but I actually meant as an artist only. Once Pyron wraps up, and a few of my side projects, I hope to find some homebrew developers to work with.

 Ohh, so you're looking more towards the pixel art side and game design, rather than the coding part? If so, keep me in mind. I have other game engines that I plan to mature into releases as well (side view action similar to megaman-vania, one that's smb-ish platformer, and a shmup).

Personal Projects / Re: Game-2014 (homebrew game for PC-Engine/TG16)
« on: August 24, 2014, 12:05:45 pm »
What should appear on each of these?

Status bar: I'm thinking player health (bar, segments, etc), player magic bar, Enemy health bar (for the one you just attacked), enemy name (above it?), current gold, XP (number or bar), weapon/item for each hand, regular item to use (press select). If you can think of anything else. Something along those lines.

 The game has items, weapons/armor (that you can change out), EXP, gold, special items, etc. Toying with the idea of doing 'stamina' or and charge systems for special attacks. So that could go on the status bar.
 Item screen could show a list of armor/weapons to equip (maybe Ys style?), items for use, special items for story events, stats (hp/mp/str/def/mag-attk/etc), save/load. The item screen would be more of a mockup, since I haven't implemented items and different weapons yet.

 Also forgot: the game is using PCE low res - so 256 pixels wide on the item screen (for now, unless I find a need for higher res on that screen later on).

Pages: [1] 2 3 4 5 6 ... 9