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

Pages: [1] 2 3 4 5 6 ... 57
And since Disch mentioned a recent game that he liked, you guys really have to play Fez if you haven't already, it's a fantastic trip.

I second the Fez recommendation.

The platforming gets a little tedious with all the backtracking, but the atmosphere is great and the puzzles have a great balance of being both "wtf is this supposed to mean" cryptic while still being actually solvable (well -- most of the time -- a few of the puzzles are pretty far out there).

You feel like you EARN those cubes.

Star Wars Battlefront 2: I bought the game, but I need to pay money again (either a few dollars to even $100) to acquire items/characters that will allow me to actually play the game. And grinding for over 9000 hours to get past the pay wall isn't gameplay; it's a chore.

So... here's the thing with SWBF2.  Everyone knows it's a pile of shit.  Everyone should have known after SWBF1.  Or really after any Battlefront game.  Ordinarily this game would just flop and everyone would forget about it in a few months... kind of like No Man's Sky.

But here's the thing...

... I'm going to let you in on a secret...

... are you ready?

Star Wars fanboys are fucking stupid.  They're like the stupidest of the stupid consumers.  They'll buy anything with the Star Wars logo on it... it doesn't matter how shitty everyone knows it is.  It doesn't matter how overpriced it is -- how lacking in base content it is -- or how poorly reviewed it is.  They'll still shell out for it.

EA knows this.  And they exploited it. The game is overpriced because they know SW fanboys will buy it anyway.  They have in-game microtransactions because they know SW fanboys will pay for them.

... and they kind of are.  Considering how badly the game has been drowning in drama, bad press, and bad PR... it still sold a looooot of copies.

Sorry, but I can't blame EA for seizing the opportunity to capitalize on fanboy stupidity.  All they did was make a shitty overpriced game (which, btw, have existed forever).  Everybody knew exactly what it was going to be months before it came out.  All they had to do was show some restraint and not buy it.  But "ZOMG STAR WARS" so they bought it anyway and got all butt-hurt.

This game is not an example of how games have gotten worse.  It's an example of how game consumers have gotten stupider.  But when games are as cheap as they are now, I guess more carelessness is to be expected.

Need I remind you that, adjusted for inflation, a copy of Street Fighter 2 on the SNES would set you back over $100?!

This.  This is really key to remember.

It was not uncommon for NES games to be priced at $50 or even $60+ at the time of their release.  In 1987.  30 years later, and modern games cost about the same -- often much less ... despite inflation.  Games are cheaper and more easily available now than they've ever been -- and part of that is because of digital distribution.

Take a game like Ori & the Blind Forest, for instance.  I'm using it as an example even though it's 2 years old now because I just recently tried in and completely fell in love.  The game is a friggin masterpiece, and IMO stands alongside the Metroidvania greats of the past... and it's $20.  A third of the price of Super Metroid or SotN -- and every bit as worthy of being played.

This kind of release just didn't happen in the pre-digital era.

EDIT:  sorry but I can't help gushing over this game.  I mean LOOK AT IT

But will you be able to play those games you bought in say another 10 years when the services that sold you the game go down? If you don't care about that, then not a problem.

1)  It depends on the game and where you bought it from.  As mentioned, GOG does not have this problem.
2)  It's a pretty safe bet to say that Steam will still be around in 10 years.  At least, I would be willing to bet.
3)  On a 10+ year timeline, I think Windows compatibility problems would be a much bigger issue anyway.  Who knows if a game designed for 2005 PCs will run on 2025 PCs?

I'm glad I decided to stop playing new games after rediscovering the PS1.

You just haven't been playing the right new games.  Either that or you're blinding yourself with stubbornness.

Good games are still being made.  But it's like games of any other area -- the vast majority of what gets released is trash.  The main difference is that for some unknown reason more people are willing to buy the trash now than they were before.

I have no problem with this.  I haven't bought a physical copy of a game in... 4 years?  5?  It seems like an antiquated concept to me.

UxROM are Nintendo boards and definitely have no SRAM. iNES mapper #2 is however a super-set of UxROM which is implementation-agnostic, and allows swapping far more banks (8 bits instead of 3 or 4), and allows for SRAM.

FCEUX at the very least seems to be putting open bus at $6000-7FFF for mapper 2.  Though maybe it wouldn't if the battery bit in the header was set?

Either way -- you're playing with fire at this point and are making your hack have questionable emu compatibility.

But yeah, so this one is going to actually take me a while. As I'll need to first convert the game into a different mapper(which would take a while if at all, not sure if I am capable of this), then adding the SRAM saving function...which would be the easy part as I've done enough of that already.

You're building a mental wall.  Doing a mapper hack isn't as hard as you think.  In fact, I'd argue that doing an SRAM hack is harder, as it actually takes understanding of what information the game is handling.

The only thing you really need to do for a mapper hack is find all the code that swaps banks and change it to a 'JSR' that does the MMC1 version of a swap.  It's little more than find/replace.  Time consuming, but very easy.

Don't let it scare you.  You definitely should be able to do it.

I'm 2 years late to the party, but I recently just discovered Ori and the Blind Forest.  I'm completely blown away -- it quickly became one of my favorite games.  Stunningly beautiful, amazingly thematic soundtrack, adorable character, and really fun platforming.

I threw this together to help explain bankswapping:

To do a mapper hack you need to know 3 things:

1)  6502 assembly  (which I assume you are reasonably proficient in if you are adding SRAM to a game)
2)  How the original mapper works (In this case, UxROM)
3)  How the new mapper works (In this case, MMC1, I assume, unless you decide on something different).

Most mappers do more or less the same thing.  So doing a mapper hack involves figuring out what the game is doing in one mapper, and doing the equivalent thing in another mapper.

In this case, UxROM only has 1 thing to do:  Swap PRG.  It does that with code similar to the following:

Code: [Select]
; Swap to bank 'some_bank_number'
LDA #some_bank_number
STA $C000,X    ; address may vary -- must be between $8000-FFFF

The equivalent code on MMC1 (to swap PRG) would be the below:
Code: [Select]
LDA #some_bank_number
STA $F000   ; address may vary -- must be between $E000-FFFF
STA $F000
STA $F000
STA $F000
STA $F000

Both of these bits of code might seem strange at first, but what they're doing is very simple.

To Swap PRG on UxROM, you just have to write the desired page number to any address in the $8000-FFFF range.  The thing that makes it complicated is that most boards have bus conflicts, so the value you write must match EXACTLY to the value that is read from that address.  IE, if you want to swap to page $05... you'd need to write $05 to an address in the $8000-FFFF range that already contains a $05.

Games often do this with a lookup table that just looks like this:
Code: [Select]
At address C000:
  00 01 02 03 04 05 06 07

The game then uses the page number as the index to the lookup table to write:

Code: [Select]
LDA #5        ; want to swap to bank 5
TAX           ; A and X are now both 5
STA $C000, X  ; Since X=5, we will write to $C005, and we know $C005 contains 5 because
              ;   that's the point of the lookup table.

Note that this is just an example, and not a definitive rule.  A game might do something like this:
Code: [Select]
LDA #$02
STA $8016
... if it just happens to know that $8016 contains a 2.  There isn'te specific routine to do this -- a game can do it any number of ways. It's up to you to look at the code and figure out what it's doing.

But you can know for sure that every single write the original game does to the $8000-FFFF range is the game attempting to swap PRG to a specific page.


MMC1 is weirder.  To Swap PRG here, you just have to write the desired page number to any address in the $E000-FFFF range.  The plus side is there's no bus conflicts, so you don't have to worry about writing to an address that contains a certain value.  The down side is MMC1 registers can only be written 1 bit at a time.

MMC1 regs are also 5 bits wide, which means each register write actually takes 5 writes (one for each bit)

Hence the LSR's between each STA.  The low bit is written first, then you shift right to move the next bit into position 0, so it will be written on the next STA.

MMC1 also has additional functionality besides just PRG swapping.  You don't have to use it, since the game you're hacking doesn't need it... however you still have to initialize everything.  Common best practice is to write to all registers once at powerup to put everything in a known state.  So take a look at MMC1's register list:

There are 4 registers:

1)  Control ($8000-9FFF).  This sets the mirroring mode, as well as the swap modes.  To match UxROM, you want 8K CHR and 16K PRG swappable at $8000... and either horizontal or vertical mirroring depending on what the game is (I'm too lazy to check).  So you'll want to write either $0E (vertical) or $0F (horizontal).  But again, gotta write 1 bit at a time, so when I say "write" I mean "perform 5 STA's"

2)  CHR bank 0 ($A000-BFFF).  Since you'll be using CHR-RAM, the CHR swapped in doesn't really matter.  You can probably get away with not writing to this reg at all, but if you want to be strict you can write $00.

3)  CHR bank 1 ($C000-DFFF).  Ditto.  Although since you'll be using 8K CHR swapping this reg will actually be ignored, so you REALLY don't need to write to it at all.

