Cortex is a program for running neurophysiological and behavioral experiments on a PC. Although it is still undergoing revisions, it is a working program that we have been using to collect data for more than eight years. The integrity of the data, timing accuracy, etc. has all been validated. Cortex runs behavioral paradigms designed -+by the user, displays visual stimuli to the subject, collects neurophysiological and behavioral data, monitors and stores eye position data, and shows the results to the user during the experiment. Because Cortex has the capability to display and manipulate any image that has been previously created and saved on disk by the user, the variety of visual stimuli it can present is practically unlimited. The program is oriented toward experiments in vision, but it can be used in a variety of other contexts.

Data acquisition capabilities include (dependent on the available I/O hardware) up to 40 spike inputs (TTL +5v digital inputs), specialized functions for monitoring hand-bar and lever movements (TTL +5v digital inputs), eye-movement monitoring functions (A/D inputs), keyboard, mouse, and touchscreen inputs. Reward triggering for alert-subject experiments is accomplished through TTL +5v digital output. The user retains access to the full-array of possible uses for the I/O equipment on-board (such as D/A output, or specialized digital I/O) with easy-to-use C functions. Up to five data acquisition boards, one of each type, may be accessed by CORTEX.

Graphical capabilities include a device-generalized graphics kernel that allows the user to run the same experiments on any of the supported configurations. To run in the single-computer configuration, either a Number Nine Co. Sgt. Pepper board, or a #9GXi-TC graphics board is required. Since these two graphics boards are no longer manufactured, a two-computer version of Cortex was developed. With the two-computer version, any VESA compliant graphics card/monitor, which is supported by Scitech Display Doctor or Microsoft DirectX, may be used. Many of the low-level technical aspects of graphical programming are handled directly by CORTEX; thus the graphical programming environment is relatively simple to use.

CORTEX is designed to simplify combined behavioral and neurophysiological experimentation by directly handling trial randomization and simple staircasing. The user retains complete control of the trial staircasing, if desired, and can generate any staircasing paradigm needed. The user can even change the staircasing design on-line, in any way, based on behavioral responses.

Associated with Cortex are a number of utility programs. Shipped with Cortex, in the \REMOTE32 and \UTIL_BIN directories, is the DOS program, CORTVIEW.EXE. This program can be used to view the contents of the Cortex output data file. Rather than viewing the results, this program also can be used to pipe the output to a text file. From the Cortex web site, there are links to other Cortex data analysis programs. One program that was written at the Laboratory of Neuropsychology (NIMH) is the Cortex Windows Workbench. This program provides an interactive and graphical look at Cortex data files. Cortex files can also be analyzed using PCOFF, which was developed in the Laboratory of Neurophysiology (NIMH). PCOFF is a comprehensive event code sequence search program that supports graphical display of rasters, histograms, reciprocal interval plots, using a number of different schemes to align data on specific events. The program also does analog signal processing (e.g. integration, averaging, etc.) as well as non-parametric and descriptive statistics. The Laboratory of Neurophysiology recently contributed a program called MatOFF. It is a powerful event search and data plotting program based on their earlier PCOFF program. Matoff runs under Microsoft Windows using MATLAB. Other laboratories at NIH, the University of Verona, MIT, and the Salk Institute have also contributed Matlab routines to help with the analysis and use of Cortex. These Matlab routines can be accessed from links on the Cortex web page.

1.2 Getting the latest version of Cortex

The latest code, executables, and documentation can be downloaded from the Cortex web site:

www.cortex.salk.edu

1.3 Technical Support

If you are experiencing problems with Cortex which are not covered in the Cortex documentation, please post a message to the Cortex web site's discussion group. The discussion group can be accessed from the "Discussion" page of the Cortex home page (http://www.cortex.salk.edu/phpBB2).

1.4 History (you may skip this part)

CORTEX has been gone through so many transitions over the decades that it is daunting to list everyone who has contributed to its development. Dr. Robert Desimone, who has overseen and guided the development of CORTEX since he initially ported it from the PDP-11 platform over a decade ago, made a valiant effort to do so several years ago. This is quoted below.

· Thomas M. White - the lead programmer for CORTEX from 1989-1997. Re-wrote CORTEX from scratch, implemented the in-line compiler (the CORTEX state system - CSS), real-time multi-threaded data collection system, and support for multiple touch screens, graphics boards, and data acquisition systems. He also wrote the initial procortex, Stats100, and Grast utility programs. Upon leaving his work on CORTEX he went on to earn his MD degree from Cornell University.

· Trina M. Norden-Krichmar - took over the role of lead programmer from Tom White in the fall of 1997. She added a Windows DirectX receive program, support for DirectX sound and movies, and support for PCI data acquisition boards. She is currently working on the implementation of a Windows version of the send program, supporting the DOS version, and updating the documentation.

· Jessica Benson – rejoined the Cortex Team in the summer of 2004 after a year absence and is back working on device drivers, Install Shield, updating the website and documentation, fixing bugs and testing. She worked on the Cortex Team from the summer of 2001 to the summer of 2003 writing the Visual C++ and MFC code to transform Cortex into the wonderful dialog boxes and menus that you see today the windows version.

· Eric Boulden – worked on the Cortex Team from the summer of 2003 to the summer of 2004. He converted the old-fashioned Cortex web site into a slick PHP/MySQL database driven web site. He also added an InstallShield-based installation to VCortex, converted the drivers for the Random Spike Device and PCI-DIO24 board for Windows 2000 and XP version, and was involved in bug fixes, testing, and documentation.

Others who have contributed substantially to CORTEX include:

· Dr. Steve Macknik - wrote the TIGA and MGL graphics modules, as well as the User's manual.

· Dr. Andrew Mitz - helped write the technical manual, contributed several user-accessible functions to CSS, and contributed the PCOFF and MatOFF data analysis programs.

· Dr. Jamie Mazer - contributed the Set module and several user-accessible functions to CSS.

· Dr. Earl Miller - overhauled the Grast program for graphical analysis of CORTEX data files, but now has contributed Matlab versions of these analysis tools.

· Robert Baumann - developed the CORTEX Windows Suite - a set of tools to facilitate the analysis of CORTEX data files.

· Dr. Giuseppe Bertini - helped design the Cortex web pages, especially the framed function reference, and contributed Matlab data analysis routines.

· David Mechner – wrote the code to support sound in the DOS version of Cortex.

Dr. Robert Desimone wrote the following for the 1997 version of the Cortex User's Manual:

It is currently impossible to list all of the people who have helped in the development of CORTEX, through their suggestions, testing, and bug-reports. The section below acknowledges those who were most helpful in CORTEX's early years.

The remote ancestor of Cortex can be traced to an assembly language program for collecting spike data and controlling an optical bench, written for the PDP-12 by David Bender in Charlie Gross' lab at Princeton during the early 1970's. The PDP-12 was a state-of-the art laboratory computer with 8K of core memory (and a 12-bit word), a bit-mapped graphics display, a real-time programmable clock, and analog and digital interfaces built in. After Dave left Princeton for Buffalo, I assembled the necessary components for a PDP-11 system (which, shockingly!, had no lab interfaces built in) and sketched the requirements for a new spike collection program that could make use of the luxurious 64K of memory (and 2.5 MB hard disk!) that was then available. The core of this program was written in 1980 in Whitesmith's C by a moonlighting mathematician, Phil Thrift, and a high school student who had been programming in C since age 12. When I left Princeton for NIMH, the program branched in its development. One branch continued to be developed at Princeton by Tom Albright, and the other branch developed at NIMH. Jeff Moran at NIMH significantly rewrote the program, then called "Behave", and added modules for controlling the subject's behavior and controlling an external Jupiter Graphics system for presenting stimuli.

As to be expected, a memory size that once seemed luxurious eventually became ridiculously too small. After the introduction of the IBM-AT, Stan Schein and I decided to switch from the PDP-11, in part because of the great difference in price and in part because the C compilers for the AT allowed transparent access to 640K of memory, whereas it was difficult to use more than 64K on the PDP-11. A Pepper SGT graphics card from Number Nine Computer was eventually chosen to replace the Jupiter graphics system. Stan, who moved from NIH to Harvard Medical School, hired Thuan Tran, then a computer science student at MIT to port the program after I had naively (and innocently!) assured Stan that the porting would take at most six weeks, once we understood all of the new hardware. Because the old program was inflexible and filled with kludges to get around memory limitations, Thuan did not actually port it. Although he retained a few design aspects of the original PDP-11 program, he completely rewrote and greatly expanded the program over the course of the next couple of years after graduating from MIT, with direction on the design by Stan and myself and support from Stan's grant (R01-EYO6096).

