document version 1.0

last updated 04 August, 2002
 
 


























VCortex: Cortex for Windows

(beta version 1.0)

User’s Manual
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Laboratory of Neuropsychology, NIMH



 
 
 
 

TABLE OF CONTENTS
 TABLE OF CONTENTS *

1. Introduction *

1.1. Cortex: A Program for COmputerized Real Time EXperiments. *

1.2 Getting the latest version of Cortex *

1.3 Technical Support *

1.4. History (you may skip this part) *

 2. Hardware and Software Requirements * 2.1 Two-computer Cortex (\VCWin32\VCSend.exe) *

2.2 Single-computer Cortex without graphics (\VCWin32\VCSingle.EXE) *

 3. Installation * 3.1 Data Acquisition Board Setup *

3.1.1 Typical Keithley/Metrabyte DASH-16 settings *

3.1.2 Typical PIO24 or CIO-DIO24 settings *

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

3.2 Graphics Board Setup *

3.3 Data Acquisition Interface Setup *

3.3.1 Spike Flip Flop Circuitry *

3.3.2 Thalamus *

3.3.3 Screw Terminal Interface Diagram for the DASH-16 type boards *

3.4 Sound Card Setup *

3.6 Cortex Software Setup and Program Execution *

3.6.1 Minimum Files Necessary to run Windows VCortex *

3.6.2 Installing VCortex on a computer without any data acquisition boards, or a computer that only has PIO24 type boards *

3.6.3 Installing VCortex on a computer with a CIO-DAS16 type board *

3.6.4 Installing the DirectX Receive Program on the receive computer (Win95/98/2000/XP) *

3.7 Uninstalling Cortex *

 4. Using Cortex * 4.1. Setting up the experimental conditions. *

4.2. Item files *

4.3. Conditions files *

4.4. Timing files *

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

4.5.1 Deciding on your Experimental Design *

4.6. Customizing Cortex with the Cortex.cfg configuration file *

 5. Running VCortex * 5.1 The Main Menu Structure *

5.1.1 The File Menu *

5.1.2 The Edit Menu *

5.1.3 The Options Menu *

5.1.4 The Tools Menu *

5.1.5 The Run Menu *

5.1.6 The Clear Menu *

5.1.7 The View Menu *

5.1.8 The Window Menu *

5.1.9 The Help Menu *

5.2 The File Menu Dialog Boxes *

5.2.1 File->Load->Item File *

5.2.2 File->Load->Condition File *

5.2.4 File-> Load ->Saved File *

5.2.5 File-> Load ->LUT File *

5.2.6 File->Load->External Variables File *

5.2.7 File->Load->Blocks File *

5.2.8 File->Save->Item File *

5.2.9 File->Save->Condition File *

5.2.10 File->Save->Saved File *

5.2.11 File->Save->LUT File *

5.2.12 File->Save->External Variables File *

5.2.13 File->Save->Blocks File *

5.3 The Edit Menu Dialog Boxes *

5.3.1 Edit->Individual Item *

5.3.2 Edit->Individual Condition *

5.3.3 Edit->Timing File->Modify *

5.3.4 Edit->Timing File->Delete *

5.3.5 Edit->External Variables->Generic Externs *

5.3.6 Edit->External Variables->Named Subsets *

5.3.7 Edit->Fixspot Item *

5.3.8 Edit->Reference Item *

5.3.9 Edit->LUT *

5.3.10 Edit->Add an Item *

5.4 The Options Menu Dialog Boxes *

5.4.1 Options->Block / Repeat->Sizing *

5.4.2 Options->Block / Repeat->MasterBlock *

5.4.3 Options->Block/Repeat->Individual Blocks *

5.4.4 Options->General Parameters *

5.5 The Tools Menu Dialog Boxes *

5.5.1 Tools->LUT->Set Number of Palettes *

5.5.2 Tools->LUT->Activate *

5.6 The Run Menu Dialog Boxes *

5.6.1 Run->Start *

5.6.2 Run->Resume *

5.6.3 Run->Stop *

5.7 The Clear Menu Dialog Boxes *

5.7.1 Clear->External Variables->All *

5.7.2 Clear->Blocking->CONDstats *

5.7.3 Clear->Blocking->BLOCKstats *

5.7.4 Clear->Blocking->Reset All *

5.7.5 Clear->Histogram/Rasters *

5.8 The View Menu Dialog Boxes *

5.8.1 View->Results of most recent trial->Codes *

5.8.2 View->Results of most recent trial->EOG values *

5.8.3 View->Display an Item *

5.8.4 View->Display a Condition *

5.8.5 View->Status Bar *

5.9 Window Menu Dialog Boxes *

5.10 Quick Start Instructions *

5.10.1 Dual Computer Cortex version (VCSend) *

5.10.2 VCSingle version *

 6. Limitations of Cortex due to structure and hardware * 6.1. Data storage *

6.2. Data file format *

6.3. Interrupt structure *

 7. Image File Formats and Color Lookup Tables * 7.1. Image File Formats *

7.1.1 The Cortex Image File Format *

7.1.2 Image File Formats Available with DirectX version of Cortex *

7.1.4 Transparency with DirectX receive program *

7.2 Movie File Formats *

7.2.1 Cortex Movie File Format *

7.2.2 Movie File Formats Available with DirectX version of Cortex *

7.3. Color Lookup Table *

7.3.1 What is a Color Lookup Table? *

7.3.2 How Cortex uses Color Lookup Tables *

7.3.3 Using the Cortex LUT Menu Options *

 8. Source Code * 8.1. Distribution *

8.2. Components *

8.3. Compiling the executables *

8.4. Adding new functions and external variables to Cortex *

8.4.1 Adding new system functions to Cortex *

8.4.2 Adding library functions *

8.4.3 Adding External Variables to Cortex *

8.4.4 Rebuilding Cortex after adding new functions and variables *

 9. Data File Structure * 9.1. Sample data file * 10. Troubleshooting * 10.1 Send/Receive computers cannot communicate: Debugging the serial connection *

10.2 Image file does not display *

10.3 Movie file does not display *

10.4 Sound does not play *

10.5 Timing file does not compile *

10.6 Spikes are not appearing in the histograms *

10.7 Colors do not look correct for BMP files *

10.8 Display of movies is slower than the refresh rate of the monitor/graphics card *

10.9 EOG data is not being stored to file *

10.10 EPP data is not being stored to file *

10.11 Adjusting the gain of the analog data *

10. 12 Can not see spike codes when viewing data *

10.13 "ERROR: CODE_ISI buffer overflowed x times (data was lost)" in the error file *

 Appendix A. Technical Notes on Blocking * A.1 Overview of the built-in capabilities for general staircasing designs *

A.2 Options->Block/Repeat Menu *

A.3 Functions available for MANUAL operation *

A.4 Technical details on the internal operations of the Cortex code *

 Appendix B. Known Bugs, Limitations, and Differences from DOS Cortex *

Appendix C: Sample Cortex.cfg file *

Appendix D: New Timing File Functions in the Windows version of Cortex *

Copyright notice *

1. Introduction
 1.1. Cortex: A Program for COmputerized Real Time EXperiments.

Cortex is a program for running neurophysiological and behavioral experiments on a PC. Although it is still undergoing revisions, the DOS version of Cortex 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, and mouse 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.

A separate computer is currently responsible for the graphical display on the subject's monitor. Any VESA compliant graphics card/monitor, which is supported by 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 \VCWin32 directory, 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.

This document describes the new Windows version of Cortex, VCortex. It was named "VCortex" since the interface was written with Microsoft's Visual C++ product. Rather than supplying a document describing the differences from the DOS version of Cortex, or even assuming a knowledge of the DOS version, this document was intended to stand on its own for VCortex. Of course, there is so much overlap between the two versions, much of the documentation is identical to the DOS version. In fact, the program will still be referred to as "Cortex", instead of "VCortex" in most of this document.

New users of Cortex are encouraged to read this entire manual. Experienced DOS users of Cortex should read Chapters 2, 3, and 5 for the major changes. Additionally, Appendix B contains a list of know bugs, limitations, and differences from the DOS version of Cortex.

1.2 Getting the latest version of Cortex

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

http:// 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/discuss.htm).

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. He is now devoting his time to earning a 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 Olsen - joined the Cortex Team in the summer of 2001. She took Trina's simple Visual C++ Windows version of the Cortex interface, and wrote the MFC code to transform it into the wonderful dialog boxes and menus that you see today. She also has spent a lot of time testing and contributing to the documentation of the Windows version of Cortex.

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.

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.

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 (\VCWin32\VCSend.exe) 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.

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.

 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. With the VCortex release, only the DirectX version of the receive program has been tested and shipped in the zip file. This is not to say that the Scitech version will not operate with VCortex, but it is not the recommended display program, and will not be discussed in the VCortex User's Manual.

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 Currently, the Windows send program will only run from Windows 95 or Windows 98.

The Windows DirectX receive program must be run from Windows. It can run with Win95, Win98, Win2000, WinXP. 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 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 The Windows version of Cortex was written specifically on the CIO-DAS1602/12 data acquisition board. It uses the onboard clock of that board to provide the timing. In the case where a CIO-DAS16 type board is not present, VCortex can also reprogram the Windows internal timer (the Windows Virtual Timer Device) to tick at 1 millisecond intervals. This option is useful in cases where the user does not have any data acquisition board, or has only a PIO24 type board.

Some testing on a CIO-AD16 was also performed successfully. Therefore, it is likely that all of the ISA data acquisition boards originally specified for the DOS computer version of Cortex should also work with the Windows 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 PCI versions of the data acquisition cards are not supported in this release of VCortex.

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.

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 Any sound card which is supported by DirectX can be installed in the receive computer with the DXRecv.exe program. 2.1.7 Touch screens The touch screen code that was written for the DOS version of Cortex, has not been migrated to the Windows version. Therefore, touch screens are not supported in this version of VCortex. 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 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.1.11 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/

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

NTI http://www.networktechinc.com/
 
 
    1. Single-computer Cortex without graphics (\VCWin32\VCSingle.EXE)

