An Incredulous Undertaking

[BGNG]

It depends both on the computer running it and methods used. Take a look at the source code. I did some fancy logical operator bizznazz and I used function callbacks, which allows me to do just this (This is pseudo-code):

Dim O As Byte
ReadByteFromFile O
RunOpcode O

See? Run an instruction based on a number instead of "Select Case O" or whatever. VB can't do that natively, so I had to use C++ to spoof it a little.

And the NES runs at wherabouts of 1.8MHz

 

[ra5555]

That is one heck of a proposal there m8, all the best to you on the project. I have no clue about emultation (exception for using emulator to play games ) and how to program them, so I will naturally assume that it is very hard to do (cause everyone says so), and like Apprentice said, it will be a long and hard journey toward your goal.

However, why shouldn't you give it a try, yeah there maybe 1 in 100 chance of success, but isn't that how all those amazing projects are accomplished?

Cheers m8

 

[BGNG]

I appreciate your enthusiasm, ra5555, but there are a few things to keep in mind:

1) It's not difficult. You need only know how.
2) If you know how, your chances of success are pretty high.
3) Why does everyone say it's difficult? Any why do they think Assembly is hard?

I'm still chuggin' along with the NES emulator. Life has thrown a few distractions my way, so I can't keep on it quite as I would like to, but I do still work on it every other day or so.

 

[Doomulation]

Hmmmm... and double hmmmm! Visual Basic and emulators? Hmmmmm! Bad, very bad.
I can't say what to believe... VB and emulators? Though you do say you know assembly. But in that case, I'd prefer C or C++ (well, I always do for emulators). Oh and VB.NET is almost as slow to program in as C -_- ...

In any case, I can't tell what to believe. Perhaps if you write them in C, it might make a better impression. I shall await until I see something written for the NDS. IF you do success, that would be neat.

As for assembly, it is not THAT easy... it's so... low level. Hard? It can be. There are lots of things you gotta do to get around easy stuff you can make in languages, like C. I know a tad assembly (enough to know if something goes wrong in the code when viewing assembly). Other than that, not very much. I don't code asssembly.

 

[BGNG]

Keep in mind: I am not angry, nor do I hold anything against you... But still:

It's attitudes like that which really make me want to spite people. Your comments on Visual Basic are clearly biased and I would wager you have little to no experience with it. There is absolutely no reason to say "Visual Basic cannot make a good emulator."

Perhaps where you are confused is that C/C++ can make BETTER emulators than Visual Basic, primarily because Microsoft doesn't want VB developers to manipulate memory for some reason. Total exclusion to things like variable/function pointers and function overloading really limit a VB developer as to what he is able to do.

Because of the little detail regarding function pointers, I am writing the Windows versions of these emulators in C++ to create a DLL which I will then incorporate into Visual Basic to set up a GUI. Although, the nature of this will let any little programming loser snag the DLL and say "Look at this emulator I made!"... I'll have to find some way to prevent that.

And... I do not mean to be offensive, but I honestly cannot determine how you concluded that Assembly is difficult even though you say you do not code with it. That's like saying, "It's difficult to land a space shuttle"... How would you know?
__________

And as for Visual Studio .NET... I think Microsoft pulled that out of the same slop bin as Windows ME... I don't like it, nor do I ever intend to use any of it. "Can we make something even WORSE?" "Impossible!" "Tough. We're gonna try anyway."

 

[Toasty]

IMO, (this is neither for or against assembly) writing assembly isn't hard, just time-consuming. Moving from C++ to assembly was very easy for me, as all of the concepts are already there, just expressed a little differently. It was basically just a matter of getting myself to look at ADD EAX, 12 and see EAX += 12.

 

[BGNG]

That, and the fact that Assembly instructions are very mild and don't do very much makes it very easy to learn what they do in their entirety. "Shift bits left"... easy concept, easy to see what it does. It's not like the "Sine" function, where it manages to generate the number via unknown means....

...hmmm... I'ma make a new topic 'bout that. Maybe someone knows.

 

[Doomulation]

Hehe, valid arguments? I'm not flaming you or anything. You are wrong on some points, lemme quote you.

Keep in mind: I am not angry, nor do I hold anything against you... But still:

