Skateboard Build – Green

This is my first post in quite some time, as many things have eaten up my free time – namely fatherhood, increased work responsibilities, and a worldwide viral pandemic that we’ll be telling our grandkids about.

Between all these strange life-changing moments, I decided I needed to get some more exercise, and relive some of my youth at the same time. So I did the rational thing, and made a skateboard.

My custom-painted deck


As I used to skate a decade ago, I thought it would be worth getting back on the old plank, but my busted up old setup needed lots of attention – basically starting from scratch. Continue reading “Skateboard Build – Green”

Zelda Custom Gameboy

For a very close friends birthday, I wanted to do something special. As I’d already modified a few gameboys by this point I thought I’d up my game in that department. He is a massive Zelda fanboy, who’d preordered both the limited edition Zelda 3DS (based on Ocarina of Time), and the limited edition Zelda Wii U (based on Wind Waker), I thought he’d appreciate a DMG gameboy done in the style of Link’s Awakening.

Links Awakening Limited Edition DMG

He’s not into making chiptune, so I didn’t bother putting in a line-out or any other such hardware. But I did custom decals on a new shell, matching buttons, and a backlight. And it came out looking great! His face when he opened it (along with a copy of Link’s Awakening) was worth all the time I put into it.

After the jump there are some pics of what the official limited edition 3DS & Wii U look like. I think I copied the basic design ideas pretty well. Let me know in the comments!

Continue reading “Zelda Custom Gameboy”

Suited and Booted N7-style

After finally getting all my notes tied together and indexed, I decided it was time for a bit more graphical tweaking. Tonight. I have attempted to recreate the N7 armour in the starbase.

I booted up RegenD, and went to the starbase, to be greeted by this happy little astronaut:-

Using RegenD’s VDP debugger, I was able to find out that this guy is actually 2 different sprites (legs and body), both using palette 1. Luckily, these are the only 2 sprites on-screen that use this palette. The first thing I noticed is that this palette has all the colours I need:-

A black, a nice deep red, and plenty of extra greys for shading. In theory, I could just recolour and tweak the original guy, and not risk breaking any other colours elsewhere!

So I knocked up a TLP palette file, loaded the ROM up, and tried to find the actual tiles that made this man… And I couldn’t. I couldn’t see a single one of them. This could be either

  • The tiles are stored at a strange offset. I tried offsetting the ROM in TileLayerPro, but I still couldn’t find them – although I didn’t try every possible offset. Or it could be
  • The tiles that make this guy up are compressed.

I fear it may be the latter. I dumped the VRAM during this scene, located one of the tiles (I think, not 100% on how VRAM is laid out), and searched for the hex in the main ROM – no results found. With the games title, font, and doorway graphics, they were quite visible in TileLayerPro when I had the right palette assigned, even if they were offset. As I could see nothing similar to this guy, but lots of “junk” tiles, I get the feeling he is compressed.

So I went for the second option to make him look like an N7 agent – hacking the palette directly. I pulled the palette from CRAM, reversed the endian-ness (sp? word?), and searched for it in the main game ROM. I got a single exact match on the first attempt – that must be the palette data. I made a little change to one of the colours, loaded it up, and one of the colours was now different! Success!

I started tweaking some of the palette, and it started looking pretty good – here is what the palette changed to:-

Changed the greys, made one of them red, tweaked a black to make the visor stand out. Lots of little changes took quite a while, as I was changing the hex by hand, and reloading the ROM each time to see what it looked like. After almost an hour, I got this little guy:-

I personally think he looks pretty badass! He definitely wouldn’t look out of place on the SSV Normandy. I’d still like to track down the tile data, to alter a few little things (the colour of the backpack, the fact he now has a grey outline, and a few embellishments), but for now he looks good enough.

At this point, I kind of freaked out though. “Oh no!” I said to myself, “what if that palette is used elsewhere in the game?!?!?!” – that could be a mighty problem. But I had a little play around, and for the starbase, external ship flight, and landing on planets, that palette never seems to get reused, so I may be in the clear.

So in the end, I’m 80% happy – the remaining 20% just gives me more motivation to get GensTracer working, so I can find the damn tiles…

Looking good, hanging in the space-hood:-


Post-Break Graphical Tweak-Out

