"16-megabyte address space"

[FistOfFury]

From my 65816 book:
"The primary distinction between the two processors is the range of addressable memory: the 65816 can address up to sixteen megabytes"

and from another page:
"The 16-megabyte address space of the 65816 is divided into 256 64K banks."

1. Does that mean ROMS that the CPU can use can be up to 16MB. Is the book wrong or is it talking about something else?
2. What was the biggest SNES game ROM ever made, and could they have made bigger ones that would have worked on the SNES?

I tried making a ROM with 256 64K banks, and it was, yup, 16MB file size. Loaded it into DOS zsnes, but it said that the ROM was too big. The GUI in win zsnes just froze after trying to load the ROM. I kept shrinking and remaking the ROM until it would load up in zsnes, it had 96 64K banks with a file size of 6.00 MB.

[Malcster]

6 Megabytes and therefore 48 Megabits is, I believe, the size of the largest SNES ROMs made (Tales of Phantasia is this big, as is Star Ocean. I think SFA2 is this big as well, although not too sure on that one). I don't know if the SNES could use ROMs any bigger.. it's possible, but as you have found out that facility has not been emulated.

NSRT defines the largest ROM size it will deal with as 6 megabytes + 512 byte header, so it's possible Zsnes does that as well. Whether the actual SNES can handle it though, I couldn't say.. it uses a slightly customised 65816, so there's a chance that doesn't have the exact addressing capacity your book lists.

[PHoNyMiKe]

I bet it's just zsnes saying it's too big. since there's no commercial games bigger than that, why bother emulating it? there are however old bad dumps that are bigger, which aren't worth emulating, so making it a 6MB limit seems fine. There are copiers out there capable of holding 16MB, so the only sure way would be to load your rom into one of those and read the byte at the end of the file.

[Noxious Ninja]

I remember somebody (probably The Dumper) talking about being able to increase the SO ROM to 8MB and insert the uncompressed graphics back in, but I'm not sure.

[PHoNyMiKe]

