mjranum@gouldsd.UUCP (04/23/87)
I want to look into writing an EMS driver into the RAMdisk driver. Can anyone out there give me pointers to how the EMS hardware is accessed by software ? I have a feeeling it's a dreadful kluge, but it might be nice to be able to free up more RAM by stuffing the RAMdisk into kluge-mem. Ideas ? Comments ? How does a user program access the extra memory ? Do I have to specifically jigger my addresses ? If anyone out there does have an answer, please slant it towards someone who is more or less hardware illiterate. I have a good grasp of addressing, and some machine lang, and I can figure anything out given enough caffeine --mjr() -- If a million monkeys program a million IBM PCs for a million years, they will write something much better than MS-DOS. It will probably run faster, multitask, and really support wildcards. User support will be dramatically improved. -me
fan@ucla-cs.UUCP (04/23/87)
---------- I am also thinking about creating an EMS ramdisk instead of using system ramdisk. I have the book, but I didn't have the disks yet. If I read the book correctly, I think that in order to implement an EMS ramdisk: (1) the EMS ramdisk can have a maximum of 1MB since the pointer they use is only 16 bits (the segment). This doesn't seem right though, there might be something I miss. (2) you will need an EMS driver that will map the logical memory into the 64K physical memory. For a very simple ramdisk driver, I was thinking of mapping the first bank to the beginning of the logical memory, and the rest 3 banks after that. That way, you will have a minimum of 48K to transfer. And if the process requests more than 48K, you could break them into parts. (3) I don't know who called the ramdisk initialization routine. But what it should do is (a) record how large is the RAMDISK (b) don't take any memory for ramdisk. I have JRAM-3 memory board, and the memory mapping is very simple. I was thinking about doing a direct hardware access without going through the EMS driver. on the JRAM-3, you could map a 64K segment anywhere on the 1M physical address. Thus, I could map 128K on D segment and the E segment. And the mapping is very simple, too. All is involved is to POKE a one-byte value into the control address (F800:0000 is the default). MOV F800:0000, 23H is all that's needed. (I didn't bother with MOV AX,F800 MOV DS,AX). Roy Fan University of California fan@cs.ucla.edu Los Angeles
jallen@netxcom.UUCP (John Allen) (04/24/87)
In article <5664@shemp.UCLA.EDU> fan@CS.UCLA.EDU (Roy Fan) writes: >---------- > > I am also thinking about creating an EMS ramdisk instead of >using system ramdisk. I have the book, but I didn't have the disks >yet. If I read the book correctly, I think that in order to implement >an EMS ramdisk: > >(1) the EMS ramdisk can have a maximum of 1MB since the pointer >they use is only 16 bits (the segment). This doesn't seem right >though, there might be something I miss. Actually, an EMS board can have 2MB of memory, and there can be four of them. Some EMS boards can have 4MB of memory, but look just like two 2MB boards to the driver. >(2) you will need an EMS driver that will map the logical memory >into the 64K physical memory. For a very simple ramdisk driver, I was >thinking of mapping the first bank to the beginning of the logical >memory, and the rest 3 banks after that. That way, you will have a >minimum of 48K to transfer. And if the process requests more than >48K, you could break them into parts. If you use all four page registers sequentially, then you could use DMA to move up to an entire segment from EMS to memory, and vice versa. > I have JRAM-3 memory board, and the memory mapping is very >simple. I was thinking about doing a direct hardware access without >going through the EMS driver. on the JRAM-3, you could map a 64K >segment anywhere on the 1M physical address. Thus, I could map 128K >on D segment and the E segment. And the mapping is very simple, too. >All is involved is to POKE a one-byte value into the control address >(F800:0000 is the default). MOV F800:0000, 23H is all that's >needed. (I didn't bother with MOV AX,F800 MOV DS,AX). Is this so? I though that the page registers were accessed through the I/O addresses: 2[0-F]8 and 2[0-F]9, depending upon switch settings, with two extra significant address bits (bit 14 and bit 15), providing access to the four page registers at I/O addresses: 02[x]8, 42[x]8, 82[x]8 and C2[x]8. As I understood it, the xxx8 addressed page registers contain the EMS page number being mapped, and the xxx9 addressed page registers contain the "page frame", ie: the segment address to which that EMS page is mapped, so that: (With dip switches set to 7) if 0x278 contains the value 0x10, and 0x279 contains the value 0xE000, then EMS memory page number 0x10 would be available to the processor at addresses E000:0 through E000:3FFF. >Roy Fan >University of California fan@cs.ucla.edu >Los Angeles Finally, since the entire F000 segment is reserved for ROM, isn't it unlikely that any registers would be placed there? Can anyone out there clear this up? John Allen ========================================================================= NetExpress Communications, Inc. seismo!{sundc|hadron}!netxcom!jallen 1953 Gallows Road, Suite 300 (703) 749-2238 Vienna, Va., 22180 =========================================================================
matt@inuxf.UUCP (Matt Verner) (04/25/87)
> > I want to look into writing an EMS driver into the RAMdisk driver. > Can anyone out there give me pointers to how the EMS hardware is accessed > by software ? I have a feeeling it's a dreadful kluge, but it might be nice > to be able to free up more RAM by stuffing the RAMdisk into kluge-mem. > Get a copy of Advanced MSDOS by Ray Duncan (Microsoft Press). It has a VERY complete description of the EMS standard. We used it to write our propreitary EMS stuff. Matt Verner UUCP: ...ihnp4!inuxc!matt AT&T Graphics Software Labs AT&T: (317) 844-4364 Indianapolis, IN "The whole point of this sentence is to clearly explain the point this sentence is making."
psfales@ihlpe.ATT.COM (Peter Fales) (04/26/87)
In article <266@inuxf.UUCP>, matt@inuxf.UUCP (Matt Verner) writes: > > > > I want to look into writing an EMS driver into the RAMdisk driver. > > Can anyone out there give me pointers to how the EMS hardware is accessed > > by software ? I have a feeeling it's a dreadful kluge, but it might be nice > > to be able to free up more RAM by stuffing the RAMdisk into kluge-mem. > > > > Get a copy of Advanced MSDOS by Ray Duncan (Microsoft Press). It has a VERY > complete description of the EMS standard. We used it to write our propreitary > EMS stuff. There is something that people may be missing when they talk about writing an EMS driver for MINIX. The EMS spec describes how an application talks to EMS memory using the driver provided by the manufacturer of the EMS board. There is no requirement that the actual hardware implementation be the same from manufacturer to manufacturer, only that the view provided to the application remain consistent. In fact, I have a copy of a program that purports to simulate EMS memory using a disk file. You can certainly believe that that EMS "board" wouldn't be compatible with a hardware implementation. While Ray Duncan's book is top notch (I have a copy myself) it would provide zero help in writing a driver for MINIX. -- Peter Fales UUCP: ...ihnp4!ihlpe!psfales work: (312) 979-7784 AT&T Information Systems, IW 1Z-243 1100 E. Warrenville Rd., IL 60566
fan@CS.UCLA.EDU (04/27/87)
>>(1) the EMS ramdisk can have a maximum of 1MB since the pointer >>they use is only 16 bits (the segment). This doesn't seem right >>though, there might be something I miss. > >Actually, an EMS board can have 2MB of memory, and there can be four of >them. Some EMS boards can have 4MB of memory, but look just like two >2MB boards to the driver. Sorry I didn't make myself clear. When I said about the 'pointer', I meant the pointer used in Minix. Doesn't the pointer has only 16 bits (I forgot the type name, physical_click or something like that). If only 16 bits are available, specifying a segment, doesn't that only give us 20 bits address, which is 1 Megabytes. Perhaps that we could have 2 EMS ramdisk? >>(2) you will need an EMS driver that will map the logical memory >>into the 64K physical memory. For a very simple ramdisk driver, I was >>thinking of mapping the first bank to the beginning of the logical >>memory, and the rest 3 banks after that. That way, you will have a >>minimum of 48K to transfer. And if the process requests more than >>48K, you could break them into parts. > >If you use all four page registers sequentially, then you could use >DMA to move up to an entire segment from EMS to memory, and vice versa. I don't think that we could use DMA to do memory to memory transfer in the IBM PC. >Is this so? I though that the page registers were accessed through the >I/O addresses: 2[0-F]8 and 2[0-F]9, depending upon switch settings, with >two extra significant address bits (bit 14 and bit 15), providing access >to the four page registers at I/O addresses: 02[x]8, 42[x]8, 82[x]8 and >C2[x]8. As I understood it, the xxx8 addressed page registers contain the >EMS page number being mapped, and the xxx9 addressed page registers >contain the "page frame", ie: the segment address to which that EMS page >is mapped, so that: > >Finally, since the entire F000 segment is reserved for ROM, isn't it >unlikely that any registers would be placed there? Can anyone out >there clear this up? The JRAM-3 board from Tall Tree is a successor of the JRAM-2 board. JRAM-2 board was introduced before the Lotus/Intel/Microsoft EMS, it used bank switching. The JRAM-3 is compatible with EMS specification and it can be used as 64K bank switching instead of just 4 16K. They have the so-called control register that will map any 64K from the board to any 64K in IBM's 1MB memory. The control register is located at any unused memory location, such as F800, E800, etc. The reason that they may use F800:0000 as the control register is that ROM is readable, but the control register is only writable. So if you do a READ on F800:0000 you got the ROM codes, but if you do a write on F800:0000, the ROM won't get changed because it is ROM, but it will affect the control register. Roy Fan University of California fan@cs.ucla.edu Los Angeles