OpenTTD on Dreamcast - Is it possible?

[Rubidium]

cstdio basically means include stdio.h and do some magic on it. Including stdio.h instead of cstdio doesn't make much sense because virtually any other C++ header includes cstdio and thus does the same as cstdio with respect to the magic.

Some google-ing makes me think we might need to link with newlib, but... can't try that now

Update: linking to a newlib doesn't seem to help.

[stevenh]

Code: Select all

#include <kos.h>
#include <arch/arch.h>
KOS_INIT_FLAGS(INIT_DEFAULT | INIT_MALLOCSTATS);
extern uint8 romdisk[]; KOS_INIT_ROMDISK(romdisk);

bool FileExists(const char *filename) {
	printf("Attempting to see if %s exists...",filename);
	FILE *f = fopen(filename, "r");
	if (f == NULL) {
		fprintf(stderr,"NOT FOUND!\n");
		return true;
	} else printf("FOUND IT FOUND IT FOUND IT!\n");
	fclose(f);
	return true;
}
int main(int argc, char* argv[]) {
	int ret;
	printf("testing...\n");
	FileExists("/openttd.cfg");
	FileExists("/rd/openttd.cfg");
	printf("testing...finished\n");
	while (1) printf(".");
	return ret;
}

...still locks up... I compiled with:

Code: Select all

kos-c++ $KOS_CFLAGS -o main.o ../objs/release/romdisk.o main.cpp -DKOS $KOS_LDFLAGS $KOS_LIBS
kos-objcopy -R .stack -O binary main.o 1ST_READ.BIN

and nothing... so to me, this means C++ can't handle fopen(..); correctly and we're doomed....
unless of course it's back down to our linking and we're missing something.

[stevenh]

this deserves a double post....
I was screwing around to see if I could see if the /cd/IP.BIN file existed, as I'd worked out yesterday that the cd-rom could be read through /cd/...
And so, I used:

Code: Select all

int main(int argc, char* argv[])
{
	int ret;char buffer[128];
	printf("testing...\n");
	FileExists("/openttd.cfg");
	FileExists("/cd/ip.bin");
	FileExists("/cd/IP.BIN");
	FileExists("/rd/openttd.cfg");
	FILE *f = fopen("/rd/openttd.cfg","rb");
	fread (buffer,1,127,f);
	fprintf(stderr,"cfg:%s",buffer);
	fclose(f);
	free(buffer);
	printf("testing...finished\n");
	while (1) {}
	return ret;
}

and got:

Code: Select all

testing...
NOT FOUND!
fs_iso9660: disc change detected
  (joliet level 3 extensions detected)
Attempting to see if /openttd.cfg exists...Attempting to see if /cd/ip.bin exist
s...FOUND IT FOUND IT FOUND IT!
Attempting to see if /cd/IP.BIN exists...FOUND IT FOUND IT FOUND IT!
Attempting to see if /rd/openttd.cfg exists...FOUND IT FOUND IT FOUND IT!
cfg:
[misc]
display_opt = SHOW_STATION_NAMES|SHOW_SIGNS|FULL_ANIMATION|FULL_DETAIL|WAYPOINTS

It seems to initialise the iso_9660 driver and then the romdisk comes to life? I have no idea... I shall point this out to the KOS devs (if I can find them)

hah..

update: attempting to use this theory in the main trunk isn't working though... the hacking conitnues.. later.

[Rubidium]

What about only using the /cd? That's the directory made with BootDreams, right? Because if that works I don't see a real point in having a /rd.

And is it possible to load the iso9660 driver yourself? Might (or might not) help.

To make a "proper" testcase you should #include <cstdio> as that mangles some of the fopen related functions.

[stevenh]

Code: Select all

///#include <kos.h>
	#include <cstdio>
	#include <cstddef>
	#include <cstring>
	#include <cstdlib>
	#include <climits>
#include <arch/arch.h>
KOS_INIT_FLAGS(INIT_DEFAULT | INIT_MALLOCSTATS);
extern uint8 romdisk[]; KOS_INIT_ROMDISK(romdisk);

bool FileExists(const char *filename) {
   printf("Attempting to see if %s exists...",filename);
   FILE *f = fopen(filename, "r");
   if (f == NULL) {
      fprintf(stderr,"NOT FOUND!\n");
      return true;
   } else printf("FOUND IT FOUND IT FOUND IT!\n");
   fclose(f);
   return true;
}
int main(int argc, char* argv[]) {
   int ret;
   printf("testing...\n");
   FileExists("/openttd.cfg");
   FileExists("/rd/openttd.cfg");
   printf("testing...finished\n");
   while (1) {} //printf(".");
   return ret;
}

works



