|
Hello Baghli I dont have BC builder so I wont be able to open these projects, but I think I can help. And, I think you are on the right track if this is to succeed. The first thing that needs to be established is if one of the existing DOS/Console applications work with DIRECTIO. If DIRECTIO does not work in this case, Im not sure where to go. My understanding (at least with older NT versions) is that DIRECTIO is supposed to give a legacy application access to the PC's IO channel by disabling the GPF mechnanism for a particular location. The *new* DIRECTIO may require something else like linking into some kind of library. I just dont know. Here is how the GPF is supposed to work and how, at least the older DIRECTIO got around the GPF. - Each IO location in the PC has a IO Protection Map (IOPM) bit, an interrupt enable bit, associated with it. You can think of this like as being something like the Interrup Enable (IE) register in the C3x. If an IO access is made to a location whose IOPM bit is set, a GPF is generated telling the OS that a non-handled acccess has been made. Windows either generates a GPF message or goes back doing nothing. In either case, the IO access is aborted. If the IOPM bit for say the printer port is disabled, no GPF will be generated and IO access proceeds just like it did in the days before Windows. Basically this allows ANY legacy code to work with Windows NT, which is something has been trying to stamp out for years. So now I am told that the new versions of Windows continually update the IOPM so this is not as easy as it used to be. The new DSK software (by the way the most recent version available for download is 2.05) has taken the great leap out of the Window so to speak. Therefor if you cant find a way around this (using an older version of Windows, or hopefully DIRECTIO), you are destined to learn how to program Windows. EG lif is no longer easy. Anyhow, the new Windows NT based OS's (NT, 2K and XP) are supported through third party DLL's whose functions are called indirectly. In this case the NT support nonsense is handled by the third party. Nice, but the catch is that we are stuck with Windows programming and simple applications like "HELLO WORLD" become complex. Back to DIRECTIO --------------------- If DIRECTIO works, you should be able to call the inport and outport IO functions directly. Which functions are linked and used in the build are determined by the OS detection mechanisms in TYPDEFS.H Basically in this header you will find the #ifdef statements that figure out if the application is being built using Borland 3.1 (old DOS apps), Borland 4.5 in 16b mode, Borland 4.5 in 32b mode, or MSVC. Untill now I had not considered what it would take to build a DOS/Console application, but with the __WIN32__ and WINDOWS_LINK_ALL attributes set I think you are ultimately on the right track. I am thinking this because you will eventually want to include the following function(s). You may want to do a grep on DRIVER.CPP to find this. #if __WIN32__ // Borland Win32 build void outportb(WORD port, unsigned char value) { _asm push dx _asm push ax _asm mov dx,port _asm mov al,value _asm out dx,al _asm pop ax _asm pop dx } When you set the WINDOWS_LINK_ALL attribute you are essentially NOT building a DLL but rather linking all of the needed sources in with the main applicaion. You get a bigger executable, and the driver code is replicated for every application, but it is simple. Hope this helps Keith Larson DSP and Analog Consultant Lincoln, Ma baghli wrote: Hi Keith |