The VCSingle.exe version is a Windows 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.

2.2.1 Computer

The single-computer Cortex computer controls experimental timing, data collection, and can send serial commands to another computer. This 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.

 2.2.2 Data acquisition cards All of the data acquisition boards originally specified for the two computer version of Cortex should also work with the single version of Cortex. See section 2.1.5 above. .
3. Installation
 3.1 Data Acquisition Board Setup

3.1.1 Typical Keithley/Metrabyte DASH-16 settings

  1. Base Address: 0x300 or 0x310
  2. 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.
3) should be set for bipolar, 16 analog inputs

4) gain = whatever is convenient

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

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

7) bar contact input: digital input 2 and 3

8) 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.

9) 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.

10) 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.2 Graphics Board Setup Install the graphics card according to the graphics card manufacturer's instructions. Install the Microsoft DirectX driver. This driver 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 type boards

(DASH-16, CIO-DAS16/F, CIO-AD16, and CIO-DAS1602/12)


 
 

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 Timing File Reference Manual for details about the functions).

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.6 Cortex Software Setup and Program Execution

In all configurations, the first step is to download the latest VCortex distribution file from the Cortex web site. Using WinZip or PKUNZIP.EXE, unzip the distribution file. In the instructions below, it is assumed that the file was unzipped into the C:\VCortex directory.
 
 

3.6.1 Minimum Files Necessary to run Windows VCortex

VCSend.exe - the Windows Send program which communicates with a receive computer via a serial connection. (Replaces \remote32\wcsend.exe in the DOS version.)

VCSingle.exe - the Windows Send program which was modified so that it does not communicate with a receive computer. The serial communications and analog/digital capabilities 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 can be run from your desktop computer to test out timing files, etc. (Replaces \remote32\sgl32.exe in the DOS version.)

DXRecv.exe - the Windows DirectX Receive program. This program should be run from the receive computer.

cdas16.vxd - the device driver for the CIO-DAS16 type boards. If the send computer contains a CIO-DAS16 type board, this device driver programs the board to provide the timing for the Windows Cortex program.

randsd.vxd - the device driver that uses the Windows Virtual Timer Device to provide the timing. This driver is used if the user does not have a CIO-DAS16 type board. It can be used when the user only has the PIO24 type boards, or has no boards at all (i.e., the RANDOM_SPIKE_DEVICE).

cortex.cfg - like the DOS version of Cortex, this is the usual configuration file that Cortex reads in order to determine the user's hardware specifications, graphics specifications, etc. Note that some of the parameters must be set differently than in the DOS version. Refer to Appendix C for an example cortex.cfg file.

css_inc.h, encodes.h - like the DOS version of Cortex, these are the usual files required by Cortex during execution. Note that the css_inc.h file had to be changed so that the keyboard mappings are the Windows equivalents of the DOS key codes. Therefore, this css_inc.h must be the one used, not the old DOS version of the file.

msvcrt.dll, gcl52fw.dll - two DLLs that may be needed to run the Windows version on your computer. msvcrt.dll provides the Microsoft user interface computers. gcl52fw.dll provides the serial communication components.
 
 

3.6.2 Installing VCortex on a computer without any data acquisition boards, or a computer that only has PIO24 type boards

  1. Make a backup copy of your c:\windows\system.ini file. Then, edit your c:\windows\system.ini file as follows. In the [386Enh] section, add the line:


    2. device=c:\vcortex\vcwin32\randsd.vxd

    (assuming the zip file was unzipped to the c:\vcortex directory)
     

  2. Make a backup copy of your c:\autoexec.bat file. Then, edit your c:\autoexec.bat file so that it contains the line:


    3. SET CORTDIR=C:\VCortex\VCWin32

    (assuming that the zip file was unzipped to the c:\vcortex directory)

    This line will help VCortex find the css_inc.h file at all times.

  3. Reboot your computer.
  4. Check the cortex.cfg file in the \vcortex\vcwin32 directory on your send computer to make sure that it accurately reflects your devices and settings.
  5. 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 current directory.)
  6. Create shortcuts on your send computer desktop for the VCSend.exe and VCSingle.exe. Double-click on the shortcut to VCSingle.exe or VCSend.exe, depending on which version you would like to run.
3.6.3 Installing VCortex on a computer with a CIO-DAS16 type board
  1. The CIO-DAS16 vxd requires a reserved IRQ for its interrupt handling. Further, it requires that the IRQ is a number between 2 and 7, inclusive. Check your ControlPanel:System:DeviceManager:Computer:Properties to see which IRQ's are currently being used. If all IRQ's between 2 and 7 are being used by other devices, you will need to reconfigure your system so that one of these IRQ numbers are free. It is usually possible to reconfigure a device (such as a sound card), so that its IRQ is moved to a higher value.
  2. Make a backup copy of your c:\windows\system.ini file. Then, edit your c:\windows\system.ini file as follows.
    1. In the [386Enh] section, add the lines:


      2. device=c:\vcortex\vcwin32\randsd.vxd

      device=c:\vcortex\vcwin32\cdas16.vxd

      (assuming that the zip file was unzipped to the c:\vcortex directory)

    2. add the section:
