Real Mode Emulator v2

[Creature]

Seems like a very nice concept to me. I haven't tested it (might try soon, if I find the time), but it seems like a pretty nice initiative. If this would be integrated in more than one OS, people might even contribute by finding bugs (or possibly even committing code).

[thepowersgang]

@earlz:
It started as an 8086 emulator, but as it is I think I will expand it to support 386 real mode (so size overrides) so that it can support all BIOSes (except if they go to PMode themselves)
Sorry if I'm impinging on your project, but I just want to release the work I've done. Plus, this is designed to be plugged into any kernel with minimal work, just edit some (about 5) defines at the top of rme.c and insert.

[earlz]

@earlz:
It started as an 8086 emulator, but as it is I think I will expand it to support 386 real mode (so size overrides) so that it can support all BIOSes (except if they go to PMode themselves)
Sorry if I'm impinging on your project, but I just want to release the work I've done. Plus, this is designed to be plugged into any kernel with minimal work, just edit some (about 5) defines at the top of rme.c and insert.

No, your not impinging on my project or anything... just kinda saying.. if you wanna copy any code or whatever.. It's been dead for a while now anyway

The 386 real-mode bit does interest me.. I always wondered how I was going to do this if my project ever got far enough (and I had considered the whole emulating-BIOS thing, but I didn't design around it)

[thepowersgang]

Well, feel free to take a look at my git. Afik, 386 real mode is very similar to 8086 except it has the size overrides (and maybe some other opcodes).
I've been working on it this morning and it's almost ready to support the operand size override and I've completed the conditional jumps.
I would like to thank technik3k for pointing out some bugs.

[Creature]

It doesn't work with me but I'm not really sure if it's the emulator. The problem is I'm using C++ and I have to modify some of the source for it to work (some casts which should be implicit aren't implicit in C++), the typedefs (which isn't really a problem) and then the defines. I managed to compile it and plug it into my kernel, and tried testing int 10h with AX = 0x0013 (simple video mode switch), but all it did was flicker the colours (and sometimes crash). I'm not really sure if I set it up correctly, though (did exactly the same as shown in the test kernel).

[thepowersgang]

I'll upload a new git dump, but long story short, the posted version was rather buggy (I've fixed quite a few since I posted it, and I suspect there are more)
I suggest either getting the git dump from my site (which will almost always be the latest) or using the version I'm attaching to this post. (I'll also update the one on the OP)

[earlz]

It doesn't work with me but I'm not really sure if it's the emulator. The problem is I'm using C++ and I have to modify some of the source for it to work (some casts which should be implicit aren't implicit in C++), the typedefs (which isn't really a problem) and then the defines. I managed to compile it and plug it into my kernel, and tried testing int 10h with AX = 0x0013 (simple video mode switch), but all it did was flicker the colours (and sometimes crash). I'm not really sure if I set it up correctly, though (did exactly the same as shown in the test kernel).

Why didn't you just compile it in a C compiler and then link the object files to your C++ kernel?

[Creature]

It doesn't work with me but I'm not really sure if it's the emulator. The problem is I'm using C++ and I have to modify some of the source for it to work (some casts which should be implicit aren't implicit in C++), the typedefs (which isn't really a problem) and then the defines. I managed to compile it and plug it into my kernel, and tried testing int 10h with AX = 0x0013 (simple video mode switch), but all it did was flicker the colours (and sometimes crash). I'm not really sure if I set it up correctly, though (did exactly the same as shown in the test kernel).

Why didn't you just compile it in a C compiler and then link the object files to your C++ kernel?

