DOS ain't dead

Hello,

a preliminary new Jemm version is available, which contains a new JLM, XDMA32, an Ultra-DMA HD driver.

XDMA32 is based on J.R. Ellis' XDMA v3.3. SATA support has been added and some bugs were fixed. Most BIOSes nowadays support Ultra-DMA, but according to Mr. Ellis there exist some ("El Cheapo"), which virtually disable this support when running under a v86-monitor like Jemm. In such cases XDMA32 might give a significant speed boost. The driver needs just 32 bytes of DOS memory.

The creation of XDMA32 revealed a bug in JLOAD - the DMA locking function did ignore a flag to check for 64 kB border crossing -, so there was a need to update Jemm to make XDMA32 run.

WARNING: This version is preliminary, intended for testing only! If XDMA32 is installed, it becomes a very crucial system component which might cause data losses if it's not working correctly!!!

Jemm v5.68 binaries (preliminary)
Jemm v5.68 source code (preliminary)

---
MS-DOS forever!

> XDMA32 is based on J.R. Ellis' XDMA v3.3. SATA support has been added and
> some bugs were fixed. Most BIOSes nowadays support Ultra-DMA, but

When you enabled SATA support do you think if also ITE8211 IDE controller will work? With Jack's help I tried to replace PCI subclass code from 01h to 80h and then ITE controller was detected, even busmaster IO base was reader OK from PCI registers but it hanged.

But I'm waiting for new mobo which should arrive in few days and then I probably will upgrade to SATA. So ITE support would'nt be really needed...

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

> When you enabled SATA support do you think if also ITE8211 IDE controller
> will work? With Jack's help I tried to replace PCI subclass code from 01h
> to 80h and then ITE controller was detected, even busmaster IO base was
> reader OK from PCI registers but it hanged.

At least there is a chance if your BIOS supports EDD-3.0, because then the driver can get the PCI device+subclass by BIOS call int 13h, ah=48h.

---
MS-DOS forever!

SWEET! :)

> At least there is a chance if your BIOS supports EDD-3.0, because then the
> driver can get the PCI device+subclass by BIOS call int 13h, ah=48h.

BTW what is EDD?
I don't think this is an issue for patched UIDE driver when it then could detect ITE controller and busmaster IO base address but hangs when it should write detected drives.
I'll try your version when come at home.

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

> BTW what is EDD?

EDD = Enhanced Disk Drive: the 4xh functions of int 13h

> I don't think this is an issue for patched UIDE driver when it then could
> detect ITE controller and busmaster IO base address but hangs when it
> should write detected drives.

What means "write" here? "Write" to the drive or "Write" to the screen the name of the drive it detected? Anyway, if UIDE was able to get the port base addresses of both the IDE and the DMA controller and it still hangs, then XDMA32 will almost certainly fail as well.

But since I know you are an experienced user and programmer, this should be no problem at all. With 386SWAT you can easily stop inside XDMA32 and find the "hang". Enjoy!

---
MS-DOS forever!

> SWEET! :)

Is this remark referring to the pretty popular English teeny pop group of the 70s? (Ballroom Blitz, ...)

---
MS-DOS forever!

> Is this remark referring to the pretty popular English teeny pop group of
> the 70th? (Ballroom Blitz, ...)

"Freakin' sweet", "wicked cool", "rad", "totally awesome", "kick ass".

> "Freakin' sweet", "wicked cool", "rad", "totally awesome", "kick ass".

I'll take that as a yes then 'cos they were a damn good band.

> EDD = Enhanced Disk Drive: the 4xh functions of int 13h

Aha, I found and got Phoenix spec.
But it looks bad, when I did:

mov     ax,41h
mov     bx,55AAh
mov     dl,80h
int     13h

nothing was happened, no version, no 55-AA toggle so seem my bios doesn't support it at all.

> What means "write" here? "Write" to the drive or "Write" to the screen the
> name of the drive it detected? Anyway, if UIDE was able to get the port
> base addresses of both the IDE and the DMA controller and it still hangs,
> then XDMA32 will almost certainly fail as well.

