View Full Version : Teach me how to make a emulator
Drake Dagow
June 6th, 2002, 05:28
plz help i am a wanabe programmer that wants to make an emulator even if its for nes help me if you can email me at kennymcqueen2002@yahoo.com:confused:
You have any programming experience?
Shiori
June 6th, 2002, 06:00
Probably none; or else he'd know what to do by now. ;)
There are a lot of perfectly good emus for the "old" consoles", but if you're that determined to join the emu scene, you might want to explore the possiblity of developing plugins for the (as of today) 2 PS2 emus under alpha development, or even help out in Sega Saturn emulation (which is pretty much due by this time).
I really find it somehow unusual that emu authors chose to develop a PS2 emu rather than lend a hand in SS emulation.
Ninjaa
June 6th, 2002, 08:44
I think it's the thrill in exploring new territory. Saturn is still new I guess as far as emulation is concerned, but the hardware is a lot older and less popular. I mean, if you were a coder, would you like to say: I made a PS2 emulator! or... I made a Saturn emulator!
Shiori
June 6th, 2002, 08:57
Still, I believe the challenges in SS emulation would be a more, shall we say, feasible and reachable target than PS2 emulation right now.
Ninjaa
June 6th, 2002, 09:06
true. Very true. Tell you what, if I ever get the knowledge required to make an emulator, I will help out with the Saturn, alright?
M.I.K.e7
June 6th, 2002, 09:21
Just a few pointers:
http://www.atarihq.com/danb/emulation.html
http://www.classicgaming.com/epr/
Sanhime
June 6th, 2002, 15:42
For some reason, SS games are far superior than games on PSX, in terms of fun factor. Saturn has some AMAZING RPGs, I think far better than FF7,8,9.
happy2k
June 6th, 2002, 16:00
haha i agreed!~~ especially Shining force 3.. the three episode.. it's fun ~~! i think is't ebtter than Ps's FF series
Ninjaa
June 6th, 2002, 16:09
I really liked the first two shining force games for Genesis. I never played the third one.
But the PSX mostly had dissapointing RPGs. The first few Square ones were good, but the rest of them stunk. Enix made a couple of goodies, and Tales and Breath of Fire were good though.
Nightmare
June 6th, 2002, 18:58
Psx got lots of good rpg, just u guys never play them and only concentrate on those more popular rpg..
Wild arms series, Ard The Lad series, Beyond the Beyond, and some others rpgs were great.
Not only Square or Enix makes good rpg games :)
Drake Dagow
June 6th, 2002, 19:09
thanks guys but that doesn't really answer my question
Ninjaa
June 6th, 2002, 19:25
well, answer the first question asked to you. Do you have any programming experience? It's kind of hard to help when we don't know anything about you.
If you don't have any experience, buy a C++ book, and learn it. Then move on to Assembly.
If you do have experience, then read Mike's post.
Allnatural
June 6th, 2002, 23:17
read... (http://www.pj64.net/emubook)
n0estoy
June 7th, 2002, 04:46
damn straight it's prime time a highly compatible saturn emulator was released! i've been waiting for it since epsxe 1.0.1
Drake Dagow
June 8th, 2002, 08:37
thanks but i have no programing expercience i admire the people who make emulators
Hanamichi
June 8th, 2002, 08:48
Then get a book and learn a programming language. You cant really "program" if you dont know anything about it yet :)
metal_ash
June 8th, 2002, 09:07
first you must have the interest to program coz writing codes aint that fun.
sniff_381
June 8th, 2002, 09:24
Originally posted by shanghai_kid
plz help i am a wanabe programmer that wants to make an emulator even if its for nes help me if you can email me at kennymcqueen2002@yahoo.com:confused:
ok.. first... buy a copy of visual Basic or maybe Visual studio... then download some patches and updates from www.microsoft.com .. you can find it there... then read the instructions... second don't be lazy... have some patience.. then TATA!!! you have your own Visual whatever... then make some programs... release it's beta... share it to people... then wait for some bugs to be discovered... debug it then... release it's 1st version...
Shiori
June 8th, 2002, 09:35
You make it sound like you just have to buy Visual Studio to instantly gain programming know-how.
sniff_381
June 8th, 2002, 09:45
no... not really... the best way to program easily is having an experience about programming... but I'm still on high school.. ur from lasalle shiori ryt??? I'm planning on studying there...
ShADoWFLaRe85
June 8th, 2002, 13:50
Originally posted by sniff_381
no... not really... the best way to program easily is having an experience about programming...
Ummm...isn't almost anything easier when you have experience with it?
Ninjaa
June 8th, 2002, 14:43
I think that the best way to learn would be to buy a programming book (my personal preference is C++), and learn it. Use Visual Studio along with it, and you should be able to learn it all eventually.
ShADoWFLaRe85
June 10th, 2002, 08:27
Yeah...I started out a long time ago with a book. It really helped me to understand by trying out some of the samples in the book and changing them to try and create my own results. I then started creating my own programs from scratch and trying out newer and newer things, eventually developing my own technique for coding, which sorta brings us to the present. It seems that the more you enjoy coding and have fun with it, the easier you'll learn it and the faster you'll pick up on it.
My suggestion to start out would be to get one of those "for dummies" books or the Sam's series - Teach yourself how to program in however many days. They really introduce you to the basics ;)
Drake Dagow
June 10th, 2002, 08:40
thanks alot if u can give an example on where i enter the codes or lanuage that would help:(
ShADoWFLaRe85
June 10th, 2002, 08:59
Well, this is how programming a piece of software works:
You must first write out the source code in whatever syntax is deliminated by the programming language. The source code can even be written in a simple text editor, if you want. However, it helps to have programming software to help you debug the code when errors are present. After your project is ready, you run it through what's called a compiler. The compiler handlers the process of translating your code into machine code, aka an executable. The software you use will vary with whatever language you choose. Some suggest to learn Java, some say C++, others reccomend Visual Basic. It's up to you, really. Here's something of an example of what it looks like entering code into software built to handle it and help you with the process of debugging:
sniff_381
June 10th, 2002, 09:19
ShadowFlare... are you using Visual Studio .NET???
ShADoWFLaRe85
June 10th, 2002, 16:44
Originally posted by sniff_381
ShadowFlare... are you using Visual Studio .NET???
I use VS.NET, yes. However, that is a picture of the Microsoft Script Editor.
ammoQ
June 16th, 2002, 18:05
Originally posted by ShADoWFLaRe85
Well, this is how programming a piece of software works:
You must first write out the source code in whatever syntax is deliminated by the programming language. The source code can even be written in a simple text editor, if you want. However, it helps to have programming software to help you debug the code when errors are present. After your project is ready, you run it through what's called a compiler. The compiler handlers the process of translating your code into machine code, aka an executable. The software you use will vary with whatever language you choose.
*LOL* Well this is how writing chinese language works: You must write chinese symbols in a way a chinese reader understands them. Remember it's up-to-down and not left-to-right.
ShADoWFLaRe85, you are basically right, but I think you missed the point: To write a program, you must understand how a computer works, you must know how to take apart the problem (the application you want to write) into small pieces, how to define that small pieces of the problem in a computer language. Entering the code and compiling it is the smallest step.
I think writting an emu is about the most complicated task for every programmer, a newbie will hardly be able to make it.
ShADoWFLaRe85
June 17th, 2002, 00:37
True, you should learn the basics of programming first, but I was assuming that was already known. I mean, if you're asking how to create an emulator, you should at least know that programming is consisted of tiny steps that work together to create the application. I'm answering one step, you're answering the other. You're explaining how the creation of the code works, I'm explaining what to do with it to come up with what we consider software. So, we're both right, ammoQ. :p
ammoQ
June 17th, 2002, 07:07
Originally posted by shanghai_kid
thanks but i have no programing expercience i admire the people who make emulators
ShADoWFLaRe85, any idea why people without programming experience always want to start with the most complex topics? ;)
ShADoWFLaRe85
June 17th, 2002, 07:11
Originally posted by ammoQ
ShADoWFLaRe85, any idea why people without programming experience always want to start with the most complex topics? ;)
I really don't think they realize just how difficult a task it is to program such software. They probably just assume that it's all the same and of course, I'm sure they want some sort of recognition ;)
SnakeBite
June 17th, 2002, 16:56
I started with a few simple things before I came up with something usefull... It could take some time before you get an idea on something very usefull... After a while, I made SnapViewer, and that's the first successfull application I've ever made...
(Delphi wasn't that hard to learn...)
Exophase
June 17th, 2002, 20:53
I used to think emulators were the most complicated things you can code, but after having thought a lot about it (yes, my member title is still true..) I think it all depends on how you think. If you're a really low level oriented person who's comfortable with computer microarchitecture then emulators can often be trivial, if you actually have the information you need.. which just isn't the case enough of the time... but writing some other things can be a lot larger, at least.
- Exo
ammoQ
June 17th, 2002, 21:42
I am pretty sure that emulators are about the most complicated program you can write (despite my title, I only wrote a rather simple plugin, so don't think I want to make myself a hero by saying so). First of all, it's pretty hard to find out what exactly the orginal machine did. The CPU is probably the easiest part, since it's very likely a common, well documented part. Plus you will very likely find existing well-working emu software for the CPU. But the custom chips for sound, graphics etc., which commands do they get? What do these commands mean? How do the chips respond? This is a lot of stuff to find out.
Sony or Nintendo won't tell you that, that's for sure.
Once you have this specification, you can start thinking about writing an emulator... this means, building functional units which resemble the parts of original hardware (this is obviously often done in plugins). But then, even if each part does his job correctly, you need to simulate the correct timing of the original hardware, since all software depends on it. Probably no PSX game was ever tested if it workls on a machine where the CPU is faster by factor 2.5, but the graphics engine is slower by factor 0.7 - every game is written for an invariable hardware. I think this is the hardest part: not only simulating a fictious machine, which is able to run software especially written for it; but to have an emulation precise enough to work with original software.
Exophase
June 17th, 2002, 23:39
Yeah, you're right, and again I think it depends largely on what documentation is available. If you're trying to reverse everything for emulation then surely it would be very, very difficult. For something like PSX there's a decent amount of documentation available if you look hard enough, probably enough to do an emulator without too much guess work. Anything old is probably pretty trivial, like NES.. the timing isn't too complicated and everything's really slow there, and there's plenty of documentation.. I guess it just depends on the system for how hard it is...
- Exo
sniff_381
June 18th, 2002, 11:02
it's really difficult on programming something... I always begin with a flowchart... but it takes me ages on finishing it... when I'm done with the flowchart... then the process on visual basic begins... and blah blah blah... until I finish the program...
ammoQ
June 18th, 2002, 23:17
Originally posted by sniff_381
it's really difficult on programming something... I always begin with a flowchart... but it takes me ages on finishing it... when I'm done with the flowchart... then the process on visual basic begins... and blah blah blah... until I finish the program...
That's good OLD style of software development - how do you document class hierachies in a flowchart? not at all? So you never use classes in your program. Hint: If it is your decision, look for a appropriate way of documenting, or cancel documenting at all.
If you use the methods of the time before structured programming (not to speak of OO-programming), you won't get it right.
ShADoWFLaRe85
June 19th, 2002, 05:17
To date, I have never used a flowchart or any sort of documentation in my programming. Waste of time, IMHO :)
Shiori
June 19th, 2002, 05:56
I just want to learn enough to graduate. :cry: I'm really wondering why I can't learn VB despite books as thick as the Yellow Pages and various training CDs. The fundamentals just don't stick in my head. I try to be interested, but I get bored after exactly 3 minutes. :(
Maybe i'm just not cut out to be a programmer, I guess. :(
ammoQ
June 19th, 2002, 19:49
Originally posted by ShADoWFLaRe85
To date, I have never used a flowchart or any sort of documentation in my programming. Waste of time, IMHO :)
When I write professional software (this means: I get paid for it), I don't have a choice, I must write documentation. But flow charts are not among the kinds of docu you will ever get from me. The most common docu is the sort that specifies the planned look-and-feel of a software product (faked screenshots etc.) This is what I need to negotiate the requirements with my customers. Another aspect that need documentations are file formats, protokolls and things like that. An entity-relationship-diagram is usefull for database-driven applications. But that's it, normaly I do not make more doku except the comments within the sourcecode.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.