Soulstar – Under The Hood – Part 1

Since there is some interested, I decided to write some blog posts about one of my old games a Mega-CD game named Soulstar.

For anyone who doesn’t know about the Mega-CD, it was a CD add-on to Sega’s Megadrive which also added some new hardware. First, it added more RAM and another 68000 (Sub) CPU, one clocked at 12.5Mhz. It also added a scaling and rotation chip, one I do believe was derived from Sega’s arcade hardware. Another sound chip was added too, but my attention was drawn to the new graphics chip. The Sub CPU had an additional 512K of RAM, while the new graphics chip had 256K of Word RAM (WRAM), usable in one of two modes: 1M mode split the WRAM into two banks of 128K, one accessible by the Main CPU while the Sub CPU accessed the other bank. 2M mode gave either the Main CPU or the Sub CPU full access to the WRAM, and was the mode used by the new graphics chip.

Before Soulstar, the other games I’d coded for the Mega-CD were Jaguar XJ220 and Thunderhawk (Thunderstrike in the US). Jaguar XJ220 was my first game for the Mega-CD, a version of the Amiga game (also coded by me). Being new to the Mega-CD, I ran some tests of the new hardware and discovered I could render scaled sprites faster in software than in hardware! I used a special memory  mapping mode where bytes could be written to a 256K memory range that corresponded to a 128K nybble version. Quite handy, as CPUs generally don’t like messing about with nybbles when storing bytes is so much easier, simpler, thus faster! So Jaguar XJ220 was coded, and I think it turned out pretty good! I could build an image of the screen using the WRAM on the Mega-CD side, then flip the WRAM over to the Megadrive side so the image could be DMA’ed into VRAM.

Jaguar XJ220 – All sprites are software rendered.

It was only afterwards I discovered there was a mistake in my timings, one meaning the hardware was actually faster than my software routines… Oh well, live and learn…

As for Thunderhawk, my first thought was to make the game a port of the Amiga version, so rendering everything as polygons. I already had a Megadrive port of Thunderhawk, (one put on hold so I could code the Mega-CD jaguar XJ220). Problem with the scaling/rotation chip was it could only render 3D in one direction, making it impossible to render a floor and “bank” it.

But then I had an idea, a rather crazy, wacky (perhaps even brilliant) idea. If I overdrew the screen vertically, then when copying the screen from WRAM to the Megadrive side, if I copied the screen as vertical strips, I could offset each strip vertically, thus shearing the whole screen! Okay, so not quite a full screen rotation, but good enough for a game! (This is the reason Mega-CD Thunderhawk doesn’t bank very much).

No sprite rotation here, just vertical/horizontal shearing!

Since the whole screen was basically a bitmap, the whole thing had to use one palette of 16 colours, the sky being on a separate playfield. I didn’t actually rotate any sprites for Thunderhawk; with the whole screen being sheared vertically, to simulate sprite rotation all I had to do was shear all the sprites horizontally. Worked out pretty good, and fooled a lot of people!

So that was Thunderhawk, my first proper use of the new hardware.

One of my favourite games was the arcade game Galaxy Force II. I can remember the first time I was that and was wowed by how the background scales throughout the first level, to the point you end up flying into a tunnel entrance! I always wanted to code a game like that, but there didn’t exist any hardware outside an arcade that could replicate anything like that.

Until the Mega-CD came along.

Once Thunderhawk was complete, I so wanted to code a space game like GF-II. Along with my Italian artist friend, we set about designing such a game. The result was Soulstar.

For the new game, I had to push things as far as possible. Thunderhawk used a bitmapped screen of 16 colours, with a 16 colour background. But for Soulstar I wanted to use all the Megadrive’s palettes. The Megadrive had 4 palettes of 16 colours. Sprites and characters could use any of the 4 palettes, so I decided early on the only way to get more colours on screen was to use hardware sprites.

The Mega-CD’s graphics chip worked by rendering a rectangular block arranged in the same pattern as hardware sprites. The destination rectangle was rendered one line at a time, each line given a start position and delta to trace across a source image. The source image was a map made of blocks (which were described in the manual as “stamps”). Stamps could be either 16×16 or 32×32 pixels, and were indexed by an area of WRAM known as a “stamp map”. The stamp maps could be either 16×16 (with 16×16 stamps) or 8×8 (using 32×32 stamps). Whatever, the pixel size of the map was 256×256 pixels.