In 1989, Thuan took a full time job with a computer company but continued to work part-time on the state-system interface to Cortex, on contract to NIMH. At about the same time, I hired Tom White at NIMH, and he significantly rewrote most of Cortex again, in order to make it more user friendly, to greatly upgrade its stimulus display capabilities, and to improve the maintainability of its source code. He also took over the development of GRAST, a histogram display program, and Procortex and STATS100, numerical analysis programs, greatly expanding and rewriting them over the course of the past year. Tom integrated STATS100 with SYSTAT, a commercial statistical program, and wrote a data analysis compiler that users can use to write their own analysis routines, without doing any actual programming. Tom is now at Cornell Medical School in a MD/Ph.D. program, but continues to work on Cortex occasionally, out of the goodness (truly) of his heart. I myself work on Cortex code, in my spare milliseconds, and am reasonably familiar with the workings of most of the modules. Rosalyn Merrill (NIMH), Amir Geva, and Jeff Moran also worked on small pieces of code for either Cortex or GRAST at one time during their development. Most recently, Marcello Gattass, the brother of Ricardo Gattass, has taken over the development of GRAST for the time being. Marcello promises a MS Windows version of GRAST sometime in the future. Steve Wise at NIMH has contributed towards some of the considerable development expense of Cortex. Finally, Cortex has benefited from the suggestions (and, unfortunately, bug-finding) of many of its users, particularly Mark Wessinger, Lin Li, Sidney Lehky, John Duncan, Earl Miller, Jennifer Hart, Driss Boussaoud, Josef Rauschecker, Ricardo Gattass, Leonardo Chelazzi, Andy Mitz, Richard Jeo, Carl Olson, Rebecca Hoag, and Peter DeWeerd.

2. Hardware and Software Requirements

2.1 Two-computer Cortex (REMOTE32)

2.1.1 Basic "Send" computer

The Cortex "send" computer controls experimental timing, data collection, and sending commands to the graphics ("receive") computer. The "send" computer contains the data acquisition card.

2.1.2 Basic "Receive" computer

The Cortex "receive" computer displays the graphics to the subject. There are two versions of the "receive" program: a DOS Scitech Display Doctor (SDD) based version and a Windows DirectX based version.

For the SDD DOS receive program, the computer must contain a Scitech Display Doctor supported graphics card.

For the DirectX receive program, the computer must contain a DirectX supported graphics card.

Like the send computer, the receive computer should also be a Pentium computer with at least 32 MB RAM. Since graphics are more CPU intensive, if you have two unequal computers, the faster computer with more memory should be the receive computer.

2.1.3 Operating Systems

The send computer and DOS Scitech Display Doctor receive computer must be booted up in true DOS to run with accurate timing. A computer that has Win95 or Win98 can be booted up into DOS easily. WinNT and Win2000 can not be easily booted up into DOS, so I do not recommend it for the DOS based Cortex program.

The Windows DirectX receive program must be run from Windows. It can run with Win95, Win98, Win2000 or XP. WinNT definitely can not be used for the DirectX receive program, since it does not support DirectX 5.0 or higher.

2.1.4 Graphics cards

A good graphics card is only required in the receive computer. It must be supported by the Scitech Display Doctor for the DOS SDD receive program, or it must be supported by DirectX for the Windows DirectX version (see section 2.2.10 below)

A graphics card with at least 4 MB of onboard video memory is recommended.

2.1.5 Data acquisition cards

All of the data acquisition boards originally specified for the single computer version of Cortex should also work with the dual version of Cortex. From Keithley/Metrabyte, there are: DASH-16 (for analog and digital I/O), and the PIO24 or PIO96 (for digital I/O only). From ComputerBoards, there are the clones: CIO-DAS16, CIO-AD16, CIO-DAS1602/12, CIO-DIO24 and CIO-DIO96.

The ComputerBoards PCI-DAS1602/12 and PCI-DIO24 boards are also supported, in case your computer does not have ISA slots.

When you are buying your data acquisition board, you may also want to order a screw terminal interface. The Metrabyte "Universal Screw Terminal Accessory Board STA-U" works well with the CIO products.

The PCI-DAS1602/12 requires a 100-pin connector and interface. From the ComputerBoards, Inc. catalog, the parts are listed as a C100FF cable and a CIO-TERM100 screw terminal board. The CIO-DIO24 and PCI-DIO24 require a 37-pin cable and MINI-37 screw terminal board.

For use with all data acquisition boards, the screw terminal interfaces must be altered (flip-flops must be added) or have another device that performs the latching, in order to collect spike data. The Cortex web page contains the necessary diagrams under the heading "Spike Flip-Flop Circuitry and Thalamus".

2.1.6 Sound cards

2.1.6.1 DOS (rvesactx.exe) version

A SoundBlaster card must be installed in the receive computer. Any modern SoundBlaster card should work (e.g., SB16, AWE32, or AWE64). Problems have been reported on SB16 compatible cards.

2.1.6.2 DirectX (dxrecv.exe) version

Any sound card which is supported by DirectX can be installed in the receive computer.

2.1.7 Touch screens

