In and OUT
I think that - on Linux - you have to possibility to use a kernel function to make an I/O port accessible from a user-mode application. I've seen some references to this in the forums but I don't exactly know where I've seen it.
EDIT: This is the URL to the message for I/O access under Linux http://www.freebasic.net/forum/viewtopi ... =3957#3957
Regards,
Mark
EDIT: This is the URL to the message for I/O access under Linux http://www.freebasic.net/forum/viewtopi ... =3957#3957
Regards,
Mark
Ok, version in CVS has full real ports I/O support for both Linux and Win32.
On a modern OS, the asm IN/OUT instructions are priviledged instructions. This means you cannot call them from an user-mode program, unless it has the rights to do so.
So to get ports I/O to work, you have to tell the OS the process has the rights to access ports.
Under Linux, this is easy: just call the ioperm() libc function and you're done; it fails if the program is not being run with enough priviledges, but if it has them, FB will make the IN/OUT functions to work.
Under Win32, things were really different. There is no ioperm() there, nor any other hidden or exposed function to enable ports I/O.
As carefully explained on the following links:
http://www.beyondlogic.org/porttalk/porttalk.htm
http://www.codeproject.com/system/kportII.asp
http://www.logix4u.net/inpout32.htm
the suggested way to go under Win32 is via a kernel driver. I didn't want to use an external lib not to require users to ship it with their programs only if they used IN/OUT... So here's the solution I adopted: when using IN/OUT under Win32 for the first time during program execution, the functions will install a tiny embedded kernel driver on the system. The driver is actually a 3K binary embedded in your EXE; it is tiny in that it only allows two operations: get the driver version and enable I/O ports access to a given process id. Once the driver is installed, an ioctl is issued to control it and allow it to enable the current process to access all I/O ports. Then the driver's job is completed; from now on, the asm IN/OUT instructions can be used directly, and that's what FB does, allowing fast I/O like in DOS (contrary to what inpout32 and porttalk do, as they both use ioctl also to read/write ports, which is slower)
On a modern OS, the asm IN/OUT instructions are priviledged instructions. This means you cannot call them from an user-mode program, unless it has the rights to do so.
So to get ports I/O to work, you have to tell the OS the process has the rights to access ports.
Under Linux, this is easy: just call the ioperm() libc function and you're done; it fails if the program is not being run with enough priviledges, but if it has them, FB will make the IN/OUT functions to work.
Under Win32, things were really different. There is no ioperm() there, nor any other hidden or exposed function to enable ports I/O.
As carefully explained on the following links:
http://www.beyondlogic.org/porttalk/porttalk.htm
http://www.codeproject.com/system/kportII.asp
http://www.logix4u.net/inpout32.htm
the suggested way to go under Win32 is via a kernel driver. I didn't want to use an external lib not to require users to ship it with their programs only if they used IN/OUT... So here's the solution I adopted: when using IN/OUT under Win32 for the first time during program execution, the functions will install a tiny embedded kernel driver on the system. The driver is actually a 3K binary embedded in your EXE; it is tiny in that it only allows two operations: get the driver version and enable I/O ports access to a given process id. Once the driver is installed, an ioctl is issued to control it and allow it to enable the current process to access all I/O ports. Then the driver's job is completed; from now on, the asm IN/OUT instructions can be used directly, and that's what FB does, allowing fast I/O like in DOS (contrary to what inpout32 and porttalk do, as they both use ioctl also to read/write ports, which is slower)
To install the driver the program must be run with administrator level priviledges. This is done only once if the driver is not installed on the host computer, or if an old driver version is found. If FB can't find an existing driver and cannot install a new one, any call to INP/OUT will trigger a runtime error (error code 8, not enough priviledges) and the call will fail.
If FB finds the driver is already installed, but not started, it just asks the service to be started; when installing it, we told the system the driver can be started by anyone, so any user can start the driver.
Once the driver is loaded, any call to INP/OUT will just use the asm IN/OUT instructions regularly to handle the port I/O.
This is as far as it goes for real hardware port I/O. About gfxlib, while a gfx mode is set, certain port numbers are "hooked", that is calling IN/OUT/WAIT on them will not use real I/O, but will trigger VGA emulation. Hooked ports are &h3da, &h3c7, &h3c8 and &h3c9. Issuing INP/OUT to any other port while in gfx mode will still use real ports I/O...
If FB finds the driver is already installed, but not started, it just asks the service to be started; when installing it, we told the system the driver can be started by anyone, so any user can start the driver.
Once the driver is loaded, any call to INP/OUT will just use the asm IN/OUT instructions regularly to handle the port I/O.
This is as far as it goes for real hardware port I/O. About gfxlib, while a gfx mode is set, certain port numbers are "hooked", that is calling IN/OUT/WAIT on them will not use real I/O, but will trigger VGA emulation. Hooked ports are &h3da, &h3c7, &h3c8 and &h3c9. Issuing INP/OUT to any other port while in gfx mode will still use real ports I/O...
Hi all
I have a sneaky suspicion that a lot of the issues discussed here are more to do with running programs in console mode under windows.
Is anybody doing any documentation on running Fb in a clean Dos machine, or the differences to console mode.?
Regards
Edit:
For example this works fine.
I have a sneaky suspicion that a lot of the issues discussed here are more to do with running programs in console mode under windows.
Is anybody doing any documentation on running Fb in a clean Dos machine, or the differences to console mode.?
Regards
Edit:
For example this works fine.
Code: Select all
FUNCTION CPLDA2D1&
asm
XOR EAX,EAX
MOV DX,&H158
IN AL,DX
MOV AH,AL 'Read first Byte
MOV DX,&H159
IN AL,DX 'Read second Byte
MOV [FUNCTION],EAX
end asm
END FUNCTION