Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Ninho

E-mail

23.04.2008, 10:06
 

comment on flushing predecode queue (pre-Pentium) (DOSX)

Post reply

Hi Japheth ! Dunnow if this place is appropriate for discussing this, or even if you are interested in discussing, anyway... briefly reviewed your HIMEMX code and comments, and I think there's a point not absolutely correct here :

mov cr0,eax
;--- the 80386 (and 80486?) need a short delay after switching to PM
;--- before a segment register can be set! Any instruction is sufficient.
dec ax ; clear PE bit
mov ds,dx

;;;; ... etc.

The point is not "a short delay" is required, it's there are incorrectly predecoded instructions ; the predecode queue, distinct from the prefetch queue, holds up to three complete instructions in the 386 ! If the "mov ds,dx" instruction followed the "mov cr0,eax" immediately, for sure it would be predecoded while still in real mode, and when subsequently executed, even though PE=1, it wouldn't do what you expect from a protected mode segment load.

How many predecoded instructions will be in the predecode queue at a given point in time depends in a complex way upon the length of instructions and their alignment (for filling/refilling the prefetch queue) so, since your code has been time-tested, I assume the bug does not manifest itself any more. But it's not a robust fix either.

The 486 changed how instructions were prefetched and predecoded. Because of the on-die cache, the prefetch queue is in fact smaller if it even exists - details are not easily found and difficult to assert by experiment without snooping hardware cycles. Also, decoding is done very differently from the 286 and 386. The details of course were never documented by Intel.

Anyway, the good news is there is a 100% correct and documented fix : you must do a near jmp $+2 after the move to cr0. This flushes both the instruction prefetch and predecode queues.


HTH,

---
Ninho
Japheth

Homepage

Germany (South),
23.04.2008, 19:54

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Hi Japheth ! Dunnow if this place is appropriate for discussing this, or
> even if you are interested in discussing, anyway... briefly reviewed your
> HIMEMX code and comments, and I think there's a point not absolutely
> correct here :
...

> Anyway, the good news is there is a 100% correct and documented fix : you
> must do a near jmp $+2 after the move to cr0. This flushes both the
> instruction prefetch and predecode queues.
This might be true, but I don't own a working 80386 system and cannot change working code just because theory suggests that it may have troubles on a 80386. I need facts. :-D (Just in case, your second name isn't Eric?)

---
MS-DOS forever!
Ninho

E-mail

23.04.2008, 20:22

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> This might be true, but I don't own a working 80386 system and cannot
> change working code just because theory suggests that it may have troubles
> on a 80386. I need facts. :-D (Just in case, your second name isn't Eric?)
Hey! This is not a theory, it's one of the few things consistently and correctly documented in Intel manuals; and it's not just the 386, the 486 as well needs it - I used to have the printed Intel manual. Mind you, I'm not sure whether it even is not still officially recommended, or required, for some later processors (not just Intel's). When doing a mode switch, in general you'll need both : a near jump (to flush the queue) and a far transfer (to fully load CS and its attributes). Of course, in this particular piece of code, you don't want the far jump, since you're only setting up "big real" mode, but you need the short jmp.

I'm really surprised you are not aware of this point, considering the depth of your experience.

And no, I'm not an Eric ;=)

Regards...

---
Ninho
Japheth

Homepage

Germany (South),
23.04.2008, 21:04

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Hey! This is not a theory, it's one of the few things consistently and
> correctly documented in Intel manuals; and it's not just the 386, the 486
> as well needs it - I used to have the printed Intel manual.
I have several working 486 which don't need it...

