Banner
Views: 844,550,031
Time:
14 users online: 400Baud, FluffyBucketSnake, Hayashi Neru,  JamesD28, Janno27, King Mayro, Kori, MagmaMouse, MiracleWater, OrangeBronzeDaisy, orka-bln, RPG Hacker, Sparkysie, VoltreN1 - Guests: 39 - Bots: 74 Users: 46,438 (2,767 active)
Latest: wat_newby3
Tip: Switch palace switches normally disappear if you replay the level. However, if you insert them as direct Map16 and use the hex-edit at $00EEB2 in the ROM map, you can replay the level without a problem.Not logged in.
EXTREME FastROM v1.1.0 (dl 1st post)
Forum Index - SMW Hacking - Resource & Tool Releases - EXTREME FastROM v1.1.0 (dl 1st post)
Pages: « 1 2 3 4 5 »
Originally posted by UMA
Why didnt the original SMW run in FastRom?

Originally posted by Smallhacker
SMW is unoptimized, unorganized, buggy, crappy, wtf-y and "how the hell does the SNES work"-y.

In other words, I don't really think that the developers had any clue what they were doing, so they figured they wouldn't push their luck and end up screwing everything up.

Originally posted by Ersanio
Well, I guess the programmers either didn't care since the original SMW didn't have any slowdown (as far as I know), or they actually didn't bother implementing it.

The second level had slowdown with the 8 koopas in a row, as did the end-of-level iris out effect, but other than that...
I should get a new layout.

Probably won't, though.
"Hey, as long as it works" must have been their motto, and well, that's all one needs.

World Community Grid: Thread | Team
 
Faster ROMs cost more money. That's all it is. Developer skill doesn't play into it since targetting fastrom or converting a game to fastrom doesn't require any real effort.
So you're saying that my patch was made effortless? D: *shot*

Are FastROM game paks actually different from normal game paks? I mean, I can't see why it should cost more money besides that.

--------------------
My blog. I could post stuff now and then
I meant from perspective of the original developers, should've added that in =] All.log is nice to have though.

The ROM chip itself has a certain access speed. The faster ones are pricier. Enough of a difference for Nintendo to put in two ROM access timings. A developer wouldn't pay extra if performance with slowrom was 'good enough'. If a SNES tried to access a fastrom region with fastrom active, but using a slower ROM it would read garbage data since the ROM wasn't given enough time to put out valid data. The 120ns and 200ns figures you might have seen refer to the required speed of the ROMs in each type.
Originally posted by Alcaro
Originally posted by Ersanio
I don't think RAM is mirrored like that.

I'm quite sure $0000-$7FFF (WRAM and hardware regs) is mirrored (otherwise it'd break as soon as a code inside a PHB PHK PLB xxx PLB block tries to perform a 16bit read from RAM, and you would've noticed that).
However, I don't think $70xxxx-$7Fxxxx is mirrored ($F0xxxx-$FFxxxx is the only way to access the last part of a 4mb rom afaik).


$0000-$7FFF are mirrored in banks $00-$3F and $80-$BF. Lookie here!

Originally posted by Ersanio
- The mirror ROM isn't actually in the .smc file itself. It gets mirrored by the SNES hardware so it can be used for FastROM purposes for example.


It's mirrored by the cart's mapper thingy actually. In fact fastrom breaks completely in 8MB exlowrom because exlowrom in fact does NOT mirror things in bank $80+ but uses bank $80 and up for new data.

As a side note, can't LM expand roms to highrom mode and pad banks with empty space instead of using a barely supported mapping mode?

--------------------
Your layout has been removed.
What does the patch do?The Game
You just lost.
It eliminates most of the slowdown which occurs during the game.

--------------------
My blog. I could post stuff now and then
http://www.youtube.com/watch?v=TqsEbukjluo

I experienced no problems during my brief testing, and as such I'll be sure to use it in the future. Er, forgot it was going to be implemented into LM. Welp, at least I'm sure it won't mess up stuff.

EDIT: I can't believe I spent 3 hours on this

World Community Grid: Thread | Team
 
Originally posted by KilloZapit
As a side note, can't LM expand roms to highrom mode and pad banks with empty space instead of using a barely supported mapping mode?


It could. However, that would still be incompatible with all existing SMW utilities, the padding will make things a bit messy, SRAM code will need to be fixed, and you could only do it automatically to ROMs that haven't yet been expanded past 1MB (2MB if you don't care about zsnes).
FuSoYa tried the patch on a real snes and told me there is some IRQ timing issues (graphical glitches appear on the last half of the last scanline below the statusbar or something) not emulated in any emulator, so he decided to keep the IRQ routine in SlowROM after all.

Well, I got a LM version with the FastROM patch and I'll try it out soon.

Image with the issue: link.

--------------------
My blog. I could post stuff now and then
The irq but not the nmi? I wonder why that would be a problem...

I should test my hack in bsnes sometime, since I did mess with the irq stuff.

--------------------
Your layout has been removed.
Well, I don't think that this patch triggers the NMI problem, if FuSoYa used an EPROM that exceeds 120 ns (the FastROM time), it can show some problems due to "late" read/write. Maybe this is the NMI problem.
If that was the cause most ROM reads would be incorrect and the game would crash quickly... I think. I would assume though when testing a fastrom patch one would be smart enough to use a fastrom-compatible flash card.

--------------------
Your layout has been removed.
I see, but I was searching for EPROMs and with some documents, I can pinpoint exactly the correctly timing. If FuSoYa uses an 27C801 EPROM, the timing will be 125 ns. It won't crash but it will show some graphic garbage.
Nah it's just the way the IRQ was coded. While SMW does use $4212 to figure out when they've hit hblank for the current scanline, it then uses a delay loop that they assumed would end right at the start of hblank for the next scanline. If you use FastROM, that loop executes slightly faster and you may start doing things before hblank begins.

Fixable to run in FastROM, but not much gain in doing so since you're mostly waiting on hblank to begin with.
Just wondering, what would happen if one NOPs out the wait for H-blank routine? Would it make the graphical glitches even worse?

--------------------
My blog. I could post stuff now and then
The new cycle based PPU in the new bsnes would help with this sort of testing. Apparently you have to compile it yourself but it's the only emulator that can do this. There's no reason not to do it if you don't have direct access to a SNES (even then it'd be handy for quick tests).
Oh yeah, the cycle based PPU Bsnes... I'd test my FastROM in that emulator but the thing is that I have no experience with compiling source code. :|

Oh well, I'll look into that some other time.

--------------------
My blog. I could post stuff now and then
I thought the whole idea of the irq was to trigger on h-blank in the first place. :/


--------------------
Your layout has been removed.
Pages: « 1 2 3 4 5 »
Forum Index - SMW Hacking - Resource & Tool Releases - EXTREME FastROM v1.1.0 (dl 1st post)

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy