News:

Don't forget to visit the main site! There's lots of helpful docs, patches, and more!

Main Menu

Lunar Expand, Wise or Unwise?

Started by Mettyk25jigsaw, March 30, 2013, 07:46:13 PM

Previous topic - Next topic

Mettyk25jigsaw

Hi, I remember a while back now (about 4-5 months ago) I looked at a program called LUNAR EXPAND, I decided then not to use it.... Now this can expand your rom to up to 8 MB, also there is another option of 6 MB and goes down from there again, even though I am not interested in the 4 MB option because I can do this in smile and I believe it's safe. I find some evidence somewhere that it may not be wise to expand it to 8 MB, but what about 6 MB? Safe or not safe? 6 Mb would be all I want anyway. What I am saying is would it cause any issues to my Super metroid rom.
     Furthermore, I don't necessarily really need any more the 4 MB, because I think the current 4 MB I have as maximum leaves enough space for me for level data and other stuff, but the extra 2 MB on top would allow me to allow a lot more free space to allow for level data for each R/ID in rooms I decide to go back to and edit it further. Eg. currently I am leaving 200 to 300 free bytes (dec.) per room ID, more often then not closer to 200.  I would like to increase that quite dramatically, but I feel I would need that extra 2 MB......Also noting that by doing this I understand that I would be altering certain criteria with the rom, that is it changes the rom to a different version of lorom to (by memory) ex-lo-rom or something similar and would have to start using different Banks rather then just $80 To $FF...I believe by memory it is $40 to $7F. And therefore only useful for things you can point to by changing the bank, however you can do this with level data (and there are other things)...
     All that I would like to know is - Is it safe to expand the rom to 6 mb using LUNAR Expand?
       Thankyou to anyone who would take the timeout to answer my question.......

Benki

#1

SMILE won't recognize the extra banks, from my understanding. Meaning you won't be able to add extra tile-sets through SMILE, and you will have to do it manually. Otherwise I'm assuming that it won't harm your ROM, outside of SMILE acting weird. I wouldn't do it unless I was 100% sure.

EDIT: I used this on my hack, It works fine  :^_^: It should work, just don't try to add extra tile-sets.

Zhs2

Not just SMILE, but in general the architect of Super Metroid makes it impossible to expand a ROM image past 4 megs, as Super Metroid is a LoROM. I wouldn't expect anybody to turn it into a HiROM soon. I wouldn't know the science behind that above the way the SNES already works: 0-7FFFFF memory space is reserved for RAM, memory, and graphics processing (I'm sure someone else here would be able to give the breakdown of what goes where) while 800000-FFFFFF - effectively 4 megabytes - is where the ROM is kept loaded during play for quick access. As a point of reference, this is also why banks are labelled as they are ranging from $80-FF since that's where they are kept loaded into ROM memory.

Benki

Emulators won't be able to identify your ROM if it's +4MB

Quietus

I'm sure that FuSoYa created some custom builds for snes9x and ZSNES, both of which should support up to 8MB.


Mettyk25jigsaw

Thankyou for your help everyone.....Qietus, I'll look into your suggestion sometime, thankyou......Benki I think I know what you are saying, but I am refering to changing the mode form lo-rom to ex-lo rom or ex/hi-rom or something similar, which may make the rom work fine with more banks if quietus suggestion turns out good, thanks for your input though, as the rom is now, I know I can't have any more banks, but if I change the mode, well I wonder if it can be different...

Mettyk25jigsaw

Yep, thanks quietus, I've tried it, it works fine in the end, however smile doesn't recognise the new banks with level data..However once again, I thought of an idea that would be just as good which would allow me to use the extra banks. I've repointed music data to these new banks, figuring smile doesn't need to recognise these new banks for music data, given the way smile works and all that. It works fine and now I am using the former banks that the music data were using.....Also another thing that I think will work to give me more spare data in the first $40-0000 bytes is the enemy gfx tiles, i don't see how this wouldn't work, I am going to try today....
  Thanks again...

JAM

Quote from: Zhs2 on March 31, 2013, 02:42:16 AM
I wouldn't know the science behind that above the way the SNES already works: 0-7FFFFF memory space is reserved for RAM, memory, and graphics processing (I'm sure someone else here would be able to give the breakdown of what goes where) while 800000-FFFFFF - effectively 4 megabytes - is where the ROM is kept loaded during play for quick access. As a point of reference, this is also why banks are labelled as they are ranging from $80-FF since that's where they are kept loaded into ROM memory.
Bank $70 -- SRAM
Banks $7E and $7F -- RAM
Banks $80..FF -- ROM (in general).

LoROM is using banks $80..FF and bank size is $8000.
HiROM is using banks $80..BF and bank size is $10000.
ExLoROM (6Mb) is using banks $00..3F and $80..FF. For 8Mb type, I think, SRAM is untouched, so ROM is using also banks $40..6F and $71..7D.
ExHiROM is using banks $80..FF and bank size is $10000.

By the way 6Mb ver. of ExLoROM is supported by most versions of Zsnes, because there ARE 3 official games using ExLoROM format.

P.JBoy

#9
The only thing the SNES has to say about the way memory is mapped is that:

  • Banks $40..$7D and $C0..$FF are all ROM
  • Banks $7E/$7F are all WRAM
  • In banks $00..$3F and $80..$BF:

    • WRAM can only be accessed with an address < $2000 (mirror of first 8K of $7E)
    • ROM can only be accessed with an address ≥ $8000
    • A mix of things in the middle (namely hardware registers and PPU access)
Past that, all mapping is done by the cartridge. With LoROM, all ROM is accessed with address $8000+, even with banks $C0..$FF/$40..$7D, HiROM is mapped to all addresses in $C0..$FF/$40..$7D and only the $8000+ of each bank is mirrored to corresponding banks in $80..$BF/$00..$3F. When you use Lunar Expand to expand your ROM past 128 banks it changes the type of ROM, and the extra banks are mapped to $00 onwards for ExLoROM with the original banks in $80..$FF only. I assume the extra  banks when extending a HiROM to a ExHiROM start at $40 with the original ones in $C0..$FF only
...

Mettyk25jigsaw

Thankyou so much JAM & PJBOY for your input, it has been muchly appreciated...

JAM

P.J.Boy
I have a question. In HiROM to where will I jump with this operator (used in bank $80)

JSR $0123

To $80:0123 or to $7E:0123?

And will the poeratoe below helps to reach the very beginning of the bank $80?

JSL $800000

P.JBoy

JSR $0123 will start executing RAM, as will $800000
...

JAM

#13
I'd better post it here instead of creating the new topic or posting in General Project thread.

What do I know.


  • To expand the ROM manually over 4Mb you'll need to change one byte in the header (0C to 0D). It can be 4.5Mb or so. Not just 6 or 8 Mbs.
  • You can't use the ASM code in the new banks (although can use the space for Level Data or Tilesets)
  • Some data from bank $80 must be in bank $00 too. Or the ROM will not be opened. I assume, the data pointing by vectors in header. [Will test it soon] Easiest solution will be just just use copy of bank $80 in bank $00.
  • Banks $7E and $7F obvioulsy can't be accessed.
  • Bank $70, although, can be used since SRAM is using addresses starting from $70:0000 and bank $70 of data will use addresses from $70:8000 to $70:FFFF
  • I haven't found a way to fix the checksum of expanded ROM. It's calucated strangely...