Sprites in the game were built from the stamp maps and rendered into WRAM to form hardware sprites for the Megadrive to display. A hardware display list was also built, up to a maximum of 80 sprites, the Megadrive’s display limit. The game did suffer from sprite dropout at times when the screen became busy, either by exceeding the limit on sprites per line, or the maximum limit. Since hardware sprites were allocated front to back, only sprites in the distance were lost first.

One trick I did use was to do deal with sprite popping. I built several depth-fade tables, each table blending bit-by-bit into a single colour; for space this was black, but for some planets (like the surface of Guha), this was the surface colour. This meant I could fade the sprites into existence. Now, I couldn’t use the hardware to do this, so instead I first rendered the sprites into WRAM, then used the CPU to modify the data afterwards. Since I usually only applied this to distant sprites (typically the last 8×8 sprite), it didn’t take much CPU time to do this.

I think the end result was quite pleasing:

Showing the software depth-fading of hardware sprite data.

I used the same trick on the landscape, as you can see in the above image. Again, the ground was rendered into WRAM using the hardware, then the CPU modified the top few lines of the data to fade the ground into the distance. As you can see, I used different tables for different sprites; the ground objects blend into a sandy colour, while the sprites in the sky are blending into a much darker colour, one that blends with the sky.

Here’s another example, inside the Warpship:

Warpship interior – note the floor fading into the distance.

You can clearly see the background fading into the distance.

Before I go any further, thought I’d mention another aspect of the game. On the linear sections, the game was synced to the music. As the music played, I could read the current time code, thus keep the scrolling in sync. It wasn’t precise, but it didn’t need to be; if the game lagged behind, the ground scrolling would speed up to catch up, then slow down once it had caught up. We designed all the linear levels to be in sync with the music. to do this, we first worked out all the attack patterns in terms of time, then gave Nathan McCree (our brilliant musician) all the times so he could work his magic. I have to say, the music to Soulstar is awesome. I still listen to it from time to time.

Where possible, I used standard Megadrive playfields to do the background, purely to reduce the amount of data that had to be DMA’ed to VRAM. There’s a finite amount of bandwidth on the DMA, so the method I used was to render the data on the Sub-side, flip the WRAM from Sub-side to Main-side, copy the necessary data into the Megadrive’s scratch RAM, then flip the ram back to the Sub-side so it could render the next frame. While the next frame was being rendered on the Sub-side, I could DMA transfer the data from Scratch RAM to the Megadrive’s VRAM over several video frames. VRAM use was double-buffered to prevent glitching.

I used several tricks to minimise the data, so I’ll detail these in the next part, going over each level and explaining all the tricks used.