[CORTEX]

CDAS16=5

(assuming that 5 is the free IRQ# in your computer)
  1. Make a backup copy of your c:\autoexec.bat file. Then, edit your c:\autoexec.bat file so that it contains the line:


    2. SET CORTDIR=C:\VCortex\VCWin32

    (assuming that the zip file was unzipped to the c:\vcortex directory)

    This line will help VCortex find the css_inc.h file at all times.

  2. Reboot your computer.
  3. Check the cortex.cfg file in the \vcortex\vcwin32 directory on your send computer to make sure that it accurately reflects your devices and settings.
  4. 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 current directory.)
  5. Create shortcuts on your send computer desktop for the VCSend.exe and VCSingle.exe. Double-click on the shortcut to VCSingle.exe or VCSend.exe, depending on which version you would like to run
3.6.4 Installing the DirectX Receive Program on the receive computer (Win95/98/2000/XP)
  1. Download and unzip the zip file on the receive computer. Again, I will assume that it is unzipped to the c:\vcortex directory.
  2. 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. The DirectX driver can be downloaded from the Microsoft web site (http://www.microsoft.com/windows/directx/downloads/default.asp). 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 7.3.)
  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.
  4. Download and unzip the latest VCortex distribution code from the Cortex web page. At a minimum, the \Wcortex directory must reside on the receive computer.
  5. 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.)
  6. 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 vcsend.exe on the send computer, the receive computer display should turn black.
3.7 Uninstalling Cortex

Refer to section 3.6 above, to see the changes to system.ini and autoexec.bat that were required to run VCortex. Comment out or remove these lines from system.ini and autoexec.bat, and then reboot your computer. 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, and autoexec.bat and system.ini files to reflect the proper paths.

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.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)

  1. regular polygon
  2. 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.

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

INNER. Circles and ellipses require an inner diameter.

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

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. 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

5

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 to 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 Windows version of Cortex, the MONITOR_TYPE must be set to VC.

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 VCortex
 5.1 The Main Menu Structure After the VCortex programs (VCSend or VCSingle) are started, the following window is displayed (see Figure 5.1). Along the top edge of the VCortex window is the Main Menu. This menu consists of 9 submenus: File, Edit, Options, Tools, Run, Clear, View, Window, and Help.

Figure 5.1 To select a menu option, click the mouse on the desired menu heading, and select an option from a drop-down menu. If you would prefer to use the keyboard, use the Alt key with arrow keys to traverse the menu, or use the Alt key with the underlined letters from the heading to select a particular submenu.

In this section, a brief overview of the Main Menu will be given. In subsequent sections, each submenu will be further expanded to include a description of each dialog box and parameter.
 
 

 5.1.1 The File Menu When the File heading is selected, the submenu consists of Load, Save and Exit. The Load pop-up menu consists of Item File, Condition File, Timing File, Saved File, LUT File, External Variables File, and Blocks File (see Figure 5.2). Selecting one of these options loads a file of that type into the program to be used for a trial. These operations can also be invoked without using the menu by using the corresponding shortcut listed on the right side of the dialog box.

Figure 5.2 The Save pop-up menu consists of Item File, Condition File, Saved File, LUT File, and Blocks File (see Figure 5.3). Selecting one of these options saves the file of that type that is currently loaded into the VCortex program memory, to the path specified in the resulting dialog box. If you load a file with the File->Load menu, and then make changes using the Edit menu, you will need to use this Save option in order for your changes to be saved to disk.

Figure 5.3

The Exit command is one of two ways to exit the program. (It is the same as Run->Stop) This option will close all windows, and exit the VCortex program. If you have made changes to any of the loaded components (items, conditions, LUTs, etc.) via the Edit menu, these changes must be explicitly saved with the File->Save menu. If the changes are not explicitly saved, the changes will be lost upon File->Exit.
 
 

 5.1.2 The Edit Menu When the Edit menu is selected, the submenu consists of Individual Item, Individual Condition, Timing File, External Variables, Fixspot Item, Reference Item, LUT, and Add an Item (see Figure 5.4). Any changes that you want to make to the files that are loaded must be done from this menu. Remember that any changes made will have to be saved using File->Save in order for the changes to remain after the program is closed.

The timing file menu has the option to modify or delete a loaded timing file (see Figure 5.4). Modify allows you to load a different timing file in the place of an already loaded one. Delete removes a timing file that was already loaded with File->Load->TimingFile.

Figure 5.4

The External Variables option has a sub-menu consisting of Generic Externs and Named Subsets. (See Figure 5.5) The Generic Externs option is used to modify the char, int, float, and long external variables, which have not been given names. The Named Subset option is used to edit the external variables by name.
 
 

Figure 5.5
 
 

 5.1.3 The Options Menu From the Options menu you can select Block/Repeat, or General Parameters. (See Figure 5.6) Block/Repeat has a pop-up menu with Sizing, Master Block, and Individual Block. Sizing is used to set the number of blocks and length of the circular buffers. Master Block is used to set block information and number of repeats. Individual Block is used to set number of trials and condition information for each block. The General Parameters option is used to set many of the parameters of the program.

