OpenTTD on Dreamcast - Is it possible?

[flasher86]

I want to know whether its difficult, or maybe someone has already made the version for Dreamcast.

I heard that it is easy to make programs for this platform, but I dont have any experience in this.

[Rubidium]

Assuming that the dreamcast can run Linux/BSD as the wikipedia page says, it should be fairly simple... there even seems to be a SDL port for the dreamcast, so it's probably just the compiling that needs to be done.

[stevenh]

A simple search on "Dreamcast" would've returned the following thread:

Dreamcast Port

Which only got a single response at the time, but I thought it was pretty cool.
I had the keyboard and mouse working fine with the game. I also have the Densha-De-Go controller and was going to hack that in to actually control the trains... but never got around to it.

If you want some pointers as to how it was all done then feel free to ask, I don't have enough time right now to explain it all

I'll make the CDI Image that I'd created available tonight. It's on a disk somewhere at home.

[flasher86]

Thats great. I would appreciate if you could publish or send the binary to me. It doesn't have to be the CDI image, actually I would rather want to look how it is done, and so on.

Is it possible to give this compilation additional grf files?

[stevenh]

Yes, you definately can, but system RAM is an issue.. I believe the 32mb limit was very easy to reach.

I was unable to find time last night to get this to you, but I will do it tonight.

update: I've uploaded the image and a lot more information on a blog post here.

[stevenh]

To all the Developers out there... How does one specify a different compiler for strgen vs. the entire system.

If you're cross-compiling for the Dreamcast then you cannot compile strgen and endian checks for the target system and run them locally during the build process?

I've just set up the Dev ISO R4 under cygwin for Dreamcast Dev and want to do everything cleanly this time...

flasher86, do you want to learn how to do it all?

[flasher86]

yes, sorry for not replying. I really want to know how to build my own compilation.

Your CDI image contains only a plain (read: unuseful for education) binary file which I wasnt able to look through, so it would be nice to understand how to compile all this code into one Dreamcast executable.

Also I have a question about save game. Is it supported? I suppose such things are the hardest features to port because DC uses completely different form of storing and accessing data from the memory card. If it would make it any easier, I would suggest that there could be some nice simplification. My idea is to get rid of the whole save/load game window, so that there would be only one slot for saves. It would be enough I think.

I have some experience in Delphi, but as you know it is really simple to compile delphi programs(I click compile and I have exe), in opposite to multiplatform c+ which is just to me hard to understand how to compile any code for such (in this case DC) platform.

Is compilation being done under Windows, linux or it doesnt matter? Are there some special compilers for dc?

and btw, huge thanks for your effort.

[Rubidium]

Cross-compiling OpenTTD is pretty easy if the compiler is gcc; if the system isn't too different from a Unixy system ./configure --host=something. The "something" in there is the full name for your target; i486-linux-gnu is for example my x86 Linux target, i586-pc-msdosdjgpp is for MSDOS binaries, x86_64-linux-gnu for 64 bits Linux, apple-darwin9 for Apple binaries and so forth. Looking at some dcemulation page told me that it might be sh-elf for Dreamcast.

This will require sh-elf-gcc, sh-elf-g++ and friends to exist in your path. Furthermore you need to point to the correct libraries/library-configure-scripts for SDL, libz, libpng and friends.

[stevenh]

Compilation will be done under cygwin. Cygwin is more-or-less a hosted *nix environment under windows, check it out for more information.
Also, grab the ISO from the previous post and mount it under Daemon tools or burn to a CD. Then install it (3 simple steps, installing cygwin is the first) and then we'll get started...

Back to the Devs, The 'typing' of INTs vs. Longs is killing me, it seems the Dreamcast KOS also uses Longs instead of ints:

Code: Select all

typedef unsigned long long uint64;
typedef unsigned long uint32;
typedef unsigned short uint16;
typedef unsigned char uint8;
typedef long long int64;
typedef long int32;
typedef short int16;
typedef char int8;

I believe I now need to overwrite this in the stdafx.h file?
I've currently just converted the actual system include to:

Code: Select all

typedef unsigned long long uint64;
typedef unsigned int uint32;
typedef unsigned short uint16;
typedef unsigned char uint8;
typedef long long int64;
typedef int int32;
typedef short int16;
typedef signed char int8;

[stevenh]

Cross-compiling OpenTTD is pretty easy if the compiler is gcc...

It is, and you just pointed out something very simple... teh environment is set up to have kos-cc/c++ for the compilers, but these are just symlinks to sh-elf-g++...

This will require sh-elf-gcc, sh-elf-g++ and friends to exist in your path. Furthermore you need to point to the correct libraries/library-configure-scripts for SDL, libz, libpng and friends.

It's all there; but I need separate "CFLAGS" for the host and the build... I need to keep digging, as the includes are being dragged into the strgen

Further to this... strgen seems to be using the host build instead of the 'build' build? ... If that makes sense.

I'm currently using:

Code: Select all

./configure --host=sh-elf --os=DREAMCAST

where I've added in DREAMCAST as an allowable 'os' to stop it from trying to use windres.

update: I hadn't installed g++ under cygwin ... meant that strgen/endiancheck were being compiled by the host g++
Progress continues ....



Next question... how are __NDS__, __BEOS__,etc... defined... I can't seem to check for defined(DREAMCAST) or defined(__DREAMCAST__) even if I specifically have -DDREAMCAST in my CFLAGS?

[Rubidium]

CFLAGS="-I/tmp/kos/include -I/tmp/kos/kernel/arch/dreamcast/include" ./configure --os=KOS --host=sh-elf --without-libicu --without-zlib --without-fontconfig --without-png --without-freetype --disable-network --without-allegro --without-sdl --without-threads

That seems to work on my Unix where I've extracted the buildchain and checked out kos from SVN, both into /tmp and without running the proper scripts to set up the environment. Seems to work means that it compiles all files, but fails horribly with linking which might very well be due to the incorrectly set up environment. I've attached the diff of what I have changed to make it compile.

KOS looks surprisingly similar to NDS when looking at the differences w.r.t. the "default" unix tools, like differently named functions or strange definitions for some types.

I've disabled threading as I couldn't find a pthread compatible semaphore header in the KOS checkout and I've disabled the rest because it would've taken my Unix headers.

[stevenh]

Hey, thanks, I was just up to pthreads failing.

sdl, png, zlib all exist and are in the kos-ports hierachy. The only issue is that sdl-config isn't there... so I might have to make my way around that.
Threading can stay disabled for now.

$KOS_LIBS needs to be linked in... along with $KOS_START, a startup.o binary that has the required boot-strap procedures.

Now I sorta understand the build process of OTTD a little better


update: Ok, it's compiled and even 'starting' on the nullDC emulator... I need to sort out a few more things for it later though.
Firstly, there's a patch... a few nasty hacks in there for unimplemented functions.
And then the commandline:

Code: Select all

$ CFLAGS="-I$KOS_BASE/include -I$KOS_BASE/kernel/arch/dreamcast/include 
-I$KOS_BASE/../kos-ports/include/SDL-1.2.9 -I$KOS_BASE/../kos-ports/include/zlib-1.2.3"
LDFLAGS="-lm -lconio $KOS_LIBS"
./configure --os=KOS --without-libicu --without-fontconfig --disable-network 
--without-allegro --without-sdl --without-threads --endian=LE 
--cc-host="kos-cc" --cxx-host="kos-c++"

