OSDev.org

finally i was able to compile and start the emulator on my arm netbook. however, it was unable to boot linux at the moment, the kernel says that file corrupted. maybe i just gave a too few ram for the emulator (i cant give more, the netbook have very few ram), or maybe an issue with g++ itself. i will lower the video memory size, and will try to add 48 mbyte ram for the emulator somehow, maybe then it will boot.

Are you mmapping the physical memory for the emulator?

Geri wrote:it just compiles wrong code from it in some situations

That's far more likely to be a problem with your code than the compiler.

Geri wrote:maybe i just gave a too few ram for the emulator (i cant give more, the netbook have very few ram)

It should work fine if you can give it at least 16MB.

So, I noticed that the CMOS registers for the current date/time work properly, except for the "Century" register -- 0x32. It should return hex value 0x20, but it appears to be returning a 0x01.

Also, I still can't get my OS to boot from a floppy image. I tried stepping through the code in the debugger, but Tornado64 tells me that I need a key to do that. How do I get a key?

Keep up the good work! And keep the bug fixes coming!

willedwards wrote:Are you mmapping the physical memory for the emulator?

no

Octocontrabass wrote:That's far more likely to be a problem with your code than the compiler.

no, its the compiler

Octocontrabass wrote:

Geri wrote:it just compiles wrong code from it in some situations

That's far more likely to be a problem with your code than the compiler.

Geri wrote:maybe i just gave a too few ram for the emulator (i cant give more, the netbook have very few ram)

It should work fine if you can give it at least 16MB.

i tryed with 30 mbyte. i will check on my other machines if that linux image is able to boot or not if i set the ram to 30 mbyte

SpyderTL wrote:So, I noticed that the CMOS registers for the current date/time work properly, except for the "Century" register -- 0x32. It should return hex value 0x20, but it appears to be returning a 0x01.

Also, I still can't get my OS to boot from a floppy image. I tried stepping through the code in the debugger, but Tornado64 tells me that I need a key to do that. How do I get a key?

Keep up the good work! And keep the bug fixes coming!

i will check that cmos register. (but possibly thats how it was implemented in the code i was front of me when i implemented this.)
i can send a license key on skype

Geri wrote:no, its the compiler

Can you provide an example of some code that doesn't compile correctly?

Octocontrabass wrote:

Geri wrote:no, its the compiler

Can you provide an example of some code that doesn't compile correctly?

i think i would, but i am not interested of spending time fixing the bugs in gcc

That doesn't mean we won't fix the bug in question for you.

Combuster wrote:That doesn't mean we won't fix the bug in question for you.

i alreday reported 1 or 2 bug then in the g++ project back then, i dont remember from what account, so i cant check them now, but i was aware them for a few months, it was still open with no reply or no movement at all. i dont think that spending days to find a strict testcase is a good idea for a project like that.

Can you tell us about the bug so we can write our own test cases?

Can you remember enough about your bug report to find it again?

Debugger works now, but I'm having a hard time using it. Maybe, I'm missing something but...

1. Everything is displayed as integers. Although I would have, years ago, liked this approach, now that I've been using hex values for so long, the integer formats are very difficult to convert in my head. I would be nice if you had the option to switch everything to hexadecimal format.

2. Instruction disassembly (on the top left) just shows byte values. It would be nice to see the disassembled instructions, if at all possible.

3. I don't see any way to add a break point, which is critical functionality for a debugger.

4. There is no way to start the machine in step mode. I would be nice if you could either start the machine in step mode, or switch to step mode and "restart" the machine at the first instruction. Then you could step through your boot loader one instruction at a time.

5. There's no easy way to view a specific memory location. You have to use the scroll bar and page up/down until to find the exact address that you are looking for. It would be nice if you could enter the address you wanted to see, and it would jump directly there.

Those are the biggest issues I'm having at the moment. I'm still trying to figure out why my floppy boot loader isn't working, but it's difficult with no break point support.

CD boot image works pretty well, though, so I may start there and troubleshoot my floppy access code after the OS is up and running.

