DOS ain't dead

Hello,

recently himemx v3.34 was released, adding support for "multi-block" extended memory.

This is cool and fine and works like a charm - mostly.

Because Jemm386, which requires an installed XMM to load, may complain that its extended memory block is beyond the 16 MB barrier. This is (or better: may be) a problem when it has to intercept ISA DMA, using its DMA buffer.

Well, the problem is minor, since ISA DMA is hardly used anymore on machines with scattered extended memory.

Nevertheless, I updated HimemX to v3.35. It also includes 2 fixes that improve compatibility with MS Himem.

https://github.com/Baron-von-Riedesel/HimemX/blob/master/bin/HimemX_v335.zip

---
MS-DOS forever!

Hi Japheth, sorry to ask a dumb question. Why not adding the jemm386 cure of himemx2 into himemx with a switch ? (Maybe adding umbm into jemm too...)

Thanks for your good tools

> Hi Japheth, sorry to ask a dumb question. Why not adding the jemm386 cure
> of himemx2 into himemx with a switch ?

It's such a minor issue, not worth it.

---
MS-DOS forever!

> recently himemx v3.34 was released, adding support for "multi-block"
> extended memory.

Japheth, I noticed that http://japheth.de is now back. Why not post the update in japheth.de too? Thanks!

Japheth -

It's nice to see both HimemX and Jemm being updated. Big thanks.

- Doug B.

> Japheth, I noticed that http://japheth.de is now back. Why not
> post the update in japheth.de too? Thanks!

I have no access to this site.

---
MS-DOS forever!

Huh and who bring it up?

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

> Nevertheless, I updated HimemX to v3.35.

Over on news://comp.os.msdos.programmer, Rod P. has some worries about your latest release. He doesn't frequent this message board here, so you may have to contact him there (which he directly requests, apparently).

I haven't tested HimemX [EDIT: HimemX2 3.35] much (only casual use), but it seems okay. Of course, I do think we need more testers, but I don't have enough machines (or "good" software tests) to reliably do it all myself.

Thanks again to everyone for their efforts.

> Over on
> news://comp.os.msdos.programmer,
> Rod P. has some worries about your latest release.



Reading my signature you should know that I'm evil - so yes, I ignored all achievements done to HimemX in the last decade by others and added the "multiple block"-thingy to the very ancient HimemX v3.32 source.

---
MS-DOS forever!

Eric Auer writes:

> Hi Japheth!
>
> As your himemx update makes use of your own
> multi-block implementation, you avoid Rod's
> bug of calling int 15.8a without sufficient checks - he
> only checked carry. However, Rod apparently misses
> having any int 15.8a support in your version. Maybe
> you could 1. pre-load DX with a known-bad-magic value
> and check whether int 15.8a has actually updated DX
> and/or 2. add a command line switch to enable 15.8a?
> Rod's version would try int 15.8a just before 15.88.
>
> Thank you for your expert DOS works!

Eric Auer writes again:

> Another oddity is that you use a conditional jump $+2
> after writing CR0, instead of Rod's jmp short $+2: I
> guess that has some sort of compatibility background?
>
> Actually those flags can have undefined changes by writing CR0,
> so making the post-set jump conditional would not work because
> you could not reliably send condition flags across the CR0 change.
> Another thought is that the very fact that undefined changes
> can happen could be the reason to use conditional jumps:
> A CPU jump prediction could not predict it?

> > Hi Japheth!
> >
> > Rod apparently misses
> > having any int 15.8a support in your version.

I'm sorry, but I don't know the background why supporting this call ought to be useful/needed. IMO it's a waste of time.

---
MS-DOS forever!

Eric responds:

> 15.8a only is interesting for mid-1990 Phoenix BIOS on PC [greater than] 64 MB, thus no real problem if omitted.
>
> Only the JZ versus JMP question and the contributor mention are still open.

EDIT: For refresher, re-read our old 2008 thread titled comment on flushing predecode queue (pre-Pentium). (I doubt RayeR's AMD 386SX-25 is still in working condition, but he's welcome to test further.)

Yeah, I still have the laptop (I'm a bit collector of PC and other scrap and maybe I'll open a museum in future :)
I powered it after 12 years since last run and CMOS battery was dead so 1st I had to figure HDD geometry to setup HDD correctly and boot. Then I found that floppy drive got some problems as spindle motor makes unhealthy loud sound when floppy inserted and of course got read error. So I have to run serial terminal and old good Xmodem file transfer protocol. HimemX 3.35 and DOS Navigator is running without problems :) BTW HWiNFO 6.0.5 is running there too (prev. versions had problem with too low memory :)

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

> > Only the JZ versus JMP question and the contributor mention are still
> open.

I'm sorry again, but I don't understand the "JZ/JMP" issue, since in the source there is a (short) JMP, AFAICS.

And the "contributor mention" thing, well, I answered that already HERE. Is my English that bad that it cannot be understood by Americans?

>
> EDIT: For refresher, re-read our old 2008 thread titled
> comment on
> flushing predecode queue (pre-Pentium). (I doubt RayeR's AMD 386SX-25
> is still in working condition, but he's welcome to test further.)

Thanks for the reminder, I had forgotten this "discussion".

---
MS-DOS forever!

>

> I'm sorry again, but I don't understand the "JZ/JMP" issue, since in the
> source there is a (short) JMP, AFAICS.

Apparently he's referring to Feb. 1st's commit 320592fa9ba2f9796a569ba1c70a49ec78353ab5 !

> And the "contributor mention" thing, well, I answered that already
> HERE.

That post was either sarcastic or useless or both. You could've just said "not important" or "maybe later" (which I inferred anyways, is that okay?).

> Is my English that bad that it cannot be understood by Americans?

Eric Auer is not an American. Do you instead mean Rod P.? Or myself?

I cannot understand your motivations, priorities, future plans, or even know what machines you tested (or will test). But I'm also not a systems programmer, so who cares. You can do what you want: I assume you can figure it out. It's not a big deal. We can always stick with older versions if you wish to diverge for other reasons.

The obvious problem is three different places (email, newsgroup, web forum) being used for discussion since none of you three seem to agree upon any single place to discuss this (although I assume none of you care that badly either). Just to state the obvious (?), Eric would prefer to email you directly.

Eric Auer responds again:

> My JZ questions were about line 1317 in version
>
> which already got changed in the 2020-03-23 update
> "added an alternative (re)alloc strategy". So my
> JZ questions lasted longer than the cause, sorry!

N.B. HIMEMX.ASM 3.35 (dated March 26th), lines 1471-4:

;--- the 80386 needs a "flush" after switching to PM
;--- before a segment register can be set!
        jmp @F
@@:


So Eric just didn't find time to (re)check out the "latest" revision, nor did I. (I blame Daylight Savings.)

> If I understood Rod P. correctly, you have not
> "ignored" his HIMEMX achievements, but recycled
> them without crediting him, while I had assumed
> you had made your own multiple block thingy? So
> [nuclear joke] still is a bit puzzling.

Rod hasn't responded to Usenet again yet. He also seems to imply some fatigue there. Japheth has also not replied there. So, looks like not much future progress.

> Of course your version now is significantly more up to date, thanks.
>
> PS: Thanks RayeR for testing!

EDIT: Off-topic: Happy birthday to der Papst. (I did buy his brother's book a few months ago but haven't read it yet.)