Vanilla-Conquer: Nintendo DSi port

mrparrot2 · Nov 29, 2021

Vanilla-Conquer: Nintendo DS(i) port

This is a Nintendo DS port of Command & Conquer: Tiberian Dawn and a DSi port of Command & Conquer: Red Alert based on Vanilla Conquer.

Command & Conquer is a Real Strategy Game released in 1995 developed by Westwood Studios and its trademark is currently owned by Eletronic Arts. Tiberian Dawn was made freeware in 2007, and its sourcecode made public in 2020. Vanilla Conquer is a source port with multi-platform support.

Command & Conquer: Red Alert is another game of its series released in 1996 and has improved gameplay mechanics, AI and graphics.

Supported features:

√ Full campaign support in both Tiberian Dawn and Red Alert.
√ Covert Operations, Counterstrike and Aftermath expansion support.
√ All FMV content is available. Are you picking this up?
√ Sound and Music. Every track is available, and every sound effect too.
√ Skirmish game.
√ Savegames.

Unsupported Features:

x Multiplayer game.
x Dual Screen support. Only the bottom screen is used in game.
x Red Alert and its expansions doesn't work on Nintendo DS: Not enough RAM.

For playing it on your Nintendo DSi, you will need:

A jailbroken Nintendo DSi capable of running .nds ROMs in DSi mode through the memory card.
A memory card with at least 1.4Gb of free space for Tiberian Dawn.
A memory card with at least 2.0Gb of free space for Red Alert.
Assets from DOS Command & Conquer versions: both GDI and Nod discs, with Covert Operations also supported but not necessary.
Assets from Red Alert versions: Both Allied and Soviet discs, with Counterstrike and aftermath supported but not needed.

For playing it on your Nintendo DS, you will need

The DS Expansion Pak. Opera, GBA Movie Player, and EZ flash 3in1 combo are confirmed to work.
A flashcard with a memory card with at least 1.4Gb of free space for Tiberian Dawn.
Assets from DOS Command & Conquer versions: both GDI and Nod discs, with Covert Operations also supported but not necessary.
Red Alert is not supported in DS mode.

Install Tiberian Dawn

For you to play VanillaTD, you must:

Download both GDI and Nod DOS C&C discs.
Create /vanilla-conquer/vanillatd/ path on the root of your flashcard.
Extract the content of both GDI and Nod discs into the folders as follows:

vanilla-conquer/
└── vanillatd/
├── aud.mix
├── conquer.mix
├── desert.mix
├── gdi
│ ├── general.mix
│ ├── movies.mix
│ └── scores.mix
├── local.mix
├── nod
│ ├── general.mix
│ ├── movies.mix
│ └── scores.mix
├── speech.mix
├── sounds.mix
├── temperat.mix
├── transit.mix
└── winter.mix

3 directories, 15 files

Files outside the gdi and nod folders can be retrieved from either disc, but only the GDI files are tested.

Double check if you extracted all files. speech.mix is easy to miss.
Move the vanillatd.nds rom on the root of your memory card.
Play.

Now, if you want to play the covert operations extension:

Download the Covert Operations disc image.
Extract sc-000.mix, sc-001.mix, and local.mix into the vanilla-conquer/vanillatd folder.
Extract general.mix, movies.mix and scores.mix into covertops folder.
The final folder will look like this (from a clean install):

vanilla-conquer/
└── vanillatd
├── aud.mix
├── conquer.mix
├── covertops
│ ├── general.mix
│ ├── movies.mix
│ └── scores.mix
├── desert.mix
├── gdi
│ ├── general.mix
│ ├── movies.mix
│ └── scores.mix
├── local.mix
├── nod
│ ├── general.mix
│ ├── movies.mix
│ └── scores.mix
├── sc-000.mix
├── sc-001.mix
├── speech.mix
├── sounds.mix
├── temperat.mix
├── transit.mix
└── winter.mix

Install Red Alert

Retail Game

Download both Allies and Soviet discs.
On the root of your SD card, create the folder /vanilla-conquer/vanillara/. Then create two more directories: allied and soviet.