> Mind you, I'm
> not sure whether it even is not still officially recommended, or required,
> for some later processors (not just Intel's).
No. Pentium and above will always "serialize" certain opcodes, including moves to control registers.

> When doing a mode switch, in
> general you'll need both : a near jump (to flush the queue) and a far
> transfer (to fully load CS and its attributes). Of course, in this
> particular piece of code, you don't want the far jump, since you're only
> setting up "big real" mode, but you need the short jmp.
>
> I'm really surprised you are not aware of this point, considering the
> depth of your experience.

I AM aware of this, indeed, I had some rather longish discussions with someone calling himself Eric (Auer) about this topic. Amazing how one can waste time about a piece of code approc. 6 lines long ... :-D

---
MS-DOS forever!
Ninho

E-mail

23.04.2008, 23:32

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> No. Pentium and above will always "serialize" certain opcodes, including
> moves to control registers.
Anyway, what I wrote is I'm not sure if Intel retired their prescription of a short jump after mode change, in the general architecture manuals, regardless of if it's needed on a particular processor.

> > I'm really surprised you are not aware of this point, considering the
> > depth of your experience.
>
> I AM aware of this, indeed, I had some rather longish discussions with
> someone calling himself Eric (Auer) about this topic. Amazing how one can
> waste time about a piece of code approc. 6 lines long ... :-D
Don't worry, I'm too old to waste time on something like that, and I won't be using the driver anyway. I sure would recompile it with the jmp short if I were to use it and even more compellingly, if my seal were put on it, because that would be the right thing to do : it is prescribed on certain processors, and it will cost virtually nothing where it isn't (modern processors will 'execute' the jmp $+2 in zero time, hidden in the pipeline.)

OK, my 386 Mobo is dead but I'll try himemx on one of my 486 DXs in a few days, I'm sure it works since you checked it, but it may have been only by chance (instruction length, code alignment, cache refill. The 486 is very sensitive to code alignment within 16-byte boundaries). A future compile might change that, exposing the bug, assuming it is one.

Later...

---
Ninho
Rugxulo

Homepage

Usono,
24.04.2008, 19:18
(edited by Rugxulo, 24.04.2008, 19:28)

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Anyway, what I wrote is I'm not sure if Intel retired their prescription
> of a short jump after mode change
I'm no x86 guru by any means, but the only example I could easily find (through a semi-brief search via Google) was this (not very helpful, I know, but anyways ...).

> > > I'm really surprised you are not aware of this point, considering the
> > > depth of your experience.

I tested it for him on my Intel 486 Sx, and 3.31 works while 3.30 doesn't. However, Japheth's AMD 486 worked fine either way. AFAIK, no one else reported any issues.

> OK, my 386 Mobo is dead but I'll try himemx on one of my 486 DXs
Jason Burgon (GVFM) and Blair Campbell (FreeDOS dude) both have 386s, so you could try asking one of them if you're truly paranoid.

P.S. I tried reassembling HIMEMX 3.32, but here's the problem:

* JWASM17S.ZIP has a (NT-only?) WLINK.EXE that is apparently modified (but buggy?), so using that won't work (no .EXE generated!), but WLINK/DOS from 1.7a-RC1 does:

---------------------------------------------------------------------
JWasm v1.7, based on Open Watcom Assembler (WASM)
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
himemx.asm: 3836 lines, 0 warnings, 0 errors
Open Watcom Linker Version 1.7
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Warning! W1107: undefined system name: dos
loading object files
Error! E3002: ** internal ** - format not decided
---------------------------------------------------------------------

JWasm v1.7, based on Open Watcom Assembler (WASM)
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
himemx.asm: 3836 lines, 0 warnings, 0 errors
Open Watcom Linker Version 1.7
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Warning! W1107: undefined system name: dos
loading object files
creating map file
creating a DOS executable
---------------------------------------------------------------------

And notice how it whines about no "system name: dos" (defined in \BINW\WLSYSTEM.LNK, I think). Of course it isn't needed (no libs used), but it seems to think it is.

---------------------------------------------------------------------
system begin dos
libpath %WATCOM%/lib286
libpath %WATCOM%/lib286/dos
format dos ^
end
---------------------------------------------------------------------

And here's the .BAT I used to make it (I generally dislike makefiles):

---------------------------------------------------------------------
@echo off
if not exist himemx.asm goto end
for %%a in (lst map obj exe err) do if exist %%a del %%a
jwasmd himemx.asm -Fl=himemx.lst
wlink system dos file himemx.obj name himemx.exe op map=himemx.map
:end
---------------------------------------------------------------------

Of course, it's not a real .LST generated, so I had to (weakly) attempt to make my own (via HIEW):

---------------------------------------------------------------------

reset_ureal:
 00000D76: BA1000                       mov         dx,00010 ;"  "     
set_ureal:       
 00000D79: 90                           nop                                   
 00000D7A: 2E0F01161800                 lgdt        cs:[00018]                 
 00000D80: 0F20C0                       mov         eax,cr0                   
 00000D83: 40                           inc         ax                         
 00000D84: 0F22C0                       mov         cr0,eax                   
 00000D87: 48                           dec         ax                         
 00000D88: 8EDA                         mov         ds,dx                     
 00000D8A: 8EC2                         mov         es,dx                     
 00000D8C: 0F22C0                       mov         cr0,eax                   
 00000D8F: C3                           retn 

---------------------------------------------------------------------

Hope some of that helps! :-P

EDIT:

> the predecode queue, distinct from the prefetch queue, holds up to
> three complete instructions in the 386 !
Isn't the longest 32-bit instruction only 16 bytes (vs. 6 for 8086 or 10?? for 286)? And any CALL or JMP flushes the prefetch queue, right? The 386 is only partially pipelined (unlike the 486, which is fully). 386's fastest instruction takes two clocks under ideal circumstances. (That's all I know, maybe not relevant here, this is beyond me!)

---
Know your limits.h
RayeR

Homepage

CZ,
24.04.2008, 22:34

@ Rugxulo
 

comment on flushing predecode queue (pre-Pentium)

Post reply

I remember that I saw some JMP trick in pmode switching routine written as an example in old Processors of intel book by Brandejs and it was described as a need to flush pipeline. But I cannot post it exactly I returned the book to my friend some months ago.
Anyway I have a 386SX notebook laying around so I can test himemx there. But what should I expect? I will hang or reboot or what if there will be a failure?

---
DOS gives me freedom to unlimited HW access.
Ninho

E-mail

25.04.2008, 08:11

@ RayeR
 

comment on flushing predecode queue (pre-Pentium)

Post reply

Hi ! By all means do try it on your 386 if you can, but be aware no amount of testing will validate this buggy code.
Unless you collected all revisions of all versions of x86 by all manufacturers,
(and yes, I successfully tried the offending code on my i486DX2-66 revision 5.)


1- programmer realises there is a problem (presumably he's been bitten...)
2- progammer makes up a story about needing an (unspecified) "delay" (between mode switch & segment reload).
3- programmer shuffles instructions, program seems to work. But the fix is wrong! Inserting only one mode-independent instruction between the move to CR0 and the move to DS (or whatever segment) isn't enough to ensure it will work on *all* IA32 processors and clone. The right and only fix is to make a jump, as I - and others, it seems - have explained.

It's amusing Japheth told me he desn't care about "theories", yet the programmer made up a bogus theory about 386/486 needing a delay as said in point 2 above; the truth is, not a delay is needed, but any predecoded instruction which depends on processor mode must be purged. An example, not involving segment load, would be executing an instruction invalid in real mode, such as LTR, just after setting Protect enable.

I hope this modest but crucial piece is corrected before it make its way to FreeDOS or other open-source projects. The fix is simple and proven.

Nuff said... I'm using Linux anyway ;=)

---
Ninho
Japheth

Homepage

Germany (South),
25.04.2008, 08:58

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> I hope this modest but crucial piece is corrected before it make its way
> to FreeDOS or other open-source projects. The fix is simple and proven.

The source is open, do what you want with it, create a HimemXX version with your patch! Just don't tell me what I have to do! I won't obey.

---
MS-DOS forever!
Ninho

E-mail

25.04.2008, 09:23

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > I hope this modest but crucial piece is corrected before it make its way
> > to FreeDOS or other open-source projects. The fix is simple and proven.
>
> The source is open, do what you want with it, create a HimemXX version
> with your patch! Just don't tell me what I have to do! I won't
> obey.
I told you, not what you have to do, but what you did not do right. You take your responsibility. I'm an old man, not willing to engage in stupid fights of egoes. I hoped you would be open to friendly critique, which it seems you aren't, too baaaad ;=) Be reassured this is my last message on this point.

I don't use FreeDOS myself; I only hope this particularwrong code sequence won't be embarked, due to developpers' negligence, into software intended for the general public (although, it seems to work on 486DX and later, and few unsuspicious people must be using older procs).


Kind regards

---
Ninho
Japheth

Homepage

Germany (South),
25.04.2008, 09:31

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> I told you, not what you have to do, but what you did not do right. You
> take your responsibility. I'm an old man, not willing to engage in stupid
> fights of egoes. I hoped you would be open to friendly critique, which it
> seems you aren't, too baaaad ;=)
I'm what is called in German "beratungsresistent" (mind is closed for advices).

That is - simply spoken - I just do what I want to do and I believe what I want to believe.

---
MS-DOS forever!
Ninho

E-mail

25.04.2008, 09:52

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> I'm what is called in German "beratungsresistent" (mind is closed for
> advices).
> That is - simply spoken - I just do what I want to do and I believe what I
> want to believe.
Even when your beliefs stand contrary both to logics and evidence ? There is also a word for the pathological stubbornness cases in my own language, and there must exist one in German too. Or maybe there isn't one, and that would explain how your beloved Führer sacrified von Paulus's armies near Stalingrad. OMG...

---
Ninho
rr

Homepage E-mail

Berlin, Germany,
25.04.2008, 10:00

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Even when your beliefs stand contrary both to logics and evidence ? There
> is also a word for the pathological stubbornness cases in my own language,
> and there must exist one in German too. Or maybe there isn't one, and that
> would explain how your beloved Führer sacrified von Paulus's armies near
> Stalingrad. OMG...
Oh no, not another political debate! Be warned...

---
Forum admin
Ninho

E-mail

25.04.2008, 10:09
(edited by Ninho, 25.04.2008, 10:30)

@ rr
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Oh no, not another political debate! Be warned...
No, not political, that's a historic notation and medical analogy ;=)

Not meant to be taken too seriously either.

---
Ninho
Steve

Homepage E-mail

US,
25.04.2008, 11:05

@ rr
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Oh no, not another political debate! Be warned...
Looks like we have a student of Herr Professor Jack on the premises.
Steve

Homepage E-mail

US,
25.04.2008, 11:04

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Even when your beliefs stand contrary both to logics and evidence ? There
> is also a word for the pathological stubbornness cases in my own language,
> and there must exist one in German too. Or maybe there isn't one, and that
> would explain how your beloved Führer sacrified von Paulus's armies near
> Stalingrad. OMG...
Let's see: A programmer's refusal to believe a critique is serious enough to act on, is equivalent to ordering millions of people killed for nothing.

Of course (slapping my head) - an amazing psychological insight.
rr

Homepage E-mail

Berlin, Germany,
25.04.2008, 11:11

@ Steve
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Let's see: A programmer's refusal to believe a critique is serious enough
> to act on, is equivalent to ordering millions of people killed for
> nothing.
Oh no, not another political debate! Be warned... applies to you too, Steve!

---
Forum admin
Japheth

Homepage

Germany (South),
25.04.2008, 11:18

@ rr
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Oh no, not another political debate! Be warned... applies to you
> too, Steve!
According to the forum rules it's not forbidden to make some political statements here. If I understand the rules correctly, capital crimes are "top-posts" and "bottom-posts" ... :-D

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
25.04.2008, 11:21

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > Oh no, not another political debate! Be warned... applies to you
> > too, Steve!
>
> According to the forum rules it's not forbidden to make some political
> statements here. If I understand the rules correctly, capital crimes are
> "top-posts" and "bottom-posts" ... :-D
This forum is about DOS. So anything besides computers is also a crime. This is a law now. :cool:

---
Forum admin
Japheth

Homepage

Germany (South),
25.04.2008, 11:24

@ rr
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> This forum is about DOS. So anything besides computers is also a crime.
I see. However, changing the rules on the fly a slightly dangerous thing to do ...

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
25.04.2008, 11:41

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > This forum is about DOS. So anything besides computers is also a crime.
>
> I see. However, changing the rules on the fly a slightly dangerous thing
> to do ...
No, this is real life. You can't know in advance how stupid people will act in future.

---
Forum admin
Japheth

Homepage

Germany (South),
25.04.2008, 13:57

@ rr
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> No, this is real life. You can't know in advance how stupid people will
> act in future.
From a legal point of view - the forum rules are part of the "contract" between you, the admin, and the "normal" members - you'll have to either accept that the new rules can't be applied to old members or you must force all old members to reregister and thus accept the new rules ...

Ok, I'll stop it...

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
25.04.2008, 14:34

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> From a legal point of view - the forum rules are part of the "contract"
> between you, the admin, and the "normal" members - you'll have to either
> accept that the new rules can't be applied to old members or you must
> force all old members to reregister and thus accept the new rules ...
You're right. But anybody is free to leave, if he doesn't want to accept new or modified rules.

> Ok, I'll stop it...
I appreciate.
Let's do something more useful for DOS in our (sp|r)are time! :-)
For example I'm still waiting for your 'QEMU keyboard bug' test case or the SoundBlaster emulation JLM, ... ;-)

---
Forum admin
Ninho

E-mail

25.04.2008, 11:34

@ rr
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > Let's see: A programmer's refusal to believe a critique is serious enough
> > to act on, is equivalent to ordering millions of people killed for
> > nothing.
My comment was slightly inappropriate, admittedly, and not meant seriously, as I noted, and you deliberately ignored the notice. Pfff! Don't you have more serious things to do with your time than create a totally artificial rhetoric ?

Please stop this now !

> Oh no, not another political debate! Be warned... applies to you
> too, Steve!
Thanks Rr!

---
Ninho
Steve

Homepage E-mail

US,
25.04.2008, 11:55
(edited by Steve, 25.04.2008, 12:09)

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> My comment was slightly inappropriate, admittedly,
Right. There is no large difference between a 386 and World War II.

> and not meant seriously, as I noted, and you deliberately ignored the notice.
1) I ignored nothing - it wasn't in the message I responded to. 2) I didn't know what you would be writing later.

