Can I have C code for a outb_delay and inb_delay function for my OS. How to work these functions.
Thanks... CyberMan
outb_delay() function
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:outb_delay() function
yes, you can ... just check out the linux sources ...
Re:outb_delay() function
When you program for an OPL2-chip you needed an delay when writing to the chip, too. There it was achieved by making
out al, 0x220
in al, 0x220
although the in instruction didn't produce any useful value , it created the necessary delay there.
If you can't make an in instruction there, I think you'll need a generic sleep function first ...
out al, 0x220
in al, 0x220
although the in instruction didn't produce any useful value , it created the necessary delay there.
If you can't make an in instruction there, I think you'll need a generic sleep function first ...
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:outb_delay() function
imho, it is unlikely that a single function could fullfill all the needs for I/O wait states: virtually every device have different timing constraints, and there is no generic rule like "read on port X until value Y appear to know if command on port Z is issued" ... though this scheme is almost true on every device, the X and Y value cannot be computed simply from the Z value (afaik) ...
with current CPU speed (and more important, with their ability to evaluate in parallel several branching possibilities and only keeping the right one), slowing down I/O with a jmp $ command won't work anymore. usually, issuing another (independent) I/O cycle on a port you know to be unattached to any device (Linux uses port 0x80) will be a safer option.
It should only be used to prevent the CPU to send successive bytes of a multi-bytes command too fast to a slow device (8042 when enabling A20 gate, for instance), but can't be relied when you wait for a result ...
with current CPU speed (and more important, with their ability to evaluate in parallel several branching possibilities and only keeping the right one), slowing down I/O with a jmp $ command won't work anymore. usually, issuing another (independent) I/O cycle on a port you know to be unattached to any device (Linux uses port 0x80) will be a safer option.
It should only be used to prevent the CPU to send successive bytes of a multi-bytes command too fast to a slow device (8042 when enabling A20 gate, for instance), but can't be relied when you wait for a result ...