From the allies disc, copy the following files:

INSTALL/REDALERT.MIX into /vanilla-conquer/vanillara/
MAIN.MIX into /vanilla-conquer/vanillara/allied/

From the soviet disc, copy:

MAIN.MIX into /vanilla-conquer/vanillara/soviet/.

Finally, copy the ROM vanillara.nds into the root of your SD card and you are done! Just launch the game!
The final working tree should look like this:

vanilla-conquer/
└── vanillara
├── REDALERT.MIX
├── allied
│ └── MAIN.MIX
└── soviet
└── MAIN.MIX

Installing Counterstrike

WARNING: Installing Counterstrike will degrade game's performance, as more things has to be loaded on memory thus leaving less space for the shapes cache (ingame sprites). Only install the extension if you intend to play it.

Download the Counterstrike disc.

Create a new folder named counterstrike inside vanillara. Then copy from the Counterstrike disc:

MAIN.MIX into /vanilla-conquer/vanillara/counterstrike/.
EXPAND.MIX (inside SETUP/INSTALL/CSTRIKE.RTP package) into /vanilla-conquer/vanillara/.

On some systems it may be easier to install the game on DOSBox to retrieve EXPAND.MIX.

The final working tree should look like this:

vanilla-conquer/
└── vanillara
├── REDALERT.MIX
├── EXPAND.MIX
├── allied
│ └── MAIN.MIX
├── soviet
│ └── MAIN.MIX
└── counterstrike
└── MAIN.MIX

Installing Aftermath

WARNING: Installing Aftermath will degrade game's performance even more, as it will require to disable the shapes cache to load the game. Only install the extension if you intend to play it.

Download the Aftermath disc.

Create a new folder named aftermath inside vanillara. Then copy from the Aftermath disc:

MAIN.MIX into /vanilla-conquer/vanillara/aftermath/.
EXPAND2.MIX (inside SETUP/INSTALL/PATCH.RTP package) into /vanilla-conquer/vanillara/.

The final working tree should look like this:

vanilla-conquer/
└── vanillara
├── REDALERT.MIX
├── EXPAND.MIX
├── allied
│ └── MAIN.MIX
├── soviet
│ └── MAIN.MIX
├── counterstrike
│ └── MAIN.MIX
└── aftermath
└── MAIN.MIX

Controls

Currently controls are assigned in the following manner, but it may be changed in the future as better controls are developed. This one tries to concentrate the main functions on the left hand, while the right hand is used to command units.

Touchscreen: Command unit (Mouse LCLICK)
DPAD: Scroll screen.
L: Cancel selection/action (Mouse RCLICK).
B: Force attack (CTRL).
A: Force trample (ALT).
X: Area Guard (G).
Y: Scatter Units (X).
R: Move viewport to Construction Yard (H).
L + DPAD: Select Team #.
B + L + DPAD: Assign Team #.

Bugs

Report bugs on the issues page in github.

CrashMidnick · Jul 19, 2022

I missed that port... Just tested it and works very very well. Thank you so much and good job !

mrparrot2 · Jul 29, 2022

Command & Conquer: Red Alert ROM is now available!

CrashMidnick · Jul 29, 2022

mrparrot2 said:
Command & Conquer: Red Alert ROM is now available!

Thanks you very much. I will test it tomorrow

This is a nice present for the DSi !
Question about "degrade game's performance" : is that possible to make a standalone .nds for each game in a given folder ? This way we can have all extension without this limit ?

CrashMidnick · Jul 29, 2022

Well... I could not resist

Working great !

mrparrot2 · Jul 29, 2022

CrashMidnick said:
Thanks you very much. I will test it tomorrow This is a nice present for the DSi !
Question about "degrade game's performance" : is that possible to make a standalone .nds for each game in a given folder ? This way we can have all extension without this limit ?

I could do that, yes, but I really do not want to maintain multiple ROMs for the same game.

However, I could try to patch the game to only load CS or AM according to a variable in REDALERT.INI.

Indy13 · Aug 3, 2022

