Re: Some I/O port s seem to be blocked / Win 98
From: Alexander Nickolov (agnickolov_at_mvps.org)
Date: 04/29/04
- Next message: Alexander Nickolov: "Re: COM threads pool in MTA"
- Previous message: Gottfried: "Re: Some I/O port s seem to be blocked / Win 98"
- In reply to: Gottfried: "Re: Some I/O port s seem to be blocked / Win 98"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 28 Apr 2004 21:08:10 -0700
You can "assign" I/O addresses, by plugging a PCI card that
has registers (e.g. memory) on those I/O addresses. The
same way you assign physical memory addresses (again,
not virtual memory) by plugging in more memory modules.
As I already mentioned, there's no virtual address translation
for I/O ports. One point I forgot to mention is that not all
hardware platforms have I/O ports. IIRC the Motorola 68K
family of CPUs (the old Macs) did not. Many embedded
CPUs don't either. On such platforms I/O is done by addressing
regular memory addresses.
In short, there's nothing you can do with software only. You
need the hardware.
-- ===================================== Alexander Nickolov Microsoft MVP [VC], MCSD email: agnickolov@mvps.org MVP VC FAQ: http://www.mvps.org/vcfaq ===================================== "Gottfried" <anonymous@discussions.microsoft.com> wrote in message news:D97BA31A-C622-4379-A1A7-6716BE0E030F@microsoft.com... > > ok an unassigned Port address points to the void > and in Win NT 2000 xp the ports are protected. > > But isn't there a method (for me) to define or assign a free port address i.e. to reserve it for software programs I may want to write to communicate over this new defined port. > Is a port necessarily only available for hardware (to be used by software) ? > But the installation routine of hardware must also reserve a particular I/O port address - isn't it ? > or is the port address of hardware defined "on board". > > Just some theoretical questions (of a software developer)... > > ----- Alexander Nickolov wrote: ----- > > An I/O port is just like the physical memory, but without the > virtual address translation (think old DOS and real mode). > IIRC, you have 64K ports (16 bit adressing) in the x86 > family of procesors. Unlike memory, the assigned addresses > are "randomly" scattered throughout this address space. > However, just like with physical memory, writing into an > unasigned address goes into the void. You won't see this > under Windows, because of the virtual memory addressing > and the page fault generated by the CPU, but in real mode > there is no such thing and you can happily write outside the > borders of your memory. (Even though you only have 1MB > of addressable memory in real mode, the memory organization > has gaps after the 640K of RAM, so this is possible.) In short, > what you are trying to do is pointless - as Igor already underscored, > writing into unassigned addresses (not backed by hardware > registers) produces the behavior you observe. Note, you can > do that under Win9x because there's no protection, but under > the Win NT family of OSes (including WinXP Home) this is > not going to fly. Ports can only be accessed by device drivers. > > -- > ===================================== > Alexander Nickolov > Microsoft MVP [VC], MCSD > email: agnickolov@mvps.org > MVP VC FAQ: http://www.mvps.org/vcfaq > ===================================== > "Gottfried" <anonymous@discussions.microsoft.com> wrote in message > news:405CACDB-E76D-4436-B9BB-6BD1A2A4AC4B@microsoft.com... > >> ----- Igor Tandetnik wrote: ----- > >> "Gottfried" <anonymous@discussions.microsoft.com> wrote in message > >> news:9B38A1CF-C4D9-48D6-BAEE-F5A6E1C2DE6D@microsoft.com > >>> I'm currently testing to read from and write to ports using the > >>> assembler commands IN and OUT (e.g:OUT DX, AL ) It works fine with > >>> ports that are already assigned to any hardware (e.g.: $0220 for the > >>> sound card OPL2 or $0060 for the keyboard). But for others it fails > >>> writing to a port that is not already assigned. The port value stays > >>> constant and does not change to the value written to it. > >>> I/O port is not a memory address. > >> Yes, I know, but it was the criterion I used to see if it works. I wrote a > tiny port writer and a listener as pre test yust to get familliar to that > toppic. > >>> It is not supposed to remember the > >> previously assigned value. It reports whatever value the attached > device > >> put into it (which may not be the same as the value you have written > to > >> the port previously). If there is no device, I suspect you will > always > >> read 0 from the port. > >> Yes, it was 0 or 255 or a third value I do not remember now. > >>> Why do you want to write to a port not backed by hardware anyway? > >> First just see what happens (lets say debug reasoons) and to learn. > > And may be I will write a programs that exchange data using a new port and > I have to reserve the I/O range that no other program can use it. > >> But my original task I had was to examin why one program using a port to > address the sound card worked on one PC and on an other not and so I started > to make some tests .. writing to and reading from a port. > >> And now I am on that point. > >>> Thanks for your answer Igor . > >> -- > > With best wishes, > > Igor Tandetnik > >> "For every complex problem, there is a solution that is simple, neat, > > and wrong." H.L. Mencken > >>>
- Next message: Alexander Nickolov: "Re: COM threads pool in MTA"
- Previous message: Gottfried: "Re: Some I/O port s seem to be blocked / Win 98"
- In reply to: Gottfried: "Re: Some I/O port s seem to be blocked / Win 98"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
Loading
