From: Mike Gonta on
On May 5, 8:06 am, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:

> The reason I ask is because even if the IVT is set to 0000:0400h using a few
> stack items shouldn't blow out the IVT.  Right?  From my notes, interrupts
> above 0x7A aren't used anymore.  There were some higher interrupts used for
> BASIC ROM's PC's had them...  Isn't that correct?  If so, that means there
> should be about 536 bytes (out of 1024) in the upper IVT that can be used
> for a stack without issues...

A very good point which needs investigation.
I do not believe that the reason some PC's failed to boot had anything
to do with limited size of the BIOS stack.
The entire boot session uses very little stack space.

I have commented out the stack initialization in boot.asm in this
latest release and
fixed the problem in rm2pm.asm.

The problem was in rm2pm where I did not convert the real mode ss:sp
to the protected mode esp as is done in pdBIOS32.
Rather I assumed that ss was 0.
I've added a few lines to rm2pm to save the ss and esp to global
memory for use by a new app - "stack.bin".
After the boot up hit enter to return to the command line and enter
"stack" or "stack.bin" (no quotes).
This app will print to the screen the ss:esp value at boot up.

I have the following results:

Pentium, 75 MHz, 32 Mb, PhoenixBIOS ver 4.04.7 rev 00.00.09 1995
00000000:000003DA

Pentium, 133 MHz, 16 Mb, Phoenix NoteBIOS 4.0 (Notebook PC) ver A04
10/03/96
00000000:000003E0

Pentium 4, 1.4 GHz, 1 Gb, Award Bios v6.00PG 2001
00000000:000003D6

Pentium M, 1.6 GHz, 480 Mb, Phoenix Bios F.14, HP Pavilion dv 1000
Notebook PC
00000000:000003C4

> PS. Yes, booted on a newer machine...

Thanks Rod.
How about the older machines? I might have some non 386 instructions
in the code that could be replaced.


http://mikegonta.com/pdBIOS32

Mike Gonta
look and see - many look but few see

From: Rod Pemberton on
"Mike Gonta" <mikegonta(a)gmail.com> wrote in message
news:ba665122-012d-4fbf-818a-69514d160bc4(a)a34g2000yqn.googlegroups.com...
> > PS. Yes, booted on a newer machine...
>
> How about the older machines?
>

One of my older machines works. A different older machines is waiting for
me to do some electrical repairs... Sigh, it's been waiting over a year
now. And, the other old machine hangs.

> After the boot up hit enter to return to the command line and enter
> "stack" or "stack.bin" (no quotes).
> This app will print to the screen the ss:esp value at boot up.
>
> I have the following results:
>
> Pentium, 75 MHz, 32 Mb, PhoenixBIOS ver 4.04.7 rev 00.00.09 1995
> 00000000:000003DA
>
> Pentium, 133 MHz, 16 Mb, Phoenix NoteBIOS 4.0 (Notebook PC) ver A04
> 10/03/96
> 00000000:000003E0
>
> Pentium 4, 1.4 GHz, 1 Gb, Award Bios v6.00PG 2001
> 00000000:000003D6
>
> Pentium M, 1.6 GHz, 480 Mb, Phoenix Bios F.14, HP Pavilion dv 1000
> Notebook PC
> 00000000:000003C4
>

For the updated image w/ stack.bin...


Intel PII, 450Mhz, w/ PhoenixBios v4.0 r6.0
00000000:000003C4

Athlon X2, 2.8Ghz, MSI BIOS v1.9
00000000:00007BB2

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). It seems to be lacking PS/2
port. This issue came up when Ben Lunt's FYSOS and Kristof Benes OS. I
don't remember how many A20 methods I tested on it though... I may have
skipped the BIOS PS/2 A20 call etc. But, after some trivial testing, the
A20 doesn't seem to be the issue. I commented out the call to port_92_A20
and it's branch to .exit in change_A20 in rm2pm, updated LBA 1, and still
saw the issue. I tried two keyboards in this machine. The problem was
there with both. I tried one of the keyboards in another machine and the
problem wasn't there. So, I don't think it's the keyboard, but it may be an
issue with the motherboard's keyboard logic. AIR, the A20 was real slow to
turn change state. On one boot, it made to the A:\ prompt, but wouldn't
type. At this point, I can only take a random guess that a needed delay or
slightly different keyboard init sequence is needed.


