CALL -151 What did it do on the APPLE ][ - command-line
A long time ago I had an apple ][ .
I remember the command call – 151
But I can not remember what it did ?
CALL -151
Enter the machine code monitor -
http://www.skepticfiles.org/cowtext/apple/memorytx.htm
Update:
That link appears to be dead, here's a Wayback Machine alternative:
http://web.archive.org/web/20090315100335/http://www.skepticfiles.org/cowtext/apple/memorytx.htm
Here's the full article just in case Wayback goes away:
APPLE CALL, PEEK, POKE LIST CALL 144 SCAN THE INPUT BUFFER CALL 151 ENTER THE MONITOR NORM
APPLE CALL, PEEK, POKE LIST
------------------------------------------------------------------------------
CALL -144 SCAN THE INPUT BUFFER
CALL -151 ENTER THE MONITOR NORMALLY
CALL -155 ENTER THE MONITOR & SOUND BELL
CALL -167 ENTER MONITOR AND RESET
CALL -198 RING BELL (SIMULATE CONTROL G)
CALL -211 PRINT "ERR" AND RING BELL
CALL -259 READ FROM TAPE
CALL -310 WRITE TO TAPE
CALL -321 DISPLAYS A, S, Y, P, & S REGISTERS
CALL -380 SET NORMAL VIDEO MODE
CALL -384 SET INVERSE VIDEO MODE
CALL -415 DISASSEMBLE 20 INSTRUCTIONS
CALL -458 VERIFY (COMPARE & LIST DIFFERENCES)
CALL -468 MEMORY MOVE AFTER POKING 60,61 OLD START - 62,63 OLD END
64,65 NEW END - 66,67 NEW STAR
CALL -484 MOVE
CALL -517 DISPLAY CHARACTER & UPDATE SCREEN LOCATION
CALL -531 DISPLAY CHARACTER, MASK CONTROL CHAR., & SAVE 7 REG. & ACCU
CALL -550 DISPLAY HEX VALUE OF A-REGISTER (ACCUMULATOR)
CALL -656 RING BELL AND WAIT FOR A CARRIAGE RETURN
CALL -657 GET LINE OF INPUT, NO PROMPT, NO L/F, & WAIT(COMMA,COLON OK
CALL -662 GET LINE OF INPUT, WITH PROMPT, NO L/F, & WAIT
CALL -665 GET LINE OF INPUT, WITH PROMPT, LINE FEED, & WAIT
THE ABOVE 3 CALLS (-657, -662, -665) REFER TO THE INPUT BUFFER FROM 512-767
CALL -715 GET CHARACTER
CALL -756 WAIT FOR KEY PRESS
CALL -856 TIME DELAY (POKE 69,XX TO SET TIME OF DELAY)
CALL -868 CLEARS CURSOR LINE FROM CURSOR TO END OF LINE
CALL -912 SCROLLS TEXT UP 1 LINE
CALL -922 LINE FEED
CALL -936 CLEAR SCREEN (HOME)
CALL -958 CLEAR SCREEN FROM CURSOR TO BOTTOM OF SCREEN
CALL -998 MOVES CURSOR UP 1 LINE
CALL -1008 MOVES CURSOR BACKWARD 1 SPACE
CALL -1024 DISPLAY CHARACTER ONLY
CALL -1036 MOVES CURSOR FORWARD 1 SPACE
CALL -1063 SEND BELL TO CURRENT OUTPUT DEVICE
CALL -1216 TEXT & GRAPHICS MODE
CALL -1233 MOVE CURSOR TO BOTTOM OF SCREEN
CALL -1321 CONTROL E
CALL -1717 MOVES CURSOR DOWN 5 LINES
CALL -1840 DISASSEMBLE 1 INSTRUCTION
CALL -1953 CHANGE COLOR BY +3
CALL -1994 CLEAR LO-RES SCREEN (TOP 40 LINES)
CALL -1998 CLEAR GRAPHIC SCREEN (LO-RES)
CALL -2007 VERTICAL LINE
CALL -2023 HORIZONTAL LINE
CALL -2458 ENTER MINI ASSEMBLER
CALL -3100 TURNS ON HIRES PAGE 1, WITHOUT CLEARING IT
CALL -3776 SAVE INTEGER
CALL -3973 LOAD INTEGER
CALL -6090 RUN INTEGER
CALL -8117 LIST INTEGER
CALL -8189 ENTER BASIC & CONTINUE
CALL -8192 ENTER BASIC AND RESET (INTEGER BASIC KILL)
CALL -16303 TEXT MODE
CALL -16304 GRAPHICS MODE
CALL -16336 TOGGLE SPEAKER
CALL 42350 CATALOGS DISK
CALL 54915 CLEANS STACK, CLEARS THE "OUT OF MEMORY" ERROR
CALL 64166 INITIATES A COLD START (BOOT OF THE DISK)
CALL 64246 BRAND NEW-YOU FIGURE IT OUT
CALL 64367 SCANS MEMORY LOC 1010 & 1011 & POKES VALUE INTO LOCATIONS
1012 THAT IS EQUAL TO (PEEK(1011)-165)
------------------------------------------------------------------------------
PEEK 33 WIDTH OF TEXT WINDOW (1-40)
PEEK 34 TOP EDGE OF TEXT WINDOW (0-22)
PEEK 35 BOTTOM OF TEXT WINDOW (1-24)
PEEK 36 HORIZONTAL CURSOR POSITION (0-39)
PEEK 37 VERTICAL CURSOR POSITION (0-23)
PEEK 43 BOOT SLOT X 16 (AFTER BOOT)
PEEK 44 END POINT OF LAST HLIN, VLIN, OR PLOT
PEEK 48 LO-RES COLOR VALUE X 17
PEEK 50 TEXT OUTPUT FORMAT: 63=INVERSE 255=NORMAL
127=FLASH ( WITH PEEK 243 SET TO 64)
PEEK 51 PROMPT CHARACTER
PEEK 74,75 LOMEM ADDRESS (INT)
PEEK 76,77 HIMEM ADDRESS (INT)
PEEK 103,104 FP PROGRAM STARTING ADDRESS
PEEK 104 IF 8 IS RETURNED, THEN FP IS IN ROM
PEEK 105,106 FP VARIABLE SPACE STARTING ADDRESS
PEEK 107,108 FP ARRAY STARTING ADDRESS
PEEK 109,110 FP END OF NUMERIC STORAGE ADDRESS
PEEK 111,112 FP STRING STORAGE STARTING ADDRESS
PEEK 115,116 FP HIMEM ADDRESS
PEEK 117,118 FP LINE NUMBER BEING EXECUTED
PEEK 119,120 FP LINE WHERE PROGRAM STOPPED
PEEK 121,122 FP LINE BEING EXECUTED ADDRESS
PEEK 123,124 LINE WHERE DATA BEING READ
PEEK 125,126 DATA LOCATION ADDRESS
PEEK 127,128 INPUT OR DATA ADDRESS
PEEK 129,130 FP LAST USED VARIABLE NAME
PEEK 131,132 FP LAST USED VARIABLE ADDRESS
PEEK 175,176 FP END OF PROGRAM ADDRESS
PEEK 202,203 INT PROGRAM STARTING ADDRESS
PEEK 204,205 INT END OF VARIABLE STORAGE
PEEK 214 FP RUN FLAG (AUTO-RUN IF >127)
PEEK 216 ONERR FLAG (>127 IF ONERR IS ACTIVE)
PEEK 218,219 LINE WHERE ONERR OCCURED
PEEK 222 ONERR ERROR CODE
PEEK 224,225 X-COORDINATE OF LAST HPLOT
PEEK 226 Y-COORDINATE OF LAST HPLOT
PEEK 228 HCOLOR VALUE 0=0 85=2 128=4 213=6
42=1 127=3 170=5 255=7
PEEK 230 HI-RES PLOTING PAGE (32=PAGE 1 64=PAGE 2 96=PAGE 3)
PEEK 231 SCALE VALUE
PEEK 232,233 SHAPE TABLE STARTING ADDRESS
PEEK 234 HI-RES COLLISION COUNTER
PEEK 241 256 MINUS SPEED VALUE
PEEK 243 FLASH MASK (64=FLASH WHEN PEEK 50 SET TO 127)
PEEK 249 ROT VLAUE
PEEK 976-978 DOS RE-ENTRY VECTOR
PEEK 1010-1012 RESET VECTOR
PEEK 1013-1015 AMPERSAND (&) VECTOR
PEEK 1016-1018 CONTROL-Y VECTOR
PEEK 43140-43271 DOS COMMAND TABLE
PEEK 43378-43582 DOS ERROR MESSAGE TABLE
PEEK 43607 MAXFILES VALUE
PEEK 43616,46617 LENGTH OF LAST BLOAD
PEEK 43624 DRIVE NUMBER
PEEK 43626 SLOT NUMBER
PEEK 43634,43635 STARTING ADDRESS OF LAST BLOAD
PEEK 43697 MAXFILES DEFAULT VALUE
PEEK 43698 DOS COMMAND CHARACTER
PEEK 43702 BASIC FLAG (0=INT 64=FP ROM 128=FP RAM)
PEEK 44033 CATALOG TRACK NUMBER (17 IS STANDARD)
PEEK 44567 NUMBER OF CHARACTERS MINUS 1 IN CATALOG FILE NAMES
PEEK 44611 NUMBER OF DIGITS MINUS 1 IN SECTOR AND VOLUME NUMBERS
PEEK 45991-45998 FILE-TYPE CODE TABLE
PEEK 45999-46010 DISK VOLUME HEADING
PEEK 46017 DISK VOLUME NUMBER
PEEK 46064 NUMBER OF SECTORS (13=DOS 3.2 16=DOS 3.3)
PEEK 49152 READ KEYBOARD (IF >127 THEN KEY HAS BEEN PRESSED
PEEK 49200 TOGGLE SPEAKER (CLICK)
PEEK 49248 CASSETTE INPUT (>127=BINARY 1, 127 IF BUTTON PRESSED)
PEEK 49250 PADDLE 1 BUTTON (>127 IF BUTTON PRESSGD)
PEEK 49251 PADDLE 2 BUTTON (>127 IF BUTTON PRESSED)
PEEK 49252 READ GAME PADDLE 0 (0-255)
PEEK 49253 READ GAME PADDLE 1 (0-255)
PEEK 49254 READ GAME PADDLE 2 (0-255)
PEEK 49255 READ GAME PADDLE 3 (0-255)
PEEK 49408 READ SLOT 1
PEEK 49664 READ SLOT 2
PEEK 49920 READ SLOT 3
PEEK 50176 READ SLOT 4
PEEK 50432 READ SLOT 5
PEEK 50688 READ SLOT 6 (162=DISK CONROLLOR CARD)
PEEK 50944 READ SLOT 7
PEEK 64899 INDICATES WHICH COMPUTER YOU'RE USING
223=APPLE II OR II+, 234=FRANKLIN ACE OR ?, 255=APPLE IIE
POKE 33,33 SCRUNCH LISTING AND REMOVE SPACES IN QUOTE STATEMENTS
POKE 36,X USE AS PRINTER TAB (X=TAB - 1)
POKE 50,128 MAKES ALL OUTPUT TO THE SCREEN INVISIBLE
POKE 50,RANDOM SCRAMBLES OUTPUT TO SCREEN
POKE 51,0 DEFEATS "NOT DIRECT COMMAND", SOMETIMES DOESN'T WORK
POKE 82,128 MAKE CASETTE PROGRAM AUTO-RUN WHEN LOADED
POKE 214,255 SETS RUN FLAG IN FP & ANY KEY STROKES WILL RUN DISK PROGRA
POKE 216,0 CANCEL ONERR FLAG
POKE 1010,3 SETS THE RESET VECTOR TO INITIATE
POKE 1011,150 A COLD START (BOOT)
POKE 1010,102 MAKE
POKE 1011,213 RESET
POKE 1012,112 RUN
POKE 1014,165 SETS THE AMPERSAND (&) VECTOR
POKE 1015,214 TO LIST YOUR PROGRAM
POKE 1014,110 SETS THE AMPERSAND (&) VECTOR
POKE 1015,165 TO CATALOG A DISK
POKE 1912+SLOT,1 ON APPLE PARALLEL CARD (WITH P1-02 PROM) WILL ENABLE L/F'S
POKE 1912+SLOT,0 ON APPLE PARALLEL CARD (WITH P1-02 PROM) WILL ENABLE L/F'S
POKE 2049,1 THIS WILL CAUSE THE FIRST LINE OF PROGRAM TO LIST REPEATEDLY
POKE 40514,20 ALLOWS TEXT FILE GREETING PROGRAM
POKE 40514,52 ALLOWS BINARY FILE GREETING PROGRAM
POKE 40993,24 THIS ALLOWS
POKE 40994,234 DISK COMMANDS IN
POKE 40995,234 THE DIRECT MODE
POKE 42319,96 DISABLES THE INIT COMMAND
POKE 42768,234 CANCEL ALL
POKE 42769,234 DOS ERROR
POKE 42770,234 MESSAGES
POKE 43624,X SELECTS DISK DRIVE WITHOUT EXECUTING A COMMAND (48K SYSTEM)
POKE 43699,0 TURNS AN EXEC FILE OFF BUT LEAVES IT OPEN UNTIL A FP, CLOSE
POKE 43699,1 TURNS AN EXEC FILE BACK ON. INIT, OR MAXFILES IS ISSUE
POKE 44452,24 ALLOWS 20 FILE NAMES (2 EXTRA)
POKE 44605,23 BEFORE CATALOG PAUSE
POKE 44505,234 REVEALS DELETED FILE
POKE 44506,234 NAMES IN CATALG
POKE 44513,67 CATALOG WILL RETURN ONLY LOCKED FILES
POKE 44513,2 RETURN CATALOG TO NORMAL
POKE 44578,234 CANCEL CARRIAGE
POKE 44579,234 RETURNS AFTER CATALOG
POKE 44580,234 FILE NAMES
POKE 44596,234 CANCEL
POKE 44597,234 CATALOG-STOP
POKE 44598,234 WHEN SCREEN IS FULL
POKE 44599,234 STOP CATALOG AT EACH FILE
POKE 44600,234 NAME AND WAIT FOR A KEYPRESS
POKE 46922,96 THIS ALLOWS DISK
POKE 46923,234 INITIALATION
POKE 46924,234 WITHOUT PUTTING
POKE 44723,4 DOS ON THE DISK
POKE 49107,234 PREVENT LANGUAGE
POKE 49108,234 CARD FROM LOADING
POKE 49109,234 DURING RE-BOOT
POKE 49168,0 CLEAR KEYBOARD
POKE 49232,0 DISPLAY GRAPHICS
POKE 49233,0 DISPLAY TEXT
POKE 49234,0 DISPLAY FULL GRAPHICS
POKE 49235,0 DISPLAY TEXT/GRAPHICS
POKE 49236,0 DISPLAY GRAPHICS PAGE 1
POKE 49237,0 DISPLAY GRAPHICS PAGE 2
POKE 49238,0 DISPLAY LORES
POKE 49239,0 DISPLAY HIRES
------------------------------------------------------------------------------
48K MEMORY MAP
DECIMAL HEX USAGE
------------------------------------------------------------------------------
0-255 $0-$FF ZERO-PAGE SYSTEM STORAGE
256-511 $100-$1FF SYSTEM STACK
512-767 $200-$2FF KEYBOARD CHARACTER BUFFER
768-975 $300-$3CF OFTEN AVAILABLE AS FREE SPACE FOR USER PROGRAMS
976-1023 $3D0-3FF SYSTEM VECTORS
1024-2047 $400-$7FF TEXT AND LO-RES GRAPHICS PAGE 1
2048-LOMEM $800-LOMEM PROGRAM STORAGE
2048-3071 $800-$BFF TEXT AND LO-RES GRAPHICS PAGE 2 OR FREE SPACE
3072-8191 $C00-$1FFF FREE SPACE UNLESS RAM APPLESOFT IS IN USE
8192-16383 $2000-$3FFF HI-RES PAGE 1 OR FREE SPACE
16384-24575 $4000-$5FFF HI-RES PAGE 2 OR FREE SPACE
24576-38999 $6000-$95FF FREE SPACE AND STRING STORAGE
38400-49151 $9600-$BFFF DOS
49152-53247 $C000-$CFFF I/O HARDWARE (RESERVED)
53248-57343 $D000-$DFFF APPLESOFT IN LANGUAGE CARD OR ROM
57344-63487 $E000-$F7FF APPLESOFT OR INTEGER BASIC IN LANGUAGE CARD OR ROM
63488-65535 $F800-$FFFF SYSTEM MONITOR
PEEK: TO EXAMINE ANY MEMORY LOCATION L, PRINT PEEK (L), WHERE L IS A DECIMAL
NUMBER 0-65535. TO PEEK AT A TWO-BYTE NUMBER AT CONSEQUTIVE LOCATIONS L AND
L+1, PRINT PEEK (L) + PEEK (L+1) * 256
POKE: TO ASSIGN A VALUE X (0-255) TO LOCATION L; POKE L,X. TO POKE A TWO-BYT
NUMBER (NECESSARY IF X>255), POKE L,X-INT(X/256)*256, AND POKE L+1,INT(X/256).
CALL: TO EXECUTE A MACHINE LANGUAGE SUB ROUTINE AT LOCATION L, CALL L.
JUST FOR FUN TRY THIS: POKE 33,90. THEN TRY LISTING YOUR PROGRAM. OR TRY:
0,99 OR POKE 50,250 OR POKE 50,127. USE RESET TO RETURN TO NORMAL.
FOR TRUE RANDOM NUMBER GENERATION TRY THIS:X= RND(PEEK(78)+PEEK(79)*256)
TO LOCATE THE STARTING ADDRESS OF THE LAST BLOADED FILE USE: PEEK(-21902)+PEEK
(-21901)*256 (RESULT IS IN HEX)
TO DETERMINE THE LENGTH OF THE LAST BLOADED FILE USE: PEEK(-21920)+PEEK(-21919
*256 (RESULT IS IN HEX)
TO DETERMINE THE LINE NUMBER THAT CAUSED AN ERROR TO OCCUR, SET X TO: PEEK(218
+PEEK(219)*256
------------------------------------------------------------------------------
E-Mail Fredric L. Rice / The Skeptic Tank
Call -151 enters the monitor, 3D0G brings you back to BASIC, and typing a slot # in the monitor followed by Ctrl-P will boot that device. Amazing what one remembers after 20 years!
May I also add that -151 is apple ]['s way of expressing hex number which should mean $FF69 (hex syntax used in Apple II i.e. 0xFF68).
The CALL is an Apple Basic command that invokes an assembly subroutine given by the argument (-151 here). IIRC, this command can accept an address as negative decimal value for addresses between $8000-$FFFF using 2's complement interpretation.
For those who are interested in history, here is the Apple ]['s monitor rom listing (in 6502 assembly) and address $FF69 is having the label MONZ which is the start of the command prompt that process machine code processing commands from user. One that uses a '*' as the prompt. A very primitive command prompt.
Apple II System Monitor
Crikey, that's a blast from the past. I think it entered the monitor ROM (I was torn between this and Integer BASIC but I'm pretty certain it was the monitor).
You could download an Apple II emulator and find out.
As a side note, the reason why this is a negative number and not the proper CALL 65385 is because the very first form of BASIC for the Apple II was known as Integer BASIC. It only understood signed 16-bit Integer values from -32768 to 32767, and so it is impossible to directly address memory beyond 32767 in the normal positive value manner.
If you tried actually typing POKE 49200,0 or CALL 65385 in Integer BASIC you will get a message like ">32767 ERR"
When the replacement Microsoft Applesoft BASIC (yes, from them) with floating point numbers was introduced, they included support for the negative POKE values for some degree of backwards compatibility for the older Integer BASIC programs. Though this compatibility is limited, as Applesoft lacks other programming features of Integer like the MOD division remainder.
Due to the strong influence of early Integer BASIC programming methods, there are many PEEK POKE and CALL commands that are generally only known by their hexadecimal and negative decimal values, but not by their positive decimal values.
Related
How to change reaction time and typing speed on holding a key in suckless dwm?
In source code must be some function or variable for that, but I can't find it and I don't know how to even google it
Changing the speed of a keypress is handled at the level of the Xorg server. The xset command is what you are looking for. The r option controls the autorepeat. Invoking with -r, or r off, will disable autorepeat, whereas r, or r on will enable autorepeat. If the server supports the XFree86-Misc extension, or the XKB extension (which it does), then a parameter of rate is accepted and should be followed by zero, one or two numeric values. The first specifies the delay before autorepeat starts and the second specifies the repeat rate. For example, I have this command run every time I login (in .xinitrc): xset r rate 300 50 This increases the autorepeat on holding all keys.
What steps are taken at the operating system/hardware level during interrupt (e.g. keyboard shortcut)?
I'm currently learning the workings of an operating system and would like to verify if my knowledge is correct on the steps taken during an interrupt. Trying to relate to something very familiar, here's what I think would happen when I press Alt+Tab to switch programs: An interrupt is generated by the hardware (keyboard): intr flag of the CPU is set via system bus from keyboard controller CPU saves the current process state to the PCB to pass control to the interrupt (is kernel mode entered here?) CPU reads interrupt to index the interrupt service routine via the interrupt vector stored in memory The interrupt service routine (along with the interrupt details such as which keys got pressed) is processed (at which point I assume user sees the program being switched) The interrupt is complete (mode bit set back to 1 indicating user mode now?), PCB of the interrupted process gets restored and resumes running. Are there steps that I'm missing or did not describe correctly?
There are many many factors here that you need to take in to consideration. For example: - Is the keyboard on the ISA bus and is of an PC/AT style keyboard? - If so, is the PIC (programmable Interrupt Controller) involved? - Is the keyboard a USB keyboard device? - Is the interrupt an older style PIC, newer style APIC, or a latest style MSI interrupt? There are many things to consider. However, to try to explain what probably happens, I will assume you have an AT style keyboard attached to the keyboard controller port (PS2 style maybe), you have an older style PIC, and a simplified single- or multi-tasking system. What could happen when the user presses the Alt key and then the Tab key: - The CPU is interrupted (hence the name) by the PIC - The CPU "jumps" to the interrupt request routine (IVT, exception, whatever) - The routine reads from the keyboard. A single byte is read which happens to be (part of) the make code for the alt key. - the routine then places this make code in some sort of input buffer the operating system has set up for it, whether it be part of the OS or part of the keyboard driver. - the interrupt is acknowledged via the PIC (this step can and usually is before the previous step) - the routine gives up the CPU (iret instruction) The process is repeated three more times (assuming a make code and a break code are single byte codes. They can be multiple-byte codes). An interrupt is created on a make and a break key. A make key is when a key is pressed. A break key is when a key is released. i.e: - make (Alt Down) - make (Tab Down) - break (Tab Up) - break (Alt Up) You see, there are four interrupts that take place (again assuming single-byte codes), four times the interrupt routine is called, and four times the CPU is interrupted to handle the key press(es) and release(es). As for the task switching, via an ALT-TAB key combination, this is usually not done within the interrupt handler. The OS will see the Make (or Break) key of the Tab, it will check the status of the shift state (which should include the Alt key) and go from there. It the keyboard is a USB style keyboard, then you have a totally different process of events. The USB keyboard does not interrupt the CPU as shown above. The keyboard has an Interrupt Pipe that periodically checks to see if there is a key make or break sequence. The OS will give up a time slice to the USB driver, just enough time to check this Interrupt Pipe. However, please note that an Interrupt (PIC, MSI, or other) is not triggered for USB keyboards, unless the USB driver specifies an interrupt should happen at end of frame. Note though that this interrupt is not fired because of the key press (or release), it is triggered because of the end of frame of the USB has taken place. There is a lot that takes place because of a simple key press and release. I would study on what style of keyboard you wish to program for, what style of interrupt controller, CPU, etc., and go from there. If you wish, I wrote a series of books on this subject where I explain what happens for both an ISA style keyboard and a USB style keyboard. It has been a very enjoyable hobby and I hope you find the same joy in yours.
Can I watch what accesses a particular address?
With Cheat Engine it is possible to watch a particular address and keep track of what has accessed a particular memory address. I was wondering if this can be done too with OllyDbg or IDA. I could not find anything that would do that.
You can use hardware log breakpoint for that purpose. Go to the address you want to monitor in the dump window (e.g here, I want to monitor 0xCB7008): Press CTRL+F5 on the chosen address in the dump window (or right click and `breakpoint > hardware log): Set Break on to Access R/W In Expressions enter once again the address in square brackets Set Pause Program to never if you don't want to stop on each access. Set Log values of expressions to Always Note that the data size if not really important (1 byte will break for 2 or 4 bytes access). Go to the log window (ALT+L), press CTRL+X to clear it, and run your program (F9). In the log window: you should see all accesses to the memory (the leftmost column indicates the code address where the read/write happens):
programmatically press an enter key after starting .exe file in Matlab
In Matlab I can start external .exe files that sometime have a pop up that requires an enter key pressed. For example:
system('C:\Program Files (x86)\WinZip\WINZIP32.EXE')
will start Winzip, and then in order to use it you need to pass the "buy now" pop up window by pressing enter.
Now my problem is not with winzip, I only gave it as an example (i use winrar anyway :).
How can I programmatically press an enter key in Matlab in such cases ? (I use win 7)
Can an event listener be used to solve that?
EDIT: The java.awt.Robot class indeed works on explorer, but not on any software that has a pop up window with an OK button that needs to be pressed. I don't know why it doesn't work for that. I gave the winzip example because I assume everybody has winzip/winrar installed in their machine. The actual software I have is different and irrelevant for the question.
There is a way using Java from Matlab, specifically the java.awt.Robot class. See here.
Apparently there are two types of programs, regarding the way they work when called from Matlab with system('...'):
For some programs, Matlab waits until the program has finished before running the next statement. This happens for example with WinRAR (at least in my Windows 7 machine).
For other programs this doesn't happen, and Matlab proceeds with the next statement right after the external program has been started. An example of this type is explorer (the standard Windows file explorer).
Now, it is possible to return execution to Matlab immediately even for type 1 programs: just add & at the end of the string passed to system. This is standard in Linux Bash shell, and it also works in Windows, as discussed here.
So, you would proceed as follows:
robot = java.awt.Robot;
command = '"C:\Program Files (x86)\WinRAR\WinRAR"'; %// external program; full path
system([command ' &']); %// note: ' &' at the end
pause(5) %// allow some time for the external program to start
robot.keyPress (java.awt.event.KeyEvent.VK_ENTER); %// press "enter" key
robot.keyRelease (java.awt.event.KeyEvent.VK_ENTER); %// release "enter" key
If your applications are only on Windows platform, you can try using .net objects.
The SendWait method of the SendKeys objects allows to send virtually any key, or key combination, to the application which has the focus, including the "modifier" keys like Alt, Shift, Ctrl etc ...
The first thing to do is to import the .net library, then the full syntax to send the ENTER key would be:
NET.addAssembly('System.Windows.Forms');
System.Windows.Forms.SendKeys.SendWait('{ENTER}'); %// send the key "ENTER"
If you only do it once the full syntax is OK. If you plan to make extensive use of the command, you can help yourself with an anonymous helper function.
A little example with notepad
%% // import the .NET assembly and define helper function
NET.addAssembly('System.Windows.Forms');
sendkey = #(strkey) System.Windows.Forms.SendKeys.SendWait(strkey) ;
%% // prepare a few things to send to the notepad
str1 = 'Hello World' ;
str2 = 'OMG ... my notepad is alive' ;
file2save = [pwd '\SelfSaveTest.txt'] ;
if exist(file2save,'file')==2 ; delete(file2save) ; end %// this is just in case you run the test multiple times.
%% // go for it
%// write a few things, save the file then close it.
system('notepad &') ; %// Start notepad, without matlab waiting for the return value
sendkey(str1) %// send a full string to the notepad
sendkey('{ENTER}'); %// send the {ENTER} key
sendkey(str2) %// send another full string to the notepad
sendkey('{! 3}'); %// note how you can REPEAT a key send instruction
sendkey('%(FA)'); %// Send key combination to open the "save as..." dialog
pause(1) %// little pause to make sure your hard drive is ready before continuing
sendkey(file2save); %// Send the name (full path) of the file to save to the dialog
sendkey('{ENTER}'); %// validate
pause(3) %// just wait a bit so you can see you file is now saved (check the titlebar of the notepad)
sendkey('%(FX)'); %// Bye bye ... close the Notepad
As explained in the Microsoft documentation the SendKeys class may have some timing issues sometimes so if you want to do complex manipulations (like Tab multiple times to change the button you actually want to press), you may have to introduce a pause in your Matlab calls to SendKeys.
Try without first, but don't forget you are managing a process from another without any synchronization between them, so timing all that can require a bit of trial and error before you get it right, at least for complex sequences (simple one should be straightforward).
In my case above for example I am running all my data from an external hard drive with an ECO function which puts it into standby, so when I called the "save as..." dialog, it takes time for it to display because the HDD has to wake up. If I didn't introduce the pause(1), sometimes the file path would be imcomplete (the first part of the path was send before the dialog had the focus).
Also, do not forget the & character when you execute the external program. All credit to Luis Mendo for highlighting it. (I tend to forget how important it is because I use it by default. I only omit it if I have to specifically wait for a return value from the program, otherwise I let it run on its own)
The special characters have a special code. Here are a few:
Shift +
Control (Ctrl) ^
Alt %
Tab {TAB}
Backspace {BACKSPACE}, {BS}, or {BKSP}
Validation {ENTER} or ~ (a tilde)
Ins Or Insert {INSERT} or {INS}
Delete {DELETE} or {DEL}
Text Navigation {HOME} {END} {PGDN} {PGUP}
Arrow Keys {UP} {RIGHT} {DOWN} {LEFT}
Escape {ESC}
Function Keys {F1} ... {F16}
Print Screen {PRTSC}
Break {BREAK}
The full list from Microsoft can be found here
There is a small javascript utility that simulates keystrokes like this on the Windows javascript interpreter.
Just create a js file with following code:
var WshShell = WScript.CreateObject("WScript.Shell");
WshShell.SendKeys(WScript.Arguments(0));
then call it from Matlab after the necessary timeout like this:
system('c:\my\js\file\script.js {Enter}');
Can't test here now, but I think this should work...
If you need to run a console-only program in a context that permits full DOS redirection, you can create a file called, say, CR.txt containing a carriage return and use the '<' notation to pipe the value into the program. This only works if you can provide all the keyboard input can be recorded in the file. It fails dismally if the input has to vary based on responses. An alternative is to duplicate the input (and possibly output) stream(s) for the program and then pipe data into and out of the program. This is more robust and can permit dynamic responses to the data, but will also likely require substantial effort to implement a robot user to the application. Rog-O-Matic is an example of a large application completely controlled by a program that monitors screen output and simulates keyboard input to play an early (1980s) ASCII graphic adventure game. The other responses will be required for GUI-based applications.
Python package pywinauto can wait any dialog and click buttons automatically. But it's capable for native and some .NET applications only. You may have problems with pressing WPF button (maybe QT button is clickable - not checked), but in such case code like app.DialogTitle.wait('ready').set_focus(); app.DialogTitle.type_keys('{ENTER}') may help. Your case is quite simple and probably some tricks with pywinauto are enough. Is your "app with popup" 64-bit or 32-bit?
wait and wait_not functions have timeout parameter. But if you need precisely listener with potentially infinite loop awaiting popups, good direction is global Windows hooks (pyHook can listen mouse and keybd events, but cannot listen dialog opening). I'll try to find my prototype that can detect new windows. It uses UI Automation API event handlers... and... ops... it requires IronPython. I still don't know how to set UI Automation handler with COM interface from standard CPython.
EDIT (2019, January): new module win32hooks was implemented in pywinauto a while ago. Example of usage is here: examples/hook_and_listen.py.
When using two frames in emacs, how do I prevent the compilation buffer from showing up in both?
I work with two monitors, and often use emacs with two frames open; one for each monitor. each frame is split into two side-by-side windows, like so: a | b <-- frame 1 in monitor 1 ------- c | d <-- frame 2 in monitor 2 When I hit my 'compile' button while in window a, the compilation buffer opens in the buffer next to it. So far so good: a | compilation ----------------- c | d However, if I then move to window c to edit some stuff, then hit compile again, window d visits the compilation buffer as well: a | compilation ------------------ c | compilation So now I have half of my screen real-estate taken up by two copies of the same compilation buffer, wondering why I have two monitors :) I can prevent this by conscientiously only hitting the compile key when my cursor is in the buffer next to the currently open compile buffer, but I hit 'compile' so early and often that I usually don't have the presence of mind to do so. I feel like there must be something I can tweak in .emacs so I shouldn't have to. Any suggestions? Ideally, when I hit 'compile', the currently open compilation buffer should move from its previous window to the one next to the currently used window. If that's too complicated, I'd easily settle for having emacs not visit the compilation buffer in the neighboring window, if it's already open in another window.
(setq-default display-buffer-reuse-frames t) From the documentation: Non-nil means `display-buffer' should reuse frames. If the buffer in question is already displayed in a frame, raise that frame.