It’s been a very busy year, but now I appear to have some free time once again, I’ve finally been able to continue on my project. After so long out of the loop, I’ve kind of forgotten where I was with it. So I’ve started small to remind myself of the code and, to a larger part, the tools I was using. Then I remembered I still don’t have the perfect debug tools on my Linux box. Stupid regen, and stupid direct-memory-access.

After a bit of digging through my notes, I remembered how unhappy I was with parts of the starbase/menu system in game. Namely, the doors to the message centre and the trade depot. The trade depot was a quick fix, I tried to make the icon more obviously trade related, by incorporating some elements that are actually traded. So from the simple “hands and boxes” logo, I just added a “Cr” and “Au” to the boxes – representing credits and gold. It’s still not great, but feel it’s a bit better with the additional clue:-

The in-game font didn’t fit into the boxes, so I had to freehand it – easy enough for a few pixels of text. But it got me to thinking about the actual in-game font… It is square, crisp, legible, and functional. But dull. And in a delusion of grandeur, I thought I could improve upon it. Ha! It is a an 8×8 font with a limited character set (capitals only, few special characters) – but it is outlined. Which not only shrinks the characters, but makes them more visible against any background. I tried around with some of the pre-made fonts from RHDN (again that resource saving my ass), but none of them rendered properly without the outline. They were either “thin” (is that right, typography nerds?), or they blended really badly into surrounding colours. At that point, I realized the outline was key in this games implementation. I tried crafting my own font, but that always broke something – kerning, readability, or just the stylistic “fit”.

I wish I had some screenshots of my failures to show you, but it was a couple of hours of frustration, and I didn’t have the foresight to save my experiments. Either way, I came to the conclusion that nothing is wrong with the standard font – and where it did fail, I couldn’t improve without making huge changes to the code. Huge changes well past my skill set.

Back to the second door then. The original shows the logo of “INTERSTEL”, the operators of Arth starbase and your mission.

This logo appears all over the place, so I am aware I will have to retool this logo in many places of the ROM – but as far as I remember, this is the smallest it’s shown in game. And the most frequent. With that in mind, I tried to recreate the Systems Alliance logo from Mass Effect:-

[Apologies for resolution]
Due to the display resolution of the Mega Drive, rarely do you have many pixels to play with. And that globe in the middle will NEVER look good with my artistic skills recreating it! Especially on the door graphic. So I’ve taken an executive decision which will hopefully please Mass Effect fans too, and chosen to plaster the game with the logo of the Systems Alliance Navy:-
 Not only is this twist on the logo easier to replicate given the limitations, it is within reason that the ship you command, and the Earth military starbase, would be under navy control. So hopefully this cop-out based on my artistic failings will still appease the Mass Effect purists who may happen upon it. I slipped through the ROM in TileLayerPro, and finally tracked it down at 0x880C2.

It’s got a completely different aspect ratio to the logo I’d like to use, but there is some black space I can move down into, which I had to. The only issue with using the extra space at the bottom, was that it might not quite fit with the rest o the doors. But that wasn’t too much of a problem, and it came out looking recognisable – which was my prime requirement. Overall I’m quite happy with the result.

Although the aspect ratio is a bit screwy, It works for me. Especially considering my artistic “skills”. Next on the hit list is to recolour the player character, to make his spacesuit red & black, like Shepard’s signature N7 armour. But that’ll be saved for next time I want to hack some graphics!

I have also made some progress with the titlescreen improvements. Whilst browsing for the door graphics, I happened upon a few extra text characters – all the letters for the copyright blurb. Only one copy of each letter for the most part, and so jumbled I couldn’t write anything by just replacing tiles. As I still haven’t found the code that loads it all into VRAM, any big change would have to wait. So for a quick fix, which ended up looking very clean, I just blacked out all the letters:-

I also replced my “X” & “Y” filler tiles with tiles of noise from within a data section of the ROM. It looks enough like a natural glitch that I’m happy with it for now. I’ll come back to it at some point I imagine, but it’s a good placeholder. Hopefully I can fix it up, when I finally work out how to spy on the DMA writes to VRAM. But that’ll be for another update.

Another update that will hopefully come a lot sooner!

Title Screen Break Dancing Headspin, Part 1

I have recently had a look deeper into my title screen tilemap woes. As posted earlier, currently my title screen looks like this:-

This seemed like a good start, but clearly not good enough. Before I began, I read a lot of VDP page on the Mega Drive Wiki. I cannot overstate how brilliant a resource this is, it has given me a much greater idea of the little black console’s internals. If you want to know anything about the system, go there.