Very cool port, i've tested it on n3ds with twl++ it works like a charm but on nds lite with expansion ram it doesn't work, i've tested it with a old hbmenu, the latest one, ysmenu and of course the original kernel of my r4 but nothing happens except white screen or shutting down the console.

mrparrot2 · Aug 3, 2022

Indy13 said:
Very cool port, i've tested it on n3ds with twl++ it works like a charm but on nds lite with expansion ram it doesn't work, i've tested it with a old hbmenu, the latest one, ysmenu and of course the original kernel of my r4 but nothing happens except white screen or shutting down the console.

This means that extra code is necessary in order to support the expansion pak. Is there any documentation about It?

Indy13 · Aug 3, 2022

mrparrot2 said:
This means that extra code is necessary in order to support the expansion pak. Is there any documentation about It?

Maybe @FAST6191 can give you some links to dig it and maybe @RocketRobz can help you, TWL++ support EZFlash 3in1 expansion pak : https://github.com/DS-Homebrew/TWiLightMenu/commit/485dcfe02d9ec94ff82189b8ebea75d1b91c5445

You can have a look here : https://wiki.gbatemp.net/wiki/3_in_1_Expansion_Pack_for_EZ-Flash_V

FAST6191 · Aug 3, 2022

mrparrot2 said:
This means that extra code is necessary in order to support the expansion pak. Is there any documentation about It?

Two main approaches, possibly three.

The main homebrew option for expansion pack RAM on the DS is "Lick's RAM API". https://forum.gbadev.org/viewtopic.php?t=13023

You might alternatively be able to use the code provided for the EZFlash 3 in 1. As above https://wiki.gbatemp.net/wiki/3_in_1_Expansion_Pack_for_EZ-Flash_V contains a list of things that use it, and each of those/one of those might have copies of the RAM library or indeed modified versions as well as examples using it.

The third method would be that the EZ3, EZ4 and such are variously open source at this point so you could learn the access protocols from those and generate your own methods.

mrparrot2 · Aug 3, 2022

FAST6191 said:
Two main approaches, possibly three.

The main homebrew option for expansion pack RAM on the DS is "Lick's RAM API". https://forum.gbadev.org/viewtopic.php?t=13023

You might alternatively be able to use the code provided for the EZFlash 3 in 1. As above https://wiki.gbatemp.net/wiki/3_in_1_Expansion_Pack_for_EZ-Flash_V contains a list of things that use it, and each of those/one of those might have copies of the RAM library or indeed modified versions as well as examples using it.

The third method would be that the EZ3, EZ4 and such are variously open source at this point so you could learn the access protocols from those and generate your own methods.

Lick's API download is broken. I found a version here but I don' t know if this is the most recent one. https://devkitpro.org/viewtopic.php?t=2986

Furthermore, I don't have a DS lite nor any of the expansion paks. Is there a way to emulate the expansion pak behavior in DSi?

As for the game concern, this is where the game spends most of its allocations: https://github.com/giulianobelinass...42bcac617228c03497ea001/common/mixfile.h#L596

This is where it caches the MIX filesystem. I think if I move this allocation to the expanison pak the game will be able to run, assuming we remove the RAM check from here https://github.com/giulianobelinass...7228c03497ea001/tiberiandawn/startup.cpp#L208 and here https://github.com/giulianobelinass...ac617228c03497ea001/redalert/startup.cpp#L285

FAST6191 · Aug 3, 2022

I have only played with the emulate GBA aspects but I believe desmume has various GBA slot/slot 2 options available here, should have a GDB bridge as well that you can use for debugging if you wanted that (works even better with debug flags left in things).

I had a copy of the gbadev link and others saved it seems so I have what I believe to be the current version attached. Have not compared it myself to the later page of gbadev suggestion of http://pineight.com/ds/#memtestARM which contains it raw in the source directory but that might also be worth comparing to.

As far as what to allocate where and where to point/remove checks then you would know way better than I on that one.
If it is a cache system and read only (at least on a per level basis) you might also be write it to the NOR section of whatever flash carts and have it read that directly (32 megs of GBA cart being nicely in if the memory bus even on the DS) to get a few more people onboard.

