80540186 visitors

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

Pages: [1] 2 3 4 5
Personal Projects / Re: Zelda - The Ultimate Quest (ALTTP Hack for SNES)
« on: August 19, 2014, 09:29:18 pm »
Sorry dude, nobody actually believes you made your hack this broken on purpose

Newcomer's Board / Re: Increasing rom size and resultant bugs
« on: August 19, 2014, 02:47:14 am »
If this is about Demon's Crest, I actually documented its copy protection a while ago when exploring various Capcom SNES games for material which I've been too lazy to put on tcrf.net (but will eventually, I promise...)

Basically the game checks for SRAM and expanded ROM at two different times. I'll just paste my short notes below:

Code: [Select]
80875A: if $701FFF is mapped, set byte at $7E0EEB to $FF (during capcom logo)
829B33: if byte at $80FFC0 != 40FFC0 (mirroring), set byte at $7E0EED to $FF (when ???)
cannot pause/view menu

80E561: if $701FFF is mapped, set byte at $7E0EEC to $FF (when taking damage)
BEE356: if byte at $80FFC1 != 40FFC1 (mirroring), set byte at $7E0EEE to $FF (when ???)
opening boss (or all bosses/all enemies?) invincible

In an unheadered US ROM (don't know about other regions) you can change the bytes at 011B3E and 1F6361 from FF to 00 to get rid of the ROM-based protection, if that's what's causing your problems, otherwise feel free to post any other important details.

(For anyone interested, I also documented a similar but much crazier protection in Mega Man X here. I plan to add this stuff to TCRF and maybe YouTube at some point, but I'm lazy :P)

Personal Projects / Re: Kyuuyaku Megami Tensei 1 & 2
« on: August 10, 2014, 11:42:12 pm »
Don't use ZSNES

Newcomer's Board / Re: 6964 - Mysterious number in Hexadecimal guide
« on: August 03, 2014, 12:17:24 pm »
Both of the documents on RHDN under my name (uploaded 2012-2013) exhibit it, and if I play around with document IDs I can find some other plaintext documents uploaded around the same period of time that do the same thing:


Since the document in the OP is from 2009 I assume there are probably a lot more to be found, and I don't remember if I ever stumbled on any others myself at any point (I had completely forgotten it even happened, or else I would have said something already :P)

Newcomer's Board / Re: 6964 - Mysterious number in Hexadecimal guide
« on: August 02, 2014, 08:02:37 pm »
It's not just that guide, RHDN seems to append numbers to the ends of a bunch of text documents and I don't really understand why

0.91 is out, and adds some helpful pointers to the sprite select window for a few of the more touchy (but important) sprites. I'll probably add more helpful stuff later on as well.

Also, fixed two bugs; one is mine and an even bigger one was HAL's. Now a room can be the maximum size possible without the entire last screen (and a small part of the next-to-last-screen) having no tile-collision detection at all. This fix will be applied to the ROM automatically on saving.

Code: [Select]
v0.91 [2014-07-18]
- added usage info to some sprites on the sprite editor
  (currently only for warp stars, cannons, and switches; maybe more in the future)
- fixed two minor UI bugs with the tileset editor
  (subtract from tile # box works correctly now)
- removed a limitation in the game where all of screen 15 (and part of screen 14)
  had no collision due to the tile collison detection code refusing to read that far
  into the currently loaded map data for some reason
  (thanks to CornetTheory for finding this issue)

Personal Projects / Re: Kirbys bizarre adventure [Demo out!]
« on: July 18, 2014, 02:11:40 am »
There are actually a few rooms (I don't remember all of their numbers offhand) where those topmost rows of tiles were updated in the European releases to match the increased visible screen space:

They did a pretty half-assed job with it even there, though (some of the clouds and cacti still have no top...)

Programming / Re: Soul Blazer input lag
« on: June 20, 2014, 04:47:11 pm »
The COP opcode just triggers a software interrupt exactly like BRK does, and they're both treated as two-byte instructions. The second byte can be (and sometimes is, though not commonly on the NES/SNES) used as an actual operand; in this case, the interrupt handler uses it as an index into a jump table:

COP #$80 in Soul Blazer does this (I omitted a few instructions at the beginning):

Code: [Select]
$00/D627 A3 02       LDA $02,s  [$00:1FEF]   A:0000 X:0800 Y:0800 D:0000 DB:01 S:1FED P:envmxdIZc HC:0674 VC:000 FC:38 I:00
$00/D629 3A          DEC A                   A:9D71 X:0800 Y:0800 D:0000 DB:01 S:1FED P:eNvmxdIzc HC:0728 VC:000 FC:38 I:00
$00/D62A 85 38       STA $38    [$00:0038]   A:9D70 X:0800 Y:0800 D:0000 DB:01 S:1FED P:eNvmxdIzc HC:0758 VC:000 FC:38 I:00
$00/D62C A7 38       LDA [$38]  [$00:9D70]   A:9D70 X:0800 Y:0800 D:0000 DB:01 S:1FED P:eNvmxdIzc HC:0830 VC:000 FC:38 I:00
$00/D62E E6 38       INC $38    [$00:0038]   A:2980 X:0800 Y:0800 D:0000 DB:01 S:1FED P:envmxdIzc HC:0926 VC:000 FC:38 I:00
$00/D630 29 FF 00    AND #$00FF              A:2980 X:0800 Y:0800 D:0000 DB:01 S:1FED P:eNvmxdIzc HC:0996 VC:000 FC:38 I:00
$00/D633 0A          ASL A                   A:0080 X:0800 Y:0800 D:0000 DB:01 S:1FED P:envmxdIzc HC:1036 VC:000 FC:38 I:00
$00/D634 AA          TAX                     A:0100 X:0800 Y:0800 D:0000 DB:01 S:1FED P:envmxdIzc HC:1066 VC:000 FC:38 I:00
$00/D635 7C 38 D6    JMP ($D638,x)[$00:DE7A] A:0100 X:0100 Y:0800 D:0000 DB:01 S:1FED P:envmxdIzc HC:1096 VC:000 FC:38 I:00

So it's basically just a "syscall" sort of deal (like the x86 "int" instruction), but for the SNES :P

Site Talk / Re: Some questions about the wiki
« on: June 14, 2014, 08:04:48 pm »
I'm forced to use linebreaks for the readability (and even if you think they are not so useful, I can find examples where they must appear in the actual text, they are not only a way to make the source text more readable).

Use <br> tags instead

Personal Projects / Re: Kirby's Dream Course editor (version 1.12)
« on: June 14, 2014, 03:44:50 am »
Just another small update, 1.12 fixes some goofy display issues that the rewritten 2D display in 1.11 introduced. Links in the OP as usual.

I got lazy for a few weeks, then I suddenly got productive for some reason after that. Then this happened.

Almost everything I wanted to be in this editor is now done. There are a few things left (mostly UI polish) but this is quite nearly a finished product now until someone finds some crazy showstopping bugs or whatever. Have fun!

Code: [Select]
v0.90 [2014-06-12]
- new HTML documentation
- full tileset, BG palette, and sprite palette editing
- editing of "stage clear" and star switch reveal areas on overworlds
- some text changes ("level" replaced with "room" or "stage" when appropriate)
- allow pasting beyond 64 tiles in either direction; this was a limitation that managed
  to survive being copied from KDCEditor without being updated for the real maximum
  height/width of Kirby's Adventure maps (thanks DarkMatt)
- more new icons (by Reimu)
- sprites and exits outside of level bounds are no longer shown, saved, or editable
- tile edit window displays tile numbers in hex
- opening non-Kirby's Adventure ROMs now displays an error instead of continuing

Script Help and Language Discussion / Re: Japanese text
« on: June 10, 2014, 05:54:46 pm »
Yep, that looks like Japanese text alright.

Small correction: HiROM (almost always) maps banks $C0-$FF and mirrors to $40-$7D, although obviously that same size limitation still applies.

ExHiROM (aka the Tales of Phantasia way) is probably the best/easiest solution - keep banks $C0-$FF at the beginning of the ROM file like normal, then expand the ROM to add more 64kb banks that will be mapped as bank $40 and up.

You'll also have to relocate the header from offset 00FFC0 to 40FFC0 in the ROM file, since the ROM portion of bank $00 is mirrored from bank $40, not bank $C0.

Programming / Re: Any easy to use side scrolling game creators?
« on: May 27, 2014, 08:32:29 am »
Do you expect there to be something easier than Game Maker?

Programming / Re: [SNES] Is CMP #$00 necessary in this situation?
« on: May 21, 2014, 08:20:23 am »
AFAIK it is wrong to expect that Squaresoft's games are all masterly programmed (just because they are masterly concepted).

I find this is true of big-name software in general, not just Square games :P

Programming / Re: [SNES] Is CMP #$00 necessary in this situation?
« on: May 20, 2014, 01:18:08 pm »
Nope, peepholes optimizers are supposed to remove this kind of things.

Although bad code produced by a (badly configured ?) compiler could be a valid explaination.

Most/all of EA's SNES sports games were written using a compiler, and it routinely did stupid things like explicitly allocating 0 bytes on the stack for functions without any arguments or local variables, so I wouldn't be surprised to see something like the OP either.

Then again, my first assumption was that this is a bit of code Mauron wrote themselves for feedback, rather than something found in an existing ROM (and if I had time, I'd let bgrep check for me  :D)

Programming / Re: Tales of Phantasia SRAM
« on: May 13, 2014, 12:39:25 pm »
I was able to read an extra 4kb of SRAM from B16000-B17FFF just fine using bsnes, though in Geiger's it (incorrectly) mirrors B06000-B07FFF instead.

I don't know if snes9x 1.52 or 1.53 fixes this. It's a shame that (imo) the best SNES debugger is based on such an old and inaccurate emulator version.

Programming / Re: Tales of Phantasia SRAM
« on: May 09, 2014, 11:36:26 pm »
How are you accessing the SRAM? I believe ToP maps SRAM slightly differently than most HiROM cartridges so that the original 8kb is at $806000, and if you added a second 8kb it'd be at $816000 (as opposed to the more typical $206000 / $216000).

Or maybe I'm misunderstanding the issue and Geiger's just isn't reading/writing the SRAM from/to disk correctly at all, in which case I have no idea.

ROM Hacking Discussion / Re: Changing rom size of snes rom
« on: May 09, 2014, 09:30:55 pm »
The rom size value in the cartridge header is completely ignored by actual cartridges and SNES hardware, and is in fact inaccurate in a few commercial titles. (I can't name any off the top of my head, but I know who to ask to find out...) If it's being polled by a flashcart, then that's a flaw in the flashcart's read logic and isn't a problem with the translation patch.

Super Noah's Ark 3D is one, if that counts (and most other unlicensed/bootleg carts I've seen don't bother with valid size info in the header either).

ROM Hacking Discussion / Re: Final Fight 3 NES MMC3 Hack Possible?
« on: May 05, 2014, 12:02:32 pm »
That said, MMC3 was not the upper limits of storage. The largest game to use an official mapper was Metal Slader Glory for the Famicom, which maxed out the MMC5 with a 512 KB PRG and a 512 KB CHR.

That's actually only half of the MMC5's maximum capacity for both PRG and CHR, though there certainly aren't any 2MB licensed games out there (and even the NES PowerPak, which supports the MMC5, doesn't support PRG or CHR ROM sizes larger than 512kb, unfortunately).

Pages: [1] 2 3 4 5