Hello Eric, On Wed, Aug 23, 2006 at 12:48:38PM +0200, Eric Auer wrote: > Hoi, mem 1.9a2 is not current - Blair should have 1.9a3 somewhere.
MEM.EXE 1.9a2 is part of the Beta9sr2 ISO. Strangely, the 1.0-Testing ISO does not contain MEM 1.9a3 but MEM 1.7 (which also crashes). Oh wait, some confusion arises because I was simply copying binaries from the ODIN directory. I just tested MEM.EXE 1.9a3 and it has the same issue as MEM 1.9a2. > Can you tell me where you downloaded 1.9a2? Then I can have a look > at the binary to try to find out why it crashes on pc xt. And do > not forget to test 1.9a2 :-). Do other things crash on pc xt? In fact I do not have a real XT; I discovered the bug on an emulator. But I am fairly confident about my analysis, and there is the fact that someone else already reported a crash on an actual PC. > For example does lbacache have the same bug? LBACACHE.COM version 19jun2005 is ok. On my emulator, it says "This software needs at least an 80386 CPU" and then exits cleanly. > And how about emm386 and himem? HIMEM.EXE (HIMEM64 3.12) crashes on "shl cx,4" even when invoked as "himem /?". Same problem with HIMEM64 3.23. Same problem with EMM386.EXE 2.08. Same problem with EMM386.EXE 2.23. > And cdrcache? CDRCACHE.SYS seems ok. It says "This software needs at least an 80386 CPU" and refuses to load. COMMAND.COM 0.84-pre2 from 1.0-Testing crashes on "push imm", which is a 286-only instruction form. I can not find the offending instruction in the source code and the surrounding code looks like it was generated by a compiler. Maybe a wrong compiler option? COMMAND.COM 0.84-pre from Beta9sr2 seems to be fine. The kernel on 1.0-Testing is 80386-only, which I think is a bad choice for an OS that claims to be DOS compatible. > The cdrcache and lbacache cpu test is the following: > > ; test if we have 386 or better: > pushf ; save flags > xor ax,ax > push ax > popf ; try to clear all bits > pushf > pop ax > and ax,0f000h > cmp ax,0f000h > jz noinst1 ; 4 msb stuck to 1: 808x or 80186 > mov ax,0f000h > push ax > popf ; try to set 4 msb > pushf > pop ax > test ax,0f000h > jz noinst1 ; 4 msb stuck to 0: 80286 > jmp short okinst1 > noinst1: ; failed, no 386 found > ... > okinst1: > popf ; good, it is a 386, now restore flags This is very close to what many people recommend. It should be ok as far as I can tell, certainly for 8086 detection. > The memory drivers use something like: > > _IS386 PROC NEAR > PUSHF ; save Flags > XOR AX,AX ; first ueberpruefen, if a8086/88 > PUSH AX ; this program abarbeitet, since > POPF ; the PUSHF-command always sets > PUSHF ; the bits 15..12 to 1, the 386 > POP AX ; sets Bit 15 always to Null (0?). > TEST AH,80H > JNZ SHORT @@NO_386 > MOV AX,7000H ; The IOPL-value remains on a 80386 > PUSH AX ; also kept after a POPF > POPF ; a 286 always sets it to Null > STI > PUSHF > POP AX > TEST AX,7000H > JZ SHORT @@NO_386 > POPF > mov ax,1 ; OK > RET > @@NO_386: > popf > xor ax,ax > ret > _IS386 ENDP The above also looks ok to me (without testing). > and in the other memory driver: > > proc check_cpu > pushf > xor ax,ax > push ax > popf > pushf > pop ax > and ah,0fh > cmp ah,0fh > je not386 > mov ah,7 > push ax > popf > pushf > pop ax > and ah,7 > je not386 > popf > clc > ret > not386: > popf > stc > ret > endp check_cpu This looks really weird; it tests only bits 8-11 of flags. I think (without actual testing) this will falsely detect 386 on 8086 as well as on 80286. Joris. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