> Don't you have more serious things to do with your time than create a
> totally artificial rhetoric ?
I didn't write the message in your name.

> Please stop this now !
You make it difficult when your criticisms become personal.

> > Oh no, not another political debate! Be warned... applies to you
> > too, Steve!
>
> Thanks Rr!
Thanks for what? He wasn't taking your side when he called for an end to the discussion you provoked.
Ninho

E-mail

25.04.2008, 13:09

@ Steve
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > and not meant seriously, as I noted, and you deliberately ignored the notice.
>
> 1) I ignored nothing - it wasn't in the message I responded to. 2) I
> didn't know what you would be writing later.
I wrote it an hour /earlier/, not later, than your message, This why I thought you deliberately ignored it. Alright, so you'd not seen it then;

(snip cause I'm not going to argue much. You're the Boss anyway)

> > Please stop this now !
>
> You make it difficult when your criticisms become personal.
Nothing personal. I was irated at Japeth self-proclaimed stubbornness, that's all there was.

> > > Oh no, not another political debate! Be warned... applies to you
> > > too, Steve!
> >
> > Thanks Rr!
>
> Thanks for what? He wasn't taking your side when he called for an end to
> the discussion you provoked.
Thank him for noting that his warning applied to you too!

Sorry, /you/ started this long and useless aside (look at the indentation and look at the time stamps). Had you read calmly the messages existing one hour prior to yours, instead of jumping onto your keyboard, I assume you wouldn't have.

OK ? Can everyone cool down ?

---
Ninho
Steve

Homepage E-mail

US,
25.04.2008, 14:18

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> I wrote it an hour /earlier/, not later, than your message, This why I
> thought you deliberately ignored it. Alright, so you'd not seen it then;

I have by now checked the timestamps and seen that you posted the second message before my response to the first. But when I was writing, it wasn't on my screen because I hadn't refreshed recently enough. If you want to call that ignoring, go ahead. Will you accept my promise to refresh every 2 minutes or so, to keep up with you?

> (snip cause I'm not going to argue much. You're the Boss anyway)
Is that a Forum position?

> Sorry, /you/ started this long and useless aside
Did you really think a lunatic and offensive comparison would go unremarked?

> OK ? Can everyone cool down ?
OK. Flame away, I'm now insulated.
Rugxulo

Homepage

Usono,
25.04.2008, 20:55

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > I told you, not what you have to do, but what you did not do right. You
> > take your responsibility. I'm an old man, not willing to engage in
> stupid
> > fights of egoes. I hoped you would be open to friendly critique, which
> it
> > seems you aren't, too baaaad ;=)
>
> I'm what is called in German "beratungsresistent" (mind is closed for
> advices).
>
> That is - simply spoken - I just do what I want to do and I believe what I
> want to believe.
Correct me if I'm wrong, but this is due to you (and most people) not having enough test machines to verify. And, since it currently works for you (and everyone else that we know of), it shouldn't be changed unless it can be literally proven that it won't work for someone else. So far that hasn't happened. Maybe in 3.33 a comment can be added explaining the "JMP $+2" workaround (in case anyone decides to try it).

