bochs

[df]

hmm.. i tried bochs 2.1 pre tonight.. first time i tried bochs in... aaaaaages...

i'm so used to vmware!

my os couldnt detect a bios32 area on bochs.. anyone know if this is right? bochs doesnt support pci??

I rely on PCI. hmm if it rules out running on bochs, i dont really care too much.

been doing a bit more work on my os lately... mmm minix driver. (and working on my minix toolset, like mtools).
more fs design, etc.

hmmm..

anyway...

back to tinkering on bochs... doesnt look like its going to do what I want tho....

maybe my pci code is just dodgy. even tho it works on vmware and my real machine...

[FlashBurn]

The normal Bochs version has no PCI support, but it has a BIOS32 I think so. You can Bochs compile so that it supports PCI, but this isn?t a good idea because it is in an alpha state.

[Guest]

btw i just wanted to know does BOCHS give you any reslts when you try int 15h e820 for a memory probe?
it hangs for me.

[FlashBurn]

Yeah, I use it for my memory detection code. Which version of Bochs do you use?

[Neo]

i use BOCHS 1.4 as well as the recent 2.0.2
could you show me the code you use (if you dont mind) just to see where i'm wrong my code works only on real hardware not in BOCHS.

[FlashBurn]

This is my function which I use for getting the mem size.

Code: Select all

;----------------------------
;   tries to get a mem map from the bios
init_smap:
   push es

   mov ax,50h
   mov es,ax
   xor di,di
   xor ebx,ebx

.loop
   mov eax,0e820h
   mov ecx,20
   mov edx,534D4150h

   int 15h

   jc .f0e801h

   add di,20

   and ebx,ebx
   jz .end

   jmp .loop

.f0e801h
   xor ecx,ecx
   xor edx,edx

   mov ax,0e801h
   int 15h

   jc .f88h

   and ax,ax
   jz .f0e801h@1

   mov cx,ax
   mov dx,bx

.f0e801h@1
   mov eax,100000h
   stosd
   xor eax,eax
   stosd
   mov ax,cx
   shl eax,10
   stosd
   xor eax,eax
   stosd
   mov eax,1
   stosd

   and dx,dx
   jz .end

   mov eax,1000000h
   stosd
   xor eax,eax
   stosd
   mov ax,dx
   shl eax,16
   stosd
   xor eax,eax
   stosd
   mov ax,1
   stosd

   jmp .end

.f88h
   mov ah,88h
   int 15h

   jc .cmos

   push ax

   mov eax,100000h
   stosd
   xor eax,eax
   stosd

   pop ax

   shl eax,10
   stosd
   xor eax,eax
   stosd
   mov ax,1
   stosd

   jmp .end

.cmos
   mov eax,100000h
   stosd
   xor eax,eax
   stosd

   mov al,18h
   out 70h,al
   in al,71h
   shl ax,8
   mov al,17h
   out 70h,al
   in al,71h
    shl eax,10

    stosd
    xor eax,eax
    stosd
    mov ax,1
    stosd

.end
   mov eax,0ffffffffh
   stosd
   pop es
   xor ax,ax
   ret
;----------------------------

[Curufir]

Great, another person who believes commenting is an optional extra to coding.

[Tim]

Curufir: I hope that was sarcasm.

[BI lazy]

*hehe* sarcasm is the honey on speech

[Neo]

Thanks a lot Flash but i just figured out that the problem was not anything to do with the int15 rather it was a silly mistake made by not restoring the registers after the call . Thanks anyway i am going through the code to see if i can improve mine anyway. btw BOCHS shows me 1mb less using int15 any idea why??
i use only e820 since i dont want to support older PC's sometime we've got to start realizing that older PC's are for the museum.

[FlashBurn]

Most OSs only use the memory above the 1MB mark, because in the first MB are the BIOS and other structures and also much of this mem should not used by your OS!

[Candy]

btw BOCHS shows me 1mb less using int15 any idea why??

Could be because of the memory gap between 15M and 16M, or because it doesn't show the 0-1M section. Also, it could be *some* piece of hard/software has reserved that bit of memory (acpi, bios, any?) and doesn't want it reported (if it is actually reserved, that's a bad implementation).

i use only e820 since i dont want to support older PC's sometime we've got to start realizing that older PC's are for the museum.

Agree with that in direction, not in specific bits. I think you should still support older pc's, but only as an afterthought. That is, if you can make the code reliable on modern PC's not counting in older models, that is a very good thing (the main set of target people use modern pc's, and a very common explanation among "normal users" is that it's just too old, so it would not even require your users to adjust). If you then want to support older platforms you can add extra bits of code that can be optionally loaded, to support the older computers. F.i., the implementation of USB keyboards + mice on my os will be native, USB root will be native, PS/2 will be in a separate module not defaultly loaded. For faster computers it results in top notch performance (which is something you want), and for slower computers it results in it still working, which is also what a lot of people want. Using old computers for their performance is not a good idea in any case.

As another side note, if you don't get to supporting the older products that is not going to backfire in 5 years. If you do not support the CURRENT products that WILL backfire. Make your OS forward-compatible, not backwards-compatible (see unix, windows).

[Neo]

yeah thats what i intend doing. no old relics only the new ones. btw will it be easy to port to the 64bit world or will that require rewriting of the entire code?
Any related info welcome.

[Therx]

Making it run on 64bit CPUs will require no work, or, if the CPU doesn't support PM then a small amount. Making the OS use all the millions of gigs of RAM will require a fair bit of work. Imagine all pointers are now longs instead of ints. And the assembly instructions will probally change a bit.

I hope that when the 64bit processors don't provide backward compatibility because that's something which has plagued the x86 for years

Pete

[nullify]

I hope that when the 64bit processors don't provide backward compatibility because that's something which has plagued the x86 for years

It's probably also the greatest strength of Intel's processors in the real world. Backwards compatibility is a double-edged sword.