chainsdude
Programmer
I was wondering if anyone had some sort of a list or more information on how the QBasic OUT command works and what it can do.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
QBasic OUT command
- Thread starter chainsdude
- Start date
- Status
Sorry, I don't have a list. However, I have come across several sites (don't remember which ones) that had some OUT commands. From what I have read (and seen some codes), the OUT command is some sort of direct device control command.<br><br>The only "OUT" command I use most often is <b>OUT &h64, &hFE</b> on a line by itself before the end of my programs. Be careful where you use this particulare code. It is designed to POKE the memory address for reboot (DOS 2 to 6.22 and Win 3.x). In WINDOWS 9x, it only ends your program <b>AND</b> closes the window that it is running in.<br><br><font color=red>Which is cool to use if a user puts in a dirty word, you can <b>reboot</b> their system--or at the very least--make them start from the beginning again. Hehe, haha.</font><br><br>good luck in the every exausting search for info on the web....<br><br>-MiggyD <p> <br><a href=mailto: > </a><br><a href= > </a><br>If a tree falls in the forest and there's no one around, does it make sound? Its not the sound that matters, but the silence it leaves behind.
The OUT statement is fairly powerful and can be very dangerous. If you have access to QB45 rather than Qbasic you might want to try InterruptX instead. Anything that can be done with an OUT can be performed with a CALL InterruptX, and more.<br><br>Oh, MiggyD, I use Interrupt 0, function 0 to perform the same trick. It generates a processor division-by-zero exception. <p> <br><a href=mailto: > </a><br><a href= plain black box</a><br>
Alt255<br><br>Thanks for the tid-bit on the Interupt call. You're right that it would be <i>safer</i>, but it doesn't automatically close the window in WIN 9x. I'll keep it in mind for another project I'm doing at work though.<br><br>See ya round and safe programming.<br><br>MiggyD <p> <br><a href=mailto: > </a><br><a href= > </a><br>If a tree falls in the forest and there's no one around, does it make sound? Its not the sound that matters, but the silence it leaves behind.
MiggyD, many apologies. My post contains some inconsistencies.<br>Interrupt 0 doesn't actually close a window, It halts the Win 9x system (doesn't work on NT Server or Workstation). It reboots the computer under DOS 6.2 and lower.<br>My point about the OUT statement is that port addresses are hardware specific. The same OUT command that closes a window on <i>your</i> computers could have detrimental effects on someone else's computer.<br>E-mail me if you would like some safe code for closing another app's window... or click on the link in my signature to read about some software that uses the code.<br><br>Sorry again.<br> <p> <br><a href=mailto: Vorpal1@Raex.com> Vorpal1@Raex.com</a><br><a href= plain black box</a><br>
<br>Alt255<br><br>I'm sorry I didn't inform you that the computers where I work are not networked. So, this 'out' would/will not affect the others (as I have already tried it long before my response to this post).<br><br>Also, what I had ment by <b>"The only "OUT" command I use most often ... before the end of my programs."</b> was that my cousins are CONSTANTLY bugging me for help on installations of their older DOS games and getting rid of other ones, (guess what) some games required rebooting... what stinks (other than my toes--see signature line at bottom) is that some of these had to be a custom install.<br><br>Anyway, if I <font color=red>would have to</font> write a QB program in an NT environment I would definitely not use the OUT, but instead use "c:\Windows\Rundll.exe User.exe,ExitWindows" -- if this looks familiar it's because you had posted this response in an other <i>"Help Me"</i> post. Way back when... and I thought it might be useful someday (and it works quite well, thanks Alt255), so I've made a note of it.<br><br>So thanks again Alt255. Have a good 4th of July. <p> <br><a href=mailto: > </a><br><a href= > </a><br>You put your left foot in, you put your left foot out, you put your left foot in and you shake it all about; and then the shoe comes FLYING OFF! Isn't that soooo embarrassing?
qbasicking
Programmer
I was looking around some of the old posts and I stumbled on this one: I like this question, i have been looking all over the internet for a list of the OUT statements but I couldn't find any.
So I decided to bring this post to the first page and see if anybody knows anything new.
Reboot Computer (DOS only):
OUT &H64, &HFE
Change Palette:
OUT &H3C8, colour&
OUT &H3C9, b&
OUT &H3C9, g&
OUT &H3C9, r&
Change Volume:
OUT &H22, vol&
Write to DSP
OUT &H80, byte%
'I know some more, but I have to find them
remember what was said in earlier posts, OUT is very powerful and has the potential to REALLY screw up your computer, use carefully
So I decided to bring this post to the first page and see if anybody knows anything new.
Reboot Computer (DOS only):
OUT &H64, &HFE
Change Palette:
OUT &H3C8, colour&
OUT &H3C9, b&
OUT &H3C9, g&
OUT &H3C9, r&
Change Volume:
OUT &H22, vol&
Write to DSP
OUT &H80, byte%
'I know some more, but I have to find them
remember what was said in earlier posts, OUT is very powerful and has the potential to REALLY screw up your computer, use carefully
There is nothing mystical about the [tt]OUT[/tt] command, and it is not at all related to the interrupt system in the way you describe. There are many things that can be done with [tt]OUT[/tt] that cannot be done with interrupt calls.
Here's how it works: Inside your computer, there is this thing called a "bus", which consists of a bunch of parallel lines that are hooked up to all devices of a particular type (for instance, all PCI devices are connected to one so-called "PCI bus"
. When you perform an OUT statement, the processor (which is also connected to the bus) announces that it is about to send data. This makes all of the devices on the bus wait and listen. Then, it sends the port number you specify down the "address lines" of the bus, and the data that you specify down the "data lines". Usually, exactly one device on the bus will recognize the port number that is on the address lines and will process the data. Sometimes, a system is misconfigured so that two devices are listening to the same port number. When this happens, communicating with one device interferes with the other one simultaneously. If the devices do not work the same way, this can cause highly undesirable things to happen. Thus, it is a good idea to ensure that no devices share the same port number(s). Plug and play does this automatically, but on older systems, you had to move jumpers to configure the cards, and it was easy to make mistakes that caused the system to malfunction.
As for reading from the bus (the [tt]INP()[/tt] function in QB), the processor announces that it is about to read, and then sends the port number down the address lines. The PCI bus standard specifies that a device responding to this must respond within a certain amount of time, so if any device is going to respond, it does so and puts the information on the data lines. After the time elapses, the processor reads the data lines, which presumably contain the data from that port.
Also note that the processor is not the only device which can initiate communication between devices. In fact, it is possible for two devices on the bus to talk to each other without interfering with the system's operation, though of this advantage is not often taken (wow, that was an awkward gramatical construct ^_^).
As a sidenote, I'll explain what interrupts are all about. Sometimes, a device has information that it wants the system to read, but the system is not aware of this. To take care of this problem, the processor has 16 so-called "interrupt request lines", also known as IRQs, which are wired to lines on the bus. In memory, the first kilobyte of memory is used to store memory addresses of so-called "interrupt handlers". Of the 16 hardware interrupts that are on the bus, only 8 were originally planned for, and the remaining 8 were added on in a rather haphazard fashion which involves interrupt 2 being invoked as a proxy to the upper 8. These lower 8 interrupts that were in the older specification correspond to interrupts 0x8 through 0xF in the processor's array of memory addresses.
When an interrupt line goes high, the processor saves information about what it is currently doing, and then branches off to the routine at the corresponding memory address. If IRQ 0 is invoked, then interrupt 8 is called on the processor. Once the interrupt processing is done, the old processor state is restored, and it resumes processing your code.
There was recently some discussion about accessing the keyboard using port I/O. This is how keyboard I/O really works at a low level: When you press a key, the keyboard controller on the motherboard records the scan code in a register, and then raises IRQ 1, which causes interrupt 9 to be called. Interrupt 9 reads the value from port &H60, which, as I just described, causes the processor to say "I will shortly read port &H60 from the bus", which in turn causes the keyboard controller to recognize that port number and set the data lines equal to the contents of the scan code register. When that short period of time allowed for devices to set the data lines elapses, the processor reads the data lines which contain the scan code from the keyboard, as well as an "activation bit" (which allows the software to determine whether the key was just pressed or just released). This value is returned to the interrupt handler which is still executing, and it processes the key information and adds it to [tt]INKEY$[/tt]'s queue and such. When it is done, it returns to your code, restoring the processor state, and your code has no clue that anything ever happened. The next time you access [tt]INKEY$[/tt], though, it contains the key that was read in from the keyboard.
Here's how it works: Inside your computer, there is this thing called a "bus", which consists of a bunch of parallel lines that are hooked up to all devices of a particular type (for instance, all PCI devices are connected to one so-called "PCI bus"
. When you perform an OUT statement, the processor (which is also connected to the bus) announces that it is about to send data. This makes all of the devices on the bus wait and listen. Then, it sends the port number you specify down the "address lines" of the bus, and the data that you specify down the "data lines". Usually, exactly one device on the bus will recognize the port number that is on the address lines and will process the data. Sometimes, a system is misconfigured so that two devices are listening to the same port number. When this happens, communicating with one device interferes with the other one simultaneously. If the devices do not work the same way, this can cause highly undesirable things to happen. Thus, it is a good idea to ensure that no devices share the same port number(s). Plug and play does this automatically, but on older systems, you had to move jumpers to configure the cards, and it was easy to make mistakes that caused the system to malfunction.As for reading from the bus (the [tt]INP()[/tt] function in QB), the processor announces that it is about to read, and then sends the port number down the address lines. The PCI bus standard specifies that a device responding to this must respond within a certain amount of time, so if any device is going to respond, it does so and puts the information on the data lines. After the time elapses, the processor reads the data lines, which presumably contain the data from that port.
Also note that the processor is not the only device which can initiate communication between devices. In fact, it is possible for two devices on the bus to talk to each other without interfering with the system's operation, though of this advantage is not often taken (wow, that was an awkward gramatical construct ^_^).
As a sidenote, I'll explain what interrupts are all about. Sometimes, a device has information that it wants the system to read, but the system is not aware of this. To take care of this problem, the processor has 16 so-called "interrupt request lines", also known as IRQs, which are wired to lines on the bus. In memory, the first kilobyte of memory is used to store memory addresses of so-called "interrupt handlers". Of the 16 hardware interrupts that are on the bus, only 8 were originally planned for, and the remaining 8 were added on in a rather haphazard fashion which involves interrupt 2 being invoked as a proxy to the upper 8. These lower 8 interrupts that were in the older specification correspond to interrupts 0x8 through 0xF in the processor's array of memory addresses.
When an interrupt line goes high, the processor saves information about what it is currently doing, and then branches off to the routine at the corresponding memory address. If IRQ 0 is invoked, then interrupt 8 is called on the processor. Once the interrupt processing is done, the old processor state is restored, and it resumes processing your code.
There was recently some discussion about accessing the keyboard using port I/O. This is how keyboard I/O really works at a low level: When you press a key, the keyboard controller on the motherboard records the scan code in a register, and then raises IRQ 1, which causes interrupt 9 to be called. Interrupt 9 reads the value from port &H60, which, as I just described, causes the processor to say "I will shortly read port &H60 from the bus", which in turn causes the keyboard controller to recognize that port number and set the data lines equal to the contents of the scan code register. When that short period of time allowed for devices to set the data lines elapses, the processor reads the data lines which contain the scan code from the keyboard, as well as an "activation bit" (which allows the software to determine whether the key was just pressed or just released). This value is returned to the interrupt handler which is still executing, and it processes the key information and adds it to [tt]INKEY$[/tt]'s queue and such. When it is done, it returns to your code, restoring the processor state, and your code has no clue that anything ever happened. The next time you access [tt]INKEY$[/tt], though, it contains the key that was read in from the keyboard.
- Status