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, butt 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 8x8 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!