Figure 5.6
 
 

 5.1.4 The Tools Menu From the Tools menu, the LUT menu has a pop-up with Set Number of Palettes and Activate. (See Figure 5.7) The Set Number of Palettes option is used to allocate space before you can load a LUT file. The Activate option is used to set which LUT is active on the graphics card of the subject's monitor.

Figure 5.7
 
 

 5.1.5 The Run Menu The Run menu consists of Start, Stop and Resume. (See Figure 5.8) The Start option is used to start running the trials, once the necessary files have been loaded and the parameters have been set through the menus. At this point, a dialog box will appear which allows you to specify the output data file name. After the output data file name has been set, the trials will begin. As a shortcut to this option you can press the F5 key to start the trials.

The Stop option is used to exit the program. It closes all the windows and exits. (It is the same as File->Exit.) The Resume option is used to re-start a trial in a block that was paused.

Figure 5.8

 5.1.6 The Clear Menu The Clear menu consists of External Variables, Blocking, and Histograms/Rasters. (See Figure 5.9) The External Variables->All option clears all the External Variables.

Figure 5.9

The Blocking option has a pop-up menu consisting of CONDstats, BLOCKstats, and Reset All. (See Figure 5.10) CONDstats clears all condition statistics. BLOCKstats clears all block statistics. Reset All resets all blocking variables that have been set for this trial.

 Figure 5.10

The Clear->Histograms/Rasters option clears all histograms and rasters. All spike information will be erased by selecting this option the next time that the Run->Start option is chosen.
 
 

 5.1.7 The View Menu The View menu consists of Results of most recent trial, Display an Item, Display a Condition, and Status Bar. (See Figure 5.11) The "Results of most recent trial" option has a pop-up with Codes and EOG values as sub-options. The Codes option will display a window containing the encodes that occurred during the most recent trial. The EOG values option will display a window containing the EOG values that occurred during the most recent trial. Display an Item can be used to display, on the subject's monitor, an item from the items file that was loaded. Display a Condition can be used to display, on the subject's monitor, a condition from the conditions file that was loaded. The Status Bar option is a simple toggle to specify whether or not the status bar should be present on the VCortex application window.

Figure 5.11
 
 

 5.1.8 The Window Menu The Window menu has options for Cascade and Tile. (See Figure 5.12) This adjusts the arrangements of the windows. Cascade aligns the windows on top of each other with only the heading visible. Tile arranges the windows so that they are all maximized in the space provided.

Figure 5.12
 
 

5.1.9 The Help Menu

The Help menu has one option: About VCortex. (See Figure 5.13) This displays the copyright and version information.

Figure 5.13
 
 

 5.2 The File Menu Dialog Boxes
 
 

5.2.1 File->Load->Item File

A standard file open dialog box will be presented. (See Figure 5.14) Select the items file that you would like to load for your experiment. Only one items file may be loaded into VCortex memory at a time. If you try to load another items file, it will overwrite the items in memory that were previously loaded.

Figure 5.14
 
 

 5.2.2 File->Load->Condition File A standard file open dialog box will be presented. (See Figure 5.15) Select the conditions file that you would like to load into your program. You may only load one condition file. If you try to load another conditions file, it will overwrite the conditions in memory that were previously loaded.

Figure 5.15

5.2.3 File-> Load ->Timing File

A standard file open dialog box will be presented. (See Figure 5.16) Select the timing file that you would like to load into your program. Unlike the items and conditions files, multiple timing files can be loaded into VCortex memory at the same time. As each timing file is successfully loaded, a message will appear to tell the user that the file was successfully loaded. The message will also provide the number in the Cortex State System (CSS) that it was assigned. This number is important since it is used in the TIMING column of the conditions file. It is also important since it is used to specify the timing file that is to be modified or deleted in the Edit->Timing File menu.

If the timing file was not successfully loaded, it means that the Cortex compiler found errors in the timing file. A message box will appear telling the user to check the cortexcc.err and VCortex.err files for more details. These error files can be found in the directory from which the timing file was loaded. Since these files are simple text files, they can be displayed with Notepad, or other word processing programs.
 
 

Figure 5.16

 5.2.4 File-> Load ->Saved File A standard file open dialog box will be presented. (See Figure 5.17) Select the "saved" file that you would like to load into your program. Saved files include all settings that were loaded into the program at the time it was saved via File->Save->Saved File. The saved file contains the names of the item files, condition files, timing files, the blocking parameters, and the general parameters for the particular experiment. Please note that the external variables file and their settings are not saved to the saved file.

Figure 5.17
 
 

 5.2.5 File-> Load ->LUT File A standard file open dialog box will be presented. Select the LUT file that you would like to load into local VCortex memory. Before you can select this option, you must allocate space for the number of LUTs that you want to load in one of two ways. The first way is by setting the LUT parameter in the cortex.cfg file. The second way is by using Tools->LUT->Set number of palettes. If you do not allocate enough space, a dialog box will appear that asks you to allocate space (see Figure 5.18)

