Quick question

FEB0-FEBF, I remember, are. Not 100% sure about FEB0 and FEB1, but B2-BF I am sure of =P

 

FF88-FF8F. And you can always use the SRAM (plenty of space) or Z80 unused space (A13000-somewhere?).

If you don't know how to use SRAM, try looking on hacking-cult.org

 

SRAM handled correctly should work on real hardware, as the SMD has SRAM support and so does the Tototek cart. Sonic 3's saving code probably wouldn't work because I believe it uses EEPROM instead of regular SRAM. If SRAM code crashes, it's because you're doing something that works on emulation but not on the real hardware.

 

Yeah, I found tis to be a problem when I had to define a free RAM value for my options in my Sonic 2 menus in S1.

Ultima suggested using SRAM for free space before, but he also said how much slower it is to use in a pratical sense, I didn't really test how slow that "slower" ism though.

 

Use the stack. (see -> Sonic Programming)

 

you can't always use the stack =P

 

I don't know about SRAM for variable usage. Maybe for stuff that needs to be saved between levels, but not constantly.

About using Z80's address space may work.

Both ways are really diry ways to handle game variables. I suggest cutting down on SST entries if you really need space quick. One SST entry is 64 bytes in size. Sometimes you just need 128 bytes. Two objects less in game may work.

You can find out where objects are loaded by looking into the disassembly. Freeing one or two object entries from never being touched is what I am talking about. You are talking about reserving an object space for something that isn't an object. I call that as dirty as using SRAM for non SRAM purposes.

 

Problem with that approach is that you don't know where an object is loaded. However, you could do just the opposite: create a new object and insert it in the level, making sure that you use screen-relative positioning so that it's always in the table.

 

Save RAM isn't any slower than normal RAM (unless you're talking about the 32X). The only problem is that most (all?) carts only sported Save RAM that's 8-bits wide so if you want to write more than a byte at a time it will be slower since you'll have to break it up into byte writes (of course you have the same problem with Z80 RAM).

I would definately recommend against using Z80 RAM though. You have to bus request the Z80 which is both slow and stops the sound driver until you are done.

 

Believe me, I saw some games storing variables in Z80 RAM XDDD. I don't remember any particular, but I think Thunder Force 3 maybe? Or am I wrong...

 

I think the game should be stored on a RAM chip and be able to rewrite itself. :o (Of course that means if you do something wrong in the game then it literally fucks itself, but hey.)

But seriously, cutting down on SST entries is best, if you need more space than the little lumps drx etc have proffered.

 

You could always use the 6291456 unused bytes from 400000 to 9FFFFF. According to the Hacking CulT 68000 memory map, that's unused. You have a lot of space there. =P

 

Yeah, but I believe you have to do your own address decoding for those addresses, so you'd have to build your own cart PCB, not to mention that it probably wouldn't work in emulation.

Or, you could port it to the Sega CD.

 

You can't use 400000-7fffff. It's used by Sega CD. Well, you can use it if you don't want compatibility with SCD =P

Oh, and the SH2 code on 32x is rewritable (it's obvious, but anyway :P)

Edit: btw, remember you can use one byte for 8 different things. I mean, bitfield.

 

I would rather go for 256 different things than 8.

The problem with 8 bits is that you will only get 256 different combinations. With 16 bits you will get 65536 different combinations. That is such a big difference.

If 8 bits is good enough, then Sonic would be possible to run manually in loops on Game Gear. But it isn't enough with 8 bits, even if you can fake 16 bits by accessing two 8 bits values at different times.

 

There is plenty of space in RAM, you just have to be a bit clever.

This idea with the SST is good. There is others examples like that:

Think about the level layout for example. In almost all level layouts, more than the half of the space in RAM isn't used. Sometimes the background don't use all 16 Y lines, sometimes the foreground don't use all 80 X columns (never I think).

In 16x16 mappings, this is the same thing. All blocks aren't used, and even a space is reserved to background layers deformations ($A800-A9FF).

Take a look at 128x128 mappings too: you can find a block that isn't used in some levels. If you build your own level, you can always keep some blocks (80 bytes each) for your RAM needs.

Collisions definitions can help too. And even for very short values, you can use the first nybble of each color in the color pallets, or even more, the last bit of each RGB definition. Useful for color related calculations (Genesis only I guess).

The only problem with this is that all these RAM values are reset while starting a new act. It's the same for the SST.

 

So that's what you are doing. In favour for Hblank effects, you cut down the backgrounds to make them just wrap by hardware.
And taking off the drawing gives you almost time to run Vblank during all lines. But you are stuck. You still don't have time if I am guessing right.

Also, I have already used Hblank to do these effects you want to do. I have also together with LocalH tested it on real hardware. There are a lot of things that you can't escape. Be prepared for failure. I had to scrap that idea. Not even Sonic 3 with optimized backgrounds could kick off the Hblank in time. You need more than 7 MHz, or you have to cut down on Sonic. And the Hblank on Genesis is really wierd. It wasn't designed very well. Don't get fooled by the emulators' output.

Good luck though!

No. That nybble has some effects on real hardware I have heard. LocalH knows more about that.