Sorry, I meant display to screen.
I tried new jemmex + xdma but no result, no HDDs:

XDMA32 V1.0, 11-25-2007
Hardware-only disk scan:
No disk to use; XDMA32 not loaded!
JLoad: 'XDMA32.DLL' loaded successfully.

XCDROM32 V1.0, 5-13-2007.
Driver name is JLOAD.
UltraDMA controller at I-O address FFA0h, Chip I.D. 808627DFh.
Unit 0:  Primary-master, _NEC DVD_RW ND-4551A, ATA-33.
Unit 1:  Primary-slave, CD-W524E, ATA-33.
JLoad: 'XCDROM32.DLL' loaded successfully.

Optical drives are OK as the are attached to ICH7R (to be able to boot from them). (Why those stupid intel cut down PATA channels :(( I don't really need SATA.)

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

> Aha, I found and got Phoenix spec.
> But it looks bad, when I did:
>
> mov ax,41h
> mov bx,55AAh
> mov dl,80h
> int 13h
>
> nothing was happened, no version, no 55-AA toggle so seem my bios doesn't
> support it at all.

did you really use AX? Because it should be AH:

mov     ah,41h
mov     bx,55AAh
mov     dl,80h
int     13h

---
MS-DOS forever!

> did you really use AX? Because it should be AH:

my mistake...

Then I got AH=30h and 55-AA flipped.
BTW it returns AH=01 under win98 and made nice BSOD after which I can't leave dos box :)

Call with AH=48h will zero the AH but don't fill ds:si pointer to structure.

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

> Then I got AH=30h and 55-AA flipped.
> BTW it returns AH=01 under win98 and made nice BSOD after which I can't
> leave dos box :)
>
> Call with AH=48h will zero the AH but don't fill ds:si pointer to
> structure.

Did you fill the word at [ds:si] with the size of the structure BEFORE the call?

It's 001Eh for EDD 2.0, 0042h for EDD 3.0.

---
MS-DOS forever!

> Did you fill the word at [ds:si] with the size of the structure BEFORE the
> call?
>
> It's 001Eh for EDD 2.0, 0042h for EDD 3.0.

Hm, it seems to me weird. I though I got a pointer to ROM with some string/binary structure. So you mean that I need 1st allocate a buffer, put it's pointer to DS:SI (like for VESA info to ES:DI) and then put a size-word at the beginning of buffer?

BTW is there some info tool which can reports EDD data? If not, maybe I can write one :)

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

I don't care about this matter, but I wonder how nobody noticed that the Artistic Licence of EMM386/JEMM is regarded as non-free by the FSF, which means it's GPL-incompatible, so the GPL'd XCDROM/XDMA can't be combined with JEMM as JLMs.

> I don't care about this matter, but I wonder how nobody noticed that the
> Artistic
> Licence of EMM386/JEMM is regarded as non-free
> by the FSF, which means it's GPL-incompatible, so the GPL'd XCDROM/XDMA
> can't be combined
> with JEMM as JLMs.

Thanks for this hint! What's your suggestion to solve this possible conflict?

---
MS-DOS forever!

> Hm, it seems to me weird. I though I got a pointer to ROM with some
> string/binary structure. So you mean that I need 1st allocate a buffer,
> put it's pointer to DS:SI (like for VESA info to ES:DI) and then put a
> size-word at the beginning of buffer?

yes

> BTW is there some info tool which can reports EDD data?

I don't know, usually I use a DEBUG "script" and RBIL:

a
mov ah,48
mov si,200
mov dl,80
int 13
int 3

e 200
42 00 00 00

g=100
d 200
q

> If not, maybe I can write one :)

Good idea! But will it be a 200 kB DJGPP app then?

---
MS-DOS forever!

> by the FSF, which means it's GPL-incompatible, so the GPL'd XCDROM/XDMA
> can't be combined with JEMM as JLMs.

But why - they are not a part of JEMM386 driver, they are just using JEMM API. E.g. there are lot of GPLed program which are using propietary WIN32API. May be, spreading XCDROM32 and XDMA32 as separate package will solve the conflict of licensies?