AMD K6-2, 500Mhz
(It's an Award 4.51 PG version too, according to dmidecode.exe output...)
http://www.nongnu.org/dmidecode/
(Sorry, it's still out of service with electrical issues...)

parts for new mATX machine!
(Unassembled, on the to do list... :-)

HTH,


Rod Pemberton


From: Mike Gonta on
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.

Thanks again for the help Rod.


Mike Gonta
look and see - many look but few see

http://mikegonta.com/pdBIOS32

From: Mike Gonta on
On May 6, 6:57 pm, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:

> For the updated image w/ stack.bin...
>
> Intel PII, 450Mhz, w/ PhoenixBios v4.0 r6.0
>    00000000:000003C4
>
> Athlon X2, 2.8Ghz, MSI BIOS v1.9
>    00000000:00007BB2

Thanks for the report Rod.
I've been finding other similar results as well, that is, either in
the
400h or 7C00h areas. In saving the esp value I added 4 to
account for the return address but forgot about the pushad at the
start of rm2pm.asm. The displayed values need 32 added to them.
That still means that there is some junk on the stack which
varies depending on the BIOS version. The Bochs BIOS in qemu
shows 00000000:0000FFFE.

I've corrected this in the latest release. I've also assembled
everything in NASM with "cpu 386" to confirm that with the exception
of the cpuid instruction in cpuid.asm all instructions are 386
friendly.


Mike Gonta
look and see - many look but few see

http://mikegonta.com/pdBIOS32
From: s_dubrovich on
On May 5, 5:43 pm, Mike Gonta <mikego...(a)gmail.com> wrote:
> On May 5, 8:06 am, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:
>
> > The reason I ask is because even if the IVT is set to 0000:0400h using a few
> > stack items shouldn't blow out the IVT.  Right?  From my notes, interrupts
> > above 0x7A aren't used anymore.  There were some higher interrupts used for
> > BASIC ROM's PC's had them...  Isn't that correct?  If so, that means there
> > should be about 536 bytes (out of 1024) in the upper IVT that can be used
> > for a stack without issues...
>
> A very good point which needs investigation.
> I do not believe that the reason some PC's failed to boot had anything
> to do with limited size of the BIOS stack.
> The entire boot session uses very little stack space.
>
You could be correct...

> I have commented out the stack initialization in boot.asm in this
> latest release and
> fixed the problem in rm2pm.asm.
>

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.

Steve


> The problem was in rm2pm where I did not convert the real mode ss:sp
> to the protected mode esp as is done in pdBIOS32.
> Rather I assumed that ss was 0.
> I've added a few lines to rm2pm to save the ss and esp to global
> memory for use by a new app - "stack.bin".
> After the boot up hit enter to return to the command line and enter
> "stack" or "stack.bin" (no quotes).
> This app will print to the screen the ss:esp value at boot up.
>
> I have the following results:
>
> Pentium, 75 MHz, 32 Mb, PhoenixBIOS ver 4.04.7 rev 00.00.09 1995
>   00000000:000003DA
>
> Pentium, 133 MHz, 16 Mb, Phoenix NoteBIOS 4.0 (Notebook PC) ver A04
> 10/03/96
>   00000000:000003E0
>
> Pentium 4, 1.4 GHz, 1 Gb, Award Bios v6.00PG 2001
>   00000000:000003D6
>
> Pentium M, 1.6 GHz, 480 Mb, Phoenix Bios F.14, HP Pavilion dv 1000
> Notebook PC
>   00000000:000003C4
>
> > PS.  Yes, booted on a newer machine...
>
> Thanks Rod.
> How about the older machines? I might have some non 386 instructions
> in the code that could be replaced.
>
> http://mikegonta.com/pdBIOS32
>
> Mike Gonta
> look and see - many look but few see