As the tilemap has repetitions in key places (for example, the X & Y tiles), I started looking for a way to change this (and hopefully get rid of the licensing info in the process). So step one was to try and find it plainly in the ROM. In RegenD, I loaded the ROM up to the title, and turned off the layers one by one to see what was where. The planet background is on PlaneA, and the Mass Effect logo & license info is on Plane B. I loaded up the VDP debugger to look at the registers:-

Register #04 is what I was looking for, the location of the PlaneB (FieldB in Regen-speak) – 0x2000. A quick VRAM dump, into my hex editor, and have a peek at location 0x2000 – and gold. After bytes & bytes of 00, suddenly I see it – “6C 87 6C 87 6C 87…”. Obviously what  I was looking for, the first row of repeated blank tiles – 6C87 being the 16-bit nametable entry for the blank tile. First try, I copied the first 20-odd bytes from the tilemap in and searched the main ROM for it.

“No Match Found”

Not entirely surprised, to be honest. With that much repetition, storing it plainly would just be a waste of space – and that could get you the death sentence as a game developer in the cartridge days!

As I can’t find it plainly in the ROM, it was time to get a bit clever, and see if I could find out where the game got the info from. Back in RegenD, I opened up the debugger, and set a breakpoint for both read and write on 0x2000 in the VDP:-

Now, I restarted the game, and hoped for it to freeze while the screen was loading so I could see the ASM code happening, and see where it was getting the data from (or how it was generating it). But nope, it never hit a break, just kept playing. Assuming the debugger was at fault, I tested it by setting a breakpoint at 0x1459 – the location I changed while attempting time travel, that ended up breaking the splash screen. Restart the game, and shortly after the EA splash begins, the debugger pauses the game and pops up. So it’s not the debugger.

I scratched my head for a while, but couldn’t get it – so I asked for help. No shame, this the first time I’ve tried to debug a Mega Drive game, and these tools don’t have the best documentation! RedComet from the RHDN forums (another brilliant resource) brought something to my attention – the RegenD VDP debugger only breaks on standard read/write operations – but not from DMA access. So to find out what is going wrong, I’m going to need to use GensTracer.

And I have had serious issues getting any Gens derivative running on my system…

I’ve learnt a lot about the Mega Drive’s VDP, and learnt how to use the RegenD debugging tools a lot more – but have also learnt of its limitations. Now to learn more, with GensTracer!

Titlescreen Hack Semi-Advancement

…well, kinda. It aint pretty, but it’s a start. More below.

(I will discuss more about getting a decent debugging emulator running later, as my VM installation drove me a little insane, after 5 attempts I have it. That will be another post, if I ever get over the trauma. Long story short, if you want Gens or any of it’s derivatives to function properly in a VirtualBox host, DO NOT INSTALL GUEST ADDITIONS. For that path leads to madness. That is all.)

Whilst jumping through hoops trying to get some handy VRAM & CRAM dumps of the title screen for the first graphics hack, I had a bit of a brainwave. The idea was simple – replace all the tiles I’d found of the title with differently coloured fonts, then I could easily see what was reused, and wether I could work around it.

So after the first run with the font copied over, I instantly saw some highly repeated characters, that wouldn’t do. So I blanked these tiles (they all appear as solid pink in the screenshot above). After that, I felt hopeful. There was a good size chunk with minimal repeats! Squeezing in the logo seemed possible!

The two-tone letters are the only repeats in there, so I thought this might be possible to work around. So I opened up TileLayerPro once more, and got my pixel art “skills” on the case. With a picture of the official logo, GIMP, and the grid tool, I got to transposing.

My art “skills” truly deserve the quotes I am using on them. After 30 minutes or so of painting, I booted up the ROM, and this is what greeted me at the opening:-

I must’ve misread/misaligned things in my head, as I still have some conflicts. There is a blank tile in an awkward place (inside the first F), some duplicated tiles I can live with, and two duplicated tiles I don’t know what to do with (showing as X and Y). Well, when I start chugging through the VRAM dumps and logs, I may be able to rearrange things.

And, obviously, clean up my tiles. But as a proof-of-concept, I’m quite happy. I just wish I had more time to spend on it!

Adventures In Graphics (and the search for *useful* emulators)

