External palette files: use -p [type:]filename.[type:] can be bcp, psp, or gpl. (Other formats may become available later.)If the type is omitted, bcp is assumed.

bcp binary coded palette with the same format as the palette in a PCX file: 256 triples of red, green and blue encoded in bytes.psp the palette format output by Paintshop Progpl the palette format output by The GIMP.

Than you OzTrans and planetmaker for the extra info. Will have a go at seeing if I can find the crash date in the exe in a hex editor and try to change that tomorrow.

Unfortunately, my knowledge of coding is VERY meager, and my knowledge of DOS coding is non-existant.If you asked me to mod World of Warcraft I could do it, which I have but... Decoding a DOS game, I have absolutely no idea how. We have a lot of people who reverse engineered the TTD client, and a lot of people who rewrote the game into OpenTTD, one of them may have an idea?

If I could have done it myself, I would have a long time ago. I am not asking for help because I am lazy, but because we could unlock a fully playable pre-release version of TTO, a true treasure in the development process of our lovable Transport Tycoon.

i know this is, old but i wanna know... did anyone had sum luck with passing 1932?

In the almost nine years that you've been waiting for somebody else to fix this for you, while bemoaning that you don't have the skills to do it yourself, you could have attended college, obtained a PhD in computer programming, reversed engineered the program and released your own patch. And probably done a bunch more awesome things, including becoming a contributor to TTO/TTD/TTDPatch/OpenTTD.

There is a point where you stop waiting for others to do for you, and you start finding your own way.

Unfortunately, my knowledge of coding is VERY meager, and my knowledge of DOS coding is non-existant.If you asked me to mod World of Warcraft I could do it, which I have but... Decoding a DOS game, I have absolutely no idea how. We have a lot of people who reverse engineered the TTD client, and a lot of people who rewrote the game into OpenTTD, one of them may have an idea?

If I could have done it myself, I would have a long time ago. I am not asking for help because I am lazy, but because we could unlock a fully playable pre-release version of TTO, a true treasure in the development process of our lovable Transport Tycoon.

i know this is, old but i wanna know... did anyone had sum luck with passing 1932?

In the almost nine years that you've been waiting for somebody else to fix this for you, while bemoaning that you don't have the skills to do it yourself, you could have attended college, obtained a PhD in computer programming, reversed engineered the program and released your own patch. And probably done a bunch more awesome things, including becoming a contributor to TTO/TTD/TTDPatch/OpenTTD.

There is a point where you stop waiting for others to do for you, and you start finding your own way.

Well I've always been horrible at Math, and my job is far away from reverse engineering DOS coding.But really, I am amazed it's been nine years...

Anybody can improve themselves, if they choose to do so. In 2009 I knew nothing at all about GRFCodec, sprites or building a NewGRF. Today I still don't know much at all, but in that time in-between I've managed to learn how to fix and modify a few NewGRFs from other people, and release a few of my own.

Very few people in this world have true talent. The rest of us have to fake it and keep educating ourselves until we are competent.

I have tried to get Math, believe me.. It just never worked out. Some people get it, other's don't.

As with any skill you're trying to learn, at first you will suck, but after a lot of practice you will improve. For some people it is just quicker with math. As someone who is relatively math-minded it also took me a while to understand stuff (higher order differential equations, WTF) but after a lot of studying it eventually clicks

I came across another interesting screenshot I thought was worth sharing. It's a scan from issue 17 of a games magazine called Edge, published in February 1995. Note the different-looking small airport and bus terminals!

This means that there are at least two unknown pre-release versions of the game that were sent to press for review.

2004 - George W. Bush is re-elected, Facebook is launched, Taipei 101 becomes the tallest building on Earth, Gurluas2000 bumps this thread wondering if it's possible to play an old TTO demo past 1932

2005 - Angela Merkel becomes the first female Chancellor of Germany, Youtube is launched, The Deep Impact probe collides its impactor with comet 9P/Tempel, Gurluas2000 bumps this thread demanding more info about an old TTO demo

2006 - Saddam Hussein is executed, Twitter is launched, Pluto is no longer considered a planet, Gurluas2000 is here in this thread to witness more screenshots of the pre-alpha TTO demo

2009 - Barrack Obama elected 44th US president, Burj Khalifa becomes the tallest building on Earth, The mouse genome is fully sequenced

2010 - Haiti is struck by a devastating earthquake, Apple debuts the iPad, scientists trap antimatter, Gurluas2000 bumps this thread proposing hacking an old TTO demo with the sole purpose of playing it past 1932

2011 - Japan is devastated by a 9.0 magnitude earthquake and tsunami, Osama bin Laden is killed in a raid, Global population reaches 7bn, Gurluas2000 continues rallying unwilling community members to help him hack an old TTO demo and reach the ultimate goal of playing it past 1932