19 thoughts on “Soulstar – Under The Hood – Part 1

  1. So I remembered wanting to play SoulStar, and just recently seeing some of the gameplay videos. I am blown away, and by your explanation of the software magic going behind background “scaling” Awed to find out that this is not a mode-7 scaling, but rather, a very impressive low level bitmap pixel processing. I think this goes beyond Galaxy Force II, which was, although impressive in its own ways.. but was reliant a lot more on hardware to scale tons of forward facing individual sprites.

    You’re amazing! I can’t wait for the follow up to this article!

    Liked by 1 person

  2. This is some really clever stuff. In my opinion, Soulstar is the most impressive mega CD game by far! It sometimes looks closer to psx games than to mega drive games.
    I would love to read part 2 of this, I hope you continue this blog 🙂

    Liked by 2 people

  3. Wow ! I always wanted to understand how Soul Star was developed as it definitely seems to push the Sega-CD very far. It’s so smooth and sometime have full screen scaling (thinking about the level in space with the giant ship). Nice to learn about the fade / fog trick, a lot of game used similar trick later to limit 3D depth view and it’s just incredible to think you were able to do that in software and with the limited amount of color available on Megadrive. I would love to heard more about how you made to keep smooth frame rate (it looks like it’s running at 20 FPS) updating that large portion of screen (i guess you’re updating different part of the screen on different frames maybe).
    Anyway, congrats for your awesome work and thanks again for sharing that !

    Liked by 2 people

  4. Thank you for posting this article. I love to see part 2 as well. 😀

    If you don’t mind me asking, for Thunderhawk were you using the vertical column offset feature of the Megadrive VDP?


  5. Hey I really enjoyed your article,my main reason for posting is I really want Soul star for the Atari Jaguar CD,there is a version with the first few kevels but it crashes at the 3rd phase,I hear people have found ways past that though..there’s a guy who is supposed to be debugging and finishing the game,would you be interested in finishing and completing the game for Jaguar CD,I would help with financial backing and maybe we can produce a version for all interested jag CD players,any thought on the matter would be greatly appreciated,T
    hank you,Frank B


  6. Its EPIC to me to know how the BEST 16 bit Shmup was made. SOUL STAR has everything that I wanna see in my beloved SEGA CD. You r my hero ! Thx for this…I still play that game, I still have the original CD. So, you ve done all the good stuff that was maded to this great add on… Jaguar (u ve put even a back light…) is such a great racing game… also, thunderstrike … ( the saturn engine was based in the sega cd engine ?) well… Hope when u finish your c64 project…you find time to make something to the SEGA CD lol…. i could cry for that…

    Liked by 1 person

    1. Hi! Actually, the Saturn version of Thunderstrike used a brand new engine I created. And after the release of the game, I did have an improved version that used the 3D hardware playfield for most of the ground, but it was never used as I had moved on to Fighting Force by then.

      Liked by 1 person

      1. Sega Saturn … Sega sometimes have no view… Fighting Force…its very good to know that this was done to be a SS game… it would be so nice to see STREETS of RAGE thery … this game was very good stuff ! SS was hard stuff to progran ? PSX was by far easier, don t ?

        Thx for the reply !

        Waiting to ah remasterd version of Soul Star in Steam : )


  7. Part 2 of this very good video game history will be done ?

    You was involved in the other Core games for Sega CD such as BC Racers and Battlecorps ?


      1. Ops…. blind man I was ! Since 2019 : S.
        I will take a look !
        … a doom type of game could be done with no trouble just with your engines !

        So…your work was there (battlecorps and BC Racers).

        Thx ! Let me see the part 2 now !
        You are a writer don t u ? I like to make narrations of books… I ve done two but they are in portuguese as I am from Brazil. I m planing to make one of the books I ve make that narrative, in a translation to english, if I do it i will link it to you give me a feedback to my narration, lol…of course…a not so good english, but I will give it a try… its a good way to improve my english skills! Lets moveeeee! Thx again for the responses!


  8. Ops…. blind man I was ! Since 2019 : S.
    I will take a look !
    … a doom type of game could be done with no trouble just with your engines !

    So…your work was there (battlecorps and BC Racers engines).

    I don t know nothing about programming… just love to play, Its good to have this contact with u artists !

    Thx ! Let me see the part 2 now ! Lets moveeeee! Thx again for the feedback!


  9. Soul Star is one of my go-to games to bring up whenever anyone claims the Sega CD didn’t add much to the Genesis. Sure, lots of games barely scratched it, but there are some gems that show off what it was capable of! This was a very enjoyable read.

    “It was only afterwards I discovered there was a mistake in my timings, one meaning the hardware was actually faster than my software routines… Oh well, live and learn…”

    You weren’t alone! Sonic CD’s ASIC code ran slow as dirt, but since it was only used (IIRC) for the “3D” bonus levels, they just pushed it out the door. Shame there wasn’t a Sonic CD 2. When harnessed well the new chip was quite powerful for its day, Soul Star, Batman, Silpheed, etc all made good use of it (although some of the fancier Silpheed levels did struggle).

    “Actually, I didn’t have any problems programming the Saturn. Was a fun machine to program.” That speaks volumes to your skill level. That’s something I can only recall hearing from you and Jon Burton off the top of my head. If you ever put together a new Sega CD or Saturn title, I’d totally back an Indiegogo or KS. I love new games for retro Sega systems! *glances over at Tanglewood and Xeno Crisis*.


  10. Probably too late by now, but I thought you’d be interested. The extra chip does what the original VDP design was meant to do, and it was meant to be directly connected (same principle as the Sega Saturn). The hardware scaler got released with the MegaCD, and the extended color support got released with the System C/2 boards.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s