I suggested to Kale that after Cool Riders we should take a look at another long-term non-working game, Gunpey.

The reason it hadn’t been emulated was because everybody was rather scared of the AXELL AG-1 blitter chip, boasting some useful features including graphic compression. Beyond that the game code is ugly, and difficult to follow, the interrupt system was less than clear, and previous attempts at writing the driver had resulted in something where the game code appeared to be running super-slow, the blitter copy was meaningless, and it wasn’t sending anything that resembled useful game data to the video device. Basically, if you ran it in MAME over the last couple of years you’ll have seen something like this at best. This is the result of the ‘blitter’ emulation copying some data from the roms to the screen, it’s clearly nonsense.

(Gunpey in MAME as it was 2 days ago)

Tasked with this Kale set about improving the interrupt emulation, and removing the hacks needed to run the game, while doing this he noticed something else, while the game was said to use a blitter there was actually also a spritelist in RAM, and tracing around the code showed that ASCII text from the game rom was being written here as sprites. With this in mind he changed the renderer to draw solid blocks for these and instead we ended up with something like this.

(Gunpey after Kale identified a sprite list, with solid block drawing)

Clearly a menu, the test menu. This required a little more work from him in fixing up some broken inputs and the like, but it soon became possible to navigate the test menu. I decided to help a bit at this point and hook up the same fake ASCII rom we used for Cool Riders up to the emulation, although in this case it wasn’t quite as straightforward because the ’tile numbers’ in RAM were actually co-ordinates, so to render them with the fake ASCII rom we had to convert each set of co-ordinates to a character number. I did a few, Kale filled in the rest and we ended up with this.


(Gunpey with a fake ASCII rom hooked up)

Doing this presented various useful test menus, making it clear that the OKI sound write had been hooked up to the wrong byte (I fixed that) and that the sound banking was wrong / missing entirely (Kale fixed that)

Now, keep in mind that the graphic rom is a 2048×2048 page of ‘textures’ (a very uncommon setup for a 2D game) you might ask why we didn’t just use the co-ordinates directly to index that page and draw the real text. The reason is it’s not really that simple, the co-ordinates were not references into that texture page, I did try. That’s actually where the ‘blitter’ comes in. It’s not so much a blitter to show things on the screen, but a device to copy graphics from the 2048×2408 page of graphic ROM to another 2048×2048 page of RAM, which is what we’d been trying to display in years before, not realizing it’s real purpose. The existing hookup was wrong anyway, putting the data in the wrong places, so I hacked up a quick viewer for that RAM, and improved the copy operations somewhat. This left us with a page of data in RAM where there clearly seemed to be a font at one location, as shown here.

(abusing the MAME tile viewer with 2048 wide tiles to identify where a font gets copied to RAM)

Yes, that’s tiny, but remember that’s a view of an entire 2048 wide texture page in RAM, and I could just about make out some character like symbols over there, you need a keen eye for these things sometimes…

I then attempted to replace the fake ASCII font with the one from this data, leaving us with this…

(Gunpey, first attempt at using the font copied from ROM to RAM)

Clearly not quite right, but at the same time it clearly IS a font as expected. Kale did some checks, and it appeared even my new copy operation was buggy, every texture was being copied at half-width, to the wrong places (I’d initially made the RAM texture page 1024×2048 based on the values used by the blitter) This meant that while we were indexing roughly the right place for the real font it couldn’t be right until that was fixed, so after a bit of head scratching I fixed it, so we ended up with some more readable text using the real fonts.

(Gunpey with the original font hooked up properly)

Booting the game at this point resulted in something actually resembling a game, but with many corrupt graphics. This was because our indexing was still incorrect for anything not on the first few lines of the RAM page. This did allow for some more fixes tho, the Demo Play text for example showed that the hookup for X/Y size sprite size Kale had done was swapped around (unsurprising because he only had 8×8 sprites to work with before) That made a good reference point for a fix.