2012 - The Diamond Jubilee of Queen Elizabeth II, Windows 8 is released, Nintendo launches the Wii U, The Mayan calendar reaches the end of its current cycle

2013 - A meteor explodes over the Russian city of Chelyabinsk, Birth of a royal baby, The NSA documents are leaked, Launch of the PS4 and Xbox One, Gurluas2000 revisits this thread with a simple message: now is the time to hack an old TTO demo and allow him to play past 1932

2014 - The first gay marriages are held in England and Wales, Google Glass is launched to the public, The new World Trade Center is opened, Laser guns are in naval use

2015 - Queen Elizabeth II is the longest reigning monarch in British history, Windows 10 is released by Microsoft, The first self-regulating artificial heart

2016 - Donald Trump is elected 45th US president, UK referendum on withdrawal from the EU passes, Microchipping of all dogs in England, The mining industry is highly automated, Three-person babies

2017 - Women's March is the biggest single-day protest in American history, US withdraws from the Paris Climate Agreement, Gurluas2000 bumps this thread, wondering whether anyone has perchance decided to hack a 1994 TTO demo to play it past 1932

2182 - humanity has ascended to a higher plane of existence, Gurluas2000' uploaded digital personality is in this thread wondering if anyone happened to hack a centuries old alpha TTO demo and let him play past 1932

_________________

Only dumb people quote themselves, and only the truest retards put such quotes in their forum signatures-Drury

Out of sheer curiosity, I took a brief look at this and poked at it briefly with a disassembler.

The binary is is a 32-bit Phar Lap DOS extended binary; which unfortunately the freeware version of IDA doesn't support at all. Apparently there's an older IDA Freeware 4.1 which was used for TTDPatch that knew what to do with these files, as well as the commercial version though I can't justify $600 dollars for the full version. The EXP (protected mode executable) starts at approximately 0x1711 (near the string "TNTB.EXE"), followed by the string table and a bunch of other data structures following it.

There's annoying little technical documentation on the Phar Lap executable format which makes this a much bigger pain the arse than it needs to be, since if I could just load it up in IDA, it would be relatively easy to find the bits that whacked with a brick. The game itself doesn't crash when the date hits 1/2/33, more specifically it just suddenly exits out to DOS. Internally, based off what little I could get IDA to decompile, the internal code uses the DPMI standard and not the older VCPI standard which is why it (kinda) works under more recent 32-bit Windows machines that can run DOS binaries. Based on my knowledge of DPMI, it's probably just triggering Int 21h AH=4Ch to tell the DPMI server to bugger off and die and dump back to DOS; I was hoping it *actually* crashed since I could just attach a crash debugger and see what happened.

DPMI is exceptionally weird, but in a nutshell, here's how it works. DOS PC's normally operate in 8086-compatible real-mode, and can only access up to 1 MiB of RAM. When you're running with an actual operating system like Windows 3.1/386, 95, or OS/2, the processor is already in protected mode and DOS applications run in Virtual 8086 mode. This is basically a sandbox to allow multiple DOS applications to run side-by-side (old school Windows users may remember when a DOS app died on Windows 3.1/95, it tended to report DPMI errors). For those of us who played DOOM or Duke Nukem 3D, you might remember seeing messages seeing DOS/4GW messages. That was it's DPMI server starting and stopping.

To actually use all the RAM (up to 32-bits worth on a 80386), you have to enter protected mode. This is where things get interesting. If TT-Demo is running in real DOS, it will launch the Phar Lap extender and setup it's own DPMI server to enter protected mode. However, if TT-Demo is running in DOS emulation more (aka, DOSbox, Windows 3.1, etc), it will notice that theirs a DPMI server already present and use that instead. If this is working the way its supposed to, it should be possible to trap DPMI calls in DOSBox, and get the function pointer of when the game decides quit, and then simply walk the backtrace to find the necessary code segments where the exit code is from.

This is complicated by the fact that TT was written in pure assembler, and probably doesn't use standard prologue/epilogue C declarations so most disassemblers are probably going to have a heart attack trying to figure out what's what. Annoying.

Not sure if I'll take this further but this should give some tips if someone else picks this up.

EDIT: Well I just can't leave well enough alone it seems. Right now, I've found and located 5 five different checks to cause the game to not proceed past 1932. Three of these quit immediately to DOS. The other two I found are more evil, they lock the game in a infinite loop and are fairly well hidden (at least against the tools of the time). I can now play to the end of Jan 1932 *but* the game partially hangs at this point. I can move the mouse but nothing else. Fiddling with the time in memory shows there's a check somewhere that seems to lock us in some sort of pause-like mode but I can't click.

