What occurs if I where to build a game that would be much larger in ROM size than any standard N64 cart made? Would I be able to say, make a game tittle that would be 256MBs in ROM size or would the N64 firmware block that or not work with it? ...Obviously provided that an evercart of some sorts would be used with the appropriate SD card size...
Been curious as to this question, too. I know there's some homebrew on certain systems that have managed to accomplish this, so maybe
In regards to the everdrive, it really depends on the size of the flash ram chip that the game gets loaded onto. If it's big enough to hold a 256MB rom, then it'll work on that cart. But when it comes to the console itself, I don't know to be honest. Can maybe test by adding a bunch of empty space to the end of a rom, to make it artificially bigger, and see if it still loads?
There are only 16 AD lines on the N64 cart interface. You won't be able to access more then 64MB at a time with that. That's not to say there couldn't be more than that on a cart though.
So I would assume the code would have to somehow have a runtime that would partition how much chunk of the storage would be used at any given time... A little like a state machine but just for storage/memory management?
There seems to be two different questions here. One is the theoretical maximum size of a cartridge that the N64 can access, which is just under 256MB - the cartridge ROM space extends from 0x10000000 to 01FBFFFFF (basically 256MB, but the last 256KB is overlaid by the boot ROM in the PIF). The other is how big a ROM you can load into an Everdrive, which appears to be 64MB - the RAM on mine is a Micron technology MT48LC32M16A2-75 which is a 512Mb (64MB) SDRAM organized as 32M 16 bit words with a maximum clock of 133MHz.
Would it possible in game logic to load in a 64MB ROM and then just have the ROM/Game access other data on the SD card space through code?
There is an API exposed that lets code on the N64 side access the SD card and presumably you could use that as a basis for some sort of paging system. The other alternative would be to use marshallh's 64drive flash cart, since that has 256MB of RAM and would allow you to create a much larger image without paging.
Holy cow... That's some 199US. I think I would rather go with a paging solution and have that work on a variety of carts. This is getting interesting... ...I feel as if, if I could backport the game I am currently building, (Which is a Unity game, but it's completely game engine agnostic, all the assets/logic and things are all independent from the game engine, and are actually meant to play like a 32bit-era game, [Most texture sizes don't even exceed 32by32/64by64 in size]), and then maybe be able to have a ROM/file system that would be able to call or allocate larger chunk sizes of data, then I could go ahead and exploit things like being able to bring pre-rendered cutscenes onto the game, things like audio, complex thing you wouldn't be able to get on a 32mb ROM. If I backport something, then I think it would be worthwhile being able to exceed the traditional limits as a proof-of-concept type of thing, enrich the game experience a little like it couldn't have been done before.
As far as I can see, there is no documentation, just code... http://krikzz.com/pub/support/everdrive-64/ED64-IO.zip
From the look of it, the files that are of most interest to you are mem.c/.h and disc.c/.h - the first describes how to write to the cartridge emulation RAM from the N64 and the second describes how to access data on the SD card. It's just block level IO though, so you would need to supply a suitable filesystem layer.
