Has anybody tested Bochs 2.4.2?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
~
Member
Member
Posts: 1228
Joined: Tue Mar 06, 2007 11:17 am
Libera.chat IRC: ArcheFire

Has anybody tested Bochs 2.4.2?

Post by ~ »

Is there a different format in the Bochs memory dump when the "Suspend" button is used to save and inspect the contents of memory, in which there is a zeroed area at locations 0x100000-0x1FFFFF of such image (but apparently and functionally not taken into account when Bochs is running)?

Recently I upgraded from Bochs 2.3.7.

Now, I have a problem in which I try to enable A20 line and when I try to write to location 0x100000 the location 0x200000 is actually written even when DS, ES, FS and GS are 0 and I point to [ESI].

I know I have set up right the rest of structures like GDT to access data in this way, since the Bochs CPU logs show that all common data registers have base address of 0 and a 4GB limit.

Does somebody know what is wrong with the A20 enabling functions below? I try to use them until A20 gets enabled, and it seems to get enabled by the "enableA20_KBC" function, but I have the problem above.

With Bochs 2.3.7 I don't have that problem.

Is that a problem with Bochs that somebody has seen yet or is there something wrong with my code, which tries to enable via keyboard controller, BIOS and fast A20?



Code: Select all

;This function waits until the
;Keybard Controller is ready to
;accept commands.
;;
;;;
  KeybCtrl_waitUntilCommandable:
  push ax


  .waitUntilReady:
   in al,0x64    ;Port 0x64 is the Status
                 ;Register of the keyboard
                 ;controller port located
                 ;on the motherboard.

   test al,00000010b ;We see if bit 1 of the returned
                     ;byte at 0x64 is set to 1, which
                     ;means that the controller is NOT
                     ;ready to accept commands. It means
                     ;"Input Buffer Full (port 0x60 or 0x64);
                     ;don't write yet".



   jnz .waitUntilReady  ;Repeat until bit 1 of byte from
                        ;port 0x64 is cleared to 0 or, in
                        ;other words, until the keyboard
                        ;controller is ready to accept
                        ;commands. It would mean "Input
                        ;Buffer Empty (port 0x60 or 0x64); can
                        ;be written".

     ;Note that writing the Input Buffer through
     ;port 0x64 causes the byte to be interpreted
     ;as a command.
     ;
     ;And if we write the Input Buffer through
     ;port 0x60 causes the byte to be interpreted
     ;as data, usually as a parameter to an immediate
     ;previously sent command at port 0x64.

  pop ax
    ret



enableA20_KBC:
;;;Wait for controller to accept
;;;commands
;;
;
 call KeybCtrl_waitUntilCommandable


;;;Write Output Port (Command -- Step 1/2):
;;;Write Output Port (Command -- Step 1/2):
;;;Write Output Port (Command -- Step 1/2):
  mov al,0xD1    ;This command is to write the
                 ;status byte. This command is
                 ;called WRITE OUTPUT PORT.

  out 0x64,al    ;Here we send the command, and
                 ;it gets processed.


;;;Wait for controller to accept
;;;commands
;;
;
 call KeybCtrl_waitUntilCommandable


;;;Write The Output Port (Command Parameter -- Step 2/2):
;;;Write The Output Port (Command Parameter -- Step 2/2):
;;;Write The Output Port (Command Parameter -- Step 2/2):
  mov al,11111111b ;This is a data byte to serve
                   ;as a parameter to the previous
                   ;controller command (0xD1). We
                   ;are setting the necessary bits
                   ;here to the normal operation
                   ;of the controller, and, of course,
                   ;it is here that we enable the A20
                   ;Address Line by setting its bit
                   ;to 1.
  ;bit 0-Normal           (1) or Reset CPU (0)
  ;bit 1-Enable A20       (1) or Disable A20 (0)
  ;bit 2-Data to Mouse    (1) or Disabled (0)
  ;bit 3-Mouse Clock      (1) or Disabled (0)
  ;bit 4-IRQ1 Active      (1) or IRQ1 Inactive (0)
  ;bit 5-IRQ12 Active     (1) or IRQ12 Inactive (0)
  ;bit 6-Keyboard Clock   (1) or Disabled (0)
  ;bit 7-Data to Keyboard (1) or Disabled (0)


  out 0x60,al    ;We send this bit-set to the
                 ;data port of the keyboard. At
                 ;this point is where really the
                 ;A20 line gets enabled.


ret





enableA20_BIOS:
 sti
 mov ax,2401h
 int 15h


ret




enableA20_Fast:
  in al,0x92
  test al,00000010b
  jnz .no92
    or  al,00000010b
    and al,0xFE
    out 0x92, al

  .no92:

ret




checkA20_unreal:
  pushad

  ;Test if we can reach very much memory in 16-bit mode
  ;and also test for A20 enabled by using an odd megabyte



  ;;Clear any past test results
  ;;;
    mov esi,1048576*1
    push dword[esi]     ;safeguard contents
    mov dword[esi],0    ;Our intended address

;    mov esi,1048576*0
    push dword[si]     ;safeguard contents
    mov dword[si],0    ;An A20-disabled wrapped address



;  mov esi,1048576*1
  mov dword[esi],"1@2@" ;Place here a colorful "12"
  mov ebx,[esi]         ;Store for later comparison
  pop dword[esi]        ;restore original


;  mov esi,1048576*0     ;See the pontetially wrapped up address
  mov ecx,[si]         ;Store for the comparison
  pop dword[si]        ;restore original





  cmp ebx,ecx           ;Compare to see
  jne .noA20error       ;If they are different, A20 is enabled an all is OK
   stc  ;gate error
  jmp .ended


  .noA20error:
   clc  ;all OK


 .ended:

 popad
ret
stlw
Member
Member
Posts: 357
Joined: Fri Apr 04, 2008 6:43 am
Contact:

Re: Has anybody tested Bochs 2.4.2?

Post by stlw »

Is there a different format in the Bochs memory dump when the "Suspend" button is used to save and inspect the contents of memory, in which there is a zeroed area at locations 0x100000-0x1FFFFF of such image (but apparently and functionally not taken into account when Bochs is running)?

Recently I upgraded from Bochs 2.3.7.
The format of memory dump from "Suspend" button is completely different between 2.3.7 and 2.4.2.
In the Bochs 2.4.2 Bochs manages memory allocated for RAM in different way, allowing "holes" of never touched memory to be never allocated.
Look on the Bochs 2.4.2 memory "save example":

Code: Select all

memory = {  ram = memory.ram
  len = 268435456
  allocated = 268435456
  used_blocks = 255
  mapping = {
    blk0 = 0
    blk1 = 2
    blk2 = 3
    blk3 = 8
    blk4 = 9
    blk5 = 10
    blk6 = 11
    blk7 = 12
    blk8 = 13
    blk9 = 247
    blk10 = 248
    blk11 = 249
    blk12 = 250
    blk13 = 251
    blk14 = 252
    blk15 = 4294967295
    blk16 = 14
    blk17 = 16
    blk18 = 19
    blk19 = 20
    blk20 = 245

In this example you could see how the blocks actually allocated/mapped (and they not done in-order). blk15 for example never touched at all and therefore never been allocated.
If you just keep "memory" image from 2.3.7 or any other Bochs build and read without taking into account all this mapping story - you will miss.

Stanislav
Post Reply