a guy named neviksti combined the decompressed (decrypted?) graphics into a single rom, to play on snes copiers. since copiers only emulate rom, there's no other way to play the full game on them. since emulators can be improved with more emulation, you can play the game on emus. I don't know if his hack works in emus (again, there's no point,) but the 12MB file is for copiers.

[FistOfFury]

NSRT defines the largest ROM size it will deal with as 6 megabytes + 512 byte header, so it's possible Zsnes does that as well. Whether the actual SNES can handle it though, I couldn't say.. it uses a slightly customised 65816, so there's a chance that doesn't have the exact addressing capacity your book lists.

Are you sure it's customized? IIRC, all it is the CMOS version 65816 (65c816), with probably the word "Nintendo" stamped on it. My book has the data sheet for the 65c816, looked over it and it's almost virtually the same. It even says it can address 16MB.

So, does anyone know for sure what's the biggest theoretical supportable ROM? Is it indeed somewhere around 16MB? Anyone know? neviksti? pagefault? nach?

I bet it's just zsnes saying it's too big. since there's no commercial games bigger than that, why bother emulating it?

Well, an emulator is supposed to emulate all the full capabilities of a console right? It should support the full theoretical limit of the CPU. What if someone wanted to make a 16MB homebrew game and run it on an emulator? Imagine the possibilities, if it was a co-op netplay compatible game...
I think the 6MB limit should be removed...Oh, and I don't have a copier

[neviksti]

So, does anyone know for sure what's the biggest theoretical supportable ROM? Is it indeed somewhere around 16MB? Anyone know? neviksti? pagefault? nach?

I have to go on a slight rant here.
One major problem with the emulators currently is that they deal _only_ with the ROM. The cartridge obviously contains more than just a ROM chip, and the emulator is forced to guess the contents of the cartridge from the ROM.

The cartridge is connected directly onto the system bus. Therefore you can do many interesting things with it directly from the CPU, or the DMA control. It also means you can wire the thing up however you want (as a "medium" it is not constant at all, unlike a CD-ROM or such).

I can tell you many things precisely about the console, because that is (almost) a constant. But the cartridge? You can do whatever you feel like with it. Therefore the question: What is the largest ROM? (ie what are the limits of the cartridge?) Don't compute.

A ROM doesn't need to have all that header info to play on a SNES. That's just a loosely enforced Nintendo convention. However the emulators currently need it since they only get the ROM. This is also why I sometimes get in arguments with Nach about all his ROM header fanatics. It just seems to be missing the point all together.

... end rant ...

The CPU can access 16MBytes directly. However, roughly 4MB is mapped to things in the console. So the largest "statically mapped" ROM is roughly 12MBytes (you probably can go above this by using every single unused address location).

Most carts are HiROM or LoROM:

HiROM - uses A15 (address line 15), so the "ROM banks" are 64kByte
... none currently use A22 (address line 22)
LoROM - doesn't use A15, so the "ROM banks" are 32kByte

Usually neither use A23 for mapping the ROM (so any ROM appearring in $00-$7F is mirrored to $80-$FF). Some HiROMs do however (Tales of Phantasia, Dai Kaiju Monogotari 2).

And to further answer your questions. The largest ROM I know of currently, is my hack of StarOcean which is 96Mbits. Which I would call neither HiROM nor LoROM, but some could argue it is both.

I think the 6MB limit should be removed...Oh, and I don't have a copier

I offered one to MarcTheMer in another post. He hasn't responded. If I don't hear from him soon, I offer it to you.

[FistOfFury]

The CPU can access 16MBytes directly. However, roughly 4MB is mapped to things in the console. So the largest "statically mapped" ROM is roughly 12MBytes (you probably can go above this by using every single unused address location).

Yeah, I was wondering about how the console stuff fits into the picture. (PPU & DMA registers, APU, and whatever else I forgot, WRAM, VRAM, the stack? still confused about the last one.) So, they all take away about the first 4MB from the 16MB pool, huh? ouch, that's alot. I wonder how come there was never any SNES games bigger then 6MB, if it was because it was time for the N64 to take over the scene, or maybe because the extra ROM chips that the SNES game paks needed were too expensive.
EDIT: Oh yeah, if someone wanted to, they could have used more then 1 cartridge for huge games couldn't they? You know, like todays games come as sets of multiple CD's, and you load each CD in sequence as you progress through the game. I wonder if you could do that with carts too, but how would that work out? Maybe have a way where the carts can connect to eachother and transfer your characters stats and points, etc, into the other carts s-ram? Wonder if that could work.

I think the 6MB limit should be removed...Oh, and I don't have a copier

I offered one to MarcTheMer in another post. He hasn't responded. If I don't hear from him soon, I offer it to you.

Sweet, I'll definately take it if he doesn't want it

[illegal eagle]

The stack is in WRAM, I think. APU and VRAM have their own address spaces, so the CPU has to access it via ports (2140h..2143h, 2139h, etc).

There's a 'mapper' on the cartridge that controls how the cart responds to memory accesses. There's no theoretical limit of ROM, but the game developers have to create their own memory handling.

More than one cartridge wouldn't be possible - VRAM + WRAM + SRAM are just ca. 224 KB, depending on the SRAM size. Where would you store the data?

The carts could connect (Seta had a slow modem in one of their N64 ROMs as you might know), but you'd need a very good game to get the money back.

[FistOfFury]

More than one cartridge wouldn't be possible - VRAM + WRAM + SRAM are just ca. 224 KB, depending on the SRAM size. Where would you store the data?

I don't see why it couldn't work, all it would do is transfer the save slot from cart 1 to cart 2. i.e. Lets say the game is a two cart game. The only thing that the second cart would do is to take the first carts sram and copy it into it's empty sram, in order to transfer your character(s) and their saved stats to the second part of the game. You would then turn off the snes to clear its RAM, disconnect the two carts, and then just use the second cart to play the second part of the game? Still wouldn't work?

EDIT:

The carts could connect (Seta had a slow modem in one of their N64 ROMs as you might know)

No, I didn't know that....

[illegal eagle]

Yeah, if you just want to save your progress etc. then it would suffice. Didn't read properly.

I could post a scan of that N64 cart (from a magazine) if you like, but this would take some time since I'm online for just one or two days per week. The game's "Morita Shogi 64", a Shougi (Japanese chess) simulation.

[FistOfFury]

Sure, go ahead and post it here, or PM me it, whenever you have time.

[Dmog]

NSRT defines the largest ROM size it will deal with as 6 megabytes + 512 byte header, so it's possible Zsnes does that as well. Whether the actual SNES can handle it though, I couldn't say.. it uses a slightly customised 65816, so there's a chance that doesn't have the exact addressing capacity your book lists.

Are you sure it's customized? IIRC, all it is the CMOS version 65816 (65c816), with probably the word "Nintendo" stamped on it. My book has the data sheet for the 65c816, looked over it and it's almost virtually the same. It even says it can address 16MB.

So, does anyone know for sure what's the biggest theoretical supportable ROM? Is it indeed somewhere around 16MB? Anyone know? neviksti? pagefault? nach?

I bet it's just zsnes saying it's too big. since there's no commercial games bigger than that, why bother emulating it?

Well, an emulator is supposed to emulate all the full capabilities of a console right?(

No.You're wrong. An emulator is supposed to be able to play the games of the original system.Period. Whether it's by imperfect means or by using game-specific hacks it does not mater. If no "roms" is bigger than 6megs then there is no need to bother,even if the original hardware had the capacity for more.

(edited) Since I was told to edit rather than double post...Just wanted to mention the above was indeed sarcasm.

"Concentrate on emulating the games,not the hardware"...Well that seem to be the mentality of many emu coder in any case... That's too bad in my opinion because it leads to less than stellar emulation...But then your average emulation fan does not really care that much about accuracy..majority rule heh

Anyway that's the feeling I have the the snes emu scene."Nah they'r no need too emulate dat it's stoopid it's fine theway it is"



P.S Anyone can point me to a link of MK's "rant"? (you know the one).

[grinvader]

P.S Anyone can point me to a link of MK's "rant"? (you know the one).

Board rant and IRC rant.

[funkyass]

for the sake of proper preservation of data, well eventually need to move from emulation to simulation of the snes.

like it or not, those carts still contain info outside of the ROM, even if its only how the traces exist on the PCB.

[Dmog]

P.S Anyone can point me to a link of MK's "rant"? (you know the one).

Board rant and IRC rant.

Thank you grinvader.

Here's the link to the first page:
http://www.snes9x.com/forum/topic.asp?w ... IC_ID=9869

[Malcster]

Are you sure it's customized?

I'm fairly sure at some point someone knowledgeable told me it had a few enhancements which Nintendo had got done. But then, I can't remember specifics, and if you have a data sheet that says no difference you may be right.

[Kagerato]

Yeah, I was wondering about how the console stuff fits into the picture. (PPU & DMA registers, APU, and whatever else I forgot, WRAM, VRAM, the stack? still confused about the last one.) So, they all take away about the first 4MB from the 16MB pool, huh? ouch, that's alot.

The registers occupy relatively few addresses, but their range is huge. In the LowROM map, register space ranges from $xx:2000 to $xx:5FFF. That's 16 kbyte, per bank.

The SPC700 has its own RAM, very separate from that of the CPU's memory regardless of what mapping is used.

Work RAM is a part of the CPU memory map; it's always in banks $7E and $7F.

VRAM is video ram. In other words, it's the section of memory specific to the PPUs. Like the RAM of the SPC700, VRAM is completely separate from the CPU memory map.

The stack location (and the direct page location, for that matter) is variable, thanks to additional registers (compared to the 6502) called simply the stack pointer and direct page pointer. They're effectively 16-bit (if in the hardware they actually contain a third, high byte it is always zero). Therefore the bank where the stack and direct page is located can never change; it's always the first ($00).

I wonder how come there was never any SNES games bigger then 6MB, if it was because it was time for the N64 to take over the scene, or maybe because the extra ROM chips that the SNES game paks needed were too expensive.

Partly it was indeed because the Nintendo 64 was coming by the time anyone considered projects that would require such massive storage. I don't think cart construction costs were a highly considered factor in the SNES era, because many carts contained specialized chips. Some of those chips were processors significantly faster than the SNES CPU. They might have had to raise the game cost slightly, but it doesn't seem to me that there was even a decent amount of trepidation at including more expensive hardware in SNES carts.

[Malcster]

Partly it was indeed because the Nintendo 64 was coming by the time anyone considered projects that would require such massive storage. I don't think cart construction costs were a highly considered factor in the SNES era, because many carts contained specialized chips. Some of those chips were processors significantly faster than the SNES CPU. They might have had to raise the game cost slightly, but it doesn't seem to me that there was even a decent amount of trepidation at including more expensive hardware in SNES carts.

Didn't games with SA-1s end up costing something stupid like $80?

[grinvader]

I don't remember exactly, but I saw a game costing FF600 when it got out. That makes around $90.
I think it was Yoshi's Island...

[FistOfFury]

Thanks for those posts everyone, it's true that you learn something new everyday Oh, and I remember Street Fighter Alpha 2 was kinda high when it first came out, I think I paid somewhere around $60-65+ (U.S.) for it.

[Bent]

I don't remember exactly, but I saw a game costing FF600 when it got out. That makes around $90.
I think it was Yoshi's Island...

Yoshi's Island was 70 bucks here. It was the most expensive game I've seen. I paid about 60 (I think) for Kirby's Super Star.

[illegal eagle]

Anyone remember Sega's first recommended price for Virtua Racing?

Sure, go ahead and post it here, or PM me it, whenever you have time.

Here it is. PM me your email if you want a pic that is three times larger. Another pic. The cart has one modem with two outlets.
Nintendo had a deal with the telephone company NTT for multiplayer games. The transfer rate is very slow, to save Nintendo some money and to allow longer connection times.

Oh, and while I was scanning interesting stuff...
Blizzard's SNES development station, at least one of them. (Blackhawk, Lost Vikings Rock'n'Roll Racing) The pic is from early 95'.
Shiny's Genesis development kit, used for Earthworm Jim. The magazine got it from David Perry and raffled (w?) it.

[FistOfFury]

Cool pics. Hehe, pics of Blizzard's "dev stations" always make me chuckle.