OSDev.org

Tornado64 is my 32-bit x86 emulator.



It have a nice debugger (or at least i think its nice), so maybe some kernel developers will find it usefull. I wrote it becouse i am an idiot to be part of another product of me i alreday told on this site before, but i released it separately too.

It can downloaded freely.

It can boot 32-bit linux distributions.

It supports the folowing:
-6x86 CPU core, can perform around 233 mhz on a modern i7 machine.
-64-bit FPU
-SVGA (HD resolution supported)
-HDD
-CD/DVD-ROM
-Floppy
-Keyboard
-Mouse
-Touchscreen
-Can work even without GUI
-Its pure emulation.
-Its fully written in C, without any non-standard thing. However, its x86-only now, i not yet was able to compile it to ARM or MIPS - my arm netbook have too few ram and gcc crashes

-Compatible with SeaBIOS (included in the package).

Tornado64 is written with the help of the tons of publicly available documentations, examples, free source code snippets, crtl+c and crtl+v buttons, clock to clock comparison to other emulators, tutorials, documents, and esoteric buddhist debugging.



download:
http://tornado64.tk/

Geri wrote:It have a nice debugger (or at least i think its nice), so maybe some kernel developers will find it usefull.

One simple question - is it better than Qemu? At least there should be some really nice parts, that allow you to think of the debugger in terms from the quote above.

But if your emulator can run Windows, then it's very promising.

just 1.0, thats not a big thing

and no, its not better than qemu (how it could be?).

Hi Geri!
This is quite cool, I just tested my OS on this and it worked as expected. From the way the emulator behaved it looked like you've used libSDL, but it doesn't poll for SDL_QUIT (hitting the 'X' button doesn't close the window. Had to manually kill it).
Else than that I'd like to add that the font isn't quite readable (maybe because I've some optical issues), how about using a standard TTF font like Code Page 437? (QEMU uses that one so it shouldn't be a problem).
Plus, the disk image browser only scans for floppy/, hdd/, etc. directories have you thought of making it scan user-specified directories?
Also, (this may be a small issue so don't bother) Does it support multiple languages?

Bender wrote:Hi Geri!
This is quite cool, I just tested my OS on this and it worked as expected.

thankyou!

Bender wrote: From the way the emulator behaved it looked like you've used libSDL, but it doesn't poll for SDL_QUIT (hitting the 'X' button doesn't close the window. Had to manually kill it).

it isnt uses sdl, it uses my own software-renderer based sprite-renderer.

Bender wrote: Else than that I'd like to add that the font isn't quite readable (maybe because I've some optical issues), how about using a standard TTF font like Code Page 437? (QEMU uses that one so it shouldn't be a problem).

there it two option in the font renderer, one is my own font set, and second is a public domain utf8 font set exported from linux. this second is disabled, becouse it takes too long to be compiled in, and not i used wrong font sets, so i would need to reexport different set. so this is currently disabled. you may can try set the smooth rendering settings, that may help a bit to be readable.

Bender wrote: Plus, the disk image browser only scans for floppy/, hdd/, etc. directories have you thought of making it scan user-specified directories?

you can just type any path in the box below the file browser.

Bender wrote: cat: /etc/sysconfig/language: No such file or directory

yes, i am aware of that - that is queryed by my renderer, not the emulator itself. it should not be an issue

Bender wrote: Does it support multiple languages?

this practicular software not. but my other softwares powered by this renderer mostly yes, thats why the language is queryed.

also, exiting is:
run / hard shutdown
run / exit software

file listing bug with windows fixed, package updated

Geri wrote:and no, its not better than qemu (how it could be?).

It could by supporting some new features or by extending existing features. If there is no such feature, then why do you think it is nice? Your "nice" has some base in the features supported - what is this base? What is nice about your system? What distinguishes your system? If there is clear "nice list" other readers can see benefits and get involved. And may be it will be useful for you to make it clear why your system is nice.

first i will fix the bugs (i alreday got several bug reports), and i will start to code new features only after that. it will take some time to reach a more serious product.

next release is scheduled to the end of year, with the folowing goals:

-4-5% bigger cycle/sec performance (have an idea, how)
-trying to make the emulation of the segmentation more effective (no idea, how)
-trying to make the paging more effective
-fixing cpuid, what givers garbage for the model name (thankyou x86 universe for making WRONG manuals)
-better 16-bit emulation (at least to be able to run some games without crashing the whole emulator)
-fixing the bugs in the emulator gui (i have a whole little list)
-having finally working ARM binaries (i was unable to compile the code on my wondermedia netbook yet)

I'd like to get a recent build .EXE whenever you get a chance, so that I can do some more testing. And if you could put it up somewhere that the rest of us could download it (github, codeplex, dropbox, etc. -- the .tk site above still seems to be unavailable), that would be awesome.

Thanks.

Spyder:
here is some direct licks for the package if somebody have issues:

http://users.ininet.hu/geri/tornado64/tornado64.zip
http://geri.comeze.com/tornado64/tornado64.zip

i hope can give new exes around the end of summer

i was finally able to compile it on arm (without optimization and strip), but does not runs becouse the implementation of long long int is buggy on the system for some mindfucking reason (does not works in most situations all)

O_O

Geri wrote:implementation of long long int is buggy

The size of integers is implementation defined; that is not a bug. (If you need a specific size, try int64_t instead.)

Octocontrabass: it wasnt about the size, it just compiles wrong code from it in some situations.