CrashMidnick · Aug 3, 2022

FAST6191 said:
Have not compared it myself to the later page of gbadev suggestion of http://pineight.com/ds/#memtestARM which contains it raw in the source directory but that might also be worth comparing to.

AFAIR, the one in memtest is the latest.

mrparrot2 · Aug 3, 2022

FAST6191 said:
As far as what to allocate where and where to point/remove checks then you would know way better than I on that one.
If it is a cache system and read only (at least on a per level basis) you might also be write it to the NOR section of whatever flash carts and have it read that directly (32 megs of GBA cart being nicely in if the memory bus even on the DS) to get a few more people onboard.

Can you please elaborate on this "NOR section of whatever flash carts"? Can I just throw a pointer there and read it as if it were RAM?

It is not exactly read-only. The game does some tricks writing into some sprite headers in order to avoid decompressing them each frame (sprites are stored using RLE compression in the filesystem) as long as the system has memory available. That engine I know very well because I had to patch it for it to work with DSi, so I think this is not a big deal. The game also disables this cache if it detects it went out of memory.

Sound effects are cached too, but that is read-only. It has its own compression algorithm but I managed to get the ARM7 to decompress them into a circular buffer. But I wonder how the ARM7 will behave reading stuff from the expansion pak.

But since the major bottleneck in performance of this game is actually its AI and it should not consume much memory, I think this is doable.

FAST6191 · Aug 3, 2022

Not really sure what to go in for here so going for the quick and dirty history+overview as I see it.

GBA cartridges are rather fast compared to standards of the day.