4)  PRG bank ($E000-FFFF).  This is what controls the PRG swapping.  Basically just write to this reg whatever the original game does when it bankswaps.

I don't think there are any UxROM boards which have on-board RAM (nesdev wiki says the board doesn't support it).  I wouldn't think most emulators or emu-on-a-carts like the PowerPak would care and would've put RAM at the $6000-7FFF range anyway for compatibility reasons -- but apparently I'm wrong!!  Interesting.

The constantly changing values in the hex editor is definitely a bug in FCEUX, though... and a weird one.  Maybe a stray/uninitialized pointer?  In any case, when I tested and read from that range I didn't get the values it showed... instead I got open bus as I'd expect.

Anyway, to answer your questions:

1)  Yes, it is possible to do a mapper conversion.  A UxROM to <insert other mapper here> mapper hack isn't different from any other mapper hack.  Just pick a mapper that has similar swapping abilities as well as SRAM support (MMC1 could work), then find all the points at which the game does mapper stuff and replace it with the MMC1 equivalent.   The only tricky thing with UxROM is that since the swap code is so small, many games do inline swaps without JSRing to a separate swap routine -- which means it might be hard to track down ALL the mapper code.

2)  No, there's not a reliable way to add SRAM to UxROM.  You'd probably be able to get some emulators to work, but others will choke.  Best to switch mappers.

Using 32KB banks with MMC1 would not grant you 512K max.  Bregalad was referring to SUROM, which hijacks one of the CHR bits and uses it as a 5th PRG bit -- allowing for more PRG to be addressed:

ROM Hacking Discussion / Re: Mapper Conversions Issues Question
« on: November 03, 2017, 08:52:47 pm »
ADC here makes no sense --- that REALLY should be ORA.  But ADC will have the same effect since C is getting cleared by the ASL.  Still -- I'd use ORA anyway.

Other than that I got this confused with Final Fantasy when I made my earlier comment.  Yeah PHP/PLP there is fine.

FWIW, Counting down is generally quicker & less space than counting up, since you can avoid a CPX:

Code: [Select]
LDX #$1F
  LDA $7000,X
  STA $0411,X
  BPL Loop

This shaves 2 bytes off the code.  If you're tight on space, that might help.

ROM Hacking Discussion / Re: Mapper Conversions Issues Question
« on: November 03, 2017, 11:05:47 am »
Eeehhhh?  That seems dubious.  Can you post the bankswitch code you're talking about?

ROM Hacking Discussion / Re: Mapper Conversions Issues Question
« on: October 16, 2017, 09:57:33 pm »
Yes, there are several swap routines in there.  A lot of that will need to be rewritten.

ROM Hacking Discussion / Re: Mapper Conversions Issues Question
« on: October 16, 2017, 04:11:21 pm »
You must have messed something up in the conversion.

UNROM in particular, since swaps are so simple (just a single write), many games will just do the STA directly in the code rather than JSR-ing to a swap subroutine.

Try setting a breakpoint on all writes to $8000-FFFF.  In an MMC5 converted game, the game should never write to those addresses.  If it is, that's the game trying to swap.  You'll need to replace the write with a JSR to a swap routine.

That isn't enough information.

That's not a bad opcode so the debugger is not snapping on that line.  And even if it were, 1 single instruction wouldn't be enough to know what is going on.   :P

I'm also not very familiar with the game so I'm not sure what's going wrong in the video.  I assume the player shouldn't be jumping to the top of the screen?

Anyway... aside from graphical glitches... actual gameplay-altering problems you can have would be one of the following:

Possible: PRG-RAM is not enabled and the game expects it to be (see $5102, $5103) ... though I'm not sure if Guardian Legend uses PRG-RAM?  **shrug**
Possible:  You didn't disable mapper IRQs (see $5204).  IIRC Guardian Legend uses DMC IRQs for timing tricks -- particularly during the flying sections.
Possible but not very likely: You're in the wrong PRG mode (see $5100)
Much more likely to cause a flat out crash than a weird problem: You're doing PRG swapping incorrectly (see $5113-5117)

Borked CHR swapping could also cause gameplay problems (if the game uses Sprite-0 hit, which IIRC Guardian Legend does) -- but that would more likely result in a crash than anything else, and would be accompanied with lots of obvious graphical glitches.

My advice:   C++ is not the language for this.  Unless you are much more comfortable with C++ specifically (which it doesn't sound like you are), you should use a quick scripting language like Python.

I highly doubt there's an existing tool that does this oddly specific task.

Perhaps write a python script to do it?   :P  This kind of quick and easy thing is what Python excels at.

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