The Place to Start for Operating System Developers
https://f.osdev.org/
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 anywaythepowersgang wrote:@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.
Why didn't you just compile it in a C compiler and then link the object files to your C++ kernel?Creature wrote: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).
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.earlz wrote:Why didn't you just compile it in a C compiler and then link the object files to your C++ kernel?Creature wrote: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).
This is why you use a Unix-like OS and gcc/pcc/some opensource C compilerCreature wrote: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.earlz wrote:Why didn't you just compile it in a C compiler and then link the object files to your C++ kernel?Creature wrote: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).
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).
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).thepowersgang wrote:@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.)
) at ADD (MR) AL DS:[BX+SI+0xx] and I'm guessing the 0xx is the faulty printf implementation talking.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 wrote:@Creature
Um... that opcode corresponds to 00 00, I suggest checking the emulated memory mappings, because it seems that you're not executing code.
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:thepowersgang wrote:@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.
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
...
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;
}