Posts for Dwedit

1 2
19 20 21
27 28
Posted: 5/20/2009 6:15 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
The Demo of Blades of Steel should also work too. I just need to know if it plays the same on a NES every time, or varies. On FCEU, it varies! On Nintendulator, it plays the same every time. On Nestopia, it plays the same every time, but is different from Nintendulator. Basically, anything made by Konami that plays DMC samples before showing randomness with no joystick input should work, but the only two games that actually do that are Double Dribble and Blades of Steel. Contra sort-of shows differences, with Contra, you can see that FCEUX has a slightly different Demo then Nestopia, in FCEUX, two enemies fail to get killed.
Posted: 5/18/2009 2:00 PM
Post subject: The "Double Dribble" test - Luck manipulation on a real NES?
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Does anyone out there have a NES, and a Double Dribble cartridge? Double Dribble and most other Konami Games use a random number generator which is called at the end of every frame, and keeps running until the next frame starts. Double Dribble plays a randomly selected Dunk animation after waiting a few seconds at the title screen. Double Dribble also plays a DMC sample during the title screen. The DMC channel can mess with the CPU a bit, by stealing CPU cycles at various times, which can affect the RNG. The DMC channel is NOT reset by starting a sample, so its behavior could possibly vary depending on the power-up condition of the NES. Here's the test: Does the exact same sequence of dunk animations play in the exact same order every time you boot the NES from a cold boot? If the same sequence of animations plays back every time, luck manipulation is possible if played back on hardware. If the sequence varies between bootups, then it isn't. There's also a third possibility: Three possible random sequences due to an undefined PPU/CPU sync on bootup.
Posted: 5/13/2009 11:25 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Despite what that controller test program says, the Microphone is not the same as the VS coin switch.
Posted: 2/28/2009 10:59 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
DD. Use it. Get everything the hell off the drive.
Posted: 2/24/2009 10:12 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Random tip for non TASers: The equipment stats bug allows you to equip cursed weapons/armor in Fake Midenhall (Hargon's Castle) with no penalties, you keep the stat bonuses, and they're not equipped after you leave the area or use the Charm of Rubiss.
Posted: 2/17/2009 2:09 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Only use clean roms.
Posted: 2/13/2009 10:45 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
That is some FAIL playing there. Didn't know about holding UP in Rad Racer to accelerate faster.
Posted: 2/11/2009 6:29 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
There is no NES Gryzor. Only Contra or Probotector.
Posted: 2/5/2009 8:00 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Micro Machines looks worse on the newer FCEUs, and Battletoads is highly glitched on level 6. Maybe we just need Nestopia Rerecording or Nintendulator Rerecording. NestopiaXDSP anyone?
Posted: 2/4/2009 10:43 PM
Post subject: What the hell! Fceu versions beyond 0.98.12 have sucked!
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
FCEU versions released after 0.98.12 have all sucked, and had much less accurate emulation then versions released before then. This also includes FCEUX sucking. What the hell happened to make the emulation so inaccurate?
Posted: 2/4/2009 10:38 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Shouldn't a run of this be done on the non-pirate version of the game? Stick with the authentic Sachen Thunder Blast Man game, not one of the thousands of pirate versions.
Posted: 2/2/2009 5:47 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Would the "bee-numb" route be any faster than the dream ruby route? Let the killer bees paralyze you, then manipulate luck long enough to remove party members before the numbness wears off. Only issue then is getting a 07 byte in the zeropage to use the overworld to manipulate stats.
Posted: 2/2/2009 5:06 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
And 0xE6 is a length counter for the music instruments which constantly ticks down, and doesn't go very far above 0x20. Ingenious!
Posted: 2/2/2009 3:54 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
That was some very impressive manipulation with that bug. Did it take a lot of tries, or any special preparation to get the items, EXP, and return locations glitched properly at the same time?
Posted: 2/2/2009 3:47 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
adelikat wrote:
One thing I was thinking about. The game uses flags in memory to determine if events have occured. For instance, I found the erdrick flag in order to more easily do solo quests. Would it be possible for these corruption glitches to alter those? Like if the flag for deciding to put in the ortega - king hydra fight could be manipulated, it could save a lot of time in a TAS.
Find the flags with a cheat finder. If they're in the 71C-7FF,000-01B range, then they are manipulable with the swamp glitch, depending on if the complimenting high byte is greater than zero.
Posted: 2/1/2009 8:39 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Edit: Looks like I made a big mistake before, the tile number check table does not wrap, it extends to 0x0192. The character number table does wrap though. * A table located at 6DE0 tells you what tiles do. Any 05's indicate a swamp, and any 06's indicate a barrier. On the Overworld, tile #07 is the swamp. Some places have no swamp tiles. * A table at 0x0093 indicates the tile number the character is standing on. AND this number with 1F before checking if it's a swamp tile. * A table in the zeropage starting at 0x68 indicates the character number to mess with. So the addresses to look at to determine effects are X and (X-0x43)&0xFF. But it also matters when you look at them, they need to be correct just as it's checking the swamp tile, which has distinctly different values sitting in the zeropage as the code which pops up the dialog box. The contents of the zeropage as it's executing PC=B0FF are all that matter. Quick look at memory map: Character #0 HP: 0x71C ... Character #0 EXP: 0x744 Character #0 Returns: 0x750 Calculating character number: Pick the byte you want to modify (such as EXP+2: 0x746), subtract 0x71C (we get 0x2A), divide by 2 (we get 0x15). You can also add 0x80 to character number and it won't affect anything, since it gets doubled before it's added to 0x71C. Character numbers needed to change: EXP+2: 0x15 or 0x95 EXP+6: 0x17 or 0x97 RETS+2: 0x1B or 0x9B RETS+6: 0x1D or 0x9D In the overworld, you need to get the corresponding memory value to match tile #7. Values 0x07, 0x27, 0x47, 0x67, 0x87, 0xA7, 0xC7, 0xE7. So those three addresses you were looking at don't appear to affect anything good.
Posted: 1/30/2009 9:10 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
For a second, it looked like it desynced at Lazy Leaves.
Posted: 1/29/2009 5:22 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
edit: Rewrote post, because previous post was wrong... (was mistakenly using big endian byte order) EXP is manipulable. Character #1/#3 high EXP byte is treated as the low byte, and character #2/#4's low byte is treated as the high byte. Assuming one subtraction, Character #1/#3 gets 16646144 extra EXP, and character #2/#4 loses 1 EXP. Character #2/#4 must have at least 1 EXP, and not a multiple of 256 EXP. See Datacystal for the actual memory addresses involved. The more amazing thing though is the ability to mess with the first 28 bytes of the zeropage, and that opens the possibilities of strange positive feedback loops.
Posted: 1/29/2009 3:02 AM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Max HP/MP don't look glitchable, since all addresses are 16 bit and word aligned. No way for an aligned 16 bit value to decrease by 2 and borrow from another byte.
Posted: 1/12/2009 5:32 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
By the way, compiling the SVN version fails, it always runs in Turbo Mode.
Posted: 1/12/2009 2:56 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Oh yeah, I just noticed that you can save input presets, but not load them without remapping your hotkeys. Seriously, what the hell?!
Posted: 1/12/2009 2:29 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
So I got the "Run Scanline" and "Run 128 Scanlines" features working: But the PPU pixel display is whacked out after reaching scanline 240. How do I accurately calculate this value? Right now I'm using this code which doesn't work correctly: 
#define GETLASTPIXEL    (PAL?((timestamp*48-linestartts)/15) : ((timestamp*48-linestartts)/16) )
	extern int linestartts;
	int ppupixel = GETLASTPIXEL;
	sprintf(str, "Scanline: %d, %d", scanline,ppupixel);
	SetDlgItemText(hDebug, IDC_DEBUGGER_VAL_SLINE, str);
Posted: 1/11/2009 6:23 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
I downloaded the source code, and I'm trying to add these in, but this stuff is very hard to do, since the scanline counter stops counting at vblank.
Posted: 1/10/2009 9:47 PM
Post subject: "Run Next Line" button in debugger?
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Would it be possible to include these in the debugger: * A "Run Next Line" button * A text label indicating what PPU pixel we're at within the scanline
Posted: 12/6/2008 8:59 PM
Quote
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
I just noticed that selecting text invalidates the area under the image, and makes the image instead appear in the proper place, so it's definitely a Firefox bug.
1 2
19 20 21
27 28