Thanks, again.

Octocontrabass wrote:Can you tell us about the bug so we can write our own test cases?

Can you remember enough about your bug report to find it again?

not really, i had two issue i remember:

1.,

casting long long-s or unsigned long longs into int in function calls. (armel 32bit)

long long something=...;
...
int whatever(int bla){..}
..
whatever(something) <- resulted value 0 instead of the proper number
whatever((int)something) <- worked fine

on x86 it works fine.

2.,

comparing long long with another type of number in an IF (maybe it was int, i am unsure about now) resulted the whole expression to be interpreted in unsigned, or in some kind of very twisted ways, but it never executed the thing inside the expression. (armel 32 bit)

SpyderTL wrote:Debugger works now, but I'm having a hard time using it. Maybe, I'm missing something but...

1. Everything is displayed as integers. Although I would have, years ago, liked this approach, now that I've been using hex values for so long, the integer formats are very difficult to convert in my head. I would be nice if you had the option to switch everything to hexadecimal format.

good idea.

SpyderTL wrote: 2. Instruction disassembly (on the top left) just shows byte values. It would be nice to see the disassembled instructions, if at all possible.

not yet implemented, becouse of lack of the time

SpyderTL wrote: 3. I don't see any way to add a break point, which is critical functionality for a debugger.

hmm, that would require an extra if in the decoder. i must think on it if its possible to implement it easilly

SpyderTL wrote: 4. There is no way to start the machine in step mode. I would be nice if you could either start the machine in step mode, or switch to step mode and "restart" the machine at the first instruction. Then you could step through your boot loader one instruction at a time.

that would need the same if

SpyderTL wrote: 5. There's no easy way to view a specific memory location. You have to use the scroll bar and page up/down until to find the exact address that you are looking for. It would be nice if you could enter the address you wanted to see, and it would jump directly there.

good idea

SpyderTL wrote: Those are the biggest issues I'm having at the moment. I'm still trying to figure out why my floppy boot loader isn't working, but it's difficult with no break point support.

maybe you should wait for a keypress, turn on the debugger, press the key (on the virtual keyboard), then you can do step-by-step

SpyderTL wrote:
CD boot image works pretty well, though, so I may start there and troubleshoot my floppy access code after the OS is up and running.

Thanks, again.

maybe i just not implemented something that would need

i changed my mind, i will remove the debugger, since nobody uses it. i will focus on the speed of the emulation and compatibility.
removing means = will not enhanced any more, but stays in the software as a legacy feature.

-goal 1: i will fix the lot of 16 bit issues and crashes. this version will be released around (december, end of the year)
-goal 2: having an arm version compiled (2015 april?)
-goal 3: i will incrase the speed of the FPU. i have an idea, how to reach even 400 megaflops. (2015 april?)
-goal 4: i will try to boot some windows. windows xp would be awesome. (2015?)
-goal 5: i will try to add network support. (2016)
-goal 6: SMP support (2016)
-goal 7: hardware graphics acceleration support (2016)
-goal 8: MMX and SSE support (2017)
-goal 9: PAE support (2017)
-goal 10: SSE2 support (2017)
-goal 11: 64-bit support (2018)

Geri wrote:i changed my mind, i will remove the debugger, since nobody uses it.

Ahem...

You may want to consider doing what Bochs does, which is build two separate .exe's, one which has the debugger, but is slower, and one that does not and is faster.

But I would definitely use the debugger if it displayed values in hexadecimal, and had breakpoints.

Speaking of which, I'm still trying to figure out why I can't boot from floppy disk image. I think it may have something to do with the fact that I'm switching to 32-bit mode first, and then trying to send commands directly to the FDC controller (0x03f5), instead of going through the 16-bit BIOS calls.

For instance, when I send the GetVersion command (0x10), and then read back the results, I'm getting 0xFF, where on (almost) all other emulators and hardware, I'm getting 0x90. (VMWare returns 0x81... wtf?)

Anyway, should this direct FDC controller access be working in the current version that is located at the link above?

Thanks. Keep up the good work.