(Gunpey, preliminary ingame shot, showing Demo Play text used as a reference for another bug fix)

After a bit of work I was able to improve this, and get the game booting with somewhat correct graphics.

(Gunpey with more of the source offsets fixed)

Meanwhile Kale was fixing the palettes. The palettes are stored in the ROM with the graphics, and copied to the RAM page in the same way as everything else. In addition to this Kale added support for transparent pen, and decoding of the 8bpp graphics. (The chip supports 4bpp, 6bpp, 8bpp and RGB555, but the game only seems to use 4bpp and 8bpp, although the test mode has tests for the others) He also fixed sprite X/Y positioning and a few other problems.

(Gunpey part way through Kale fixing some graphical issues)

At this point the game booted and you could easily identify what was going on, but was still it had significant, and hung if left in attract mode. Also inputs weren’t working on the I/O test screen nor properly on the character select screen. Kale figured out this was an interrupt problem, fixed that, and also identified the end of sprite list marker, and fixed that, getting rid of most bad graphics. We also found things to work better without an ‘invert bank select’ hack that had been added earlier for the spritelist, so that was removed.

I then spent an hour or two debugging some of the remaining graphic problems, figuring out, getting rid of some issues where graphics were incorrectly offset (because we weren’t using enough lower bits to index the RAM bitmap when drawing sprites) and identifying which bits were source sizes, and which ones were zoomed sizes.

That leaves us where we are now. The majority of remaining glitches can be attributed to a handful of things. The major one is the graphic compression, it’s used for most backgrounds and a number of other elements, there doesn’t seem to be an obvious bit to enable decompression when the sprites are drawn, so it might happen during the blits. Beyond that there are still transparency / alpha issues, and the zooming hasn’t been hooked up. Anyway, this is what it looks like *now*

(Gunpey as things stand now, still missing the graphic decompression, but otherwise looking good)

Not bad for a days work on a driver that has been sitting idle in the source for years where every previous attempt at making progress quickly hit a brick wall. I think it’s fair to say that Kale did most of the important work with this one, especially in getting past that initial brick wall and identifying some vital points about the hardware, but like Cool Riders team work was involved in getting us this far. The compression looks interesting, the compressed data for the BanPresto logo case shows that it might not be especially efficient, the white fill still needs a significant number of bytes to represent it, but we’ll see.

The actual game is most similar to the PSX version that became playable in UME/MESS recently, I don’t know if the background data there will be helpful / needed to decompress this, but still it’s something you might find interesting. Obviously the hardware here is VERY different, and strange for a (c)2000 release, an original V30 CPU being used at that point definitely wasn’t common.

Why, yes, it does

(4 different places blending is used for effect)

I’ve done an initial implementation of the blending in Cool Riders, turns out the basic logic is

If a sprite has palette value of 0x8000 it’s transparent, always.
A value < 0x8000 is a solid 555RGB colour A value > 0x8000 is a blended 555RGB colour

when a Colour is blended a sprite attribute is used to decide the blending level, this goes between 0x0 (full blend, MAYBE 100% invisible) to 0x7 (no blend, solid)

Implementing this was more work than I expected, mainly because it broke my zbuffer implementation, because in some cases transparent sprites were being sent to the display by the game before the sprites they were meant to cover, causing them to cut holes in sprites and show the background instead. The only real way to fix this was to sort all the sprites based on their z value before drawing which meant a slight change in the way things were being done was needed.

Having done that, I was able to get the above screens, and blending seems correct in the cases where it’s used now.

One thing that threw me off when trying to figure out the blending at first was that ALL the road pixels had the 0x8000 bits set, why would you want to blend the road? The only thing underneath it is the background! It turns out that most sections of the road actually have the 0x7 value set for the blend level, meaning they render as solid, but during my testing (rendering different values of that register as random colours every frame) I noticed that some bits of the road actually had different blend values set, in increasing amount. It turns out the blending is used for a most unexpected effect too, blending the end of one road terrain type with the start of the next! The screenshots below show the road between stages first, on the left from an earlier build without blending, and the right the current code, with blending applied, kinda neat.