The code was written for and tested on a Microtouch touchscreen. The latest Microtouch Touchware driver software is available from the 3M web site (http://www.3m.com/3MtouchSystems/downloads/legacy.jhtml). You must install the DOS version of the Touchware driver on the send computer.

2.1.8 Serial connection

The two computers are connected via a serial cable between COM ports. The serial cable connecting the two computers must be a null modem cable. (Laplink-style cables will work.) Black Box Corporation sells a "Universal Serial cable (DB25F/DB9F to DB25F/DB9F)", and its part number is BC01802, which works well with Cortex.

2.1.9 Monitors

A good monitor is only required on the receive computer. Remember that the highest refresh rate that can be achieved is dependent on the graphics card and the monitor. Therefore, when selecting a monitor, make sure that the monitor can handle the refresh rate at the desired resolution and color depth. You will also want to buy a video-splitter (such as a VOPEX splitter from NTI) so that the graphical output can be displayed on a monitor for the subject and a monitor in your setup.

2.1.10 Software

SciTech Display Doctor must be installed on the receive computer only if you are going to use the DOS Scitech Display Doctor receive program. A free copy, can be downloaded from the SciTech web page http://www.scitechsoft.com/products/ent/free_titles.html. Please note that the Scitech Display Doctor is no longer supported by Scitech. Refer to the Scitech web site to find out which graphics cards are supported.

In order to use the DirectX receive program, the DirectX 6.0 (or higher) driver must be loaded. The DirectX driver is freely available from the Microsoft web site. If you are interesting in running AVI, MPEG, or QuickTime movies, you must also have Microsoft Internet Explorer version 4.0 or higher, installed on your computer.

2.2 Single-computer Cortex without graphics (\REMOTE32\SGL32.EXE)

The SGL32.EXE version is a 32-bit DOS program, which does not display graphics. The serial communications functions and the analog/digital capabilites are supported. Therefore, this version can be used when graphics are not necessary, or when the graphics are displayed by some other means. The advantage of this version is that it is built with 32-bit DOS, so the amount of memory that can be used is not limited to the 640 KB boundary.

2.2.1 Computer

The single-computer Cortex computer controls experimental timing, data collection, and can send serial commands to another computer. The Cortex computer contains the data acquisition card.

A Pentium computer (at least 100 MHz) with 32 MB RAM and at least a 1 GB hard drive for data storage is recommended. These specifications are based on the assumption that the computer will have Win95/Win98 installed on it also. Similar to the other DOS versions of Cortex, the single-computer 32-bit Cortex program must be run from a computer which is booted up in true DOS.

2.2.2 Data acquisition cards

All of the data acquisition boards originally specified for the other versions of Cortex should also work with the single 32-bit version of Cortex. See section 2.1.5 above.

2.3 Single-computer Cortex with graphics (NNIOS and NUM9GXI)

2.3.1 Computer

The basic computer must be at least an AT class machine (80286 or better) with 640K memory, keyboard, and mouse. A VGA video board (or compatible video card, such as a Hercules monochrome board) is needed in addition to a compatible monitor.

2.3.2 Graphics

For visual stimulation studies, a Pepper SGT-plus graphics card with at least 1 MB of memory, or a #9GXi-TC graphics card with 4megs VRAM and at least 1 meg DRAM, is needed for the subject's visual display. The Pepper SGT will work with any VGA or multiscan monitor and the #9GXi-TC can support multiple resolutions and scan rates. Many labs use two subject monitors (one for the subject and one for the user....they may be in separate rooms) and use a video splitter such as the VOPEX-2V-H from NTI). Please note that the Pepper SGT-plus and the #9GXi-TC graphics cards are no longer manufactured. In fact, the CORTEX development team does not have these graphics cards, so this version of CORTEX has not been tested for the NNIOS and NUM9GXI executables.

2.3.3 Data acquisition

All of the data acquisition boards originally specified for the other versions of Cortex should also work with the NNIOS and NUM9GXI versions of Cortex. See section 2.1.5 above.

2.4 Useful Web Sites for Finding the Necessary Hardware and Software

BlackBox Corp. http://www.blackbox.com/

Cortex home page http://www.cortex.salk.edu/

ComputerBoards, Inc. http://www.computerboards.com

Keithley/Metrabyte http://www.keithley.com/

Scitech Software http://www.scitechsoft.com/

Microsoft DirectX http://www.microsoft.com/directx/homeuser/downloads/default.asp

NTI http://www.networktechinc.com/

Microtouch http://www.3m.com/3mtouchsystems/

3. Installation

3.1 Data Acquisition Board Setup

3.1.1 Typical Keithley/Metrabyte DASH-16 settings

· Base Address: 0x300 or 0x310

· DMA Channel: By default, the board requires DMA channel #1. If something else is using that DMA channel, there is an onboard jumper that can be switched to use DMA channel #3. Otherwise, use the Windows Control Panel to move the conflicting device to a different setting.

· should be set for bipolar, 16 analog inputs

· gain = whatever is convenient

· analog eye inputs (EOG): analog input channels 3 High and 4 High

· evoked potentials (EPP): analog input channels 1 High and 2 High

· bar contact input: digital input 2 and 3

· solenoid reward output: digital output 1. Cortex outputs a brief TTL pulse to trigger a solenoid control circuit. By default, the duration of the pulse is 20 ms. It can be configured to different times via the Cortex Run:Parameter:General menu options, or using an external variable (ms_reward_duration) in the timing file.

· spike inputs (2 or more separate spike channels): digital inputs 0 and 1 (for the first two inputs), which are fed by flip-flops (provided by the user’s electronics shop...see Section 3.3 entitled "Data Acquisition Interface Setup"). Typically one uses the "user 1 and 2" lugs on the Metrabyte interface connector board to access the flip-flops.

· output to clear flip-flops: digital output 0

3.1.2 Typical PIO24 or CIO-DIO24 settings

The PIO24 board is shipped with a base address of 0x300. The base address must be changed with onboard jumpers, if this address is already occupied. By default, Cortex uses Port A as 8 lines of input, Port B as 8 lines of output, Port C (0-3) as 4 lines of input, and Port C (4-7) as 4 lines of output. This is configured at startup in Cortex, but you can dynamically change this in your timing file to give a different distribution of inputs and outputs.

3.1.3 Typical Computerboard CIO AD-16, CIO-DAS16/F, and CIO-DAS1602/12 settings

The Computerboard CIO AD-16, CIO-DAS16/F and CIO-DAS1602/12 can be considered to be a combination of a DASH-16 board and a PIO24 digital I/O board, with the address space of the PIO24 following that of the DASH-16. Because of the PIO24 on board, it is usually necessary to use the Computerboard with a base address of 0x300 for the DASH-16 component rather than 0x310. If the DASH-16 component has an address of 0x300, the PIO24 component can be set with an address of 0x310, which is a safe address. Otherwise, if you set the base address for the DASH-16 component at 0x310, the address space of the PIO24 is automatically set at 0x320, which apparently can conflict with other devices on the bus. Note: The CIO-DAS1602/12 board is shipped with the analog inputs set to UNIPOLAR. Therefore, the switch on the board must be changed to the BIPOLAR setting in order for Cortex to collect analog data properly.

3.1.4 PCI-DAS1602/12 settings

The PCI-DAS1602/12 also contains a DASH-16 portion and a PIO24 portion. It is a plug-and-play device, which does not have any onboard jumpers to configure the base addresses. Every time the computer boots up, the BIOS assigns base addresses to the board which will not conflict with the other devices in the computer. It is possible that each time that the computer boots up, the board will have different addresses. Also, instead of having just one base address, the PCI-DAS1602 has five base addresses. Because of this complicated situation, Cortex will just query the BIOS and board internally, to figure out these five addresses. The base address that is supplied on the DEVICE PCIDAS1602 line in the Cortex.cfg file will be ignored, even though it is a required parameter. For other technical notes about the PCI-DAS1602/12, refer to Appendix B.

3.1.5 PCI-DIO24 settings

The PCI-DIO24 is the PCI version of the PIO24 board. It is a plug-and-play device, which does not have any onboard jumpers to configure the base addresses. Every time the computer boots up, the BIOS assigns base addresses to the board which will not conflict with the other devices in the computer. It is possible that each time that the computer boots up, the board will have different addresses. Also, instead of having just one base address, the PCI-DIO24 has two base addresses. Cortex will query the BIOS and board internally, to figure out these two addresses. The base address that is supplied on the DEVICE PCIDIO24 line in the Cortex.cfg file will be ignored, even though it is a required parameter.

3.2 Graphics Board Setup

3.2.1 Pepper SGT settings

· 640x480 resolution (default)

· Should be set for no emulation

· Put the following line in your config.sys file

· device=nnios.sys /m=A000:64;

· (Note: If the /m=A000:64 option generates a "memory windows" error, do not put it into the device line.)

· Copy the nnios.sys file into the root directory of your computer.

· Shut down the computer and install the Sgt. Pepper card into the computer.

· Restart the computer. When your computer boots up, it should tell you that it has loaded the Pepper SGT device driver successfully.

3.2.2 #9GXi-TC settings

Set the DIP switches for the board as listed below.

DIP Switch Settings:

Sw1 Sw2 Sw3 I/O Address

On on on 280-28F

On on off 290-29F

On off on 2A0-2AF

On off off 2B0-2BF

Off on on 2C0-2CF

Off on off 2D0-2Df

Off off on 2E0-2EF

Off off off Reserved

Sw4 Reserved

Sw5 Enable VGA

On On-board VGA enabled

Off On-board VGA disabled

Sw6 VGA BIOS Transfer mode

On Word (16-bit) mode

Off Byte (8-bit) mode

Sw7 Monochrome emulation

Off Monochrome enabled

On Monochrome disabled

Sw8 Reserved

· Set the first three switches to the desired address, and then set ON, Off, On, Off, On (assuming you don't plan to use the on-board VGA).

· Once the board is physically installed, run the install program from the floppy disk from a DOS prompt.

· Once that is done, replace the TIGA communication driver in the autoexec.bat with one of the drivers in the \util_bin directory of the CORTEX download. That is, replace the line "c:\tiga2\tigacd.exe" in the autoexec.bat file with c:\cortex\util_bin\ticortcd.exe. Upon bootup, if you get an error which says something like "#9GXI Comm buffer failure..", then replace ticortcd.exe in the autoexec.bat file with one of the other executables in the \util_bin directory (i.e., t2cortcd.exe, or tigacd0.exe).

· After that, you can set various aspects of the board (i.e. default resolution, screen offsets, and flicker rates) for each resolution in the gxi.bat utility in the c:\tiga2 directory.

3.2.3 Graphics card setup for Scitech Display Doctor and DirectX Receive Programs

Install the graphics card according to the graphics card manufacturer's instructions. Install the SDD or DirectX driver. These drivers should recognize the graphics card, if the driver supports it.

3.3 Data Acquisition Interface Setup

3.3.1 Spike Flip Flop Circuitry

The Dash-16 does not latch digital inputs (for purposes of spike acquisition, neither does the PIO24). This seems to be typical for digital inputs boards for the PC, except possibly for a handshaking line. So if you want to collect neuronal spikes, you must add flip-flops between the TTL pulse of your window discriminator (a +5v digital pulse) and the digital input ports of the board. Otherwise, if your TTL pulse is less than 1 msec long, it may be "gone" by the time the Cortex program gets around to examining the port; if longer than 1 msec, Cortex will read more than one spike for each pulse. A circuit diagram for the flip-flops can be obtained from the Cortex web site. The flip-flops are cleared by digital output #0 (courtesy of the software and the flip-flop circuit). The spike inputs go to user inputs 0 and 1. Behavioral inputs go to digital inputs 2 and 3 (bar up/down = 2, bar left = 2, bar right =3), which naturally are not latched.

3.3.2 Thalamus

Although Cortex does not require any interface beyond the screw-terminal box or panel sold by Metrabyte or Compuboard (plus a couple of flip-flops for the spikes), Andy Mitz developed a fabulous general-purpose interface called Thalamus. Thalamus is an interface and interconnect box that goes between the computer I/O boards and the outside world. It contains BNC connectors for up to 8 A/D channels and up to 8 spike inputs. It has input latches for all 8 spike inputs. Four of the 8 A/D inputs can have built-in anti-aliasing filters. Thalamus also has "D" type connectors for digital input and output. There are 8 "touch pad" circuits in the Thalamus unit to aid with touch switches or to condition other switches. There is also a one-shot and driver for delivering rewards. Thalamus was developed by the Laboratory of Neurophysiology, NIMH. Drawings for the Thalamus are available on the Cortex web site and at the Laboratory for Neurophysiology's web site.

3.3.3 Screw Terminal Interface Diagram for the DASH-16, CIO-DAS16/F, CIO-AD16, and CIO-DAS1602/12

(#) Represents pin number

Resetting of latches is usually implemented in the latch circuitry.

3.3.4 Screw Terminal Interface Diagram for the PCI-DAS1602/12 board

3.3.5 Screw Terminal Interface Diagram for the PCI-DIO24 and CIO-DIO24 boards

· If you are using the PCI-DIO24 or CIO-DIO24 board with the PCI-DAS1602/12 board you will use the Reset line on the PCI-DAS1602/12 board to latch the spikes.

· If you are using the PCI-DIO24 or CIO-DIO24 board alone you will use Pin 25 as the Reset line.

· In order to get the reward and bar to work properly with the PCI-DIO24 or CIO-DIO24 board alone, you must use the DEVinp and DEVoutp functions in your timing file.

· The above diagram shows the default port settings, but the board can be programmed to have different input and output lines using DEVoutp.

3.4 Sound Card Setup

The dual computer Cortex program has the ability to play sounds. Sound can be used not only as stimuli, but also as an auditory feedback mechanism to assist in training. Up to 256 different sound (.wav) files can be played during an experiment. Additionally, the volume and mix of the sound from the speakers can be changed during the experiment through function calls in the Cortex timing file. See the online Function Reference Manual at http://www.cortex.salk.edu/CortexFunctionReference.php.

3.4.1 Sound for DOS Scitech Display Doctor (rvesactx.exe) version

A SoundBlaster card must be installed in the receive computer. Any modern SoundBlaster card should work (e.g., SB16, AWE32, or AWE64). It might also work on SB16 compatible cards, but it has not been tested. If the SoundBlaster card has been installed properly in the computer, there is no additional configuration necessary to use the Cortex sound capabilities. The code reads the DOS “BLASTER” environment variable to get the addresses and IRQs of the card. Certain problems with the sound initialization and execution during the use of Cortex are logged to the file “rvesactx.err” on the receive computer. Please note that the sound (.wav) files must be present on the receive computer.

3.4.2 Sound for DirectX (dxrecv.exe) version

Any sound card which is supported by DirectX can be installed in the receive computer. After the sound card is installed in the computer, the DirectX driver must be installed. Certain problems with the sound initialization and execution during the use of Cortex are logged to the file “dxrecv.err” on the receive computer. Please note that the sound (.wav) files must be present on the receive computer.

3.5 Touchscreen Setup

Prior to Cortex version 5.7 release 10, a touchscreen could only function properly on a single computer Cortex setup. For release 5.7 release 10 (and later), the dual computer version of Cortex also works properly with a touchscreen. The code was written for and tested on a Microtouch touchscreen. Please refer to Section 3.6.4 of this document for the basic dual computer installation instructions. If you have never set up a dual computer version of Cortex before, you may want to set up a basic system first before attempting to use the touchscreen.

3.5.1 Hardware Setup

On the receive computer:

· Connect the Microtouch touchscreen graphics cable to the video card in the receive computer.

· Connect COM1 on the receive computer to COM1 on the send computer via serial cable (for Cortex communication).

On the send computer.

· Connect the Microtouch touchscreen controller serial cable to COM2 on the send computer.

· Connect COM1 on the send computer to COM1 on the receive computer via serial cable (for Cortex communication).

· Install Microtouch Touchware DOS driver software (see section 3.5.2 below).

(Note: The above instructions were simplified by assuming that COM1 is used for the Cortex communications port.)

3.5.2 Microtouch Touchware Setup

The latest Microtouch Touchware driver software is available from the Microtouch web site (http://www.3m.com/3MtouchSystems/downloads/legacy.jhtml). You must install the DOS version of the Touchware driver.

1. Reboot the send computer into DOS, since Touchware must install and run from DOS. During Touchware installation, the driver tries to find the touchscreen controller. If it does not find the controller, run microcal.exe. If microcal.exe finds the controller, write down the settings for the communications port number, the IRQ number, and the baud rate. Edit the file DOSTOUCH.INI, and replace the current values with the ones reported by microcal. You should now be able to run the Touchware driver (DOSTOUCH.EXE), and it should report that the driver was installed.

2. Calibrate the monitor using microcal.exe on the send computer. Be aware that the calibration screen will appear on the send computer's display...not the touchscreen! However, if you touch the corners of the touchscreen, it should be detected properly. For a more accurate calibration, you can temporarily attach the touchscreen video cable to the video card of your send computer (instead of your normal send computer monitor). This will allow you to see the calibration markers on the touchscreen itself while running microcal.exe.

3. To work properly with Cortex, it is suggested that you edit the DOSTOUCH.INI to contain the following values:

· DefaultVirtualSize=640 480 (This allows the touchscreen to map the touch from (0,0)(999,999) to the required (0,0) (640, 480).)

· CursorOffset=0 (so that when the screen is touched, no value is added to the location)

4. You may also want to experiment with the TouchMode value in the DOSTOUCH.INI file. These values can be changed by running the DOSPANEL.EXE program.

5. Before running Cortex, you must always boot up your computer into DOS and run the DOSTOUCH.EXE driver on the send computer.

3.5.3 Cortex Configuration File Setup for Touchscreen Operation

In order to specify to Cortex that the touchscreen will be used, the following line must be included in the CORTEX.CFG file. (Refer to Section 4.6 for general information about the Cortex.cfg file.)

TOUCH_SCREEN <int ms_per_tik > [<store_touch_data]

· For example, the line could be:

TOUCH_SCREEN 50

· where 50 is the number of milliseconds between queries of the touchscreen

· (To emulate the touch screen using the mouse, use a negative number for the ms_per_tik value.)

Since the calculation of the location of the touch is based upon the "pixels-per-dva" setting in the CORTEX.CFG file, it is imperative that the values are set correctly in the GRAPHICS_SPECS line.

In Cortex version 5.9.3 and higher, the optional parameter, <store_touch_data, was added to the TOUCH_SCREEN parameter of CORTEX.CFG. This parameter allows the user to specify whether or not the touch values should be stored to the EPPbuf, the CODE/ISI buf, both places, or neither place.

·         Valid values are:
      EPPBUF
      CODEBUF
      NEITHER
      BOTH (default)

· If no value is provided, the touch data will be stored to both the EPPbuf and CODE/ISI buf.

3.6 Cortex Software Setup and Program Execution

In all configurations, the first step is to download the latest Cortex distribution file from the Cortex web site. Using WinZip or PKUNZIP.EXE, unzip the distribution file.

3.6.1 SGT Pepper version

The SGT Pepper version of Cortex will automatically be installed into the \SGTPEPPR directory on your computer.

You will need to edit the cortex.cfg file in that directory to reflect the settings for your system.

You run the SGT Pepper version of Cortex by entering nncortex -n, where 'n' is the name of the disk drive where you would like temporary files stored. This drive can be a RAM disk, to speed up performance. The temporary files do not contain the experimental data but rather hold information used internally by Cortex, such as binary representations of the items. Another command line argument that can be used is the filename of a "Save" file (created through the Cortex menus with Disk:Save). If a filename is encountered on the command line, Cortex interprets it as the name of a Save file, and automatically loads those settings into Cortex.

3.6.2 TIGA (#9GXi-TC) version

The TIGA version of Cortex will automatically be installed into the \NUM9GXI directory on your computer.

You will need to edit the cortex.cfg file in that directory to reflect the settings for your system.

You run the TIGA version of Cortex by entering ticortex -n, where 'n' is the name of the disk drive where you would like temporary files stored. This drive can be a RAM disk, to speed up performance. The temporary files do not contain the experimental data but rather hold information used internally by Cortex, such as binary representations of the items. Another command line argument that can be used is the filename of a "Save" file (created through the Cortex menus with Disk:Save). If a filename is encountered on the command line, Cortex interprets it as the name of a Save file, and automatically loads those settings into Cortex.

3.6.3 Single-computer with no graphics (SGL32) version

The SGL32 version of Cortex will automatically be installed into the \REMOTE32 directory on your computer.

You will need to edit the cortex.cfg file in that directory to reflect the settings for your system.

You run the SGL32 version of Cortex by entering sgl32 -n, where 'n' is the name of the disk drive where you would like temporary files stored. This drive can be a RAM disk, to speed up performance. The temporary files do not contain the experimental data but rather hold information used internally by Cortex, such as binary representations of the items. Another command line argument that can be used is the filename of a "Save" file (created through the Cortex menus with Disk:Save). If a filename is encountered on the command line, Cortex interprets it as the name of a Save file, and automatically loads those settings into Cortex.

3.6.4 Dual Computer Cortex Software Installation Instructions

The Cortex "send" computer controls experimental timing, data collection, and sending commands to the graphics ("receive") computer. The two computers are connected via a serial cable between COM ports.

By default, Cortex uses COM1 as the communications port and 115200 as the baud rate on each computer. However, COM2 can also be used for Cortex communication. The send side can be changed to use COM2 and a different baud rate in the Cortex.cfg file with the COM_PORT line. The receive program must be changed with command line arguments. That is, if you wanted to use COM2 and baud rate 9600 on the receive computer, you would have to supply COM2 and @9600 as command line arguments.

There are two versions of the "receive" program: a DOS Scitech Display Doctor based version, and a Windows DirectX based version. You only need to set up and use one of these receive programs!

3.6.4.1 Scitech Display Doctor "Receive" (RVESACTX.EXE) software installation

· Install SciTech Display Doctor. A free copy can be downloaded from the SciTech web page ( http://www.scitechsoft.com/products/ent/free_titles.html).

· During the installation of Display Doctor, allow the autoexec.bat to be changed. After installation, the autoexec.bat must contain the line "C:\SDD\UNIVBE32.EXE -w", so that the Display Doctor will automatically be launched upon bootup. Also, make sure that the linear frame buffer capability is enabled in Display Doctor, by double-clicking on the Display Doctor Control Center icon and looking at the "Compatibility Testing" section.

· Download and unzip the latest Cortex distribution code from the Cortex web page. The minimum files that the receive computer must contain are: RVESACTX.EXE, DOS4GW.EXE, and PC8X8.FNT. These three files must all reside in the same directory.

· If you have bitmaps associated with your tests, they must also reside on the receive computer, since the bitmap files do not get transmitted over the serial line. (If they are not there, you will get the error "can't calc image size" on the send computer.)

· Boot up the computer into true DOS (see section 3.6.5).

· To run the Scitech Display Doctor based receive program, change to the Cortex directory containing the executables (usually \REMOTE32). In DOS, type "RVESACTX" to start the receive program running.

3.6.4.2 DirectX Receive Program (DXRECV.EXE) software installation

· Install the DirectX driver. In order to use the DirectX receive program (DXRECV.EXE), the graphics card in your receive computer must be supported by DirectX, and the DirectX 6.0 (or higher) driver must be loaded. If these criteria are not met, the DXRECV.EXE program may hang, and the WCSEND.EXE program (on the send computer) will report the error “Couldn’t initialize graphics board” upon startup. If this happens, you must install the DirectX driver on the receive computer. The DirectX driver is freely available from the Microsoft web site. Go to the web page http://www.microsoft.com/directx/homeuser/downloads/default.asp. Download and install the current version of DirectX 7.0. If you are only interested in running DXRECV.EXE, you only need to download the DirectX driver. (If you are interested in changing and recompiling the DXRECV code, you must download the DirectX SDK. See Section 8.3.)

· If you are interesting in running AVI, MPEG, or QuickTime movies in DXRECV.EXE, you must also have Microsoft Internet Explorer version 4.0 or higher, installed on your computer.

· Download and unzip the latest Cortex distribution code from the Cortex web page. At a minimum, the \Wcortex directory must reside on the receive computer.

· The DirectX receive program (DXRECV.EXE) is a Windows application, which must be run from Windows (not DOS). The easiest way to run it, is to make a shortcut on the desktop of the receive computer to the executable, \WCORTEX\DXRECV.EXE. When you want to run the program, just double-click on the DXRECV.EXE shortcut icon. An hourglass may (or may not) appear for a few seconds. When you start wcsend.exe on the send computer, the receive computer display should turn black.

NOTES:

· If you are running Dxrecv.exe in Windows 2000 or Windows XP, you may find that the Display Properties settings can not be set to 640 x 480. Therefore, you must change the shortcut properties of DXrecv.exe. This can be achieved by right-clicking on the shortcut and selecting Properties. Once the Properties sheet comes up, click the Compatibility tab. On this tab you will see a "Compatibility mode" group box. Select “Run this program in compatibility mode for:”. Once this box is checked, you will be able to choose an operating system from the drop down list box. Choose Win95 or Win98/Me, depending on your system’s Send computer. If you are running Cortex at 8 bits per pixel color, it is also recommended that you check the “Run in 256 colors”. Also, if you are running at 640 x 480 resolution, you must check “Run in 640x480 screen resolution.“ These two options are located in the "Display settings" section on the Compatibility tab panel.

· If the user would like to change the default baud rate and COM port for the DirectX receive program (DXRecv.exe), the user must change the command line arguments in the Properties page of the Dxrecv.exe shortcut on the desktop. The parameters should be added onto the "Target:" line. For example, the "Target:" line would read:

c:\cortex\wcortex\dxrecv.exe COM2 @115200

· Notice that there are no spaces between the COM and the 2, and no spaces between the @ and the baudrate. If these command line arguments are omitted, the default values are a comport setting of COM1 and a baudrate of 115200. For Win2000 users, the shortcut must be created from the directory \dxsource\dxrecv\release\dxrecv.exe for the command line arguments to work properly. If this is done, then the working directory of the dxrecv.exe program will be \dxsource\dxrecv\release, not \wcortex.

3.6.4.3 "Send" (WCSEND.EXE) software installation

· It is not necessary to install any special graphics driver on the send computer. Therefore, just download and unzip the latest Cortex distribution code from the Cortex web site.

· Edit the c:\cortex\remote32\cortex.cfg file to reflect your system setup. Make sure that the line "COM_PORT 1 115200" has been uncommented.

· The testing files (items, conditions, timing files) must be located on the send computer. (The associated *.lut files must be located in the specified directory on the send computer. If a path to the .lut file is not specified in the conditions file, Cortex will look for the .lut file in the directory from which the send program is running.)

· Boot up the computer into true DOS (see section 3.6.5).

· To run the send program, change to the Cortex directory containing the executables (usually \REMOTE32). In DOS, type "WCSEND" to start the send program running.

· For the DOS version of send and receive, the serial connection between the two computers can be broken while Cortex is running by the keyboard combination CTRL-ALT-SHIFT. You might have to use this keyboard combination several times, and hit the ESC key. To set the keyboard sequence to SHIFT-CAPSLOCK-ALT instead of CTRL-ALT-SHIFT, set the environment variable "CORTEX_ESC_OPT" equal to 1 before running Cortex. If the environment variable is not set, or if it set to 0, then the default CTRL-ALT-SHIFT key sequence will be used.

3.6.5 Booting up the computer in "true" DOS

To run in true DOS mode, shut down your computer and choose "Restart the computer?". When the computer displays the "Starting Windows 95…." message, press the F8 key. In the menu that appears, choose the option for "Command Prompt Only". The computer will boot to a C:> prompt.

In order to make the computer boot up in DOS without having to hit F8, you can do the following:

1) For Win95/98, in C:\ there is a hidden system file called MSDOS.SYS. In order to be able to edit it, go to a DOS prompt, change to C:\, and then type "attrib -h -r -s msdos.sys".

2) Of course, before you edit it, make a backup copy!!

3) Edit msdos.sys. In the [Options] section, add the following lines (or change them if they are already there) to look like this (explained below):

BootMenu=1

BootMenuDefault=6

BootMenuDelay=60

4) Save the file, and change it's attributes back to hidden, read-only, system file, by typing "attrib +h +r +s msdos.sys".

5) Reboot, and it should show you the menu.

NOTE: The above options are set so that:

a) BootMenu=1 means show the menu. If you no longer want to see the menu, you will have to edit it to say BootMenu=0.

b) BootMenuDefault=6 means that if you don't press any menu key, it will automatically boot up with option 6 (command prompt only). In Win98, the value should be 5.

c) BootMenuDelay=60 means that it will wait 60 seconds before running the default menu item. The default time is 30 seconds. Of course, you can make it less, if you want.

3.7 Uninstalling Cortex

Cortex does not place any information in config.sys, autoexec.bat, Windows system directories, etc. Cortex files will only exist in directories where you have copied the files. When installing a new version, it is best to just create a new directory. Delete the old directory when the new version works with your experiment. Remember to change the Cortex.cfg file to be appropriate for your setup.

4. Using Cortex

A fundamental feature of Cortex is that it is organized around "trials". That is, data are collected in discrete trials that last anywhere from a few milliseconds to a few minutes, followed by an "intertrial" interval in which the program does bookkeeping such as storing data from the previous trial and setting up the conditions for the next trial. The duration of the intertrial interval can be increased by the user, but the minimum may be about half a second or so (or longer if you need to read in large images from disk files).

Before Cortex begins running trials, the user must specify the different varieties of experimental conditions that are to be run in the session.

4.1 Setting up the experimental conditions.

To set up the experimental conditions, it is necessary to write at least three ASCII text files "off-line", which you then import into Cortex. These three files can be written using your favorite text editor. Word processing programs cannot be used unless they can output a standard ASCII text file, which some word processing programs have as an option. It is best to work from an already existing set of files (such as the examples and demos provided with Cortex), which you can edit and modify, rather than to try to write the files from scratch the first time.

The three files you must write are items, conditions, and timing (state system) files. For a given experimental session, you can import only a single item and condition file into Cortex, but multiple timing files.

For the items and conditions files, you will note that at the top of each file, there are headings such as ITEM, TYPE, CENTERX, etc. These headings are special keywords that you should not alter. The first and last character of each keyword define the beginning and end of the data field columns located under the keywords. That is, you enter your specifications in the columns situated under each heading word, taking care not to extend any data beyond the first or last character of the heading word. Because "tabs" can mean any number of spaces, depending on your text editor, Cortex cannot interpret tabs in the files. Thus, DO NOT USE TABS. USE ONLY SPACES between values in the items and conditions files. If you use tabs, previous versions of Cortex would read in your file in a jumbled manner and become very confused. The recent versions at least warn you that tabs are present in your file. If you get a warning about tabs, re-edit your file to remove them and then reimport the file. The state system file is free-format, so tabs are fine. The format of the files is given next.

4.2 Item files

For experiments in vision, you probably have in mind a number of visual stimuli that you want to present to a particular neuron or subject. Before specifying how and when you want the stimuli to be presented, it is first necessary to describe to Cortex the stimuli you want to present. These stimuli are referred to as ITEMS in Cortex.

You must describe each item you want to use in a given experimental session in the ITEMS ASCII file, which you import into Cortex at the start of the session. For example, you might want to compare the responses of a neuron to 20 bars of light that vary in color and orientation. In the items ASCII file, you would describe the 20 items in the format required by Cortex, including the type of visual stimulus (in this case, bars of light), their height, width, orientation, color, and position relative to some reference point on the display screen (to be described later).

An example items file is shown below:

ITEM TYPE FILLED CENTERX CENTERY BITPAN WIN_WIDE WIN_TALL HEIGHT WIDTH ANGLE INNER OUTER -R- -G- -B- C ------FILENAME------

-4 1 1 0.00 0.00 0 1.00 1.00 0.00 0 0 0 x

-3 1 1 0.00 0.00 0 0.30 0.30 0.00 255 255 255 x

-2 1 1 0.00 0.00 0 1.00 1.00 0.00 255 255 255 x

-1 1 1 0.00 0.00 0 1.00 1.00 0.00 255 255 255 x

0 1 0 0.00 0.00 0 3.00 1.00 0.00 50 50 50 x

1 1 0 0.00 0.00 1 3.00 1.00 45.00 100 100 100 x

2 8 0 0.00 0.00 2 1.8 1.8 230 0 230 x face.ctx

3 1 1 0.00 0.00 1 3.00 1.00 45.00 250 250 250 x

Some of the columns you must fill in within the items file are as follows:

ITEM. The ITEM refers to the item number, which you henceforth use in Cortex as the name or identifier of the stimulus you have created. Some items have negative numbers. These are "special" items that are used internally by cortex. Their meaning is usually as follows, but can be used differently:

-4 Background item

-3 Fixation spot item

-2 Reference field

-1 Reference point

0 Play item

TYPE. Cortex can handle many different kinds of items, which generally fall into two classes. The first class Cortex "knows" how to create itself. This class includes bars, circles, ellipses, annuli, and ASCII characters. Each of these types has an associated code number, which you enter in this column (see below for a list of type codes). In addition, you must enter the appropriate information about the items in the other relevant columns in the file. For example, bars need a length and width, circles need a radius, etc. The second class is bitmaps and movies, which are items that you have created outside of Cortex and saved in a disk file. These also have a "type" number, which you enter in this column. For these bitmap and movie items, you must also give the name of the disk file that holds them in the FILENAME column. For the format of these bitmapped files, see Section 7. All items, regardless of type also need an CENTERX and a CENTERY, which you enter in the appropriate column.

Item type codes:

1 bar

2 circle

3 circular annulus (outer and inner diameter should be entered in the inner and outer columns)

4-6 reserved

7 ascii character

8 bitmap (name of file must be in FILENAME column)

9 ellipse

10 annular ellipse

11 movie (name of file must be in FILENAME column)

12 regular polygon

13 ascii string

14 cross

FILLED. Objects such as bars, circles and annuli can either be filled or just an outline. If you put a '1' in this column the object will be filled, and if you put a '0' it will be an outline. If a FILLED parameter is not specified, the item will be filled by default.

CENTERX, CENTERY. Each object must have a location on the screen. This sets the x and y axis location, in degrees, from the reference point. The reference point is the location that Cortex defines to be the center of its coordinate system for placing items on the screen. The user can configure this location.

BITPAN. "Bitpannable" means that you plan to pan objects around inside a stationary window on the screen. A '0' in this field means that the object is not bitpannable, and cortex should treat it like any other object. A '1' in this field means that it is bitpannable, that cortex should utilize the window size you specify (see below), and that cortex should replicate the object 4 times, to give you more object to pan around with. A '2' in this field means the same as 1, but Cortex won't replicate it. If you use option 1, there may be sharp transitions in the image at the boundaries of the four replications, but for some purposes, this is OK. Also, you may need to set the bitpan field to 2 if you have an extremely large object. The Sgt. Pepper card will not allow you to import a bitmap larger than the display screen (640 x 480), unless you specify a window around it that is smaller than 640 x 480.

WIN_WIDE, WIN_TALL. When you give a window length and width (in degrees), and the object is bitpannable, Cortex will create a window around your item. This will allow you to pan a large object around inside a smaller window. This is only available when bitpan=2 for Manual.

HEIGHT, WIDTH, ANGLE. Bars require a length, width and orientation, in degrees.

OUTER. Circles and ellipses require an outer diameter.

INNER, OUTER. Annuli require an inner and outer radius.

C (Color), -R-, -G-, -B-. For items that Cortex knows how to create, such as bars and circles, you must tell Cortex what color they should be. In the color column you may, if you wish, give a letter representing the color name you want. 'R', for example, stands for red. However, these default colors will probably not have the exact red, green, and blue values you want, so you should really list the actual rgb values you want in the file instead of just giving a color name. To give the actual rgb values, use 'X' as the color name in the color column, and then enter the appropriate values in the -R-, -G-, and -B- columns. These values range from 0 (off) to 255 (maximal brightness) for each red, green and blue gun on the CRT.

For items that are stored as bitmaps, the color you list in the items file is ignored. The colors are determined by the color lookup table, which is described in Section 7.3. The name of a color lookup table file can be entered in a menu within Cortex or listed in the conditions file (see below).

FILENAME. For bitmap and movie items, you must give the filename. The name can include a path, if it is not in the current directory. Note, however, that the length of the name, including the path cannot extend past the ends of the ------FILENAME------ column (i.e., 20 characters total).

4.3 Conditions files

The second ASCII file you must import into Cortex is the conditions file. Cortex can interleave trials from a large number of experimental conditions within a single experimental session. Each condition determines what happens on a particular type of trial. In this file, you specify which items are linked together within each condition, and which timing structure is associated with that condition.

An example of a conditions file is as follows:

COND# TEST0 TEST1 TEST2 TEST3 TEST4 TEST5 TEST6 TEST7 TEST8 TEST9 BCKGND TIMING TRIAL_TYPE FIX_ID ---COLOR-PALETTE---

1 2 2 1 2 0 -3 lookup.lut

2 3 6 7 5 4 1 1 0 -3

3 4 4 1 2 0 -3 lookup.lut

4 6 7 8 9 1 1 0 -3

5 10 9 3 5 1 1 0 -3

6 12 13 12 13 1 3 0 -3

7 13 12 13 12 1 3 0 -3

COND# The condition number is, as you might expect, the number of each experimental condition. Each line typically defines a condition, but if you need to list more than two items on a given test screen, you can list the additional items on the next line. In the above example, condition number 2 extends across two lines. Depending on the version of Cortex you are using, the maximum number of items per test screen is either 4, 8, or 16.

TEST0, TEST1, etc. For each test screen you list the items that you want to appear together. The item numbers refer the items listed in the items file. On a single trial, you can have up to ten successive screens worth of images presented. The timing and sequence of the display screens is given in the state system. For example, the state file could be programmed so that in condition 2, TEST0 containing items 3, 6, and 5 will appear together first on the display screen. Then,TEST1 containing items 7 and 5 will appear together, followed by TEST2 containing item 4 alone. You can switch from one display screen to the next in one frame, i.e. 16.6 milliseconds when running at a 60 Hz refresh rate.

The order of the test screens and the order of the items within the test screens are important, if the timing file contains commands to display multiple test screens simultaneously. TEST0 will always be on top, followed by TEST1, then TEST2, etc. (That is, TEST0 will cover up everything below it.) Within the tests, the items are drawn in the order they are listed. That is, if TEST0 lists items 1,2,3,4 (in that order), they will be drawn in the same order (1,2,3,4). Item 1 will be on the bottom, and item 4 will be on the top.

BCKGND. For the background, you list an item that you would like to have as the background on each test screen. Only the color of the item, as specified in the RGB columns in the items file, will be used.

TIMING. In this column, you list which timing file (state system file), you want to run with this condition. The timing files are imported separately, and are referred to by their number.

TRIAL_TYPE. Currently not used, except as the expected_response field in the output data file header.

FIX_ID. In this column, you list which item you want for the fixation stimulus. This is typically item -3, the item number that Cortex uses internally to hold the fixation stimulus. However, you may list any item.

---COLOR-PALETTE---. The color lookup table for images and movies can either be entered from within one of Cortex's menus, or listed on a line in the conditions file. This should be the name of a disk file that holds the lookup table. Each condition can have its own lookup table. Lookup tables can also be loaded by number from the state system, for dynamic changes in color during a trial.

We have neglected the issue of timing -- when and for how long the stimuli remain on the screen. Each experimental condition is associated with a timing file. The same timing file may be used by all conditions or each condition may have its own. The timing file is discussed in the next section.

4.4 Timing files

The timing file is responsible not only for informing Cortex when stimuli should go on and off, but also for any behavioral contingencies such as monitoring for a lever press, checking eye position, giving rewards, etc. The price for this flexibility is that the user must program every aspect of the flow of control, every contingency, every error state, etc.. If you know the C programming language, the state language of CORTEX will seem very familiar; the language is essentially a subset of C, with a few added features.

Each timing file is written as an ASCII file and saved with a file name. After you have written and stored your state systems as disk files, you then import one or more of the files into CORTEX, which sequentially assigns them each a number. These numbers are used as names for the timing structures. In the conditions file, you specify which timing structure is associated with each condition. For example, you may want to use two different timing structures in an experiment. Each will have its own ASCII file, with its own file name, and you will import (from within Cortex) the one timing file as timing structure #1 and the other as timing structure #2. In the conditions file, some conditions may list timing file #1 as the necessary timing structure and other conditions may list timing file #2. For information on writing the timing file, please refer to the separate document entitled, "Timing File Reference Manual".