> > I don't care about this matter, but I wonder how nobody noticed that the
> > Artistic
> > Licence of EMM386/JEMM is regarded as
> non-free
> > by the FSF, which means it's GPL-incompatible, so the GPL'd
> XCDROM/XDMA
> > can't be
> combined
> > with JEMM as JLMs.
>
> Thanks for this hint! What's your suggestion to solve this possible
> conflict?

a) it's not combined (it's a separate module)
b) as the license holder of xEMM386: if that would be a problem, I'd
change the license (but not to GPL)

Tom

> a) it's not combined (it's a separate module)

Yes, but according to the FSF, "if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."

Of course, all this is very subjective, but it's better to avoid any doubt.

> b) as the license holder of xEMM386: if that would be a problem, I'd change the license (but not to GPL)

Your choice - plenty of licences... if only they were written for mortal people, not for lawyers!

> Thanks for this hint! What's your suggestion to solve this possible conflict?

Easiest is Tom to change the EMM386 licence, as he suggests. There's one more obvious way to go, but I'd better keep my mouth shut on it, lest provoke another "war".

> Easiest is Tom to change the EMM386 licence, as he suggests.

No. Because there is also Harald Albrecht holding a copyright, who most likely is not "accessible". And as far as I am concerned, the only acceptable licence other than "Artistic" is "Public Domain".

> There's one more obvious way to go, but I'd better keep my mouth shut on it,
> lest provoke another "war".

Sorry, hypo, but if you didn't intend to start another war, you should have kept your mouth shut *before* posting the "Licence conflict". I know very well that you are not at all interested in license issues. Courage!

---
MS-DOS forever!

> No. Because there is also Harald Albrecht holding a copyright, who most
> likely is not "accessible". And as far as I am concerned, the only
> acceptable licence other than "Artistic" is "Public Domain".

Let's see what Tom says on this.

> Sorry, hypo, but if you didn't intend to start another war, you should
> have kept your mouth shut *before* posting the "Licence conflict". I know
> very well that you are not at all interested in license issues. Courage!

First you thank me (see above), then you insult me. Shall I "open my mouth"?

> First you thank me (see above), then you insult me. Shall I "open my
> mouth"?

You don't find yourself a hypocrite for suggesting someone else to be more careful about copyright violation, when they're on the safe side of license "gray area" while you're busy stating you don't recognize copyright and blatantly violate licenses?

Edited for clarity :)

> No. Because there is also Harald Albrecht holding a copyright, who most
> likely is not "accessible". And as far as I am concerned, the only
> acceptable licence other than "Artistic" is "Public Domain".

I have Harald Albrecht permission to change the license.

I recommend (and allow) to change the license to Artistic 2.0, which is 'free enough' according to the FSF.

This should settle this non-issue.

Tom

> I recommend (and allow) to change the license to Artistic 2.0, which is
> 'free enough' according to the FSF.

I wouldn't use the FSF as a gauge for "free" - the GPL is not at all free.

I suggest BSD :)

"Can't you feel when you are superfluous? Then let me tell you: you are!"

The above was written by your friend some weeks ago. It applies 100% to you now.

> The above was written by your friend some weeks ago. It applies 100% to
> you now.

Ah, so what you're saying is that it's extremely obvious to everyone that you're an idiot/hypocrite, making it a redundant thing to mention? Fair enough.

> May be, spreading XCDROM32 and XDMA32 as separate package will solve the
> conflict of licensies?

I think that except as examples how to write a JLM, they don't do much good now when we have UIDE which takes just 1.75K (for up to 200 MB of cache!) of upper memory - a very small amount for a fully caching UDMA driver of HDD/CD/DVD. The only reason A. Grech added XDMA32 is to upset Jack again, not to help his users. Isn't that a big hypocrisy?

Sorry for "opening my mouth" but I was challenged by him.

> Ah, so what you're saying is that it's extremely obvious to everyone that
> you're an idiot/hypocrite, making it a redundant thing to mention? Fair enough.

Risking to repeat myself, I say "look into the mirror and you'll see him". I know why you wrote that "SWEET". You were referring to how sweet you feel to upset Jack with Grech's ports of Jack's old and obsolete XDMA and XCDROM to JLMs.