It's attitudes like that which really make me want to spite people. Your comments on Visual Basic are clearly biased and I would wager you have little to no experience with it. There is absolutely no reason to say "Visual Basic cannot make a good emulator."

First off, I didn't say VB did not do any good emulator, but the fact remains that VB is slow and has limited stuff it can do in low level. And fact is that I DO have experience with visual basic. It was my first programming language which I started with. I used it for several, all while I tried to get the hang of C++, actually. But I never DID an emulator in it for that matter, so I disgress.

Perhaps where you are confused is that C/C++ can make BETTER emulators than Visual Basic, primarily because Microsoft doesn't want VB developers to manipulate memory for some reason. Total exclusion to things like variable/function pointers and function overloading really limit a VB developer as to what he is able to do.

Indeed, but it isn't required in most normal applications. And direct memory manipulation is what causes the most problems/exceptions (well, there are at least many of them), in a normal C application.

Because of the little detail regarding function pointers, I am writing the Windows versions of these emulators in C++ to create a DLL which I will then incorporate into Visual Basic to set up a GUI. Although, the nature of this will let any little programming loser snag the DLL and say "Look at this emulator I made!"... I'll have to find some way to prevent that.

Indeed. That's lame. I'd use a copy protection system and keep a documentation of the exported functions to myself. I'd make the GUI in C++ as well, though, but I know that GUI making is easy in VB. Using MFC, it isn't that hard to do GUI making in C++, you know...

And... I do not mean to be offensive, but I honestly cannot determine how you concluded that Assembly is difficult even though you say you do not code with it. That's like saying, "It's difficult to land a space shuttle"... How would you know?

I have very little experience with it. I did read a documentation to learn assembly, which is where most of my knowledge and experience comes from. Once I think I used an asm hack in a program and there is also once program that I tried to use inline assembly so that I knew what code would be generated exactly when compiled. This, since I didn't want unneccesary instructions and also know that it made the results in the correct way (not just achieve the result). Still haven't finished that, though, but that's a very simple software.

And as for Visual Studio .NET... I think Microsoft pulled that out of the same slop bin as Windows ME... I don't like it, nor do I ever intend to use any of it. "Can we make something even WORSE?" "Impossible!" "Tough. We're gonna try anyway."

It has some advantages, actually, I'd say. Did you ever try the NET Framework? I figure, that if it is further developed, it might come to replace MFC which I use instead of Native Win32 Development. The NET Framework contains many nice functions to use. Although that's pretty much all why I like the framework

Also, there's C# (C Sharp). It's like VB & C++. A rapid tool, yet it does not sacrifice the power of C or C++. It's pretty nice, too. Visual Basic .NET, is just s00d if you ask me, though. It's low level as the others now, so why use it? Use C# or C++ instead...

Well, there's my answers to you

 

[BGNG]

Visual Basic is designed to be as computer-friendly and functional as possible, which sacrifices a nice chunk of its power to error checking and that kind of thing, which is why it's so much slower than C. However, with any computer running a good 500 MHz or faster, I have seen many good applications written in it, and I myself have programmed an audio sequencer which renders stereo audio at 48000 hz using the Windows "waveOut" API and it works full-speed on my little test machine which is running an AMD K6-2 with Win98 SE.

The thing with the DLL, ironically, is that I WANT other people to be able to use it. I've decided to make a function inside it which stores an encrypted string identifier under the function name "TellTaleHeart" such that any suspecting person can just try that in the DLL to see if it's a legitimate work or actual plagiarism.

And again, I'm only working with C++ for function pointers. And with the idea of a DLL, I've decided to do all the emulator-ing in C++ to make it all easier to handle. I still prefer to use Visual Basic. GUI's are nice and easy in C++, too, but I choose to use VB instead.

The .NET framework just isn't programming at its finest. Any program compiled with it needs to be run on a machine with a compatible setup, so it's virtually headed towards the same concept as Java... And Java doesn't try to hide the fact that they're proprietary.

 

[Cyberman]

And again, I'm only working with C++ for function pointers. And with the idea of a DLL, I've decided to do all the emulator-ing in C++ to make it all easier to handle. I still prefer to use Visual Basic. GUI's are nice and easy in C++, too, but I choose to use VB instead.

Heathen! LOL VC # GUI developement system has always had something to be desired. This is why Microsoft bought Borland's chief GUI archetect. They realized there software basically STUNK for Rapid Application Developement in that reguard so what better way then BUY the talent from the competition (that's how MS works shrug).