Figure 5.18 If enough space is allocated a dialog box will appear, Figure 5.19.

Figure 5.19
 
 

 5.2.6 File->Load->External Variables File A standard file open dialog box will be presented. (See Figure 5.20) Select the external variables file that you would like to load into VCortex memory. An external variables file allows you to give a meaningful name and a value to the Cortex external variables. The values of these variables persist between trials. Their values can be changed in the timing file, or through the Edit->External Variables menu option.

Figure 5.20
 
 

 5.2.7 File->Load->Blocks File A standard file open dialog box will be presented. (See Figure 5.21) Select the block file that you would like to load into your program. A block file is used to load the blocking parameters that were set up and saved for a particular experiment. Unlike the File->Load->Saved Files option, the blocks file does not contain information about the items, conditions, timing files, or about the general parameters.

Figure 5.21
 
 

 5.2.8 File->Save->Item File A standard file save dialog box is presented. (See Figure 5.22) Select the path and filename that you want to use to save the items that are currently loaded in the VCortex memory. It is only necessary to select this option if the items were explicitly changed via the Edit menu.

Figure 5.22
 
 

 5.2.9 File->Save->Condition File A standard file save dialog box is presented. (See Figure 5.23) Select the path and filename that you want to use to save the conditions that are currently loaded into VCortex memory. It is only necessary to select this option if the conditions were explicitly changed via the Edit menu.

Figure 5.23
 
 

 5.2.10 File->Save->Saved File A standard file save dialog box is presented. (See Figure 5.24) Select the path and filename that you want to use to save all the files and parameters that are currently loaded into VCortex memory.

Figure 5.24
 
 

 5.2.11 File->Save->LUT File This menu option presents a dialog box that asks you which LUT you want to save. The range is specified to the left of the edit box in parentheses, and is determined by the number of LUT files that have been allocated with the Tools->Number of Palettes, or with the LUT parameter in the cortex.cfg file. (see Figure 5.25)

Figure 5.25 Once a LUT number has been specified, a dialog box will be displayed that allows you to specify the entry number at which you would like it to begin saving. (See Figure 5.26) The dialog box also contains a field to specify the file name of which to save the LUT file. You can enter the entire path in the box provided, or you may use the Browse button to traverse the file directory.

Figure 5.26
 
 

 5.2.12 File->Save->External Variables File A standard file save dialog box is presented. (See Figure 5.27) Select the path and filename that you want to use to save the External Variables file that is loaded into VCortex memory.

Figure 5.27
 
 

 5.2.13 File->Save->Blocks File A standard file save dialog box is presented. (See Figure 5.28) Select the path and filename that you want to use to save the block parameters that are loaded into VCortex memory.

Figure 5.28
 
 

 5.3 The Edit Menu Dialog Boxes

5.3.1 Edit->Individual Item

This menu option allows the editing of the items that were loaded from the items file. First, you must select the item to be edited. (See Figure 5.29) The range of valid items is given in the dialog box in parentheses. Cortex automatically starts the numbering at –4. –4 is the Background, -3 is the Fixation spot item, -2 is the Reference field, -1 is the Reference point, and 0 is the Play item. All other items loaded by your item file will begin at 1.

Figure 5.29

A property sheet is displayed with tabs across the top for type, color, position and window size. The type page is complex because the value of the type combo box affects the display of that page. If you would like to change the item type, select the desired type from the drop-down list. Depending upon the item type, the other parameters on the page will change to match that item type. Note: The changes made to these items only change the copy in local memory and will not be saved to the item file unless you select File->Save->Item File.
        1. Item Type
Annular Ellipse (See Figure 5.30)  

Figure 5.30

Annulus (See Figure 5.31)
 
 
 
 
 
 

Figure 5.31

Ascii (See Figure 5.32)

- Ascii Character: the character that you want to display

Note: In the items file you may enter values for height and width. These variables are misleading because you are not able to change the size of the character. A standard font is used for all character items. These variables control the size of a square within which the character will appear.

Figure 5.32

Bitmap (See Figure 5.33)

- File Name: the name of the bitmap file that will be loaded. You may enter the entire path in the space provided or you can use the Browse button to traverse the directory.

Figure 5.33

Circle (See Figure 5.34)

Figure 5.34

Cross (See Figure 5.35)
 
 

Figure 5.35

Ellipse (See Figure 5.36)

Figure 5.36

Movie (See Figure 5.37)

- File Name: the name of the movie file that will be loaded. You may enter the entire path in the space provided or you can use the Browse button to traverse the directory.

Figure 5.37

Polygon (See Figure 5.38)

Figure 5.38

Rectangle (See Figure 5.39)

Figure 5.39

String (See Figure 5.40)

Figure 5.40

5.3.1.2 Item Color (See Figure 5.41)

Enter the red, green, blue (RGB) values for the item's color. (see Figure 5.41) These values must be from 0 to 255. You can also press the Choose Color button to view and set the colors.

Figure 5.41

