It is currently Sun Jul 22, 2018 6:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 108 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8  Next
Author Message
PostPosted: Sun Jun 17, 2018 8:17 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2714
I don't have the tools to build a custom cartridge, let alone test it on one. That's why it's at $a0 instead of $80 or $00. It's funny how Nintendo never placed SRAM in the most optimal places.

It only takes approximately 30 lines because once it hits the max amount of DMA size, it ignores everything after it.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 9:48 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7322
Location: Seattle
Unlike on the NES, where there would have been a clear advantage to overflowing regular code into save RAM, on the SNES it's most often exclusively for save data.

Also, decoding both $3xxx and $5xxx should have required another pin on the MAD-1, and couldn't be done with the 74'139 at all.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 9:50 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20283
Location: NE Indiana, USA (NTSC)
Perhaps Nintendo put SRAM on Super NES PCBs in out-of-the-way address spaces because it didn't expect SRAM to be used for anything but battery save. The less time the save chip spends enabled, the less likely it is to suffer data loss when losing power or otherwise running out of voltage spec.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 10:06 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2714
Weren't there games that used non-battery SRAM?


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 10:16 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7322
Location: Seattle
Not significantly. Only GSU carts.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 10:29 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2714
So you're telling me that if back in the day, if I tried publishing my game for Nintendo, they would put a lousy battery in the cart that will cause the game to malfunction after a while?


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 10:42 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7322
Location: Seattle
wtf?

No, what they would have told you was "You don't want to waste your money buying a small amount of extra RAM on top of the 128 KiB that are already in the console".

Historical production costs were huge, probably $10-$20 per unit, even in volume. Adding several more dollars on top of that wouldn't have been something you could have gotten anyone sane to finance.

Also, the battery's presence wouldn't cause the game to malfunction, it would just mean that if you were using cart SRAM for something other than just save data, the save data was more likely to get destroyed.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 10:49 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2714
The primary reason for the SRAM, is for software sprite rotation, and not having to pad out levels to avoid software rotating sprites clashing with each other.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 11:04 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3349
Location: Nacogdoches, Texas
So Alisha's Adventure uses the same 8KB of sram? If you ever wanted to have something tested on real hardware, I have an SD2SNES I can use.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 12:51 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2714
It uses 128kB of SRAM, but it's split up into 8kB banks because it is using an existing cartridge memory layout. If you look carefully at the above code, I implemented an "animation mode" that is specifically for jumping across SRAM banks for rotating sprites.

Code:
sram_bank_crossing:
lda {animation_index}
xba
and #$ff00
-;
cmp #$2000
bcc +
sbc #$2000
inc {temp2}
clc
bra -

single_sprite:
lda $0002,y
bmi sram_bank_crossing
lda {animation_index}
xba
and #$ff00
clc
+;


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 2:53 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3349
Location: Nacogdoches, Texas
BSNES would have allowed you to put SRAM wherever you would have wanted, wouldn't it? I thought the roms had headers that define how much SRAM they need and where it is.

What did you need 128KB of SRAM for?


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 3:06 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20283
Location: NE Indiana, USA (NTSC)
Caching software-rotated sprite cels, as an alternative to putting a GSU on the board to rotate them in real time like Yoshi's Island does.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 3:43 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 935
lidnariq wrote:
Unlike on the NES, where there would have been a clear advantage to overflowing regular code into save RAM, on the SNES it's most often exclusively for save data.

I have a reason. Speed.

My game uses an H-IRQ to pull off an elaborate raster effect, and it needs to run at 6 master cycles per byte to get everything done within the available window. Right now I use a trampoline in shadow RAM to get into a FastROM bank, but the IRQ plus a full slate of HDMA eats the bulk of the CPU time available during active display, and saving a JML per line plus two master clocks on every byte accessed on the stack might actually be worth it, even aside from the small speedup to regular code.

This is obviously an edge case, but it may actually be topical because there's a section in Mission 1 of Metal Slug that seems to want three 4bpp BG layers. And with the way it's arranged, it may be possible to use a combination of sprites and window masking to cover a scroll split executed with an H-IRQ. You might say it's overkill to add a custom SRAM configuration just to avoid having to reduce the bit depth of a BG layer, and you may be right. This particular section isn't even that busy, so it may very well not even be helpful (other than the small general speedup from having fast work RAM and a fast stack, and when porting Metal Slug to the SNES, any advantage is worth looking at).

...it may be possible to use sprites for the waterfall once the beam is below the HUD. There's not much else going on in that section, and the destructible part of the wooden structure is offscreen before the bulk of the waterfall comes into view. The ship and cliffs look like they'd reduce to multipalette 2bpp pretty well if you gave them a bit of HDMA and maybe some bridging sprites. This could be a good candidate for an OBSEL split, particularly if we decide to try to use real colour blending on the near-field waterfalls instead of checkerboard dither... it looks to me like the cliff on the left is out of view before the near waterfalls overlap any part of the far waterfalls, so the latter could be switched back to a 4bpp BG to permit layer blending.

I fear the water is going to have to slow down a bit. Even with tile reuse (and there are repeated elements in that far waterfall), there's just not enough bandwidth, or VRAM, to do 60 fps without butchering the graphics... wait, could it be possible to use colour math to combine a static 4bpp cliff+water background with mostly 2bpp animation? With enough tile reuse, the whole animation might fit into a useful amount of VRAM, or at least enough could be cached to leave the bulk of the bandwidth for the foreground. Still not hitting 60 fps, but might be faster than trying to use 4bpp for everything... One could also exploit the VRAM gate settings to overwrite half the bitplanes in a 4bpp tile set, but while that does reduce the bandwidth requirements, it also prevents compact tile caching/switching (which there may not be room for). Also, arranging tiles so they can be replaced selectively without a ton of overhead is harder when using 16x16 BG tiles. Using 8x8 tiles allows finer colour control but wastes VRAM on map data. Lots of work to figure out the best way to do this...


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 4:05 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7322
Location: Seattle
Sure. With 16-bit M/X, the effects of fast B bank seem to be very approximately equal to fast K bank. And with a standard LoROM cart, you can even use cart RAM with fast timings.

But with 8-bit M/X, the benefits of fast B bank are only roughly 1/3 ish of fast K bank. It's not clear whether that difference is big enough to matter.


Top
 Profile  
 
PostPosted: Sun Jun 17, 2018 4:11 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3349
Location: Nacogdoches, Texas
I thought I had shown in a picture that you can use BG3 for the middle layer in that scene in conjunction to a window layer, and you'd have enough color for everything but the rocky edge of the BG layer and a few highlights on the tree trunks that you could use a few 16x16 sprites for. By some stroke of luck, the layer doesn't actually extend up to where the status bar is.

Something that's a real pain though is that the wooden fortress is really two layers in of itself. Luckily, you can get by a lot of it by messing with tile priorities, but there are some parts you are going to need sprites for. I think both front and back parts use the same palette, so you might be able to get away with an Equinox style sprite masking system so sprites don't need to be there all the time (so you could potentially save vram space). There is so much layering in this scene that even the Neo Geo even displays sprite pixel per line dropout with the last explosion, but that's also because they weren't smart about lowering it. (The waterfall layer is presumably loaded in its entirety even while most of it is occluded).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 108 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group