News: 11 March 2016 - Forum Rules, Mobile Version
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia

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

Pages: [1] 2 3 4 5 6 ... 148
Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 08:05:17 pm »
Interesting notes about those other things. I always assumed 00 (BRK) would just stop the game entirely. Still not sure I follow NMI or IRQ though, I'll need to read more about it, but in my hacking it's not something that's really been necessary to know. I did wonder how games would go into infinite loops (such as JMP to themselves, over and over) but still eventually continue the program counter. I guess it has something to do with the PPU saying "okay, next frame, get on with it". :)

Supposedly the better way to detect Vblank (than directly checking $2002),
is to do something like
Code: [Select]
LDA #$00
STA Flag
CMP #$00
BNE Loop

and then in the NMI route set Loop to a non-zero value.

One possible way of writing to VRAM is to format data in RAM (when it's time to write data to VRAM, you want the CPU to just blast it in there, not waste time calculating it).
Then set a flag that tells the NMI routine data is ready to be written. (the NMI routine would thus have code to read the formatted data and write it)
The weird thing about the NES PPU is that every time data is written to VRAM (even like tile data), the scroll registers need to be rewritten afterwards or the PPU freaks out, even if not scrolling the screen.

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 04:17:35 pm »
By soft reset, I mean reboot the game directly, without returning to the BIOS screen. (similar to how on a Wii, when you push Reset while running a GameCube game, it resets the GC game but doesn't drop you back at the system menu)

A "vector" is a 2-byte pointer to each of the three functions in the CPU's address space.

NMI is "non-maskable interrupt". An "interrupt" is a piece of code that is named because it makes the CPU interrupt whatever routine it was working on (needing a special instruction, RTI, to tell it to resume what it was doing previously to the interruption). "non-maskable" means there isn't a CPU instruction that can explicitly disable it (not affected by CLI, which I think is the relevant instruction). In this case of the NES the NMI is initiated by the PPU. (the CPU can write a command to tell the PPU to disable the NMI. However, it is NMI since the CPU cannot itself disable it.)
The PPU forces that routine to run once each frame, which is often how timing is done on the NES. Typically NMI will also run code to check for pending VRAM/palette write requests (ideally first since it's the most time-critical) as well as sound driver and controller input checks.

Reset is, as may have been implied, the start of the game code. Pushing Power or Reset sets the CPU to that instruction. Some Konami FDS games will call the Reset function of the FDS BIOS directly, as an antipiracy measure to effectively endlessly reboot the console if it detects the game has been hacked.

IRQ is a standard interrupt. I think it can be initiated by the BRK instruction but I've never seen it done intentionally (I've only seen it before because I recall it is opcode 00, making it a common thing to happen when debugging bad code.) The stock NES hardware doesn't use it but some of the more advanced mappers (such as MMC3) use it for some of the more advanced functions (like split-screen scrolling).

Oddly, the Master System uses NMI for the Pause button and makes Reset function like a gameplay button the game can ignore if it feels like it. Sounds like they should've been handled the opposite. :P

ROM Hacking Discussion / Re: FF1 MMC5 Conversion (Disassembly)
« on: September 23, 2017, 02:14:18 pm »
As for making empty banks (filler.dat) .. that's just to pad the ROM to the appropriate size.  It's only necessary if you're expanding.  If so, make it big enough so that your final ROM is exactly $80010 bytes (512K + 16 byte header)

That should be everything!
Filler still needs to go between the boundary of the last 16KB ROM bank, doesn't it?

Either it was the only ROM they found and they don't know better, or more likely they want to take advantage of unintentional enhancements offered by inaccurate emulation (such as MMC3 with up to 2MB ROM).
(or maybe intentional enhancements? Like N64 texture packs is the best example I can think of, and much less known, an HD SMS emulator)

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 02:02:03 pm »
There ARE some things right at the end of RAM that are read ($DFFF and thereabouts)
The last six bytes of RAM are supposed be reserved for a game's vector table, I think.
Though I don't know if the FDS supports IRQs, so I imagine only NMI could go used, as I don't think Reset could be used since I don't think the FDS supports soft-resets.
But I have no experience in that area, it's just what I think I've read.

Personal Projects / Re: Secret of Evermore Scroll Hack
« on: September 23, 2017, 01:56:57 pm »
Secret of Evermore actually uses a completely different engine than Mana.  The developers basically tried to mimic it, but they didn't use any of the original code.  It's probably still feasible to do though.
Maybe not be as well known as I thought, Evermore was the first game by an American team Square hired.
They reported that some changes in the game, such as being one player only, was due to the game being originally intended for half the ROM size it released on.
Might have been the only released game as well. I think they had one or two other games announced in a very preliminary stage, including an official Evermore sequel, before the first game was even out.
But then a year later the PlayStation "war" happened and Square reportedly replaced their US subsidiary entirely.

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 02:00:53 am »
My guess is Knight Lore had allocated a certain amount of RAM for holding level data and allows file expansion up to the maximum size.
You could expand a file but you have to be careful that expanding the file doesn't overwrite other data loaded (or written at runtime, the PRG-RAM is still writable).
Of course, if you are manually inserting extra space with a hex editor, you would have to insert it at the right space in the file within the "ROM", then remove extra space so the disk side size total is still the 65,000 byte size, as well as updating the file's header with the right size. Or else I imagine you'll effectively corrupt the game.

Newcomer's Board / Re: Is Searching Through a ROM This Hard?
« on: September 20, 2017, 02:19:18 pm »
I'd image 2600 games being easier to disassemble, being typically like 4KB, right?

But it sounds like ASM hacking on it would be harder as timing was a far bigger deal from what I've read.
Whereas with NES, code timing isn't usually a big deal unless you're dealing with like NMI/IRQ stuff.

Gaming Discussion / Re: 3DS Samus Returns and AM2R
« on: September 19, 2017, 11:47:30 pm »
I do remember Metroid II having something of a balance between exploration aspects within a generally linear structure. (to account for that it was a portable game and you may not exactly carry graph paper around with you to draw a map :P )
The world was mostly split into different regions that I think were referred to officially (or at least by Nintendo Power) as "Phases".

Basically one large hub room filled with acid that reduces as each "phase" of the game was completed, allowing access to the next "phase".
You would have to look around within each Phase to find all the Metroids to unlock the next one.
Even if you don't remember the hub area, the music at least worked as a sound cue (seeing the giant acid pit plus the game's main theme music).

Newcomer's Board / Re: Is Searching Through a ROM This Hard?
« on: September 19, 2017, 11:38:30 pm »
I have never used random ROM corruption and I cannot imagine it being a very productive means to find stuff versus trying to track it down the "smarter" way.

But maybe in the days before good debuggers, it was a means of tracking data (such as level data). Obviously just to get a foothold in the game.

Newcomer's Board / Re: Puggsy Copy-Protection Disabling Patch + Explanation
« on: September 16, 2017, 12:20:06 pm »
Supposedly Mega Man X (and maybe other Capcom SNES games?) use non-existent SRAM as one of the copy-protection checks. Although MMX delays execution of its antipiracy effects in order to make them harder to detect.

Newcomer's Board / Re: What do the "Mods" abbreviations mean?
« on: September 15, 2017, 12:09:24 pm »
That's not written somewhere?
I think it's Graphics, Sound, Levels, Text, and Gameplay.

Gaming Discussion / Re: Super Mario Bros. Xtreme Beach Volleyball
« on: September 14, 2017, 08:55:47 pm »
I recall watching someone play one of the SNES Mario preschool games and I recall Peach had rats popping out of her dress. She may want to do something about that. :P

Strange that article mentions Clu Clu Land, as that one was released on the FDS. Unless it means that the VS. Clu Clu Land machine itself has never been released outside Japan?
I do remember one old Nintendo interview, I want to say Mario Mania (NoA's Super Mario World guidebook), said that CCL performed poorly on location test.

I suppose it's almost a given that VS. Castlevania will come at some point, maybe VS. Gradius.

It was announced in Nintendo's "Nintendo Direct" video they would be released as Switch "Arcade Archives".
I think Mario Bros. will be the first, new week, I think.

It is of course going to be a digital release, but that's a long overdue start.

Along with arcade Mario Bros. and Punch-Out, it looks like VS. Super Mario Bros and Clu-Clu Land (which has been available in Japan as the FDS version, which it seems Nintendo calls "Clu-Clu Land D") but also Ice Climber, Pinball and Balloon Fight as well.

ROM Hacking Discussion / Re: YY-Chr Famicom problem
« on: September 12, 2017, 06:12:52 pm »
You probably need to increment the offset by 1 at a time to make it line up.
Check the files it came with for the keys.

Programming / Re: smb3 help thread regarding PPU
« on: September 12, 2017, 04:39:31 pm »
PPU RAM data is (usually) not contained in the CPU RAM.

The CPU can only send data to the PPU RAM by writing the PPU address (2 bytes) to (CPU) $2006 and then writing the data one byte at a time to $2007.
Since PPU can only reliably be written to during Vblank, games are often set up so that they will have a section of RAM set up for PPU write codes and then set up a flag to tell the Vblank routine when it should copy data to the PPU (by reading that data block, which can be however the game programmers want).

ROM Hacking Discussion / Re: Super Mario Bros 2 (FDS): Mario and Luigi codes
« on: September 12, 2017, 12:14:25 pm »
You wouldn't find it just by staring at hex.

Try cheat searching.
Most likely, Mario/Luigi's Y position will decrease as they are further up the screen.
Start a cheat search while the are standing, press the jump button and quickly try to cheat search while they are in the air (if you can pause while they're in the air it might help).

What you want to try to find is RAM addresses affected by jumping. This will probably give you the RAM address of Mario's sprite data (nearly all NES games will allocate a $100 byte page of memory to sprites) and maybe some other bytes. You want to narrow it down to the jumping bytes.
Then when you find them, use the Debugger to set a Write Breakpoint on the RAM addresses. So it will show the code that has updated the positions. Likely it will be code to DECrement or SBC (subtract) some value and then probably CMP (comparing) it to the maximum value (a lower value likely because sprite Y position go from the top of the screen to the bottom)

However, you may want to test on SMB1 first to make sure you have the technique.
SMB2 is a disk game which has an added technical difficulty to being sure you have the actual value.
In SMB1 (a cart game) you can tell in the debugger (when the Trace Logger will appear after the game tries to write to the address specified by the Write Breakpoint) when it reading values from the original game code because ROM addresses will be $8000+.
In FDS games, game code is loaded to RAM and then executed. In an FDS game, if you find it reading data from an address above $6000, it is likely the original code (the "ROM" data) but you can't be certain since that area is RAM and as such games CAN write to it.
And if you do find that it is code, to find it in the ROM, you might have to use a hex search to find it. As FDS games use a file structure which would make hex searching in a hex editor the easiest way to locate code in the ROM, for a beginner. (unlike cartridge games where it is easier to convert a CPU address to a ROM address)

Personal Projects / Re: Romancing Saga 1 translation
« on: September 11, 2017, 06:59:38 pm »
For the two Final Fantasy games it was mostly a case of timing. The first game was localized very late in the NES's life, and the SNES and FFIV were just around the corner, making it pointless to translate two already obsolete games instead of the current one on the beteer hardware.
Also, translating four games at once (FF2, FF4, Legend II and Adventure) would probably have been a huge task for Square's US branch at that time (seeing how they were lucky to put out even a couple games per year).
(or so I assume they were close together. Square's pamphlet from SCES 1991 announced both FF2 (NES) and FFL2, while in the end the other three released games seem to have been released weeks apart in October-November 1991)

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