aeBIOS Test Request
in [ASM]
|
From: Rod Pemberton on 10 Nov 2007 18:12 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message news:ff6rdb$oe9$1(a)aioe.org... > > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message > news:feu4dt$6go$1(a)aioe.org... > > > > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message > > news:fekdmu$24r$1(a)aioe.org... > > > 1010 RM0D > > > > 1013 PM06 (aeBIOS problem machine) > > > > 1014 (lockup) > 1027 RM01 Sorry about the delay, I'm fairly positive the program is going "into the weeds." I previously thought it might have been the EBDA being corrupted, but I'm now suspecting something to do with loadall386. But, I don't know for sure. What I do know is this: In bootsector.asm, disable irq0, trips loadall386. mov ax,001h out 021h,al Note that that is disabling irq0 prior to you reprogramming them. Disabling later has _NO_ effect. In fact, it must be disabled prior to the first int 0x13 in bootsector.asm. This makes no logical sense to me since it seems aeBIOS catches this... Could there be a possible interrupt in my BIOS not clearing an IRQ? You are letting the BIOS clear IRQ's for both RM an PM correct? In bootsector.asm, 0xcc memory before doing anything else. Triggers RM03 instead of RM01... This implies memory corruption to me. I'm clearing these regions since that is what the working machine accepted: 00500h-07bffh 0xcc 07e00h-0ffffh 0xcc (Obviously, even the good machine won't boot if BDA, 0400h-0500h, cleared.) Is it possible the loadall region is being overwritten (0800h-0866h)? Rod Pemberton
From: Rod Pemberton on 12 Nov 2007 22:52 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message news:fh5ds0$ojo$1(a)aioe.org... > > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message > news:ff6rdb$oe9$1(a)aioe.org... > > > > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message > > news:feu4dt$6go$1(a)aioe.org... > > > > > > "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote in message > > > news:fekdmu$24r$1(a)aioe.org... > > > > 1010 RM0D > > > > > > 1013 PM06 (aeBIOS problem machine) > > > > > > > 1014 (lockup) > > > > 1027 RM01 > > Sorry about the delay, I'm fairly positive the program is going "into the > weeds." I previously thought it might have been the EBDA being corrupted, > but I'm now suspecting something to do with loadall386. But, I don't know > for sure. What I do know is this: > > In bootsector.asm, disable irq0, trips loadall386. > > mov ax,001h > out 021h,al > > Note that that is disabling irq0 prior to you reprogramming them. Disabling > later has _NO_ effect. In fact, it must be disabled prior to the first int > 0x13 in bootsector.asm. This makes no logical sense to me since it seems > aeBIOS catches this... Could there be a possible interrupt in my BIOS not > clearing an IRQ? You are letting the BIOS clear IRQ's for both RM an PM > correct? > > In bootsector.asm, 0xcc memory before doing anything else. Triggers RM03 > instead of RM01... This implies memory corruption to me. I'm clearing > these regions since that is what the working machine accepted: > > 00500h-07bffh 0xcc > 07e00h-0ffffh 0xcc > > (Obviously, even the good machine won't boot if BDA, 0400h-0500h, cleared.) > > Is it possible the loadall region is being overwritten (0800h-0866h)? > Well, not sure if you're reading these anymore, but I think I found a bug. But, it didn't fix my fourth PM int 13h "off into the weeds" problem... This is what you have for rm_bios: use32 rm_bios: pushf ; half of this is used for 16-bit BIOS iret... (?) push eax ... use16 ... pop eax ..int: ; flags bad here, but not being reset for BIOS call... (?) call DWORD [cs:0] pushf ;half of this is used for pop below + upper half of push from above (?) push eax ... use32 ... pop eax popf ; is upper half of flags possibly bad here (?) ret It appears the sizes for the push and pop of the flag register are mismatched. It also appears that the flag register isn't being set properly for the BIOS call. This is what I think it should be, but I'm not familiar with all the interactions of aeBIOS: use32 rm_bios: pushfw ; wrong size above, 16-bit for BIOS iret pushfw ; missing, needed to pass to BIOS call push eax ... use16 ... pop eax popf ; missing, pass to BIOS call ..int: call DWORD [cs:0] pushfd ; wrong size above, need 32-bit for 32-bit pop push eax ... use32 ... pop eax popf ret Hope to hear from you... Rod Pemberton
From: Rod Pemberton on 20 Nov 2007 07:55
"Mike Gonta" <mikegonta(a)gmail.com> wrote in message news:0d760fbd-ad40-46b6-bfd0-e1bc559e5551(a)p69g2000hsa.googlegroups.com... > On Nov 18, 5:29 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > > > I changed the routine to use memory location 0 and 1Mb which works for both. > > Thanks Rod, I've implemented this in the latest version. > > > I just threw in a random delay loop. I'm not sure how much is needed. > > Some keyboard controller interfaces require a delay to "latch" > the A20 line. The original AT bios indicates 20 microseconds, also > implemented in the latest version. > > http://mikegonta.com/aeBIOS > 11/19 looks good on both. All apps work. No RM/PM errors. The only irregular thing I noticed is that the old machine outputs a space after the prompt when it first boots. Does the detect_a20 routine still work elsewhere? Now, you probably need those other guys to retest... ;-) Where do you plan to go from here? More functions? Anyway, good luck. Rod Pemberton PS. Next time, start another thread. I can't figure out where I am now... :-) PPS. Still haven't found out why the AV BIOS setting shadows... Nothing coming up in searches. Maybe it was "secret." |