LoRom Model Doc

I made this: http://www.cs.umb.edu/~bazz/snes/lorom.html

Please verify what I wrote.

Amazing, thank you very much friend for sharing your knowledge with the rest...

double flawless victory, bazz Wins!

reading a bit I found this:



this information is correct?

Yes I confirmed this with NoCa$h. No commercial cartridges we know that do this, however it is possible. Most games just mirror 00-7d and 80-fd, where 7e-7f is system ram and fe-ff is more ROM/SRAM. This kind of mirroring occurs when mappers don't acknowledge A23. It's the same reason why LoRom mirrors itself (I explain all this in more detail in the doc.), that the upper banks mirror the lower ones. It is the ignoring of an Address line. Ignores A15 causes the LoRom mirrors. Lorom and Hirom both ignore A23 causing the big mirroring to occur.

You can potentially make a cartridge that mapped new data to those upper bank areas. and you lose a 1 Mbit by System RAM 7e-7f. thus I concluded 63 Mbit. However, the potential of mapping is really up to your imagination and technology. Maybe you can devise a way without losing 1Mbit. You can create tech that could do all sorts of things!! The more you understand the more you realize the potential of electronics.

Here's how I see it:

A0-A14 + A16-A23 = 15+8 bank bits = 23 address lines. 2^23 = 8 MBytes = 64 Mbits

LoROM's point is to be able to share ROM and I/O in the same 64KB page. Since the SNES only maps I/O registers for banks 00-3F and 80-BF, you only have 32 Mbits of convenient LoROM code space. However, you could put data into the upper banks (40-7F, C0-FF) so that it wasn't an issue and you could keep the LoROM mapping for everything.

hello again, I read the entire document, I think it's fascinating, congratulations

I made this little diagram for you, I hope you serve something


I have the following question

What function performs the pin 49 [/ ROMSEL (aka / CART)]?


I using a decoder memory, I would like SRAM to place in position 80:6000, this table would be nice?



greetings colleague

First: you repeatedly have said banks $00-7f. This is misleading. It is banks $00-7d (because as you already know, banks $7e-7f are used by 128KB RAM). Maybe at the hardware level the mask ROM gets assigned to $00-7f and then you "lose the last 128KBytes" because (again at the hardware level) the 128KB RAM region the SNES uses "stomps over" it. But I wish you would stop saying $00-7f when that's simply misleading.

This is further supported by the fact that the actual developer docs state clearly that banks $80-fd -- not banks $80-ff (read closely!) -- are mirrored from $00-7d. Meaning: you lose the last two banks, so effectively you can't even get a full 32mbit in mode 20 (you can get at most 32mbit - 64KB)



Your math is wrong:

* Banks $00-7d = total of 126 ($7e) banks
* Address ranges $0000-7fff are reserved (unmapped to ROM), leaving you with 32KBytes of addressing space for ROM per bank
* 126 * 32,768 = 4,128,768 bytes
* 4,128,768 bytes = just shy of 32mbit (32mbit is actually 4,194,304)

If you want to design a cart that does not allocate address ranges $0000-7fff in banks $80-fd for NES registers/etc., then yes, you could get "almost" 64mbit (specifically 64mbit minus 128KB) within that region. However, that would not be mode 20 -- that would be a new/custom cartridge. And if you were, additionally, able to overcome the "last 2 banks" issue (i.e. banks $fe-ff) then you could get a full 64mbit.

I really do not understand why everyone on this forum is suddenly, out of the complete and total blue, all at once (multiple people!!), jacking off over the memory map. People are acting like this is a spawn of satan or some super insanely complex thing to understand -- it isn't. Maybe at the hardware level (address lines, the 128KB of RAM at banks $7e-7f, etc.) it's complex, but when visualised by Nintendo in their own documentation it's pretty damn clear.

They just didn't do a very good job of leaving full linear addressing space available. I've already stated in another post how I would have designed things: in that diagram you'd end up with 251 banks available, all 64KBytes, linearly, for ROM. That's 16,449,536 bytes, or roughly 125.5mbit.

But whoop de doo. WHO CARES, IT'S NOT LIKE ANY ONE OF YOU ARE MAKING GAMES THAT ARE GOING TO TRULY NEED (read: not waste) ALL THAT SPACE. So I wish people would stop jacking off. :P

Edit: lots of edits, actually.