In the color dialog box which appears when you use "Choose Color", you can click the mouse on a particular color and the RGB values of that color will be returned to the color property page. You can also choose Define Custom Color to choose colors that are not displayed in this dialog box. (See Figure 5.42)

Figure 5.42

5.3.1.3 Item Position (See Figure 5.43)

Item positions are used to determine where the center of the item will be located on the subject's display. The values are in degrees of visual angle (dva). Item positions assume that the center of the subject's display has the coordinate (0, 0).

X-Position: a positive value moves the item right, and a negative value moves the item left.

Y-Position: a positive value moves the item down, and a negative value moves the item up.

Figure 5.43
        1. Window Size (See Figure 5.44)
Bitpan - "Bitpannable" means that you plan to pan objects around inside a stationary window on the screen. If "No" is chosen from the Bitpan listbox, the object will not be bitpannable. If "Manual" is chosen from the Bitpan listbox, this means that the object is bitpannable, that Cortex should utilize the window size you specify. In this case, Cortex will replicate the object 4 times, to give you more object to pan around with. If "Automatic" is chosen from the Bitpan listbox, it means the that the object is bitpannable, but Cortex won't replicate it. Because of this, the window size is simply the size of the object, and cannot be specified. If you use Manual option, 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 Automatic if you have an extremely large object.

Window - As mentioned above, the Window Size can only be set if the Bitpan parameter has been set to Manual. If the Bitpan field is not set to Manual, the height and width boxes will be grayed out. 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.

Figure 5.44
 
 

 5.3.2 Edit->Individual Condition This menu option allows you to edit the conditions that were loaded from the conditions file. (See Figure 5.45) First, you must select the condition to be edited. The range of possible items to select is given in the dialog box in parentheses.

Figure 5.45 After the condition number is entered, and OK is pressed, a dialog box will appear which allows you to edit the conditon. (See Figure 5.46) The entry fields labelled Test0 through Test9 represent the "test screens" (i.e., TEST0 through TEST9 in the conditions file). See Section 4.3 of this manual for more information about test screens. For each test screen, the items that you want to appear together should be on the same line. The maximum for each line is 16 items, and each item number must be separated by a space.

The background item number specifies the item to use in the background of the subject's display during the trial. Only the color of the item, as specified in the RGB columns in the items file, will be used

The time sequence number refers to which timing file (state system file), you want to run with this condition. The timing files are imported separately (with File->Load->Timing File), and are referred to by their number.

The fixspot item number is the number of the item that will appear as the fixation point for that condition.

If you want to use a color palette, specify a path and file name in the color palette filename entry field. You can also use the browse button to traverse the file structure for the file you want to use.

The possible choices for the trial type can be selected from the list box. This parameter is currently not used, except as the expected_response field in the output data file header.

Note: The changes you make to these conditions are only changes to local memory and will not be saved to the condition file unless you select File->Save->Condition File.
 
 
 
 

Figure 5.46
 
 

 5.3.3 Edit->Timing File->Modify This menu option allows you to load a different timing file in the place of a timing file that has already been loaded. (See Figure 5.47) The possible range of numbers to choose from appears in parentheses, and is the number of timing files that are already loaded. The timing file number is assigned when the timing file is loaded via File->Load->Timing File.

Figure 5.47

After the number of the timing file has been entered, a standard file open dialog box is displayed to allow you to specify the new timing file to load into that place. (See Figure 5.48)

Figure 5.48
 
 

 5.3.4 Edit->Timing File->Delete This menu option allows you to remove a timing file that has already been loaded. (See Figure 5.49) Specify the timing file number to be deleted. The range of valid timing file numbers is shown in parentheses. The timing file number is assigned when the timing file is loaded via File->Load->Timing File. When the timing file is deleted with this menu option, any timing files that had been loaded after this file, will move up to fill the empty spaces. For example, if you have five timing files loaded, and you delete timing file #3, the timing files loaded as #4 and #5 would be reassigned timing file numbers 3 and 4.

Figure 5.49
 
 

 5.3.5 Edit->External Variables->Generic Externs This menu option allows you to edit the external variables. (See Figure 5.50) Each type external variable has its own page in the dialog box, and the type is specified by the page tab. The types that you can modify are char, int, long, and float. You can select values for variables 0-29 of all four types.

Figure 5.50
 
 

5.3.6 Edit->External Variables->Named Subsets

This menu option is very similar to the Generic Externs option, except the user-defined names of the external variables are displayed. (See Figure 5.51) The user must create an external variables file of a specific format using #SET lines, in order to name the external variables. (See the demo file named \demos\misc\externsw.tim.) The file must then be loaded with the Load->External Variables File menu, before the names will show up in the Edit->External Variables->Named Subsets dialog box. Once the external variables file has been succesfully loaded, you are able to then use these names in your timing files. If you select this menu options without already loading an external variables file, you will be prompted to first load a file.

Figure 5.51

If an external variables file has been loaded, a dialog box appears which displays a Name & Alias box that contains all the external variables that are loaded. (See Figure 5.52) By clicking on the down arrow of the listbox, you will be able to scroll through all the named external variables. Once you select the one to be edited, the appropriate entry box will be displayed to let you edit that external variable.