(Left, old code, no blending | Right, new code, blending used between road sections)

This is also used to great effect on short tunnels and the like. The road blending also gets used to show sprites below the tunnel for a special effect when entering the extra stage, as the first lot of screenshots show.

Of course doing all this slows things down a bit, so I’ve actually spent most of the past 2 days coming up with optimizations, including an object tile caching system so that we can avoid calling the RLE decoder too often, as decoding entire rows of 16×16 tiles each time just to draw a tiny road line in the background is not an insignificant waste of CPU power! All that got it up to a decent enough speed on my system, before all the extra effects dragged us to around where we were before, so time well sent.

Additionally I improved the full-screen RGB effect logic, so it now actually gets applied to the full screen instead of just the tilemaps, but it will need a video to demonstrate that, and I don’t have time to do one tonight, later maybe.

Content not available.
Please allow cookies by clicking Accept on the banner

(Video showing the latest progress, cropped to a single screen)

Content not available.
Please allow cookies by clicking Accept on the banner

(same video, without cropping so you can see the attract on the 2nd screen)

A few graphical glitches remain, but nothing major and it’s feasible the ones we have left could be original bugs although I do have a few things to try first. The sound is still buggy, but as of now the game is marked as WORKING.

Here is the video to go with this update

Content not available.
Please allow cookies by clicking Accept on the banner

Another interesting aspect of the Cool Riders hardware is the way the palettes work, and this is also tied directly to the compression.

Due to the palettes for the sprites being hardcoded in the compressed gfx ROM with the sprite data it would be quite tricky to do colour cycle type effects without storing an entire extra copy of the palettes just for one or two changes. Sega realised this and covered it by allowing secondary ‘partial’ palette entries to be used, substituting a specified range of colours in the original palette if enabled. This is how the tyres and brakelights on the Player and Rival bikes work. If you look at the older screenshots like the one below:

(old screenshot from previous update, note the tyres / light on the bikes are wrong)

You’ll see that the wheels and brakelights appear are bright blue/green colours. This is because those data entries are a actually meant to use data from the 2nd palette index specified, not the first. This means that by cycling the secondary palette index value, and leaving the first alone the wheels of the wheels can be animated without storing the colours needed for the rest of the object. If you render just the second palette index values, ignoring the primary one you end up with the following, note, the tyres and brakelight are correct

(test screenshot, just the using the 2nd palette index instead of the first, note for the bikes ONLY the tyres / light are correct)

Interestingly, if you render the scene using ONLY the second palette indexes get a lot of objects are still correct, because for most they duplicate the same palette entry in both.

Combining the two you get this

(new screenshot, all bike graphics are correct)

How does this work? Well we know the basics, it’s done when decompressing the RLE sprites, using the 2nd index in certain situations, but beyond that is where things become confusing. The problem is this effect seems ONLY to be used on the bikes, giving little evidence of how it should actually work. Maybe for certain sprite type it’s always enabled, so they have to ensure both palette indexes point to the same place, but even then there is what should be a mask / threshold value which is set to 00 for everything except the bike anyway, and there is a bit ONLY set on the bike which would seem a sensible bit in a sensible location to use to enable the effect. Either way, it works, but that’s sometimes the downside of hardware with only one game, making limited use of something. If the game didn’t use this here we wouldn’t know about it at all. Another point of interest is that OutRunners also uses a special way to do the brakelights on the bikes, although a different one to the one we have here, but again it points at some of the System32 thought processes going into the design here.

