mega drive – Quintendo

Bare Bones Script Updates

Well, it’s been a while since I even looked at this project, but the tiny glimpse of Mass Effect Andromeda from E3 got me somewhat remotivated.

So I’ve started going through my proposed race changes, and updated all references in the ROM for each. Everything it, and in some cases has given me a few characters to play with when I redo the scripting. The only real problem was with the Elowan… Their name being somewhat shorter than “Salarians”, has had me refer to them as the “Salari”. I will try and take another look at this and see if I can extend some of the references. Luckily, in much of the conversational text I can reword things to buy myself the few extra characters needed, hopefully it’ll only be a minor canon-quibble in the end.

So now I have NPCs in the game claiming to be Mass Effect races! The script still needs changing – no self respecting Volus would meet you without calling you “Earth-Clan” – and the graphics definitely need changing, but baby steps!

Whilst hunting through the ROM for race names to change, I stumbled upon a piece of text test from the original development:-

THIS STRING TESTS IF THE NEW WRITEMESSAGE FUNCTION WORKS PROPERLY OR NOT. THIS MESSAGE SHOULD APPEAR CORRECTLY IN A WINDOW WHEN THE START BUTTON IS PRESSED PLANETSIDE. WHEN THE WINDOW IS FULL, THE USER PRESSES THE A BUTTON AND MORE OF THE MESSAGE SHOULD APPEAR. THIS IS TO BE USED FOR ANYWHERE THAT A MESSAGE COULD RUN LONGER THAN A WINDOW, FOR EXAMPLE IN THE ALIEN COMMUNICATIONS SECTION, WHERE ALIEN MESSAGES COULD BE SEVERAL WINDOWS LONG. SPECIAL CHARACTERS THAT ARE ALLOWED ARE: LOWER CASE R STANDS FOR RETURN, SO YOU CAN BREAK A LINE IN THE MIDDLErSMALL C IS c, SMALL T IS t, SMALL I IS i.rPUNCTUATION STANDARD ASCII: !+=-:?%#.,rANY ILLEGAL VALUE SHOWS UP AS A

In my previous meddling with the initial briefing text, I had already worked out that “r” would insert a line break. Now I also know that “c” and “t” do something! The “c” diplays as ©, and “t” displays as an up & down arrow in the same character – generally used in game as a “press to continue text” notifier. I can’t see either of these bindings being of particular use in game, but the list of supported punctuation characters definitely will be. No semi-colons for this game!

Also, I may hijack this part of the ROM for a hidden message of my own. The kids go crazy for hidden messages these days.

After doing the race names successfully, I moved onto the mineral elements. Starting out with the fuel source “ENDURIUM+”, I decided tochange this to Element 0, or Eezo. In official environments (briefings, trade centre, etc.) would become “ELEMENT0” (to fit into the character space of “ENDURIUM”), and in more conversational/informal settings (convos, discovered logs and the like) it would be replaced with “EEZO”, in keeping with Mass Effect usage. So I searched the ROM and updated as necessary, and loaded it up to see the change.

I’d forgotten about the “+”, which seems to have persisted. On the upside, this means I can replace “ENDURIUM” with “ELEMENT-“, and if I can replace the “+” with a “0”, it will eventually read as “ELEMENT-0”. However it was only ever showing as “ENDURIUM” in the ROM. Tracking down where the “+” comes from will be a greater challenge, as that lone character appears a lot in the code.

That’s slowed me down somewhat, so I’m going on a trial & error fishing expedition for this elusive punctuation mark!

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:-

Zim – Tool Shoutout

Just a quick post to say, I have come to love Zim.

I found my notes on this hack (plans, discoveries, changes made, etc.) started becoming a bit unmanageable as a simple few text documents. After looking for a better way to manage everything, I came across Zim, which is just a lightweight, local wiki for storing all your info.

I’ve started rewriting my notes in there, and it has already smoothed the flow of recording and reminding in my notes. Highly recommended.

Now, I’m starting to think about hacking via a version control system, to keep all my little changes as there own patches. I have very little knowledge of them, and not sure if it is possible. VCS is normally just for textual changes, as would happen with source code – how reliable are they at picking up Hex diffs? Has anyone else tried this before?

Food for thought. Anyway, back to compiling my notes!

Racial Changes