Agreed. Unless they use it for "streamed" music or something in the like (don't know if this counts as a waste or not - it probably does since the SNES is able to do high quality sequenced music).

the SNES asserts the /CART line, according to this memory map: http://wiki.superfamicom.org/snes/show/ ... memory-map

Read the whole section.


That part is important.


You need to be more specific. Do you already have decoder electronics you want to use? Are you designing a new cartridge. Are you modifying an existing one? Is it LoRom/HiRom?

Let's keep the topic on LoRom cart. The following is some info on how to analyze a cartridge. The Last paragraph is most important, I believe it has the tips you need to make a good decision:
Here is how I would approach a pre-existing cartridge I want to hack:
You need to know how your cart's decoder is mapping SRAM/ROM. By analyzing a cartridge that you want to hack, you can discover how it maps ROM/SRAM. You do this by taking apart the cartridge, you will need the security screw bit. Then, using a multimeter, you can discover the connections on your cart. I did this when learning first about memory decoding, I found it really helps to do it yourself and learn it.

I have some advice when you are actually using a multimeter on your cart: When you can't see the traces on the cartridge, say they go underneath an IC, don't fret. You can poke around the pins with your multimeter until you discover the correct connection. Be sure to keep a piece of paper and you can map the connections yourself. It's a great exercise.

Then, with the full understanding, you can decide how to best approach modifying the cartridge.

I can tell you a couple helpful hints that I have learned, however they require more research to reach full conclusions:
The LS139 in the carts I have analyzed (about 3), they all mirror ROM 0000-7FFF and 8000-FFFF. That means that mapping SRAM to 6000 will require hacking. The MAD-1 however, in the one cartridge I have verified this, and Neviksti claims all MAD-1 carts, they do not map anything to 0000-7FFF, and ROM only maps to 8000-ffff. So perhaps the modification would be easier to map SRAM to 6000 in a MAD-1 equipped cartridge. It requires research. I do not know MAD-1 decoding, so I cannot help you at this point. Hopefully my hint helps.

I modified my post to be more exact.



My Math is right. You are doing calculations for only Banks 00-7D. My calculations include Banks $80-$FF. Like I said, this is under the notion that you can put new information into the upperbanks instead of mirroring from the lower banks. This is of course, all following the guideline of ROM only in 32KB chunks.



Deciding not to mirror upper banks (aka connected A23 to 'stuff') and keeping ROM mapped in 32K chunks, gives you max 63 Mbit. Then, you decide to map ranges $0000-7fff to other things, then you can get more than 63Mb for your cart. However, since connecting $0000-7fff seperate from $8000-FFFF involves connecting SNES A15 to peripheral, we are learning more about universal memory mapping rather than a traditional LoRom model. My document serves as a gateway to understanding universal memory mapping potential in the light of learning what traditional LoRom is identified as.


I created this document solely because all of the memory maps I used I found inaccurate and only provided a glimpse into the full mapping. I wanted a quick reference to see what SNES bank corresponded to what ROM address. I created that in my document. Along the way, I found it important to teach some of the topics I easily understood. Moreover, I am at the point of understanding memory mapping is truly a universal concept and these things we call LoRom and HiRom really are not standards. Whether you see eye-to-eye with me on that is irrelevant. I can do what I want, I can map memory how I would see fit, and so can you. However, I aimed to please the concept of LoRom to help myself and more so the other people whose vision may be clouded, thinking that LoRom and HiRom are strict definitions that all carts must follow, or simply for people that were in my position when I learned SNES coding for the first time, and had no idea WTF I was doing. I didn't know shit about electronics, and nobody was there to give me the points of view I can clarify for others in my doc.



My document is not about who cares or how to make the biggest cartridge, this document is simply stating facts about memory mapping. Now people can better understand the potential of memory mapping and get away from false appearances of strict guidelines as was impressioned upon myself and others with the likes of the way LoRom and HiRom had generally been taught.

I hope you guys enjoy it.

One thing you need more memory for is voices, be it voice acting or vocal music. Look at "One-Winged Angel", a song played near the end of the first Final Fantasy game after the end of the Super NES era. In addition to the samples used by the sequenced backing track, there are roughly 17 seconds of samples:

• estuans.wav: 4 seconds
• sephiroth.wav: 1 second
• sors.wav: 2 seconds
• inanis.wav: 2 seconds
• venias.wav: 4 seconds
• gloriosa.wav: 4 seconds

At 8 kHz and 4.5 bits per sample, that's almost 80 kB just for the vocals. Something less repetitive or better than telephone quality would be even bigger.

hello thank you very much for answering

I'm creating my own cartridge, I'm just in the last part in the decoders. I know how it works (truth table), and learned how to use it (74LS139), but I'm trying to learn the address maps (A0-A23), I made a diagram (old post), I wonder if it is correct?

and through a 74LS139 to dynamically change directions.
but did not know the most important, assign them to a particular position.

example:



/ROMSEL = 0
A22 = 0
then enters the rom of 32 Mbit and assigns it to the memory 00:8000

/ROMSEL = 0
A22 = 1
then enters the rom of 64 Mbit and assigns it to the memory 40:0000

/ROMSEL = 1
A22 = 0
A14 = 1
A13 = 1
then enters the SRAM and assigns it to the memory 00:6000


but, is that correct?


regards.

PS: My first tests were with tester, too.

Looks correct. I double checked. Make sure your ROM connections to the SNES Address bus is right. In short, I won't explain it.

yeahhhhh! .... thank you very much for everything, I'm happy, I love you Bazz , wuajajaj

seriously, because if not for your guide, could never have understood how to map address.

Thanks for your time, thank you for sharing your wisdom, thank you for your willingness, finally thanks man.