Fiddling with the memory, I found that if I set the time back, the game unfreezes, so it's a runtime check. I have managed to set the clock further into the future, and if the game is paused when I do so it runs for a few seconds before hanging. I dunno how much I'll keep fiddling but this is interesting how much Chris went to prevent this demo from being played. I did look into the GRF. The monorail is only partially implemented; a lot of the GRF stuff is MIA.

oh wow nice work, I didn't expect someone with knowledge like you to actually stumble upon this thread at this kind of date

what isn't all that unexpected is how the demo is missing a lot of features, I wonder how much there really is

As far as I can tell, this is probably a late alpha/early beta probably about six months from shipping. Internally, it looks like most of the functionality is there; most of the ship/planes/RV/train meta data is there though the grfcodec failed to pull the vehicle stats, likely due to the offsets just being different so I got garbage in the NRO file.

There are some interesting bits in the code; there is a fair bit of code to initialize and setup networking and serial ports for multiplayer, and it looks like the GUIs exist for creating and placing roads/ship depots/etc. I'm not sure there's any airport type beyond small though, though at least some definition data exists for things like the Boeing 727.

Interesting, there are some references to OS/2 in the code. It wasn't uncommon for developers to use OS/2 even for DOS games because it was possible to run a debugger inline with executable, and it was quite a bit more stable than Windows 3.1 in this role. I've unfortunately run into a bit of a headache though because DOSBox's debugger is annoyingly limited, and the memory map is wonky. Normally, data is basically loaded in a single segment in protected mode, but there appears to be multiple data segments so I can't get cross-references to line up properly.

Internally, it looks like there are two seperate applications which get loaded and unloaded. The first entry point loads TRTITLE.GRF and displays the opening titles, and then a second segment that has all the game data. This could also just be an artifact of linking depending how Chris laid things out in the assembler since hand-written assembler code can throw out most of the rules you get used to when debugging compiled binaries. I was only able to find the loader functions by finding the DPMI interrupts and tracing backwards.

EDIT: Well I slammed into a brick wall. I need a debugger better than the DOSBox monitor which is ... lacking at best in terms of functionality. I *did* manage to get OpenWatcom's debugger to attach to TRANS.EXE, and successfully read and dump memory. Added bonus is OW at least in theory knows about Phar Lap and knows how to interact it. Unfortunately, it looks like that support bitrotted out of OW2; the trap file is present but the debugger shims are missing. I filed a bug upstream, but I'm going to have to get creative if I want to look at this things guts more in-depth. It looks like the stubs are needed even if I ran the debugger on OS/2 which is unfortunate. I might be able to force a "trap to debugger" by hexediting in the int 3 call, but that will have to wait until I get home.

The largest problem is OllyDbg is really meant to be run on Windows applications, and not DOS ones, and it has to attach to a process, not simply act as a static disassembler. The only way I could use this is to setup a 32-bit version of Windows, and given that the original TT-Demo is kinda flakely on Windows to begin with, I rather not add additional variables to the mix. In all likelyhood, I'd probably have to dig out Windows 95/98 to use it, and then I'm stuck in the DOS penalty box which drastically complicates debugging efforts. I might be stuck going down that route though if I want to power on.

I did talk to the OpenWatcom guys, and I got the remote debugger setup, and I now got SOME useful trace info out of TT. The problem though is for full functionality, I need what's known as a trap files for the DPMI server. Without it, I can get crash reports (which is how TTD guys used OllyDbg), but not full debugging. I have the Watcom side of it, but I'm missing the Phar Lap side. Basically, in the world of old-skool DOS, you couldn't just take something like OllyDbg and plug it into any application. Instead you had to have a special shim that wedged itself between the extender (Phar Lap) and your app (TT Demo). That let's you set breakpoints and watchpoints which are stupidly useful (I'll likely need working watchpoints to re-enable non-train play).

The trap server was part of the Phar Lap 386|Extender SDK which appears to have more or less fallen off the internet. There are some newer ones floating, but I probably need a version of the DPMI trap that matches what TT Demo used. I'm not even sure if later TTD used Phar Lap or changed to something else.

That being said, I have isolated some interesting bits of code. Intentionally causing a crash MIGHT get me the magic bits I need to plug into IDA to get everything to line up. I know TTDPatch was originally developed with IDA so I'm probably going down the right path here, but reverse engineering is a black at best, and utter magic at worst. Now that I'm home, I'm going to try and shoehorn in a crash and see if I can grab it with WDC, that should let me get a better idea of the memory layout.

Well. Partial success. Popping an 'int 3' shell into the demo did crash it and I got a trace dump to screen as Phar Lap went belly up. wdw didn't see it though. I might be stuck with the DOSbox debugger but that makes me less than happy :/

Wow, you're a boss I hope this does amount to something, not because I'm gonna start playing the TTO demo but because I love seeing someone work on a really difficult problem, explain their thought process in an interesting way as they work through it, and finally solve it!

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum