• Please review our updated Terms and Rules here

Is there an EMM document or specification somewhere?

I "almost really despise" the concept of paging memory to a disk! Yes, something can still run instead of fail, but at what cost! I've walked up to too many systems where everything has come to a crawl because they had way more memory committed than they had physical RAM. I suppose depending on the situation though, transparently using a disk file would be another option.
I believe DISKCOPY would buffer to C: to avoid disk swaps in sufficiently late MS-DOS versions (6?).

Heap is just conventional memory, right? Is your fdimage code special-cased to do disk i/o directly into conventional memory if no EMS/XMS available rather than double-buffering as is necessarily with XMS and as simplifies code with EMS? If not, you would be cutting effective conventional memory capacity in half, right?

If you wanted to get really sophisticated you could bypass DOS access the floppy controller directly and DMA directly into extended memory, right? but https://web.archive.org/web/20121022073637/https://support.microsoft.com/kb/93469 to be aware of.
 
Heap is just conventional memory, right? Is your fdimage code special-cased to do disk i/o directly into conventional memory if no EMS/XMS available rather than double-buffering as is necessarily with XMS and as simplifies code with EMS? If not, you would be cutting effective conventional memory capacity in half, right?

Yes, heap is conventional. I have a single track sized buffer that is created as to not cross a segment boundary so it can be used with the bios I/O to load or save an entire track with one call. It is this one buffer that will get copied to/from xms, ems, or conventional memory.

If you wanted to get really sophisticated you could bypass DOS access the floppy controller directly and DMA directly into extended memory, right? but https://web.archive.org/web/20121022073637/https://support.microsoft.com/kb/93469 to be aware of.

I'm not going that far! :)

Here is a zip of the xeh, xms, and ems functions (and a test program) if anyone wants to use them for anything. They compile in BC++3.1 using the large model, but could be adapted to other models if desired.

EMS 4.0 function 24 also implemented in this version if ems version is >=4.0.
 

Attachments

  • xeh_101.zip
    7.6 KB · Views: 12
I'm not going that far! :)
It actually made me think about how would an aggressive protected mode OS (that could attempt floppy DMA up to 16MB) handle a situation where the system has an 8-bit floppy controller instead of 16-bit so it needs to keep DMA under 1MB.

Since your files are .CPP, but don't actually have any C++ in them, I'd either rename to .C to prevent name mangling or put extern "C" on all prototypes of your public facing API so that they would be callable from C.

Looks like you allow a single handle to point to a mixture of the three types of memory and handle everything right for a transfer of a mixture of each? nice.
 
It actually made me think about how would an aggressive protected mode OS (that could attempt floppy DMA up to 16MB) handle a situation where the system has an 8-bit floppy controller instead of 16-bit so it needs to keep DMA under 1MB.

I'm not certain what you mean by that. All legacy floppy DMA, right down to my AM3+ motherboard is 8-bit and is the last vestige of the 8 bit ISA architecture. Which is probably why manufacturers were eager to discard legacy floppy support.
 
Since your files are .CPP, but don't actually have any C++ in them, I'd either rename to .C to prevent name mangling or put extern "C" on all prototypes of your public facing API so that they would be callable from C.

You are right, that is a good plan.

Looks like you allow a single handle to point to a mixture of the three types of memory and handle everything right for a transfer of a mixture of each? nice.

It was Chuck's idea, so he deserves the credit for it! It turned out real nice for the project.

Plasma's idea on the function 24 was nice too, now it works with EMS whether there is a page frame or not if it is ems 4.0+.
 
I'm not certain what you mean by that. All legacy floppy DMA, right down to my AM3+ motherboard is 8-bit and is the last vestige of the 8 bit ISA architecture. Which is probably why manufacturers were eager to discard legacy floppy support.

This is probably a dumb question, but are the 8-bit DMA channels on an AT or higher actually limited to under the 1MB mark? The first reference I looked up about ISA DMA didn’t mention that, and since both the XT and AT architecture used the crusty old 8237 that only counts to 64K internally the high-order bits are stored in an external page register. Is that register different widths for the low and high-order channels, or some other limitation? Because otherwise I don’t see why you wouldn’t be able to do DMA to/from an 8 bit I/O device over the full 16MB range.
 
I'm not certain what you mean by that. All legacy floppy DMA, right down to my AM3+ motherboard is 8-bit and is the last vestige of the 8 bit ISA architecture. Which is probably why manufacturers were eager to discard legacy floppy support.
Ah, that's right, so no such thing as a 16-bit floppy controller. I suppose Sound Blaster 16s would be able to do DMA up to the 16MB mark rather than 1MB though, on their high DMA channel.
Do you have an ASRock 980DE3/U3S3? That's a board I have that is the end of the line for onboard floppy.
 
Insofar as I'm aware, the 5170 and later uses a 74LS612 or equivalent to provide an 8-bit extension to the 16-bit address generated by the 8237s. Granted, the second 8237 is rigged to have its address shifted by 1 bit (word vs. byte) but the extension still holds. I haven't looked to see if the A20 gate thing comes into play, however.
 