4.5 Using the ITEMS, CONDITIONS, and TIMING files in a study

By modifying different ITEM, CONDITION, and TIMING files, either alone or in combination, you can create many different experiments. For example, once you have set up an experiment using a particular set of ITEM, CONDITION, and TIMING files, you could change the stimuli alone by importing a different ITEMS file into Cortex. Another way to achieve the same end would be to import a single large ITEM file that held a large number of stimuli to use, and then switch the items to use for a particular experiment by importing a new CONDITIONS file. The new CONDITIONS file will select new items from the ITEMS File. Alternatively, your primary interest might be in different experimental paradigms rather than different stimuli. In this case, you could keep the ITEMS and CONDITIONS files constant, but import different timing files for different experiments.

4.5.1 Deciding on your Experimental Design

Cortex can interleave trials from a large number of experimental conditions within a single experimental session. Each condition determines what happens on a particular type of trial. For example, in one experimental condition, you may want just a red item presented, and in a different condition you may want just a green item presented. Therefore, you would set up two conditions, each with a single item on the TEST0 screen.

Why use two conditions rather than one in this example? Why not just present the red item on the TEST0 screen and the green item on the TEST1 screen of a single experimental condition? You could do this, but then the order of stimulus presentations would be the same throughout the experiment (i.e. red followed by green). If you want stimulus presentations randomly interleaved, you should assign stimuli to different experimental conditions because Cortex can only randomize the order of presentation of conditions, not the screens within a condition (actually, strictly speaking, ANYTHING can be done within the state system, including randomizing the order of presentation of screens within a condition, but this is tricky stuff). Another reason to use multiple conditions rather than a single condition with multiple screens is that there is a limit to how many screens can be presented sequentially within a single condition. You can only have 10 different screens of images (TEST0 through TEST9) within a single condition, but you can have any number of conditions.

O.K., you might ask, why do you ever need multiple image screens within a single condition? Why don't you just use one condition per screen image? One reason is that screens can be switched in 16 milliseconds (or less, depending on the refresh rate capabilities of the graphics card and monitor), whereas switching between conditions typically may require about a half a second because of various disk operations that must be performed. For some experiments, you may want to switch between certain stimuli rapidly, in which case you should put the stimuli on different screens within the same condition. Another reason is that you may want pairs or groups of stimuli always presented in the same order. Thus, on one condition you may want to have a red bar always followed by a green bar, and on a second condition you may want to have a blue bar followed by a yellow bar. Finally, if there are any behavioral contingencies linked to your conditions, at present these contingencies cannot easily span different conditions (except in some limited circumstances, described later). Consequently, if, for example, you expect a specific behavioral response to a red bar only when it has been preceded by a green bar, these two stimuli should be placed in the appropriate order within the same experimental condition. If you expect a different behavioral response to a red bar preceded by a red bar, you should place these stimuli in the appropriate order in a different condition. Items, incidentally, can be reused in many different conditions.

The concept of conditions is also related to how the data are stored. Recall that data are stored by trial and condition, with the data for each trial preceded by a header. Thus, one trial's worth of data in the data file would contain the data for condition one, the next trial's worth of data might contain the data for condition five (depending on the order of presentation), etc.. Within each trial's worth of data, the onset and offset of TEST0, TEST1, etc can be marked by using the encode() function in your timing file. Suppose that a red bar item is presented only on the TEST0 screen of condition 12. To locate the neuronal responses to the red bar in the data file, you would find all the trial data for condition 12 (the condition number is given in the header for each trial), and then find the time of occurrence of TEST0 in each of the trials for that condition. The spikes that fall within TEST0 onset and TEST0 offset represent the neuronal response to the bar on that trial.

4.6 Customizing Cortex with the Cortex.cfg configuration file

Within your current directory, you should also have a Cortex configuration file, which must be named 'Cortex.cfg'. This file contains information about the type and address of the hardware devices you are using as well as information about the size and location of graphic windows on the user's display (e.g. the histograms, rasters, eye position display, etc). The file is an ASCII file that can be edited both to conform to your current hardware configuration and to customize your display. An example configuration file should have been included with the distribution code.

The MONITOR_TYPE line of the Cortex.cfg file refers to the user's monitor. If this is not set correctly, your screen may go haywire when the program loads. For the SGT Pepper version of Cortex, there are fewer compatibility problems with the pepper card if you use the Hercules card as the user's display device. However, VGA should work, as well. For the dual computer version of Cortex, VGA should work fine.

A second critical piece of information to check is the name and address of the analog/digital I/O board in your system. This is set on the DEVICE line of the Cortex.cfg file, but the device information also is important on the THREADS and MULTI_SPIKE lines.

A third critical piece of information includes the graphics resolution and the pixels/degree that are to be used for the subject's display. These values are set in the GRAPHICS_SPECS line of the Cortex.cfg file. Because you specify all locations to Cortex in terms of degrees of visual angle, Cortex needs to know how many pixels equal one degree. You can calculate this based on the size, resolution, and distance of your monitor from the subject. Cortex assumes that your monitor has the correct aspect ratio, so that pixels are square. An example Cortex.cfg file can be found in Appendix C.

5. Running Cortex

5.1 The Cortex Menu Hierarchy

RUN

Parameters

Start

Resume

Display

ExternVars

Getaccuracy

Histogram

Rasters

Eog

List epp

Touch

Eye trail

Clear

PLAY

Alone

Condition

Conds&save

Data & hists

Num play

items

ITEM

Import

Display

View/

Modify

Use All

Add

Save

Reference

CONDITION

Import

View

Display

Modify

Save

TIMING

Add

Modify

Delete

Help

Add

Binary

Modify

Binary

LUT

Number

View

Activate

Get

Save

Store

Recall

DISK

Save

Get

SET

Import

Load

iComp

5.2 Main menu

After Cortex loads, the following menu will be displayed:

Run Play Item Condition Timing LUT Disk Set

To choose a command from the menu, either type its highlighted character or highlight the entire word with the arrow keys, followed by the "enter" key. The "escape" key will bring you out of the current menu and back to a higher level. Normally, you will want to import the items, conditions, and timing files first.

NOTE: From any menu you can hit the F1 key, which will put you into DOS while retaining Cortex in memory. From DOS, you can run a DOS editor to change any items, conditions, or timing files you want, or you might execute a DOS command such as a directory listing, or whatever. To return to the program, just type 'exit'. Everything you have entered into the program is saved when you return, as is any data you have collected. If you changed an items, conditions, or timing file while in DOS, Cortex will not know about your changes unless you re-import the file into Cortex.

Item. To import the items file, type 'i' for items, and Cortex will display the items menu. Then choose 'i' for import, and give the file name. To actually see one of the items on the graphics screen, type 'd' for Display, and give the item number when prompted. If the items file contains images, you will need to import a color lookup table to see the image. Type 'l' to invoke the LUT menu, then give the filename for the table. If you simply want to view a listing of the item's properties (item type, length, width, etc.), or change them, type 'v' for view/modify and give the item number when prompted.

Another items menu choice is the reference point. If you type 'r' for reference, Cortex will tell you what is the current reference point and will then ask if you want to change it. The five possible reference points are: 'background (-4)', 'fixspot (-3)', 'Rfield (-2)', 'Rpoint (-1)', and 'Play (0)'. The reference point is the location that Cortex defines to be the center of its coordinate system for placing items on the screen. For some studies in fixating subjects, the fixation spot is the most natural reference point. If you make the fixation point the reference point, then the location of all the stimulus items will necessarily be in retinal coordinates. Alternatively, you might want your items displayed at locations relative to some other point on the screen, such as the center of the receptive field you are studying. If so, choose 'Rfield' as the reference (ie. Item number=-2). Note that, unlike other items, the fixation point location is always specified in screen coordinates, i.e. its location is not referred to any reference point other than itself. The reference point and its location can also be changed within the "play" routine, which is described a little later.

Condition. From the main menu you can access the Conditions menu just like you did the Items menu. Like with items, you can ask Cortex to display a condition. One difference from the items display is that when you ask Cortex to display the items listed on a particular test screen of a particular condition, it will show you all of the items that you linked together on the test screen, including the background item. Thus, you can see how the stimulus screens will actually appear during a trial.

Timing. Like the Items and Conditions, you access the timing menu from the main menu. Unlike the case for Items and Conditions, you can import multiple timing files. To import the first timing structure, type 'a' to add a timing file, and you will be prompted to supply the filename of the file. After importing the first file, type 'a' for Add, to add more timing files to the list. If you make a mistake, you can go back and reenter a state file, by typing 'm' to invoke the modify option. Each condition in the Conditions file must specify the number of a valid timing structure.

Disk. Rather than importing the same files each time you run an experiment, you can save all of the files and other parameters in a single disk save file, which you can import the next time you run the program. Go to the disk menu and type 's' for Save. Normally, you would not 'save' the files and parameters until you have entered all of the information required by Cortex, which is described below. To retrieve the file at a later time, type 'g' for

Get in the Disk menu.