One effect used more widely is the RGB brightness control, and it’s the reason some things turn an odd colour in the background in the current video. Kale has done a preliminary hookup of this effect, but right now it’s not quite right (has various modes) and in addition it should apply to the full screen, including sprites, so you can’t even see if if you’re in a tunnel right now, or you have a background partially made of sprites. It’s used for various thing, including flashing the screen red when you crash, and a white ‘flash’ when you come out of a tunnel, as an attempt to simulate the time it takes for your eyes to readjust to the light.

Kale also added an interpretation of some other registers, allowing the InVision logo, and filmstrip part of the attract to render with solid backgrounds, rather than the background tilemaps which shouldn’t appear there.

The filmstrip also uses another feature, clipping windows. For each part of the filmstrip a window is specified, this clips all graphics to within the specified area and is noticeable on a number of the animations, especially the zooming one (we’re still missing a heart on the TV there, but that’s another matter) This effect is also used between stages (not quite sure why) and occasionally gets set to erroneous(?) values on certain levels like Romania, the second time you encounter Dracula. Not sure what that should do, if anything. I’ve implemented this effect, interestingly the format for these windows is basically the same as the format used for the framebuffer copy params. Furthermore there might be yet another way to specify this using another set of blitter registers, used in the end sequence (you can’t notice with the ending in the video, but for the one in the previous video the text should get clipped to the TV screen area, currently the game just sends a ‘full-screen’ setting via the usual method so that needs further investigation)

Anyway, that’s yesterday’s work. I might take a break from things today before looking at the blending.

The routes, for people interested

Stage 0: Prestage

Left Route
1st Stages: Niagra Falls
2nd Stages: Greenland, West Indies, Brazil
3rd Stages: Rumania, England(1), Spain, Egypt, Kenya
4th Stages: Arctic, Russia, China, Japan(1), Hong Kong, India, Antarctic

Middle ROute
1st Stages: New York
2nd Stages: Washington, Niagra Falls (2), Chicago
3rd Stages: Atlanta, Mississippi, Desert, Grand Canyon (2), Rocky Mountains
4th Stages: Florida, Houston, Texas, Hawaii (1), Las Vegas, San Francisco, Alaska

Right Route
1st Stages: Grand Canyon (1)
2nd Stages: polynesia, Hawaii(2), Canada
3rd Stages: Australia, Indonesia, Japan(2), Mongolia, Russia
4th Stages: Antarctic(2), Kenya, France, Switzerland, England(2), Sweden, Arctic(2)

Stage 5: Extra Stage

– total 50 stages

————————————–
Left Route (starting Niagra Falls)
————————————–
-Greenland
–Rumania
—Arctic
—Russia
—China
–England
—Russia
—China
—Japan
–Spain
—China
—Japan
—Hong Kong

-West Indies
–England
—Russia
—China
—Japan
–Spain
—China
—Japan
—Hong Kong
–Egypt
—Japan
—Hong Kong
—India

-Brazil
–Spain
—China
—Japan
—Hong Kong
–Egypt
—Japan
—Hong Kong
—India
–Kenya
—Hong Kong
—India
—Antarctic

————————————–
Middle Route (starting New York)
————————————–
-Washington
–Atlanta
—Florida
—Houston
—Texas
–Mississippi
—Houston
—Texas
—Hawaii
–Desert
—Texas
—Hawaii
—Las Vegas

-Niagra Falls (2)
–Mississippi
—Houston
—Texas
—Hawaii
–Desert
—Texas
—Hawaii
—Las Vegas
–Grand Canyon (2)
—Hawaii
—Las Vegas
—San Francisco

-Chicago
–Desert
—Texas
—Hawaii
—Las Vegas
–Grand Canyon (2)
—Hawaii
—Las Vegas
—San Francisco
–Rocky Mountains
—Las Vegas
—San Francisco
—Alaska

————————————–
Right Route (starting Grand Canyon (1))
————————————–
-Polynesia
–Australia
—Antarctic(2)
—Kenya
—France
–Indonesia
—Kenya
—France
—Switzerland
–Japan
—France
—Switzerland
—England