i hereby entirely give up on fopen(..);... it hates me and I hate it.

[stevenh]

This is nothing short of WTF!?!?!...
A simple printf(...); at the start of the unix.cpp:main(..); will allow everything to continue with fopen();
I can't explain why.. but it just then works.

Attached is a diff and the romdisk.o has been updated with gfx resources and a config with invalid GRFs in it

Here's the latest progress:

Code: Select all

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 ac940260
C:BSC_PCTRA = 000A03F0
C:BSC_PCTRA = 000A03F0
vid_set_mode: 640x480IL NTSC
VREG = 03
fs_romdisk: mounting image at 0x8c27b0e0 at /rd
maple: attached devices:
  A0: Dreamcast Controller          (01000000: Controller)
WELCOME TO OpenTTD FOR THE DREAMCAST d00d!
ini: ignoring invalid NewGRF 'jpset_bldw.GRF': not found

And then it stops.. in the diff you'll see I had to comment out delete ini; from settings.cpp... it seems the 'delete' operator locks the system next

i'm out for the weekend, so mr.rubidium, feel free to hack at your leisure

note: that if the game would usually close after an error, i.e. if a language pack wasn't found, that the emulator will simply loop as KOS restarts the whole system once the main function rerturns.

[Rubidium]

I agree that the printf is WTF-ish. I've played a little more with the port and your diff. First of all the stat function thinks that the files on /rd and /cd aren't regular files but character devices. This basically meant that it couldn't find any files. Secondly OpenTTD is almost instantaniously out of memory when having a romdisk and showing the intro screen. Once I removed the intro screen and moved all the important stuff to the CD-rom (made with bootdreams) it showed the intro screen just fine for a few minutes (until I got bored and closed it).

At the moment I've got no clue how to control the game; none of my keyboard keys seem to do anything and my mouse doesn't work either. I guess that probably needs some work on the SDL side, although I failed to influence some other programs running in the emulator using keystrokes/the mouse.

[stevenh]

Rubidium,
Would you be able to post your latest diff? What did you do to get the game to load further? I imagine something was causing another freeze?

Also, as for keyboard and mouse input, that should well be up to the emulator to work out... I haven't checked to see if the relevant plugins exist for nullDC. but am sure one of them will sort it out.

Also, what editor did you use to insert files into the CDI?

All seemingly 'special' issues aside, this seems to have been a much more pleasant porting experience than last time.

[Rubidium]

What did you do to get the game to load further? I imagine something was causing another freeze?

I removed the romdisk as the romdisk seems to be eating away "our" precious memory. So now everything needs to be in the CDI image.

I've used bootdreams to create a working CDI. Just copy 1ST_READ.BIN to <svn>/bin/ and place the Transport Tycoon .GRF files and sample.cat in <svn>/bin/data/. Then point to the <svn>/bin/ directory in bootdreams and let it create the CDI.

Currently I'm trying to get a set of unix tools to make a valid and especially working CDI image as that vastly simplifies distribution. Bootdreams in Wine isn't doesn't work with enter-enter-enter-enter as then it crashes due to a too long filename. For some reason it pads a gazillion whitespaces after the proposed filename. However, I'm failing to find a howto that doesn't require me to burn something to a CD or to use applications via Wine.

Great to see that you found someone to fix the libpng issue!

Oh, and ./configure --host=kos should work when you've set up your environment.

[VasiliyRS]

Hello guys, can you update Dreamcast port to latest release ?

[Lordmwa]

The answer is 99.99% certain to be no for a number of reasons:

1) The last post here was 3 and a half years ago, a hell of a lot has changed in openttd since then

2) It appears that it wasnt working back then so just bumping the trunk will be useless

3) This project died for a reason, yes it was a laugh to try and get openttd on an old console but there was no point in it, it will not be anywhere near as playable on the dreamcast as it is on the pc

[FLHerne]

Agreed. I can confirm that OTTD, even with small maps, is barely playable with 64MB of RAM. Dreamcasts have even less than that, so even if OTTD *worked*, it wouldn't be *playable* to any meaningful extent. While I agree strongly with running things on ancient hardware just for the sake of it, it seems a bit pointless to ask the devs to waste time on it - they probably have more useful things to do. Go ahead and try to do it yourself if you want, but the devs should probably work on platforms that are actually useful. .

[stevenh]

Hello guys, can you update Dreamcast port to latest release ?

Even if I had the time I wouldn't bother... as everyone has so rightly indicated: the Dreamcast is dead.
I do still love my Dreamcast console... Densha-de-go with it's controller is great fun... but with 16mb RAM + 8mb GPU RAM you're dreaming.

OTTD has evolved into something amazing and I instead urge you to play with the latest sets and features in 1920x1080 glory.