P.S. Japheth, HIMEMXX is what you sent me (unofficially) after 3.30 but before the 3.31 fix. Like I said, it didn't work on my old 486 (although Devore's last HIMEM 3.26 did) until HIMEMX 3.31. Maybe I'll try e-mailing Blair and Jason to try their 386s. Or somebody here could perhaps ask for testing on the FreeDOS users mailing list??

EDIT: And don't forget, worst case scenario: just use XMGR or HIMEM 3.26 or FDXMS286 instead (and if that works and HIMEMX doesn't, then it may be a bug).
RayeR

Homepage

CZ,
26.04.2008, 00:54

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Hi ! By all means do try it on your 386 if you can, but be aware no amount
> of testing will validate this buggy code.

I tested himemx v3.32 on intel 386SX/25MHz and it was initialized OK. But it hanged when I tried to start DOS Navigator (it runs OK with MS himem.sys or QEMM 9)

---
DOS gives me freedom to unlimited HW access.
Japheth

Homepage

Germany (South),
26.04.2008, 09:49

@ RayeR
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> I tested himemx v3.32 on intel 386SX/25MHz and it was initialized OK. But
> it hanged when I tried to start DOS Navigator (it runs OK with MS
> himem.sys or QEMM 9)
Good. Half of the job is done. And now, what happens if you add this jmp $+2 to the code? (I know you're a good programmer, so don't play the stupid!).