This is probably a dumb question, but are the 8-bit DMA channels on an AT or higher actually limited to under the 1MB mark? The first reference I looked up about ISA DMA didn’t mention that, and since both the XT and AT architecture used the crusty old 8237 that only counts to 64K internally the high-order bits are stored in an external page register. Is that register different widths for the low and high-order channels, or some other limitation? Because otherwise I don’t see why you wouldn’t be able to do DMA to/from an 8 bit I/O device over the full 16MB range.
Yeah now I'm even more confused. All the more reason if someone feels like it to write such a floppy imaging tool that avoids the extra copy via XMS!
Last I read about it, accessing a disk directly under DOS gets tricky if you want to correctly handle the possibility of a write-behind disk caching program or other TSR that might try to generate disk activity while you're working with the floppy controller directly. I recall something about disk caches hooking int 13h and flushing the cache by convention if anyone calls it, and programs that want to do direct programming of the controller needing to also hook int 13h while they are doing so to block a TSR from messing with the disk. I think this was in the fastdisk code that comes with the Win 3.1 DDK. Perhaps the InDOS flag would also need to be set to block int 13h calls temporarily?

That's the board. Still using it.
Nice. On this topic, I actually run into tons of issues with floppy access on Linux with that board generating weird noises and a flood of dmesg errors. floppy=nodma cuts down on them and makes it possible to read and write floppies successfully.
 
Insofar as I'm aware, the 5170 and later uses a 74LS612 or equivalent to provide an 8-bit extension to the 16-bit address generated by the 8237s. Granted, the second 8237 is rigged to have its address shifted by 1 bit (word vs. byte) but the extension still holds. I haven't looked to see if the A20 gate thing comes into play, however.

As I said, I can't imagine why it would? All the DMA controller is doing with an I/O device transfer is essentially acting like a counter on the memory address side, and on each DMA cycle it it asserts the memory READ/WRITE line for that byte/word (depending on if it's an 8 or 16 bit channel) and the opposite I/O port WRITE/READ line so the data byte flies across the common bus connector; the DMA controller itself doesn't touch the data, and the floppy controller is blissfully unaware of where the data is coming from/going to, it doesn't have any concept of remote address whatsoever. And since all the DMA controller knows about the 64K range it can actually increment through whatever the registers are set to in the 74LS612 are none of its business. If the A20 gate is set to "fix" the real-mode rollover problem (and it affects DMA transfers, I'm not entirely sure it does?) it seems like it'll do the same garbling of the address lines regardless of whether it's an 8 or 16 bit channel.

(I mean, isn't it a well-known bug/misfeature of the 16 bit channels that because they use such a crude hack to make them 16 bit (IE, just sliding their address over 1 bit) that isn't accounted for by the paging register that if you tried to transfer more than 32K "words" it'd roll over and give you the same memory twice? That sounds like IBM intended DMA across the whole range to have byte granularity and the 16 bit DMA channels are kind of an afterthought.)

FWIW, the Linux documentation about ISA/LPC DMA doesn't say anything about a 1MB limit for the lower channels, it just says if you intend to do ISA DMA you have to allocate your buffer in the lower 16MB, period.
 
I recall that when the 68K was first being sampled, there were gripes about lack of support chips specifically intended for it. "Oh, you can use the 6800 support chips...". Intel essentially did the same thing by saying "Just use the 8080/8085 chips". Which leads to all sorts of hacks. The 8089 was resource-limited (2 DMA channels and 20 bit addressing) and expensive and a bit complicated to integrate. The 80186 does have full 20-bit DMA, but only two channels (at least on the "A" version). I'm not aware of any major vendor with a 16-bit floppy controller. IRQ6/DMA2 is hardwired on most motherboards with integrated floppy support.
 
As I said, I can't imagine why it would? All the DMA controller is doing with an I/O device transfer is essentially acting like a counter on the memory address side, and on each DMA cycle it it asserts the memory READ/WRITE line for that byte/word (depending on if it's an 8 or 16 bit channel) and the opposite I/O port WRITE/READ line so the data byte flies across the common bus connector; the DMA controller itself doesn't touch the data, and the floppy controller is blissfully unaware of where the data is coming from/going to, it doesn't have any concept of remote address whatsoever. And since all the DMA controller knows about the 64K range it can actually increment through whatever the registers are set to in the 74LS612 are none of its business. If the A20 gate is set to "fix" the real-mode rollover problem (and it affects DMA transfers, I'm not entirely sure it does?) it seems like it'll do the same garbling of the address lines regardless of whether it's an 8 or 16 bit channel.

(I mean, isn't it a well-known bug/misfeature of the 16 bit channels that because they use such a crude hack to make them 16 bit (IE, just sliding their address over 1 bit) that isn't accounted for by the paging register that if you tried to transfer more than 32K "words" it'd roll over and give you the same memory twice? That sounds like IBM intended DMA across the whole range to have byte granularity and the 16 bit DMA channels are kind of an afterthought.)

FWIW, the Linux documentation about ISA/LPC DMA doesn't say anything about a 1MB limit for the lower channels, it just says if you intend to do ISA DMA you have to allocate your buffer in the lower 16MB, period.

I was confusing ISA DMA with ISA bus mastering where the card needs to know the address and really would need all 24 address lines. The MASTER pin doesn't even exist on an 8-bit slot, so by definition all cards supporting ISA bus mastering are 16-bit so no 1MB limitation applies.
 
Back
Top