Tuesday 20 August 2013

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!


Monday 29 July 2013

Time Travel (1.21 Giggawatts required)

Tonight I have been attempting time travel. One thing I've wanted to change early on in this hack has been the year of gameplay. Starflight starts in 4620, which doesn't fit for a Mass Effect game [SPOILER]depending on how you play number 3![/SPOILER]

As noted before, I've found the operations centre messages in the ROM, but changing the dates makes the title not appear in the message list. The message is still there, and still selectable/readable, but the title will not show. I reckon this is tied into the in-game calendar, as changing the title doesn't make it disappear, only changing the date. I thought I would try a quick and ugly brute force attempt to change the games start date. Searching for text in the ROM for "4620" only brings up the message titles. So I tried to look for the hex (120C would be the equivalent).

I found 20 examples. I changed the title of the message so the date read 2158, and went through one by one changing any instance of 120C into 086E (the hex equivalent of 2158). 19 of these changed nothing when viewing the message centre. Changing the first totally borked the game:

The EA splash freaks out. Different restarts can make it freak out in different colours, but it never gets past it. So I can safely say that those 2 bytes aren't the initial date. Gives me a rough idea for where to start when removing the EA splash (which I would like to at some point), but no help with my current goal.

So time for another way to find the time format. Idea here was to look through what was happening in RAM, so I fired up regend (the only debugging Mega Drive emulator that actually seems to function in Wine), and got the ship orbiting. As there was little happening on-screen, and no input to confuse things, I thought it would be easy to spot something as simple as the ticking clock of time. After investing some time of my own, I wasn't wrong. The fun starts at RAM position 0x943B...

0x943B (highlighted green) is a simple rising tick, that flips at 93h. Strange number, but if it gets the game timing right who am I to judge? The next byte (highlighted in red) constantly matches the current "hour" in-game. This however, seems to be stored in BCD - i.e., 09 flips over to 10, as opposed to 0A as you'd expect in hex. The following byte (highlighted blue) matches the current in-game "day" (again stored BCD-style). As expected, the next 2 bytes hold the "month" and "year" as expected, again in BCD. The "year" byte only holds 2 digits, such as 46XX. So I did what comes naturally - try and break it and see what happens! Pause emulation, push a few nonsensical times into the RAM, let emulation resume and...

It's broken. Kinda. Though for some reason, the game just doesn't care. Even though it is the 1Cth day, of the C4th month, 462F anno domini. So I let it roll, to see what the date would tick over to... Day 1C clicked to 23, which made some kinda sense. C is equivalent to 12, which added to the 10 makes 22. Which should turn to 23.

Changing the date/time to something more impossible has odd side effects. For example, setting the hour to 26, gets it trapped on the same day, with the time getting higher and higher with never changing a date. Looks like the time handling routine is just "hour==24" to change the date, as opposed to "hour>=24".

For fun, I set the year to 4699, and letting it tick over returns it back to 4600. This reinforces my impression that the "46XX" year is hard coded into the ROM. I imagine the date routine for checking messages will add 4600 to the year byte before comparison. Now the challenge will be to find 4600d in the ROM somewhere (or 11F8h), and find the code that initializes 0x943F in RAM, and tweak them both to change the year in the game.

Time to start learning more about regend's debugging features!

Monday 10 June 2013

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!

Wednesday 29 May 2013

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.

Sunday 12 May 2013

First footsteps - and a few wobbles

Early proof of concept work has begun, and I've already hit snags. Overcome most of them, but snags none the less.

I'm working on a Linux & Wine setup for this hack, but attempting to use as many native tools as possible. The hex editor I have settled on is Bless - and it has functioned perfectly for my needs. The only feature that I really wanted was tabbed editing of multiple files, so I can refer to the original working ROM easily, and it has that. Has loads of other features too, but I don't seem to need them yet.

So with this tool in hand, I started looking into the Starflight binary, and thing went better than expected! Started with a random scroll down the data, hoping to find ASCII enconding, and lo and behold I did:-
Bingo! With the knowledge that the main story info and conversations was stored in such an easy to use format, my spirits were lifted. Time for one quick tweak, and to see if I can still get the ROM to load. So I changed the word "STAR" to "RATS", saved my new ME0.bin file, and went to load it up in Kega Fusion and see what happens.

 Aaaand, black screen. I knew the cart checksum would be an issue on hardware, but Fusion has the option to automagically fix it on the fly, so I was hoping it would load anyway. What I wasn't expecting was for EA to have their own extra checksum function hidden in the ROM. EA are a terrible, distrusting company nowadays - and it appears they've been that way since 1991 at least!

A quick google later, and I find that this has been overcome. wboy from the NHL94 hacking scene has offered a solution to the EA ROM checksum issue, which I shamelessly copied into my own project. Save, load, rinse, repeat and the ROM now boots up in the emulator! Thanks wboy! (I felt it unnecessary to sign up to yet another forum just to post a single comment of thanks, so saying it here clears my conscience somewhat).


So I did a bit more text editing, and went to see the results, and it has paid off.
And there, in functional glory, is the first message in the message centre when a new game is started, with text modified for a link to the Mass Effect universe. The only issue I have found is the date at the beginning - if I change that, then the title of the message doesn't show up in the message centre. I will have to have a little deeper look at why, because the year 4620 puts this game far later than Mass Effect, which doesn't really work.

So, the proof of concept for changing text has been done, and I'm about to start looking into changing the year - as it's clearly referenced elsewhere in the code.

I'll post more when I've resolved that issue, and started my proof of concept for the graphics editing.

Genesis - It all starts with an idea...

All things start with an idea, and while playing through BioWare's Mass Effect trilogy, I had one.

Back in the Mega Drive/Genesis era, I remember playing a game called "Starflight" by Binary Systems.This game had everything I wanted at the time - a giant galaxy to explore, different races to meet and fight, planets to explore, and all tied together with a loose background story of your epic voyage through space. Playing the first Mass Effect reminded me of this game in many ways, especially when exploring planets in the Mako vehicle. The devs at BioWare have even mentioned Starflight as one of their inspirations for the game. (As a side note, I think it's a shame that vehicle exploration was cut from the rest of the trilogy - it took away a lot of the sense of adventure, seemed to close down the scale of the universe, and made the game feel closer to the normal dull "corridor-shooter". But the rest of the gameplay mechanics had been tweaked and improved so I could never get too mad.)



With a head full of Mass Effect, and my nostalgia glands throbbing at the memory of Starflight, I have decide to take on a project to combine the two. So I am going to be working on a romhack of the MD/Genesis version of Starflight, replacing graphics and text to make a Mass Effect themed version. Gameplay will remain unchanged, as that kind of assembly hacking is beyond my current knowledge, but after a bit of digging I may end up making some changes - we'll just have to see what I learn.

I will be documenting the process here, so fingers crossed it actually functions!