I hate VB myself but that's because I found it's implementation too anoying.

The .NET framework just isn't programming at its finest. Any program compiled with it needs to be run on a machine with a compatible setup, so it's virtually headed towards the same concept as Java... And Java doesn't try to hide the fact that they're proprietary.

Most things are proprietary. Java is not really proprietary as it's well documented in this interfaces etc. I still think of it as a spaghetti however Sun has been debating weather to open source Java or not for the past year. They have created the Solaris 10 Open Source license to be inspected by the FSF. Having read it.. iI think they are still in the 'it's all mine' thinking on things. Oh well. I don't think .NET is anything useful, it's more smoke than substance. Some things it can be. In general it's just another 'we want to run your lives' thing from MS. I'm skeptical of it's true usefullness as a 'proprietary standard'.

Cyb - And this too shall pass (Bill Gates eating a wooper at Burger King).

 

[BGNG]

Microsoft tried to buy Google, failed, and now they're trying to figure out how to be at least as good, such that they can have revenge.
__________

Anyway... Emulators! Nintendo DS! Wireless Multiplayer!.. (The topic of this thread.)

 

[gladius]

I realize this thread is rather old, but just to set the bar on how tough this will be, I wrote the sound core for snesds (snes emulator for ds), it is 95% extremely optimized asm and the main snes core is 100% asm. The graphics are emulated using the DS's 2D hardware so we get a huge speed win there (pay for it in compatibilty though).

And even with us using all the resources of the machine, we don't have enough cpu power (the sound is done on the arm7, the main cpu on the arm9). Also, the guy who wrote the cpu core (loopy) is a freaking genius when it comes to arm assembly - see the source of snesadvance for some inspiration .

For simpler consoles such as nes and gb good emulators exist, gbc would be something good to target if you are set on it.

Edit: okay, I thought this thread was '06, not '05, so it's even older than I thought, but the point still stands .

 

[Cyberman]

I realize this thread is rather old, but just to set the bar on how tough this will be, I wrote the sound core for snesds (snes emulator for ds), it is 95% extremely optimized asm and the main snes core is 100% asm. The graphics are emulated using the DS's 2D hardware so we get a huge speed win there (pay for it in compatibilty though).

And even with us using all the resources of the machine, we don't have enough cpu power (the sound is done on the arm7, the main cpu on the arm9). Also, the guy who wrote the cpu core (loopy) is a freaking genius when it comes to arm assembly - see the source of snesadvance for some inspiration .

For simpler consoles such as nes and gb good emulators exist, gbc would be something good to target if you are set on it.

Edit: okay, I thought this thread was '06, not '05, so it's even older than I thought, but the point still stands .

Well we haven't banned for necromancy on threads.. Yet

Cyb

 

[Martin]

Did BGNG ever release anything?

 

[aprentice]

Did BGNG ever release anything?

its was all just talk like we all said from the beginning

 

[Cyberman]

Well I think he had too many other projects he worked on instead. Sort of like being interested in everything at once.

Cyb

 

[Falcon4ever]

Last post in December 23rd, 2005, 21:10...
M.I.A.

 

[Blargg]

Oh heh, thread already dead. Well I typed this anyway. Perhaps all the criticism did it in.

I think you have severely underappreciated the amount of work in implementing even a NES emulator on a PC. Straightforward accurate designs barely run on modern machines, and an optimized design must take into account the general architecture, so writing this for Windows doesn't mean it'll work well on the DS. Without having the entire design worked out in detail, it might be subject to drastic change mid-way through implementation due to realizing some missed detail. Due to this, the apparently progressing implementation can take a step back to square one.

But the real issue is that your visible efforts in this thread are aimed at persuading others that you are up to the task, rather than doing the task itself and letting the result speak for itself. Nothing shuts up naysayers like delivering the goods; and no, "I'll deliver the goods" is not delivering them, just claiming you will. You can't deliver them until they're done, thus you shouldn't make outrageous claims until you've got the goods already.

And regarding the word "incredulous", either you chose that word intentionally as a hint to careful readers, or "I do not think that word means what you think it means".

 

[Garstyciuks]

In my opinion sometimes it is better to say something about your creation when you know that you will be able complete and have something to show.