From: Mike Gonta on 5 May 2010 18:43 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 6 May 2010 18:57 "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 6 May 2010 19:28 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 6 May 2010 20:00 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 6 May 2010 23:39 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
|
Next
|
Last
Pages: 1 2 3 4 Prev: New win32 Asm Programming Tutorial Next: The A20 story - Was pdBIOS32 (still is pdBIOS32) |