-Hawaii(2)
–Indonesia
—Kenya
—France
—Switzerland
–Japan
—France
—Switzerland
—England
–Mongolia
—Switzerland
—England
—Sweden

-Canada
–Japan
—France
—Switzerland
—England
–Mongolia
—Switzerland
—England
—Sweden
–Russia
—England
—Sweden
—Arctic(2)

One of the most significant improvements to the Cool Riders emulation over the last day and a bit has been the addition of Priority handling, allowing you to see most of the objects as they were meant to appear.

It turns out the system uses what appears to be a 12 + 2 bit z-buffer (although it could possible be full 16-bit, and the 2 separate bits MIGHT have additional separate meaning) This is a lot more priority depth than most 2D systems have, and is actually closer to what you’d find on a 3D system. Either way, simply implementing it as a 14-bit z-buffer and doing a z-compare for every pixel write at least fixes most priorities, leaving the game mostly playable again.

The other fix made over the last few days involves the transparent pens. Previously there were pixels missing from most objects (not the zoom gaps, I’ll talk about those later) This was caused by us filtering out all 0x0000 value pixels when copying our framebuffer to the screen. This was actually incorrect because 0x0000 means the pen is black, instead pens which should be (fully) transparent have a value of 0x8000. The most significant bit also seems to have other meanings tho, and is set on some objects which should be alpha-blended, as well as the text and various other objects for reasons I don’t yet understand. We actually have a 2nd palette offset with some sprites too, although it’s usually set to the same value. Either way there are still questions to be answered, because if the 0x8000 bit specifies alpha blending, how do you blend a black pen? It could of course be additive blending, in which case a black pen would blend to the same colour as the source, but I’m not sure of this yet. At least now however objects look a bit better.

There are still imperfections, other than the missing transparency effects my zoom precision is still inaccurate, this is what is causing the gaps between sprite tiles in many cases. It’s easy to understand why, each tile is 16-pixels wide, sprites can be made of multiple tiles (and usually are) The zoom value for 1:1 drawing is 0x40 (128) to draw 16 pixels, and so the lower bits of the zoom, if looked at on a per-tile scale have no effect, you’d need to span multiple tiles to see them. The problem is my zoom drawing currently only considers the current tile when drawing it, but the full zoomed width of the sprite when placing it, hence gaps. It shouldn’t be too hard to come up with a better algorithm and elimiate the gaps, but zooming in emulation is rarely perfect because the actual algorithms applied by hardware when deciding which pixels to shrink / expand vary wildly, and only in some cases is it obviously contains in a ROM table (NeoGeo being one such example)

Performance is currently an issue too. For all I’ve said about this being a sprite-scaler it can throw as much at the screen as most 3D systems, make that 2 screens, each running at a medium resolution (same as Daytona etc.) with lots of scaling, z-checking, and (once implemented) blending and you can see it’s expensive. Currently for good performance you’ll need a decent i3/i5, my Core2 doesn’t quite cut it in places. I’m still trying to optimize it, and there is definitely room for improvement in some area. I was hoping that threading the sprite rendering would help some, but it doesn’t, it helps a little, but also becomes very sensitive to any other use of the 2nd core by the host PC (are MAME threads running at a really low priority or something?) so while you get some gains you can get nasty performance spikes if the PC decides to do something else in the background. I’m not out of ideas yet, but I thought it fair to warn people that in the current state it is kinda slow. Just emulating the CPUs, and sound chips alone (even with SH2 recompiler) is actually quite a drag, so I don’t have THAT much room for maneuver.

There are still other missing features too, quite a few registers are ignored, and there are definitely clipping window effects I need to implement. How the tilemaps get enabled / disabled isn’t known either.

*edit* Zoom handling has been improved, gaps (mostly) gone

