Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Entertainment Games IT Technology

Porting Games From Binary 178

Posted by michael from the meaningless-and-time-consuming-are-our-middle-names dept.
CowboyRobot writes "My favorite Slashdot links are those that inspire me to embark on meaningless and time-consuming quests. This is one of them. Two Canadian game developers at Digital Eclipse have a thorough explanation of how to port a game using nothing but the binary stream coming out of the cartridge. They use the TRS-80 and Phantasy Star III as examples."
This discussion has been archived. No new comments can be posted.

Porting Games From Binary More

Porting Games From Binary

Comments Filter:

  • secrets galore.. (Score:3, Funny)

    by grub ( 11606 ) <slashdot@grub.net> on Thursday September 25, 2003 @08:23AM (#7054054) Homepage Journal

    01110100011010000110010100100000011001110110111
    1 0110000101110100011100110110010101100011011110
    00 001000000110011101110101011110010010000001101
    001 01110011001000000110110101111001001000000110
    0100 0110000101100100001011000010000001101000011
    00101 001000000110101101100101011001010111000001
    110011 00100000011011010111100100100000011010000
    1100001 0110111001100100011100110010000001110111
    01100001 011100100110110100100000011010010110111
    000100000 01110111011010010110111001110100011001
    0101110010 00101110

    01100001011100100110010101101110011101 000010000
    001111001011011110111010100100000011001 11011011
    0001100001011001000010000001111001011011 1101110
    10100100000011101000110111101101111011010 110010
    000001110100011010000110010100100000011101 00011
    0100101101101011001010010000001110100011011 1100
    10000001100100011001010110001101101111011001 000
    110010100100000011101000110100001101001011100 11
    00111111001000000011101000101001

  • All my games are so old... (Score:5, Funny)

    by SmirkingRevenge ( 633503 ) on Thursday September 25, 2003 @08:23AM (#7054057)
    They're in unary, you insensitive clod!

  • When Bad means Good (Score:5, Insightful)

    by WebfishUK ( 249858 ) on Thursday September 25, 2003 @08:28AM (#7054083)


    It's this kind of pointless endeavour that gives geeks a bad name.

    It's this kind of pointless endeavour that makes me happy to be a geek.

    Some people climb mountains, other disassemble 8085 binary code.

  • link to the printer-friendly version (Score:5, Informative)

    by mblase ( 200735 ) on Thursday September 25, 2003 @08:29AM (#7054097)
    printer-friendly [acmqueue.com], one page, no ads.

  • Badly researched? (Score:5, Insightful)

    by FyRE666 ( 263011 ) on Thursday September 25, 2003 @08:32AM (#7054123) Homepage
    Unless I'm missing something, this novel idea is complete garbage. Yes, sure you can disassemble the machine code, produce some C code from that and then recompile for a new target CPU but it's not going to work for the vast majority of applications.

    The reason: hardware.

    Even your average 80's arcade machine relies upon custom hardware for virtually everything. The main program spends most of its time simply adjusting registers to control sprites etc, and reading from hardware to detect collisions and so on. This new code you've generated for a new CPU will still expect the same supporting hardware...

    • Re:Badly researched? (Score:4, Insightful)

      by Zan Zu from Eridu ( 165657 ) on Thursday September 25, 2003 @08:53AM (#7054301) Journal

      If you rebuild an executable for system X from a binary dump for system Y, you don't just disassemble it, but you put in macro's for all of the opcodes for system Y. These macro's are the glue that emulate parts of Y's hardware on system X.

      It's comparable to the difference between an interpreted language and a compiled language. An emulator is a virtual machine that interprets opcodes for machine Y and translates them to instructions for machine X on the fly; this solution compiles the tanslations into an executable for machine X once.

      • tanslations

        These are op-codes that, when rearranged, make pretty pictures?

      • Re:Badly researched? (Score:5, Insightful)

        by ivan256 ( 17499 ) * on Thursday September 25, 2003 @11:11AM (#7055502)
        If you rebuild an executable for system X from a binary dump for system Y, you don't just disassemble it, but you put in macro's for all of the opcodes for system Y. These macro's are the glue that emulate parts of Y's hardware on system X.

        That's a dubious claim at best. A rom image is likely to contain device driver calls that set register bits that have no equivalent on other hardware. In order to produce a single device operation, a series of opcodes is likely to be required that is guaranteed not to appear in the same order on all software for the platform, and may not even have an analog on the new platform. That means at the very least you have tailor your macros for every image, if not for sections of an image. In the worst (and most likely) case, procedures and algorithims comprised of hundreds of opcodes and used to manipulate hardware on the original system would be completely invalid on the target, and would have to be implemented completely differently. That's the same thing as porting the software, but with some extra steps added.

        Their example in the article is perfect to illustrate this. After they converted the FM synth codes to sampled PCM data, do you really think the sound code from the original ROM came even remotely close to working? I call bullshit.

        Furthermore, there is no evidence in the article that this project was actually attempted, much less completed. Even if it was, I would bet significant sums of money that their tools wouldn't work to translate other games from Genesis to Gameboy without as much work as went into the tools in the first place. If their techniques ever were to work, it's likely that it would only be while translating between two extremely similar systems. Did anybody with a clue at the ACM read this article before posting it?
        • Uhh, speaking as someone who owns the said version of Phantasy Star III on the Gameboy Advance, I think you're a little off-base. Remember, all custom chips have reliable inputs and outputs, so if you're switching a program over to a system lacking a specific custom chip, it's not very hard to find something with equivalent functionality on the current system or to just hack through it with software. There really isn't a line drawn in the sand between translation and emulation - I'd say that translation's
          • Uhh, speaking as someone who owns the said version of Phantasy Star III on the Gameboy Advance

            I didn't know that owning a video game cartridge implied any knowledge of how it was created. You have no idea if the methods described in this article were used in the creation of the GBA version of the game. I'm willing to bet that if these methods were used, they were only used on a limited number of code sections, labor intesive, and not directly reusable.

            it's not very hard to find something with equivalent

          • Re:Badly researched? (Score:2, Informative)

            by Anonymous Coward
            The article is a load of rot. Externalising everything outside the basic flow control program and saying "here be I/O" is an utterly useless approach. Most games machines run as several programs on custom _processors_, tied together as a full system.

            Remember, all custom chips have reliable inputs and outputs

            Are you kidding? We're not talking about LEGO toys like the IBM PC or Tandy. Machines like the C64 and Amiga have autonomous, cycle-exact digital/analog hybrid custom chips which all have control ov

      • Sounds an aweful lot like emulation to me. I mean, otherwise, ther's an aweful lot of opcode being releated over and over (hence the macros), that the result might be many many times bigger than the original.

        More Bad Research [blat.info]
    • Yes, sure you can disassemble the machine code, produce some C code from that and then recompile for a new target CPU but it's not going to work for the vast majority of applications.

      Decompiling to C must have changed quite a bit since I last tried it, around 10 years ago. If not, it seems like you'd run into nothing *but* problems with platform-specificity.

      That is, the only C decompilers I've tried did in fact take a binary and output C- however, the C was just a bunch of inline assembly statements and
      • Another interesting thing to take into account is that back then there was probably more hand-optimized code (as opposed to compiler-optimized). I don't know how this would affect things, but I imagine it would. Probably hand-optimized code would be less predictable.

        As a side note, I love one-line loops. :-D
    • you will have to rewrite the parts that directly access the hardware into something that C++ or one of the supporting C++ libraries can use. Usually the data can be preserved or converted into something the supported libraries can work with. This is hard because it can be 60% to 90% of the code.

      Either that or you create macros or a virtual machine to handle the hardware access.

      Now a remake can be hard to do, one example is Telengard for Windows [buildingworlds.com] which is based on the old C64 classic game by Avalon Hill.

    • A computer can be thought of as a series of 'boxes within a box'. By that, I mean from the Von Neuman machine running the assembly language instructions, all the way up to the operating system and applications running on it are all just virualizations - emulators of something more complex sitting on top of something simple.

      At the lowest level is the microcode program that is hardcoded into the cpu itself. So, the 'CPU' instructions, as we think of them in an assembly program binary, are really virtualize
    • it is still just a turing machine... one set of inputs+known state=one output only

      Am I missing something? The software will still give it the same appearance, right?

  • Suboptimal resource use (Score:5, Interesting)

    by AllUsernamesAreGone ( 688381 ) on Thursday September 25, 2003 @08:32AM (#7054124)
    One problem that I don't see addressed in the article is the different approaches games use today compared with those on old hardware. For example, on machines where the disparity between CPU and memory speed was not as great as it is today, it was common practice to precalculate many maths-intensive operations into lookup tables (usually in the form of sin tables, cos tables and so on). On a modern processor this level of precalculation can result in slower execution than just working out the maths on the fly, so most games do minimal precalculation of things like maths functions. While it's often the case that speed is not really an issue with old game ports, it would be interesting to see how they would approach the problem of porting and ensuring that the resulting game makes optimal use of the target machine.
    • On the other hand, when the original machine was based on a Z-80, and you're translating it to run on an AthlonXP 3000, perhaps speed won't be an issue? I'd be more worried about clever programmers actually using some of the unintended (undocumented) side effects in the hardware.
    • On a modern processor this level of precalculation can result in slower execution than just working out the maths on the fly

      I doubt that. Precalculating a table of cosine values isn't going to take an appreciable amount of time on modern hardware, and you can be sure that lookups are going to be much faster than calling any actual math routine, even on modern hardware.

      Also, think about this: if the tables are built into the application, and if you replaced the lookups with calls to actual cosine routines,

      • You're overlooking a big bottleneck: memory access. If you precalculate your tables, they have to go into main memory, some time later you use part of a table so in needs to get into cache. If the table is big enough, the prefetch didn't get enough of it or your program does a lot of other work, you'll be constantly fetching in and out of main memory. This takes massive amounts of time compared to actually working it out on the fly unless you can be 100% certain your tables will be in cache all the time (wh
        • Three flaws with this theory.

          1)Old machines had MUCH less memeory than we do now. So they had lookup tables, but those lookup tables were not huge. Rarely more than 1-300 entries.

          2)Old machines had much slower memory buses. Even emulating a pentium 1, they had 66 MHz buses. Nowdays, 300 MHZ buses are common. This extra speed makes up for any loss due to cache coherency problems.

          3)Cache coherency problems only occur on loaded systems. Frequently, that won't be the case.
    • When trying to emulate a classic game, the goal is to emulate everything -- even the bugs, even the inefficient ways it may have done things. So, there may not be an attempt made to optimize the game for modern hardware at all. Just duplicate the inefficient functions of the original to ensure that the final product is as close to the original as possible.

  • It can be useful sometimes (Score:5, Interesting)

    by Anonymous Coward on Thursday September 25, 2003 @08:34AM (#7054133)
    In our lab we sometimes have to reverse-engineer components for which we no longer have documentation. It would be very simple to export the data of a video game cartridge by accessing its ROM module with a binary card reader. The trickier part is to get the offset right so that any fluctuations will be evened out on the oscilator. One could then re-compile the imported code into a new platform similar to what the folks at MAME [slashdot.org] do.

    What we've done is imported "Yars' Revenge" from the Atari 2600 did some elevation emulation, ported the code, and re-compiled to make it work on the Intellivision. We may be selling that cartridge commercially as there is a great need for 8-bit cartridges.

    Which is nice.
    • Elevation emulation might work - if you're lucky. In my experience a process called 'shaving the ROM' leads to more consistent results, especially vis-a-vis surface mounted components. Look it up on Google.

      Or not.

    • Anything like these?

      games 1 [thinkgeek.com]

      games 2 [qvc.com]
    • What we've done is imported "Yars' Revenge" from the Atari 2600 did some elevation emulation, ported the code, and re-compiled to make it work on the Intellivision. We may be selling that cartridge commercially as there is a great need for 8-bit cartridges.

      Pardon me, but I think one of two things have happened here.

      1) The esteemed moderation pool (of which I have occasionally found my self a member) missed a clearly +1, Funny post (great need for 8-bit Intellivision carts?) and modded it as Insightful/In

  • Hm.. (Score:1, Funny)

    by Anonymous Coward
    What? Someone found yet another way to make a copy of 'Rygar'?

    Damnable geeks.

  • Sweeet... (Score:3, Interesting)

    by TopShelf ( 92521 ) * on Thursday September 25, 2003 @08:36AM (#7054165) Homepage Journal
    Can't wait to play true classics [cstone.net] on my Pentium 4...
    • MAN does that bring back C64 memories.

      You should have seen the grin on my face the instant I rolled over the link and saw the filename in the status bar.

      Let Baldur's Gate, Neverwinter Nights, Morrowind, and all the rest KNEEL and COWER before the ONE TRUE RPG!
    • TRS-80? I want Megabug! Was anyone else addicted to that? Polaris was cool too.


      Seriously, though, I first started programming on one of those, with BASIC, and a tape drive when I was 6 years old. I would be awesome if I could play the games from it again on my Athlon.

      • But.. you can!

        Check out:

        Ira Klang's TRS-80 Central:
        http://www.trs-80.com/

        TRS-80 Emulators:
        http://www.vavasour.ca/jeff/trs80.html
        http://discover-net.net/~dmkeil/

        TRS-80 Software:
        http://home.planet.nl/~srahman/trs80_so ft.htm

        (I was a TRS-80 user from way back as well... published games under the Pacific Software name back in the early 80s.)

  • Article text (Score:4, Informative)

    by Anonymous Coward on Thursday September 25, 2003 @08:42AM (#7054206)
    Server is spewing intermitant database errors so:

    What if you have to port a program, but all you have is a binary?
    Bridging the Gap
    Typical software development involves one of two processes: the creation of new software to fit particular requirements or the modification (maintenance) of old software to fix problems or fit new requirements. These transformations happen at the source-code level. But what if the problem is not the maintenance of old software but the need to create a functional duplicate of the original? And what if the source code is no longer available?

    This exact problem arises when trying to reproduce the original play of old arcade games on modern devices. The game play is so well known that anything short of the original is unacceptable. Often the source code is available, but it may be incomplete and may not cover all of the patches that were added to later production models. In addition, it is too expensive to provide copies of the original hardware.

    Providing faithful emulations of video games (and old home computers) is our primary experience with this process. But the same techniques can be applied to other areas. Aging hardware and software can be replaced by new hardware with a completely compatible program.

    BRIDGING THE GAP
    The general problem can be expressed as "bridging the semantic gap." You must create a program that precisely maps the meaning of the original program onto a host system. Primarily this means an interpreter of some kind for the target processor's instruction set, but one must also deal with I/O (input/output) devices. Such an interpreter is known as an emulator. (See "The TRS-80: A Simple Emulator" on page 54 of this article.) If the program is automatically converted to a different language, it is called a translation.

    Why are we tackling the problem at such a low level? Mainly to achieve the highest fidelity possible to the original. Emulation is about mapping semantics. The semantics of hardware are usually well documented either by circuit diagrams or chip-specification documents. Internal layers inside software are usually designed to much looser standards, so it is unlikely that specification documents--if they exist--completely describe the behavior. In fact, the software itself is the most authoritative description available. It is true that chip specifications are not always complete or accurate, but chips are reused and over time the deviations become widely known.

    The semantic gap between the target and host systems is not purely an abstraction. It can be quantified as follows: G = number of host instructions to emulate one target instruction. Given G and some idea of the relative speeds of the host and target system, you can quickly decide if emulation is feasible. The problem here is that the value of G is a function of an actual emulator. A rule of thumb is that G is at least 10, but practically speaking, 10 is lower-bound for systems that are quite similar. Although time is usually the overriding concern, there is an analogue for a semantic gap in terms of storage space.

    Figure 1

    Emulation and translation start with the same inputs (the ROM data and the hardware documentation) and produce the same result: a copy of the original running on a PC. The difference comes in how the ROM data is handled. For the emulator, it is simply a parameter to the program. For the translated version, the ROM is converted and compiled into the executable.

    The semantic space gap is the ratio of the size of the host program to the size of the target program. For an emulator, the host program size is broken into two pieces: the host's representation of the target program and the emulator code and associated tables. Unless the host and target are radically different, there is little to be gained by significant changes to the representation of storage. Thus, if the emulator code is ignored, the semantic space gap is typically exactly one.

    Intuitively, the value of G really depends on how differe

  • Inspiring Slashdot links (Score:1, Funny)

    by Anonymous Coward
    inspire me to embark on meaningless and time-consuming quests

    This is as close to having a girlfriend as the average Slashdotter can get.

  • Gain v Pain.. (Score:5, Insightful)

    by adeyadey ( 678765 ) on Thursday September 25, 2003 @08:45AM (#7054227) Journal
    This methos is of genuine value for cases of applications where the source has been lost and needs alteration - for just running invaders/pacman/etc an emulator is just as good - since you have to slow things down to run at 100% original speed. The best emulators really o absolutely emulate every facet of the original CPU & hardware - the VICE C64/PET/VIC emulator runs on a 1mhz interupt, that, as I understand it, emulates all the states of the 6502 processor exactly. If you convert bin->asm->c you would still need to put hold-states in the C code to make it step at exactly that speed, cycle for cycle. Where this method would be better than MAME/VICE style emulation is when you need to patch the code- to upgrade it, fix bugs etc. This applies more to non-game type code where old (and failing) hardware/software needs to be migrated to new hardware, maybe with minor code changes.. And if you are not tied to executing at a set pace, then bin->asm->c is a really cool thing to have.

  • Wow, those guys ARE good. They even ported their company web server to a TRS-80.

    But some areas of the code still need work:

    int fork() { return 1; }

  • Let's see... (Score:5, Insightful)

    by Wolfier ( 94144 ) on Thursday September 25, 2003 @08:51AM (#7054284)
    Emulation:
    *Each assembly instruction interpreted by an interpreter
    *Compile once to run N applications

    "Translation":
    *Each assembly instruction translated to a C macro
    *Compile N times to run N applications

    Looks like emulation wins. If an emulator has JIT then "translation" losses its only speed advantage too.

  • Idea depreciated: DUMB (Score:5, Interesting)

    by Creepy Crawler ( 680178 ) on Thursday September 25, 2003 @08:51AM (#7054285)
    For console video games, why in the hell would you translate the language? All the consoles had funky hardware that games used one time or another.

    For 1, the NES uses mappers to display games. On emulators, many mappers are not supported. NES game producers also put hard-coded timings in games. So if your recompiled game isnt the exact same multiplier of clock frequencies, many will exhibit starnge behavior or just lock up.

    Next, the SNES had pretty much basic AppleII GS hardware with the exception of the 32 channel sound card. It had a sound cpu which could hold 64k code along with samples. A problem that the makers of ZSnes had was determining the random noise generators formula. On the older games like Chrono Trigger, the wind would sound like square waves going up and down. That sounds fun, compiling a game when you find out that the hardware emulation controls wernt right.

    Jump to PS2. Who would have thought that a comuter like that would be available to the public? One that has little GFX ram but a huge bus. Not to mention a full FS to "compile". What pitfalls occur in the 3D hardware?

    Emulation is still better as it offers a replacable shim to modify and add features. You can also use other emulators.
    • The SPC-700 does 8 channels, not 32.
      • I know. The default AppleII gs hardware is a SNES with a 32 channel sound board. The SNES was a Sony SPC700 chip that handled only 8 channels and 64k ram.

        Sorry for the confusion.
        • Ah, my mistake, sorry... I wasn't familiar with the AppleII gs' hardware and thought you referred to the SNES.

        • The Apple IIGS and Super NES had the same CPU (65c816), but that's it; their I/O architectures were NOTHING like each other. Apple IIGS and Super NES video weren't even close, and neither were their sound chips. The IIGS had a memory-mapped dumb frame buffer; the Super NES's video was tile-based, somewhere between that of the Sega Genesis and that of the Game Boy Advance, and VRAM was accessed through a couple I/O ports.

    • These people [digitaleclipse.com] are the ones who translated Phantasy Star games to the GBA.

      The GBA does not have the power to emulate the Mega Drive (Genesis) even with a JIT compiler. Hence, a different method would be needed. Either simulation, recompilation, or translation. Translation was the best option given what they had to work with.

      Emulation is wonderful and all but it certanly doesn't work in all situations.

      FYI, I believe that PS1 was emulated and PS2,3 were translated in Phantasy Star Collection. They're not
      • >>FYI, I believe that PS1 was emulated and PS2,3 were translated in Phantasy Star Collection.

        Ambigous. Do you mean that the PS1 code was emulated in the PS2? If so, you're wrong. There's 2 main CPU's in the PS2. One is for PS1 and a bios-like chip to interface to the main CPU to make the PS2 rom calls. They also use this shim to add anti-aliasing.

    • Re:Idea depreciated: DUMB (Score:1, Informative)

      by Anonymous Coward
      This Link [applenews.com.br] dispells the myth about the SNES using AppleIIgs hardware. Kujo2K
    • For console video games, why in the hell would you translate the language?

      For posting a reply, why in hell wouldn't you read the F*&^ing article?

      The article talks about the EXACT reason they chose tranlsation vs emulation. They are translating to the Gameboy and in their words:

      The CPUs are so close in performance that direct emulation can immediately be ruled out. The larger cartridge size means we can accommodate some code expansion caused by translation.

      Previously in the article they mentio

  • Digger (Score:4, Interesting)

    by Fellgus ( 16870 ) on Thursday September 25, 2003 @09:01AM (#7054348) Homepage
    The classic Digger game with CGA graphics for the PC (ran on the 8086) went through this process by this guy: http://www.digger.org/ [digger.org]

    Amazing feat. It's completely rewritten in C to gain exactly the same functionality as the original code, with only the binary / dissassembled machine code to work with.

    • Class! I had this once, I was an addict, and good at about the first five levels. Then I lost interest, but now I can play it again!

  • yay! glad to see I'm not the only geek doing this (Score:2, Interesting)

    by Anonymous Coward
    Well, I'm not porting to a different platform, but I am converting old bootable 360k floppy disk games into games that can still be run on modern computers.

    I've finished the Epyx game JUMPMAN
    http://www.classicgaming.com/jmanproject

    and I'm currently working on Beyond Castle Wolfenstein

    This is a very time consuming hobby, but for me it's a matter of preservation than anything. I don't want to have to dig out the PCjr from my closet everytime I want to play these oldies.

    -jeff!

  • Too much self modifying code, the guy is a fool (Score:2, Interesting)

    by Anonymous Coward
    Too much self modifying code, the guy is a fool.

    He does not talk about dynamic recompilers (that use page management dirty-bits to track self mofifying code)

    He does not talk about self modifyingh code

    he does not talk about timing loops and differences in different opcodes

    He does not talk about lot of things.

    I suspect he is not the one to talk about this stuff.

    Tom Dowdy (old email dowdy@apple.com) knows all about DR he wrote a paper on it.

    So did the guys who wrote a DR for recoding Mac 68K on an Inte

  • These are a few of my favorite links... (Score:5, Funny)

    by nanojath ( 265940 ) on Thursday September 25, 2003 @09:08AM (#7054389) Homepage Journal
    "My favorite Slashdot links are those that..."


    My favorite Slashdot links are those that go down within about 12.5 seconds of showing up on the front page. I know I must be missing something really great!

  • Project Odin (Score:5, Interesting)

    by paugq ( 443696 ) <pgquilesNO@SPAMelpauer.org> on Thursday September 25, 2003 @09:38AM (#7054645) Homepage

    The guys at OS/2 Netlabs [netlabs.org] have been doing this for years now. It'ts called Project Odin [netlabs.org] They run Win32 apps on top of OS/2 with no emulation: they "translate" binaries on-the-fly. They even run Win32 drivers on OS/2!!

    • Looks like all they do is reorganise the PE files when they load them, and have an implementation of the Win32 API (ala wine).

      I don't think they're actually translating calls to Windows functions to OS/2 functions - that would be neat (and very very hard, due to side effects)
    • They provide the Win32 API for OS/2, the code is still i386. So this is a completely different animal. WINE and CygWin fall into the same boat.

  • These guys are hardly experts (Score:5, Interesting)

    by Salamander ( 33735 ) <`jeff' `at' `pl.atyp.us'> on Thursday September 25, 2003 @09:43AM (#7054671) Homepage Journal

    I've had to suffer through these guys' port of Joust on shockwave.com (in fact I have the high score for the month currently) and it has several inexcusable flaws. The most annoying is that it doesn't always respond to keypress events properly - rather critical functionality for a game. It doesn't actually seem to drop the events, which would be bad enough, but it ignores them for as much as half a second at a time and then spits a whole bunch out together. If your game wasn't screwed up when it seemed to ignore the event, it's damn sure going to be screwed up when they all get played back in a burst along with the other keys you hit to recover from the original failure. I know Windows is not a real-time system, and I've worked on real real-time systems (microsecond response times) so I do know the difference, but there's no excuse for a delay this long on an unloaded modern system. Other games don't seem to be afflicted by the same problems. The problem is not in Windows; it's in Digital Eclipse's emulation of the hardware on which the game originally ran (even if the code is translated the non-CPU hardware still has to be emulated).

    There was also a time when the game's speed calibration was totally broken. I'd play on my 600MHz laptop and it would be just about right, but when I went to my 1.5GHz desktop guess what happened. Yeah, everything in the game was moving about 2.5x as fast and the game was unplayable. This only persisted for a week or two, but it's still not something that should happen in a version that's released to the public. These technical failures, combined with their apparent acquiescence to Shockwave's desire to add deliberate player-killing features to their translation (the very laws of physics in the game change after you get a good score, and I've looked at the original ROM code so I know exactly how they're doing it) have left me with the impression that Digital Eclipse is both incompetent and unethical.

    • That problem of storing up an assload of commands and unleashing them all at once is also present on my DVR (sort of like TiVo) it is very annoying to try to fas foreward through a set of commecials and end up getting sent all over the recording because the machine decides to take random amounts of time to execute commands from the command queue, it should be simple to make the box have a *small* queue (2-3 commands) and an overflow command either being dropped or triggering a queue flush in order to allow

    • Re:These guys are hardly experts (Score:1, Informative)

      by Anonymous Coward
      "I've had to suffer through these guys' port of Joust on shockwave.com (in fact I have the high score for the month currently) and it has several inexcusable flaws. The most annoying is that"...

      ... some mook sitting in a chair propping up a can of mountain dew with his belly thinks that dissing the free (as in beer), well intended, open-hearted work of someone else (did you really *suffer* through the joust port? poor baby) earns him some cool. please.

      yeah yeah, you've got a grasp, but so what?

      pounding on s

      • Programs that simply don't work right, that don't meet quality standards we'd apply to every other product category, is a perfect illustration of why the public at large views geek culture - that includes you, we're on Slashdot - as a bunch of overpaid lazy clods.

        Mindless flames that make unwarranted assumptions (such as "propping up a can of mountain dew") are a perfect illustration of why the public at large and even the geek community views Slashdot - and particularly the anti-community of aptly named a

  • TRS-80 games (Score:4, Interesting)

    by Zog The Undeniable ( 632031 ) on Thursday September 25, 2003 @09:43AM (#7054676)
    Can someone please do "Cuthbert Goes Walkabout"? I played it on a Dragon 32, but most Dragon games were originally written for the TRS-80.

    Odd TRS story: the bicycle manufacturer GT made a mountain bike called an RTS-1 (Rear Tuned Suspension). It shouls have been the more logical TRS-1 (Tuned Rear Suspension), but the Tandy trademark apparently stopped them using the initials TRS. This was about 10 years after the TRS had gone out of production!

    • Tandy made mountain bikes?

      I ask, because I was under the impression trademarks only apply in a certain industry (ie/ I've seen a furniture store called McDonalds). Correct me if I am wrong...

  • an ML/OS compiler? (Score:3, Interesting)

    by LWATCDR ( 28044 ) on Thursday September 25, 2003 @10:34AM (#7055102) Homepage Journal
    Why not a compiler that takes machine code and compiles it to a new machine code? Such systems have been made. The Java JIT compilers take java bytecode and compile it to native machine code. The translator on the Transmeta chip takes AI-32 and comiles it. Why not one that takes say an MS-DOS program and converts it to Linux? You would have to map every interupt and dos call but it could be done. Selfmodifying code would be a big no no or a huge challenge for the compiler. All in all it could be interesting.
    • You still have a lot of things to overcome, but it would not be impossible. You would know about code entry points, but what happens when you do something like: mov 5, r1 shl 2, r1 cmp r4, r5 be r1

      You would need some sort of emulation going through the whole thing. There could be lots of tricky situations where you are not sure of where branches are going to go.

      You could have a software emulator and someone play through the whole game, I suppose, but there is no guarantee you would get all of the br
      • I was not thinking of games specificaly. THe idea of treating the ML as a language and compiling it kind of interests me. I have heard that IBM did something like that for the AS/400. They created a "perfect machine code" that gets "translated" when you install or is it when you run the program. That is how they could move from a CISC CPU in the Model38 to a Power Risc cpu in the AS/400. I would think that a modern PC now has the power to do the same thing. Might it not be possible to create a perfect ML fo
  • I mean wow guys, you just run the C compiler backwards and it will disassemble the object code into C.

    And it tells you "Paul is Dead" at the same time.

    These kids now adays...
  • ...you insensitive clods! (To all those that's been saying "emulation is better".)

    IMHO, It was smarter to do it this way than try to emulate the genesis on a GBA. The latter might be possible one day, with enough hacking breakthroughs, but this is no less generalizable. They have a perl-based translator which they can improve, much like an emulator often need to be improved the more games it is to support.
  • If they had the original assembley source files, think how easy this would be. Code sections already separated from their data sections. All you would need to do is know HOW the hardware worked and translate the assembler files. Yes, there would need to be a few changes, like resolution differences, possible shortage of buttons, etc.
  • This article was interesting but short on technical detail. Here are some other links on static recompilation:

    http://www.gtoal.com/sbt/ [gtoal.com]
    http://groups.yahoo.com/group/staticrecompilers/ [yahoo.com]

    It is unclear to me how they deal with more complex situations such as self-modifying code or code that jumps into the middle of an instruction.

Slashdot Top Deals

A person with one watch knows what time it is; a person with two watches is never sure. Proverb

Close