OSDev.org

When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?

not exactly

when you access memory (or anything mapped as memory) the CPU puts the address you are accessing on the address bus, and indicates with another pin whether it wants to read or write

then whatever is watching the address bus, sees its own address, and responds by either placing data on the data bus, or receiving the data that is on the data bus

when you us "in" and "out" instructions, what the CPU does, is put the address (in this case 0x60) on the address bus, and then indicate with another pin that it is accessing the I/O bus rather than the memory bus, then whatever device is watching for I/O writes to that particular address responds as appropriate

the CPU doesn't know that 0x60 is the keyboard, it only knows that it is an address, its the keyboard controller that "knows" it should respond to address 0x60

in the diagram you posted, those pins labled AD# are both the address and data bus, the another pin (don't remember which one) indicates whether it is an address on the I/O bus, or memory bus, and another pin indicates whether it is a read or write



of course this is a very simple view of things, modern CPUs are extremely complex, relatively speaking

JAAman wrote:

When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?

not exactly

when you access memory (or anything mapped as memory) the CPU puts the address you are accessing on the address bus, and indicates with another pin whether it wants to read or write

then whatever is watching the address bus, sees its own address, and responds by either placing data on the data bus, or receiving the data that is on the data bus

when you us "in" and "out" instructions, what the CPU does, is put the address (in this case 0x60) on the address bus, and then indicate with another pin that it is accessing the I/O bus rather than the memory bus, then whatever device is watching for I/O writes to that particular address responds as appropriate

the CPU doesn't know that 0x60 is the keyboard, it only knows that it is an address, its the keyboard controller that "knows" it should respond to address 0x60

in the diagram you posted, those pins labled AD# are both the address and data bus, the another pin (don't remember which one) indicates whether it is an address on the I/O bus, or memory bus, and another pin indicates whether it is a read or write



of course this is a very simple view of things, modern CPUs are extremely complex, relatively speaking

So basically all the hardware share the same channel and in this case all the hardware that don't have an ID of 0x60 wont respond?

computertrick wrote:Do you think I should be using 16 bit registers in case the keyboard sends 16 bit values?

The keyboard registers addressable by software are all eight bits wide, although, just to make things more complicated, some keys send a stream of eight bit bytes, instead of just one. Usually that happens with keys which were not present on the original IBM keyboard.

Also could you explain 0x60 to me. How does the CPU know 0x60 is the keyboard? is 0x60 a pin number or something?

It doesn't need to know, any more than a port on a microcontroller needs to "know" that it is connected to an LED. It is the hardware designer and programmer who need to know that.

When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?

If it helps you to think in those terms you can do so. When I first began programming the PC in assembly language, in my minds eye I imagined something like that to be happening. Programming a computer means thinking in terms of pictures, because, after all, to try and think in terms of electrons trapped in depletion layers is not especially useful. But, as Jaaman says, what you imagine happening in your mind's eye, and what happens in reality, are not necessarily the same thing.

All communication with other components (memory and I/O) comes through the same pins. Every device examines the incoming address signals to determine if it is being addressed. The addressed device then performs the requested operation, and in the case of a read cycle, the data lines are driven as appropriate. All other devices leave their output pins in high-Z. Don't try to read or write using the wrong data size. For example, the keyboard controller requires bytes.

When I want to send data I just set a bit to high on PORTA or PORTB and it turns on. And for receiving I just check if the pin is high. Surly their is some similarity with the Intel processors?

Not quite. Reading an I/O port on an x86 system may have side effects, whereas reading a pin on a microcontroller does not. In the same manner, writing to an I/O port may have side effects, even if it is the same value that was just written. Port 60h on a PC has a side effect both when reading and when writing.

computertrick wrote:In long term I'm hoping to read in visual input from a camera or something.

If this is where you're thinking of going with it, I wonder if you'd be better off biting the bullet and writing device drivers for USB. It's probably less work and more useful than trying to wire something up which no one else will ever duplicate.

DavidCooper wrote:

computertrick wrote:In long term I'm hoping to read in visual input from a camera or something.

If this is where you're thinking of going with it, I wonder if you'd be better off biting the bullet and writing device drivers for USB. It's probably less work and more useful than trying to wire something up which no one else will ever duplicate.

I think you could be right do you know what address the usb port uses?

computertrick wrote:I think you could be right do you know what address the usb port uses?

Don't expect it to be that easy - it's a massive task which I'm only just taking on now. You need to start with this PCI page in the wiki which will show you how to look for things like USB controllers which will have different locations in different machines (use one of the external links at the end to identify what the devices you find are). The next thing you should do is read the book Mike Gonta recommends in the Book Recommendations thread in this forum - a Kindle version is now available for a much lower price (though the paper version's well worth the money), and some of it can be read at Amazon without buying it.

DavidCooper wrote:

computertrick wrote:I think you could be right do you know what address the usb port uses?

Don't expect it to be that easy - it's a massive task which I'm only just taking on now. You need to start with this PCI page in the wiki which will show you how to look for things like USB controllers which will have different locations in different machines (use one of the external links at the end to identify what the devices you find are). The next thing you should do is read the book Mike Gonta recommends in the Book Recommendations thread in this forum - a Kindle version is now available for a much lower price (though the paper version's well worth the money), and some of it can be read at Amazon without buying it.

I'm aware that their are protocols involved. Thanks for the link I'm going to check it out!

No.
On intel processors, devices are mapped by the bios to changable port numbers or memory addresses. 0x60/0x64 for ps/2 is fairly standard, most arent

computertrick wrote:I think you could be right do you know what address the usb port uses?

Heh. That makes me smile.

The CPU is wired (more or less) directly to the Keyboard controller, which is why you can communicate with it using IN and OUT commands. This technology and those port numbers were defined about 40 years ago.

USB controllers on the other hand, have only been around for around, well, 20 years. But still, the technology between a PS/2 keyboard and a USB keyboard is completely different.

To communicate with USB devices, you need to communicate with the USB Host Controller, which is a PCI device. So before you can communicate with the USB Host Controller, you will need to communicate with the PCI Bus and "find" the USB Host Controller. Check out the wiki page for "PCI" to get started. Then take a look at the "USB" wiki page.

I am currently working on some USB code myself, so feel free to PM me any questions about the PCI bus or the USB controllers after you have read the wiki pages.

Good luck!

SpyderTL wrote:

computertrick wrote:I think you could be right do you know what address the usb port uses?

Heh. That makes me smile.

The CPU is wired (more or less) directly to the Keyboard controller, which is why you can communicate with it using IN and OUT commands. This technology and those port numbers were defined about 40 years ago.

I'm not sure what you meant by (more or less) directly wired, it is so ambiguous.
However, some modern machine don't have KBC at all. Some BIOS may provide emulation, otherwise accessing such port may result in freezing the machine (as for mac).
In case a legacy KBC is physically exists, it's commonly hosted on the south-bridge, which is far from directly wired to CPU.