OSDev.org

0x3B0 wrote:Why you don't give the source code for Visual C?

Why would he?

i do actually want to make it work in MSVC, because i think the majority of windows users have VC as their IDE/compiler.

I think that this emulator is really nice piece of work but what motivates you to work on it ( there are a lot of emulators nowadays, why one more? ) ?

Nable wrote:I think that this emulator is really nice piece of work but what motivates you to work on it ( there are a lot of emulators nowadays, why one more? ) ?

Perhaps the same reason most people here are motivated to work on an operating system - because they can and they like the challenge.

MessiahAndrw wrote:

Nable wrote:I think that this emulator is really nice piece of work but what motivates you to work on it ( there are a lot of emulators nowadays, why one more? ) ?

Perhaps the same reason most people here are motivated to work on an operating system - because they can and they like the challenge.

yep, exactly. i wanted to give it a shot and see where it goes, it's fun to be able to play old games and run programs in it after spending all these brutal hours writing the code and many many more debugging it. just like 99.9% of OS projects here are never going end up being as good as windows or linux, i know this is almost certainly never going to reach the level of something like QEMU. it's just a good learning experience.

i also think putting the code out there is a good way to help other people see how this works without having the complexity of QEMU or bochs code. it's a lot simpler to understand. i've gotten e-mails via my website from a few people who have said it's helped them understand how CPU emulation works.

BTW, for whose of you who like to understand how emulation and binary translation works and how to write your own emulatr there is very good book which explains the basics:

http://www.scribd.com/doc/90416134/emuprog

Thanks,
Stanislav

pretty good link. that's probably the best general emulation doc i've seen.

btw, i will probably post another update to fake86 within the next few days if anybody cares. i've fixed some bugs, improved the timing accuracy by a ton, fixed the PC speaker emulation, added network emulation support under linux via libpcap (not limited to the win32 version anymore), and fixed the bug where MS-DOS Edit and QBASIC would leave you in a garbage screen mode after exiting, among other more minor fixes.

miker00lz wrote:pretty good link. that's probably the best general emulation doc i've seen.

btw, i will probably post another update to fake86 within the next few days if anybody cares. i've fixed some bugs, improved the timing accuracy by a ton, fixed the PC speaker emulation, added network emulation support under linux via libpcap (not limited to the win32 version anymore), and fixed the bug where MS-DOS Edit and QBASIC would leave you in a garbage screen mode after exiting, among other more minor fixes.

If you want, PM me or something, and I'll set it up to build in MSVC (10 or 11 Beta, whichever). I don't know if you've updated it yet, it would make more sense to 'port' the newer version than to port the older version and merge changes.

Inspiration and admiring you!.Cool Work.Keep Going!
Few Questions:
1]Where did you learn these things?Any tuts you read, share with us ,plz!
2]How long did you take to build these cool stuff?

Read the entire thread, a link is posted.

I've finished a preliminary port. It doesn't quite work yet.

First off: the original program looks to be written in C99 making use of GCC extensions (or some kind of extensions). VC++ only supports C89 (that's why it's called Visual C++).

I've had to change a bit of code, and also, I forced it to compile in C++ mode as it was easier than fixing all the C99->C89 changes. You really need to learn to use headers better... you duplicate the same code and macros a lot, and I wouldn't be surprised if that was part of the problems I'm having. For instance: why are the macros to control Mutexes (btw, on Windows use Critical Sections, mutexes are slower and are for something else) defined in _two_ places?

I can get it to start. It sometimes hangs on starting audio; once video is set up, though, it randomly crashes. I am assuming that there is a buffer overrun somewhere, but I have not yet located it. It's hard to navigate the code.

Anyways, here's what I have so far: http://www.stackheap.com/fake86.7z ... I will leave it up to the builder to find and set up SDL.

Ameise wrote:I've finished a preliminary port. It doesn't quite work yet.

First off: the original program looks to be written in C99 making use of GCC extensions (or some kind of extensions). VC++ only supports C89 (that's why it's called Visual C++).

I've had to change a bit of code, and also, I forced it to compile in C++ mode as it was easier than fixing all the C99->C89 changes. You really need to learn to use headers better... you duplicate the same code and macros a lot, and I wouldn't be surprised if that was part of the problems I'm having. For instance: why are the macros to control Mutexes (btw, on Windows use Critical Sections, mutexes are slower and are for something else) defined in _two_ places?

I can get it to start. It sometimes hangs on starting audio; once video is set up, though, it randomly crashes. I am assuming that there is a buffer overrun somewhere, but I have not yet located it. It's hard to navigate the code.

Anyways, here's what I have so far: http://www.stackheap.com/fake86.7z ... I will leave it up to the builder to find and set up SDL.

thanks for giving it a go. i know the code is very poorly written in most places. i'm pretty new to C, and a lot of the code was written a good year and a half ago. i've been putting off re-organizing it all because it worked. i've been improving my header usage a lot in particular, i know that's the biggest problem with this code. (my NES emu is much more well-organized, and uses VC http://sourceforge.net/projects/moarnes )

tonight i am just going to spend a couple hours re-organizing most of fake86, and move it over to VC in the process. also, thanks for the tip on critical sections. this is the first multi-threaded app i've done.

I'm fairly confident that you have a race condition regarding your threading, which is causing a shared buffer to be overwritten, crashing the program.

I didn't apply it universally, but if you look for "mkukli" in comments, you'll see specific changes I made. You can also just diff though.