I was going to, but then I realized (since I'm using Visual Studio) that I have rules that apply globally to every source file (event .c's) so C++ rules were getting applied (invalid parameters). So then I decided to compile it manually, but then that gave me environmental problems (sigh, Windows) and I gave up because I was too lazy to quickly fix it (and didn't really know whether it was the compiler or not). But then again, if it fails again, I'll try to do it thoroughly.

EDIT: I've tested it using a C compiler (and some dirty hacks to get my C++ memory allocation function into the C code without using system calls or anything, damn), and it still doesn't seem to work. Last time I got some crazy colours, but now it just hangs, I'll try to find out where exactly it hangs (or chokes on). I'm also not getting any error codes (the function just never returns).

[earlz]

It doesn't work with me but I'm not really sure if it's the emulator. The problem is I'm using C++ and I have to modify some of the source for it to work (some casts which should be implicit aren't implicit in C++), the typedefs (which isn't really a problem) and then the defines. I managed to compile it and plug it into my kernel, and tried testing int 10h with AX = 0x0013 (simple video mode switch), but all it did was flicker the colours (and sometimes crash). I'm not really sure if I set it up correctly, though (did exactly the same as shown in the test kernel).

Why didn't you just compile it in a C compiler and then link the object files to your C++ kernel?

I was going to, but then I realized (since I'm using Visual Studio) that I have rules that apply globally to every source file (event .c's) so C++ rules were getting applied (invalid parameters). So then I decided to compile it manually, but then that gave me environmental problems (sigh, Windows) and I gave up because I was too lazy to quickly fix it (and didn't really know whether it was the compiler or not). But then again, if it fails again, I'll try to do it thoroughly.

EDIT: I've tested it using a C compiler (and some dirty hacks to get my C++ memory allocation function into the C code without using system calls or anything, damn), and it still doesn't seem to work. Last time I got some crazy colours, but now it just hangs, I'll try to find out where exactly it hangs (or chokes on). I'm also not getting any error codes (the function just never returns).

This is why you use a Unix-like OS and gcc/pcc/some opensource C compiler

Are you trying to do this in an emulator or on a physical machine?

[thepowersgang]

@Creature
Also, do you have debug enabled in the emulator, and are you capturing the debug output? (It's sent to the bochs port 0xE9 hack and to COM1.)

[Creature]

@Creature
Also, do you have debug enabled in the emulator, and are you capturing the debug output? (It's sent to the bochs port 0xE9 hack and to COM1.)

I'm using Bochs as emulator (I could test it later on some real hardware, too, however) and I haven't really had the time yet to exactly find out where it hangs (only had a quick browse, but will look into more detail soon). It's probably obvious (since there is no crash and nothing happens now), that it must be choking inside the RME_Int_DoOpcode function, since it's being called in an infinite loop (which breaks on a return value, which it probably never gets).

I also know the printf debug output is useful, I however don't have any kind of printf function in my kernel (heretic!), I only have an IO class with insertion and extraction operators (I guess even the simplest implementation could print the format though), so I temporarily disabled it.

EDIT: It apparently gets stuck (note I grabbed a quick and dirty printf implementation ) at ADD (MR) AL DS:[BX+SI+0xx] and I'm guessing the 0xx is the faulty printf implementation talking.

[thepowersgang]

@Creature
Um... that opcode corresponds to 00 00, I suggest checking the emulated memory mappings, because it seems that you're not executing code.

[Creature]

@Creature
Um... that opcode corresponds to 00 00, I suggest checking the emulated memory mappings, because it seems that you're not executing code.

The entire lower 1 MB is identity mapped in my paging system, meaning only the allocated memory can cause problems, I've tried mapping higher memory, but only setting Emu->Memory[0] to 0 will make it work for me, which then results in me being able to switch back and forth from graphics mode but getting stuck afterwards (doesn't seem very healthy to use address 0 anyway, but it's the only thing that'll make it work). I've also tried not using any form of paging (and using a placement address, as I see in your testing heap), which still hangs.

[thepowersgang]

@Creature:
Could you post the log here? Because I doubt it would actually lock up just with 00 00, the problem would probably be a jmp/call somewhere jumping to invalid memory.

Also, mapping emu->Memory[0] to 0 should cause errors when the first block of memory is read because, by default, the emulator's memory access functions NULL check.

[Creature]

@Creature:
Could you post the log here? Because I doubt it would actually lock up just with 00 00, the problem would probably be a jmp/call somewhere jumping to invalid memory.

Also, mapping emu->Memory[0] to 0 should cause errors when the first block of memory is read because, by default, the emulator's memory access functions NULL check.

Well, I'm not sure what log you're referring to, but I'm guessing you want the debug output from the run, which is:

Code: Select all

(311) [26C] 0:26C
ADD (MR) AL DS:[BX+SI+0x0]         ; 0 0
(312) [26E] 0:26E
ADD (MR) AL DS:[BX+SI+0x0]         ; 0 0
...

Then it just goes on and on incrementing these numbers. I also found nothing of interest in the Bochs log. Since it seems to work fine for you, I'm guessing I'm doing something wrong (probably something really stupid or something I missed), so I'll post the source here (which is almost an identical copy of the testing kernel, because I didn't want to mess anything up that might make it not work):

Code: Select all

		tRME_State *Emu;

		void *LowCache = malloc(RME_BLOCK_SIZE);
		memset(LowCache, 0, RME_BLOCK_SIZE + 1);

		Emu = RME_CreateState();

		Emu->Memory[0] = (byte *) LowCache;

		for(size_t i(RME_BLOCK_SIZE); i < 0x100000; i += RME_BLOCK_SIZE)
			Emu->Memory[i / RME_BLOCK_SIZE] = (byte *) i;

		Emu->AX.W = 0x13;
		
		int Ret = RME_CallInt(Emu, 0x10);

		switch( Ret )
		{
		case RME_ERR_OK:
			IO << "\n--- Emulator exited successfully!\n";
			IO << "Emu->AX = 0x%04x\n" << Emu->AX.W;
			break;
		case RME_ERR_INVAL:
			IO << "\n--- ERROR: Invalid parameters\n";
			break;
		case RME_ERR_BADMEM:
			IO << "\n--- ERROR: Emulator accessed bad memory\n";
			break;
		case RME_ERR_UNDEFOPCODE:
			IO << "\n--- ERROR: Emulator hit an undefined opcode\n";
			break;
		case RME_ERR_DIVERR:
			IO << "\n--- ERROR: Division Fault\n";
			break;
		default:
			IO << "\n--- ERROR: Unknown error %i\n" << Ret;
			break;
		}