Originally GBA carts were banks of NOR that got increasingly larger and larger.
However that was expensive (especially back then) so instead flash cart makers switched up and copied from NAND (later CF, SD and other such options) to RAM and ran things from there. Flash cart devs (and Nintendo with their web browser for the DS) realised this RAM could be set and used in play to effect better homebrew.
They still tended to however include a bank of NOR for various reasons (in the case of most EZFlash offerings, which will include the popular 3 in 1 expansion pack, both dodging the having to write first and because most things were 16 megs of RAM) which meant when the GBA slot/slot2 of the DS came along you could write the NOR and variously have it appear for the DS, usually said NOR bank was 32 megabytes in size or larger (the max size of standard GBA ROMs, https://mgba.io/2015/10/20/dumping-the-undumped/ for those few that went further though some homebrew, pogoshell being the main example, also went there too but for the purposes of this that is probably way off in the weeds). Can be trickier with some carts though, and things like the EZFlash Omega DE will have options to fake being a GBA cart to dodge that one.
As far as I am aware none of the commercial efforts that ever read the GBA slot did more than the header ( https://wiki.desmume.org/index.php?title=List_of_Nintendo_DS_games_with_GBA_connectivity ) to confirm the game was there while maybe touching its save for relevant aspects of that one (which you can still mess with, see cory1492's pokepatch) but it is still all there and there was a proof of concept done for a ROM hack a while back.

As far as chuck in a pointer and go from there then if the cart is presenting the relevant section then yes. Older NOR based things are easy enough as you write it without a loader and that will be what appears, I mentioned the mode of the Omega DE that fakes it, the 3 in 1 probably will do it as standard, some other stuff might well take some coaxing to display that (though still doable, possibly even in software by you*) as they will tend to present the loader section first.
Whether you have to make a fake GBA header (only a few bytes in the end and probably will help some) being about as complicated as that one gets.
Desmume will do this as well as faking a GBA game is easy enough.

*Rudolph, who did the popular GBA Exploader for the 3 in 1, also supported the EZ4 for a few builds but it had a trouble with bricking things so we tend not to suggest that. If you are not doing any writing and having your users write their own data beforehand then that should not be a problem. I don't think the protocols are open source for this one (the internal function of the EZ4 to fake GBA games being a tricky thing that needed you in DS mode that has since been removed) but should be reasonably similar to the EZ3 and 3 in 1 ones https://github.com/ez-flash

The NOR thing was more of an offhand remark though. The RAM approach would be the standard one opted for in most homebrew discussions/circles.

Technicmaster0 · Aug 4, 2022

I think that it would be easiest to stick to the RAM API.
The only "RAM expansion" beeing made today is the EZ Flash OMEGA Definitive Edition as far as I know. It has 28MB of RAM. But you might want to support the official RAM expansion, that one has only 8MB.
Anyways. I can test the Slot-2 RAM builds if you decide to make them.

mrparrot2 · Aug 4, 2022

So I tried to get it to work on DeSmuME but it always fail on `fatInitDefault` regardless if I use R4 or MPCF Flash Card. The emulator is correctly detecting the directories because I see echo messages of it scanning the directories and finding the files. (Windows DeSmuME 0.9.12 running on OpenSUSE Tumbleweed via Wine 7.10).

MelonDS works without any problems, but it doesn't support any kind of memory expansion.

So unless someone assert that fatfs is correctly working on DeSmuME I can only provide instructions for someone to add support for the Expansion Pak. I can teach how to build the game and point what can be patched, but building a ROM blindly for someone else to test is something that I really do not want to do.

Indy13 · Aug 5, 2022

mrparrot2 said:
So unless someone assert that fatfs is correctly working on DeSmuME I can only provide instructions for someone to add support for the Expansion Pak. I can teach how to build the game and point what can be patched, but building a ROM blindly for someone else to test is something that I really do not want to do.

PM sent

mrparrot2 · Aug 8, 2022

So, the newest version of MelonDS supports the GBA memory expansion.

TD launches with it, but without sound effects, mouse cursor, nor fonts. Red Alert complains that REDALERT.MIX is corrupt, but the same file boots correctly if I set the emulator to DSi mode, which forces the game to allocate memory on-board. After some analysis I found that some addresses seems not to be writable on the memory expansion pak.

Preloading the file LOCAL.MIX at address 0x9000000:
- Filesize: 74489 bytes
- Allocated bytes 74492 (I always 4-bytes align)
=> addresses ranges from 0x9000000 to 0x90122FC

Then I noticed that the file's CRC didn't match, so I did the following experiment:
- Load file on address 0x9000000 (expansion pak) using fread.
- Load file on address provided by malloc (default on-board RAM) using fread.
- Found out that from 0x9011EF8 onward the bytes doesn't match the onboard RAM counterpart anymore. Those always read 0xFF.
- Writing to those address and reading them has no effect (8 bit writes, 16 bit writes, ...), always returning 0xFF.

This means that the memory at the expansion pak isn't contiguous, but I need it to be. On the other hand, CONQUER.MIX which is 2MB size loads correctly, so there are contiguous addresses big enough to support the files.

Any ideas of how do I solve this?

[Edit]
I found out that MelonDS discards any 8-bit writes to address 0x80000000 to 0x0A000000. Therefore I must 16-bit burst the files content. fread is simply not reliable enough.

mrparrot2 · Aug 9, 2022

Here is a version of VanillaTD that somewhat works with the Opera expansion pak. It may work with other expansions, but those aren't emulated by MelonDS.

What doesn't work:
- Shape cache (every sprite sheet will be decompressed each frame. Performance hit)
- Sounds effects (ARM7 doesn't seems to like reading from the expansion pak while the ARM9 is doing so).
- Button text (I suspect that it is VRAM discarding 8-bit write's fault. DSi seems fine with those).

I am concerned that fixing the sound effects will take a lot of effort and probably I will do that last, if I will ever do that. I designed the sound engine of the game to run completely asynchronously with the ARM9, so some sort of AUD cache will have to be implemented on ARM9 side for the sound effects to work.

OTOH, Red Alert doesn't boot. It still complains about corrupt files. But I don't think it will ever work with the Opera expansion, as RA requires 15Mb of RAM to work and I already did some footprint reduction to make it run on DSi.

Vanilla-Conquer: Nintendo DSi port

Well-Known Member