---
MS-DOS forever!
Ninho

E-mail

26.04.2008, 10:29

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

Said by RayeR :
> > I tested himemx v3.32 on intel 386SX/25MHz and it was initialized OK.
> > But it hanged when I tried to start DOS Navigator (it runs OK with MS
> > himem.sys or QEMM 9)
Good job! I /knew/ it would hang or crash at the first XMS block move. Glad you did test, and no need to remind you, have backups ready when you do this kind of hazardous operations !

Japheth says :
> Good. Half of the job is done. And now, what happens if you add this jmp
> $+2 to the code? (I know you're a good programmer, so don't play the
> stupid!).
I'm confident it'll work, you Saint Thomas ! (No "Godwin law" involved this time, I suppose :-) ) You see, "testing" can prove a program wrong, it /cannot/ prove it right. Only deductive logic can, and this lesson was first taught by a genius named Dijkstra in the 60s-70s; unfortunately almost nobody in the industry and very few in the Academy listened to him.


Hopefully, RayeR will be coming back soon confirming the fix, and this issue I helped raise shall be solved for the benefit of everyone. I'm not sorry I came to this board.

---
Ninho
Rugxulo

Homepage

Usono,
26.04.2008, 20:57

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Hopefully, RayeR will be coming back soon confirming the fix, and this
> issue I helped raise shall be solved for the benefit of everyone. I'm not
> sorry I came to this board.
Bug reports are always welcome, fixes even moreso. So thanks! ;-)
RayeR

Homepage

CZ,
27.04.2008, 01:52

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Good. Half of the job is done. And now, what happens if you add this jmp
> $+2 to the code? (I know you're a good programmer, so don't play the
> stupid!).
Hey dude, a little bit suspension ;-)
1st I'm not familiar with OW/MASM. I installed OW 1.8 but had some troubles during compiling - wasm:
himemx.asm(159): Error! E094: This instruction is not supported
himemx.asm(300): Error! E065: Operator is expected
himemx.asm(300): Error! E045: Initializer value too large
...
So I had to pirate MASM, then it complied OK.

Now I can confirm that Ninho's patch works. DN now runs fine.

Here's my patched src+bin signed as himemx 3.33
and here's photo of this old testing machine (it has AMD 386SX-25 not intel that i said before).

---
DOS gives me freedom to unlimited HW access.
Rugxulo

Homepage

Usono,
27.04.2008, 05:36

@ RayeR
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > Good. Half of the job is done. And now, what happens if you add this jmp
> > $+2 to the code? (I know you're a good programmer, so don't play the
> > stupid!).
>
> Hey dude, a little bit suspension ;-)
> 1st I'm not familiar with OW/MASM. I installed OW 1.8 but had some
> troubles during compiling - wasm:
OW 1.8 isn't released yet, so at best you're only using a beta. Anyways, you don't need that (or MASM), use Japheth's forked JWasm.