Figure 5.52

The contents of the box depend on the type of the variable. (See Figures 5.53 - 5.57)The types that you are able to edit within this box are int, char, float, long and pchar (string).

Figure 5.53

Figure 5.54

Figure 5.55

Figure 5.56

Figure 5.57
 
 

 5.3.7 Edit->Fixspot Item This menu option allows you to edit the item that will be used as the fixation point. This dialog box is the same as the Edit->Individual Item menu option discussed in section 5.3.1. 5.3.8 Edit->Reference Item This menu option allows you to select which item is the reference item. (See Figure 5.58) The range of possible reference items is specified in the dialog box in parentheses. Five of the 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 the 'Rfield' item (item number –2) as the reference point. 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. You are also able to specify any of the items that you loaded from the item file as the reference item.

Figure 5.58
 
 

 5.3.9 Edit->LUT This menu option allows you to edit the contents of a lookup table. (See Figure 5.59) First, select which lookup table to edit. The range is specified in the dialog box in parentheses.

Figure 5.59

The LUT Edit dialog box which appears, allows you to change the RGB values for 256 LUT entries. (See Figure 5.60) The LUT Entry # will start at 0. The Red, Green, and Blue values correspond to that entry number. When you are finished editing that LUT entry, you can select Next>> to go to the next LUT entry. If you want to go to a particular LUT entry from this point, you can enter a specific LUT entry number in the LUT Entry # field, and press Update, to display the RGB values for that entry number. The entry number, red value, green value, and blue value must be between 0 and 255. When you are finished with all of the changes for that LUT file, press ‘Exit and Save all Changes’ to store all the new values to memory. If you do not want to save your changes press ‘Exit and Do NOT Save Changes’. Note: The changes you make to this LUT are only changes to local memory, and will not be saved to the LUT file unless you select File->Save->LUT.

Figure 5.60

After selecting ‘Exit and Save all Changes’, you will be reminded that these changes are only made to local memory. (See Figure 5.61)

Figure 5.61
 
 

 5.3.10 Edit->Add an Item This menu option allows you to add an item to the end of the list of items that are loaded into memory. The dialog box is the same as for editing an individual item, so see "Section 5.3.1 Edit->Individual Item" for more details. Note: The added item will not be added to the item file unless you choose File->Save->Item File. 5.4 The Options Menu Dialog Boxes

5.4.1 Options->Block / Repeat->Sizing

In this dialog box, you change the number of blocks, and the lengths of the circular buffers for each block and condition. (See Figure 5.62) All values must be greater than or equal to zero. Number of Blocks: The number of distinct blocks that should be created. The default is one block.

Length of circular buffer for each block: The circular buffer contains one-character codes representing the result of each block. Since this is a circular buffer, if you do not make this buffer large enough, the contents could be overwritten. For example if you run 20 blocks and the size of this buffer is only 5, it will be overwritten 4 times. The contents of this buffer can be viewed in the status window during the trial beside the heading Bbuf.

Length of circular buffer for each condition: This buffer contains one-character codes representing the result of each trial. Since this is a circular buffer, if you do not make this buffer large enough, the contents could be overwritten. For example if you run 20 trials and the size of this buffer is only 5, it will be overwritten 4 times. The contents of this buffer can be viewed in the status window during the trial beside the heading Cbuf.

Figure 5.62
 
 

 5.4.2 Options->Block / Repeat->MasterBlock This dialog box consists of two pages: Options and More. (See Figure 5.63) The Options page contains the most frequently used Master Block options, while those on the More page contain the more obscure ones. For those of you who are familiar with the DOS version of Cortex, the "More" options would only be visible if the Block->Sizing menu had the "Menu Length" parameter set to FULL. 5.4.2.1 Options Number of repeats: The number of times that the blocking structure should be repeated.

Maximum number of blocks: Specifies the maximum number of blocks that can be run.

First block number: the first individual block that will be run.

Last block number: the last individual block that will be run.

Block Order: Specifies the order in which the blocks should be run. The choices are as follows:

Incremental: The blocks to be run will follow in sequential order (i.e. 1,2,3...). If Delayed_Retry is selected for On_Error, there may be discontinuities (e.g. ...8,9,3,7) if the block which needs to be repeated has a lower block number than those which would normally be run next.

Random without replacement: Guarantees an even distribution of the number of blocks over the maximum blocks, but randomizes the order of presentation.

Random with replacement: The blocks will be run in completely random order.

 Clear block circular buffer when: This refers to the automatic resetting of the circular buffers (recency tables) and the num_correct and num_errors counters they contain. Although BLOCKstats is updated correctly, CORTEX uses it to determine the order of blocks for the next trial. The default for this variable is "When block changes". Possible values are: Manual: CORTEX never clears BLOCKstats, so the user must do so manually.

At start: Cortex clears statistics when Run->Start is chosen, but not upon Run-> Resume.

When block changes: Cortex clears statistics when a block (correct OR error) has finished.

When repeat all blocks: Cortex clears statistics when the repeat counter is incremented.
&nbs