Is it enought to just have the source code?

Discussion in 'General Gaming Discussion' started by Hebon, Jul 4, 2011.

Jul 4, 2011
  1. Hebon
    OP

    Member Hebon Dabbling in the videogamagical

    Joined:
    Mar 10, 2011
    Messages:
    146
    Country:
    United States
    If someone had the source code for any game system, would it then be possible to make a fully functional emulator?
    Is that all it would take, or would you need hardware schematics and devkits as well?
     
  2. Ammako

    Member Ammako GBAtemp Guru

    Joined:
    Dec 22, 2009
    Messages:
    6,372
    Country:
    Canada
    There is source code for hardware?
     
  3. Hebon
    OP

    Member Hebon Dabbling in the videogamagical

    Joined:
    Mar 10, 2011
    Messages:
    146
    Country:
    United States
    Source code of the operating system, whatever it might be.
     
  4. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,737
    Country:
    United Kingdom
    Game systems function somewhat like embedded hardware meaning operating system is not that meaningful a term and even on the more modern systems with some semblance of an operating system running underneath it all there is a tendency to treat the game somewhat like a simple standalone machine (give or take security and the features that might be conferred by the menu- stuff like 360 messages, audio chat and such which the wii lacks and indeed was one of the criticisms of the wii architecture- http://hackmii.com/2009/02/why-the-wii-wil...get-any-better/ ).

    Equally if encryption is used you can build a machine that runs but without the actual keys to decrypt them you are out of luck (the PSP and PS3 scene frequently saw some things like this thanks to the methods used and we similar things with developers/debuggers and reviewer machines).

    Likewise although some have made transistor level emulators http://www.youtube.com/watch?v=uP1gWg5ezyY they are very slow (even on top end hardware that chip which is a really old, really basic chip is not quite realtime) so the trick is to abstract/simplify it a bit to make it run more quickly but eventually you fall foul of some quirk somewhere and some piece of code will fail to run (all the old 8 and 16 bit consoles that have trouble games that work with beefier emulators- this is usually the reason). Because of this abstraction though some people have done some very clever things over the years to allow a small subset of code to run (some of the early and indeed present N64 stuff not to mention the newer console emulators).

    Games then become a unification of three things

    1) the actual hardware design including any hardware processing abilities (the 360 actually has a fairly nice audio decoder chip onboard).
    2) the software that is contained within this hardware (the BIOS*, the loaders and any other programmable stuff)
    3) developer's tools whatever they might be (first party SDK, game engine, custom SDK.....)
    - I mention this mainly for the dynamic recompilation concept the early N64 emulators toyed with and maybe some of the stuff that went on with regards to old dos games (if they were a doom engine game some people attempted to tweak the now open source doom engine to function with the game that is not open source).

    * http://nocash.emubase.de/gbatek.htm#biosfunctions
     
  5. Schlupi

    Member Schlupi Gbatemp's Official Earthbound Maniacâ„¢

    Joined:
    Aug 31, 2007
    Messages:
    3,985
    Location:
    Rozen Queen Co, Chicago Branch
    Country:
    United States
     
  6. Hebon
    OP

    Member Hebon Dabbling in the videogamagical

    Joined:
    Mar 10, 2011
    Messages:
    146
    Country:
    United States
    So in essence, you would mainly need knowledge of the hardware and the source code to make a fully functional emulator. Devkits would only make things simpler.

    Is that right?
     
  7. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,737
    Country:
    United Kingdom
    Possibly not- several games have made extensive use of scripting languages and such like (SCUMM games and whatever SCUMMVM emulates these days first up and some of the things like puzzle quest (made in lua), the stuff with game engines up above and getting more into tech the dynamic recompilation thing (although you can not decompile like you can for a scripting language chances are a function comes from a given code snippet so you can now compile this for the host system).

    Likewise we have seen a few game specific emulators over the years- I recall posting about an international karate "emulator" several years back for the DS and if I widen that to include some of the "hacks" added to emulators to run certain games.

    Carrying on the SDK for a system (or at least the older systems- some of the hardware workings are hidden from developers these days) could in theory provide enough to do some damage in the emulator world- going for a C type language the headers would probably include some mappings and the like as well as detailing how the memory, graphics display, audio, buttons, interrupts, available or preferred commands, instructions and modes and so forth all function which might allow you to cobble together a half working (or indeed quite well working) emulator without seeing the hardware*.

    If I had to though I would choose hardware info over any source code for menus, BIOS and such (although I will note my comment earlier about being able to derive hardware designs from the finished product- a common phrase is "there are no secrets in hardware").





    *I think this is going to be a long one, it looks like we get to do a thought exercise on developing a GBA emulator. It is certainly not the only way to develop an emulator and probably not even a very good one if you actually wanted to make a practical emulator.
    Going back to http://nocash.emubase.de/gbatek.htm for a minute (from what I have seen of the old AGB toolchains and such you can get most of it from those just that you will have to work at it so for the purposes of this exercise you get to ).

    CPU Modes
    ARM Mode ARM7TDMI 32bit RISC CPU, 16.78MHz, 32bit opcodes (GBA)
    THUMB Mode ARM7TDMI 32bit RISC CPU, 16.78MHz, 16bit opcodes (GBA)

    A reference guide is available from the ARM website if nothing else (note for more modern systems companies have taken to simply incorporating the arm designs in custom chips along with some other stuff so do not wander over to ARM.com and expect to come away with a complete guide to the chip) but if not.
    Anyhow you are looking at some code which you manage to decode ( http://nocash.emubase.de/gbatek.htm#armconditionfield - scroll up a bit) as being add contents of R1 to the contents of R0
    Now you have probably given each register to be a variable in the emulator program so although your machine does not treat the code the ARM uses to add some data in the same way you then get to kick this to an add method your processor can make use of.
    Rinse and repeat for all the other instructions (although you probably will probably want to make it decode instructions and generate things accordingly rather than add every possible instruction to a long list).
    This decoding the instruction, regenerating it in a "useful" format, doing it and then passing it back to the emulator for the next instruction is why emulation tends to take a machine several times more powerful to pull off in real time. Doing this though does allow a tiny bit of code to be run (small fragments mainly) if specially coded but that is useful as well.
    Of course the ARM CPU used here has a secondary mode so you probably want to get it to emulate the state it is in as well (this is fairly unusual in processors though).


    A bit further is the GBA Memory Map so you can see what it is trying to do when it writes to the memory, reads from it or tries to trigger a DMA (direct memory access- a way to have chunks of data shift, copy or something like that in memory without having to have the CPU as in intermediary).
    This means you can now almost step through the running of a rom (not everything runs inside the CPU in this case). For optical media or non memory mapped games you are probably going to want to figure out how it gets data and convert reads there into reads your host machine can deal with (which when anti copying measures come into play why modern emulators want isos rather than trying to run it live from a disc).

    Shortly after that you have the GBA I/O Map so you can piece together what needs to happen for button presses good enough for first blush.

    You are missing the BIOS though (why you can probably run your own code but commercial games which use it fall flat) but that is OK as somebody has dumped it and you can just reference it manually (why earlier emulators like the BIOS) but alongside this if it did not happen in the CPU point you get to.

    After this you notice the audio chip ( http://belogic.com/gba/ ) also runs at the same time as the CPU and relatively independently so you look up the audio chip and realise you need to make a new "CPU" style emulator for the audio.

    You might have done this earlier but graphics are probably important to this. You look up the display format from the memory which is easy enough but game systems are not video players and their images are made up from all the various things in the memory (I am sure we have all see what happens when layers get out of order). Now the GBA does have a few modes here ( http://nocash.emubase.de/gbatek.htm#gbalcdvideocontroller ) so you probably want to get them sorted but you can get the modes sorted, the palette loaded in and image coloured accordingly and finally the OAM sorted to get it all where it needs to be on the screen.

    So you get this all added and somehow it is all running at once you get to try and make sure they stay synchronised (at worst it crashes and at best is far too fast with lots of nastiness in between the two)- this is probably going to get costly to resources but otherwise you probably want to run a counter and then get the machine to do instructions at a given counter value as it would on the host system.

    Of course to get here you have probably skipped a few steps and things like interrupt priority need to be added- as was hinted at in various posts so far in this topic you also have things like extra hardware which at first on the GBA tends to mean the various save types which you get to detect and emulate (older versions of VBA tend to do a rather weak check here which is why they fall flat). On top of this you have probably assumed a few things (for the sake of simplicity or the sake of speed) which is where those trouble games start appearing.

    Granted this assumes a PC or something that you control and has enough grunt (although trying to figure out a way to interface low level graphics and sound with programming interfaces usually designed for far more complex formats is not necessarily all that easy- why many emulators base themselves "on" MAME, SDL in some form and will tend to use the same sorts of methods as regular games). If you are making the emulator for a handheld or something with low power you get to cobble things together to work there (different tile sizes- you get to fix it). This says nothing of all the various things you can with an emulator (writing things in memory during runtime- stuff like this makes emulators invaluable debugging tools and indeed they are usually intended to be as such- running games is usually an end stage goal/will happen when the emulator reaches a level of maturity phase).

    Getting back on topic the trouble games was a hint at this paragraph- developers will frequently learn the hardware or indeed a compiler changes and implements something in a new way so every future bit of codes follows and all the interesting quirks it might have to get the best games they can from it all and if your emulator is using info inferred from anything other than hardware knowledge you run the risk of it falling flat but naturally not every piece of code will do this meaning you can get by on less or indeed build an emulator around a specific game.
     
  8. Nimbus

    Member Nimbus sudo /usr/bin make-me-a-coffee --nosugar --cream=1

    Joined:
    Nov 1, 2009
    Messages:
    913
    Location:
    Probably being lazy.
    Country:
    United Kingdom
    Hardware's an important part too.

    Of course, the source code is like being given the gift of creation by god in the Linux and general software world.
     
  9. pistone

    Member pistone GBAtemp Advanced Fan

    Joined:
    Feb 18, 2010
    Messages:
    504
    Location:
    in your heart...coz secretly you love me !!!!
    Country:
    Albania
     
  10. Hebon
    OP

    Member Hebon Dabbling in the videogamagical

    Joined:
    Mar 10, 2011
    Messages:
    146
    Country:
    United States
    I don't want you to think that what you said was a waste, but that amount of data you gave me was HUGE!
    I'm not sure I understood it all (perhaps 30%), and my gears are grinding trying to sort it all out.

    I am not new to the world of computers, but I can't say I'm anywhere near a level where I understand what makes a emulator (although I am learning).

    From what I've gathered and can understand;
    -Having the source would make building an emulator much easier, and less resource hungry,
    -but having hardware schematics wether obtained or researched would be necessary.

    Am I on the right track?
     

Share This Page