[MarkoMan]

Well, with the TAS up, I guess my suggestion to make a timer that counts up instead of down in terms of ranking is too late...

Wow @ multiple choice. I figured out the bottom path easy, but it has never occurred to me ever that Sonic can't be crushed by jumping... amazing detail.

Now, I can beat this.

[Tamkis]

Quote

Ah well, it's not a disaster if this glitch does happen, because by resetting the game you'll get back to exactly where you left off, and there's no danger of your save file being corrupted because the Sonic 1 and 2 save system has been entirely replaced by the Sonic VR one (yes, this is a hack of a hack!)

You know, I kind of figured that your base game engine was Sonic 1 & 2, since one of the levels had a sonic 2 enemy from WFZ and Sonic 1 elements .

Great hack as always, ColinC10! I really liked how you used many elements from Sonic 1 & Sonic 2 in one level, something I've always wanted to see. Multiple choice was hard, and High Jump was even harder (still haven't completed it). That's the only level I have left to complete. The Music selection is catchy and appropriate, as well as the backgrounds. Good luck competing against Flamewing for the Best Hack Trophy in the contest.

BTW, have you or anyone else have tried this hack on real hardware with a flashcart? I'm really curious as to see if it would work, what with the ROM using streamed PCM music and being 6MB in size.

[Sik]

Tamkis, on 23 September 2011 - 09:56 PM, said:

BTW, have you or anyone else have tried this hack on real hardware with a flashcart? I'm really curious as to see if it would work, what with the ROM using streamed PCM music and being 6MB in size.

Considering most flashcarts cap at 5MB, nope, it wouldn't, just because of the cartridge. This is because mapper support in flashcarts is only enough to get Super Street Fighter 2 running and nothing more (this also means that bank switching only works in the last two pages).

[GerbilSoft]

ColinC10, on 22 September 2011 - 10:08 PM, said:

If Gens is more accurate than Kega Fusion at emulating Mega Drive hardware, then it would be really useful for myself and other hackers if you could give a brief list of what the differences are in simple terms that idiots like myself can understand. For example: "When using bankswitching, only execute code in the first 512 KB, and use the higher banks for data fetches". That way I can correct the errors in Sonic VR, and other people might be able to fix these kind of mistakes as well.

If Kega Fusion is more accurate then I don't really care what limitations Gens has. I usually try to support as many emulators as possible, but this year I'm short on time so I'll leave my message on the first post that says "use Kega Fusion".

