Prev: New win32 Asm Programming Tutorial
Next: The A20 story - Was pdBIOS32 (still is pdBIOS32)
From: Mike Gonta on 7 May 2010 20:03
On May 6, 11:39 pm, s_dubrov...(a)yahoo.com wrote:

> however this latest version hangs before completing the diskette read,
> on the dell latitude CPi laptop, Pentium MMX. - I never make it to the
> prompt or signon.

It sounds like pdBIOS32 and friends might be stepping on the BIOS
stack.
I've put back the stack initialization in the boot sector.
Let's see where this machines stack is at.

Thank you Steve for the help.


Mike Gonta
look and see - many look but few see

http://mikegonta.com/pdBIOS32
From: Rod Pemberton on 7 May 2010 21:56
"Mike Gonta" <mikegonta(a)gmail.com> wrote in message
news:4752e30b-acb6-4105-b18a-8465cf52f300(a)k29g2000yqh.googlegroups.com...
On May 6, 6:57 pm, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:
> > Pentium-MMX, 233Mhz, Award Modular BIOS v4.51 PG
> > **hangs** at end of initial Hello world app.
> >
> > It generally won't proceed to the A:\ prompt. AFAICT, it'll only enable
> > the A20 via the so called "at method" (via 8042).
>
> All of the apps run in high memory, so the problem won't be A20.
> It may have something to do with the port_60_A20 code in rm2pm.
> Delete the "start.txt" file so that the hello app won't be loaded and
> comment out
> "call change_A20" in rm2pm so that the A20 is not enabled. The START
> monitor
> runs in low memory, from the command prompt try the built in functions
> - cls, ver and exit.

When done, warning about A20, press F1, then cls, ver, and exit work in the
monitor.

If I comment out two lines in change_A20:

call port_92_A20
jne .exit
; call port_60_A20
; jne .exit
xor BYTE [cs:A20_STATE], 1

It reliably enters the monitor too. That probably eliminates port_92_A20
and wait_A20 as issues. That was against ...506 image. The port_92_A20 not
being an issue surprise me a bit...


Rod Pemberton


From: s_dubrovich on 7 May 2010 22:03
On May 7, 7:03 pm, Mike Gonta <mikego...(a)gmail.com> wrote:
> On May 6, 11:39 pm, s_dubrov...(a)yahoo.com wrote:
>
> > however this latest version hangs before completing the diskette read,
> > on the dell latitude CPi laptop, Pentium MMX. - I never make it to the
> > prompt or signon.
>
> It sounds like pdBIOS32 and friends might be stepping on the BIOS
> stack.
> I've put back the stack initialization in the boot sector.
> Let's see where this machines stack is at.
>
> Thank you Steve for the help.
>
Sure.. from power-on cold boot & ctrl-alt-del reboot, both give:
A:\>stack
00000030:00000100

-I guess that says something :)

Please note that when I first looked at this issue, years ago now, it
is system dependent whether the SS:SP values were the same between
cold boot & ctrl-alt-del reboot. Also, FS&GS are not necessarily zero
on reboot.

-I've got a design question. The 32bit pm code is org'ed at 10`0000h,
are there any rm dependencies which would prevent basing the pm
descriptors at 10`0000h (actually, 10`FFF0h) so that pm code could be
org'ed at 0h?

FFFF:FFFFh -> 10`FFEFh + 1 -> 10`FFF0h.

-thx,

Steve


> Mike Gonta
> look and see - many look but few see
>
> http://mikegonta.com/pdBIOS32

From: James Harris on 8 May 2010 04:13
On 8 May, 02:56, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:

....

> If I comment out two lines in change_A20:
>
>   call port_92_A20
>   jne .exit
> ;  call port_60_A20
> ;  jne .exit
>   xor BYTE [cs:A20_STATE], 1
>
> It reliably enters the monitor too.

IIRC port 0x92 (fast a20) is not safe to use on all machines. Does the
code carry out some sort of check before it tries the port?

>  That probably eliminates port_92_A20
> and wait_A20 as issues.  That was against ...506 image.  The port_92_A20 not
> being an issue surprise me a bit...

Port 0x60 is slower but, IIRC, it is easier to verify its existence.

James
From: Mike Gonta on 8 May 2010 06:57
On May 7, 10:03 pm, s_dubrov...(a)yahoo.com wrote:

> Sure.. from power-on cold boot & ctrl-alt-del reboot, both give:
> A:\>stack
> 00000030:00000100
>
> -I guess that says something :)

Thanks Steve, it sure does.
I've corrected the bug in rm2pm.asm where I was using the pm
stack pointer before converting from the rm version. It was no
problem when ss was 0 because real mode 0:offset is the same
as protected mode offset.
I've removed the stack initialization in boot.asm, as I am convinced
that the BIOS stack (even when located in the lower IVT) is sufficient
for the initial setup code.
As a side note, on one PC I tested when I used 0:7C00h for
the stack pointer it froze when rm2pm returned to the boot sector.
Other values such as 0:7B00h and 0:0FFFEh were OK and this
PC showed a BIOS stack in the 0:400 region. The strange thing is
that the "start" monitor uses 7C00h and that PC worked fine as
long as I didn't use that as the initial value. Of course the latest
release tested OK with this PC.


Mike Gonta
look and see - many look but few see

http://mikegonta.com/pdBIOS32
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: New win32 Asm Programming Tutorial
Next: The A20 story - Was pdBIOS32 (still is pdBIOS32)