I had to force the use of the kos-cc/kos-c++ as they are specially built binaries (not symlinks as I'd originally assumed!)
If you're environment is set, then you can just:

Code: Select all

cd objs/release
kos-objcopy -R .stack -O binary openttd ./1ST_READ.BIN

and then use Boot Dreams and build the CDI.

[Rubidium]

The attached file compiles and links OpenTTD on KOS with sdl, zlib and libpng on my environment that I made using http://dcemulation.org/?title=Configuri ... nder_Linux with the exception that I fixed libpng (see the other attachment). Any idea how to get that fix into their subversion repository? I can only find very very stale websites (4+-ish years old).

The __NDS__ and friends are defined by the compiler itself. The KOS compilers do not do that, but require that you define the right information using the CFLAGS (see KOS_CFLAGS).

I've got no idea with what kind of emulator I would be able to test my build binaries or how they should be packaged, so what I've made is completely untested.

[stevenh]

And I'm stuck... the call to fopen(); locks the emulator and I can't seem to get around it... my romdisk is loaded and works in other test programs... maybe the linking process is killing something? I don't know... It knows the file is there, and doesn't try if it's not... but once you try fopen() on a file that exists it just locks up. This kinda thing used to happen when we were out of memory.

I think it's actually the first time we're hitting malloc and it's failing... I know there's an issue with using the default mallocs, etc... but this is inside fopen and it's entirely annoying since you can't look inside it.

Your patch kos_v2.diff seems to have CRLF at the end of the sdl-config and libpng-config and cygwin doesn't like this at all.

update: seems that any call to fopen will lock, but fs_open works... the last thing I need to do is convert them all though .... I wonder where we are introducing the incorrect fopen and how we can overwrite it? The examples show that fopen can work.

Rubidium, did you want a step-by-step to work out how to test it in an emulator? (nullDC currently)

[Rubidium]

Having \r\n (CRLF) at those scripts sounds very odd to me; if it would contain \r then my text editor would basically light up like an christmas tree. Could very well that your patch tool replaces \n with \r\n for text files, like my patch tool replaces \r\n with \n.

The fopen comes from the stdio.h installed by the compiler environment ($KOS_CC_BASE/sh-elf/include/stdio.h). If that shouldn't be used that'd mean more work in stdafx.h and probably #defining fopen and friends to fs_open (and friends). It might furthermore very well be that fopen doesn't work anymore; fopen isn't defined in the kernel and fs_open is, however... fopen is still exported in the kernel without an existing implementation which might be the cause of the crash.

My attempts of getting nulldc to work are currently kind of failing; I haven't found something that ran in it; okay, the openttd-dc.cdi from you blog does something. But I can't, for example, run a self-compiled hello world, like the one in $KOS_BASE/examples. Any pointers in what I should and shouldn't do to start those things is greatly appreciated. I'm using "nullDC 1.0.0 Public Beta 1" because the most recent version (1.0.3) was crying about missing dlls when they did exist and I couldn't figure out how to solve that.

[stevenh]

To get the png example working (the 'hello' code didn't work for me either), you need to follow these steps:

• cd to ./examples/dreamcast/png and make... this will produce example.elf
• then run:

  Code: Select all

  $KOS_OBJCOPY -R .stack -O binary example.elf 1ST_READ.BIN

• you now need Boot Dreams from here
• run boot dreams, point it to the ./examples/dreamcast/png folder and hit process.
• it'll ask: confirm DiscJuggler image? (yes), confirm scramble? (yes), create IP.BIN? (yes) and then choose image location and name.
• you now have a bootable cd image... load it into nullDC and watch the console in the background...

it'll first show a whole lot of debug information, but then you'll see KallistOS somewhere and then information about attached controllers and the like...

Code: Select all

KallistiOS ##version##: Wed Mar 12 23:26:05 PDT 2008
  Cyle@cyle-2bfec5cee0:/usr/local/dc/kos/kos
thd: pre-emption enabled, HZ=100
VREG = 00
VREG = 00
Error in .\dc\mem\sb.cpp:sb_WriteMem:423  -> Write to System Control Regs , not implemented , addr=5f74e4,data=1fffff
maple: active drivers:
    Dreameye (Camera): Camera
    Sound Input Peripheral: Microphone
    PuruPuru (Vibration) Pack: JumpPack
    VMU Driver: Clock, LCD, MemoryCard
    Mouse Driver: Mouse
    Keyboard Driver: Keyboard
    Controller Driver: Controller
  DMA Buffer at ac0c5020
C:BSC_PCTRA = 000A03F0
C:BSC_PCTRA = 000A03F0
vid_set_mode: 640x480 NTSC
VREG = 00
fs_romdisk: mounting image at 0x8c061730 at /rd
maple: attached devices:
  A0: Dreamcast Controller          (01000000: Controller)
  A1: Emulated VMU (02000000: MemoryCard)
  A2: Emulated VMU (02000000: MemoryCard)
  B0: Dreamcast Controller          (01000000: Controller)
pvr: disabling vertical scaling for VGA

This is the same process for openttd... except you'll need to slap romdisk.o in your objs/debug or objs/release (depending on what you're building) and then use the following configure command to have it linked in:

Code: Select all

$ LDFLAGS="$LDFLAGS romdisk.o"
./configure --os=KOS --cc-host="kos-cc" --cxx-host="kos-c++" --with-sdl --with-png
--prefix-dir="" --without-personal-dir --data-dir="rd" --endian=LE --install-dir="/rd"

Now we get to the fopen issue... fs_open is, of course, not the same and not easily swapped in... it'd nearly be nice to abstract the 'file open' mechanisms even further so that we can choose the correct implementation... I don't want to hack up the source tooooooo much though....
I need to shift priorities for this for the next few days... so i'll be working on it when i get the time but not as much as i'd like to be.

as for the \r\n issues... we'll just blame tortoisediff then.



update: it seems that there are a few examples that actually use fopen... i don't know how successfully though. I'm currently hacking up stdafx.h and the linker order to include bits and pieces where necessary but it's all to no avail....

[Rubidium]

I seem to have something somewhat running now But Wine and those tools do not work nicely together and I had to work around quite a few issues. Anyhow...

The fopen problem; KOS really should provide those functions OR it shouldn't provide them at all, not like it is now provide them partially (or should we hack away in the headers of kos-cc?). Hacking around it in a "user unaware" fashion seems currently impossible, which probably means major problems as people are so used to using fopen and such.

How to generate romdisk.o, and is it really needed? By the looks of it it contains openttd.cfg, but that can also be in the cdi image. Or is it some kind of ramdisk?

I've added an updated version of my diff which should only need ./configure --host=kos to compile and link properly. Eventually I'd like to automate the whole process of making the cdi image (I really dislike clicking my mouse), but I'm still searching for the right (unix) tools to do the same as bootdream.

[stevenh]

Right... to create a romdisk (as i don't believe KOS can see the root of the CDI):

• create an empty directory somewhere... call it 'romdisk'
• add in the files that you want the application to see:

  Code: Select all

  /romdisk
      -openttd.cfg
      /data
          opntitle.dat...
          etc...
      /lang
          english.lng

• now go back to the parent folder so you can see the romdisk dir.
• convert to an img and then a linkable object:

  Code: Select all

  $KOS_GENROMFS -f romdisk.img -d romdisk -v
  $KOS_BASE/utils/bin2o/bin2o romdisk.img romdisk_boot romdisk.o

• add the following under the KOS INIT in unix.cpp:

  Code: Select all

  extern uint8 romdisk[];
  KOS_INIT_ROMDISK(romdisk);

• and also spew some fprintf (or enable debugging levels, feel free to tell me how!!) to see where the code gets to. (currently the fopen in FileExists is the killer)

You now have a disk that will be mounted RO at /rd and you can then access all required files... save-games will be an entirely separate issues...
High scores, etc... will need to be disabled appropriately...

I'm curious... what output are you seeing in the console and are you getting past the fopen issue? You never know.. it may be my environment screwing up.

I had to use the follow command line to get rid of the issues with directory structures and it trying to use /usr/local/* :

Code: Select all

./configure --host=kos --prefix-dir="" --data-dir="rd" --without-personal-dir

...I've added in the following code to fios.cpp:

Code: Select all

fprintf(stderr,"Attempting to see if %s [%s] exists...",filename,OTTD2FS(filename));
FILE *f = fopen(OTTD2FS(filename), "r");
if (f == NULL) {
	fprintf(stderr,"NOT FOUND!\n");
	return false;
}
fprintf(stderr,"FOUND IT FOUND IT FOUND IT!\n");
fclose(f);

and I get:

Code: Select all

fs_romdisk: mounting image at 0x8c2b7f60 at /rd
maple: attached devices:
  A0: Dreamcast Controller          (01000000: Controller)
  A1: Emulated VMU (02000000: MemoryCard)
  A2: Emulated VMU (02000000: MemoryCard)
  B0: Dreamcast Controller          (01000000: Controller)
Attempting to see if /openttd.cfg [/openttd.cfg] exists...NOT FOUND!
Attempting to see if /openttd.cfg [/openttd.cfg] exists...NOT FOUND!
Attempting to see if /rd/openttd.cfg [/rd/openttd.cfg] exists...

...it just sits there hanging when the file does actually exist... to me this means that fopen is being called... but then fails afterwards?
I've just used the Dev ISO R3 and it still craps out... so there is something in our build process which is swapping another implementation of fopen? or a call that fopen makes? ... It's really beyond my knowledge.

I do know though, that back in the day, I'd been using cygwin and the Dev ISO and I got it all working... I don't remember switching away from fopen... but I did compile everything by hand (i.e. the source compiling and linking...)... since I had no real knowledge of the build system.
To me, this means that the final link could be killing it... or something to that effect... but I have no idea how.
...and after numerous re-ordering and adding/removing libraries i _cannot_ get past the fopen issue... strangely I can use fopen in the other examples

[Rubidium]

I seem to be having the exact same place of "hanging". It might very well be something with the C++ headers that mess things up for us.

[stevenh]

Rest assured its not the emulator causing out grief; it hangs on real hardware also...

The examples use all standard headers... but we use <cstdlib>,<cstdio>,etc... what do these mean over <stdlib.h>,<stdio.h>,etc....

I can't do any more testing tonight... but I might try and read up on library/header inclusion.