Still polishing the documentation and drafting a release thread, but for the moment, enjoy a little preview of a potentially game-changing development tool. (Almost befitting that this comes just days after Devon's Sonic 1 Mode 1 experiments.)
A while back I made this little hack on smspower View topic - Sonic The Hedgehog SMS Remix (beta version) - Forums - SMS Power! It's main purpose was to basically advertise the fact that Maxim's massively enhanced version of WV's Sonic 1 SMS editor 'STH1EDWV' was an amazing tool and people should try it. As it happened, Slogra's astonishing Sonic Genesis for Master System did a much better job at that, and I quickly forgot about it. I also never released the mini hack here, so without further ado I present: Sonic 1 SMS Remix It's based on the idea that we've all played the game to death, so I tried to make something which encouraged a bit of exploring -all extra lives moved to new locations (including small layout changes to accommodate them) -all chaos emeralds moved to new locations (including small layout changes to accommodate them) -all maps allow backtracking, if you reach the end of a level, it should always be possible to get back to the start if you look around a bit. -and new for this version, that includes disabling the scrolling in Bridge 1 and screen locking/instant death in Jungle 2. It isn't polished, the difficulty is all over the place, it's very lightly tested and it's not winning any awards :-) but it is a functional* hack for Sonic 1 SMS, and I think that's pretty cool. Screenshots are a bit tricky as they'd reveal something hidden and nothing has changed except the hidden stuff. I'll think about it. *subject to testing...
My attempt to improve SMPS-PCM's sample streaming routine using movep unfortunately did not work due to hardware limitations (movep simply copies the data too fast for hardware to handle), but it did produce a usable 68k routine for copying data to an 8-bit peripheral using movep (confirmed as this code worked in GPGX due to that emulator not emulating the waveram behavior correctly): Code (ASM): ; ------------------------------------------------------------------------- ; Subroutine to copy data to an 8-bit peripheral using movep ; Can handle data of any size, and starting at any address ; input: ; a0 = source ; a1 = destination ; d0.w = size of data ; uses d1.l, d4.l, d5.w ; ------------------------------------------------------------------------- CopyTo8Bit: move.l a0,d1 btst #0,d1 ; is start address of data odd? beq.s .even ; branch if not move.b (a0)+,(a1)+ ; copy first byte manually if starting at odd address addq.w #1,a1 ; skip over non-write address subq.w #1,d0 ; minus 1 for 1 byte copied .even: move.w d0,d5 ; if data is not divisible by 8, there will be a remainder of up to 7 bytes lsr.w #3,d0 ; d0 = loops to copy data with 8 bytes per iteration (excluding any remainder) beq.s .less_than_8 ; branch if there are less than 8 bytes total subq.w #1,d0 ; minus 1 for loop counter .copy: move.l (a0)+,d4 ; get 4 bytes of data movep.l d4,0(a1) ; write to destination move.l (a0)+,d4 ; get another 4 bytes movep.l d4,4*2(a1) ; write to destination lea 8*2(a1),a1 ; advance destination address dbf d0,.copy ; repeat for all longwords of data .less_than_8: andi.w #7,d5 ; d5 = remainder if data size was not divisible by 8 beq.s .no_remainder ; branch if there is no remainder cmpi.b #4,d5 bcs.s .less_than_4 ; branch if remainder is less than 4 bytes move.l (a0)+,d4 ; get 4 bytes of data movep.l d4,0(a1) ; copy to destination addq.w #8,a1 ; advance destination address subq.w #4,d5 ; minus 4 bytes from remainder beq.s .no_remainder ; branch if remainder was exactly 4 .less_than_4: subq.w #1,d5 ; minus 1 for loop counter .copy_remainder: move.b (a0)+,(a1)+ ; copy one byte of data addq.w #1,a1 ; skip over non-write addresses dbf d5,.copy_remainder ; loop until remainder is gone .no_remainder: rts
Unfortunately I have no means to test this code, but this was nevertheless an insightful look into the finer details of of the 68k family. It's well-documented that S3K is wholly incompatible with 68010-modded Mega Drives due to KosM's exception stack frame trickery (specifically, pushing a return address and status register to the stack and executing an rte, which has disastrous results on the 68010 since its stack frame has at minimum an additional 4 bytes below the return address). I'd always wondered if it would be possible to modify the game to allow it work on 68010-modded systems without breaking compatibility with ordinary Mega Drives, and a post I saw on an Amiga forum suggested a solution. Code (ASM): ; --------------------------------------------------------------------------- ; Called by game initialization. ; --------------------------------------------------------------------------- Check68010: move.b #'T',(f_68010).w ; let error handler know we are testing for a 68010 moveq #0,d0 movea.l d0,a0 movec.l a0,vbr ; clear vector base register on 68010; trigger illegal instruction exception on 68000 nop ; if on a 68000, error handler will clear f_68010 and return cmpi.b #'T',(f_68010).w ; are we in fact on a 68010? seq.b (f_68010).w ; if so, set all bits (required so error handler works correctly) rts ; =========================================================================== IllegalInstruction: cmpi.b #'T',(f_68010).w ; was this exception triggered by the 68010 test? bne.s .error ; branch if not clr.b (f_68010).w ; we are on a 68000, clear flag rte ; continue with initialization .error: ; fall through to error trap or handler code ; --------------------------------------------------------------------------- ; To prevent this from crashing on 68010s, push an empty longword to the stack ; below the return address. This is the vector offset/format longword: the ; highest nybble signifies the format of the frame (that is, how many words it ; has excluding the status register), while the rest contains the 24-bit ; vector address formed by taking the address in the vector table entry and ; adding the contents of the vector base register. ; The frame used by interrupts on the 68010 is four words, signified by the ; format nybble = 0, and the vector offset is, as far I can tell, not used for ; anything on rte, so we should be able to get away with simply pushing an ; empty longword to the stack rather than backing up an additional longword ; with the PC and status register. ; --------------------------------------------------------------------------- Restore_Kos_Bookmark: movem.w (v_kosm_stored_dregs).w,d0-d6 ; restore data registers movem.l (v_kosm_stored_aregs).w,a0-a1/a5 ; restore address registers .chk68010: tst.w (f_68010).w ; are we running on a 68010 modded console? beq.s .not_68010 ; branch if not clr.l -(sp) ; push dummy vector offset/format longword to stack so rte behaves correctly on 68010 .not_68010: move.l (v_kosm_bookmark).w,-(sp) ; restore return address move.w (v_kosm_stored_sr).w,-(sp) ; restore sr rte
The 68010 was the 68000’s immediate successor in the 68k family. It was nowhere near as popular as 68000, as its main improvements (e.g., virtual memory support) were targeted towards high-end professional and enterprises applications. It didn’t see much use outside of some mid 1980s UNIX workstations, several Atari arcade boards, and a third-party AppleShare server. That said, it’s pin-compatible with the 68000, so it is possible to install a 68010 in a Genesis or in any other hardware that uses a plain 68000 (same modification has also been done to Atari STs and Amigas, and there’s even an adapter available that allows using 68-pin PLCC chips in hardware that uses the 64-pin DIP configuration). The main reason is the small performance boost it provides: small dbcc loops of two instructions are loaded into and executed from the prefetch cache, skipping the task of fetching the opcodes each time, mulu/s and divu/s execute faster, and the clr and scc instructions are faster (they are now pure write instructions rather than read/modify/write). It’s not 100 percent software compatible, however, due to changes in the exception stack frame and the move to SR instruction being changed to a privileged instruction. (EDIT: fixed the pin counts.) (EDIT: added a little more information about the 68010's speed improvements.)
To go into a little more detail, the MOVE to SR instruction was made privileged due to a potential circumvention of virtual memory protections. Motorola advertised the 68010 as being designed for virtual memory usage as a result. But aside from that, there was an overall improvement to processing speed, 10-14% faster at the same clock speed. This is why a lot of people swapped 68010s into their 68000 machines; who didn't want a faster Amiga? But because of the MOVE to SR change, software was prone to breakage; those same Amiga owners found that the calculator application would now cause Guru Meditations! I have a few 68010s on hand myself and I would love to try the mod out and see what kind of a difference it would make in games. Potentially it could eliminate some slowdown! But to do that I need a system that uses the 68000 in DIP packaging, and the only one I have is a system I'd rather not modify like that...
Amusingly enough, the Macintosh's Calculator desk accessory apparently also crashed when upgraded with 68010s. And it wasn't just virtual memory protections: privileging MOVE from SR allowed the 68k architecture to meet the Popek and Goldberg virtualization requirements (noteworthy since it took another 21 years for x86 to do the same).
Finally got my first hack out. It's a simple winter palette swap, but it's a start. Thank you Clownacy for giving me pointers throughout, you're a real hero!
A very quick port of Green Hill Zone Act 1 to Sonic CD; objects do not work at all, as does the background, and some tiles and collisions are buggy, but it should work, even on hardware. And before you ask, the FMV audio was taken from a Countryballs video (because space). EDIT: Uploading a link to the source code here, as I am currently unable to do much further work; some further changes were made, but it's pretty buggy and full of engine tests (read: introduction is the Rockman X3 PS1 opening).
A lovely YouTube user, under a video related to Sonic 2 - Score Rush, was wondering if there was a way to play Sonic 2 with just the moveset changes. Indeed, such a way was there. ...or so I thought, because turns out I didn't finish porting over some things from Sonic 2 - Score Rush to Vanilla Sonic 2. So I did exactly that! The attached ROM hack is a straight build of Sonic 2 with Knuckles, the very disassembly that was used in the creation of Sonic 2 - Score Rush. This build offers you the default moveset options from Sonic 2 - Score Rush. There's no way to change those in game, as I could not be bothered to implement an options screen specifically for this mini hack. For 2 player versus, only options that would normally affect all characters are made available, so Sonic and Tails do not get air moves. The moveset is as follows: No air speed cap; No rolling jump lock, meaning you keep control if you jump after rolling; Slow ducking from Sonic & Knuckles is in place; Sonic gets the Super Peel-Out, the Drop Dash, and the Insta-Shield in 1P mode; Tails gets the Flight in 1P mode; Tails gets flight cancel in 1P mode. Only a human can cancel Tails' flight, and it can not be cancelled while holding Sonic; Bullet deflection from Sonic 3 is in place Additional features not normally accessible in Sonic 2 - Score Rush include: Tails Assist, from the 2013 version of Sonic 1; Virtual controller swap: if both players press A while the game is paused, they will swap controllers virtually. Useful for netplay users! Modified Super Transformation method: to transform, you'll have to press a different jump button from the one you used to jump. Same as Sonic 3 Complete's method! Player-dependent pausing: If player 1 pauses, only player 1 can unpause. Same goes for Player 2. Credits Giovanni: Knuckles in Special Stages and Ending port, additional bugfixes. Heyjoeway: Code and assets from Sonic 2 Community's Cut DeltaWooloo: Scrapped programming work redhotsonic, MoDule, Esrael Neto, MainMemory, flamewing, Selbi, Puto, Clownacy: Guides
I'm currently working on a video that required a sandbox environment for measuring Sonic's speed. So I made exactly that; Kilo's Speed Sandbox. Features - HUD that displays current X velocity in pixels per frame (PPF), and tracks the highest speed reached in the session. - 2 levels for testing the player's speed. A flat level with a speed shoe monitor and red and yellow springs. And a level with a massive drop with a slope to convert vertical speed into horizontal speed. - Speed shoes monitor acts as a toggle rather than a timer, turning into a slow down monitor upon breaking. - You can transform into Super Sonic at any moment with the Sonic 3 input of a double jump, with the ability to revert. - You can exit out to the title screen by pausing and pressing A without inputting the level select cheat. - You can fill the levels with water via the options menu. I'm simultaneously proud of this as my first Sonic 2 hack, and also extremely ashamed of how bad some of the solutions I came up with to get this to work, but it's only a prop for a video so clean and optimized code wasn't my focus.
A small milestone from my effort to make a Mode 1 version of Sonic CD, even if it's a feature that won't be used in the long run. This test ROM checks the drive for a copy of Sonic CD or CD++, and if found, loads the disc's filesystem, then loads TTZ's PCM driver and plays its music. This was mainly intended to verify some code changes and optimizations to the game's file engine, but it's also a good demonstration of how Mode 1 can be used to load and execute additional program code from disc. That it allows a chance to show off my initialization code and the system I devised to allow for compressed sub CPU code is a bonus. :P The ROM is attached below. To run in Blastem, place the ROM in a directory with cue sheet and ISO + audio files for a copy of Sonic CD or CD++ of any region, launch the ROM in Blastem, and use the "Lock On" option in the in-game menu to select the cue sheet. To run in Genesis Plus GX, do the same as Blastem with cue sheet & ISO + audio files, rename the ROM file to match the name of the cue sheet, and run. To run on real hardware, place a copy of Sonic CD or CD++ of any region in the drive before launching the ROM. ROM will display messages if sub CPU initialization fails, a red screen if no disc is found or if disc is an audio CD with fewer than 35 tracks, and a blue screen if an audio CD with more than 35 tracks is found. Source code for the ROM can be downloaded here. A thank you to Devon for helping me find an oversight in the sub CPU program decompression, and to MaskOfDestiny for demystifying the BIOS' TOC read status byte.
I made a stupid little shitpost hack for April Fools Day. Spoiler: Crosspost hi guys did u know that sonic 1 is actually kinda slow? theres lag and it doesnt actually feel like ur actually going faster than da speed of sound. I FIXED THAT BITCH! introducing... what i did 2 make it actually fast is increased sonics speed to be INSTANT FAST, uncapped the frame rate (fuck u vsync!!!!), and removed USELESS shit like background scrolling, water coloring, palette cycling, and stage tile animations. i also simplified the camera system so sonic is always at the center of the screen (why would we wanna take focus away from him???) and now da game is fast and good AND SIMPLE. HAVE FUN OR I WILL FUCKING CRY MYSELF TO SLEEP LIKE A BADASS. DOWNLOAD
Tch, not optimized enuff. Cliffs and dropped rings still cause lag. And those level load times are a joke, you gotta ditch the PLC system and make all the art uncompressed and DMA it all at once, John Sega didn't gift us blast processing for you to not use it. I will be expecting an update before midnight or I will be calling the ROM hacking police.
Honestly, I'd love to see a version of this without any of the physics changes, if possible. Like pure stock Sonic 1 with the frame rate uncapped (which would probably also mean no water color or background scrolling but WHO CARES ABOUT THAT!!! We don't need background scrolling when the game is running at 200FPS!!! (VERY optimized))
I "ported" the ancient 2005 Sonic 1 disasm to ASMX about a year ago. Was using it for some now-cancelled projects. It's functionally identical to the standard ASM68K version but ASMX is missing a few directives so I'd proceed with caution if you want to use this. https://github.com/KurkG4/S1-Hivebrain-2005-ASMX EDIT 07/16/24: Re-uploaded onto Github, apologies for the dead link.
you can thank Discord for that, btw a quick tip is to avoid using Discord as a file hosting place @Kurk, use something else like Google Drive or a different file hosting site.