And please remove that idiotic signature of yours! Jack never said that most Germans are Nazis.

> Risking to repeat myself, I say "look into the mirror and you'll see him".
> I know why you wrote that "SWEET". You were referring to how sweet you feel
> to upset Jack with Grech's obsolete and problematic ports of Jack's old
> XDMA and XCDROM to JLMs.

Let's stop this here!

---
Forum admin

> Let's stop this here!

I agree. Everything is already clear enough.

> I think that except as examples how to write a JLM, they don't do much
> good now when we have UIDE which takes just 1.75K

1.75K is very good, but every byte of low memory counts, so if the JLM version can do significantly better, then IMO it's well worth it.

> I don't know, usually I use a DEBUG "script" and RBIL:

I got some EDD data but looks a lot of zeros there, probably only few entries filled. I'll check it

I found that my bios doesn't look at size word in buffer, the result is same for 42h, 0h, ffffh or whatever. But in spec is described that you should enter max buffer size and bios should change it to 30 or 26. I got always 26.

> Good idea! But will it be a 200 kB DJGPP app then?

I never made over 200 kB UPXed DJGPP app :)
But I think my old good BC is good for this job, maybe less than 20kB.

BTW do you know what should mean
"Unhandled exception 000E at 0020 1A9E ErrCode 0002" I sometimes got when running Turbo Debugger 4.0 when playing with short ASM code for EDD (it happened at TD start)? I didn't see this before use JEMM but everything else seems run OK.

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

> I never made over 200 kB UPXed DJGPP app :)
> But I think my old good BC is good for this job, maybe less than 20kB.

You can try first alfa http://rayer.ic.cz/programm/eddinfo.exe
Please send me your edd.bin dumped to current directory.

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

> 1.75K is very good, but every byte of low memory counts, so if the
> JLM version can do significantly better, then IMO it's well worth it.

Yes, but these 1.75K can be in upper memory (so no low memory is used), if you specify DEVICEHIGH=UIDE.SYS in CONFIG.SYS, and it's for a HDD/CD/DVD cache size of up to 200MB (a few KB more are taken for a cache size of up to 1GB), whereas neither XDMA[32] nor XCDROM[32] do any caching. Plus there are other drawbacks of the old XDMA/XCDROM too (bugs, less control and compatibility, and so on).

> I recommend (and allow) to change the license to Artistic 2.0, which is
> 'free enough' according to the FSF.

Yes, that'd be most natural. It might solve another issue: missing JLOAD source code. Clause (9) in the Artistic Licence 2.0 (missing in version 1) says:

=== start quote ===

Items That are Not Considered Part of a Modified Version

(9) Works (including, but not limited to, modules and scripts) that merely extend or make use of the Package, do not, by themselves, cause the Package to be a Modified Version. In addition, such works are not considered parts of the Package itself, and are not subject to the terms of this license.

=== end quote ===

