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 isn't as hard as porting the Sega Genesis games, since the Master System's CPU is the Z80. Right now, around 99% of the game's logic has been ported over, and only converting the VDP instructions into TI-OS ones has to be done before I consider this project to be complete.

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

Mockups:
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. Smile
calc84maniac wrote:
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!


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?
epsilon5 wrote:
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)


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.

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


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! Very Happy
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
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 vote in polls in this forum

 

Advertisement