How to exit a gw basic program at any time? - basic

I am creating a game and i want that if the user hit F10 or any other function key then they the program should end.

Kinda bad that you haven't had this answered...
Well to start, you will have to find the ASCII value of whatever key you would like to have be the exit.
To do this either make a simple program to figure it out using chr$,asc(),and an input. Or just search it real quick.
What you are going to want to do is in your games area where you are using an inkey$(Which I assume you are, because most games would have movement and that is almost required) and just check for the key being pressed along with every other key.
For Example:
A simple movement game:
10 cls
20 K$=inkey$
30 if K$="a" then REM move left
40 if K$="d" then REM move right
50 if K$= EXITKEY then REM EXIT
60 goto 20
-Also, sorry if this is the incorrect method, but this should work...I'm still a bit rusty on GW

I assume you are in the middle of some kind of BASIC program and you would like to 'get out', exit from this ?
Press ENTER to get to a BLANK space and type system, hit ENTER again and you are out!

For future searchers, this answer provides additional context to inform the design of mechanisms for exiting BASIC programs.
For some simplistically designed BASIC programs, the only method to exit is Control-C or Control-Break. But some emulators (such as DOSBox) do not process Control-C in a manner that will present it to the underlying program.
On some systems, you can press Ctrl-ScrollLock as a workaround:
I have a little trick for those interested: use Ctrl-ScrollLock, it
behaves like Ctrl-Break with many BASIC interpreters running within
DOSBox. It works with GW-BASIC, BASICA (often bundled with compatible
DOSes like Compaq's), QBasic, QuickBasic, and possibly other
development "workbench" interfaces.
The reason this works is a little complicated, so only read on if
you're interested in knowing. DOSBox does not have true Ctrl-Break
handling like real DOS, which is a combination of hardware and
software interrupts and internal flags. However, the DOS Ctrl-Break
handler is only a default handler that all starts with INT 9, the
keyboard hardware interrupt. Many of the program development apps hook
INT 9 and intercept keys before DOS sees them, so they can do their
own processing. After all, the DOS default behavior for Ctrl-Break is
to terminate the app, and that is often not what is wanted. The INT 9
handler code looks for the Control key being depressed by checking the
shift status byte in BIOS data, and then reads scancodes from the
keyboard data port 60h. The scancode for ScrollLock is 46h, and the
scancode for Ctrl-Break is a 2-byte "escaped" sequence of E0h 46h,
where E0h is the escape code. It seems the handler routines are often
not very rigorous in their processing of the escape code, and just
drop it, so Ctrl-ScrollLock ends up working the same as Ctrl-Break.

This code snip exits a program when function key is pressed in Qbasic:
DO
DO
' read keyboard
X$ = INKEY$
IF LEN(X$) THEN
EXIT DO
END IF
LOOP
IF LEN(X$) = 2 THEN
x = ASC(RIGHT$(X$, 1))
' exit program on F1 to F10
IF x >= 59 AND x <= 68 THEN
END
END IF
END IF
LOOP

Related

Linux program to emulate keystrokes without X

I'm writing a driver for a pda with a goal of converting UART received key numbers to keystrokes.
The way i currently have this system set up is that when a key number is received, i can exec a program. In a config it is defined what command is executed if a certain number is received by my driver. It does this by fork()ing and exec()ing. It runs at boot and immediately parses these key numbers, so i intend to use this instead of a real keyboard.
Is there any program then, with which i could simply do something like
programname KEY_SPACE 1 to press KEY_SPACE
and
programname KEY_SPACE 0 to release KEY_SPACE?
Such a program must work without, as well as with X. I'd also prefer this to be able to do mouse events as well, however if there is a different program to do that, that's fine by me. It can be run as root as well, if need be.
What you need is to use uinput, it allows to emulate input device from userspace. You have documentation here: https://www.kernel.org/doc/html/v5.11/input/uinput.html
It has an example showing how to send a KEY_SPACE press event and then a KEY_SPACE release event.

How to detect xterm resize in-band

I'm looking for a way to get resize events on an xterm as an alternative to the winch signal. I need to get a signal for the xterm resize that is remote compatible, that is, could be used over a serial line/telnet/ssh/whatever. The winch signal is only for local machine tasks.
I know that vi/curses can do this because I have tried ssh and use vi to edit a file, and it responds to resizing of the window.
So after a bit of research, it does seem there is no in-band method for this. I don't think it would be difficult to add. You have two sides to a connection, ssh, serial or whatever, let's say A and B where A is on the host and B is the remote. To get behavior equivalent to a local windowed task, I would say at least two things are essential:
Mouse movement/button messaging.
Window resize messaging.
The second, can be a two step process. If the B task gets an alert that the window size has changed, it can use in band queries to determine what the new size is, using the (perhaps infamous) method of setting the cursor to the end of an impossibly large screen and then reading the actual location of the cursor that results, then restoring the location, all done with standard in-band controls.
Why care about in-band vs. out of band? Well, nobody cares now :-), but serial lines used to be quite popular, and in-band, that is, actual escape sequences sent down the line are going to work, but telnet or ssh "out of band" communication is not.
It would not be difficult to add, a local program that shims the ssh or telnet, or even xterm itself, can get the winch message and change that to an escape alert to the B side. Here the mouse messaging is instructive. The messages consist of two actions:
The B side must enable such messages, so that the A side won't send unknown escapes to it.
The A side must have an escape to signify winch.
Thus a new escape from B to A, and one from A to B.
I'm actually fairly satisfied with winch. What was wanted is to have the same capabilities as vi/curses (based on my observation). This kind of support is already far better than Windows, which (as far as I know) implements none of this remote side support.

How to read from STDIN_FILENO even if terminal is closed?

Im trying to code a program in Linux to read every input from keyboard, but using STDIN_FILENO it only reads those entered in the terminal. What I want is during execution it should read keyboard even if the terminal is closed.
STDIN_FILENO is just a helper macro.
From stdin you recieve stream of bytes that are passed to your program, they doesnt neccessary come from terminal - also can from a file, etc. It's not capturing keyboard. The terminal is capturing keyboard and then passes entered data to your program's stdin.
In order to capture keyboard you will need some other method of receiving events. I guess you are running GUI aka X server; Normally applications create windows and receive events related to them. In order to capture all keyboard events, you will have to go more low-level. Take a look at xlib which should be sufficient for you, even though it might not be.

Raspberry Pi Keyboard Interface (Key Remapping?)

I am building a Raspberry Pi wearable computer and as a result am not able to hook up a full sized keyboard to the Pi (I don't have one that is not full sized). Instead I have a numeric keypad USB attachment which functions as a keyboard, but only the numeric keypad part (0-9, a triple 0, +, -, *, - and numlock).
Now my question is: how would one go about writing a script/program to run in the background that will change input keypress(es) to other keypress(es), for example, changing 777 (in rapid succession) to 'c' or 5 to 'x'. This way I hope to be able to type, albeit slowly at first, using only 16 keys. What libraries are a good idea and do you have any sample usage of them.
Ideally this should work both in the startup command prompt (RPi doesn't run X immediately) and in the X environment.
You could use evmapd to catch the keyboard keycodes, and modify its source (I assume you're comfortable with C) to wait for multiple keystrokes before outputting a regular keyboard code. For example, send 67 for 'c' to the keyboard buffer, after receiving 97 (numpad 1) three times in quick succession from the physical device.

Can you write to [PC]?

According to the DCPU specification, the only time a SET instruction fails is if the a value is a literal.
So would the following work?
SET [PC],0x1000
A more useful version would be setting an offset of PC, so a rather strange infinite loop would be:
SET [PC+0x2],0x89C3 ; = SUB PC,0x2
Probably (= I think it should work but I didn't try).
This is called "self modifying" code and was quite common the 8bit era because of a) limited RAM and b) limited code size. Code like that is very powerful but error prone. If your code base grows, this can quickly become a maintenance nightmare.
Famous use cases:
Windows 95 used code like this to build graphics rendering code on the stack.
Viruses and trojans use this as an attack vector (write code on the stack or manipulate return addresses to simluate a JMP)
Simulate switch statements on the C64
There's no value for [PC], so I'm guessing you need to do it in a round-about way by storing PC in something you can use as a pointer (registry or memory).
SET A , PC
SET [A+3], 0x8dc3 ; SUB PC, 3 (if A can't be changed from outside SUB PC,2 works too.)

Resources