Eric,
> Finally I find time to read the changelog examples, thanks!
>
>>>> 03/27/2007
>>>> bugfix: free EMS pages not always reported correctly.
>
> Wrong amount of free space? Or non-free pages reported as free?
"Not my department", as I've never used actual EMS -- Ask Japheth.
>>>> bugfix: translation DMA for 16-bit controller (channels 4-7)
>>>> didn't work.
>
> This fix sounds VERY useful.
Might be, if I could ever find a "real" diskette driver that is not
embedded inside some BIOS.
>>>> 03/02/2007 bugfix: XMS function 11h (free UMB) always returned an
>>>> error.
>
> Error status? Or failed to work?
"Not my department, ask Japheth", as above.
>>>> 10/07/2006 bugfix: allocating a EMS block with zero pages (int 67h,
>>>> ah=5Ah, bx=0) returned with AH=0, but did not return a valid DX
>>>> handle.
>
> A rare situation?
Perhaps, but would YOU like to be "bitten by this bug"?
>>>> 09/30/2006
>>>> bugfix: VDS functions 03, 04, 07 and 08 may have failed if bit 1 of
>>>> DX was set (request to copy in/out of DMA buffer) and registers
>>>> BX,CX were <> 0.
>
> Int 4b.8103/4/7/8? Lock/Unlock/Request/Release DMA region/buffer?
> I first thought it was a missing feature, but re-reading the above
> it was a bug triggered by BX / CX values. Oops :-!
UIDE uses ONLY "VDS lock" and "VDS unlock", since MS-DOS EMM386 is
absolutely UNRELIABLE for any other VDS calls! "VDS lock" returns
the 32-bit address of a memory area, without which it is "Kiss your
*** GOODBYE!!" re: using UltraDMA!!
>>>> bugfix: 1 kB of DMA buffer may have been inaccessible.
>>>> bugfix: releasing a DMA buffer of size < 1 kB always failed.
>
> Probably uncommon, but still an annoying bug fixed by Japheth :-)
Depends -- Users with SCSI or old IDE disks (i.e. no "UltraDMA") may
just be "Sh** out of luck!", as our actor Clint Eastwood once noted!
>>>> 09/06/2006 bugfix: writing to "ROM" page FF000 if ALTBOOT wasn't set
>>>> caused a crash.
>
> Yes I remember the times when ALTBOOT was "needed for stability"...
Another "Kiss your *** GOODBYE!!", in my opinion!
>>>> 08/25/2006 bugfix: unsupported VDS functions caused a debug display,
>>>> which didn't work and may have caused corruption of monitor data.
>
> Interesting.
"Corruption of monitor data" is only "INTERESTING", you say?? I might
say many OTHER things, starting with "Flat-Ass DISASTER"!!
>>>> 08/23/2006 bugfix: DMA buffer is ensured to begin on a 64 kB physical
>>>> address boundary.
>
> I wonder where else it was before.
Who cares -- Does the expression "Flat-Ass DEAD!!" mean anything to you??
>>>> 08/17/2006 bugfix: in VCPI protected mode entry switch to host stack
>>>> before context is switched.
>
> That probably caused random crashes with protected mode apps before?
"You BET your ***!" {our companion to "Kissing" it, as above)!
>> Note that all of the "bugfix" items listed above are not-long after the
>> final update for FD-EMM386, meaning that Japheth likely inherited them
>
> Maybe some other changes after 2008 made JEMM386 harder to use again?
"Not my department -- Ask Japheth"!
> Still trying to find an explanation for Alain's pessimism and troubles
> experienced by the users of his software when trying to use JEMM386.
> In any case I agree that JEMM386 has several clear improvements, too.
> Based on your changelog examples - not on "who is on the base list".
Nonetheless, whoever decided to "pitch" FD-EMM386 and include JEMM386
deserves a MEDAL!
> "Clear improvements over FD-EMM386" does not mean that FD-EMM386
> was horrible, just old.
After all your admissions and my "notes" above, one DARE NOT only
say FD-EMM386 was "old". It was BAD, still IS bad (due to being
"abandoned"!), and should be updated or flatly ELIMINATED, before
others get "burned" by any ["Interesting"] items listed above!!
SORRY for my strong feelings, and "friend" Brutman can call me
"hostile" all he wishes. But "I felt it my DUTY to provide
responsible opinions" [as Sir Edward Murdoch noted to General
Haig, in the 1980 "Anzacs" Australian T.V. series), and I would
be DERELICT in that duty if I did not express how BAD and RISKY
FD-EMM386 still is!!
> But my big question is what makes JEMM386 uncomfortable/shaky for
> Alain, even though JEMM386 actually is better than FD-EMM386 and a
> lot more up-to-date and maintained.
Again, "Not my department", especially as I know only enough about
protected-mode to get my "real mode" XMS move logic running within
XMGR and UIDE. Ask Alain.
>> ... Why not recommend that users who create "boot" diskettes DO
>> NOT include any "EMM" driver in such "boot" activities??
>
> I totally agree with your recommendation.
"Yahoo"! Or "Yay-hoo!" depending on what U.S. state hatched you!
>> Would you care to GUESS the first message XMGR will give you??
>> Something like "NOTE: A20 line found on!", maybe?
>
> The FreeDOS kernel only switches A20 by calling HIMEM/XMGR, so if
> XMGR finds A20 to be already on, then the BIOS probably did that.
I really DOUBT IT, or else why do MS-DOS V7.10, MS-DOS V6.22 that I
still use, and PC-DOS in fact NOT give me the same message! Maybe
you need to look "a little DEEPER" into the FreeDOS kernel!
>>> In short, I would be happy about a "force-on" "A20 method".
>
>> Glad to hear that, since your own FreeDOS is already DOING so!
>
> It is not, but probably it should ...
"Baloney!" [polite "B" word], as I just noted above!
>>>> XMGR doesn't handle the usually-ignored BIOS calls ...
>
>> Why do I say such calls are usually ignored? Because XMGR
>> has NEVER supported them, and no one has ever "complained"
>
> That simply means that all modern systems support port 92 and
> or keyboard controller style A20. It does not mean that BIOS
> calls for switching A20 would be broken in BIOS.
I never said or implied the BIOS calls WERE at-all "broken"!
I simply said that it appears nobody USES them, for the same
reason you note: "Keyboard" or "Port 92h" logic works fine.
> Proves your point that using the BIOS to manipulate A20 is not
> necessary, nobody has yet reported non-BIOS to cause problems.
Agreed, and I can "save" adding all that logic into XMGR!
"Hallelujah!", and "Saints be Praised!" [take your pick]!
>> The kernel already IS doing part of the work! Try ALL of the
>> options on Lucho's "boot" diskette"! You will find that only
>> MS-DOS and PC-DOS are not hard-enabling "A20", when they load.
>> DR-DOS, the Russian PTS-DOS, ROM-DOS, and FreeDOS all DO hard-
>> enable "A20".
>
> The FreeDOS kernel contains no 8042, port 92 or int 15.24 style
> A20 manipulation code (or it would be very well hidden) so the
> only A20 work of the kernel are calls to XMS driver functions
> number 5 and 6. Maybe an obscure side-effect of something else
> distorts your measurement? The boot menu used by Lucho might
> enable A20 but the MS / PC DOS kernel then disabled it again?
REALLY doubtful, since when I do NOT use Lucho's "boot" diskette
I get the SAME results! I suggest you need to investigate your
"very well hidden" comment, above!
> I still cannot find *how* the FreeDOS kernel would enable A20
> before XMS drivers are loaded ...
If I had to "guess", I suggest you investigate whatever logic
"burns up" all HMA space for DOS "buffers". FreeDOS HMA is
not available for drivers like my UIDE until after AUTOEXEC
is run! That is why I tell FreeDOS users to run your DEVLOAD
[in AUTOEXEC] to load UIDE, if they want to load UIDE into HMA
space. SOMETHING is enabling "A20" in the FreeDOS kernel, and
it does NOT happen, no-matter WHAT loading scheme I use, with
MS-DOS or PC-DOS! "Look a bit further!", my friend!
>> ... Given that, I am NOT in favor of adding such a hard-enable
>> for "A20" in my XMGR driver. If other XMS managers offer such
>> an option, I hope their users "Know what they are doing!"
>
> As all options, the user has to decide whether to use that, yes.
How carefully you avoid my "problematical" comment!
Jack R. Ellis
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