> himemx.asm(159): Error! E094: This instruction is not supported
> himemx.asm(300): Error! E065: Operator is expected
> himemx.asm(300): Error! E045: Initializer value too large
Obviously WASM leaves a bit to be desired in its MASM compatibility.

> Now I can confirm that Ninho's patch works. DN now runs fine.
Just to be clear, what was it that DN didn't do before that it does now (file copying?)? And what version of DN (DN151, DNOSP, NDN)?

> Here's my patched src+bin
> signed as himemx 3.33
> and here's photo of this old
> testing machine (it has AMD 386SX-25 not intel that i said before).

Just curious, but what kinds of programs do you run on it? Games? Programming (e.g. DJGPP)? How big is the HD? How much RAM? (Just curious.)
RayeR

Homepage

CZ,
27.04.2008, 13:20

@ Rugxulo
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> you don't need that (or MASM), use Japheth's forked
> JWasm.
Aha, I just looked in MAKE where was written that I need wasm 1.7j or masm 6+.
I got masm 6.11

> Just to be clear, what was it that DN didn't do before that it does now
> (file copying?)? And what version of DN (DN151, DNOSP, NDN)?
DN didn't start at all. It displayed bottom toolbar and hanged. Probably alloc some XMS on start. I used this version:
DN+ by Rainbow based on DN Open Source v1.51.04/DOS. Later DNOSP runs much slower on slow machines.

> Just curious, but what kinds of programs do you run on it? Games?
> Programming (e.g. DJGPP)? How big is the HD? How much RAM? (Just curious.)
It has 4MB RAM (1MB onboard+some expansion module). It also has IIT387 coproc. Original HDD was dead (i think 120M) and I replaced it by 500M. It'n not usable for games, it hasn't soundcard and LCD is very ugly & slow monochrome. I used it before for some simple programming in Borland Pascal. Also have prehistoric DJGPP GCC 2.7.2 on it but it's very slow. I have installed win 3.1 and monkey linux (minidistro runs on UMSDOS FS) but it's quite slow.
Now I have much better NB but i just like old HW to my collection :)

---
DOS gives me freedom to unlimited HW access.
Rugxulo

Homepage

Usono,
27.04.2008, 20:20

@ RayeR
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> DN didn't start at all. It displayed bottom toolbar and hanged. Probably
> alloc some XMS on start. I used this version:
> DN+
> by Rainbow based on DN Open Source v1.51.04/DOS. Later DNOSP runs
> much slower on slow machines.
Ah, okay. BTW, there's a real mode and a DPMI version of DNOSP. (Can't remember, but NDN might need a 486DX. I know it definitely needs an FPU, but do try it anyways if you're adventurous.)

> > Just curious, but what kinds of programs do you run on it? Games?
> > Programming (e.g. DJGPP)? How big is the HD? How much RAM? (Just
> curious.)
>
> It has 4MB RAM (1MB onboard+some expansion module).
Same as my first 486. Not a huge amount, but enough to run DOS + Win 3.x and games like King's Quest 6 (which could run with text or sound, floppy or CD-ROM version).

> It also has IIT387
> coproc.

That's good, at least. My 486s were always Sx (no FPU). Not essential for most stuff but certainly nice.

> Original HDD was dead (i think 120M) and I replaced it by 500M.
Should be enough for reasonable DOS use. ;-)

> It'n not usable for games, it hasn't soundcard and LCD is very ugly & slow
> monochrome.

Well, it may not be an ideal game machine, but there are still some games that could be fun (Dungeon Crawl? NetHack? ADOM?). (I regret the lack of soundcard more than the mono screen.)

> I used it before for some simple programming in Borland
> Pascal. Also have prehistoric DJGPP GCC 2.7.2 on it but it's very slow.

DJGPP203.UHA (djdev 2.03p2 + gcc 2.95.3 + bnu 2.16.1 + cwsdpmi r5 + rm)

Granted, you'll have to unpack on a newer machine with more RAM first and repack with something your 386 can handle (.bz2 or .zip or whatever; use "bzip2 -sd" to decompress if necessary). But at least it's kinda modern (2.95.3 is dated 2001 and support through PPro). Yeah, DJGPP is kinda slow (even though it started out on a 386), just avoid newer versions (even slower!), and avoid -O2 if you can help it.

