Two weeks ago, I had the idea of porting some of the Sonic games originally made for the Sega Master System/Game Gear to the TI-84+ CE. This wouldn't be as hard as porting the Sega Genesis games, since the Master System's CPU is the Z80. Right now, the game runs in its entirety without any major problems, meaning the port is pretty much complete!

Source Code: https://github.com/grubbyplaya/Sonic-2-CE (feel free to contribute)

Sounds pretty sweet, now at least one calc the in 83+ line will finally get a full blown Sonic game.

Pretty soon, we are going to have a Switch-84+ CE; if people like you continue to make such great ports!

I'm kind of curious what your porting approach for this will be. Is a lot of the code going to run in 16-bit compatibility mode, or are you going to port the code to 24-bit? If remaining in 16-bit mode, how will banking be handled?

I notice a lot of RAM addresses in the disassembly are hard-coded, though it wouldn't be too difficult to turn those into 16-bit accesses from 24-bit code as needed (since $D0C000 to $D0FFFF with TI's default MBASE lands cleanly in safe RAM). Since ROM-based addresses seem to have actual labels in the disassembly, the code portion seems easier to port to 24-bit, though you'll probably need to expand pointers to code in the ROM from .dw to .dl, as well as update the code that parses those pointers.

Though, if any pointers to ROM are stored in RAM, that might be a little more involved to deal with (you may need to convert them into offsets to avoid shifting all the RAM variables). Potentially pointers stored in ROM could be changed to offsets as well, as long as the code reading the pointers applies the offsets appropriately. In fact, this may be quite necessary for ROM-based data (graphics, levels) which probably need to be stored in separate AppVars in Flash to accommodate the 64KB file size limit and RAM limitations.

Anyway, it seems like a pretty cool project, so good luck!

Running the game at its native resolution of 256x244 would look fine on the calculator, probably better than any scaling would, considering how close the resolutions are.

Looking forward to this port, keep us posted!

Those Sonic games were pretty fun on my Sega Game Gear back then. I'm glad to see one ported to calculators.

I hadn't really thought about the pointers, since a good chunk of the work so far has been spent on converting the disassembly's directives, which are targeted towards a general Z80 assembler, and converting them into ones compatible with SPASM-ng. Once I'm done with that, I'll definitely try to implement it.

Completely missed this earlier--awesome work so far! I also think that the native resolution of 256x224 would be preferable over stretching an image, unless you can find an efficient way of doing that (maybe look at TI-Boy CE for some examples).

Have you been able to make any sort of working product yet, or is the sound code removal and VDP code reworking still ongoing?

Thanks for the support! I'm not planning to stretch the image. Instead, I'm going to update the game's resolution from 256x224 to 320x240. This will probably be done last, since the game can run perfectly fine without it.



I haven't gotten the project to build, but so far, all the sound logic is gone, almost every assembling error that SPASM-ng put out has been fixed, and around a twentieth of the VDP stuff has been ported over. Unfortunately, the Master System uses a 6-bit palette, so every color in the game needs to be reworked to fit in an 8-bit palette. I originally intended to release the complete file on October 16th, exactly 30 years after the SMS original, but at the rate I'm going it'll probably be done by November or December.

I realized I never got around to making a post in this topic, but the project sounds really cool! I'm looking forward to giving it a try when it's done. Best of luck with the project, and I can't wait to hear more about it!

Hey everyone, I've spent the last two months working on and off on Sonic 2 CE, and I've reached a huge milestone two days ago; The code can now be assembled! To celebrate, I'm going to share what I've been doing coding-wise for the past two months.

I split most of the sound code from the game around October 5th and ported it over a couple days later. The GitHub repo for the ported sound driver will probably be made public after Sonic 2 CE is finished.

Around three weeks later, I merged most of 8-bit Sonic 2's 31 banks of data, which are 16 KB in size, into eight appvars to save space. I kept adding data that I glossed over during the next few weeks, culminating in eleven separate appvars that contains around 83% of the original 8-bit Sonic 2's data. The banks that contained game logic instead of data (28-31) were instead merged into the main s2.asm file.