Play. When you are collecting data, Cortex runs in a very automated fashion and does not allow you to change stimuli interactively. However, it is often desirable in mapping receptive fields to be able to change stimuli and their location "on the fly". In such an informal mode, you generally don't need to be collecting and storing data, since you are changing stimuli in an unpredictable way. Rather, you want to be able to hear the neuronal responses on a loudspeaker while you are playing around with stimuli. After you have decided on the receptive field, you want to be able to use the receptive field center as the reference point for all subsequent stimulus presentations when you collect data. You may even want the play stimulus you have created to become an item that is displayed automatically when data are collected again. All of this is what PLAY is designed for. Play has two modes, "alone" and with "conditions". The "alone" mode is appropriate for experiments in which there are no behavioral contingencies. By default, Cortex uses a white square as the Play item. In this mode, PLAY simply allows you to move and change stimuli constantly, using a mouse.

After the Play mode has started, the F10 function key will invoke a full-screen list of play parameters. The arrow key on the keyboard can be used to move the cursor through the different parameters. Type in new values to change them. Some of the parameters (Position, Item Size, and Orientation) can also have their values controlled by the mouse. For example, if "Position" is highlighted, pressing and holding the right mouse button, while moving the mouse, should move the Play item left and right. Similarly, pressing and holding the left mouse button, while moving the mouse, should move the Play item up and down. Pressing and holding both mouse buttons, while moving the mouse, should allow the Play item to move in all directions.

These same operations will work if the cursor is on the "Item Size" choice, except they will change the size of the item. "Orientation" also can be manipulated by the mouse, but the left and right mouse buttons both have the same effect on orientation. Once the cursor is on "Position", "Item Size", or "Orientation", you can hit the F10 key again to make the full-screen parameter list disappear. Whatever parameter was highlighted will be the parameter that the mouse will change. If the cursor is not on one of these three parameters, the mouse will have no effect.

In the "conditions" mode, PLAY runs whatever experimental conditions you choose, and simultaneously allows you to change and move stimuli around with the mouse. The experimental conditions in this case normally have some behavioral component to them -- e.g. a fixation task. In this mode, PLAY will continue to reward the subject for performing the task correctly and will operate just as it does when you are collecting data. The difference is that you have control over your own mouse-driven stimulus.

When you have found a particular receptive field location that you want to save, PLAY allows you to save the play item parameters, including its location, to any item in your item file. The item you save the play item to, can also be the reference item. Reference point items are described in the section on the Item menu. From within PLAY, you can select 'receptive field' or another item to be the reference point, and then save the location of the mapping stimulus to the reference point. Then, when you return to collecting data, the items will be displayed at locations relative to the center of the receptive field that you found. The reference point can also be changed from within the ITEMS menu, described previously. NOTE: This code has not been changed since the last release, but during recent testing of multiple versions we have not been able to get the reference item and reference point to function in the manner described above.

LUT. The LUT menu is used for loading, viewing, and changing color lookup tables in Cortex. Refer to Section 7.3 for more information.

5.3 The Run Menu

Run. After importing the necessary files, you go from the main menu to the menu for running trials and collecting data. The run menu is the following:

Parameters Start Resume Display ExternVars Get accuracY Histogram rAsters eOg List epp touch eye_Trail clear

Parameters. The parameters menu allows you to set up staircasing, and to set other general parameters.

Some of the more obscure options are as follows:

Blocking. Cortex allows the conditions to be grouped within blocks. Within each block, you can specify how many trials you want to run. This has great utility when you want conditions to be randomly chosen within a small subset of the conditions, but not across the full range of conditions. For example, you might set up one set of conditions in which the subject is to perform visual discriminations based on color and another set of conditions in which the subject is to perform discriminations based on orientation. By placing the color conditions within one block and the orientation conditions within another, you can prevent the orientation conditions from being interleaved with the color ones.

Selection_with/without_replacement. If you choose 'without replacement', then when Cortex picks a condition to run, it deletes that condition from the list of conditions that it will choose from for the next trial. Cortex will calculate how many times each one can be called for the maximum number of trials. Then, the conditions can be presented in any order. Each condition has a counter of how many times it can be presented. The counter is changed each time the condition is presented. So, ultimately (across all trials) there is an even distribution. If you choose ' with replacement', then Cortex puts the chosen condition back into the available list of conditions, so that condition might even be chosen again for the next trial.

On_Error. In addition to selection with/without replacement, there are other blocking options that affect how conditions are chosen. Some of the possible condition-picking options are ignore, retry_immediately, and delayed_retry. The last option is extremely useful, but it requires some explanation. When training a subject, it is often desirable to repeat a condition that it gets wrong, so that it doesn't decide to just skip all the difficult conditions or make just one kind of response. A common technique is to use "correction trials", which means to simply repeat a condition that is not performed correctly. The problem with conventional correction trials is that a subject who makes an error can learn to simply make the opposite response on the next trial, and it will then always get the next trial correct. A better way to do correction trials is to put the condition performed incorrectly back into the list of conditions to be chosen from randomly on the next trial. This option assumes random selection without replacement for all correctly performed trials. The incorrectly performed condition will keep coming up in the block ever more frequently (but not necessarily the very next trial) until the subject gets it correct. (More information on Blocking can be found in Appendix A.)

Eye Window Size. For studies in fixating subjects, you need to specify the size of the fixation "window", or fixation criteria. If, in the timing file you wrote that the subject must start to fixate by some time point during the trial, then Cortex will use the window size to decide whether fixation has been achieved (and remains achieved). To open the window all the way up, give it a size of 30 degrees or more.

A2D Gain and Offset. Cortex cannot actually measure degrees of eye position. It can only measure voltages from the A/D converters. Cortex assumes that the full-scale range of the A/D converter is equivalent to an eye movement from one side of the display screen to the other. If this is not so, you should adjust the eye position gain either using the gain setting on your eye tracking hardware, the gain setting on the analog input board, or let Cortex set the gain programmatically using the value supplied in the Cortex.cfg file as the A2D_GAIN parameter. Refer to the documentation for your particular board for information on how to set this parameter. Typically, you shift your fixation stimuli 5 degrees or so to the left, right, up, and down, and keep adjusting the eye coil hardware gain and offset setting until Cortex shows that the subject's eye position is on it. The size, in degrees, of the "crosshair" on the eye display can be changed by setting the "Eye max saccade allowed" parameter in the Run:Parameters:General menu, which is a convenient way to measure distance in degrees on the display screen. If for some reason you can't get your gain high enough or whatever, you can also enter an integer gain multiplication value in the Run:Parameters:General menu, which will be used to multiply all incoming A/D values. The default is 1, which is the recommended setting. There are also eog_xoffset and eog_yoffset parameters in the Run:Parameters:General menu, which will be subtracted from the data. The default for the offset parameters is 0.

Start. This menu option starts running the experiment. The items, conditions, and timing files should have already been loaded. You will be prompted for the name of a file to use for the output data file.

Display. Displays the encodes of the trial that just completed.

Extern Vars. This menu option is used to load, set, and modify certain Cortex State System external variables. There is more information about using external variables in the "Timing File Reference Manual".

Get. Retrieves saved parameters, items, conditions, and timing files. (It has the same behavior as the Disk:Get menu option.)

EOG. Lists the EOG values from the trial that just completed, if the parameters and timing file were set to collect EOG data.

List epp. Lists the EPP values from the trial that just completed, if the parameters and timing file were set to collect EPP data.

Touch. Lists the touch screen values from the trial that just completed, if the parameters and timing file were set to collect touch screen data.

Eye Trail. Connects the dots of the EOG values on the user's monitor, if the parameters and timing file were set to collect EOG data.

Accuracy. Lists the accuracy and circular buffers for the blocks and conditions.

Clear. Truncates the data file, clears the histograms and raster plots, and clears the staircasing data.

5.4 Quick Start Instructions

If the Cortex executables have been downloaded and installed on your computers (see Section 3), these instructions will run you through a brief introduction to the use of Cortex. These instructions assume that you have installed Cortex in a directory named \cortex.

5.4.1 Dual computer version (with DirectX-based receive program)

Make sure that the send computer has been started up in true DOS mode (Command prompt only).

1) On the receive computer:

a) DXRECV.EXE is a Windows console application, which must be run from Windows (not DOS). The easiest way to run it, is to make a shortcut on the desktop of the receive computer to the executable, \WCORTEX\DXRECV.EXE. When you want to run the program, just double-click on the DXRECV.EXE shortcut icon. An hourglass may (or may not) appear for a few seconds. When you start the send computer, the receive program should go black.

2) On the send computer:

a) At the DOS prompt, type "cd \cortex\remote32" and hit enter.

b) Then, type "wcsend" to start the Cortex send program.

c) Cortex will ask if the parameters are OK. Type "Y" for yes.

d) A connection should now occur between the send and receive computers. It will now ask if you want to run Cortex. Type "O" for OK.

e) Now, you must load an items file, a conditions file, and a timing file. You can find examples of these files in the c:\cortex\demos\ directory. To load an example items file, choose Items:Import from the menu, and then type in c:\cortex\demos\misc\gtest.itm and hit enter. Hit "escape" until you get back to the top level Cortex menu. To load the conditions file, choose Conditions:Import from the menu, and then type in c:\cortex\demos\misc\gtest.cnd and hit enter. Again, hit "escape" to get back to the top level. To load the timing