Here’s the video to go with this update, sorry for the delay, I’ve probably hit some kind of unwritten monthly upload limit because my uploads are terribly slow right now ;-) A few changes have been made since this was recorded, but they’ll have to wait.

Content not available.
Please allow cookies by clicking Accept on the banner

I like to do articles about interesting / unique things I find when emulating a platform, and the way the road is drawn on Cool Riders is one of those things.

While most hardware uses a ’tilemap’ like chip to draw a road with linescroll and lineselect type parameters to do bends and curves (that’s how it works on OutRunners for example) or simply throw a ton of layered sprites at the job (F1 Super Lap) Cool Riders takes a hybrid approach.

You’ll have noticed that in the previous update, even the latest video I added to it was lacking the center of the road, this is because the road is somewhat special. While it does still use the regular sprites / blits it has an extra parameters on them. This parameter allows every line in the sprite to use a lookup value specifying the zoom and scroll offsets for that line of the sprite. This essentially allows you trapezoid shaped sprites by having a table of increasing zoom values. That’s exactly what Cool Riders does, meaning this extension to the sprite system lets them use normal sprites in a way more suited to drawing the road.

Here are some screenshots, sorry about the bad colours and priority, I haven’t figured those things out yet. Also there are gaps in the zooming because my algorithm is imperfect.

Hooking up the road has actually made it much harder to play for now, because it gets drawn over the bike, the priority scheme looks to be non-trivial at this point.

Anyway, Cool Riders also sports another fairly uncommon feature. As well as being able to flip sprites in the horizontal and vertical direction it can also rotate them by 90 degrees. This is used on the map screen. All 3 forks of the main tree are the same sprite with rotation applied. Quite why all roads lead to New York at opposite ends of the earth I don’t know, especially not when it’s the 2nd stage. From memory some Dynax hardware supports a similar effect.

What happens if you enable both effects at once? I haven’t seen the game do that, and I likely don’t want to know ;-)

Overnight Kale confirmed something I’d been thinking for a while, the Sprite palettes are in the compressed ROMs (they appear to be uncompressed tho) This allowed him to fix the palettes for the text in test mode, but still needs work for actual game graphics etc.

CRT test screens can be handy, I’ve started to (hopefully) improve the palette addressing based on it



Getting there..



That’s better.. fixes some ingame objects too (but still not right ingame)

Some Ingame colours, note still broken transparencies, imperfect zoom, and broken priority.. so you can’t actually see much

So.. I spent all night looking at the sprites, it’s 7am now.. I should probably get some sleep

There is a video to go with this too… didn’t have time to do it last night

Content not available.
Please allow cookies by clicking Accept on the banner

Anyway, as discussed before the game uses compressed sprites. The actual compression isn’t TOO complex, it’s just several RLE modes in the end (although the current implementation is still incomplete, many sprites have holes, and I don’t know if the palettes are encoded in there too)

The main issue is the weird arrangement of the ROMs, the compression works on 10-bits at a time, which is unusual, and means that the game actually has 10 sprite roms, which need to be correctly ordered and divided up to get the right data to process.

One area Cool Riders differs to practically every other Sega game is that the sprites are actually TILE based, every sprite is made of a number of 16×16 tiles, and the layout of these tiles for each sprite is also stored in the compressed graphics roms. The spritelist actually references a tile arrangement in these roms, with that tile arrangement further referencing the compressed data located at some position after it (allowing for the same compressed data to be shared with multiple tile arrangements)

Anyway, for now the temp zoom code is gone, so you can see things break up quite badly in the video, and the lack of flipping becomes VERY obvious now we have somewhat correct sprite data. Improving these is on my todo list. Likewise I still need to figure out where the framebuffer clear bits are because right now it flickers badly, it’s migraine inducing.

Here is a video from yesterday with temp zoom code reinstated, some stupid bugs with flipped-zoomed sprites that have since been fixed tho.

Content not available.
Please allow cookies by clicking Accept on the banner