On November 5th, I finally did a thing that I've been putting off and manually converted every 6-bit palette in the game to an "8-bit" one. Unfortunately, the 8-bit palette with hex values that I used for reference was actually for a VGA monitor, which is mainly just a 6-bit palette with darker shades of every color. I probably need help with this one.

From then until two days ago, I mainly just worked on getting rid of every assembling error still left over, allowing the game to assemble into a 91 KB .8xp file. Since I finished that, I'm going to take a break from this project until I feel ready to redirect all the art, layout, mappings, and palette routines to the appvars and get the main engine to fit within 64 KB.

I remember playing Sonic 2 on Game Gear, that was really fun to play especially on trips. I'm glad to see that this port exists so I can play it once again. I have a few questions though. If this can now be assembled, can we download or play the games? It sounds stupid but I'm still not sure about it. Also, could we (theoretically) follow this process for other Game Gear games? Some that come to mind are the Sonic 1 for game gear, Triple Trouble, and others? This project is interesting since there hasn't been a very good Sonic game for the TI84+CE or even a port for it. Thank you for your hard work!

Even though it can be assembled, there's still the problem of porting the VDP code. Testing it out on a calc will absolutely crash it.


I've made a SMS palette converter in Scratch to help me with porting the game. It'll theoretically work with every SMS game (not just Sonic), and it's included in the source code of the port if you wanna check it out. Since Sonic 2, Sonic Chaos and Sonic Triple Trouble share a similar codebase, it's entirely possible to take the ported code from Sonic 2 CE and put it in the other two games. I'm not so sure about Sonic 1, though. Thanks for asking!

I have question. Could there be potential for a SMS emulator on the 84+CE or 83PCE? Sorry if I may sound stupid, I am not familiar with pretty advanced programing.

I'd say yes something would be possible. Id looked into it a while ago but in some instances individual ports may be a better option.

Long time no see! It's been a few months, most of which I was doing absolutely nothing, but there's been two massive breakthroughs recently that I think are worth updating the thread over.

Palette and Tile/Sprite emulation is 100% complete!




One of the main reasons it took so long to get palettes working is because I misread the LCD controller documentation and believed that the xlibc palette was the official one. I only realised my mistake after I already manually converted every palette in the game to the xlibc one, mockups and all.

Now, all that's left to complete the VDP emulator is tilemap scrolling, and I'm not looking forward to that at all, mainly because the fastest way to implement it that I know of is by rendering the tilemap beforehand, taking up 48 KB of precious RAM, and copying it to the screen in chunks of whatever the horizontal scroll value is.

I'll update this thread again when that's complete. Until then, see you guys later!

Great work on the updates; thanks for coming back instead of permanently ghosting! I look forward to the next update on getting the tilemap scrolling.

Nice work, was not expecting another update on this!

48K of RAM seems like a pretty reasonable requirement to me if that's going to make a big different for speed--there's plenty of special areas that you can use to get that amount, as I'm sure you're well aware.

I know I said I'd update the thread when I get the tilemap to render, but there was a recent breakthrough that definitely shouldn't be glossed over:



The full intro and title screen runs! (sans background)

The main reason why it took me two months to get to this point is because I spent a while manually modifying the entire engine to work in ADL mode, only to have to manually undo it when I realized that the game would have to be completely overhauled to not need interrupts.

After I switched back to Z80 mode, which allowed me to replicate the SMS memory map, everything went surprisingly smoothly. All I really had to do was fix any bugs caused by the initial switch to ADL mode, like the game assuming that ROM banks were being stored in the start of safeRAM.

Once I made sure that everything was being loaded into VDP RAM correctly, I enabled the VDP emulator. Sprite rendering worked almost perfectly (I only had to add support for 8x16 sprites), but tilemap rendering was so ridiculously broken that I disabled it when I recorded the aPNG.

Thanks to everyone that's helped me get so far with this project. It wouldn't me possible without you!

Incredible. I cannot see the screenshot, but I imagine it is fantastic. Excellent work, keep it up!