So JLOAD could be considered not a part of the package. Really? As JEMM has some provisions for JLOAD, I don't think so. But if clause (9) doesn't apply to JLOAD (that is, it's a part of the package and is covered by the same licence) then Mr A. Grech should make its source code available as per clauses (4), (5) and (6).

> First you thank me (see above), then you insult me. Shall I "open my
> mouth"?

My first post (the "thank you") was pure sarcasm, although I have to admit that I forgot to use the smiley.

And btw, I didn't insult you. You're constantly refusing to use my nickname in this forum, thus forcing me to also avoid using yours. OTOH I really don't want to learn and remember your true name. This finally leads to 2 options for me to use as a name for you:

1. HYPO: which is - of course - NOT an abbreviation of HYPOcrite, but a short form for HYPERMAN, Superman's friend. Do you know who is Superman? Anyway, they both are VERY GOOD guys.

2. TBC: which is - of course - NOT an acronym for "The Board's Clown", but for "The Best Credible one"

So please choose the one you'd prefer, I will obey.

---
MS-DOS forever!

> I have Harald Albrecht permission to change the license.
>
> I recommend (and allow) to change the license to Artistic 2.0, which is
> 'free enough' according to the FSF.
>
> This should settle this non-issue.

Thanks for bothering to clarify this!

---
MS-DOS forever!

> OTOH I really don't want to learn and remember your true name.

I'd understand if you said "don't remember": I also have difficulties remembering names.
But you said "don't want to learn and remember". I think that's just a superiority complex.
In any case, my true name is in my user data, unlike yours which is still "Angela Merkel".

> Yes, but these 1.75K can be in upper memory (so no low memory is used), if
> you specify DEVICEHIGH=UIDE.SYS in CONFIG.SYS, and it's for a HDD/CD/DVD
> cache size of up to 200MB (a few KB more are taken for a cache size of up
> to 1GB), whereas neither XDMA[32] nor XCDROM[32] do any caching. Plus
> there are other drawbacks of the old XDMA/XCDROM too (bugs, less control
> and compatibility, and so on).

If you don't like it, just don't use it Japheth said, that it was easy to port - so there exists a second driver now which is also very good.

"Zorla güzellik olmaz", as the Turks would say!
The English say it longer: "You can take a horse to water, but you cannot make him drink".

> Yes, but these 1.75K can be in upper memory (so no low memory is used), if
> you specify DEVICEHIGH=UIDE.SYS in CONFIG.SYS, and it's for a HDD/CD/DVD
> cache size of up to 200MB (a few KB more are taken for a cache size of up
> to 1GB), whereas neither XDMA[32] nor XCDROM[32] do any caching. Plus
> there are other drawbacks of the old XDMA/XCDROM too (bugs, less control
> and compatibility, and so on).

Some remarks from me:

1. According to the "official" UIDE site it is "Gone Forever" (http://johnson.tmfc.net/dos/drivers.html). It seems a bit strange to compare XDMA32 with something not available at all. It probably can be found on your boot disks images, but these also contain "stolen" software, which some people want to avoid to download.

2. Caching is sometimes good, and sometimes it is bad and can even slow down things. I prefer a cache available as a separate module. And I also prefer to use extended memory for 32bit protected-mode DOS programs, and not waste it for a cache if the system includes fast SATA drives. Therefore, the original QDMA, which just cached 1-sector reads in a 256 kB buffer, was a better thing IMO.

3. Yes, there were some bugs in XDMA, but it is SOFTWARE and those bugs are/will be fixed finally.

4. UIDE has to do up to 5 switches to protected-mode during an Int 13h when running in v86-mode (2 VDS + 1 Int 15h + 2 A20). Not that this does matter a lot as far as speed is concerned, but it clearly shows that a driver running in protected-mode is the BETTER design then.

---
MS-DOS forever!

> 1. HYPO: which is - of course - NOT an abbreviation of HYPOcrite, but a
> short form for HYPERMAN, Superman's friend. Do you know who is Superman?
> Anyway, they both are VERY GOOD guys.

hyper() = über()
hypo() = unter()

I leave the rest to you.

lucho...you have to understand that different people are good at different things. You're good at physical labour, like cleaning toilets and mopping floors. Other people are good at thinking. Everyone should do what they're good at ;) --- this would save everyone time.

I'll try to make this *very* simple so you can understand. Let me know what I don't need to clarify for you, if anything:

1. Countries that are not communist/socialist recognise that people may "own" something, which means it belongs to them! What a novel idea, huh?

2. Japheth is the "copyright owner." The copyright owner owns the code, like a writer or artist owns a book or painting they have created. The term "owner" is derived from the word "own" as explained in (1).

3. The "copyright owner" can make copies without any form of authorization, that's why we call them the copyright "owner"

4. People are not allowed to make copies of Japheth's software, because they are not the "owner" of the work.

5. A license is what allows people who are not the owner of the copyright to make copies, under certain conditions

An example might be that Japheth could release the next version of JEMM under the GPL, and not release the source at all. He owns the copyright and doesn't need permission. He's not bound by the license because he "owns" the software.

Even if he were able to break his own license...who's going to sue him for Copyright infringement? Will he sue himself?

> You can try first alfa
> http://rayer.ic.cz/programm/eddinfo.exe
> Please send me your edd.bin dumped to current directory.

Thanks! I sent you the EDD.BIN file.

The eddinfo program apparently ignores drive numbers given as a parameter?

---
MS-DOS forever!

> I think that except as examples how to write a JLM, they don't do much
> good now when we have UIDE which takes just 1.75K (for up to 200 MB of
> cache!) of upper memory - a very small amount for a fully caching UDMA
> driver of HDD/CD/DVD. The only reason A. Grech added XDMA32 is to upset
> Jack again, not to help his users. Isn't that a big hypocrisy?

Hypo, there is a misconception in your thoughts. I don't act unreasonable. As you might be able to realize, all the drivers - HIMEMX, XCDROM32 and XDMA32 - were released at times when your master had installed his little embargos. And the intention behind these action was to make him learn that his drivers are important, but not ABSOLUTELY NECESSARY, and his embargos are therefore a waste of time. Some pain can drastically increase the learning effect, so it is indeed appreciated that Jack was slightly upset (thanks for confirming that!), but this is just a side effect.

Yes, the highly optimized UIDE might be slightly faster than the combination XDMA32 + LBACACHE, but almost nobody will care. It's just this famous 0.1% part of users who does.

---
MS-DOS forever!

If the society needs me to clean toilets and mop floors, I'd do it. I've done it in the army, and am proud that I fear no labour, unlike you, who have never done it, lest not get your precious white hands dirty! There is no shameful labour.

(The contempt you feel against me is equal only to contempt I feel against you.)

Hands off socialism! Your washed brain knows really nothing about it. If you need to express your mad anticommunism, this is not the right forum to do this.

A. Grech doesn't own JLOAD. There is no such thing as "intellectual property". He only breaches the EMM386 licence by not making the source code of the EMM386 extension called JLOAD available, nor does he obviously care about it, nor I do.

Nothing you wrote is true. Really nothing!
May I remind you what Jack wrote on Udo's forum?

== start quote ===

Finally, I leave it for all of you to try almost ANYTHING on your systems using a disk cache, or not. SATA disks rotate at 7200/10000 RPM and still have "rotational latencies", and their "high" transfer rate of 1.5 to 6 Gigabits/sec ARE NOT matched by a "net" bit-stream from the disk of about 240 Megabits/sec! Do your OWN tests, then decide for yourselves if Japheth's comments about not needing a cache are correct, or NOT!

=== end quote ===

As I've tested, the speed difference in using UDMA+cache and only UDMA is really enormous.

> If the society needs me to clean toilets and mop floors, I'd do it. I've
> done it in the army, and am proud that I fear no labour,

It's easy not to fear what is not a threat to you, safe at your TU.

> unlike you, who have never done it, lest not get your precious white hands
> dirty!

How do you know what labor sol has or has not done, or what color his (her? [no direct evidence available]) hands are?

> Hands off socialism! Your washed brain knows really nothing about it.

It's your brain, washed by "actually existing" socialism that knows nothing.

> If you need to express your mad anticommunism, this is not the right forum
> to do this.

Your father had a good job with the Party, right?

> A. Grech doesn't own JLOAD. There is no such thing as "intellectual
> property". He only breaches the EMM386 licence by not making the source
> code of the EMM386 extension called JLOAD available, nor does he obviously
> care about it, nor I do.

Another of your illogical and immaterial rants. Thank you for the entertainment!

... to see all those posts and being unable to reply because you believed that you were banned - and actually just had forgotten that you changed your password. Too bad that you weren't smart enough to think of opening just another account (believe me, we all would easily have recognized you as the TRUE "lucho", because it's simply impossible to fake your style). I realize now that a fool's live has its very own shortcomings.

About the "cache" issues: you're "answering questions which have not been asked", which tells me that you either a) don't know what you're talking about or b) are just "intellectually dishonest". The latter astonishes me slightly, to be honest, because I thought it impossible that anyone may be able to use the terms "intellectual" and you ("lucho") in one sentence.

---
MS-DOS forever!