aeBIOS Test Request
in [ASM]
|
From: Frank Kotler on 23 Sep 2007 03:41 Mike Gonta wrote: > http://mikegonta.com/aeBIOS 20070923 Not a start image - Press Any Key (same as 20070922, but on a new line now) My /proc/cpuinfo claims: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 1 model name : Intel(R) Pentium(R) 4 CPU 1.80GHz stepping : 2 cpu MHz : 1816.203 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 3617.58 .... although I suspect a FDC problem. Dunno what that is - "barely workin'"... may not be a problem with your code... Best, Frank
From: Rod Pemberton on 23 Sep 2007 19:48 "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message news:fd43de$9v8$1(a)aioe.org... > "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message > news:fd413k$3v4$1(a)aioe.org... > > "Mike Gonta" <mikegonta(a)gmail.com> wrote in message > > news:1190480060.304450.255970(a)n39g2000hsh.googlegroups.com... > > > Testing feedback would be greatly appreciated. > > > > > > > 9/22 same... [2nd stage not loaded - halted] > > 9/23 changed... FDC failed - halted RP
From: geezer on 23 Sep 2007 21:59 Mike Gonta <mikegonta(a)gmail.com> wrote: >On Sep 22, 1:19 pm, "Benjamin David Lunt" <zf...(a)frontiernet.net> >wrote: >> Are you reading all 35 sectors with one read? > >Correct. Then maybe you need to patch the diskette parameter table. See INT 1Eh in Ralf Brown's list. The table could be in ROM, so you copy it to RAM (0000:0522h seems to be the traditional location for the copy), patch the sectors-per-track value, then point the INT 1Eh vector to the patched table. ================================================================ From MS-DOS 7.0 (Win95) bootsector ================================================================ {snip} 0000:7C41 33C9 xor cx,cx ; SS=0 0000:7C43 8ED1 mov ss,cx {snip} 0000:7C48 16 push ss 0000:7C49 07 pop es ; ES=0 0000:7C4A BD7800 mov bp,0x78 ; SS:BP --> INT 1Eh vector 0000:7C4D C57600 lds si,[bp+0x0] ; DS:SI --> old diskette parameter table (DPT) {snip} 0000:7C54 BF2205 mov di,0x522 0000:7C57 897E00 mov [bp+0x0],di ; new INT 1Eh vector --> new DPT at 0000:0522 0000:7C5A 894E02 mov [bp+0x2],cx 0000:7C5D B10B mov cl,0xb ; copy old DPT (11 bytes) to new DPT 0000:7C5F FC cld 0000:7C60 F3A4 rep movsb 0000:7C62 06 push es ; DS=0 0000:7C63 1F pop ds 0000:7C64 BD007C mov bp,0x7c00 ; SS:BP --> this bootsector 0000:7C67 C645FE0F mov byte [di-0x2],0xf ; new head settle time=15 ms (why?) 0000:7C6B 8B4618 mov ax,[bp+0x18] 0000:7C6E 8845F9 mov [di-0x7],al ; new sectors/track in DPT = sectors/track from this bootsector {snip} ================================================================ From Linux (prior to version 2.6) bootsect.s ================================================================ {snip} /* * Many BIOS's default disk parameter tables will not * recognize multi-sector reads beyond the maximum sector number * specified in the default diskette parameter tables - this may * mean 7 sectors in some cases. * * Since single sector reads are slow and out of the question, * we must take care of this by creating new parameter tables * (for the first disk) in RAM. We will set the maximum sector * count to 36 - the most we will encounter on an ED 2.88. * * High doesn't hurt. Low does. * * Segments are as follows: ds=es=ss=cs - INITSEG, * fs = 0, gs is unused. */ ! cx contains 0 from rep movsw above mov fs,cx mov bx,#0x78 ! fs:bx is parameter table address push ds seg fs lds si,(bx) ! ds:si is source mov cl,#6 ! copy 12 bytes cld push di rep movsw pop di pop ds movb 4(di),*36 ! patch sector count seg fs mov (bx),di seg fs mov 2(bx),es
From: Rod Pemberton on 26 Sep 2007 04:29 "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message news:fd6trd$tha$1(a)aioe.org... > > "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message > news:fd43de$9v8$1(a)aioe.org... > > "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message > > news:fd413k$3v4$1(a)aioe.org... > > > "Mike Gonta" <mikegonta(a)gmail.com> wrote in message > > > news:1190480060.304450.255970(a)n39g2000hsh.googlegroups.com... > > > > Testing feedback would be greatly appreciated. > > > > > > > > > > 9/22 same... [2nd stage not loaded - halted] > > > > > 9/23 changed... > > FDC failed - halted > Sorry, I didn't notice the 9/24 update. 9/24 changed... 06 (on green background) Bad news: QEMU doesn't like it now. Interesting news: I have a utility which boots A: after DOS is loaded. It works for FYSOS, but not DOS... It hasn't been working for aeBIOS. But, it now "works" for aeBIOS 9/24 version. However, 06 still comes up - only _after_ the first hello world/press a key messages. Since the "working" machine loads and displays hello world/press a key over and over without waiting (even on 9/24), the 06 gives me the impression that DOS "enabled" something, your OS ran due to this, your OS "disabled" something when it tried to reload/rerun. Rod Pemberton
From: Rod Pemberton on 26 Sep 2007 05:28
"Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message news:fdd545$aqa$1(a)aioe.org... > > "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message > news:fd6trd$tha$1(a)aioe.org... > > > > "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message > > news:fd43de$9v8$1(a)aioe.org... > > > "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message > > > news:fd413k$3v4$1(a)aioe.org... > > > > "Mike Gonta" <mikegonta(a)gmail.com> wrote in message > > > > news:1190480060.304450.255970(a)n39g2000hsh.googlegroups.com... > > > > > Testing feedback would be greatly appreciated. > > > > > > > > > > > > > 9/22 same... [2nd stage not loaded - halted] > > > > > > > > 9/23 changed... > > > > FDC failed - halted > > > > Sorry, I didn't notice the 9/24 update. > > 9/24 changed... > 06 (on green background) > > Bad news: QEMU doesn't like it now. > > Interesting news: I have a utility which boots A: after DOS is loaded. It > works for FYSOS, but not DOS... It hasn't been working for aeBIOS. But, it > now "works" for aeBIOS 9/24 version. However, 06 still comes up - only > _after_ the first hello world/press a key messages. Since the "working" > machine loads and displays hello world/press a key over and over without > waiting (even on 9/24), the 06 gives me the impression that DOS "enabled" > something, your OS ran due to this, your OS "disabled" something when it > tried to reload/rerun. > Just read the 9/24 docs: "Should int 0 to int 0Fh occur, a 2 digit hex number will appear..." 06 appeared which is invalid opcode... MG Previously: > No unreal mode, all code is pmode, except for the transition to the real mode BIOS. RB int. list: "INT 06 C - CPU-generated (80186+) - INVALID OPCODE" "...many 386 BIOSes emulate the 80286 undocumented LOADALL instruction which was removed from the 80386+" Now, I'm wondering if 286 LOADALL is actually the invalid opcode? Rod Pemberton |