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

Pages: [1] 2 3 4 5 6 ... 9
ROM Hacking Discussion / Re: SNES power thought experiment
« on: January 09, 2017, 03:50:23 am »
I'm not sure what you mean by 'need'. Why do we need HD video? Higher resolutions opens up more creative possibilities (assuming the same amount of colors could be used).

 Because you're talking about a system, a retro system, with a specific design scope when it comes to capabilities and limitations. If you want something with less limitations, or more capability, move to dev'ing on a system from a different generation. Unless you need that resolution on the SNES that overrides the limitations that it inherits; thus the question. Is it possible to use that res to make an RPG? Yes. Do the advantages of a higher res out weight the limitations? That's for you to decide. The resolution is pretty much there for brag rights, more than practicality, just like the 64x64 sprite mode of the SNES.

But I guess that settles that, if the vram is a bottleneck.
VRAM is the least of your worries, if you not familiar with SNES homebrew/dev. SNES is not a beginner friendly system to learn to dev on (dev != hack).

Personal Projects / Re: Dragon Warrior 1 - ultimate patch and project
« on: January 09, 2017, 01:14:46 am »
Protip: "Bytecodes" are quicker to type.
For those of us that don't struggle with ADHD, the extra time it takes to type out mnemonics, and label names (!), is worth the trade off for clarity.

ROM Hacking Discussion / Re: SNES power thought experiment
« on: January 08, 2017, 06:37:43 pm »
Just to keep it short, I am curious about something that someone familiar with SNES architecture might know, but I'm not sure if anyone would know this for certain.

Aside from the difficulty of creating such a thing, let's say there is a SNES homebrew SuperFX2 support. Would that be enough to run in 'higher' definition mode (512x448), with decent speed? Something like a typical SNES RPG, such as Final Fantasy, Dragon Quest, etc. (no 3d effects).

 The first question I have to ask is.. why? For what reason do you need that screen resolution???

I have assumed higher definition mode wasn't used much due to slowness caused by more tile updates needed when scrolling, as well as to avoid NES-like scrolling glitches (as if you used the maximum resolution, the entire tilemap would be displayed onscreen with no room to render in off-screen map data gracefully).

Then again, when I think about it, the NES problem might be caused by its attribute table system. The SNES allows per-tile palette selection. I do think the problem with displaying the entire tilemap is the issue (which means to shift a row means having to redraw the entire tilemap and rewrite to VRAM which I think is more data than can be safely written to the PPU in one frame).
You can clip the display to be slightly less than 512. Hell, one of the Final Fantasy games on the SNES runs with a 240 horizontal resolution (256 clipped to 240 visible pixels). Only the BG layer is going to be double horizontal res and double vertical res, and not the sprites (they'd be only double vert res). But even at that, you're going to "loose" vram space because of the increased storage space for the same screen realestate as low res objects and tiles. Some layering and color transparency abilities are lost in high res mode. I wouldn't say it's necessarily slow or taxing (you don't need an SFX chip or such to use it), just that you loose so much to gain so little.

ROM Hacking Discussion / Re: Screenshots
« on: January 08, 2017, 06:26:41 pm »
Never understood the appeal of those kaizo hacks..

Personal Projects / Re: Dragon Warrior 1 - ultimate patch and project
« on: December 19, 2016, 12:35:12 pm »
Since you're dealing with code instead of data, it'd be more clear if you posted the code as mnemonics instead of hex values (or at least long with it).

Doesn't seem too unusual.
How is that not unusual? If you're writing code, in assembly or directly with hex codes, you should at least be aware of the fundamentals. After learning what registers are, what memory is, how to add/sub/whatever operations between registers -> subroutine and stack should be next on that list. I mean, stack pointers (one, multiple, "software" ones that have no specific hardware opcodes for it, etc) are fundamental to every "processor" post 1970.


What you're describing is sometimes referred to as "hooks" in assembly or hacking slang. You write a hook, and it might simply just jump to another piece and bypass the original code, or jsr (jump subroutine) to a piece of code that modifies data for the original code and returns back control to the original routines, or just monitor another routine and/or its data (spy on it, and set flags or states as indicators for later insertion code to handle). How much asm experience do you have? It seems rom hackers tend to learn it on the fly, as they need it for hacking. I thinking maybe a primer tutorial for assembly or just how processors work in general, and the basics (like stacks), might be something handy to reference for future hackers learning it - and asking questions. Stacks can be a safe way to save registers for your hook code, and restore them afterwards. Depending on the processor, and how the stack pointer is used, sometimes it's possible to use the end of a stack (or the beginning of it) as free usable ram - because it's guaranteed that a program or existing code won't ever touch it. Though that's a more advance technique in hacking.


Since posting this thread I have gotten comfortable with jumping to new code and returning back to the original function. However I think I need clarification on something:

Let's say I'm in a certain function that is using all the registers. I want to add a hack where in this function I can jump to another one that is completely different as opposed to jumping somewhere and simply modifying some of the register values for the orgigibal function. The new function will need to use the same registers to do its magic- will the values in the registers for the initial function be lost (over written) once the new function gets going? Or are those values "saveable" so that I can go through the new function and not have to worry about the original ones ref values being deleted or changed?

I should mention this is for the N64.

 Are you saying you're writing ASM code and you never heard of a stack before???

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.

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.

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

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

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