I’ve been putting a lot of thought recently into how the races will marry up in this conversion. There are 7 main races that you meet in Starflight – this leaves a lot of Mass Effect races out… Thinking about how they react to the player (and each other), I’ve put together a little list of changes I intend to make. The most important ME races are all covered, and things kind of fit. Any major issues can probably be written around when changing the script though.

Below are the ways I plan to convert each race for this mod. And check out the beautiful artwork ripped from the Starflight manual. They don’t do game-art like this anymore!

The Mechan -> The Geth

This was the mos straight-forward of them all. Have one synthetic race, replace with another synthetic race. The Mechan are guarding the world of “Heaven” in SF, which I can easily replace with “Rannoch” (the old Geth homeworld). In SF, they are waiting for an old expedition to come and arrive, and are friendly with you if you claim to be a part of that expedition. With a bit of script-jigging, that can easily be changed to waiting for materials for their “megastructure”, and convincing them that you were sent by Nazara (the reaper Sovereign). Easy, and relatively clean.

The Gazurtoid -> The Asari

The Gazurtoid are described as “highly religious”, and see themselves as “redeemers of the galaxy”. The Asari are a highly spiritual race themselves, and while not “redeemers of the galaxy”, this can be toned down. They were the first to inhabit the Citadel, and political leaders, so not too much of a stretch.

The Thrynn -> The Krogan

Much like the Mechan, the choice for the Thrynn was obvious. They are described as “Cunning reptiles not to be trusted”. Which made me immediately think of the Krogan. In SF, you have to be friendly with them to stop them from attacking you. With the Krogan, being dominant is more likely to earn their respect, so that doesn’t quite fit. But with a bit of hackery, I may be able to change that. The Thrynn will attack you almost immediately if you are friendly with Elowan, or have one on board. Given the genophage in ME, that made me think…

The Elowan -> The Salarians

Who would the Krogan hate more than Salarians, for unleashing the genophage! The Elowan are described as gentle & peaceful, which can match up quite nicely with the Salarians thoughtful, scientific nature. The Elowan are wary of the Thrynn, as the Thrynn eat their children – the delicious “headfruit”. They won’t communicate if a Thrynn is on board, or if you have been friendly with them recently. This can be seen as the Salarians being wary of the Krogan, as they strive for revenge for the genophage. I did think about having the Turians fill this role, but they don’t really count as “gentle & peaceful”. However…

The Spemin -> The Turians

The Spemin are an arrogant race, which can be tied into the Turians “warmonger” attitude – arrogance in their militaristic strength. They are also said to be knowledgeable of the other races in the galaxy, and considering the Turians have been part of the council for a long time, that should fit. They are more likely to respond to you if you go in threatening – which sounded right for a warlike race. This is a trait that fits closer with the Krogan, however… So I may have to replicate this code with the Thrynn somehow. Swapping the Turians for the Krogan won’t work so well, as there is no bad-blood between Turians & Salarians, so it would make for having to change everything around. And 1 inconsistency is better than many!

The Veloxi -> The Volus

The Veloxi are an obsequious race, and highly knowledgeable of all the others. Which is very similar to the trading Volus – always polite to get a deal, and full of information from their galactic trading. The Veloxi are proud of their ties to the ancients in SF – but that can easily be written out for the Volus. Their information on the ancients is also somewhat incorrect in the game. And this can be easily rewritten as the Volus picking up rumours whilst trading – and rumours aren’t always factually correct.

The Minstrels -> The Hanar

The Minstrels are a race of space faring poets, singing songs of history, the ancients and the universe. Change poet for preacher, and ancients for “Enkindlers” and you have the Hanar to a T. This one practically writes itself!

So that is how I plan to change the SF races to those of ME. I’ve got all the main citadel races covered, but a few side races are missing (Elcor, Drell, Vorcha, Quarians, etc…). I may look at adding more, but I think that may be way beyond my skills. But due to the text-heavy nature of the game, I’m sure I can slip in some references to the others somewhere! If you have any clever ideas on how to convert the races that you find superior to mine, please let me know in the comments.

Now I’ve got a plan, it’s just the HEFTY task of changing in-game text and graphics! If anybody is any good with pixel-art, and wants to help out, please let me know.

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!

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!

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.

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
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.

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.