With the EA checksum skipped, and my first text edits visible in game, I ploughed on. The ROM header has been updated to play on all regions, and every reference to MU (the currency of Starflight) has been rewritten as CR (credits) – much more “Mass Effect” than MU. I’ve made a few notes as to which races I intend to transform into their ME equivalents, but that’s a different post altogether. I haven’t properly looked at the date issue yet, so everything is still showing as the year 4620. I’ve thought about that, but can’t even settle on a date to set this in any more… Starflight spans 41 years, which is longer than the gap between the Human-Turian first contact war & the Reaper invasion in the Mass Effect universe, so no time entirely makes sense. But again, that’s an issue for another post.

With text-edits going fine, I thought it was time to jump right into doing the first few aesthetic changes, and this is where my troubles became apparent.

This is the main title screen from the game. The changes planned seemed small – remove/change the “licensed by…” text, and replace the STARFLIGHT banner with a low res reproduction of the Mass Effect logo. Seeing as how the “licensed by…” text was in the same font used throughout the game, I thought a simple text edit in my hex editor would be able to remove it – just blank it out with spaces, or replace with “Unlicensed hack by Category, commiserations to EA, BioWare & Binary Systems”. But unfortunately, no such text appears in the ROM, at least not in the same easy to change form as the rest of the game’s text. Fair enough I thought, maybe the game stores the entire title screen as just a set of tiles. Thinking along this line of thought, I fired up Tile Layer Pro in Wine, and started looking for it. Mixed results.

I found the tiles for the font (I probably won’t change it, but good to know I now could), but nothing so obviously laid out as the title screen. Obviously the code references the same font tile locations differently to text in the rest of the game, so once again a more in depth look into the code will be necessary. Luckily, the main title banner was stored right above it in the ROM!  What great luck!

I spent a few minutes trying to reconstruct the banner from the tiles, and noticed two problems almost immediately.

  1. The tiles aren’t just laid down for the logo – some of them are reused within it, making the plan of just “importing” some Mass Effect logo from a DVD case spine impossible; and
  2. The colours are not even slightly right

The solution to 1 is not-so-obvious, but will be solvable when I work out the title screen “licensed by…” placement (as I imagine it is all referenced in the same area of the ROM. I prepare to be disappointed). The solution to 2 was very obvious however, but has confounded me for more time than I care to admit (mostly due to my Linux fanboyism – but hey, acceptance is part of the cure!)

I had overlooked the way the Mega Drive actually deals with graphics, by having sprites and palettes as separate entities. I’ve read the basics of the technical docs for the Mega Drive, and am aware that palette data is stored as RGB values in CRAM. If I can get a dump of the CRAM whilst the title screen is displayed then I can make Tile Layer Pro show the tiles correctly! Converting the hex CRAM dump into a TLP friendly format (or worst case scenario, converting by hand and inputting into TLP by hand) may be time consuming, but will make editing the tiles more obvious.

Getting a dump of the CRAM would also help towards my many many other investigative issues… What I needed was an emulator with debugging features. Being a Linux user bit me right in the ass here. There are some good native emulators for Linux, but none with the features I needed. Gens/GS plays nicely, but has no RAM/CRAM/breakpoints – any of the features I needed to continue. Same story for Kega Fusion – good to play on, but none of the features I really needed. But I have found the following:-

  • DebuGens is a mod of the original Gens, with handy dumping features – even direct TLP palette files from scenes! Seems useful, but under Wine, it crashes out whenever a ROM is loaded, which I put down to being quite low-level code, not just Win32 API calls.
  • GensKMod is another mod of Gens, with even more debugging features – but the same issues of the code base, and crashes exactly like DebuGens.
  • Exodus is a new emulator just released, which seems the best of the crop. Many features, and cycle-accurate emulation, it seemed to be the saviour. But this program is 64-bit Windows only, and Wine 64bit support just plain sucks. I compiled my on wine to run it, but it was buggy, and the wine64 install broke all other windows programs I was running, and that is just unacceptable.

This has left me with two options, which I will just have to suck up and go through with to progress on this project. My laptop has a valid Windows 7 license, and it is time to either dual boot or run a VM of Windows. The Linux acolyte in me feels tainted, but needs must…

…for now, at least. Exodus appears to be going open source soon, which is great news. A native Linux port would save all my issues. But for now, time to spin up a VM.

Until next time… Category

If anybody has any insight into my issues, or ideas in general, feel free to leave a comment.