The 512 KB code limitation is actually due to an error in Gens, and isn't a limitation in hardware. The problem in this case is that Starscream (Gens' 68000 emulator) has two fetch functions: one for instruction fetch and one for data fetch. The data fetch function is properly managed by Gens' SSF2 mapper, but the instruction fetch function is not. Hence, if you have any banks swapped out, executing code there will act like the bank isn't swapped, which can cause weird issues. (I recommended the first 512 KB because that's guaranteed to not be swapped.)

I will eventually fix this limitation in Gens/GS II. I don't think Kega or Regen have this issue, and the real system obviously doesn't.

If you end up putting code in a swappable area, that's fine. It'll break on older Gens, but it'll give me a test case to fix the SSF2 instruction fetch mapping in Gens/GS II.

(tl;dr version; if you execute code in a ROM bank that's been swapped with another bank, it will break on Gens and most Gens derivatives, but should work on Kega, Regen, and actual hardware.)

[Sik]

GerbilSoft, on 23 September 2011 - 10:32 PM, said:

I will eventually fix this limitation in Gens/GS II. I don't think Kega or Regen have this issue, and the real system obviously doesn't.

Nope, but Regen won't be able to run the hack properly anyways since it only allows 5MB instead of 6MB. In fact, I don't know if it's still hardcoded to Super Street Fighter II (I got AamirM to add support for that S3D hack that used the mapper, but that required a custom build and I don't know if the changes made their way into the current version). If that's the case then the mapper won't work with anything but that ROM, period.

[Mr. Mash]

I can't do the high jump

[ColinC10]

GerbilSoft, on 23 September 2011 - 10:32 PM, said:

The 512 KB code limitation is actually due to an error in Gens, and isn't a limitation in hardware. The problem in this case is that Starscream (Gens' 68000 emulator) has two fetch functions: one for instruction fetch and one for data fetch. The data fetch function is properly managed by Gens' SSF2 mapper, but the instruction fetch function is not. Hence, if you have any banks swapped out, executing code there will act like the bank isn't swapped, which can cause weird issues. (I recommended the first 512 KB because that's guaranteed to not be swapped.)

I will eventually fix this limitation in Gens/GS II. I don't think Kega or Regen have this issue, and the real system obviously doesn't.

If you end up putting code in a swappable area, that's fine. It'll break on older Gens, but it'll give me a test case to fix the SSF2 instruction fetch mapping in Gens/GS II.

(tl;dr version; if you execute code in a ROM bank that's been swapped with another bank, it will break on Gens and most Gens derivatives, but should work on Kega, Regen, and actual hardware.)

Great, thanks for the explanation. Here's a memory map of Sonic VR, taken straight from my notes. As you can see, I didn't manage to fit all the code into the first 512KB (bank 0). However, my "music playing area" is in banks 1-3, so these are the ones that get swapped in and out. The rest of the game code comes after this in bank 4, so I don't think I'll actually hit this issue. Is that right?

;0			0x000000 - 0x07FFFF	Sonic 2 code, Sonic VR sound driver, art & 01_mermaid
;1	0xA130F3:	0x080000 - 0x0FFFFF	01_mermaid
;2	0xA130F5:       0x100000 - 0x17FFFF	01_mermaid
;3	0xA130F7:       0x180000 - 0x1FFFFF	01_mermaid
;4	0xA130F9:       0x200000 - 0x27FFFF	Sonic 1 objects, Sonic VR code, art & 03_mess
;5	0xA130FB:       0x280000 - 0x2FFFFF	03_mess
;6	0xA130FD:       0x300000 - 0x37FFFF	03_mess
;7	0xA130FF:       0x380000 - 0x3FFFFF	00_helix_nebula
;8			0x400000 - 0x47FFFF	00_helix_nebula
;9			0x480000 - 0x4FFFFF	00_helix_nebula & 02_blackout_city
;A			0x500000 - 0x57FFFF	02_blackout_city
;B			0x580000 - 0x5FFFFF	02_blackout_city

By the way, if anybody's considering using bankswitching in their own hack, it's really easy to do (although it doesn't seem to be well documented online for some reason, which is why I'm mentioning it here). The ROM is divided into 512KB banks, so a ROM with the maximum size of 4MB will have banks 0-7. These are represented by the odd numbered 0xA130F# registers you can see above. If I want to get to banks 8-$B (the remaining four banks between 4MB and 6MB), I just move the bank number that I want to access into the register that corresponds to the address range I want to use to access it. For example, to play track 0 - Helix Nebula, I just do this:

		move.b	#7,($A130F3).l
		move.b	#8,($A130F5).l
		move.b	#9,($A130F7).l

And then tell the sound driver to start playing from address 0x080000. Simple!

The register 0xA130F1 doesn't appear on the list above because the first bank can't be switched. However, if you've used SRAM in your hack you'll have seen it before. That's because it's used for a slightly different type of bankswitching - setting a 1 here will cause the address range 0x200000-0x3FFFFF to represent RAM instead of ROM, allowing you to write values here to be saved in SRAM. Set 0xA130F1 back to 0 to have this address range behave as normal again.

[Sik]

ColinC10, on 24 September 2011 - 07:46 AM, said:

By the way, if anybody's considering using bankswitching in their own hack, it's really easy to do (although it doesn't seem to be well documented online for some reason, which is why I'm mentioning it here).

http://emudocs.org/Genesis/ssf2.txt

ColinC10, on 24 September 2011 - 07:46 AM, said:

That's because it's used for a slightly different type of bankswitching - setting a 1 here will cause the address range 0x200000-0x3FFFFF to represent RAM instead of ROM, allowing you to write values here to be saved in SRAM. Set 0xA130F1 back to 0 to have this address range behave as normal again.

Explanation is wrong. Bit #0 sets whether ROM is visible (clear) or RAM (set), bit #1 sets whether RAM is writeable (clear) or not (set).

[TheBarAdmin]

Impressive.

The main concept behind this is original and fun! The way you set up the level gimmicks and play around with the physics is very creative (and I assume these are all from sonic 1 and 2 so far). This could serve as inspiration to make more varied and fun level designs. =)

[ColinC10]

Sik, on 24 September 2011 - 10:45 AM, said:

ColinC10, on 24 September 2011 - 07:46 AM, said:

By the way, if anybody's considering using bankswitching in their own hack, it's really easy to do (although it doesn't seem to be well documented online for some reason, which is why I'm mentioning it here).

http://emudocs.org/Genesis/ssf2.txt

ColinC10, on 24 September 2011 - 07:46 AM, said:

That's because it's used for a slightly different type of bankswitching - setting a 1 here will cause the address range 0x200000-0x3FFFFF to represent RAM instead of ROM, allowing you to write values here to be saved in SRAM. Set 0xA130F1 back to 0 to have this address range behave as normal again.

Explanation is wrong. Bit #0 sets whether ROM is visible (clear) or RAM (set), bit #1 sets whether RAM is writeable (clear) or not (set).

Yes, I did find that file eventually, hence why I've directly copy/pasted some of my notes above from it. And not mentioning the write-protect functionality doesn't make my explanation "wrong", just "simplified"!

[Shade Vortex]

This is actually a pretty novel idea, and it has a good difficulty curve to it. Starts out basic, and gets more complicated pretty much each mission. It's made me actually think about how to accomplish some of them, so it's definitely teaching me to play it in ways I probably never would have thought of playing Sonic games or levels in. I like how the missions basically require extensive knowledge of how to abuse the physics to your advantage, especially stuff like high jump- I didn't even think I'd be able to do something like that, had it not been for this hack.

Great job, I commend you for your efforts. This does get frustrating at the end though, so it's great for those who love a challenge.

[GerbilSoft]

ColinC10, on 24 September 2011 - 07:46 AM, said:

Great, thanks for the explanation. Here's a memory map of Sonic VR, taken straight from my notes. As you can see, I didn't manage to fit all the code into the first 512KB (bank 0). However, my "music playing area" is in banks 1-3, so these are the ones that get swapped in and out. The rest of the game code comes after this in bank 4, so I don't think I'll actually hit this issue. Is that right?

Yeah, it looks like it shouldn't hit the Gens limitation.

[nineko]

Why this hack didn't have a wiki page yet is beyond me.
Sonic VR

[Jaseman]

I love this hack (but the last world is kicking my ASS) but I do have one thing to note: Doesn't boot on Gensoid on Android (my phone is my primary Genesis emulator). I'd imagine this has something to do with the bankswitching, but thought it was notable.

[Sonic 65]

This is some awesome stuff, man. It's probably the best "bite-sized challenge" type game I've played, actually (including commercial titles like Super Meat Boy). I love the use of level gimmicks, how manipulating the physics is integrated into level design, how the game turns things that you would just casually dismiss in a regular Sonic game (like Buzz Bombers) into legitimate threats...it's just really clever overall. The Anamanaguchi music is a cool touch too but Helix Nebula should have been last instead of first. =P

I still can't figure out that god damn High Jump, though. It's that and the last level left.