Or try OpenWatcom. ;-)

Or try smaller compilers (Micro C, Small C, BCC/Dev86DOS, Desmet C, Turbo C).

> I
> have installed win 3.1 and monkey linux (minidistro runs on UMSDOS FS) but
> it's quite slow.
The RAM thing is probably the main barrier (although a 386 is no speed demon either, and neither is a 486). I think UMSDOS is kinda slow itself, though, and obviously Linux is not very 386- or 486-friendly. Maybe NetBSD or Minix would be a better fit?

> Now I have much better NB but i just like old HW to my collection :)
Yes, it's good for testing or just playing around with.
flox

Homepage

27.04.2008, 22:08

@ Rugxulo
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Ah, okay. BTW, there's a real mode and a DPMI version of
> DNOSP.
The last version of DNOSP I used was a DPMI16 version. I don't think that it had changed. But DNOSP is dead... DN/2 won't support DOS anymore.
Steve

Homepage E-mail

US,
28.04.2008, 02:44

@ flox
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> The last version of DNOSP I used was a DPMI16 version. I don't think that
> it had changed. But DNOSP is dead... DN/2 won't support DOS anymore.
DNOSP was last updated in 2007:
http://beta.dnosp.com/
marcov

27.04.2008, 15:46

@ Rugxulo
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Just curious, but what kinds of programs do you run on it? Games?
> Programming (e.g. DJGPP)? How big is the HD? How much RAM? (Just curious.)
(I kept my 386 till two,three years ago to test Free Pascal/go32v2 software FPU support)
Ninho

E-mail

27.04.2008, 10:10

@ RayeR
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> > Good. Half of the job is done. And now, what happens if you add this jmp
> > $+2 to the code?
>
> ...
> So I had to pirate MASM, then it complied OK.
>
> Now I can confirm that Ninho's patch works. DN now runs fine.
>
> Here's my patched src+bin
> signed as himemx 3.33
> and here's photo of this old
> testing machine (it has AMD 386SX-25 not intel that i said before).

Nice (the photo is, too!)...

Now I didn't have a look at the JEMMEX code, we can suspect it has the same error setting the 'unreal' mode. The best in my opinion, would be for Japheth - who owns or at least maintains that nice stuff if I understand clearly - to review and patch the whole lot himself.

Good day

---
Ninho
Japheth

Homepage

Germany (South),
28.04.2008, 11:50

@ Ninho
 

comment on flushing predecode queue (pre-Pentium)

Post reply

> Now I didn't have a look at the JEMMEX code, we can suspect it has the
> same error setting the 'unreal' mode.
That's unlikely.

---
MS-DOS forever!
tom

Homepage

Germany (West),
27.04.2008, 14:46

@ Japheth
 

comment on flushing predecode queue (pre-Pentium)

Post reply

maybe you take some advice from Intel, 80386 Programmer's Reference Manual
page 10-10 has this code

mov eax,1 ; set PE bit
mov cr0, eax ; begin protected mode
;
; clear prefetch code
jmp short flush
flush:
..

just assume that the intel guys knew the 80386 fairly well ;)
DOS386

01.05.2008, 05:48

@ Japheth
 

HIMEMX bug

Post reply

RayeR wrote:

I tested himemx v3.32 on intel 386SX/25MHz and it was initialized OK. But it hanged when I tried to start DOS Navigator (it runs OK with MS himem.sys or QEMM 9).

Japheth wrote:

> Good. Half of the job is done. And now, what happens if you add this jmp
> $+2 to the code? (I know you're a good programmer
Would be nice to get it fixed occasionally ... when JAWASM is more stable and can __really__ compile it ;-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Japheth

Homepage

Germany (South),
01.05.2008, 09:20

@ DOS386
 

HIMEMX bug

Post reply

> Would be nice to get it fixed occasionally ... when JAWASM is more stable
> and can __really__ compile it ;-)
Well, yes, I'm considering to put it on my todo list. However, I need a second verification that it fails from an independent - stochastically independent - source before further action can be done. You know, my work is based on a strong belief in scientific principles.

---
MS-DOS forever!
Back to index page
Thread view  Board view
22049 Postings in 2034 Threads, 396 registered users, 224 users online (0 registered, 224 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum