A
Reference Manual
for the
Runtime and Summary Programs
for
Classical Conditioning
by
Dave Lavond
with assorted advice and interference from
Christy Logan
Dragana Ivkovich
Dick Thompson
Judy Thompson
Revised 31 March 1994
Revised 1 September 1995
Revised 21 February 1997
Revised 6 March 1997
Revised 30 December 1997
Revised 29 August 2000
 Copyright 1995 - 1997 Dave Lavond. All rights reserved.
Table of Contents
1 Who is this for?
2 History of These Programs
3 About Forth Computer Language
3.1 Origin and General Features
3.2 Dictionary Structure
3.3 Dictionaries
3.4 Words in the Dictionary
3.5 Don't Forget to Forget
3.6 Manipulating the Runtime and Summary Programs
4 The Forth Editor
4.1 The Summary Auto(matic Parameter) Function
4.2 The Search Function
4.3 Other Editor Commands
4.4 The Editor is used by Runtime and Summary Options
4.5 The Runaway Printer
5 The Setup
5.1 What You Need
5.2 Legal Issues
5.3 Original, Working and Backup Copies
5.4 Booting the Software
5.5 Making a Turnkey System
5.6 Data, Library and Graphics Disks
5.7 Optimizing Data Disk Storage
6 The Runtime Program
6.1 The Menu and Options
7 Runtime Option 0: Exit Runtime, Enter Forth
8 Runtime Option 1: Run
8.1 Interpreting the Graphics Display
9 Runtime Option 2: Comment
10 Runtime Option 3: Changing the Run Default
11 Runtime Option 4: Intertrial Parameters
12 Runtime Option 5: Intratrial Parameters
13 Runtime Option 6: Instructions for User Trial Sequence
14 Runtime Option 7: Softswitches
15 Runtime Option 8: Run Summary Program
15.1 Overview of Running a Session
15.2 Things You Need
15.3 Defaults
15.4 Review of Forth Classical Conditioning/IBM-PC Interface
15.5 To Run (or "A Sample Run")
15.6 Data Storage
16 Runtime Offline Data Collection
17 Compiling Your Own Runtime
18 Changing the Runtime Default Choice
19 Changing the Runtime Default Drives
20 Changing the Runtime Default Directory
21 Runtime and Summary Program Interactions
22 The Summary Program
22.1 General Overview
22.2 Using the Summary Programs
23 Summary Option 0: Exit Summary, Enter Forth
24 Summary Option 1: Analysis from Raw Data Stored on a Data Disk
25 Summary Option 2: Analysis from Data Stored on a Library Disk
 Copyright 1995 - 1997 Dave Lavond. All rights reserved.
26 Summary Option 3: Analysis from Data Stored in RAM
27 Summary Option 4: Analyze with No Printout
28 Summary Option 5: Creating a New Trial Type Table
28.1 The Hard Way
28.2 The Easy Way
28.3 Limitations of All Methods
28.4 The Meaning of Numbers
29 Summary Option 6: Display Contents of Library Disk
30 Summary Option 7: Load RAM with Library Calculations
31 Summary Option 8: Graphics Review of Data Disk (w/Laser Printer for Pictures)
31.1 To Start
31.2 To End
31.3 General Control
31.4 Moving from Trial to Trial
31.5 Averaging Data
31.6 Average a Range of Trials
31.7 Average a Range of Trials by Hand
31.8 Average Several Trials by Hand
31.9 Average Several Consecutive Trials
31.10 Averaging Averages
31.11 What are All Those Numbers?
31.12 A Note about the Cursor Display
31.13 Printing the Picture to a Laser Printer
32 Summary Option 9: Summary Program Parameters for Analysis
33 Summary Option 10: Save RAM Calculations to Library Disk
34 Summary Option 11: Serial Communications
35 Summary Option 12: Analyze Interspike Data
36 Summary Option 13: Graphics Review with Cross-Correlations
37 Summary Option 14: Z-score Analysis
38 Directions for a Typical Summary
38.1 Some General Comments to Keep in Mind
39 Explanation of Summary Printout
39.1 Details on A/D (Eyelid) Analysis
39.2 The Header
39.3 Bad Trials
39.4 CR Trials
39.5 Criterion
39.6 Session Summary
39.7 Block by Block Analysis
39.8 Details on Unit Analysis
40 Askiing
41 Adlibbing
42 Troubleshooting
42.1 The Runtime Program Can't Find the Menu File (or "Menu No file")
42.2 The Runtime Program Can't Find Disk (or "Data No File")
42.3 The Runtime Program Crashes during the Intertrial Timing
42.4 The Runtime Program Crashes during the Intratrial Timing
42.5 The Runtime Used to Give Stimuli but Now it Runs Trials Without Stimuli
42.6 The Summary Printouts are Not the Same
42.7 The Summary Printout is Not What I Remember the Runtime to be Like
42.8 The Summary Printout Prints Weird Characters and Ejects Many Pages
42.9 The Summary Prints out Only Zeros
42.10 The Summary Does Not Ask for any Parameters (e.g., number of trials ...)
42.11 The Summary Loads Parameters (e.g., number of trials ...) that I Don't Want
43 Tricks
43.1 Inversion
43.2 Invert
43.3 Condensed Printing on a Laser Printer
43.4 Measure CRs only on Trials in Which a CR Occurred
43.5 Measure UCRs only on Trials in Which a UR Occurred
43.6 Enough Already
43.7 A Block of This, A Block of That
44 Glossary
45 Bibliography
 Copyright 1995 - 1997 Dave Lavond. All rights reserved.
1
1 Who is this for
This document is not for someone who has never used the programs. It is for those persons who already have been
shown how to use the Runtime and Summary programs. It is intended as a reference manual to give detailed instruction in the
normal uses of these programs, and to give an intermediate to advanced level of understanding of the programs so that you can get
more out of them  so you can more efficiently use them, so you can tailor available functions to your purposes, so you can
implement functions that are new to you, so that you can manipulate the programs in ways not envisioned.
It would be unrealistic for you to expect that you can read and absorb in one sitting all this material that follows. I
recommend reading as much of the material as possible and not worrying about fully understanding all passages. Some things
won't make sense until you need to know them. After reading the manual and using the programs for some time, read the manual
again.
This documentation also does not go into detailed Forth programming. That statement may surprise you after you have
read this reference manual. But I have not discussed, for example, the Forth stack structure, Forth compiler versus interpreter
(this is not the interpreter encountered in the Runtime operation), machine language coding, Forth programming structures (like
loops or if-then constructs), special structures (like resolutions), or the exact operation of any code used in the Runtime or
Summary programs. In those respects this manual ranges from no information to cursory information. The glossary mainly
consists of words you can use to manipulate these programs, rather than rewriting them or using them at a primitive level. The
glossary does not include explanations of fundamental Forth words like DUP or SWAP.
To learn more about Forth I recommend the book Mastering Forth by Martin and Tracy. To learn more about this
particular implementation of Forth for the IBM-PC I recommend the documentation that comes with the language. To learn more
about good Forth programming style I recommend Brodie's book on Forth style [i.e., how to write code that is readable, efficient
and documented] titled Thinking Forth (this is an excellent book). To learn more about IBM PC machine language programming I
recommend The 8086 Book, and about machine language programming in Forth I recommend the documentation that comes with
the language. To learn more about the hardware I recommend Eggebrecht's Interfacing to the IBM Personal Computer, and to
learn more about our particular interface I recommend the descriptive article by Lavond and Steinmetz (1989) An inexpensive
interface for IBM-PC/XT and compatibles, Behavior Research Methods, Instruments & Computers, 21, 435-440
(c) copyright 1995 Dave Lavond. All rights reserved.
2
2 History of the Forth Runtime/Summary Programs
Today (revised 31 March 1994; originally 11 March 1994) is too far away to remember all the details and be sure of
accurately reconstructing the actions taken in producing these programs. For what it is worth, I will leave out some of the details
and the following sounds about right. Although this is meant as a personal and informal recollection, numerous individuals have
been kind enough to embellish and make corrections.
As far as I know, the computerized analysis of classically conditioned rabbit nictitating membrane data was first done in
R.F. Thompson's laboratory using a PDP-12 computer, costing $100,000 with hard disk and accessories. The training sessions
were presumably controlled by some form of solid state electronics around 1971, and the data was collected to 4 channel, reel-toreel tape, which was later played back to the PDP-12. Originally, the PDP-12 system was online, running 4 chambers, with
programs written by Dick Roemer (1975). Thompson believes this was the first online system for classical conditioning. However,
Thompson found that the PDP-12 system would crash several times a day, causing the loss of data. For this unreliability, the
system was converted to an offline system of analysis from tape.
Thompson's interest in classical conditioning began in graduate school at the University of Wisconsin from his major
professor W.J. Brogden who did classic work in animal conditioning and who trained with W. Horsley Gantt, who in turn trained
with Pavlov. Another of Thompson's professors at Wisconsin, David Grant, had trained with Ernest Hilgard and was a major
figure in human eyeblink conditioning. Thompson and Gormezano were fellow graduate students (mid 1950s). Gormezano
trained with Grant. Later, Thompson was much impressed with Gormezano's development of the rabbit eyeblink-nictitating
membrane conditioned response preparation (early 1960s), a view reinforced by the arrival of Mike Patterson in Thompson's lab
as a postdoc. Patterson got his Ph.D. degree with Gormezano. Gormezano himself later came to the Thompson laboratory as a
visiting professor. [I thank Dick Thompson for this paragraph straightening out the origins and much of the early details.]
My belief is that prior to this, classical conditioning data was collected on polygraph paper and analyzed by hand. The
Thompson laboratory ran its computerized experiments with relays and with Coulbourne or Grason-Stadler solid state modules.
[As an aside, many people tried to computerize their experiments. My graduate advisor, Don Meyer, gave up trying to
computerize his monkey experiments in the 1960s and even published an article on the experimental problems that were
introduced. Meyer never had a computer in his laboratory after that. One advantage of his failure with computers is that Meyer
always stressed the importance of watching the behavior of your subjects; for example, the problems with the computer (besides
breaking down) included the difficulty in setting up experiments that did not have problems with stimulus-response contiguity. But
as far as computers go, Meyer was handicapped by the state of the technology at the time. Today, the computer is so familiar that
we can hardly imagine a time or experiment without it. Nevertheless, one should heed Meyer's lesson: don't just put your animals
in the box and leave  watch your animals. You might learn something from them.]
At some point, the hardware necessary for running the experiments was improved by a system designed at the shop of
the Department of Psychobiology, University of California, Irvine. This consisted of a rack-mounted unit with rotatary thumb
switches for selecting interstimulus intervals and durations of tone and airpuff. In addition, a programmed ROM module for trials
fit into a plug, allowing for normal delay conditioning, trace conditioning, or unpaired conditioning.
The next improvement in hardware for actually running the experiments seems to be Solomon's KIM-1 (6502)
microprocessor based system, which interfaced into the various TTL equipment for tones and airpuffs (Solomon & Babcock, 1979;
Solomon, Weisz, Clark, Hall & Babcock, 1983). By playing a tape recorder into the KIM it could be loaded with different training
parameters. The fundamental timing algorithm was based on the execution cycles for 6052 instructions multiplied by the KIM-1
computer clock rate. [This published code is not entirely correct. See below for an explanation.] Data was still collected to a 4
channel tape recorder, and analyzed by the PDP-12.
When I came into the Thompson laboratory in the summer of 1980, each of these different systems was still in use, and
a new PDP-11 computer was in use and just finished being programmed for analyzing data from the 4 channel tapes. The maker
of the PDP computers, Digital, was of no help in converting the PDP-12 code into PDP-11 code. The PDP-12 system was later
sold for $500 to someone to use for spare parts. [A.J. Annala tells me that initially the even numbered PDP computers were sold
commercially while the odd numbered PDP computers were developmental in-house models. Eventually the odd numbered
computers were also marketed. This explains why the PDP-11 computer was a newer computer than the PDP-12.]
At some point, I designed and built two small 6502 based computers and interfaces. The software was based on the
timing algorithm used by Solomon and colleagues. My classical conditioning programs were on ROM, rather than KIM-1 tape
recorder, and different types of training sessions were selected by switches. Furthermore, minor changes in the training
parameters could be altered using front switches. Still, the data was collected to the 4 channel tapes. In order to program the
ROM I used a Commodore VIC computer with a 6502 assembler and a ROM burning interface card. [If you wish to try this
approach yourself I give you this warning. I had to reprogram the ROMs several times because of problems with the timing values
discovered by myself and, in at least one instance, by Laura Mamounas. The code published by Solomon is not completely
accurate, which I verified by comparing the published code with the actual working code in the laboratory machines.] The units
worked but they soon became obsolete. I also used the VIC computer to learn the Forth computer language. Forth had the
advantages that it took relatively little computer memory, was extensible and highly flexible in compilation, allowed easy interface
with machine language code, was well documented with many books on the market and there were a number of suppliers of
implementations of Forth.
Currently Forth has declined in popularity, perhaps only of interest to those interested in robotics or in archaic
languages. Today, memory and computer speed limitations are no longer such important considerations that bore Forth. Now we
find that popular programming languages like C incorporate many of the powerful programming features of Forth, such as
combined interpreter and compiler functions, and integration of C programming with assembly language programming. The
popular object oriented programming, whereby a data record can incorporate many different data types, is a subset of Forth’s
powerful extensibility  the ability to create new programming structures. For example, although Forth originally did not come
with a case command (in case of 1 do this, in case of 2 do that, etc.) that programming structure can be created in Forth, which I
have done in more recent updates. Nevertheless, the primary reason to remain with Forth is that the routines are already written
and they work with very simple (standard speed, low memory) computers.
With the entry of Joe Steinmetz as a postdoc in the laboratory (1984?) came the on line computer system. Coming from
Patterson's laboratory at Ohio University in Athens, Ohio, Steinmetz used an Apple II (6502) system there that added much more
(c) copyright 1995 Dave Lavond. All rights reserved.
3
flexibility in programming the delivery of trials and stimuli, collected the data to floppy disks, analyzed the data on line and gave
an on line display of the last trial's data, and also allowed for later analysis off line. Polygraph records and tape recorders became
obsolete.
The system used in Patterson's laboratory came from Gormezano's laboratory. There, Scandrett and Gormezano (1980)
developed a computer language called FIRST (as a play on words for the already developed computer language called Forth, for
fourth generation language) and an interface card that controlled timing and stimuli and also had a specialized floating point
semiconductor. The fundamental timing algorithm was based upon a floating point processor and an 8253 Programmable
Interval Timer. [The programming for the latter was described in Intel manuals, and numerous interfacing books described its
use, including one called The 8253.] There was a dispute between Gormezano and Scandrett as to who actually owned the FIRST
language. The interface card was needed for running the FIRST computer language because of the floating point chip, which got
hot enough to make toast. At this point in time, it is unclear to me how much programming or reprogramming was done in
Patterson's laboratory.
Thompson bought an Apple computer to use Tim Teyler's software for hippocampal slices. A few persons spent a lot of
time playing computer games on it. Somehow, Steinmetz convinced Thompson to upgrade his classical conditioning chambers
with an Apple and the FIRST system. I was not involved in the request or the decision so I do not really know how this came
about.
Steinmetz and I set out to create our own system for several reasons. I wanted to be independent of anyone else and I
wanted a system that did what the PDP-11 system did for analysis and display. I also had a lot of experience programming 6502
machine language, and in designing 6502 computers and interfaces. I had also learned Forth programming language previously.
I also did not like that FIRST could only work on a computer with a FIRST card inside, meaning that you could not analyze on a
different computer, and that the cost of FIRST was very expensive. Plus there was the problem of who owned FIRST. Since
Steinmetz was familiar with Gormezano's and Patterson's code (and I believe he wrote much or all of Patterson's code) some
operations, like not counting conditioned responses immediately after conditioned stimulus onset, were implemented.
I designed and built the interface card (subsequently referred to as the "Forth card" although the card was not required
to actually run Forth) using my many books on 6502 computers and interfaces, and purposefully used the simplest TTL chips to
avoid using a 8255 chip so that we were not anything like the FIRST board. The thing that actually made the FIRST board
unique, however, was a floating point chip that was necessary to run FIRST. The fundamental timing algorithm was based upon
the 8253 timing chip. I wrote the Runtime program because it required 6502 and Forth code, and Steinmetz wrote the Summary
program which only required Forth code. It was intended that the Runtime and Summary programs would be independent of each
other in that the parameters for analysis were not carried over from Runtime into Summary. Part of the reason had to do with us
wanting to have the option of reanalyzing data with new parameters (in Summary). Part of the reason had to do with not wanting
to place the parameters on the data disk because in the FIRST system a special disk, called the "parameter packer", was required
and a pain to use to do this function.
After a few years Thompson (1986?) switched over to an IBM system which required us to do everything over again.
Well, almost but not quite. I had to learn 8088 machine language, and I had to learn some variations of Forth because the IBM
version of Forth (made by the same company as the Apple version) operated a little differently. The fundamental timing algorithm
(for intratrial events) was based upon the 8253. We also made use of the internal IBM clock to implement the intertrial interval
timing. In addition, I incorported the 8255 Programmable Input/Output chip. [As with the 8253, there are numerous first and
second source documents describing its use and programming.] All of the machine language in the Runtime program was newly
written. Most of the Forth was transported without any problem, but I ended up writing new or improved Forth code for the
Runtime. I also had to write all the routines for drawing data to the screen because, unlike the Apple version, graphics was either
not available for the IBM version at that time, or what was available was not very fast. Almost all of the Summary Forth code was
transported, except for some minor things like "dark" erased the screen in IBM Forth and some other word, which I now forget,
did it in Apple Forth. We published the interface and its necessary machine language code (Lavond & Steinmetz, 1989).
Since then, I have rewritten nearly or all of the Forth code in the Summary program. This was to make the code more
efficient and easier for me to follow. Operationally, the code does exactly what it did before, except where I have written new
features, corrected bugs, or in a few places modified the way the code actually operated. The Runtime has also been substantially
rewritten for these reasons. At one point, I eliminated all variable redundancy between the Runtime and Summary programs.
Except for a few variables like TTARR or names of some operations like SESINFO, none of the original Steinmetz code remains
in today's version. I presume that Steinmetz has done the same with my code because we no longer update each other or try to
keep the systems compatible.
In the last few years there have been very few major changes. In fact, any data collected with previous versions can be
reanalyzed with current versions. The last really big change was to add Runtime routines for collecting more unit data channels
(now up to 4 unit channels). For that I also had to write a new display for the data. Most of what I write now are minor features
or minor changes in analysis, usually at someone's request, or new adjunct programs like the z-score analysis or methods to create
ascii files of data and library disks. While the C programming language has improved substantially over the years to include many
Forth features, and could be used to write classical conditioning software, I certainly have no desire to do so, and I suspect that
our Forth interface and programs will be around for a while longer because they work so well and so cheaply with a basic 8088based IBM computer with very little memory (256k) and simple floppy disks. I have lost track of persons who use either the Apple
or IBM versions of our classical conditioning software. I believe they are the following: myself, Thompson, Steinmetz, WoodruffPak, Logan, Solomon, Berger, Madden, Dawson, Swain (Greenough), and Nordholm.
The version of the Runtime software that this manual is based on was compiled 29 October 1992. The Summary
program has been updated as recently as 14 March 1992, but the Summary program does not have a version date. Since I wrote
the Runtime source code I kept a record of all changes (showing original date for the code and the most recent changes), but
Steinmetz did not keep records of versions of the Summary program. I have been keeping some records of changes to the
Summary since it is almost all my code now, but I do not have dates for the original inception of the codes.
As far as I know, and I have no intention of spending my time trying to find out, there is no detailed, published
description of how the classical conditioning procedure is actually implemented, with all its assumptions and methods of
calculations (for example, "bad trials", "criterion level", "trials to criterion", "baseline"). A graduate student of John Harvey,
for example, thought we were doing something funny with our analysis because we declare a "bad trial" whenever movement in
(c) copyright 1995 Dave Lavond. All rights reserved.
4
the first 25 msec of the CS period exceeds the criterion level. The accusation was that we were purposely excluding learned
responses to support the role of the cerebellum as essential for classical conditioning. Since Harvey uses the Gormezano FIRST
system, we pointed out to the student that he was apparently unaware of the action of the program he himself was using.
There are several articles that have been particularly helpful to me in aspects of this implementation of classical
conditioning. The single most important one is by Thompson, Berger, Cegavske, Patterson, Roemer, Teyler and Young (1976) for
its descriptions of timing parameters and data analysis with z-scores. Also of interest are Berger, Latham and Thompson (1980)
and Berger, Rinaldi, Weisz and Thompson (1983) for unit analysis and cross-correlations. We describe data collection and
analysis with z-scores and cross-correlations in our study of the effects of cerebellar lesions on nictitating membrane and eyelid
EMG behavioral measures (Lavond, Logan, Sohn, Garner and Kanzawa, 1990).
(c) copyright 1995 Dave Lavond. All rights reserved.
5
3 About Forth
WARNING If you are just starting to use the Runtime/Summary software then skip this section and go to the Setup section. The
information in this section is intended for those who want to hijack these programs for their own nefarious purposes. You may never
be so depraved.
The following is a very brief explanation of how Forth operates and its use in the Runtime and Summary programs. I
will not write a book on Forth programming here. To get a better appreciation of Forth programming I recommend you pick up a
book on Forth programming, like Martin and Tracy's Mastering Forth.
3.1 Origin and General Features
Forth was invented as a real time language to control the positioning of astronomical telescopes. It may still be favored
for certain robotics applications. Its name comes from the idea that it was a fourth generation computer language. Since the
Forth compiler was originally written using Fortran, the name was abbreviated from Fourth to Forth because of the restriction on
file name length. Forth was designed to operate in the very small memory spaces that were available at the time. In addition, it
was designed to easily interface with machine language routines. Forth itself was conceived as an intermediate language between
machine language and languages like BASIC and Fortran. For simplicity, Forth's computational operations were originally
restricted to integer operations on 8 and 16 bit signed numbers. This had the additional advantage that computations were very
fast in comparison to floating point operations. The restriction on number size led to a number of clever ways of multiplying and
dividing numbers to get around these limitations. However, double numbers (32 bit numbers) were later introduced, and floating
point was eventually added as an extra option. Most of the computing operations in the Runtime and Summary programs use only
byte (8 bit), single (16 bit) and double (32 bit) sized numbers. For computing z-scores in the Summary program, however, I had to
use floating point numbers because the sums of x and sums of x2 get too large.
3.2 Dictionary Structure
Forth operates like a dictionary. It comes with a common set of defined operations agreed upon by Forth users. Our
version is Forth-83; Forth-79 was the first conventionally agreed version of Forth. I do not know the latest version. To see the
Forth dictionary, including the common words and the words used for the Runtime, you can do the following. Boot up DOS, then
type forth<return> to start the Runtime program. When you see the Forth Runtime Opening Menu with its options, type 0 (that is
the number zero, not the letter o) and you will exit the Runtime program. type flush<return> to close all files and you should see
the reply “ok” (or "ready" in some implementations).
Every time you press <return> you should see "ok". That is how you know that you are in Forth. To see the dictionary
type forth words<return> or simply words<return>. The screen will fill up with words and scroll until it has shown you every last
word. There are a lot of them. A handy feature of this implementation of Forth is that you can pause the view of the dictionary by
pressing any key once. Pressing (almost) any key again allows the dictionary view to continue. Press a key again and there is
another pause, press (almost) any key again and the scrolling will continue. This is handy to know so that you can stop to read
some of the words before they scroll off the top of the monitor screen. The one exception is if the second key pressed is a <return>
key, then no more words will be shown. There is a Forth word called nuf? which controls this pausing function. We use nuf? in a
few places to control our programs. For example, in the Summary program when analyzed data is being printed out, if you press a
key then printing will stop until you press (almost) any key once more. [By the way, it does not have to be the same key, it could be
the <space-bar> and the letter "t", for example.] If you wanted to completely stop the printout, make the second key press the
<return> key. If I want to stop something right now, I press <return><return>.
Now, something to notice about the forth words as they scroll by is that the newest words are at the top of the monitor
screen and the oldest ones are at the bottom. In fact, the last defined word is the very first one you see after typing words<return>.
The words are not alphabetical -- they are listed according to when they were created. If you want to see if the word DUP has
already been created, this version of Forth allows you to type sifting DUP<return> which will show every word in which the letters
DUP appears. Another handy feature of this version of Forth allows us to see the function of DUP by typing see DUP<return> -in this case, all it tells us is that it is "code", meaning that it is written in machine code rather than in Forth. The function "see"
is really only useful for seeing definitions written in Forth. Try see MENU<return>. Both "sifting" and "see" are upper-casesensitive; that is, in order to find the words you must use upper case. Try sifting menu<return> and you will only get an "ok" back.
For the purposes of the Runtime and Summary programs, "menu" is always converted by Forth to "MENU". Therefore, when we
define one word as "menu" and later define another as "MENU" we will get the warning message "MENU Redefined" from
Forth.
3.3 Dictionaries
Forth has the ability to create different vocabularies. With different vocabularies, the same word can mean different
things without redefining the word. Using the word "menu" as in the example above, we could have two different vocabularies,
one called Runtime and the other called French-restaurant. In Runtime when we execute menu<return> then the runtime menu
shows up. In French-restaurant when we execute menu<return> then we see a list of phonetically unpronounceable words next to
outrageous prices. In the former we get a substantive program for satisfying scientific curiousity. In the latter we get skimpy
proportions with a haughty air of pseudo-sophistication, feigned culture and a sense deja vu of The-Emperor's-New-Clothes in
fashion. Of course, I don't really think of the French this way. I think all Europeans are like this. The context when
menu<return> is executed determines its functions. Although the vocabulary function is available, I generally do not use it in
programming. We do have to use it, however, when using the provided Editor and Assembler features.
There is another place where the context determines the action of a word. For example, there is a file named
ASKIING.SCR and, after loading the file, the word "askiing" will convert a DATA.SCR file into ASCII format for use by a
spreadsheet (see the section titled Askiing). The command including askiing<return> opens and loads the file ASKIING.SCR. The
(c) copyright 1995 Dave Lavond. All rights reserved.
6
command askiing data.scr,file2<return> converts DATA.SCR to an ASCII file called FILE2.SCR. Forth is smart enough to know
which word to use in these different contexts.
In general, you do not have to be worried about vocabularies or context. In fact, this section is given only as an
afterthought after the whole rest of the reference manual was written, and only came up because, after the previous section,
Christy Logan asked "can you define menu as something different from MENU?". There are two interpretations to that question:
the one Christy was asking (which I answered with a few sentences at the end of that section), and the one that I was initially
thinking (which is answered by this section). [Ifigured out and wrote her answer first.]
3.4 Words in the Dictionary
What is a word in Forth? Except for numbers, all else is a word. A Forth word can be a name for a variable, a
constant, or a function (a function is like a subroutine, and is the main way to write programs). Whenever you invoke a word its
function is executed, just like a small program. For example, type copyright<return> and you will see the copyright notice printed
to the screen. Try version type<return> and the date of the latest runtime version you are using will be displayed. This is handy to
know if you want to find out whether your version has the latest features. [This is not today's date, but the last time a major
revision was created.]
In Forth, a new word is created from words that already exist. The new word, if you are a serious programmer, should
probably do something that the old words did not do. In fact, usually a new word does a lot of old words in a new order. Here is a
simple example. Type the following:
: star ascii * emit ;<return>
: even star space star space star space star space star space star cr
;<return>
: odd space star space star space star space star space star space cr
;<return>
: flag even odd even odd even odd even odd even ;<return>
flag<return>
A field of stars will be printed to the monitor screen. [By the way, the spacing in these definitions is critically important. Forth can
only identify words if they are surrounded by a blank space.] We created several routines (called "words": star, even, odd and
flag) and executed them all when we called up the name "flag". [You can begin to appreciate the real debugging power of Forth
by executing just part of the code, for example, by typing star<return> or odd<return>.] Now if you type words<return> you will
see that the last word created (flag) will be the first word seen. Now type : flag bell ;<return>and you will get a message from
Forth something like "flag redefined". In a sense this is an error message, but really it is only a warning. Forth is letting you
know that it has determined that "flag" has already been defined but that Forth is creating a new definition for "flag" anyway;
that is, Forth you know what you are doing. Now type flag<return> and, instead of stars, the computer bells at you. "Flag" now
does a new function. Type words<return> and you will see two entries for "flag". Whenever you type "flag" Forth only executes
the newest definition of "flag". But it has not forgotten the original definition. Now type forget flag<return> and again type
words<return> and flag<return> to see what happens. ["Flag" no longer bells and instead you see stars again.] Now type forget
stars<return> and words<return> and all the definitions we created (star, even, odd, flag) are gone. Now type flag<return> and
the computer will beep in error. [A bell and a beep are two different sounds -- the IBM beep is longer and annoying, the Forthwritten bell is shorter and more pleasant. On a 4.7 MHz or 8 MHz IBM computer type roadrunner<return> for another sound I
commonly use.]
A final word about forgetting and the dictionary words. Since the dictionaries are created chronologically, whenever
you forget an old word you also forget every thing defined since then. For this reason, you cannot simultaneously forget an old
definition of flag and keep the new definition of flag intact. [Actually you cannot do that, but I could by using the hated technique
called "patching". The major disadvantage of patching in this example is that you do not recover the computer memory -- you just
skip over it -- so I see no real point in even trying it. The only time I have patched some code (taking code out, skipping code or
putting code in) is in debugging. When I have figured things out, I forget everything and recompile with the correct code.]
3.5 Don't Forget to Forget
It is a good idea to "forget" words that you are no longer using. While you could just keep redefining the same words,
that can get confusing (which definition worked?) and you take up dictionary memory. A handy tool I invented is the following
create it<return>
now define a whole bunch of forth words, test them out, and when finished you type
forget it<return>
You will see this in some of the more recent routines that I have written. The advantage here is that I do not have to remember the
first word to forget ("let's see now, was 'even' or 'odd' defined first in the example above?") because the first word is always it.
3.6 Manipulating the Runtime and Summary Programs
In your usage of the Runtime program, you will see some examples of Forth programming and usage. For example, in
using Runtime Option 4 you might see something like
: user ( --) >s slip t& t&a t&a t&a t&a t&a t&a t&a t&a ;
' user is trialsequence
This code creates a block of trials with a particular sequence (the first line) and then declares that definition as the sequence of
trials. As another example, in using Runtime Option 5 you might see something like
252 3 * scale pts
252 252 + 16 - scale airon
The first line has the arithmetic operation 252 and multiplied by 3, then the Forth defined word "scale" which takes that answer
(756, which is really the total duration of the trial in milliseconds), divides it by the bin width (actually 4 msec/bin), and stores the
(c) copyright 1995 Dave Lavond. All rights reserved.
7
answer (189 bins) in a constant called "pts" (total number of points -- or bins -- per trial). The second line does a similar
operation for "airon" (telling the computer when to turn the air on after the start of the trial).
More often you will be manipulating the Runtime and Summary programs by changing variables or constants. [We are
not really supposed to change constants, but there are good reasons for doing so that I will only mention briefly: constants are
accessed faster, and constants are easier to use with the machine language coding.] Variables are defined like this
variable #trls
and constants are defined like this
100 constant badunits
Both "#trls" and "badunits" are already defined in the most recent version. A variable has no initial value or the value of zero.
In general, I try to name a variable using the symbol "#" so that I remember it is a variable. This is my convention; variables do
not have to been defined this way. To give a variable a value try
108 #trls !<return>
which is read "108 number-of-trials store" and means that you store the number 108 in the variable #trls. This variable is used to
tell the program how many trials to run. Another variable, "trl#" (current trial number) tells the computer where to start running
trials (see Runtime Option 4). To see that #trls actually has stored the number, type
trls @ .<return>
which is read "number-of-trials fetch print". In Forth, "@" means "fetch the value of the preceding variable" and "." means
print the number to the screen. Forth already defines "?" as: ? @ . so you get the same result by typing
#trls ?<return>
In our example of a constant, "badunits" (the number of units counted in the PreCS period which, if exceeded, would
make this a bad trial -- a trial to be excluded from analysis) is defined as 100. You can see this by typing
badunits .<return>
and "100" will be printed to the screen. [Notice that you do not fetch (@) a constant. Not normally anyway. Sometimes the
Runtime program uses constants to hold the address on the Forth interface card, for example, the a/d converter, and we store to
that address or fetch from that address.] But what if I want to reanalyze my data using a count of 50 for badunits? To change it,
type
50 is badunits<return>
and type
badunits .<return>
to see the change. Since constants should really be constant (like the value of pi or the speed of light) Forth has a function called
"values" which works just like constants ("100 value badunits" for example). This seems peculiar to me. In the Runtime I define
a function "vlu", which I pronounce "value", which works like this
vlu toneon
This creates a constant called "tone on" with an initial value of zero. Later we set the value of "toneon" (and other
values like "pts" and "airon") with Runtime Option 5. But if there is a "binwidth error", which occurs when the number of
milliseconds is not evenly divisible by the binwidth, then "scale" does not change the value from zero. This usually causes the
Runtime program to appear to freeze. Sometimes it actually does freeze, sometimes it is in a very long loop. "Scale" does not have
to do this; I purposely programmed it this way, because it is a serious error by the user in setting the interstimulus intervals. It
used to be that the program would abort the Runtime program when a binwidth error was detected, but that was a long time ago
and I do not remember the reason for doing it the current way.
Without going into more specifics of the programming, you now should have a basic idea about how Forth operates.
Clearly there are more things to learn, as you have probably noticed that Forth uses "reverse Polish notation" like HewlittPackard calculators for number operations. The book Mastering Forth by Martin and Tracy, who incidentally wrote our version of
Forth, is a good introduction.
(c) copyright 1995 Dave Lavond. All rights reserved.
8
4 The Forth Editor
The Martin and Tracy book Mastering Forth also talks about the editor, but there are features that are unique to the
IBM version -- especially file handling -- which are documented in the literature that comes with the Forth language disk. Here I
will only give you a brief view of the editor's operation and some handy features. I assume you are still in Forth, and you can test
this by pressing <return> and Forth should respond with an "ok".
4.1 The Summary Auto(matic Parameter) Function
When you run the Summary program Options 1, 2, 3, 4, 7, 8, 13 and 14 it will ask you "How many trials? How many
blocks? Which trial type series?" There is a feature that allows you to always analyze your data the same way by skipping these
questions and having the answers automatically loaded for you. This is useful if you always analyze your data the same way. To
do this, you have to edit the first screen of the file SUMMARY.SCR:
using summary 1 edit<return>
This opens the Summary file and edits the first screen. [Notice that I typed more than one command on the same line. You can
keep on typing on several lines until the computer beeps at you.] A "screen" in Forth is a space of 1024 bytes, or 1K. Computers
and floppy and hard drives are still organized in terms of so-many-Ks but it may not be so obvious to us in most applications.
Forth files are created on 1K boundaries. The first 1K space is called "screen 0" (screen zero), the second screen is screen 1, etc.,
and the last screen is one less than the actual number of 1K boundaries. By convention, Forth screen 0 is reserved for comments
and cannot hold any programming. To see screen 0 press the PageUp key (or ^v). To get back to screen 1 press the PageDown key
(or ^r).
In good Forth style, screen 1 holds programming instructions for loading in the rest of the opened file. At the top of
screen 1 the first line is a comment. Comments in Forth are anything on a line after a "\" (a backslash) and anything between
parentheses [there must be a space after the opening parentheses: ( this is a Forth comment) and (this is not).] Comments between
parentheses can be on different lines and even on different screens.
Look for "variable auto auto off". Using the arrow keys you can move over to off and change it to "on". Press ^N
(Cntrl-N, i.e., hold the Control key down and press N) and you simultaneously save your change and leave the editor back to
Forth. Now if you were to run the Summary program you would not be asked what the parameters are -- they are loaded
automatically. But what are they?
4.2 The Search Function
They are whatever parameters I use, which may not be what you are interested in. To change them to what you want
you need to reenter the editor. So type 1 edit<return> once again to edit screen 1. Now we need to find where the program is
getting its default parameters. To assist us, I have placed astericks in Forth comments, so all we need to do is search for those
astericks. Press the escape key (<escape>) and the editor will respond with "ED:" Type s ***<return> to search (s) for three
astericks in a row (***). The editor will search from where we left the cursor was left on the screen forward until it finds and
highlights *** and leaves us at the "ED:" prompt. Typing <return> returns us to the screen at ***. Identify the proper
variable(s) and move the cursor with the arrow keys and change the values as desired. There are a couple of ***s on this screen,
and therefore a few variables to change. There may even be more ***s to change, so search again until the "ED:" says "Not
found". At the ED: prompt you can simply type s<return> if you want to search for the same characters repeatedly. Press
<return> to enter the screen, and then ^N to save the changes and leave the editor. Finally, close the file by typing flush<return>
4.3 Other Editor Commands
Suppose in editing a screen you want to add something, not just write over it. Press Ins the "insert" key to enter the
insert mode. Press it again to leave the insert mode.
Suppose in editing a screen you want to split a line (i.e., move everything to the right of the cursor down one line).
Press ^I.
You say you want to join a line (i.e., move everything on the line below up to the right of where the cursor is positioned).
Press ^6 (I don't know why it is a 6).
What if you make changes on the screen, then decide you do not want to make the changes and you wish you could start
over? Press <escape> and at the prompt "ED:" type fresh<return>.
From "ED:" you can also clear the whole screen by typing wipe<return>. I hope you know what you are doing when
you try this, or that you have a backup copy of the file somewhere.
To copy to a buffer a whole line that the cursor is on type ^L. To copy to a buffer a whole line that the cursor is on and
erase the line from the screen type ^K. Move the cursor to the new position and type ^O to take the last line out of the buffer.
These are probably the major editor features that you would use. I recommend making copies of files and practicing
the editor on the copies until you feel comfortable with the editing commands.
4.4 The Editor is Used by Runtime and Summary Options
The Runtime program makes use of the editing function when you choose Options 4, 5 and 7. The Summary program
makes use of the editing function when you choose Options 9 and 14. You use the arrow keys to get around the screen, and leave
the editing function when you press ^N.
4.5 The Runaway Printer
You will probably also use the editor to fix the comment saved to screen 0 of a data disk. If the Summary program
(Options 1, 2, 3) causes the printing of strange characters and ejects multiple pages when it should not before getting around to
(c) copyright 1995 Dave Lavond. All rights reserved.
9
printing the summary data, then chances are very good that the comment for this data is not correct. This usually happens if you
do not add a comment to the Runtime, or if you stop in the middle of running a session. At this time there is nothing you can do
but turn the printer off and turn it back on. The newer version of the program checks to make sure the comment is valid, and
won't print it out if there are illegitimate characters, thus avoiding these problems.
In the older versions of the program, to fix the problem for analyzing that same data in the future, or just to change the
comment, you need to edit the first screen of the data file:
change to the drive which contains the data (e.g., drive b<return>), then
using data 0 edit<return>
do your editing, then type
flush<return>
The comment is saved on the second line of the screen. Completely type or retype the entire line, including all spaces.
Put a few spaces at the beginning of the third line just for extra measure. Sometimes we see only spaces but actually there is some
code that is not an ASCII character. When the Summary program goes to print the comment, it also sends these unASCII codes to
the printer, which it interprets as a printer command. For example, the number 12 tells the printer to eject a page. You can try
this yourself:
printer on<return>
" hello there, this is a test" type<return>
Note the space between " and h is very important
cr cr<return>
Here each cr means "carriage return", not "conditioned response".
12 emit<return>
printer off<return>
The most current version of the Summary program automatically scans the comment and only sends legal ASCII
characters to the printer. This prevents the Runaway Printer problem and may give you a comment on the printout of random
characters. To put your comment onto the file, follow the procedures outlined above, or better yet, don’t forget to put a comment
on every data file before pressing 1 to run trials.
(c) copyright 1995 Dave Lavond. All rights reserved.
10
5 The Setup
The hardware and software described in this manual is intended to assist the experimenter in training subjects for
classical conditioning. While this system is designed for our own purposes we hope that others will find our efforts helpful.
5.1 What you Need
5.1.1 Hardware
Computer. IBM PC or XT or compatible with 256k or more memory. The computer can be based on 8088, 80286, 80386 or 80486.
Anything above a 8088 is overkill for running the experiments, but the higher machines have definite advantages in speed and
hard and floppy memory for analyzing the data.
Monitor. Monochrome Graphics Card and Monochrome display, Color Graphics Adaptor and Color Monitor, or Enhanced
Graphics Display and Monitor. All graphics is displayed as if it were on a monochrome graphics display (i.e.200 verticaì pixels
and 640 horizontaì pixels, white on black). Therefore, the monitor display is assumed by the software to start at $B8000. [Base 16
numbers (hexadecimal) are convenient for machine language programming and include the numbers 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A,
B, C, D, E and F. Hexadecimal numbering is denoted by a $ followed by the number. The numbers 900 (decimal) and $900
(hexadecimal) are not the same numeric values.] The software wilì not work with a Hercules Graphics card (we've tried it and will
not work in display modes where the display is stored at $A0000.
Printer. We have used parallel dot matrix (Epson LX-80, Mitsuba, IBM Proprinter, and laser (HP Laser Jet II) and also serial
laser (HP LaserJet) printers. We use the dot matrix printers when collecting data and the laset printersd when we want good
quality graphical printouts of the pictures.
Interface Card. Card plugs into an empty slot. If the interface card is wire-wrapped then the card hangs over an additional slot
This card is either purchased by the user or the plans are purchased and the item is constructed by the user The interface includes
8 a/d converters (4 available to the user) 8 parallel outputs to control equipment, 1 on board timer for intratrial events, and 2
counters for measuring unit activity. These plans are published in Lavond and Steinmetz (1989). [We also have a version with 4
units channels. All of the computers in my lab are set up this way. The plans for this are not published, but our chicken scratches
are available without explanation, assistance or guarantee. Maybe when we get a CAD program we will update the plans.]
Hard or Floppy Disk Drives. The default is Drive A (one floppy system) and Drives A and B (two floppies system), however, this
can be changed to any combination of hard and floppy drives of any size.
5.1.2 Software
DOS. DOS version must be compatible with Forth (e.g., 2.0 or above) and must be supplied by the user. We currently use version
3.3. There is one major exception: The Runtime program will not work using DOS 4.0, but it will work with DOS 5.0 [Microsoft
fixed the memory management scheme for the drive buffers].
Forth Language. "MasterForth" (an implementation of Forth-83) originally purchased from Micromotion, a company that is no
longer in business (other companies still distribute their implementations of Forth). However, I have written permission to
distribute a low volume of copies. So far, my actual distribution to new customers is far less than one copy per year.
Classical Conditioning Software. The computer files include the following:
a) Compiled Runtime file to run and collect data (FORTH.COM).
b) Source Summary file to analyze data (this is compiled at time of use) (SUMMARY.SCR).
c) Menu file used by the Runtime program (MENUS.SCR).
d) Z-score file used by the Summary program (Z.SCR).
e) Important files for compiling machine code (ASSEMBLE.RLF) and for adding floating point numbers and calculations
(FLOAT.RLF).
f) At our discretion you may also find source files for other programs (e.g., ADLIBBING.SCR, ASKIING.SCR, LATENCY.SCR).
Probably the most used is LASER.SCR for printing pictures from the screen to a laser printer, if included.
g) The source code for the Runtime program (RUNTIME.SCR) may or may not be available to you. So far, only one person that I
can remember has signed a nondisclosure agreement to see the code. As far as I know, neither Steinmetz nor this other person has
ever used or modified the Runtime source code, and for obvious reasons no one's code(s) is/are in my source file [I have had no
such contact; I could not control what changes would be made and how they would influence other parts of the code; it would be a
nightmare for me to debug]. Person's are welcome to reverse engineer the code, but it would be easier if they simply asked.
Here is a list of the files that are needed for classical conditioning, plus a few extra ones that are helpful:
forth.com
forth programming language & runtime program
menus.scr
runtime menu file and parameters for training
summary.scr
summary program written in Forth
laser.scr
screen print file used by summary program
cross.scr
cross correlations file used by summary program
z.scr
z score file used by summary program
z.blk
z score file used by summary program
printer.scr
comes with original forth.com, used to print out source code
float.rlf
comes with original forth.com, adds software floating point
assemble.rlf
comes with orginal forth.com, adds assembly language
adlibbing.scr
creates ASCII file of library disk information
(c) copyright 1995 Dave Lavond. All rights reserved.
11
askiing.scr
latency.scr
creates ASCII file of data disk information
cr latency routines for analyzing Welsh like data
5.2 Legal Issues
DOS musy be separately purchased by the user. Consult their documentation for questions about copies. Usually the
policy of software writers is to allow only one copy to be used at any one time, or one copy per machine. As noted above, we have
written permission to distribute a low volume of copies of Forth now that the company is out of business. This does not mean that
Forth is out of business, only that the company that made this particular implementation is not in business.
Our programs (Runtime, Summary) can be copied and used as many times as needed within one laboratory. We think
this is a generous and workable solution, and do not take kindly to distribution outside of the laboratory, for example, by persons
who leave the laboratory (e.g., postdocs, visiting professors, former graduate students).
5.3 Original, Working and Backup Copies
We send just one copy of our programs. Call this diskette the Original. We recommend that you write-protect this disk
and make several copies, and call these the BACKUP copies. Use a BACKUP copy to make more copies, called WORKING copies,
when needed. Use the WORKING copy to actually run experiments. If the WORKING copy goes bad, then make a new one from
the BACKUP. If the BACKUP goes bad, then make a new one from the ORIGINAL. If the ORIGINAL goes bad, you will be
embarrassed and have to ask us to send another copy.
We recommend that the copies be in physically different locations so that, in a disaster, you are not left with all your
copies gone. For example, the ORIGINAL goes home, the BACKUP goes in your office, and the WORKING copy goes in the
rooms with the running chambers.
5.4 Booting the Software
We use two different boot systems depending upon the type of monitor. If you have a CGA monitor/card or better, then boot up
DOS and at the A> prompt (or similar) type
forth<return>
and you will see the Runtime menu on the screen.
If you have a monochrome monitor with a monochrome graphics card, and if it comes with software to program the
card to simulate a color monitor, as we have, then
boot up DOS and type
color c<return> at the DOS prompt type and
forth<return>
and you will see the Runtime menu on the screen. Note that the command COLOR C is peculiar to the card and software that we
have, and that this step may not be necessary for all monochrome graphics cards.
5.5 Making a Turnkey System
A turnkey system is one which automatically runs a program when you boot up a disk. In a single disk drive system,
you create a Runtime/Summary turnkey by booting up DOS,replacing the DOS diskette with an unformatted diskette, format a
diskette with boot tracks by typing
format b: /s<return> and follow the monitor instructions to replace the DOS
diskette and type
copy a:*.* b:<return> and follow the monitor instructions with the copy in the
drive, now type
copy con: b:autoexec.bat<return>
color c<return> if you have a monochrome graphics card
forth<return>
You now have a bootable and self-starting (turnkey disk) Test this by turning ofg thecomputer. Place the new disk in drive A.
Turn off the computer. You will see, momentarily, the Forth RuntimeOpening Menu and its options appear on the screen. Use
this as your WORKING DISK and/or make BACKUP copies. We don't supply turnkey disks because you must do this with your
own DOSdiskette.
5.6 Data, Library and Graphics Disks
In addition to the WORKING COPY of the Runtime/Summary program, you will also need three more disks to store the
data that you collect and analyze: a data, a library and a graphics disk. The long way to create the disks is
boot DOS
format a diskette
type forth<return>
type 0flush<return> at the Runtime menu
(this chooses option 0 -- not listed -- to leave the Runtime program,
enters Forth and close all files)
[This is not an error that there is no space between the 0 and flush. The 0 immediately causes exit to Forth -- no <return>
required. You then immediately type flush<return>.]
put in the formatted disk
and type making data<return> then type
(c) copyright 1995 Dave Lavond. All rights reserved.
12
1000 more<return> -- this can take several minutes
At some point this process will stop with an error message saying something like the disk is full or cannot close the file or cannot
FLUSH. You now have a data disk that will hold the maximum number of trials on the disk To find out how many trials the file
can hold type size 1- u.<return> The number returned by this Forth code is the maximum number of trials you can save on that
file. Each trial is synonymous with a Forth screen, and has 1024 bytes of storage space; now type flush<return> to close the newly
created file and type making data<return> for as many formatted disks as you have, or type making library or making graphics
instead -- it is all the same process. To exit from Forth to DOS, type bye<return>.
By the way, Forth automatically adds the extension .SCR to the end of these files unless you specify otherwise.
The shorter method is to create one (1) data disk as described above, and then to exit to DOS (using bye<return>). At
the DOS prompt
type diskcopy a: b:<return>
and follow the instructions.
After making many copies of the DATA disk, you can use then for collecting data or you can convert some into library
or graphics disks by typing
rename data.scr library.scr<return> or typing
rename data.scr graphics.scr<return>
This is much faster than using Forth to make the files for two reasons: first, DISKCOPY automatically formats the disk and then
copies the files; second, the Forth copy routine is very slow. We keep a DATA disk around just for this purpose. (These
instructions are in DOS; in Forth you rename a file using the form renaming data.scr,library.scr<return>. Notice that the spacing
or lack of spacing is critically important in Forth.)
The DATA.SCR file is used by the Runtime program and by Summary Options 1, 8, 13 and 14. The file LIBRARY.SCR
is use in Summary Options 1, 2, 3, 4, 6, 7, and 10. The GRAPHICS.SCR file is used in Summary Options 8 and 13.
5.7 Optimizing Data Disk Storage
The above instructions for making a data disk make a file that is as large as the disk will hold. On a standard 5-1/4" 360k diskette,
the data file can hold more than 350 trials, which is far more than the usual training session. To make a data file so that it is just
large enough to hold 108 trials plus your comment you would do the following:
making data<return>
108 size - 1+ more<return>
flush<return>
This makes a file called DATA.SCR with 109 screens (screen number 0 for the comment, and screens 1-108 for the
actual data trials). Typically when you "make" a file Forth automatically creates 3 screens (screens numbered 0, 1 and 2). "Size"
returns the number of screens that have been alread allocated. The calculation comes to ((108-3)+1), or 106 more screens to add
to the file. You could accomplish the same thing with
making data<return>
106 more<return>
flush<return>
but the more general statement above using "size" will take care of conditions in which Forth automatically allocates different
amounts of space.
A file size of 109k (each screen is 1k long) is created with this code, means that the actual floppy disk can hold 360/109
or 3 whole data files of the same size. Obviously, the data files cannot have the same name. Since the first file is automatically
named DATA.SCR, we can create more files with other names. We typically call these DATA.001 and DATA.002 on the 360k
diskette:
making data.001 106 more flush<return>
making data.002 106 more flush<return>
Note that with Forth I can put all those commands on the same line.
Now I have a diskette that I call the Data disk with the three files DATA.SCR, DATA.001 and DATA.002. When I begin
running trials, data automatically goes to the file named DATA.SCR. Always. When I run a new session, new data writes over the
old data. However, I can save the first data by
renaming data.scr,animalnumber.day
renaming data.001,data.scr<return>
This renames (and therefore protects) the data, and renames one of the two other files to DATA.SCR where new data will be saved.
Now the files on the data disk are ANIMALNUMBER.DAY, DATA.SCR and DATA.002.
This is an efficient use of the data disk. I actually create one disk with the files DATA.SCR, DATA.001, DATA.002,
DATA.003, DATA.004 and DATA.005 on 3-1/2" 720k diskettes and copy this disk using DOS to make new data disks.
6 The Runtime Program
This section describes how to use the Runtime portion of the classical conditioning software. It assumes that you can
boot your computer with Forth and currently have the Forth Runtime Opening Menu on the screen, that you have a Data disk,
and that you have a working Interface Card and equipment.
The Runtime program controls the delivery of stimuli, the intertrial interval, the type and order of trials, the collection
of data and initial analysis of that data. The user has wide control over timing values, over amount of data to collect (as long as it
is less than 1024 bytes per trial -- see the section on Data Storage in the Overview), over the types and numbers of trials to present.
The user can write small additions to the software, or completely rewrite the Runtime and compile one's own program (these will
require a knowledge of Forth and maybe also of 8086 machine language).
6.1 The Menu and Options
(c) copyright 1995 Dave Lavond. All rights reserved.
13
There are 8 listed options (plus the hidden 0 option mentioned above) showing on your screen. The options are
arranged in a descending order of useage: the lower the number the more likely you are to use it. That is, you will always do
option 1; you probably will do option 2 and then option 1; you may do option 3 then 2 then 1; et cetera. The options are:
(c) Copyright 1995 - 1997 Dave Lavond and Joe Steinmetz
Runtime Default Currently Set at Choice #2
\ 90% Delay 4 ms, 1 unit, 1 a/d
122232222
\
normal intratrial parameters
Enter Choice:
1. Run
2. Enter comment for data file
3. Change run default
4. Change session parameters
5. Change isi parameters
6. Instructions for user-defined sequence
7. Change soft switches
8. Run summary
0
Ready
Figure 6.1: Runtime Opening Menu shoiwng 8 options and the effect of choosing option 0 (the hidden option)
to exit the Runtime probram. Normally, you would add a flush<return> to close the MENUS.SCR file, but here
I leave it open so that I can edit some of the screens.
7 Runtime Option 0: Exit Runtime, Enter Forth
This is an unlisted option. Typing 0 (zero, not ohh) at the Runtime Opening Menu causes you to exit the runtime
program into Forth. You can always tell if you are in Forth by typing <return> -- Forth answers back with an "OK" or "Ready".
Once in Forth, you can issue Forth commands or make Forth definitions. The first command you will want to issue is
flush<return>. This closes the menu file called MENUS.SCR, and all other files, so that you do not accidentally damage them by
writing some bad code. Get in the habit of typing flush<return> often while you are in Forth -- it does not hurt to do it many times
(unless you want a file to be open, but then it only closes that file).
Another thing you can do is to type the following
: n 0 portb pc! ;<return>
: y 1 portb pc! ;<return>
Now if you type y<return> the tone will come on and stay on. Type n<return> and it will turn off. You can do this as much as you
like. It is handy for debugging the electronic interface. If you now type
: y 8 portb pc! ;<return>
You will get a message "y redefined" from Forth. Now when you type y<return> the air will come on and stay on. Type
n<return> to turn the air off. Repeat turning the air on and off. Now type
forget y<return>
You will now find that typing y<return> will turn the tone on again, and n<return> will turn off the tone. This simple example
shows you some properties of Forth and how to manipulate the program. There is much more about Forth programming that can
be picked up in books on the topic. An appendix to this manual describes some of the variables and constants used in the Runtime
and Summary programs that you can manipulate. To get back to the Runtime Menu, type menu<return>
8 Runtime Option 1: Run
At the Runtime Opening Menu, pressing 1 will cause classical conditioning to begin. The following is an overview of
the process, then we discuss some details. The program asks you to put in a data disk. This is the diskette with a file named
DATA.SCR as described in the section "Setup". [The file DATA.SCR could be on a hard drive if you have set datadrive
appropriately. See the section "Changing the Runtime Default Drives".] After you have done so, press <return> so that the
program knows that you have complied. The screen will enter graphics mode and begin running trials. For each trial, the
program counts the intertrial interval, executes a trial, displays the results of the trial graphically and numerically, and then begins
timing until the next trial. At the end of running all the trials, the program will ask if you want to summarize the data. If yes, you
will go to the Summary program. If no, you will go back to the Runtime program (to the Runtime Opening Menu).
Now the details. When you type 1 the program actually does several things before the first trial appears. The "soft"
switches are loaded first (which gives control over such things as whether the data is saved to disk or not -- see Option 7), then the
intertrial intervals (iti) are loaded (including the time between trials, the trial order, the beginning and ending trials -- see Option
4), and finally the parameters you have chosen for the interstimulus intervals (isi) are loaded (including when the tone and airpuff
turn on and off during a trial -- see Option 5). The parameters chosen for isi and iti depend upon which "choice" you have made
for the run (Option 3) which allows you to arrange and store up to 10 types of training sessions, for example, for delay or trace
conditioning. The "soft" switches are the same ones used for all "choices". Default values are used for choice, isi, iti and "soft"
switches if you have not changed anything. [Notice that, because of the order of loading the parameters, if you make a change to a
(c) copyright 1995 Dave Lavond. All rights reserved.
14
value using Option 7, the "soft" switches, and then make another change to that same value using Option 4, the iti parameters,
then the Option 4 value is what is actually used.]
After the parameters are loaded, a message will then appear on the screen
"Put data disk in drive B" for a two-drive system. Make sure there is a data disk in drive B and then press any key to continue. I
usually press the space bar because it is the largest key. Drive B will operate and you will see some numbers at the bottom of the
screen. For example, on the 4th line from the bottom you may see "1> 200". The "1>" refers to the current data channel read by
the a/d converter for channel 1, and the "200" (or whatever number) refers to the current value read from the a/d converter
(usually a potentiometer). For this software and hardware, a/d values range from 0 to 255 (8 bit a/d), with 0 representing a closed
eyelid and 255 representing an opened eyelid. Baseline is normally set to 1/5 the distance, at 200, by the eyelid hardware to allow
for some eye opening and a lot of eye closing. [The reason for using 0 as a closed eyelid is because there is less software overhead
for displaying the response -- computer screens place 0,0 at the upper left corner rather than the lower left corner as would be
expected by Cartesian coordinates.] The position of the eyelid is monitored during the iti for the benefit of the experimenter so that
this value is continually updated until the actual trial begins.
Before the first trial, the 3rd and 2nd to the last lines on the screen are blank. After the first trial, the 3rd line gives
headings and the 2nd line gives the calculated statistics for the last trial (if the display is showing the block average -- denoted by a
small square in the upper left corner -- these numbers still refer to the last trial and not to the display). The amplitudes during the
PreCS, CS and UCS periods are given in millimeters (assuming that the user has calibrated the system so that 10 a/d units
represents 1 mm of movement), and a latency to the first time (after the PreCS period) that 0.5 mm of closure occurs is given in
milliseconds. The PreCS mm is the absolute deviation in either direction from baseline. The baseline is the average of the position
of the NM in the PreCS period and is calculated for each trial. If the deviation from baseline exceeds 0.7 mm in the 160 msec
before the CS onset then this is considered a "bad trial" (i.e., too much movement) and its statistics are not added to the block
average. Also, if the latency to 0.5 mm is less than 25 msec after tone onset -- i.e., if the animal gives an eyeblink that is faster than
is the minimum physically possible response latency -- the trial is considered to be a "bad trial". These data still exist, on the data
disk and in RAM for reanalysis by the Summary program, they are just not counted in the calculations for good trials. The user
could change these criteria by changing the Runtime source code and recompiling, or by temporarily changing the Summary
default variables (see Summary option 9). None of the original data is lost. The CS and UCS mm are the maximum deviation
from eyelid closure above baseline -- i.e., eyelid closure; deviations which represent eyelid openings (i.e., a/d values which get
larger) are not counted.
You can change a number of these variables for the run. For example, the 0.5 mm criterion is a variable called critlevel
-- “criterion level” -- and is the default whenever the program is booted up. You can change this, for example, to a 0.1 mm by
adding the line 1 critlevel ! on any of the screens observed for Options 4, 5 or 7 (in one place only, not all three places!), mentioned
above. Similarly, to change the bad trial criterion level to 0.5 mm use 5 bada/d ! -- "bad analog-to-digital"; to change the duration
to 100 msec use 100 baseln ! -- "baseline (before CS onset)"; and to change the time after tone onset to 10 msec use 10 badtime ! -"bad time (after CS onset)". Where you place the code can be determined by function (Option 4 is for session parameters), by
whether there is room on the option screen, and by whether you want these changes for all runs regardless of choice (then use
Option 7) or whether you want these changes only for a particular choice (then use Options 4 or 5). In general, if it is a temporary
change, I put it at Option 4, and if I want it permanent and for all options I put it at Option 7. Don't forget that someday you may
want to change it back, so you want to be able to find it again sometime in the future.
The last line on the screen tells the experimenter how many seconds there are until the next trial will occur. This
approximation is measured from the beginning of one trial to the beginning of the next trial. The iti is also given for reference.
The iti will vary according to the experimenter's wishes; it is currently set to vary from 20 to 40 seconds with an average of 30
seconds between trials (20 minimum ! 20 range ! -- see option 4). Finally, the number of the next trial is noted in terms of block
number and trial number within the block. For example, if the last line reads 12 of 29 secs until trial 7,3 then the intertrial interval
is 29 seconds of which there are only 12 seconds left until the 3rd trial within the 7th block. (Note that the interval from the start
of one trial to the start of another trial assumes a tape recorder is on for 1.5 seconds. If you turn the tape switch off -- tape off, see
option 7 -- then the timing between trials will actually be shorter than the interval displayed. Or at least that is how I remember it.
It may be now that the actual timing is independent of the tape recorder. Since we almost never use the tape recorder this is not
something I am particularly interested in.)
There are several ways to stop a session in the middle of a run. During the run you can temporarily halt the session by
pressing (nearly) any key -- the space bar is handy. A message INHIBIT will flash on the screen. Press any key to continue the
session. This is useful if, for example, the animal moves and the eyelid is no longer being monitored, or if a drug injection is to be
given.
With the earlier versions of Micromotion PC MasterForth, a ^C (pressing control and C at the same time) would abort
the session and return to the Runtime Opening Menu. With newer versions of MasterForth, a ^C seems to be intercepted by DOS
and will cause the runtime program and Forth itself to be aborted, leaving you in DOS. This especially seems to happen if you
press ^C during the trial itself. Your data in RAM will be lost. Data is still on the disk, however, but in previous versions you had
to remember how many trials you actually gave.
In the latest version, the Runtime program saves the number of the last trial on the data disk (in the first two bytes of
screen 0 of the file DATA.SCR). This means that there is a record of the last trial given should there be a power failure or should
you prematurely stop the session. When you go to run another session by rebooting or by typing menu<return>, the program
checks to see if the disk already holds the total number of trials that it expects to run -- that is, it checks to see if the last run was
stopped prematurely. If the program finds fewer trials saved on disk than the total number of trials then you are given a warning
and asked if you want to take up where you left off (i.e., with the next trial that would have been run) or if you want to start over at
the beginning. The default (pressing any key) starts running from the beginning. This default condition exists because the most
frequent reason this message pops up is because I am testing the Runtime program and I want to overwrite the previous data by
starting from the beginning. To have the program take up trials where it left off, press y instead.
All versions allow access to the Forth interpreter by pressing the <escape> key. The message INTERPRETER: will
appear on the 4th line from the bottom of the screen. You can now type any valid Forth command. The changes you make are
temporary, being only good for this particular subject. (You may be a little confused as to where you are typing because there will
not be a cursor on the screen. This is because the video is in graphics mode.) However, if you type an error you will cause a crash
of the Runtime program although you may still be in Forth. You have two courses of action. First, you can type flush<return> to
(c) copyright 1995 Dave Lavond. All rights reserved.
15
close all files; type tx<return> to change from graphics mode to text mode; and type menu<return> to get back to the start of the
Runtime program. Alternatively, you can type dark<return> to erase the screen and type continue<return> to continue where you
left off. Depending on the nature of the error the latter may or may not work and you may end up crashing Forth and maybe even
DOS also. Therefore, be extremely careful if you use the interpreter. If you intentionally wish to abort the run without losing the
data you have already collected, then type abort flush<return> in the interpreter (however, the "comment" you make with option 2
will NOT be saved correctly; only an early exit with ^C will do that, but ^C, as mentioned, can be risky). An abort is also
accomplished by pressing <escape> a second time. Type flushreturn> and menu<return> to restart. Otherwise, to normally exit
the interpreter and continue with the session, type <return> after the message INTERPRETER:. The interpreter option exists so
that the experimenter can change some parameter during the run; you might want to change the length of the intertrial interval,
for example. WARNING: do NOT change how much data you are collecting (e.g., from 1 a/d channel to 2). There is a way to do
this safely but it requires a knowledge of Forth and the Runtime program. You are better off starting the session over (a warm
boot).
Normally, however, the session will run to its completion. At this time the computer will beep at the user two times and
ask Do you wish to summarize the data? (Y). The usual answer is yes (press y or any key except n). The Summary progams are
described in another section.
8.1 Interpreting the Graphics Display
After the first trial the display will show a picture of the data collected. The x-axis alway presents time. Time 0 starts at
the left and the end of the trial is at the right of the screen. The nictitating membrane (or other a/d source) is presented in the
upper half of the screen. Eyelid closures go towards the top of the screen. For a paired tone-airpuff trial there will be two vertical
lines. The first vertical line from the left is the time of tone onset and the second is the time of airpuff arrival at the cornea (this is
not the time of onset of the air solenoid; see the discussion of this issue in option 5). The rulings in the vertical lines represent 5
mm increments. (Due to the curvature of the screen you may overestimate the size of the a/d values. Many times I place a straight
piece of paper or ruler on the screen to convince myself that the rulings on these synchronization marks agree with the calculated
values.)
You will notice three dots immediately under the a/d display. These were initially used for debugging the software but
since they are informative we left them in. The dots refer to the data calculated for the trial, specifically to the maximum CS period
amplitude, the maximum UCS period amplitude, and to the onset latency (the first time a movement of 0.5 mm was made after the
onset of the CS). There are two things to note about the dots. First, the order of the dots depends upon the magnitudes of the
measurements. In particular, the dot for the latency measurement may come before or after the dot for the CS amplitude. This is
reasonable since, if there is no learned response then the latency of responding will not be within the CS period. If no response is
observed then the latency is the end of the trial. Second, a dot may appear under what seems to be a straight line. This is not a
mistake. The fact is that an 8-bit a/d converter can represent numbers from 0 to 255, but the resolution of the whole screen in the
vertical dimension is from 0 to 199, and the a/d graph uses less than half of the screen (i.e., less than 0 to 100). The screen simply
does not have enough resolution to display a dot for every a/d value. The actual data collected are not in any way affected by the
limitation of the display screen. In this instance, the calculated values are more accurate than the graph. The dots are turned off
in Option 7 with datadots off, which becomes necessary for some horizontal displays.
If you collect more than one a/d value (up to 4 are possible) then in the newest version you will see up to four different
lines of data drawn and staggered -- 4 #a/d ! in Option 4. (In older versions, a number (from 1 to 4) is displayed in the upper left
corner of the screen, which refers to the number of the currently displayed channels. If you press 2 at any time during the iti then
the data of the second a/d channel will be drawn on the screen.) Also, the four lines of text at the bottom of the screen are altered
to give the current reading from each of the active a/d channels, and the only numbers displayed are those that represent the CS
and UCS maximum amplitudes. Obviously, there is not enough space to show as much data as with only one a/d channel.
Up to four unit data channels -- 4 #units ! in Option 4 -- are collected and displayed in the new version (two channels in
the old version) in the middle third of the screen below the a/d graph and above the four lines of numbers at the bottom of the
screen. Each tick mark (a vertical grouping of dots) represents one count of a unit from the discriminator. If two units are
counted during the same bin then the second unit is displayed on top of the first unit. You can collect up to four unit channels in
the new version (two channels in the old version) and display all at the same time, the second unit under the first and so on. The
default setting is to display each count as three vertical dots (3 is unit1x for 3x magnification for unit channel number 1 -- see
option 4) and to limit the top of the unit display so that the units do not overlap/write-over the a/d graph (28 IS ceiling -- can be
added to Runtime Options 4, 5 or 7, or see the review option, #8, of the Summary program). Changing the value for the
amplification factor (unit1x, e.g.) does not change the actual data, but only changes the way they are display.
In the newest versions you also have some options to control the horizontal display. A variable called xscalex -- "x-axis
scale multiplier" -- has a default value of 1, which means that there is no magnification in the x axis (horizontal) dimension, and
thus no spaces between data points. This is the best condition for printing the picture with unit data to a laser printer for
publications (i.e., 1 is xscalex is the default). To have the computer automatically maximize the horizontal display I often put on
the screen for Option 7 the code xmaximum pts u/ is xscalex so that all of my displays will be their largest. However, for some
choices I override this condition by placing on the screen for Option 4 the code 3 is xscalex [placing the code here overrides
xscalex values found elsewhere] -- if the value is too large for the screen then weird things will happen, mainly lines wrapping
around the screen -- (only that choice is affected, the displays for all other options are not influenced by this and will remain at the
maximum due to the action of Option 7).
Another feature is whether the a/d data (the nictitating membrane data) is displayed as dots or as lines between data
points -- dots draw faster, so in Option 7 I usually have dots on and I also turn the debugging dots for CS and UCS maximum
amplitudes and 0.5 mm latency off with datadots off because currently they get messed up with some choices of xscalex.
9 Runtime Option 2: Adding a comment to the data disk
Up to 64 characters can be entered which will accompany the data disk, the library disk, and the printout. My usual
information includes the animal number, the session, the data, the day of the week, and the study, as in 87-074 R1 4/13/87 MON
(c) copyright 1995 Dave Lavond. All rights reserved.
16
CBMACQ STUDY but it can be whatever you wish as long as it is printable (this is not censorship; rather, trying to print some
characters can cause a system crash). If your printout in the Summary program looks funny and the system crashes then it is
possible that there are some unprintable characters in the comment that have caused the whole system to go haywire. We have
encountered this a few times. This usually happens if you stop the run short of a full session without using ^C. The data may not
be lost and may be recoverable but you have to have a good knowledge of the software and Forth to accomplish this feat (see the
information on the Forth Editor in section "About Forth". In general, avoid typing any control or alternate characters and use
^C to stop a run short (but only press ^C during an iti, not during a trial).
Press <return> to get back to the Menu.
10 Runtime Option 3: Changing the run default
IBM users now have the option of using any of ten types of sessions, for example, 90% paired training, trace
conditioning, etc., which are "permanently" available. The default upon booting the system is either default = 1, which is 90%
paired training, or = 2 (something else) in the disks we send you. You may have requested some other arrangement. It is
important to note that whenever you choose a new session default you are also using a unique set of isi parameters. If you used
90% paired training and now choose trace conditioning, the isi parameters you set up for 90% training will not be used by the
trace procedure. Therefore, if you want to change the isi parameters for trace conditioning (choice 5), for example, you must use
option 3 from the Runtime menu first in order to choose for the trace trial sequence, then option 5 from the Runtime menu to
change the isi values. This is a new feature so that you now have 10 options, so you only have to change isi parameters once at the
beginning of a new study; once these isi parameters are set then you only need to use option 3 to select the type of session to run.
Another new feature is that you are shown your current choice so you can select it (i.e., keep the selection unchanged) -- I kept
forgetting what the program choice was already set at.
If you want the default choice on bootup to be changed, see the section "Changing the Runtime Default Choice".
You must make a selection to return to the Menu.
11 Runtime Option 4: Changing the session parameters
Session parameters include the beginning trial number, usually 1 (trl#; it may be something else if you have collected 10
trials and you want to continue at trial 11, for example); the minimum iti and the range of iti; number of a/d channels in use (#a/d;
up to 4); number of unit channels in use (#units; at least 2 and up to 4 with some Forth interface boards) and the size of the units
on display (unit1x, unit2x); how you wish the blocks summarized (blksum(a) and blksum(b); 0 = no sum, 1 = sum tone alone trials,
2 = sum tone-air trials, 3 = sum light alone trials, 4 = sum light-air trials, 5 = sum air alone trials) -- note that blksum(a) and
blksum(b) will add to the same picture so that if A = 2 and B = 4 then all the paired trials will be summarized (see next paragraph);
the unitduration refers to the length of the pulse given to the unit counter -- this is used to calculate the maximum number of
reasonable, valid counts possible in the binwidth chosen (e.g., the Haer discriminator gives a 200 usec pulse); the number of trials
(#trls), blocks (#blks), trials per block (#t/blk) and the binwidth (bin; in microseconds -- choose whole milliseconds for this value);
and finally the actual trial sequence. There are several built-in trial sequences including 90% paired (90%; 9 trials per block),
75% paired (75%T; 8 trials per block), unpaired (UNP; 18 trials per block), trace (TRACET; 9 trials per block), extinction
(EXTINCTIONT; 9 trials per block), 75% alternating tone and light blocks (75%TL; 18 trials per superblock). In addition, the
user can define his/her own trial sequence using Option 6. It is extremely important to make certain that the number of trials per
block equals the number you have in your sequence. If the program runs one block and then crashes you might suspect that there is
a mismatch here.
At the end of every block of trials during the Runtime program a summary picture will be displayed. Only one summary
picture is made. This picture can be of all tone alone trials in the last block (BLKSUM(A) = 1, BLKSUM(B) = 0), or of all toneairpuff trials in the last block (BLKSUM(A) = 2, BLKSUM(B) = 0), or of all tone alone and all light alone trials in the last block
(BLKSUM(A) = 1, BLKSUM(B) = 3), or of all tone alone and all paired tone-airpuff trials in the last block (BLKSUM(A) = 1,
BLKSUM(B) = 2), or any other combination. (The values for BLKSUM(A) and BLKSUM(B) are interchangeable.) We repeat,
only one picture will be made for each block.
It is extremely important to be aware of the amount of data you are trying to collect. As currently written, 1k (1024)
bytes of space is set aside for each trial. If you collect data points every 5 msec (5000 bin !) for 1000 msec (1000 scalepts) with 1
a/d (1 #a/d !) and 2 units (2 #units !) you will require (1000/5)*(1+2) or 600 bytes, and that is fine. If, however, you try to collect at
2 msec (2000 bin !) then you need 1500 bytes, and this is too much. You will not be given a warning, but in this example your trial
display for the last unit channel will look funny -- that is because you are actually displaying part of the array used to summate
trials for the block average. So far this mistake has not crashed any IBM program, because we have implemented a miniRAM
disk, but our Apple II version would crash.
The changes you make with this option will remain changed when you reboot the computer.
This option uses the built-in Forth editor. Use the arrow keys to move around the screen. Type ^N to return to the
Menu.
SCR# 10
\ 90% Delay 4 ms, 2 units, cold studies
122232222
DECIMAL
255 maxeye !
1 trl# !
\ beginning trial #
7 minimum ! 1 range !
\ iti values; 5, 1 are minimum
2 #units ! 3 is unit1x 3 is unit2x
\ unit collection
1 #a/d !
\ a/d collection
2 blksum(a)
0 blksum(b)
200 ( usec) unitduration ! \ Haer discriminator output duration
(c) copyright 1995 Dave Lavond. All rights reserved.
17
108 #trls ! 12 #blks ! 108 12 / #t/blk ! 4000 bin !
\ bin is in usecs -- for the moment, use whole msecs.
‘ 90% is trialsequence
Figure 11: Intertrial parameters (Runtime option 4) for one of the ten optional runs (see choices from Runtime
option 3). These parameters are unique to each of the ten choices (unlike the soft switches, Runtime option 7,
which are good for all ten choices). Use ^n to return to the Runtime menu.
12 Runtime Option 5: Changing interstimulus intervals
Before changing the interstimulus intervals you must select option 3 first and choose the trial sequence you wish to run.
The reason for this is that there are separate screens holding the isi parameters for each of the 10 possible trial sequences.
The isi parameters are given in whole milliseconds. These values MUST be evenly divisible by the binwidth (in
milliseconds, i.e., bin divided by 1000) seen with option 4. If the value is not evenly divisible, then a zero (0) is entered into the
variable and you can get disastrous results when you run (e.g., the airpuff or shocker could be left on during the entire intertrial
interval). The computer can figure out the exact values for you. Any valid Forth word (e.g., + - / * SWAP DUP etc.) is useable on
this screen (and in option 4 also).
The parameters that need to be set include pts (total time for the trial; actually the total number of points to be collected
in each trial, see "scale"), airon (time from start of trial to turning on the air solenoid -- don't forget to subtract the time delay for
the solenoid to turn on and for the air to travel down the hose), airoff (time from start of trial to turning off the air solenoid),
toneon (time from start of trial to turn on tone), toneoff (time from start of trial to turn off tone), lton (time from start of trial to
turn on light), ltoff (time from start of trial to turn off light), shkon (time from start of trial to turn on shock), shkoff (time from
start of trial to turn off shock), pulseon (time from start of trial to give a pulse out on the last parallel output -- this is an on/off,
microsecond pulse used to signal or trigger external equipment). Sync pulses are given (on the second to last parallel output) for
the beginning of the trial, toneon, lton, and shkon. Shkon is usually used for turning on a shocker, but it is also used to indicate
the sync pulse for the arrival of the air at the eye (therefore, it does not have the hose delay needed for the airpuff solenoid). If you
only use airpuff and do not set the shkon value then the Runtime display and calculations will not be correct.
Although we think of these values as "times" they are actually converted by the word scale into number of bins. For
example, if the trial duration is 750 msec and the period of collection is once every 10 msec (i.e., 10000 bin ! in Runtime Option 4),
then 750 scale pts results in the value of pts being 75 (75 points at 10 msec each equals 750 msec total). All of the values on this
screen are converted to number of bins because this is used by the assembly code to actually deliver a trial. These values are then
converted into times which are printed out (Summary Options 1, 2 and 3). If you have 250 scale toneon with 10 msec bins in this
example, then the actual value of toneon is 25. Thus, at the 25th bin count from the beginning (starting at bin 0) the tone will
come on. The equivalent to pts in the Summary program is trialdur (which comes from the last screen of the SUMMARY.SCR)
and is the actual trial duration in msec. The Summary program calculates pts from trialdur, because the data file (DATA.SCR) -where the Summary program gets its data -- stores data points by bins, not by time.
The changes you make will remain changed when you reboot the computer.
This option uses the built-in Forth editor. Use the arrow keys to move around the screen. Type ^N to return to the
Menu.
SCR# 11
\
DECIMAL
normal intratrial parameters
\ millisec from beginning of trial:
252 3 *
scale pts
\ trial duration, ms
252 252 + 16 scale airon
\ air latency
252 252 + 16 - 100 +
scale airoff
\ air latency
252
scale toneon
252 252 + 100 +
scale toneoff
252
scale lton
252 252 + 100 +
scale ltoff
252 252 +
scale shkon
\ used for sp
252 252 + 100 +
scale shkoff
252
scale pulseon \ on 0ms before tone
Figure 12: Intratiral parameters (Runtime option 5) for one of the ten optional runs (see choices from Runtime
option 3). These parameters are unique to each of the ten choices (unlike the soft switches, Runtime option 7,
which are good for all ten choices). Use ^n to return to the Runtime Menu.
(c) copyright 1995 Dave Lavond. All rights reserved.
18
13 Runtime Option 6: Making your own trial sequence
Selecting this option merely shows you instructions for making a trial sequence of your own choice. Follow the
instructions and put the sequence at the end of the screen seen with option 4. You can make as many sequences as you like
because these are compiled just before the first trial begins. You can make up your own functions or use the predefined functions
we provide: T&, L&, A&, S&, TL&, T&A, T&S, L&A, L&S, TL&A, TL&S, each will run an intertrial interval and a trial of the
chosen type (A=air, L=light, T=tone, S=shock, and their combinations). Notice that you are actually writing a Forth program. To
make up your own functions will require a knowledge of Forth and of the Runtime source code.
For example, there is currently no word for making a shock alone and tone-shock trials. Based upon the Runtime code,
the following code would accomplish this:
: SHOCK ( --) NOTHING 8 KIND 'SHOCK-ON/OFF VEC3 ! 'PULSE-ON VEC5 ! ;
: TONE-SHOCK ( --) NOTHING 9 KIND 'TONE-ON/OFF VEC2 ! 'SHOCK-ON/OFF
VEC3
'PULSE-ON/OFF VEC4 ! ;
However, there is currently an interdependence between shock and air trials.
Note the following definition of a paired tone-air trial from the Runtime
code:
: TONE-AIR ( --) NOTHING 9 KIND 'TONE-ON-OFF VEC2 ! 'AIR-ON/OFF VEC3 !
'SHOCK-ON/OFF VEC4 ! 'PULSE-ON/OFF VEC5 ! ;
Even though the word TONE-AIR is meant to only turn on the airpuff, the phrase ‘SHOCK-ON/OFF VEC4 ! is included in this
definition. The reason is that there is a discrepancy between when the air solenoid is turned on (this is the function of 'AIRON/OFF VEC3 !) and when the air actually arrives at the eye (this is the function of 'SHOCK-ON/OFF VEC4 !). In other words,
there is no delay in delivery of a shock UCS. The cursor markings on the a/d graph display are based upon the time of UCS arrival
at the eye, as are all the UCS measurement calculations during the trial (and in the Summary programs). Therefore, the currently
defined word TONE-AIR could more accurately be called TONE-AIR-SHOCK. If you want a definition in which air and shock
are truly independent then you will have to redefine the more primitive command for 'AIR-ON/OFF which requires some
knowledge of 8086 machine language programming.
In addition to the sequence you define here in the Runtime, you must also configure the Summary program so that it
will correctly analyze your data. The Runtime and Summary programs do not communicate any parameters between them. To set
up the Summary program read that documentation; at the least you will need to create a trial type table (Summary option 5) and
set up the session parameters (Summary option 9).
This option uses the built-in Forth editor. Use the arrow keys to move around the screen. Type ^N to return to the
Menu.
SCR# 6
DECIMAL \ User-Defined Sequence
\ the following trial-types have already been defined:
\ t&, l&, s&, a&, t&a, l&a, t&s, l&s, tl&, tl&a, tl&s where t=tone, l=light, a=air, s=shock.
\ Note: do not define sequence with only 1 trial/block.
\ To use: define a sequence of trials in a block, e.g.,
\
: (user) >s slip l& l&a l&a l& l&a l&a l&a l&a ;
\
Each definition MUST have : (user) >s slip ... ;
: user ( --)
\ use this to make a block sequence of trials.
>s slip
\ do not alter this line ! ! ! ! !! !!! ... . .
.
t& t&a t&a t&a t&a l& l&a l&a l&a l&a ;
\ yeo repl sequence
‘ user is trialsequence \ do not alter this line !
! ! ! !! !!! ... . .
.
\ the following info must match your defined sequence:
( 200 #trls ! 20 #blks ! 200 20 / #t/blk ! 4000 bin)
Figure 13a: Runtime option 6 shows this screen of instructions. This is for informational purposes only. This
screen is never loaded. Put your definitions of user and its resolution as trialsequence on the bottom of the
intertrial parameters (Runtime option 4). Use ^n to return to the Runtime menu.
SCR# 12
\ 90% Delay 4 ms, 2 units, cold studies
122232222
DECIMAL
255 maxeye !
1 trl# !
\ beginning trial #
20 minimum ! 20 range !
\ iti values; 5, 1 are minimum
1 #units ! 3 is unit1x 3 is unit2x
\ unit collection
1 #a/d !
\ a/d collection
2 blksum(a)
0 blksum(b)
200 ( usec) unitduration ! \ Haer discriminator output duration
108 #trls ! 12 #blks ! 108 12 / #t/blk ! 4000 bin !
\ bin is in usecs -- for the moment, use whole msecs.
(c) copyright 1995 Dave Lavond. All rights reserved.
19
: user ( --) >s slip t& t&a t&a t&a a& t&a t&a t&a t&a ;
‘ user is trialsequence
3 is xscalex
Figure 13b: Also intertrial parameters (Runtime option 4) showing a user-defined trial sequence (instructions
seen with Runtime option 6). Note also that the horizontal scaling factor xscalex is manually set to be 3.
14 Runtime Option 7: Changing the soft switches
Soft switches are binary variables that are read by the program to determine what option to select. You can turn the
TAPE recorder on or off (remember that the intertrial intervals assume the tape is on), or prevent data from being stored on disk by
putting the SAFETY on (for example, if you have no drive B or no Data disk), or have the run automatically PAUSE between
blocks of trials so you can administer drugs (for example), or FILTER the a/d data (by averaging neighboring values) to smooth the
data, or FLASH on and off the INHIBIT message, or collect data offline with LIVE OFF, or turn off the preCS pulse usually given
at the beginning of each trial (PCSPULSE OFF -- so you can trigger an external device to the CS pulse, for example), or get a
graphical representation of the data (PICTURE ON) or a table of numbers during the run (PICTURE OFF). There is also an in
USE word which is not very useful for the experimenter -- this was used in debugging and is used by the program to determine
whether there is data that needs to be updated to the disk and screen.
This option uses the built-in Forth editor. Use the arrow keys to move around the screen. Type ^N to return to the
Menu.
SCR# 4
\ software switches
tape off 4 before ! 1 after !
safety off
pause off
filter on
flash on
use off
live off
pcspulse on
picture on
dots on
datadots off
xmaximum pts u/ is xscalex
\ ON = tape recording
\ OFF = storage to disk
\ OFF = no pause between blocks
\ ON = a/d filtering
\ ON = flash “inhibit” message
\ OFF = no previous trial
\ OFF = normal data collection
\ ON = start trial w/sync pulse
\ ON = display graphics picture
\ OFF = display numeric data
\ OFF = draw lines between data
\ OFF = no data dots
\ set max data display
Figure 14: Runtime option 7 shows the soft switches and their states. This screen with these parameters and
states are used no matter which of the ten Runtime choices is selected (Runtime option 3). Use ^n to return to
the Runtime menu.
15 Runtime Option 8: Run Summary Program
The Summary program is described elsewhere. Here it is important to note that you can run the Summary program
directly from the Runtime program. However, since at the end of each session you are automatically asked if you wish to
summarize the data (and get a printout and store the data as well) this option is not used very often. Furthermore, if you are in
Forth (i.e., if you get an "OK" message after pressing a return) you can bypass the Runtime program by typing instead including
summary<return>.
15.1 Overview of Running a Session
This section gives an overview of how to run a session from start to finish.
15.2 Things you Need
1) DOS 2.0 or higher (but do not use DOS 4.0; DOS 5.0 is ok)
2) Forth programming language from Micromotion
3) Compiled Forth Runtime program
4) Source code for Forth Summary program
5) Data disk
6) Library disk
7) Interface card and your equipment
8) IBM PC or equivalent with at least 256K RAM and 2 floppy disk drives
9) A monitor and driver capable of displaying 200 x 640 graphics pixels
10) Printer with compressed mode (e.g., IBM, EPSON have 17 cpi)
(c) copyright 1995 Dave Lavond. All rights reserved.
20
15.3 Defaults
As you receive the Forth disks they will be set up to run a session of classical conditioning consisting with whatever
parameters are on my disks at the time. I may be testing code, debugging problems or analyzing data. The parameters are usually
12 blocks of 9 trials per block for a total of 108 trials per session. Each block consists of one tone alone trial followed by 8 paired
tone-airpuff trials. The intervals from the start of tone trial to the start of another trial vary from 20 to 40 seconds with an average
of 30 seconds (20 minimum ! 20 range !). At the end of each block you will see on the screen a summarized block picture of paired
trials for the last block (denoted by a square in the upper left corner). The default collects one a/d channel at a rate (binwidth) of 4
msec per point. All stimulus durations are even multiples of 4 msec. There is a 248 msec baseline before tone onset, the tone lasts
for 348 msec and coterminates with a 100 msec airpuff. Total trial duration is 744 msec.
15.4 Review of Forth Classical Conditioning/IBM PC Interface
1. The pinouts for the parallel TTL outputs are the following (assuming that you have a standard interface; I know that some of
interfaces made for Dr. Diana Woodruff-Pak by Bob Clark are not standard by design):
Pin 1
tone (or any CS)
Pin 2
light (or any CS)
Pin 3
unused
Pin 4
airpuff
Pin 5
shock
Pin 6
tape
Pin 7
trial synchronization pulses
Pin 8
pulse
2. The pinouts for the a/d inputs (0-5 volts in) are relatively simple: the first pin is the first a/d line, the second pin is the second
a/d line, etc. Four a/d lines can be handled by the software, although the a/d chip actually has 8 lines. It is wise to ground unused
inputs and this may have been done already on your board. If you are trying to read another a/d and you only get zero then you
will have to unground its input.
3. The pinouts for the unit counter are simple: the first pin is the first counter, the second pin is the second counter.
4. There exists one more pin used as a TTL input for synchronizing data collection offline from tapes.
5. There are, unused and not wired, 8 TTL parallel inputs.
6. In addition to the hardware provided, the user could easily add additional timers/counters (8253), parallel I/O (8255), a/d (0808)
as desired for the user's own purposes in the unused space on the card. I have done this on one card to add more unit counters
and to control an attenuator and a frequency generator.
15.5 To Run (or "A Sample Run")
Boot up DOS and load in the Forth program in Drive A. (You may have set this up automatically -- a turnkey -- as
noted in the Runtime instructions above.) Choose option 2 from the Forth Runtime Opening Menu and enter a comment (e.g., the
animal number, or simply "test"). Choose option 1 to start the run. Put in a Data disk in drive B and press any key to continue.
The program will run one full session. You can temporarily stop the computer by pressing (almost) any key -- an INHIBIT message
will appear on the screen. Restart by pressing (almost) any key. You can stop the session prematurely and save the data you have
collected by pressing the <escape> key to get into the interpreter (however, your comment will NOT be saved properly). [Alternatively, you could use ^C, but see elsewhere for associated problems.] Type ABORT FLUSH<return> and you are now in Forth.
Type TX<return> to return the video from graphics to text mode (now you can see the cursor). If you do not want to save the data
and you want to start over again you can turn the computer off (a fair idea) or simultaneously hold down the control and alternate
keys while tapping the delete key (a warm boot and a better idea).
If not aborted, the session will stop itself after 108 trials and beep twice at you with the message Do you wish to
summarize the data? (Y). Press N if you do not want to summarize, press Y (or any key except N) to automatically run the
Summary program. The Summary menu will appear (with about 14 options now). Choose option 3 (Summarize from data
collected during the Runtime into RAM). Answer any questions (see Summary documentation). You will get a printout of the
session. You will next be asked for a Library disk to store the session's data. Remove the Runtime program disk and insert a
Library disk in drive A if you want to store the computations of the data onto a library disk. Press any key to continue. [If you do
not want to store to a Library disk, it is best to put a disk with any files on it, except it should not have LIBRARY.SCR, and press
<return>. The computer will say it cannot find the file and it will abort to Forth. Pressing <return> will cause Forth to respond
"ok" (or "Ready").] When finished you will be told to reinsert the Runtime disk. Do that and press a key for another run, or
reboot the computer to run another session.
15.6 Data Storage
During the Runtime the raw data are stored on the Data disk in drive B. The Data disk has the raw data for all trials
including the "bad trials" identified during the run; i.e., the data from the "bad trials", while not included in Runtime average
calculations, are not altered or thrown away. At the same time, the calculations made during the run are stored in Segment 2 of
RAM. The calculations are not altered or thrown away for "bad trials". If option 3 (analysis from data collected into RAM) is
chosen during the Summary program these calculations for the individual trials are not made again but are recalled from Segment
2 of RAM. If option 1 (analysis from data saved to disk) is chosen in the Summary program then the calculations for the
individual trials are recomputed from the raw data and the answers saved to Segment 2 of RAM. Block averages are computed
during the summary program from these numbers in Segment 2 of RAM. At the end of the Summary program these numbers for
the individual trials are saved from Segment 2 of RAM onto the Library disk. In addition, the block pictures shown at the end of
each block during the Runtime are stored in Segment 3 of RAM (up to 64 pictures). At the moment the Summary program does
not do anything with these pictures (therefore they are lost when written over or the computer is turned off) but they could be
(c) copyright 1995 Dave Lavond. All rights reserved.
21
dumped to a Graphics disk in a manner analogous to the Library disk. However, these pictures can always be reconstructed from
a Data disk by using the Review option (#8) in the Summary program if you save the data disks from each run (you cannot
reconstruct the pictures from the Library disk).
The Data disks are written over when a new session is run. If you wish to save the raw data then you need to save the data disks
or save the data onto tape. You can prevent accidentally writing over important data by renaming the file. For example, in Forth
type RENAMING DATA.SCR,88-123.001<return> (note the spacing). In DOS type RENAME DATA.SCR 88-123.001 <return>
(note the spacing) (DOS may not allow you to begin a file name with a
number).
Recall that the Summary program provides an option (#1) for analyzing data from the disk. This subprogram
recalculates all the numbers normally made during a run and stores these numbers in Segment 2 of RAM, where the rest of the
Summary program picks them up, averages, prints them out and stores them to the Library disk.
The reasons for having the raw data saved on disk during the run are two-fold: a) so that data can be recovered in the
event of an unexpected power failure (this has happened on rare occasions -- the user must know or figure out how many trials
were actually given); b) so that the raw data is preserved as long as one likes for reanalysis or review (as in the Summary
program). To get a printed picture of the graphs from the screen we have used the commercially available resident program
GRAFPLUS to print out pictures from the Forth screen. By loading in our LASER program and/or using the REVIEW option
from the Summary menu you can also send these printouts to a Hewlett-Packard laser printer. It is not recommended that you
have Grafplus resident while collecting data with the Runtime program -- our experience is that timing is off.
16 Runtime Offline Data Collection
During a normal run of a session the user can collect data to a tape recorder. Signals within the audio frequency range
(like unit activity and sync pulses) can be recorded directly onto the tape. DC or very slow signals (like eyelid data) can be
frequency modulated (e.g., with a Vetter device, with a phase locked loop, with a voltage-frequency chip) and stored on tape, and
then demodulated on playback. The user may do this for later analysis or reanalysis of the session's data. This is most likely for
multiple unit activity where windows can be set up for looking at different units.
The Runtime program can be used to analyze from tape, i.e., offline data analysis. We have used this option sparingly.
With the disks we sold you, there is an example of how to set up for offline collection. From the Forth Runtime Opening Menu
choose option 3 (change run default). You will then see that selection 10 is set up for offline analysis. Choose selection 10. From
the Forth Runtime Opening Menu select options 4 and 5 to see the session, iti and isi parameters. Or just select option 1 and run
as you normally would. The parameters are loaded, the Data disk is ready, the iti has counted down, and now the computer sits
and waits. It waits for a sync pulse from the tape -- a TTL level signal onto the external sync pin of the Interface Card. When
triggered, the computer will run a trial in the sequence and collect the data. There is no picture on the display. The display prints
the trial's statistics instead. The iti is counted down and the computer waits for another trigger pulse. This repeats itself until the
total number of trials you request has been received.
Items of note:
As with online analysis, the signals into the Interface Card must be within the correct ranges. Unit inputs must be TTL
levels and the a/d data must range from 0 to +5 volts.
There must be sufficient time between trials on the tape so that trials are not missed (this must be empirically
determined for your setup and is a function of your switching device, the recorder's time to speed up, and the tape speed).
Computer operations that take a lot of time had to be eliminated between trials so that trials would not be missed. The
calculations for graphics take too much time. For this reason the PICTURE is OFF. The TAPE is also OFF. Don't get excited -you play back the data offline under manual control. Having the TAPE switch turned off merely means that the computer will not
try to control the tape or to wait for the tape.
For even faster collection you can decide not to collect to disk by putting the SAFETY ON. However, since disk access to
RAM uses DMA (direct memory access) you will not gain a whole lot.
You can also reduce the intertrial interval. However, anything less than 3 seconds (determined empirically) effectively
disables your ability to interrupt collecting with the <escape> key.
You can make the trial sequence anything you like. The example uses 90% paired training.
The program only looks for the first sync pulse. It assumes that you have the tape correctly positioned at the beginning
of a trial rather than in the middle of a trial (otherwise collection will begin on synch pulses for the tone or airpuff).
In the normal course of events, after pressing option 1 for run, the program first loads in the soft switches (there is only
one set of soft switches shared for all run defaults), then the iti and session parameters, and then the isi parameters. For this
reason, you can override the soft switches (as in this example) when the iti, session or isi parameters are loaded.
In order to collect offline, the soft switch LIVE must be OFF. This is why the program waits for an external
trigger/sync pulse.
If no sync pulse occurs the computer could be stuck and wait forever. You can manually trigger a trial by pressing any
key. This is handy if you wish to collect spontaneous data, or if you need to have an iti so that you can use the <escape> key to,
finally, use the Forth interpreter.
The offline collection stops when
the total number of trials requested have been collected;
during the iti you press
<escape> and abort from the interpreter;
you press ^C (which should take you back to DOS)(not a good idea if you have
not collected data to disk);
you perform a warm boot (not a good idea if you have not collected the data to
disk);
you turn off the computer (not a good idea if you have not collected the data to
disk)
(c) copyright 1995 Dave Lavond. All rights reserved.
22
17 Compiling Your own Runtime Program
If you have written your own runtime program, or modified the Runtime
source code for our programs, you can easily (re)compile your new code. To do
this you need to have the file RUNTIME.SCR or equivalent.
1) Boot up your version of MS-DOS 2.0 or higher (but not 4.0; 5.0 is ok).
2) Put a copy of your Micromotion Forth disk in drive A and type forth<return> to load the language in the file
FORTH.COM. [Your Runtime disk also has a file called FORTH.COM. But the Runtime disk's FORTH.COM is an "image" of
the Runtime code, and therefore includes the Forth language but also the Runtime program. If you use the Runtime
FORTH.COM with the following instructions you will get a bazillion (that's a whole lot) words redefined and run out of room
before completing the compilation. You could try forget runtime<return> before you attempt to compile, but unless you are me -or unless you are very familiar with the Micromotion documentation -- you may still run into trouble with other vocabularies (see
"Dictionary Structures" and "Dictionaries" in the section "About Forth Computer Language") and not be able to fix it. The
moral is: stick with the plain Micromotion Forth disk with just the Forth code on it.]
3) Put your source code in drive B.
4) Type including b:runtime<return> (if RUNTIME.SCR is the name of your source).
5) After several minutes of loading the program, using both drives, the whole system will be finished.
6) Type ' menu is ready<return> (note the apostrophe and the spaces).
7) Type saving a:forth<return>. This command saves the compiled program back to the file FORTH.COM, i.e., this
changes the original Forth file so use a copy of the ORIGINAL disk in drive A instead. [I repeat, save to a copy of the original
disk, not to the original disk itself. That way you always have a working disk.]
8) Leave forth with bye<return> and (in DOS) copy these files if they are not already updated on drive A: copy
b:menus.scr a:<return>, copy b:summary.scr a:<return>, copy b:z.scr a:<return>, and copy b:laser.scr a:<return>.
9) To make a turnkey disk see the Runtime documentation.
18 Changing the Runtime Default Choice
When the Runtime program boots up it assumes that you would like to run whatever program in your list of 10 that you
have listed as number 1 (or whatever we left it at when we compiled the program). You see the whole list of 10 possibilities by
typing 3 from the Runtime menu. If you wanted the default to be possibility number 5 instead of number 1 (say that number 5 was
for unpaired conditioning) you have one of three options.
First, you can boot up as always with the default set to number 1, then choose option 3 from the Runtime menu to
change the default, and select number 5 for unpaired conditioning.
Second, you can edit the options, moving all of the parameters for unpaired conditioning to the first position (options 3,
4 and 5 would have to be used by novices; option 4 and the Forth editor could be used by more advanced users). For novices,
make a selection with option 3 for a type of run default, select options 4 and 5 and write down all the parameters. Select option 3
and change the run default to 1. Select options 4 and 5 and write down the parameters you copied.
For more advanced users, the parameters for each default occupy 2 adjacent screens beginning at screen 10 of the
menu file. Therefore, choice 1 occupies screens 10 and 11, choice 2 occupies screens 12 and 13, choice 3 occupies screens 14 and
15, et cetera. To interchange 90% paired conditioning (choice 1) with 75% paired conditioning (choice 2) you could do the
following. From Forth the advanced user can type FLUSH<return> (close all files), USING MENUS<return> (open the
MENUS.SCR file), 10 EDIT<return> (allow editing of screen 10). You now use Forth editor commands: type ^K sixteen times (yes
16 times). Each ^K removes one line from the screen and places it into a buffer. This buffer is a last in, first out type, meaning
that the last line you place in the buffer is the first to be taken out of it (when you use the ^O command below). Move to screen 12
by typing ^V twice. Each ^V moves the editor one screen forward. You are now on screen 12. Type ^K sixteen times to gobble up
that screen. The buffer now holds 32 lines of text. Now move back two screens by typing ^R twice. You are now back on screen
10. Type ^O sixteen times to offload the sixteen lines you gobbled from screen 12. Go forward to screen 12 (^V twice) and offload
the 16 lines you first gobbled from screen 10 (^O sixteen times). Type ^Q to save the changes to disk. You have now exchanged
screens 10 and 12. You next need to exchange screens 11 and 13 in the same manner. Obviously this is a reasonable amount of
work. Next you will see there is an easier way.
Third, you can change the boot default from 1 to 5, for example, so that unpaired conditioning is normally your default
choice. To do this, select 0 (zero) from the Runtime menu and type FLUSH<return> to close all files. Now type 5 CHOICE
!<return> and SAVING FORTH<return>. This changes the default to 5 and saves the whole Forth dictionary back onto the
Runtime/Summary disk. Use a WORKING COPY of the Runtime/Summary disk because you are actually changing the program.
Now when you boot up (e.g., test this by typing Control-Alternate-Del all at the same time -- a warm boot) the menu will come up
with choice 5, unpaired conditioning, as the default.
19 Changing the Runtime Default Drives
The current defaults are drive A for the Runtime disk and drive B for the Data disk. You can now change
this so that you can use any desired combination.
To make this change leave the Runtime program (type 0 from the Runtime menu, type flush<return>).
To change to Runtime in the hard disk, Data in drive A, type:
" c" programdrive s!<return>
" a" datadrive s!<return>
To change to Runtime and Data drive both to the hard drive, type:
" c" programdrive s!<return>
" c" datadrive s!<return>
(c) copyright 1995 Dave Lavond. All rights reserved.
23
To make this change permanent, type:
saving forth<return>
20 Changing the Runtime Default Directory
Before entering the Runtime program you can change directory in DOS and then run from that directory. For
example, from my hard disk I do:
cd \dave\forth<return>
forth<return>
The default drive and directory are determined by where I begin but the Runtime program then operates on the program, data and
library drives as determined above. According to the Micromotion documentation, to change the default directory you can use the
Forth command (for example)
drive b<return>
chdir \dave\forth\datafiles<return>
to change the path for drive b to be \dave\forth\datafiles. If that does not work then try the equivalent statements
drive b<return>
" \dave\forth\datafiles" cd<return>
I have not used these much so I really don't know if this will work. You can try saving
saving forth<return>
leaving forth
bye<return>
and then starting it up again to see if it worked with
forth<return>
My computers are very primitive so I don't have much reason to try this.
21 Runtime and Summary Program Interactions
This is simple. There is no interaction. Therefore, you must correctly set up parameters for the Runtime and Summary
programs separately. For the Runtime this is done with options 3, 4 and 5 as discussed in the preceding write-up; for the Summary
this is done with options 5 and 9 as discussed in the following write-up.
This lack of communication dates back to the FIRST program that Steinmetz was familiar with, and therefore was done
on purpose so that the user could choose, in the Summary program, exactly how the data were to be analyzed. Unfortunately,
many users are confused by this feature. In the future, I may allow for both options: analysis at the user's discretion, and/or
analysis using the runtime parameters. [Don't hold your breath.]
22 Summary Program
This manual describes the procedure for using the Summary programs for analyzing data collected by the Runtime
program. Unlike the Runtime program, the Summary programs are not precompiled. The Summary programs are compiled by
Forth at the time that they are being used. This strategy allows for great flexibility in rewriting the analysis programs by the user.
The Runtime and Summary programs do not communicate with each other about how any of the data was collected. Read on to
understand how to use the Summary program for analyzing data from a run.
22.1 General Overview
The Summary program is actually a collection of several programs. The programs were designed and written to reduce
and analyze data collected during classical conditioning trials generated by the Runtime program. These programs analyze and
generate printouts of blocked and session data, and contain routines for summarizing and generating pictures of behavioral and
discriminated neural data. After each trial presentation during the Runtime phase, raw digitized behavioral data and
discriminated neural data for each trial are stored to floppy disk and 11 standard dependent measures are calculated and stored in
RAM. These dependent measures include: CR amplitude, area and peak latency, UCR amplitude, area and peak latency, PreCS
baseline activity, and discriminated unit activity for PreCS, CS and UCS periods. The Summary programs can use data from
RAM, from a Data disk, or from a Library disk to calculate blocked and session totals. After the classical conditioning session, it is
a good idea if the computer is not turned off or rebooted until after the data have been summarized since the data in RAM is lost
when the computer is turned off or rebooted. However, do not be concerned if the power should inadvertently fail before the
summary is executed since the data can be recovered from the Data disk. Here is a brief overview of the summary process:
1) The user selects a summary option (usually Summary Option 3).
2) Information about values of variables used during the runtime phase is entered (number of trials, number of blocks, number of
trial types).
3) A trial type table is selected and loaded.
4) The trial-by-trial data are brought into main memory and arranged into blocks.
5) Session and block totals are calculated.
6) The session and block data are printed.
7) The dependent variables for each trial are stored on a Library disk.
Before continuing with a discussion of how to use the summary programs a few words concerning the Library disk are
in order. A Library disk is actually an archive of dependent measures obtained on each trial during the run. It is valuable since
session summary printouts can be obtained from the Library disk if the session printouts are inadvertantly misplaced. It is also
(c) copyright 1995 Dave Lavond. All rights reserved.
24
useful for reanalyzing data with a different blocking scheme, a different CR criterion, a different bad trial criterion, etc. The
Library disk does not, however, contain raw digitized data. The Library disk contains the results of computations made with
parameters at the time of analysis, so you cannot change the intrastimulus parameters if you reanalyze. Therefore, if you want to
save the raw trial-by-trial behavioral and neural responses, you must save the data disks or back-up the session data on magnetic
tape during the run. You must have the raw data (Data disk) in order to do a Graphics review (Summary option 8, below). See the
Runtime documentation for directions on how to create a Library disk.
22.2 Using the Summary Programs
There are three ways to enter the summary programs: 1) After completing the runtime phase, a message asking "Do
you wish to summarize the data (Y)?" is displayed. Press Y to see the summary menu. 2) If you are in Forth, you can type using
a:summary<return> (in Forth you can also type summarize-<return>). If the program disk is in drive A, the summary menu will
be displayed. 3) If the Runtime menu is displayed, you can choose option 8 to enter the summary phase. Since most of the time a
summary is desired immediately after a session, the most frequently used Summary option 3. The following is a description of
each of the options displayed on the summary menu. The options listed are:
Select analysis from this list:
1. Analysis from raw data stored on a DATA disk
2. Analysis from data stored on a LIBRARY disk
3. Analysis from data stored in RAM
4. Analyze data, store in LIBRARY, no printout
5. Create a new trial type table
6. Display contents of a LIBRARY disk
7. Move data from LIBRARY disk to RAM
8. Graphics review of a DATA disk
9. Reset system and summary parameters
10. Move data from RAM to a LIBRARY disk
11. Serial communications
12. Convert data file to ascii for spreadsheets
13. Graphics review with correlations of DATA disk
14. Standard Z-scores analysis of DATA disk
Enter Selection Number: 0<return>
Ready
flush<return>
Figure 22.2: Summary Opening Menu showing 14 options and the effect of choosing option 0 (the hidden
option) to exit the Summary program. Notice that all files were closed with flush<return>.
23 Summary Option 0: Exit Summary, Enter Forth
This is an unlisted option. Typing 0<return> will cause you to leave the Summary Menu and enter into Forth. This is
handy if you need to change the options for automatic loading of parameters (see auto) or the terminate-stay-resident (see tsr)
functions of screen 1 of the Summary file. After editing these (or other) parameters, and if you have not closed the file (i.e., not
typed "flush<return>") you can reenter the Summary program by typing 1 load<return>. If you have typed flush<return> you
can reenter the Summary program by typing summarize<return>, which is how the runtime program option 8 gets to the Summary
program.
24 Summary Option 1: Analysis from Raw Data Stored on a Data
Disk
This option summarizes data stored on a data disk during the runtime phase. After selecting this option, you first enter
three pieces of information: how many trials were delivered during the run, how many blocks the trials must be grouped into, and
how many trial types are represented in each block (e.g., if each block is made up of one CS-alone presentation and 8 paired CS
and UCS trials then there would be 2 trial types). Next, you must select a trial type table which represents the arrangement of trial
types within a session (see option 5 for information concerning creating the trial type tables). After loading the trial type table, you
are directed to place the data disk in the data drive and press a key to continue. Each trial is then loaded into main memory, the
dependent variables are calculated, and routines for printing out the results are loaded. Make sure the printer is on-line since the
printout is generated immediately after this portion of the program is loaded.
The calculations made by the Summary program are based upon those parameters found at the end of the
SUMMARY.SCR file (using summary size 1- edit<return> -- see Summary Option 9). The Runtime and Summary programs do not
share parameters. This way, you can intentionally or unintentionally analyze the same data with different parameters. Usually, it
is unintentional, in that the user forgets to make sure that the Runtime parameters are entered into the Summary program. Check
the parameters before analyzing the data.
After the printout has been generated you are directed to place a Library disk in the library drive and press a key to continue. If
the Library disk is full (the program determines this) you are directed to insert another Library disk. It is important to keep a good
supply of Library disks since every session eventually gets stored on a Library disk. On the average, each Library disk will hold 5565 sessions (depending on the number of trials per session). At this point the dependent measures calculated for each trial are
stored on the Library disk and you are directed to reinsert the program disk and press a key to continue.
(c) copyright 1995 Dave Lavond. All rights reserved.
25
See the section "Explanation of Summary Printout".
25 Summary Option 2: Analysis from Data Stored on a Library
Disk
This option allows you to analyze dependent measures previously stored on a Library disk. Although rarely used, this
option has been included in case you lose a printout or want to reanalyze the data with different values for certain variables. To
use this option you must know where on the library disk the data you wish to analyze is located (see option 6). After selecting this
Option 3, you are directed to enter the number of trials, blocks, and trial types, and select the trial type table to be used. You are
then directed to place the Library disk in the library drive and enter the number of the information screen which identifies the
session you wish to analyze (from option 6). After entering this number and pressing a key the trial-by-trial data are transferred
into RAM, the session and block data calculated and a printout generated.
See the section "Explanation of Summary Printout".
26 Summary Option 3: Analysis from Data Stored in RAM
This option is the quickest and most frequently used method for summarizing data since it works on dependent
measures calculated and stored in RAM after each trial during the run. After selecting this option, and if the automatic feature is
turned off [Summary screen 1 auto off] you are directed to enter the number of trials, blocks and trial types, and then asked to
select a trial type table. The data from RAM is then transferred into main memory, the session and block data calculated and a
printout generated. You are then directed to insert a Library disk in the library drive, the dependent measures are transferred to
the Library disk, and you are directed to reinsert the program disk and press a key. Using this option, a 100 trial summary with 10
blocks and 2 trial types can be completed in under 2 minutes with a slow IBM computer like mine.
Since Summary Option 3 uses the calculations of the data stored in RAM, those numbers are based upon the analysis
done by the Runtime program and its parameters. If the Summary parameters (Summary Option 9) are different than the Runtime
parameters, then the printout will be a combination based upon both the Runtime and Summary parameters, which will yield
unpredictable results. This is because the Runtime program calculates values based on its parameters, and the Summary program
takes those calculations and interprets them according to its parameters. Probably the worst thing you could do is have the
Runtime and Summary binwidths be different. The moral of the story is, to get consistent results, both run and summarize the data
with the same parameters.
See the section "Explanation of Summary Printout".
27 Summary Option 4: Analyze Data, Store on Library Disk, No
Printout
This option is identical to option 1 except no printout is generated after the analysis (the data are only stored on the
Library disk). This option was included in the event that you may want to analyze data on a computer that is not equipped with a
printer.
28 Summary Option 5: Create a New Trial Type Table
To perform any analysis, the Summary program must know the order of trial type presentations used during the run.
There is an easy way and a hard way to do this.
28.1 The Hard Way Warning: Before you do this the hard way, you might want to just read through this and through the easy
way, then make a choice. This option allows you to create and store, within the Summary program, up to 12 trial type tables which
are eventually displayed during the summary
process.
As currently configured, the Summary program can analyze classical conditioning sessions which have up to four trial
types (e.g., sessions during which tone and light CSs were presented both alone and paired with an airpuff UCS). You can also
create and store tables to be used in conjunction with sessions which presented three trial types (e.g., tone alone, air alone, and
tone-air trials), two trial types (e.g., tone alone, tone-air trials), and one trial type (e.g., tone alone extinction or UCSs alone). You
can store up to four tables of four trial types, four tables of three trial types, and four tables of two trial types. If you only have one
trial type you do not have to specify a trial type table because the program does not have to separate trial types before performing
the analysis. For example, you might store four different tables of two trial types (e.g., 90% paired tone-air trials with 10% tone
alone trials; 50% paired tone-air trials with 50% tone alone; explicitly unpaired tone and air presentations; and alternating
presentations of tone and light alone trials). After creating four tables for a specific number of trial types, the tables can be
replaced by other tables you create by merely writing over tables that have already been created and stored.
Here is how you create a trial type table. Select option 5 and read the brief instructions provided. When prompted,
enter 1) the number of trial types to be defined in your table (i.e., 2, 3 or 4), 2) the number of blocks of trials to be included in the
trial type table, 3) the number of trials contained within each block, and 4) which trial type series you are creating (a series is
defined as a number from 1 to 4 that identifies which particular table you are creating for the desired number of trial types). After
entering this information the computer will display the trial type table currently residing in the series space that you wish to use (if
there has been one previously created there). Next, you are asked to enter one block of trials for the new trial type table. At this
point, enter a series of 1s, 2s, 3s or 4s depending on the number of trial types you want to be included in your trial type table.
Consider the following examples:
Example 1. You want to create a trial type table for 10 blocks of 10 trials with each block composed of 90% paired tone-air trials
with 10% tone alone presentations. You would input a 2 for the number of trial types, 10 for the number of blocks, 10 for the
number of trials per block, and let's say that you are making this table 4 in this series (e.g., you have already defined 3 other series
(c) copyright 1995 Dave Lavond. All rights reserved.
26
using 2 trial types). To create this trial type table you would input 1222222222 when asked to enter a block of trial types (where 1
represents a tone alone trial and 2 is a paired tone-air trial, or the other way around). After entering theblock and pressing
<return> the computer will show you the whole table which would look like this:
12222222221222222222122222222212222222221222222222
12222222221222222222122222222212222222221222222222
Example 2. You want to create a trial type table for 6 blocks of 10 trials with each block composed of 4 paired tone-air trials, 1
tone-alone trial, 4 paired light-air trials, and 1 light-alone trial. You would input a 4 for the number of trial types, 6 for the
number of blocks, 10 for the number of trials per block, and maybe 2 to identify which series of 4 trial types you are creating (e.g.,
this is the second series you define with 4 trial types). To create this trial type table you would input 1111233334 when asked to
enter a block of trials (where 1 represents a tone-air trial, 2 is a tone alone trial, 3 is a light-air trial, and 4 is a light alone trial, for
example; the meanings of the numbers are arbitrary -- this causes a slight problem for the review, option 8, when putting cursors
on the screen). After entering the block and pressing <return> the computer will show you the whole table which would look like
this:
111123333411112333341111233334111123333411112333341111233334
After the computer displays the table you have created, you will be asked to enter a description of the trial type table. It
is very important that you type in a message (up to 64 characters long) that describes the table you just created (e.g., "90% Paired - 100 trials") because when you eventually run a summary of your data this message will be displayed along with the three other
messages for this particular number of trial types to allow you to choose the appropriate series used for the analysis. After typing
in this message the program will return you to the main summary menu.
28.2 The Easy Way Instead of fooling around with this option I just use the editor. Edit the screen used to store the label with size
6 - edit<return>. Edit the screen for two trial types with size 4 - edit<return>, for three trial types with size 3 - edit<return>, and
for four trial types with size 2 - edit<return>. The top 4 lines of each screen are for the first choice (of 2, 3 or 4 trial types), the
next 4 lines of each screen are for the second choice (of 2, 3 or 4 trial types), the next 4 lines of each screen are for the third choice
(of 2, 3 or 4 trial types), and the last 4 lines of each screen are for the fourth choice (of 2, 3 or 4 trial types). Save the changes with
^N.
If you do this option you must enter all trials, not just one block of trials. And if you get out of sequence, then your
analysis will be messed up.
SCR# 79
90% paired (122222222)
75% paired (12212222)
unpaired (122112122112122121)
christy’s
cold probe study (122232222)
unused
unused
unused
tone/light blocks (1221222234434444)
shock-us repl (1222234444)
unused
lidocaine test (TLTLTLTLLTTLTLT)
NOTE: each number for a trial type has 4 options (1/line):
lines 1-4 for sessions with 2 trial types.
lines 5-8 for sessions with 3 trial types.
lines 9-12 for sessions with 4 trial types.
Figure 28.2a: The list of titles you assign to the trial type tables is stored on this screen (here, screen 79) of the
summary file. You either use Summary option 5 or directly edit this screen.
(c) copyright 1995 Dave Lavond. All rights reserved.
27
SCR# 81
1222222221222222221222222221222222221222222221222222221
2222222212222222212222222212222222212222222212222222212
2222222122222222122222222122222222122222222122222222122
222222122222222122222222122222222122222222
12212222122122221221222212212222122122221221222212212222
12212222122122221221222212212222122122221221222212212222
12212222122122221221222212212222122122221221222212212222
12212222122122221221222212212222122122221221222212212222
12211212211212212112211212211212212112211212211212212112
21121221122112122112122121122112122112122121122112122112
12212112211212211221121221121221211221121221121221211221
1212211212212112211212211221121221121221211221121
12222222221222222222122222222212222222221222222222122222
22221222222222122222222212222222221222222222122222222212
22222222122222222212222222221222222222122222222212222222
2212222222221222222222
Figure 28.2b: Example screen (here, screen 81) showing four trial type tables (256 trials maximum for each
trial type) with two trial types. In this table, they could be anything, but a 1 represents a tone alone trial, and a
2 represents a paired tone-airpuff trial. For all the program cares, a 1 could represent making a peanut butter
sandwich and a 2 could represent a bicycle ride. You either use Summary option 5 or directly edit this screen.
[Since I am typing this screen in using a word processor, instead of using an actual screen, there may be
error(s) in the patterns of the numbers -- the important point is to get the sense of this screen.]
28.3 Limitation of All Methods
Note that the maximum number of trials allowed per table (i.e., maximum number of trials per analysis) is currently
256.
28.4 The Meaning of Numbers
For your reference the following is copied from the description of Summary option 8.
The Runtime program defines a tone alone trial, paired tone-air trial, light alone trial, paired light-air trial, and air
alone trial as having values of 1, 2, 3, 4, and 5 respectively (this is how BLKSUM(A) and BLKSUM(B) work). But for the
Summary programs the numbers 1, 2, 3, 4 and 5 have no intrinsic meaning. The number of trial types that you enter (e.g, 2 trial
types), however, limits the range of usable numbers. That is, if you have 2 trial types then you must use only the numbers 1 and 2.
If you have 4 trial types then you must use only the numbers 1, 2, 3 and 4.
29 Summary Option 6: Display Contents of a Library Disk
This option automatically scans a Library disk and reports where your data have been stored. Individual sessions stored
on the Library disk are identified by the descriptive comment you entered with option 2 of the Runtime program (i.e., the comment
you entered before starting the runtime session). (However, if you stopped the run short of its natural end, e.g., by typing
abort<return> from the interpreter, this comment is not properly stored to the Library disk.) Normally, after typing the comment,
it is written by the computer to two places: 1) on screen 0 of the data disk (at the end of a normal run), and 2) in the first 64 bytes
of RAM (to what IBM calls Segment 2 RAM, or the third 64k bank of RAM; DOS and the Forth program are in Segment 0 RAM).
During the Library disk storage phase of the summary process (either from the Data disk or from RAM) the comment is
transferred to the Library disk for your future reference.
The function of this option of the summary program is to locate the screen number that marks the beginning of a
particular session's data on the Library disk. After selecting this option, you are directed to place the Library disk in the library
drive and asked if you want a printout of the starting screens and comments for the various sessions stored on the disk. If you
want a printout press any key except "N". If you want it displayed on the screen only, press "N". You should then see displayed
on the monitor or printer the comments for the sessions you previously stored on the Library disk being scanned. After scanning
the disk, you will be asked whether or not you want to see a list again (e.g., if you want to list another Library disk). Answer "Y"
or "N". If you answer "N", the main menu for the Summary programs will be redisplayed.
This option is useful if you want to use option 2 of the Summary programs (analysis from data stored on a Library disk)
since option 2 requires you to identify the Library disk starting screen for the particular session data you wish to (re)analyze. This
option is also useful for creating printed catalogs of data stored to Library disks.
30 Summary Option 7: Move Data from Library Disk to RAM
This option allows you to transfer data from a Library disk to RAM (i.e., summaries of dependent measures calculated
for each trial). This option was included for debugging purposes, and is rarely used for that, and so it is not very useful to the
average user. This feature may be deleted in future versions of the Summary program to make room for other features.
(c) copyright 1995 Dave Lavond. All rights reserved.
28
31 Summary Option 8: Graphics Review of a Data Disk (with Laser
Printer for Pictures)
This popular option allows you to graphically review and/or summarize data that you have collected and stored on a
Data disk. You can create pictures of behavioral data and unit histograms (i.e., averages of behavioral data and summated unit
histograms) for any range or subset of trials stored on a Data disk. These results can then be saved on a Graphics storage disk.
With the aid of a resident screen dump program (e.g., the separately purchased Grafplus) or a HP Laserjet printer you can get a
hard copy of an individual trial or of an average of several trials. This is one program that is often rewritten with improvements
and new features.
To use this option, you must have 1) the raw digitized data that is written during the runtime to the Data file (i.e., this
option does not work for summarized dependent measures stored on a Library disk), and 2) a Graphics file (see instructions in the
Runtime documentation for making these disks). These files must exist before invoking the review program.
Select option 8 from the Summary menu to load in this program. The review program is compiled and the default
values (e.g., #a/d, bin, pts, etc.) for summary analysis are loaded (see option 9, reset system and summary parameters). At the end
of compilation you will see a message Type FLUSH<return> and REVIEW<return>. FLUSH closes the Summary file and REVIEW
starts the program. You can, in fact, review as many different Data disks as you like without recompiling the review program from
the Summary disk.
After typing review<return> the display changes to graphics mode, lists the current default directory, and asks for
information about the Graphics disk. Press <return> if you are using the default file GRAPHICS.SCR on the current drive, or
enter the drive and name of any other graphics file and <return>. You are then asked about the Data disk. Press <return> if you are
using the default DATA.SCR file on the current drive, or enter the drive and name of any other data file and <return>.
Here are two quick examples. First, if you are currently on drive A and have a Graphics file on drive A and a Data file
on drive B, then when asked for a Graphics file simply press <return> and when asked for a Data file type b:data.scr<return>. In
a second example, you are currently on drive A and you have the Graphics file named MYGRAPHS.NO1 on drive B and the Data
file named MYDATA.NO2 also on drive B. In answer to the question about the Graphics file type b:mygraphs.no1<return> and
answer b:mydata.no2<return> to the question about the Data file.
In its latest incarnation, the review program is more flexible about the names of the files used. The original version,
like the Runtime and Summary programs, required the generic files named DATA.SCR for the raw data and GRAPHICS.SCR for
storing picture averages. This simplified programming and user applications. These are still the defaults (i.e., pressing <return>
will cause the computer to assume that these are the proper filenames; one caution, however: the computer will also assume that
the files are on the default drive, so you must specify the drive and file name if otherwise, as in B:DATA.SCR). You may have
renamed your Graphics file or your Data file to protect them so that they would not be accidentally written over; i.e., by renaming
the files so that they are not GRAPHICS.SCR and DATA.SCR you can save the information without worrying about the program
accidentally writing over the data. Previously, you had to re-rename these files back to GRAPHICS.SCR and DATA.SCR in order
to use any Summary program. This is no longer necessary for the review program. This feature will probably never be
incorporated into the Runtime program so that generic files will always be used.
Both a data file holding the raw digitized data and a graphics file to hold averaged pictures must be specified even if you
only want to look at the individual trials (the data file) or the averages (the graphics files). In this instance, make a "dummy" file
to pretend to hold data before invoking the review program.
After specifying these files the review program will display the first trial from the data disk. Note that the trial is
displayed and you will see the message "Continuous Off". The display also shows you the directory and filename for the data you
are viewing. You now have a variety of functions available at your command. Type ? to see a list of some of these options (all of
the possibilities will not fit on the screen). Here is a list of functions:
31.1 To Start
review
prompts user for Data and Graphics files, turns PRINTING
OFF (i.e., disables laser printer; Press <escape> and type
printing on<return><return> to turn on the laser printer
back on -- yes, that is <return><return>), and displays
the first trial.
[Note: The command printing on allows the screen print function
(see p below) to send the output to the printer. The command
printer on directly turns on the printer as the output device rather
than the monitor -- this is something you probably do not want to do.
Notice the difference is between -ing versus -er.]
31.2 To End
e
exit the review program. You can analyze another data
disk by again typing review<return>. you can also
exit by pressing <escape> and typing theend<return> -yes, this is one word.
31.3 General Control
1,2,3,4
toggle for a/d measurements. For example, if there are 3
a/d channels, pressing 1 will show the calculations
for the first a/d channel, 2 shows the second a/d
(c) copyright 1995 Dave Lavond. All rights reserved.
29
channel, 3 shows the third a/d channel, and 4 will
show no change (it would show the fourth channel if
you selected 4 #a/d !).
c
toggle continuous on or off: continuous off means that you
view one trial for each press of a cursor key;
continuous on means that the program will
automatically advance through trials until told to
stop or until the beginning/end of the session is
reached. The continuous feature modifies many of the
cursor control keys below.
d
change default drive.
k
change the speed at which trials are recovered from the
disk when continuous on. When prompted, enter a value
within the range 0 (fastest) to 65535 (slowest).
Practically speaking, a value of 100 is a reasonably
slow speed. Pressing any key during the count will
automatically skip the count and go to the next trial.
<escape> call for the interpreter. Besides the normal Forth
commands and variables you can invoke, you may find
the following commands useful. The command 1 units or
2 units safely changes the number of displayed units
from 1 to 2 (i.e., changes the variable #units) if you
change data disks. The command 2000 binwidth or 4000
binwidth safely changes the bin duration (the variable
bin) to 2 msec or 4 msec if you change disks. The
command 125 is ceiling changes the screen cut-off for
the unit displays (this is normally set to 25 so that
the units will not overlap the eyelid display). The
commands 1 is unit1x and 5 is unit1/ sets the size of
unit channel 1 to 1/5 (this is useful when averaging
so many trials that the unit display goes way off the
screen). To allow printing to a HP Laserjet printer
type printing on. [You must have the file LASER.SCR
for this function.] Now when you type p you will get
a printout of whatever is on the screen at the time.
It will take several minutes to transfer the data to
the printer and to print it out. You can also exit
from the interpreter by typing theend (one word).
[Typing flush<return> is a good idea, otherwise you
might get an error message saying something like "Too
many files".] Hitting <escape> a second time is the
same as typing abort. To leave the interpreter and
reenter the review program, type <return> on an
interpreter line by itself.
p
print the current graphics screen to a HP Laserjet
printer. See <escape> above and the later section
"Printing the Picture to a Laser Printer".
31.4 Moving from Trial to Trial
down arrow
advance to the next trial(s) (operates with continuous
on/off).
up arrow return to the previous trial(s) (operates with continuous
on/off).
left arrow stop advancing through trials.
pgup
return backwards through trial(s) by the number of trials
per block (operates with continuous on/off).
pddn
advance to the next trial(s) by the number of trials per
block (operates with continuous on/off).
home
return to the first trial.
end
advance to the last trial of the session.
j
jump to any trial number you enter when prompted.
31.5 Averaging Data
0
b
x
+
zero the array used to accumulate pictures for averaging.
display the averaged array (a square appears in upper
left of the screen).
add a range of trials (prompted) to the accumulation array.
add the currently displayed trial to the accumulation array.
(c) copyright 1995 Dave Lavond. All rights reserved.
30
/
7
8
s
r
l
remove the currently displayed trial from the accumulation array.
divide the number of trials added to the accumulation
array and display.
used in Summary Option 13 only, this activates the
cross-correlation function
automatically zeroes (0) the accumulation array, adds and
averages a range of (prompted) trials, and displays
the block average. (Historically, the * symbol was
used for this function, but I got tired of using the
shift key; 8 is the other character on the * key.)
save the averaged picture to the graphics disk. You are
prompted for a screen number (1 to size 1-) and an
offset (0 or 1 for the first and second halves of the
screen). Each screen can hold 1024 bytes of data.
The Runtime program does not let you collect more than
this without causing problems. If you have less than
half 1024 bytes (i.e., less than 512 bytes) per trial,
then you can save two averages to the same screen, one
average from the top half (offset 0) and the other
from the bottom half (offset 1). You must keep track
of where you need to recall data from.
recall an averaged picture from a graphics disk. You are
prompted for a screen number (1 to size 1-) and an
offset (0 or 1 for the first and second halves of the
screen). Each screen can hold 1024 bytes of data.
The Runtime program does not let you collect more than
this without causing problems. If you have less than
half 1024 bytes (i.e., less than 512 bytes) per trial,
then you can recall two averages from the same screen,
one average the top half (offset 0) and the other in
the bottom half (offset 1). You must keep track of
where you have saved data. Also note that this
picture will be displayed with the cursors of the
current trial that you were displaying before you
recalled an average. To get other cursors for the
block average, jump to a trial with the correct
cursors and recall your data.
edit screen 0 of the graphics disk. You can write
comments here to remind yourself what is on this disk.
You can use the review program to simply look at the data you have collected. Or you can average several trials. There
are many ways to average the data. Here are the methods we use:
31.6 Average a Range of Trials
To average trials 1 through 10, type 8 (to call up the average routine), answer 1 to the prompt STARTING TRIAL and
answer 10 to the prompt ENDING TRIAL, wait for the block display (denoted by the square in the upper left corner). If the laser
printer is on, and you have set PRINTING ON with <escape>, you can type P to get a printout of the screen. (If you have loaded a
resident program like Grafplus before starting Forth, press PRT SC -- print screen.) Type any key to continue. Type S to save the
picture to a graphics disk. Type any other key to see whatever trial you were last on and to continue averaging other pictures. This
assumes that all trials are of the same type (e.g., all paired trials) and that there are no "bad trials" within the range (the review
program will average all trials; i.e., unlike the Runtime program, the review will average in "bad trials"). This option
automatically clears the accumulation buffer every time it is invoked.
31.7 Average Several Trials by Hand
To average some random sequence of trials try the following. Type 0 (zero) to clear the accumulation buffer. Jump (j)
to one of your trials. Press + to add that trial to the buffer. Jump (j) to another of your trials. Press + to add that trial to the
buffer. Let's make a mistake and press + again to add that trial again. Oops. Press - to subtract out that trial. Jump (j) to
another trial and add (+) it. Keep doing this until you are finished. Press / to divide and B to display the block average (a square
will appear in the upper left corner). Save (s), print to laser (p) or continue (any key) with some other task.
31.8 Average Several Consecutive Trials by Hand
To average several trials in a row by hand you could turn continuous on (C), set the speed of viewing to something
reasonable (k, answer 100 to the prompt), zero the accumulation array (0), jump (j) to the first trial, add (+) it, press the down
arrow, and as each picture is displayed you can add (+) it to the accumulation array, press the left arrow to stop, then divide (/) and
display the average (b).
31.9 Average Several Consecutive Trials
(c) copyright 1995 Dave Lavond. All rights reserved.
31
Suppose you have the sequence of trials 122222222122222222 and you only want to average the 2s. You can
accomplish this by zeroing the accumulation array (0), typing x to add a range and answering 2 to STARTING TRIAL and 9 to
ENDING TRIAL to add in the first set of 2s. You are then prompted to type x again to add another range, or / to see the average.
Here type x and answer 11 and 18 as the starting and ending trials. You are then prompted again to type x again or /. Divide (/)
the trials to have chosen and you will see a block (square in upper left) display (b). Save (s), print to laser (p) or continue (any key)
with some other task.
You could accomplish the same average of the 2s in the above example by another method. Zero (0) the accumulation
array. Type x to add a range and answer 1 and 18 to the starting and ending prompts. When the message "type X again, /B or any
key to continue" appears, type any key to continue.
Jump (j) to the first trial. Subtract (-) that trial from the accumulation array. Now either jump (j) to trial 10, or if you
have 9 trials per block you can get to trial 10 by pressing the Page Down key (be sure that continuous is off, otherwise the display
will continue to skip through the trials by the number of trials per block). Subtract (-) trial 10. Now divide (/) and display the
block (square) display. Save (s), print to laser (p) or continue (any key) with some other task. Of course, in this example, you
could have started by only adding in trial 2 through 18 instead of 1 through 18.
31.10 Averaging Averages
Assume that you have separately averaged the first and second halves of a session and saved those averages to a
graphics file, and now you want an average of the whole session. If you have the original data file then you can use one of the
procedures described above. If you only have the averaged data you can do the following. Zero (0) the accumulation array.
Recall (r) the first half from the graphics disk.
You are then prompted to add (+) or subtract (-) the display to/from the accumlation array, or press any key to continue.
Add (+) the picture. Recall (r) the second half and add (+) it. Divide (/) and display the block average (square) of the averages.
Save (s), print to laser (p) or continue (any key) with some other task. Mathematically you must be careful about doing this
procedure. To be correct the averages used for both halves should each have been based upon the same number of trials,
otherwise the final average picture is biased (weighted) towards the half average that had fewer trials (this may be inconsequential
depending upon the disparity of the numbers of trials between the two halves and upon the size of the numbers in each half).
31.11 What are All Those Numbers?
Note the line of numbers at the bottom of the screen. These numbers correspond to the various response measurements
made for this picture, e.g., CR amplitude, latency and amplitude, etc.
The sixteen calculated numbers for each trial are:
PreCS average baseline for eyelid channel 1
PreCS absolute deviation from baseline for eyelid channel 1
CS maximum amplitude for eyelid channel 1
CS cumulative area for eyelid channel 1
CS peak latency to maximum amplitude for eyelid channel 1
UCS maximum amplitude for eyelid channel 1
UCS cumulative area for eyelid channel 1
UCS peak latency to maximum amplitude for eyelid channel 1
latency to 0.5 mm or greater response in CS period
PreCS count of unit channel 1
CS count of unit channel 1
UCS count of unit channel 1
PreCS count of unit channel 2
CS count of unit channel 2
UCS count of unit channel 2
PreCS positive area for eyelid channel 1 [never used for anything]
If there is a second eyelid channel then the 16 numbers repeat, and so on for additional channels. Typing 1, 2, 3 or 4
will show the numbers for those a/d channels respectively (assuming that #a/d is set to that number or greater) in the older
versions of the Runtime/Summary programs.
31.12 A Note about the Cursor Display
The Graphics disk, like the Data disk, stores only the data used to make the pictures on the screen. Neither disk stores
information about timing or about the kind of trial (tone alone versus paired trial, for example). That is why you have a "trial type
table" in which similar trials are identified by a series of 1s, 2s, 3s or 4s. There is no trial type table for the Graphics disk, so when
you recall a picture that you have previously stored the program assumes that the averaged picture is the same type as currently
displayed from the Data disk. Therefore, if you are displaying a paired trial and recall an averaged picture, then you will see the
cursors for a paired trial on the display. If that is not what you want then move (e.g., by jumping (J)) to a trial of the correct type.
However, there is another discrepancy. The Runtime program defines a tone alone trial, paired tone-air trial, light
alone trial, paired light-air trial, and air alone trial as having values of 1, 2, 3, 4, and 5 respectively (this is how BLKSUM(A) and
BLKSUM(B) work). But for the Summary programs the numbers 1, 2, 3, 4 and 5 have no intrinsic meaning. The number of trial
types that you enter (e.g, 2 trial types), however, limits the range of usable numbers. That is, if you have 2 trial types then you must
use only the numbers 1 and 2. If you have 4 trial types then you must use only the numbers 1, 2, 3 and 4.
The review option of the Summary program uses the display routines from the Runtime program. You can see the
problem, then, if you have only 2 trial types in the Summary program and those trials are unpaired tone and air trials. You must
(c) copyright 1995 Dave Lavond. All rights reserved.
32
use 1 and 2 to segregate the sequence, but the Runtime program interprets a 1 as a tone-alone trial and a 2 as a paired tone-air
trial. Therefore, the cursors displayed on the screen will be incorrect for the air-alone trials.
This is not a disaster since the cursor information is not a part of the stored data, so you could ignore the problem.
Alternatively, for the review option, you could define a trial type table (Summary option 5) that is compatible with the Runtime's
interpretation of these numbers (but do not try to analyze the data with other Summary routines). Or, with some knowledge of
Forth, you could temporarily change the trial type table for the correct display. Or, as explained in the next section, you can fool
the review program into displaying another set of cursors.
31.13 Printing the Picture to a Laser Printer
There are two types of graphics pictures you may want to have a hardcopy: individual trials and block averages. Both
methods require that you have the file LASER.SCR and that you have activated the printing function by <escape>ing to the
interpreter and typing printing on<return>.
For printing individual trials you then just press p. It will take a few minutes to transfer the data. You will see the
"ready" light of the printer flashing during the transfer. At the end of the transfer the printed page will be ejected and the
program will beep (actually roadrunner) back to you. You can make as many prints of any trials as you wish as long as printing is
on.
Sometimes the cursors are in the wrong place for a trial. I have usually seen this with air alone test trials having the
cursor placed at the beginning of the trial instead of in the correct place. This is due to an incompatibility between the Runtime
and Summary programs. There are a several possible solutions if you want a picture with the correct synch pulse for the air.
First, one solution is, from the interpreter <escape>, to type air drawing mirage<return>. Second, if you have tone alone, air
alone and paired tone-air trials, but not light alone trials, you can do the following trick in the interpreter: set lton to be the mark
for the air alone trials with shkon is lton<return> and exit the interpreter back to the review program with another <return>. Now
press p just as you normally would. The advantage of the latter is that once you make the change then all air alone trials will show
the cursor until you reload the review program again.
To print the numbers along with the drawing for an individual trial, for example for trial 35, you could use the
following command: 35 get drawing reading mirage<return>. This is done automatically if you are viewing trial 35 and you press
p after making printing on.
For printing block averages of trials you must first average the trials you are interested in. You must then display the
last trial (not the block you were just on. You do this so that you can get to the interpreter. Press <escape> to get to the
interpreter. Now type blockdisplay mirage<return> and wait for the printout.
To print both the graphics and the numbers for the block display use the following after pressing <escape> to get to the
interpreter. Type blockdisplay blockmeasurements reading mirage<return> and wait for the printout. The numbers are shown
without headings, but correspond to those seen for individual trials. Also, there is no indication printed that tells you what trials
you have averaged, so you are advised to manually write this on the printout.
Since the stimulus cursors for the block display are derived from the currently displayed individual trial, the cursors
may not be correct for the block display. One way to fix this is to jump (j) to a trial that has the correct cursors. The other way is
to temporarily trick the review program. For example, suppose you have averaged paired tone-airpuff trials, the current trial is a
tone alone trial, and therefore the block display shows the tone alone cursor and you want both the tone and airpuff cursors. At
the trial display you could do the following: <escape> to the interpreter then type tone-air blockdisplay mirage<return> and you
will get the right picture. The cursor options are: nothing (no cursors), tone, lt (light), air, tone-air, lt-air, tone-lt, tone-lt-air. When
you <return> (by itself on an interpreter line) to the review program from the interpreter the original cursors will be shown.
32 Summary Option 9: Reset System and Summary Parameters
This is an extremely important option. To perform any phase of the summary operation, the program must know the
proper values of variables that are associated with the runtime session. To obtain these values the Summary program uses a
number of variable values left over from the Runtime phase (i.e., values set before the runtime session are carried over to the
Summary phase). However, for a variety of reasons not readily apparent to the user, a number of variable values have to be reset
just before the Summary process is undertaken. The Runtime and Summary programs were purposely designed this way, so that
you could have great flexibility in analyzing the data.
Option 9 of the Summary program is provided to check and/or alter variables used during the summary. After selecting
this option, you will be placed in the editor mode and a screen containing variables and values is displayed. It should look
something like this:
(c) copyright 1995 Dave Lavond. All rights reserved.
33
SCR# 84
756
252
598
252
1
1
25
160
1
0
0
0
new parameters for cold probe study.
1000
250
350
250
3
3
25
160
1
0
0
0
Dragana’s problem.
this screen holds the default parameters:
pts
toneon
toneoff
lton
unit1x
unit2x
badtime baseln#a/d
chan1
chan2
chan3
chan4
598
1
0
504
0
0
598
7
100
4000
5
255
350
1
0
750
0
0
850
7
100
2000
5
255
ltoff
#units
un1
shkon
bada/d
un
shkoff
critlvl
badun
bin.usec
maxeye
Figure 32: The last screen of the Summary program (here, screen 84) showing the top three lines of active
parameters for data analysis. Except for rare circumstances, these normally match the Runtime parameters
exactly. You either use Summary option 9 or directly edit this screen.
Only the top three lines of numbers are values of variables that are defined in the last three lines of the text. As noted in
Summary Option 3, if the Runtime and Summary parameters are different then your printouts will give unusual results. If you
truly want to analyze your data with new parameters then you must use Summary Option 1, Analysis from Data Disk.
Here are what the parameters represent:
pts = trial length in msec (e.g., 3 x 248 msec)
toneon = onset of tone (in msec)
toneoff = offset of tone (in msec) [never used in calculations]
lton = onset of light (in msec)
ltoff = offset of light (in msec) [never used in calculations]
shkon = onset of UCS (in msec)
shkoff = offset of UCS (in msec) [never used in calculations]
bin.usec = bin width (in usec) -- should equal whole msec
unit1x = gain for display of unit channel 1 histogram
unit2x = gain for display of unit channel 2 histogram
badtime = time (in msec) after CS that cannot be a learned response
baseln = amount (in msec) of preCS period used for baseline (from CS)
#a/d = number of a/d channels active (0-4); must total chan1 + chan2 +
chan3 + chan4
#units = number of unit channels active (0-2); must total un1 + un2
bada/d = this number divided by 10 equals the criterion (in mm) for a
"bad trial" (i.e., too much movement during the preCS period).
critlvl = this number divided by 10 equals the criterion (in mm) for a
movement to be counted as a CR.
chan1 = 1 if active, 0 if inactive (no data to analyze)
chan2 = 1 if active, 0 if inactive (no data to analyze)
chan3 = 1 if active, 0 if inactive (no data to analyze)
chan4 = 1 if active, 0 if inactive (no data to analyze)
un1 = 1 if active, 0 if inactive (no data to analyze)
un2 = 1 if active, 0 if inactive (no data to analyze)
badun = if PreCS unit count equals or exceeds this value then it bad it
is considered a "bad trial"
maxeye = a calibration value. For rabbits it is always 255. For humans
it is the maximum eye opening for the subject.
To alter these values, edit the screen as described in the Runtime documentation or in the documentation Forth by
Micromotion. Edit only the numbers, not the variable names. The analysis will not be performed correctly if the values on this
screen do not match the values used during the runtime. When finished altering these values press ^N to save the changes and the
program will return you to the main Summary menu.
It is critically important that the numbers remain within their 8 space fields and that they begin at the leftmost position in
the field. If they get out of alignment then the numbers do not get correctly interpreted and the Summary analysis is all wrong.
Although it is visually obvious if they are out of alignment, it is hard to figure out over the phone.
While the ability to analyze with arbitrary parameters, as this option provides, is very flexible, many users have a great
deal of difficulty making the parameters match in the Runtime and Summary programs. So while this feature will continue to
exist, a future version may preserve the Runtime parameters and allow analysis using those values instead.
33 Summary Option 10: Move Data from RAM to a Library Disk
(c) copyright 1995 Dave Lavond. All rights reserved.
34
This option is included in the event that you may not want to immediately analyze your data after the run, but you may
want to store it on a library disk for future analysis. After selecting the option and entering the number of trials, blocks and trial
types, you will be prompted to insert a Library disk in the library drive and press <return> to transfer the data.
Except for testing purposes, I do not think I have ever used this option, so it is a future candidate for deletion. I have
heard that some people use this to analyze after training with a pseudorandom paradigm, so that the comment can be edited on the
Library disk before printing out.
34 Summary Option 11: Serial Communication
This option loads in primitive words for serial communications. Communication with an external device (e.g., plotter,
modem) would have to be done by hand (i.e., by typing in commands at the keyboard). A more useful implementation is the file for
printing nictitating membrane data to a Hitachi 673 serial plotter. To do that, type including plotter<return> and follow the
instructions (obviously, you need the file PLOTTER.SCR to do this).
The file HEATH.SCR also uses serial communications. This file is specifically designed for collecting digitized data
from the Heath/Zenith SD 4850 Digital Memory Oscilloscope and averaging. The Heathkit digital memory oscilloscopes can be
triggered by the Runtime program to collect data at very fast rates. From Forth we can control the settings of the Heathkit device,
and download data into a Forth data file for further analysis. For example, we collected evoked auditory potentials during the CS
period, and displayed and averaged these (see Zhang's dissertation).
With the HEATH.SCR file loaded, then by typing COM1 WORDS you will see a list of compiled Forth words for
communication. Type AVERAGE, enter a number of trials to collect when prompted, and then you can collect and average data.
The main problems with the Heath system are 1) it can only collect 512 or 1024 data points at a time, 2) there is no external trigger
(only internal triggers), and 3) the serial communication (at 9600 baud) is slow so you cannot rapidly collect data. In these
respects the device from Modular Instruments Incorporated (MI2) is better; however I think the signal averaging software from
MI2 leaves a lot to be desired and the MI2 fast 12 bit a/d that I have seen picks up "glitches" (wild data points even when the input
is grounded). Therefore, I feel the Heath a/d at only 8 bits is better than the MI2.
35 Summary Option 12: Convert data file to ASCII file
This option allows one to convert a Forth binary data file into an ASCII file that can be read by spreadsheet programs
(for library file conversion see Adlibbing). To use this option you must have the file ASKIING.SCR. After the file is loaded then
instructions for its use will appear on the screen. This conversion feature allows you to write new analyses for your purposes by
using the spreadsheet's operations. This also provides a way to export a Forth binary data file to another programming language.
This option is the same as typing including askiing<return>.
For a more complete description see the section on Askiing.
36 Summary Option 13: Graphics Review with Cross Correlations
Refer to Summary Option 8 as the graphics review program is the same here.
The new feature is that you can do cross-correlations on the data. While reviewing data, average one or more trials.
Then press 7 to activate the cross-correlation feature. The cross-correlations always begins with a correlation of two channels in
phase as it was originally collected, and is computed from tone onset to the end of the trial (i.e., excluding the baseline period). In
the next correlation, one of the channels is repositioned by one binwidth and a correlation is computed again. In subsequent
correlations, that same channel is moved one binwidth at a time and new correlations are computed. The maximum number of
correlations that can be computed depends upon the duration of the baseline (PreCS) period. That is because in order to compute
all the correlations based upon the same number of pairs of observations, data points from the baseline (PreCS) period are added
to the beginning one of the channels, and the same number of data points are dropped off the end of that same channel. [The data
is not really lost, it is just not used in the calculations.]
Therefore, you will be given the opportunity to select the data channels for the "fixed" and "lagged" channels. The
"fixed" channel is nonmoving in the sense that the baseline (PreCS) data will never be used in the calculations. The "lagged"
channel repositions itself by adding points from the baseline (PreCS) period and drops off data points at the end of the trial. One
channel can be both the fixed and the lagged channels: this is an autocorrelation. It might be useful if there is some repetitive
character to the data (this is like a Fourier analysis). Normally, you would do a cross-correlation between the behavior (nictitating
membrane/eyelid) and a unit channel (either neural units or EMG). Because you are normally interested in whether unit activity
precedes the behavior, the fixed channel should be the behavior and the lagged channel should be the unit activity.
The total number of correlations calculated is equal to the total number of points in the baseline (PreCS) period (plus
one, which is the zero lag). This can give a rather lengthy printout. Since the forth word NUF? has been included in the
definition, you can cut short the printout by pressing <escape><escape>.
(c) copyright 1995 Dave Lavond. All rights reserved.
35
Cross-, auto- & correlations are only done on averaged data.
The currently available data arrays & defaults are:
A. a/d 1 ---------- fixed array
B. unit1
C. unit2 ----------- lagged array
D. unit3
Enter <return> to accept these deaults
Press any other key to change defaults
E:\DAVE\FORTH\DATA.BOB
lag
r
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
.
.
.
.3865
.4199
.4513
.4825
.5120
.5389
.5659
.5943
.6170
.6372
.6535
.6665
.6718
.6718
.5853
.6876
.6905
.6891
.6880
.6840
.6799
.6750
.
n
msec
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
126
0
4
8
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
84
.
Figure 36: Cross-correlations in the graphics review option (Summary option 13) can only be done on
averaged pictures. Here, I averaged the last block of paired trials and set the fixed (nonmoving) array to be the
eyelid data and set the lagged unit channel to be the second unit data. The highest correlation is 0.6905 at the
16th time lag (i.e., the unit activity best predicts the behavior by 64 msec). The number of paired observations
is always 126 (63 bins in the CS period plus 63 bins in the UCS period at 4 msec per bin, or 504 msec total; the
lagged channel adds bins in the PreCS period to the beginning of the pairs and drops off an equal number of
bins from the end of the UCS period). One should be cautious about taking the correlations too seriously: I
doubt that there are significant statistical differences between correlations.
Since I am typing this in rather than using the actual printout, I am not showing all the data. But the
numbers I am using are real. Is 0.6905 (lag 16) different from 0.6891 (lag 17), or from 0.5943 (lag 7), or from
0.3865 (lag 0)? [I actually did this test, and if I remember correctly, the 16th lag is significant from no lag, but
not from any other lag (lags 1 through 15).] In fact, with 124 degrees of freedom (N-2), all of these
correlations are significant by themselves at the p<.01 level (for the talbe where df-100, the critical r value is
0.254).
37 Summary Option 14: Z-score Analysis
Every data channel can be analyzed by z-scores. To do this you must have the file Z.SCR and FLOAT.RLF (the
floating point extension). The most complex part about this option is dividing the trial into epochs for analysis. Most of this
writeup here is about that problem.
For this analysis to work properly you must be able to divide each trial into equal time epochs. For example, in my
usual Runtime the PreCS (baseline), CS and UCS periods are all 252 msec. But this is not what I mean about equal time epochs.
What I mean is that each of these 252 msec periods can be subdivided into 3 epochs of 84 msec each. [For independence, you
must make sure these epochs are not overlapping (i.e., no epoch shares any data points with any other epoch).] The z-score
program basically compares the activity in these 84 msec epochs to each other. To do this, one of the epochs is used to calculate
the expected mean and standard deviation over all trials -- I use the last 84 msec of the PreCS period. The z-score is then
(c) copyright 1995 Dave Lavond. All rights reserved.
36
calculated by subtracting this mean, in turn, from the values of the other 84 msec epochs and dividing that by the standard
deviation. I calculate z-scores for the 3 CS and 3 UCS epochs for each trial. If a z-score in the middle and last CS epochs exceeds
the critical level for p<.05 one-tailed test then that trial is considered to show a learned response.
A session analysis by block is computed by averaging trials and computing z-scores on those values. While the last 84
msec epoch of the PreCS period is used to calculate the mean and standard error for the whole session, the block analysis allows zscores to be calculated for the block averages of the PreCS epoch as well. This allows you to see is the baseline changes from one
block to another. The 3 CS and 3 UCS z-scores for the blocks are calculated by using the same mean and standard errors.
Finally, a block analysis is done by calculating the mean and standard deviation on the basis of only those trials that
are used in the block. Therefore, the first z-score for the PreCS epoch will always be zero (the mean subtracted from itself). This
analysis is important when the baseline is expected to deviate from block to block, for example, when each block represents a new
recording electrode location, or when each block represents normal functioning or when a temporary lesion is created and
returned to normal again.
In loading this feature, the program will stop for you to edit Summary screen 10. This is where the epochs are defined.
I have the screen set up so that it automatically divides the periods into thirds and sets the start and end bin numbers for each
period. You could just as easily plug in the numbers directly [it might make more sense to you].
Here is a simple example. Suppose you collect 756 msec of data per trial using 4 msec time bins (4000 bin !) so that
after 756 scale pts the value of pts is 189 (you can see this by typing pts . in Forth). We can then divide the whole trial into 9
successive 84 msec periods. The tone comes on at 252 msec (252 scale toneon) and the airpuff arrives at 504 msec (504 scale
shkon), so that the values of tone and shkon are 63 and 126. In other words, since the bins are 4 msec each, the trial begins at bin
0, the tone comes on at the 63rd bin, the shock arrives at the 126th bin, and the end of the trial occurs just before bin 189 (because
the first bin is considered as bin 0 and not bin 1). The CS period is from bin 63 to bin 126, or 63 bins long. We want to analyze the
first, middle and last thirds of the CS period [it could be any division from 1 to 63 in this case, but we figure that thirds are
computationally sound and experimentally relevant]. One third of 63 yields epochs of 21 bins.
In this example, then, the baseline epoch goes from bin number 42 to bin 62 inclusive. Thus, we use the following
command on screen 10 of the Summary file: 42 , 63 , \ e.g., PCS3/3 = SD,mean. There are several things to note here. First, the
spacing is critically important. Second, the commas (,) are necessary. Third, the backslash (\) and everything following it are
comments and unimportant for the actual functioning of the z-score program. More simply, the first CS epoch is 63 , 84 ,
indicating bins 63 through 84 inclusive. You would have to do the same procedure for all the periods you were interested in. You
do not have to do the whole trial. If all you wanted to do was the baseline and the first CS and first USC epochs then all you need
on screen 10 is
4 constant d#bytes
create ranges 0 , 0 , here
42 , 63 ,
63 , 84 ,
126 , 147 ,
here swap - d#bytes u/ ranges !
Everything else on the screen is comment or needed for automatically figuring the periods out.
In order for the automatic feature to work correctly the CS period in milliseconds must be evenly divisible (i.e.,
absolutely no remainder) by the bin (in msec) and then evenly divisible (i.e., absolutely no remainder) by 3 (for thirds of the
period). In the example above, on a calculator 252 divided by 4 divided by 3 (which equals 252 divided by 12) is 21 with no
remainder. [Mathematically it is ((252/4)/3) = 21].
To continue with the program, type ^N to exit the editor. The rest of the program will load and give you instructions in
its use. The default is to print 12 blocks (#blks) at 9 trials-per-block (#t/blk), which you can change manually or by editing
Summary screen 11.
Please note that the z-scores print out "??" if there is only one trial involved in the calculation (e.g., if there is only one
of that trial type in the block or only one good trial in the block). This is not an error -- the z-score cannot be calculated (the
denominator is n-1, or zero -- an error would result).
SCR# 10
03sep88dgl/04jul89dgl
\ ranges
variable #periods
: 3rd ( --n) 3 #periods ! toneon 3 / ;
4 constant d#bytes
create ranges 0 , 0 , here ( will hold #ranges = ranges @)
toneon
dup 3rd - swap , , \ e.g., PCS3/3 = SD, mean
shkon 3rd - 3rd - dup 3rd - swap , , \ CS1/3
shkon 3rd dup 3rd - swap , , \ CS2/3
shkon
dup 3rd - swap , , \ CS3/3
shkon
dup 3rd +
, , \ UCS1/3
shkon 3rd +
dup 3rd +
, , \ UCS2/3
shkon 3rd + 3rd +dup 3rd +
, , \ UCS3/3
here swap - d#bytes u/ ranges ! \ store # of ranges; e.g., 7
\ Instruction:
\ Make certain the differences for each range are the same.
\ Type ^n to continue.
Figure 37: Summary option 14 for z-score analysis shows this screen (here, screen 10) which defines the
epoches used for analysis. Here I have a complex set of commands so that the epochs are automatically
(c) copyright 1995 Dave Lavond. All rights reserved.
37
computed for me. See the section describing this option for a simpler set of commands. Use ^n to continue with
loading the z-score program.
38 Directions for a Typical Summary
1) After the session, type "Y" when asked if you want to summarize the data.
2) Selection option 5 to create a new trial type table if this is the first time you have run a particular kind of session.
3) Select option 9 to check and/or reset parameters if this analysis is different than the last analysis performed.
4) Select option 3 to analyze data stored in Segment 2 RAM.
a) enter the number of trials, blocks and trial types when prompted
b) select the trial type table to be used when prompted
c) wait for the printout to be generated
d) insert a Library disk in drive A when prompted. Press any key.
e) reinsert the Program disk in drive A and perform a warm boot (i.e., press controlalternate-del at the same time).
5) If graphics summary is desired, select option 8 from the Runtime menu then select option 8 from the Summary menu. Type
review<return> to start.
38.1 Some General Comments to Keep in Mind
1) Most of the options presented on the main menu use a number of prompts to direct the user through the data analysis.
2) The user must save the data disks if a record of the raw digitized behavioral and neural data is desired. The Library disk only
contains summarized data about each trial (i.e., the dependent measures calculated for each trial).
3) If a mistake is made sometime during the analysis simply let the analysis continue to the end and then reanalyze the data
correctly. Do not turn the computer off or reboot if you want to analyze data from RAM (since these procedures over-write RAM).
If for some reason you must power down or reboot, you then must perform the analysis from the data disk (Summary option 1-analysis from disk).
4) If for some reason you find yourself in Forth (i.e., outside of the Summary or Runtime programs) two words might come in
handy and prevent a reboot of the system. To get back to the Runtime menu, type menu<return>. To get back to the Summary
menu, type summarize<return>. These words keep data within RAM intact. If you find yourself outside of Forth and in DOS, type
the word FORTH after the A> prompt to get back to the Runtime menu without rebooting.
5) Keep a good supply of Library disks on hand.
6) Make back-up copies of important disks (e.g., Library and Graphics disks).
7) It may be a good idea to make several copies of the Program disk and use a copy for each type of run you do (e.g., a disk for
normal training, another disk for discrimination training, another disk for trace conditioning, etc.). This will save you time in
constantly editing parameters everytime you run a different type of session.
8) Unlike the Runtime program, the Summary program is compiled every time it is used. This takes a few more seconds in loading
time, but makes it easier for you to make changes in the Summary routines to meet your individual needs.
9) Become familiar with Forth programming. Micromotion includes a copy of the book Mastering Forth when you purchase the
language. This will make it easier for you to understand the filing structure of these programs, easier to create and edit files, and
enable you to modify portions of the summary routines. If you are reasonably good, you can modify and recompile the Runtime
program.
39 Explanation of Summary Printout
Included within the Summary program documentation is an example of the printouts of behavioral and neural data
generated by the summary program. The printout is divided into three major sections: 1) header information, 2) session summary,
and 3) block-by-block summary.
At the beginning of the header information you will find the descriptive comment you entered before running the
session. Next, the particular a/d channel number associated with the printout is found along with the number of trials, blocks and
trial types on which the analysis was based. The session summary section first displays, by trial number, the trials that were not
included in the analysis because of too much movement during the preCS period (i.e., the bad trials). Next, all CR trials are
displayed by number and information concerning whether or not the animal reached training criterion is given (in this case the
criterion is set at 8 CRs in 9 consecutive trials). Lastly, the session averages for CRs, UCRs and latencies are given along with the
number and percent CRs. These averages are separated by trial types (identified as 1s or 2s according to the trial type table you
selected during the analysis). The block-by-block portion of the summary printout shows percent and number of CRs after the
session has been broken down into blocks (as designated by the trial type table).
For the neural data printout, the program only counts, tabulates and displays discriminated counts for three recording
periods (preCS, CS and UCS periods). The printout shows the total number of counts per period over the session and block-byblock after separating the trials by trial types. If you have more than 1 a/d channel active, a printout will be generated for each
a/d channel separately (starting with channel 1 and ending with channel 4). The printouts for the 2 unit channels follow the
printouts for the behavioral data. It is possible to get trial-by-trial printouts of a session from data stored in RAM, on a data disk
or on a Library disk. To do this, simply set the number of blocks equal to the number of trials when this information is requested
during the analysis. Make sure you also indicate to the computer that there is only 1 trial type.
39.1 Details on A/D (Eyelid) Analysis
The functions for data analysis are fundamental to the Runtime program. Even when analysis is done in the Summary
program, the analysis is done by accessing the Runtime routines for consistency [this was one of the changes that I made in
(c) copyright 1995 Dave Lavond. All rights reserved.
38
rewriting the Summary code of Steinmetz -- using the Runtime code instead of duplicating it in the Summary program]. The
eyelid/-nictitating membrane data analysis from the a/d channels in the Runtime program is directly based upon the way the data
was analyzed by the PDP-11 computer in the Thompson laboratory and the Gormezano FIRST system as used in the Thompson
laboratory at the time, and the experience of Steinmetz in programming the FIRST system in Patterson's Ohio University
laboratory.
If you have just used the Runtime program to collect data, then RAM holds the analyzed data (obviously, based on the
Runtime parameters), and Summary Option 3 accesses these answers in generating the printout. Summary Option 1, analysis
from disk, causes new calculations, based upon the parameters at the end of the Summary file (usually screen 84 of
SUMMARY.SCR), to be stored in RAM. These new RAM values are then used to generate the printout. For every analysis with
new parameters use Summary Option 1.
39.2 The Header
At the top of the summary printout is information for the analysis. This includes the comment you typed in Runtime
Option 2, which a/d data channel is used for this analysis, and the number of trials (#trls), number of blocks (#blks) and number of
trial types (types) used for this analysis, based on your answers to the queries for Summary Options 1, 2 and 3 (unless you have
auto on).
39.3 Bad Trials
Bad trials are defined as trials in which there is too much movement in the baseline (PreCS) period, or in which there is
reason to doubt that a movement in the CS period is really a learned response, or if there is too much unit activity in the baseline
period if unit channels are collected. The Runtime routines make the basic measurements during the trial but make no judgement
about whether the trial is good or bad. Therefore, all data is collected and stored onto the Data disk (the disk with the file
DATA.SCR) regardless of the quality of the data. The determination that a trial is bad is made by the routines of the Summary
program based on those measurements.
The average of the a/d channel is calculated during the entire PreCS period, from the beginning of the trial to the bin
before the onset of the tone. Using this measure, a bad trial is any trial in which there is movement exceeding the value of bada/d
(usually 7, meaning 0.7 mm), in either direction from the baseline (above or below), during the time from the bin immediately
before the CS onset back in time by the value of baseln (usually 160 msec before CS onset). [The value of baseln does not have to
be evenly divisible by the binwidth since the Summary program only looks at the whole number generated by the division of baseln
by bin.] The value of baseln can go back to the beginning of the trial (maybe not, it might be to the beginning of the trial plus one
bin). Usually only the time immediately preceding the CS is considered, allowing for some movement early in the PreCS period.
Note also that the calculated baseline average is influenced by movement in the entire PreCS period. Certain trials will not be
counted as bad even if there is movement throughout the PreCS period, because the deviation from the average does not exceed the
value of bada/d.
A bad trial also results if there is early movement exceeding the positive value of critlevel (usually 5, meaning 0.5 mm)
for a conditioned response in the CS period, the period from CS onset to CS plus the value of badtime (usually 25 msec). [The
program does not care if badtime is not evenly divisible by the binwidth since it only looks at the whole number result.] These trials
are excluded because only reflexive eyeblink movements could occur in 25 msec or less. (Typical alpha responses occur in the
range of 40-80 msec.) By this condition, the program does not count early movements as conditioned responses but declares the
trial as bad.
Finally, if unit activity is collected, then a bad trial is declared if the total activity in the PreCS period for the trial
exceeds the value of badunits (usually 100) [assuming that you have set .summary on screen 47 so that ['] nm/unflag is badflag and
also ['] .nm/unlevel is .criteria]. I have also used the value 50. Normally, the height discriminators are set so that 4-8 units are
collected in the PreCS period, so a count of more than 100 in the PreCS period is unusual. [A "trick" to disable the unit criterion
is to make badunits a very large number. The largest it can be is 65535.]
The condition(s) for declaring a badtrial are defined in the words nmflag, unflag and nm/unflag (on my Summary screen
36). [Also see the section "Tricks" for definitions of christy and dragana (also on my Summary screen 36).] The condition(s) are
resolved as badflag in the definition of .summary (my Summary screen 47) with the code normally ['] nm/unflag is badflag. If you
wanted to only use the eyelid criteria and not the unit criterion you would change this to ['] nmflag is badflag. If you do not want
any bad trial criteria then try ['] noop is badflag, where noop means "no operation".
Bad trials are marked in an array called bdtarr (a Steinmetz word meaning "bad trial array"). The actual data file
(DATA.SCR) is not altered in any way, so that, by using a different resolution to badflag, you can reanalyze your data. It is bdtarr
which gets printed out.
39.4 CR Trials
[Note for a better understanding of the explanations below that if there the trial length is pts then the first bin of the
trial is number zero (0) and the last bin of the trial is number pts minus one bin.]
Trials are counted as having conditioned responses if they are not bad trials and if there is a movement that is equal to
or exceeds the positive value of critlevel (usually 5, meaning 0.5 mm) in the period from CS onset to the UCS onset minus one bin
on all trials. A newer feature is that if the switch tonealonecrsinusperiod is on (Summary screen 1) then conditioned responses are
also counted from CS onset to the end of the trial (to pts minus one bin) on CS alone trials. In the older Summary program,
conditioned responses were not counted on tone alone trials in the period from when the airpuff would have come on to the end of
the trial (to pts minus one bin), but you could readily identify conditioned responses in that period on the printout (i.e., if there was
an unconditioned response that equaled or exceeded critlevel on a tone alone trial then it must be a conditioned response; that
scoring was done by hand).
(c) copyright 1995 Dave Lavond. All rights reserved.
39
CR trials are marked in an array called crtarr (a Steinmetz word meaning "conditioned response trial array"). Again,
the actual data file (DATA.SCR) is not altered in any way, so that, by using a different critlevel you can reanalyze your data. It is
crtarr which gets printed out.
39.5 Criterion
This is one of the most complicated features to implement because there are so many exceptions and conditions.
Basically, a criterion for learning looks for a string of correct answers, or in this case, a string of conditioned responses. The
length of the string is a variable called outof (usually 9; my Summary screen 55). This criterion is complicated by allowing for one
incorrect response (one non-conditioned response trial) anywhere in the string. The program allows for one incorrect response
out of 9. To implement this, different counters are used to keep track of the number of correct responses before and after an
incorrect response, and if a second incorrect response occurs then the before number is discarded, the after number gets stored in
the before number, the after number itself is zeroed, and subsequent new correct responses are added to the after number. Get the
feeling that I am telling you more than you want to know? I've already stopped giving the variable names.
There's more. The string only counts trials that are not bad trials. You could have a lot of bad trials in the string but
they are not counted.
And more. Not all trials are the same. In the trial type array (Summary Option 5) I generally assume that, if there are
2 trial types, then trial type 1 is a tone alone trial (or light alone) and type 2 is a paired tone and airpuff trial (or paired light and
airpuff); if there are 3 trial types, then trial type 1 is a tone alone trial (or light alone), type 2 is a paired tone and air trial (or
paired light and airpuff), and type 3 is an air alone trial; and if there are 4 trial types, then trial type 1 is a tone alone trial (or light
alone), type 2 is a paired tone and airpuff trial (or light and airpuff trial), type 3 is a light alone trial (or tone alone), and type 4 is a
paired light and airpuff trial (or tone and airpuff). There are no tables for more than 4 trial types.
Why is this important? Because the criterion also takes into account the trial type. Criterion trials for tone (or light)
include trial types 1 and 2, and criterion trials for light (or tone) include trial types 3 and 4. That is, meeting criterion is based on
trials for the same conditioned stimulus, whether it is a CS alone or paired CS-UCS trial.
Still more. The criterion is based upon the fundamental Runtime routines (used in Runtime and Summary programs)
that utilize the parameters critlevel, badunits, bada/d and maxeye, which the printout reports and you are most likely to want to
change, and also badtime and baseln which it does not report and which are less likely to be changed.
My god, there's more. Not only does the criterion routine have to figure out when criterion has been met, but also
where it has been met (i.e., both which trial in the session and which trial of that particular type 1 and 2, or 3 and 4 [types 1 and 2
for one CS type (e.g., tone), types 3 and 4 for another CS type (e.g., light) or for UCS alone trials (obviously, one should never
reach learning criterion on these trials]).
The printout might report something like this
Criterion: 8/9 (includes CRs in US period on CS alone trials)
Maximum nm/eye level set at 25.5
Nm/eye criterion level set at 0.5
Bad nm/eye level set at 0.7
Bad units set at 100
Types 1 & 2 Criterion Trial 27 (Session Trial # 45)
Types 3 & 4 Criterion not met
In this made up example, this printout means that for all type 1 and 2 trials (tone alone and paired tone and airpuff
trials) that the first time in this run when 8 conditioned responses occurred in 9 trials (counting the CS period on all trials, and
also the UCS period on CS alone trials) was on the 27th type 1 and 2 trial presented, which was the 45th trial actually given in the
session (this is given just for your information; in this example the other trials were type 3 or types 3 and 4), and not criterion was
made on types 3 and 4 (or type 3 alone). The number 27 is the value you use for the number of trials to criterion for that day. If
there were 108 total trials the day before, 54 of which were of types 1 and 2, without reaching criterion, then the total number of
trials to criterion for this animal is 54 + 27 = 81.
We're not finished yet. Sometimes the animal makes 8 conditioned responses in a row without making a mistake. So
that we keep the same criterion (i.e., the animal is allowed one mistake) we should count the very first trial in the string as part of
the criterion. Therefore, you may see a line like this
Types 1 & 2 Criterion Trial 27 (Session Trial # 45) (see also 26)
The value 27 is actually the point where 8 out of 8 trials is met (I call this the "Steinmetz criterion" because of its
origin). The value 26 is the place where the actual 8 out of 9 trials criterion was met (the first trial in the string is not a learned
response). In the latter case one might think that you could use the next trial in the sequence, but that could be another learned
response (a 9 out of 9 criterion), and besides this is a shifting criterion from the beginning of the session where you look for the
first 8 out of 9 learned responses. The latter method (the number 26 in parentheses) is the actual method that is traditionally used:
count until you have 8 conditioned responses, take that trial number, and subtract the 9 criterion trials (i.e., the animal actually
learned on the last trial before the string of correct responses; from the time he learned, he has been showing that he has learned
by making correct responses). For this reason, if the animal has a previous day of training, the following is also a correct message
Types 1 & 2 Criterion Trial 1 (Session Trial # 1) (see also 0)
This means that the animal actually learned on the last trial of the previous day. You could also see something like
Types 1 & 2 Criterion Trial 27 (Session Trial # 45) (see also 24)
(c) copyright 1995 Dave Lavond. All rights reserved.
40
The difference between 24 and 27 would be accounted for by a string of 8 correct responses, by intervening bad trials,
and/or by intervening trials of the wrong trial type.
Although the correct answers are 27, 26, 0 and 24 in the above examples, respectively, you may choose to use the values
27, 27, 0 and 27, respectively, because those are more usually conservative (i.e., it takes at least that long for the animals to learn).
[However, don't be fooled into think that there is something logical about going with the latter case (27, 27, 0 and 27) because it
looks more consistent. The critical question is whether you are using the same criterion from session to session, from animal to
animal.]
39.6 Session Summary
Next in the printout comes the summary of the entire training session by trial types. For each trial type, a report is
made of the actual number of conditioned responses and actual number of trials (excluding bad trials) used in the calculations
(CR/Trials), the computed percentage (%), the CR amplitude, the CR area, the CR peak latency, the UCR amplitude, the UCR
area, the UCR peak latency, and finally the onset latency to critlevel. All trial types make all of these calculations (regardless of
whether it is a tone alone or paired tone and airpuff trial, for example).
Amplitude is the largest height encountered in a particular time period. CR amplitude is the largest positive deflection
from the PreCS baseline level between CS onset and UCS onset minus one bin. For conditioned responses, amplitudes equal to or
above critlevel are added together with values of zero (0) if the response is below critlevel. It is assumed that anything less than
critlevel is random noise. If you want to find out the amplitude of conditioned responses when they actually occur, then one
approach is to change ['] nm/unflag is badflag (in the definition of .summary on my Summary screen 47) to ['] christy is badflag
(assuming christy is defined on screen 36) then every trial in which there was no conditioned response will be treated as a bad trial.
(See the section titled "Tricks".) [On the other hand, if you really want to find the average of all responses (i.e., not treat non-CRs
as zero) then you will have to change the definition of nmcrcheck on Summary screen 35. I leave this as an exercise. It actually
involves simplifying the code.] UCR amplitude is the largest positive deflection from the PreCS baseline level between UCS onset
and the end of the trial (pts minus one bin). UCR amplitude is always counted regardless of its size.
Area is the accumulation of amplitude by time in a particular time period. CR area is simply a count of all positive data
points from the PreCS baseline level between CS onset and UCS onset minus one bin. UCR area is simply a count of all positive
data points from the PreCS baseline level between UCS onset and the end of the trial (pts minus one bin). There are three worthy
points to make: First, if the epochs for the CS period and UCS periods are different time lengths, then naturally one number could
be larger than the other by virtue of counting more data points. Second, each data point represents one bin, so if you collect one
session at one binwidth and another at a different binwidth (let's say at 4 and 8 msec, respectively), then the area measures are
made up of different counts. That is, the same 240 msec CS period would have 60 or 30 data points, respectively. Therefore, one
should only make comparisons of areas when the epochs are the same and the binwidths are the same. Third, the values reported
here are really accumulations of amplitude measures, and are not multiplications of the amplitude by time. The resolution
(assuming equal epochs and binwidths) is +/- 0.05 mm (i.e., half the calibration value of 0.1 mm for rabbits). Finally, as with CR
amplitude, CR area does not count trials in which there is no conditioned response by the action of nmcrcheck. UCR area is
always counted regardless of its size.
Peak latency is the time that the largest height was encountered within a particular time period. CR peak latency is the
time from CS onset to the largest amplitude encountered between CS onset and UCS onset minus one bin. UCR peak latency is the
time from UCS onset to the largest amplitude encountered between UCS onset and the end of the trial (pts onset minus one
multiplied by the binwidth. The resolution of latency is, therefore, a function of the binwidth (e.g., to +/-2 msec with a bin of 4
msec). The program reports latency to whole milliseconds, but you should take into account the actual resolution of the
measurement. Both CR and UCR peak latencies are counted regardless of the size of the response they are based on. If the peak
amplitude is zero (0), then the maximum time is reported.
Onset latency is the latency from CS onset plus badtime [CS+badtime] to the first time that a response exceeds the value
of critlevel or until the end of the trial (pts minus one bin). [Any criterial movement between CS and CS+badtime is considered a
badtrial.] If no response is made, then the maximum time is reported. This means that the onset latency will be biased towards the
end of the trial any time that no response is made.
39.7 Block by Block Analysis
The same calculations made for the entire session are also made and presented on a block by block basis. Probably the
most important thing to note here is that sometimes there are conditions in which there are all bad trials within a block for a
particular trial type. In this instance, the count of good trials is actually zero (0), but in order to prevent a divide-by-zero error in
calculations a one (1) is substituted. Most likely you will find this condition when there is only one tone-alone test trial in a block
and it is a bad trial. Under these circumstances, the entire line of numbers will be reported as zeros. When there is truly a good
tone-alone trial you will see numbers for CR and UCR peak latencies and for onset latency.
39.8 Details on Unit Analysis
For analysis of eyelid EMG as the behavior I created some very primitive routines for scoring conditioned responses.
For eyelid EMG there is usually little or no activity in the PreCS baseline period. [If you analyze EMG with the Z-score routines
you must have at least one unit count in the PreCS period for the whole session or in the block for the Z-scores. Otherwise, the
mean and standard deviation on which the Z-scores are calculated are both zero. Division by zero is not allowable. Even Einstein
made that mistake in a famous error.] For eyelid EMG I have one routine that scores any EMG activity in the CS period as a
conditioned response, and another routine that scores a conditioned response if there is any EMG activity CS period which exceeds
the activity in the PreCS period. These are obviously very crude measures with no major calculations here. The print out gives an
analysis session of percentage of conditioned responses for the various types of trials, and gives zeros (0) in the amplitude, area,
peak and onset measures. Surprisingly, this crude method matches fairly well with one's sense of the data.
(c) copyright 1995 Dave Lavond. All rights reserved.
41
The unit analysis continues with a block analysis (by trial type) of the total counts of units in the PreCS period (from
the start of the trial to CS onset minus one bin), the CS period (from CS onset to UCS onset minus one bin), and the UCS period
(from UCS onset to pts minus one bin). This analysis originates with the PDP-11 routine. I do not find this report very useful. I
recommend either the Z-score analysis (Summary Option 14) or the cross-correlations in one of the graphics review options
(Summary Option 13).
40 Askiing
The askiing function converts a Forth binary DATA disk into ASCII characters useful for importing into a spreadsheet
such as Excel and Lotus. The name is a play on the words ASCII and skiing. The converted ASCII file with have the form where
a) the first line is the comment followed by a <return>, b) all subsequent lines (each delimited by a <return>) are the data collected
in the trials; within each trial, each 8 bit number (represented by an ASCII value) is separated by a space. To use this function you
must have the file ASKIING.SCR.
This function is used in Summary Option 12 but it can also be used separately in you are already in Forth (i.e., if "ok"
or "Ready" appears in response to you typing <return>). In Forth type including askiing<return> and wait for the program to
load. When it is finished loading it will display these instructions:
Instruction:
Type "flush<return>"
You MUST set the parameters #TRLS and PTS:
E.G., "0 #trls ! 0 is pts<return>"
[values shown are the current default values]
Then type "askiing file1,file2<return>",
where file1 is the forth binary DATA file
and file2 is to be the new ascii data file.
Notes:
File2 can already exist [it will be overwritten]
or askiing will make file2 if it does not exist.
You can repeat "askiing file3,file4<return>" as many
times as you wish.
Follow the instructions, being sure to set the parameters correctly (the parameters in the above example will not work).
Each time you convert a disk it will take several minutes. If you press any key during the conversion, the conversion will pause. If
you then press any key again then the conversion will continuke, or if you press the <return> key instead then the conversion will
abort. To get back to running type menu<return> or to summarizing type summarize<return>.
Remember in your spreadsheet that you also need to know the sample rate (i.e., the value of bin) in order to convert the
a/d events into times, and that your resolution is limited by that. That is, if your sample rate is 10 msec and you average 50 times
together you might end up with a latency of, let's say, 236.95 +/- 9.3 msec. That is false. You cannot measure that, you can only
measure in 10 msec increments. Your actual resolution is 240 +/- 10 msec. This is a common rounding error that is especially
seen when people write about statistical differences. Just because the calculator or computer can make the calculation does not
make it a valid number. The Summary printout also gives the impression of greater precision than is really possible, so be
sophisticated in your interpretation. I reflexively keep this knowledge in mind when I interpret every number that comes out of
these programs.
A similar program used for spreadsheet conversion of the LIBRARY disk is adlibbing.
41 Adlibbing
The adlibbing function converts a Forth binary LIBRARY disk into a space-delimited ASCII file useful for importing
into a spreadsheet such as Excel and Lotus. Since this function was created after the askiing program, the name adlibbing is a
play on the words library, askiing, ad lib (ad libitum) and to adlib. The converted ASCII file with have the form where the first line
is the comment followed by a <return> and all subsequent lines (each delimited by a <return> at the end of the trial) are the
computations for each trial (each an 8 bit number represented by its ASCII value) separated by a space. To use this function you
must have the file ADLIBBING.SCR.
This function is currently only accessed if you are already in Forth (i.e., if "ok" or "Ready" appears in response to you
typing <return>). In Forth type including adlibbing<return> and wait for the program to load. When it is finished loading it will
display these instructions:
Instruction:
Type "flush<return>"
You MUST set the parameters #TRLS and PTS:
E.G., "0 #trls ! 0 is pts<return>"
[values shown are the current default values]
Then type "adlibbing file1,file2,scr#<return>",
where file1 is the forth binary DATA file
file2 is to be the new ascii data file
and scr# is the screen number in library file.
Notes:
File2 can already exist [it will be overwritten]
or adlibbing will make file2 if it does not exist.
Repeat "adlibbing file3,file4,scr#<return>" as many
times as you wish.
Follow the instructions, being sure to set the parameters correctly (the parameters in the above example will not work).
Each time you convert a disk it will take a few moments. If you press any key during the conversion, the conversion will pause. If
(c) copyright 1995 Dave Lavond. All rights reserved.
42
you then press any key again then the conversion will continue, or if you press the <return> key instead then the conversion will
abort. To get back to running type menu<return> or to summarizing type summarize<return>.
Remember in your spreadsheet that you also need to know the sample rate (i.e., the value of bin) in order to convert the
a/d events into times, and that your resolution is limited by that. That is, if your sample rate is 10 msec and you average 50 times
together you might end up with a latency of, let's say, 236.95 +/- 9.3 msec. That is false, you cannot measure that, you can only
measure in 10 msec increments. Your actual resolution is 240 +/- 10 msec. This is a common rounding error that is especially
seen when people write about statistical differences. Just because the calculator or computer can make the calculation does not
make it a valid number. The summary printout also reports a degree of precision that is not possible, so be sophisticated in your
interpretation. I reflexively keep this knowledge in mind when I interpret every number that comes out of these programs.
The sixteen calculated numbers for each trial are:
PreCS average baseline for eyelid channel 1
PreCS absolute deviation from baseline for eyelid channel 1
CS maximum amplitude for eyelid channel 1
CS cumulative area for eyelid channel 1
CS peak latency to maximum amplitude for eyelid channel 1
UCS maximum amplitude for eyelid channel 1
UCS cumulative area for eyelid channel 1
UCS peak latency to maximum amplitude for eyelid channel 1
latency to the critlevel or greater response in CS period
PreCS count of unit channel 1
CS count of unit channel 1
UCS count of unit channel 1
PreCS count of unit channel 2
CS count of unit channel 2
UCS count of unit channel 2
PreCS positive area for eyelid channel 1 [never used for anything]
If there is a second eyelid channel then the 16 numbers repeat, and so on for additional channels.
A similar program used for spreadsheet conversion of the DATA disk is askiing.
42 Troubleshooting
Naturally, I cannot anticipate all possible problems that one can have with the Runtime and Summary programs. This
reference manual has already addressed many problems where appropriate, and their solutions. Here I will try to cover some of
the most common problems and their possible solutions.
42.1 The Runtime Program Can't Find the Menu File (or "Menu No file")
After typing forth<return> the forth program is loaded and then the Runtime program begins running. One of the first
things the Runtime program does is look for the file MENUS.SCR. If it cannot find the file then you get the error message. You
might have the file but it may be on the wrong drive. First, check to see which drive was accessed to find the MENUS file (i.e.,
which drive light came on?). If it is not the drive you expected or where the MENUS file is located, then type (assuming you want
the program drive to be drive c) " c" programdrive s!<return>. To make it permanent (so that on future boots it uses the correct
drive) make sure the current drive is the one with the program disk (in this example, drive c) type drive c<return> to make c the
current drive and then make the change permanent with saving forth<return>. Now boot up the disk and program again.
42.2 The Runtime Program Can't Find Disk (or "Data No File")
After pressing 1 for Runtime Option 1 (Run) the program stops and says that it cannot find the disk or no file. First
thing to check is if there is a DATA disk in the drive (i.e., a data disk with the file DATA.SCR). The second thing to check is if, in
trying to run again, the drive light comes on, indicating that the proper drive is being accessed. If the proper drive is not accessed,
then set it with something like (if you want the data drive to be drive c) " c" datadrive s!<return>. To make this a permanent
change so that on future runs it is automatically set, then make sure the current drive is correct with drive c<return> and then
next type saving forth<return>.
42.3 The Runtime Program Crashes during the Intertrial Timing
The Runtime program enters the graphics screen and then does not count down the intertrial timing interval. The first
thing to check is to make sure that your computer does not have a TSR program loaded. (This is different from the Forth tsr
function in the Summary program, but the idea came from this source.) TSR programs are things like screen savers and
calendars/-clocks. Since this Forth implementation preceeded TSR programs the two (Forth and TSRs) do not behave well
together. You cannot have a TSR and Forth operating at the same time. This is because Forth was designed to occupy a
particular RAM location, and TSR programs (which get loaded first) occupy that space and bump Forth up. If this is the problem
then solution is simple: do not use TSR programs.
The second thing to check is the hardware for the a/d converter. Since a/d channels are checked during the intertrial
interval, if this is not working then the program will be stuck. You will have to consult the circuit published in Lavond and
Steinmetz (1989) and turn the power off and trace the wires on the Forth board. Usually, a wire is broken or is shorting out. You
don't have to check all the wires. Check the wires on the following chips, in this order: first, OSC1.0000 (oscillator) sometimes
this just comes out of the socket; second, 0808 (a/d converter); third, 8253 (on-board counter/-timer); fourth, 8255 (digital
interface).
(c) copyright 1995 Dave Lavond. All rights reserved.
43
It could be that nothing is happening because you hit any key and the program is in the inhibit mode. If that is true,
then hitting any key will get back to the count down mode. This should be obvious, however, because the "INHIBIT" message
should be flashing, so I don't count this is as an error.
42.4 The Runtime Program Crashes during the Intratrial Timing
The Runtime program begins and counts down the intertrial time, but then does not do anything.
The first thing to check is if the isi parameters are correct (Runtime Option 4 [binwidth] and Option 5 [all other isi
parameters]). If the timing values you give are not exactly divisible by the binwidth (i.e., if there is a remainder) then this is a
binwidth error. The solution is to make sure that every parameter (e.g., toneon, toneoff ...) is evenly divisible by the binwidth. You
will have a clue that you have a binwidth error if, after seeing the message "Running ..." the program says "binwidth error". This
message only briefly appears and you may not even see it in computers with very fast processors. In Forth you can see the error
message by using "scale" to reset parameter values. For example, let's create an error on purpose: start with 10000 bin !<return>
and then try 125 scale toneon<return> and you will get the error message. Type toneon .<return> (meaning "print the value of
toneon") and you will get the answer 0 (zero) back (i.e., no value was loaded into toneon). Now try 120 scale toneon<return> or
try 5000 bin !<return> 125 scale toneon<return> and you will not get the error message. Typing toneon .<return> will yield 12 and
25 respectively.
The second thing to check is if you have live off in Runtime option 7. If live is on then the program is waiting for an
external pulse to signal the beginning of a trial. "Live on" is used to collect data that has been recorded on a tape recorder.
The third thing to check is the hardware. Check the wires for (in order) the chips OSC1.0000, 8253 and 8255.
42.5 The Runtime Used to Give Stimuli but Now it Runs Trials Without Stimuli
I would guess that there was a power glitch that has affected the programming of the 8253 and 8255 on the Forth
board. To fix this enter the interpreter <escape> and type reset<return> and another <return> to continue running trials. If the
tone, light and/or air and/or shock don't come on now then I don't know what is the problem.
42.6 The Summary Printouts are Not the Same
If you run an animal and summarize the data using Summary Option 3 (analysis from RAM), and then later you
reanalyze the data disk with Summary Option 1 (analysis from disk) and you get a printout with different numbers, then chances
are very high that the Summary parameters have been changed in the meantime. Use Summary Option 9 (summary parameters)
to check your values.
42.7 The Summary Printout is Not What I Remember the Runtime to be Like
Again, chances are that the summary parameters (Summary Option 9) are not the same as the parameters in the
Runtime (Options 4 and 5). The Runtime and Summary programs do not, at this time, communicate parameters. This was
intended to make analysis of the data more flexible.
42.8 The Summary Printout Prints Weird Characters and Ejects Many Pages
This usually indicates a erroneous or missing comment on the data file. See the section, The Runaway Printer, in the
description of the Editor, for instructions on fixing the comment in the data file.
42.9 The Summary Prints out Only Zeros
Chances are that the summary parameters (Summary Option 9) are not in their 8 space fields, or do not begin in the
first field of the 8 space field. The following is correct spacing (where I have added a line of numbers so you can see things better,
a line of pretend parameters, and a line identifying the parameters):
1234567812345678123456781234567812345678123456781234567812345678
750
250
600
250
600
500
600
5000
pts
toneon toneoff lton
ltoff
shkon shkoff bin.usec
The following is wrong because the number 500 is not within its proper space:
1234567812345678123456781234567812345678123456781234567812345678
750
250
600
250
600
500
600
5000
pts
toneon toneoff lton
ltoff
shkon shkoff bin.usec
And the following is wrong because the number 500 does not start at the
beginning of the field:
1234567812345678123456781234567812345678123456781234567812345678
750
250
600
250
600
500 600
5000
pts
toneon toneoff lton
ltoff
shkon shkoff bin.usec
42.10 The Summary Does Not Ask for any Parameters (e.g., number of trials ...)
Edit Summary screen 1 and change from auto on to auto off. See the section on the Editor (and see the next section).
42.11 The Summary Loads Parameters (e.g., number of trials ...) that I Don't Want
(c) copyright 1995 Dave Lavond. All rights reserved.
44
Either turn the auto function off (edit Summary screen 1 for auto off) or edit the Summary file so that it has the proper
automatic parameters (see the section of the Editor and search for ***).
43 Tricks
Over the years there have been specialized applications  small bits of Forth code written for peculiar paradigms  that
I have authored for individuals. Here are the ones I remember.
43.1 Inversion
This routine was written for Rodney Swain and Paul Shinkman.
Sometimes a subject initially opens the eye instead of closing it as the Runtime and Summary programs expect. The
programs are designed to detect closings instead of openings, and all measurements are made on that basis. It could be that the
subject actually does open the eye and that the experimenter wishes to measure this, or that the experimenter has hooked up the
potentiometer backwards but the data is otherwise good (the lighting conditions sometimes reverse the sense on optically based
potentiomenters). The end result is that the experimenter wants the program to measure the eye opening instead of the eye closing.
There is nothing (short of recompiling) that can be easily done in the Runtime program. But you can collect the data,
invert the data signal, and then analyze the data from disk (Summary Option 1) with the Summary program just as you normally
would done so. To do this you need to add the following code in the SUMMARY.SCR file to the definition of the word "recalc"
[see Summary screen 64; if it is not on screen 64 then screens have been radically moved (which is possible) so try searching for
the word recalc or RECALC; there is more than one definition of recalc (or RECALC) in the SUMMARY.SCR file)]:
On a line by itself you must have:
variable inversion inversion on
And inside the definition of recalc you must place immediately before the word measure (or MEASURE) the following
code:
inversion @
if (nmrv) @ pts bounds ?do 255 i c@ - i c! loop then
This does not change the actual data file (i.e., the original data is exactly the same as when you collected it), and it will
only invert the first a/d channel.
Because the routine is controlled by the variable inversion, you can change to inversion off without removing the code
inside the definition of recalc and have a normal analysis. A better idea is to move variable inversion inversion on to screen 1 of
the SUMMARY.SCR file (don't leave it on screen 64 if you move it to screen 1) where the other variables auto and tsr are found.
Finally, because it is a variable, and if you have tsr on, you can recalc a lot of data files, some with inversion on, some with
inversion off, without having to reload Summary Option 1 in between.
Note that the pointer to channel 1 a/d data is found in (nmrv) which is used by the measuring routines..
43.1 Invert
This routine was written for Sanae Alice Kanzawa and is based on the inversion routine above.
The problem encountered in leg flexion conditioning is that the animal can move his leg in a range of motion that
exceeds the range of the polarized potentiometers in use. As a result, the correct display would show leg flexion with an upward
deviation, which the Summary analysis programs are designed to analyze, and sometimes the display would show a leg flexion as a
downward deviation, which the Summary analysis programs would ignore. By using the review option in the Summary program
we can view the individual trials and determine whether the data is upside down or not. If the data is upside down, then entering
the interpreter by pressing <esc> allows us to type the command invert<return> to reverse the polarity of the data. As written,
invert only changes the first a/d data (channel 1) but it could be altered to invert any a/d data.
The invert program works in the review program because the number of the currently viewed trial is left on the stack.
This number is duplicated (dup) and used to access the first data channel on that trial for inversion. The code for the simple
definition is:
: invert ( trial# -- trial#)
dup pts bounds
?do 255 i c@ - i c! loop
update save-buffers ;
The comment indicates that the trial number is needed for this definition but that it is unaltered. The trial number left on the stack
is used to display that trial. In fact, the 'jump' option on the review program works by simply substituting the desired trial number
for the one on the stack.
By adding an offset to skip past unwanted channels, and putting a limit so that unit channels are not inverted, the
routine can be changed to invert any data channel. We have not implemented this, but if you wanted to change the second a/d
channel out of any number of valid a/d channels (#a/d @) the code might look something like the following:
: invert ( trial# -- trial#)
dup pts 2 ( second channel) #a/d @ min ( range check) 1- * + ( = offset) pts bounds
?do 255 i c@ - i c! loop
update save-buffers ;
Whereas the inversion rountine about changes all the trials for the analysis, the invert routine here only changes the
trial being viewed. The inversion routine above is a temporary change. The invert routine here is a permanent change  if you
want to keep the original data, you must either keep a record of which trials you have inverted or copy the file before making any
changes.
43.3 Condensed Printing on a Laser Printer
(c) copyright 1995 Dave Lavond. All rights reserved.
45
This routine was primarily done for myself. To get condensed printing on the laser printer, just as there is for the
Summary print outs to an Epson dot matrix printer, you can define
: +condensed esc# emit " (s16.66h8.5bv0T" type ;
: -condensed esc# emit " (s12h10v3T" type ;
Note that the spacing is very important. To activate condensed mode to the laser printer you type
printer on<return>
+condensed<return>
printer off<return>
Now when Forth commands go to the laser printer they will be typed in small print. To turn this off use do the same thing but
substitute -condensed.
43.4 Measure CRs only on Trials in Which a CR Occurred
This routine was written for Christy Logan.
Currently when measurements are made in the CS period the data for every trial (whether a CR occurred or not) is
averaged for CR amplitude, CR area and CR latency. Adding the following code to the definition of nmflag (NMFLAG) on
Summary screen 36 [if things have moved you will have to search for it] will cause Summary Option 1 (analysis from disk) to only
average trials if CRs where found in the CS period (i.e., giving the amplitude, area and latency measurements for actual
conditioned responses). Add this code at the end of the definition for nmflag and before the semicolon (;):
cramp @ critlevel @ u< or
For the purposes of this analysis, any trial that does not have a conditioned response is considered to be a bad trial and not entered
into the calculations.
See the section Enough Already below.
43.5 Measure UCRs only on Trials in Which a UR Occurred
This routine was written for Dragana Ivkovich.
Suppose you are only giving UCS alone test trials and you want to characterize UCRs when they occur, in a fashion
similar to that done for CRs only above. First you need to define a new variable variable critur 5 critur !. Then, instead of the
code cramp @ critlevel @ u< or you would use the following code:
critlevel @ cramp @ u< uramp @ critur @ u< or
Note that it is not a mistake that cramp and critlevel are reversed in this definition. Here, any movement that occurs in
the CS period is considered a bad trial. Then, only UCR movements that exceed the critur level will be considered to be a response;
anything less than that is also a bad trial. These bad trials, then, are not counted in the calculations.
See the section Enough Already below.
43.6 Enough Already
The modifications for Logan and Ivkovich can be incorporated into an option that allows either analysis to be chosen.
This is much more complex to implement than the two options above, but it is much more flexible. If you change screen 36 to look
like the following
\ continued
\ all flags on this screen are true if a bad trial ...
: nmflag ( -- f) onset @ badtime @ u< onset @ 0> and
bada/d @ rescale btrl @ 2dup = -rot u< or ( u<=) or ;
: nmflag' ( -- f) nmflag cramp @ critlevel @ u< or ;
: nmflag'' ( --f) nmflag critlevel @ cramp @ u< or
uramp @ critur @ u< or ;
: unflag ( -- f) badunits @ pcsu1 @ u< badunits @ pcsu2 @ u< or ;
: nm/unflag ( --f) nmflag unflag or ;
: christy ( --f) nmflag' unflag or ;
: dragana ( --f) nmflag'' unflag or ;
Now when you use Summary Options 1, 2 or 3 and if tsr is on (so you can analyze multiple data disks), then do
' christy is badflag<return> before you do recalc .summary<return> to do an analysis with Christy's option. You can change to
new options at any time by doing 'nm/unflag is badflag<return> (or ' dragana is badflag<return>). You only have to do the part '
christy is badflag<return> once for as many recalcs as you wish. [In this method, the default if you do not specify christy or
dragana is the usual nm/unflag.]
The advantages of this method are that you do not have to reprogram the Summary option and the Summary options
are flexible.
[This programming feature is called "resolving" the function. The phrase ' christy is badflag is read (in Forth) "tick
christy is badflag" and means "get the address of the function christy and make it the function of badflag". Now whenever
badflag is executed by the program, whereever it is located, the function christy will be engaged. Basically, this is a method for
writing a program with an unspecified function (badflag) which is later "resolved" by ' christy is badflag. Backwards
programming like this is usually discouraged, but here it has the advantage that badflag can have a variety of future functions.]
43.7 A Block of This, A Block of That
I don't remember doing this but supposedly I wrote a function for Craig Weiss and/or Dave Krupa so that they could
run a block of tone-alone trials or a block of air-alone trials for testing unit responses. It probably worked something like this:
you would put pause on on Runtime Option 7 so that the program would run a block and then wait for a key press before running
(c) copyright 1995 Dave Lavond. All rights reserved.
46
another block, you press a key, and then you would go into the interpreter with <escape> and type some secret code to set
trialsequence to either all tone or all air trials, then you would press <return> to continue running trials. To set up the code you
might do the following (assuming you have 9 trials per block)
: allair >s slip a& a& a& a& a& a& a& a& a& ;
: alltone >s slip t& t& t& t& t& t& t& t& t& ;
: aaa ['] allair is trialsequence ;
: ttt ['] alltone is trialsequence ;
The secret codes are aaa and ttt.
(c) copyright 1995 Dave Lavond. All rights reserved.
47
44 Glossary
The following is intended as a quick listing of Forth words created for the Runtime or Summary programs. This is not
an exhaustive listing, but rather a listing of some important or useful words.
Format:
Forth word (how word is used) [how word is pronounced (if not obvious)]. Description. Normal value and/or usage. Where found
or used.
Special
\| (function) [backslash pipe]. If definition needed, compile from here to pipe. See need, \if, \;.
\; (function) [backslash semicolon]. If definition is needed, compile from here until semicolon found. See need, \if, \|.
A
a& (function) [a and]. An airpuff (or shock) alone trial. See Runtime Option 4.
abort (function). Immediately stop executing Forth words and give a warning beep. See also exit. Defined by MasterForth.
#a/d (variable) [number of a-to-d]. The total number of analog-to-digital (nictitating membrane or eyelid) channels to collect or
analyze. See Runtime Option 4.
after (variable) An arbitrary unit of time after the trial to keep the tape recorder on. See before, tape. See Runtime Option 7.
air (function) Sets up vectors for interstimulus intervals during a trial. Also sets up graphics display of marks for the airpuff. Can
be useful for proper placement of airpuff mark in review program (Summary Options 8 and 13).
airoff (value/constant) [air off]. The bin number when the airpuff is turned off. You must factor in the delays caused by the
solenoid and hose. See Runtime Option 5.
airon (value/constant) [air on]. The bin number when the airpuff is turned on. You must factor in the delays caused by the
solenoid and hose. See Runtime Option 5.
auto (variable/switch) Normally off, the Summary program will ask for the number of trials (#trls), number of blocks (#blks),
number of trial types (types), and trial sequence; if on, the Summary program will assume values embedded in the
SUMMARY.SCR file. See discussion of the Editor in the manual section About Forth.
B
bada/d (variable) [bad a-to-d]. Value in 1/10th millimeter which, if equalled or exceeded in deviating (above or below) from the
PreCS (baseline) average from toneon-baseln [toneon minus baseln] to toneon, indicates a bad trial. Normally 7 bada/d
! [0.7 mm]. Used by Runtime and Summary programs.
badtime (variable) [bad time]. Time in milliseconds after CS onset (i.e., in CS period) to look for too much a/d movement,
indicating a bad trial. Assumes that if a response occurs faster than the time it takes a reflex then the response could
not be learned. Normally 25 badtime !. Used by Runtime and Summary programs.
badunits (variable) [bad units]. If the number of units counted in the PreCS period exceeds this value then the trial is considered a
bad trial. Normally 100 badunits ! and sometimes 50 badunits !. For multiple units, height levels on unit discriminator
are usually set to give count rates of 5-20 counts in 250 millisecond baseline period. Only used by Summary program.
baseln (variable) [baseline]. Time in milliseconds before CS onset (i.e., in PreCS period) to look for too much a/d movement,
indicating a bad trial. Normally 160 baseln !. You could use the entire baseline period. It normally is not all used,
allowing for some movement in the baseline period. Used by Runtime and Summary programs.
beep (function) The IBM-defined sound from the computer to get your attention. See bell, roadrunner.
before (variable) An arbitrary unit of time before the trial to turn the tape recorder on (gets tape up to speed before the trial). See
after, tape. See Runtime Option 7.
bell (function) A short sound from the computer. More pleasant/less annoying than the IBM-defined beep. See roadrunner.
bin (variable) The duration in microseconds of each period of data collection. For example, 4000 bin ! causes a/d and units data to
be collected every 4 milliseconds during a trial. See scale. See Runtime Option 4.
#blks (variable) [number of blocks]. The total number of blocks of trials in a session. Equal to #trls divided by #t/blk. See
Runtime Option 4.
blksum(a) (function) [block sum A]. During data collection, add/average certain trials and display at the end of the block.
0=nothing, 1=tone alone, 2=tone-air, 3=light, 4=light-air, 5=air alone, 6=tone-light-air trial. Additive with blksum(b).
See Runtime Option 4.
blksum(b) (function) [block sum B]. See blksum(a).
bye (function) Leave Forth and reenter DOS. Defined by MasterForth.
C
ceiling (variable) cuts off the top of the unit displays so that they do not overlap and obscure the a/d data. Normally 28 ceiling !.
(c) copyright 1995 Dave Lavond. All rights reserved.
48
continue (function) If a session has been accidentally interrupted, for example by pressing <escape> key twice during an intertrial
interval, you can resume training with dark continue<return>. See also exit.
copyright (function) Display the copyright notice.critlevel (variable)
critlevel (variable) [criterion level]. The value in 1/10ths of a millimeter which must be equalled or exceeded to count the a/d data
as a conditioned response, between the time periods toneon+badtime to shkon. Normally 5 critlevel ! [0.5 mm]. Used by
Summary program only.
cs1on (variable) [cs one on]. Onset time in milliseconds of the first CS. Related to toneon. Used by Summary. See toneon.
cs2on (variable) [cs two on]. Onset time in milliseconds of the second CS. Related to lton. Used by Summary. See lton.
D
dark (function) Erase graphics screen. Defined by MasterForth.
datadots (variable/switch) data dots. Normally off; on draws three dots at the maximum CS deviation, the maximum UCS
deviation, and at the 0.5 mm latency for the a/d channels. [When the new graphics display was written to accommodate
more unit channels and to show all the trial data on the screen, the dots do not always show up in the right position.]
See Runtime Option 7.
datadrive (string) [data drive]. Identifies drive where program can find the Data disk. For example, " b" datadrive s!<return>.
See librarydrive, programdrive.
dots (variable/switch) Normally on, draws a/d data as dots; off draws a/d data with lines between dots. Drawing dots is faster than
drawing lines, so this is preferred during data collection. Drawing lines is more esthetic, so dots off is preferred during
review (Summary Option 8) when printing to laser printer for publication. See Runtime Option 7.
E
exit (function). Terminate execution of a word. Defined by MasterForth.
exit, how to exit Forth. Type bye<return> to reenter DOS.
exit, how to exit review of trials (Summary Options 8 and 13). There are two methods: either press e (that is all there is to it), or
press <escape> (to enter interpreter) <escape> to exit interpreter and the review of trials) then type tx (to change to text
mode) flush<return> (to close all files). See review to reenter graphics review.
exit, how to exit running trials. Press <escape> (to enter interpreter) <escape> (to exit interpreter and the run of trials) then type
tx (to change to text mode) flush<return> (to close all files). See continue to reenter trial sequence [must be done before
tx and flush]..
exit, how to exit Runtime menu. Type 0 (zero). It is then a good idea to type flush<return> to close all files. See menu to reenter
Runtime menu.
exit, how to exit Summary menu. Type 0<return> (zero). It is then a good idea to type flush<return> to close all files. See
summarize to reenter Summary menu.
exit, how to exit Summary printout. If the printout looks good but for some reason you want to stop the printout (for example, the
paper is jammed but the printer head is still working) then type <escape><escape> to stop the printing. If the printout
looks bad (for example, weird characters printout and/or multiple pages are ejected) then turn the printer off -- see The
Runaway Printer to correct the comment.
F
filter (variable/switch) Normally on, this causes 3-point moving average (smoothing) of raw a/d data when it is collected to
minimize spurious measurements; off causes no smoothing. See Runtime Option 7.
flash (variable/switch) Normally on, this causes the "inhibit" message to flash during a session; off causes no flashing. Speed of
flashing is a function of the computer clock. See Runtime Option 7.
forth (function). From DOS, enter the Runtime and Summary programs by typeing forth<return>. See exit.
G
H
I
\if (function) [backslash if]. If a definition is needed, compile the rest of the line. See need.
info (function) An array that temporarily holds the computed data during a training session. These are the numbers that are
printed on the bottom of the monitor screen in the review program (Summary Options 8 and 13). In order, the numbers
are: (1) PreCS average baseline, (2) PreCS maximum deviation, (3) CS peak amplitude, (4) CS area, (5) CS peak
latency, (6) UCS peak amplitude, (7) UCS area, (8) UCS peak latency, (9) latency to criterion level amplitude, (10) unit
1 PreCS count, (11) unit 1 CS count, (12) unit 1 UCS count, (13) unit 2 PreCS count, (14) unit 2 CS count, (15) unit 2
USC count, (16) PreCS positive area. Used by Runtime and Summary programs.
(c) copyright 1995 Dave Lavond. All rights reserved.
49
inversion (variable/switch). Normally off, inversion on is used to invert the a/d data for analysis with Summary options 1, 2 and 3
(data analysis from data disk, library disk, or RAM). Used when the potentiometer is recording data backwards
(flipped) or when the behavior moves potentiometer in opposite direction from normal eyeblink. See also invert.
invert (function). Used to invert the a/d data (channel 1) for the current trial data in the Review option of the Summary program.
Load the review program from the Summary menu (option 8), start program with review<return> and jump to the trial
that needs to be inverted, then access the interpreter (using <esc>) and type invert<return>. See Tricks.
it (function). A temporary marker. After defining 'it' (create it) other words are then loaded and their functions executed. When
the words are no longer needed, then they can all be easily removed by typing forget it<return>. Forth uses marker for
a similar purpose where loading in words from other files. Create it and forget it are used in the Summary programs
and in debugging code.
J
K
L
l& (function) [l and]. A light alone trial. See Runtime Option 4.
l&a (function) [l and a]. A light and airpuff (or shock) trial. See Runtime Option 4.
l&s (function) [l and s]. A light and shock trial. See Runtime Option 4.
library (function) Store calculations of each trial to library disk. See Summary Options 1 and 10.
librarydrive (string) [library drive]. Identifies drive where program can find the Library disk. For example, " a" librarydrive
s!<return>. See datadrive, programdrive.
live (variable/switch) Normally off, collects data online; on collects data from previously recorded tape for off-line data collection.
[Due to changes in the machine code for the trial the sense of live was accidentally altered from on/off to off/on.
Unfortunately, it would take a lot of reprogramming to fix this.] See Runtime Option 7.
lt (function) [light]. Sets up vectors for interstimulus intervals during a trial. Also sets up graphics display of marks for the light.
Can be useful for proper placement of light mark in review program (Summary Options 8 and 13).
lt-air (function) [light-air]. Sets up vectors for interstimulus intervals during a trial. Also sets up graphics display of marks for the
light and airpuff. Can be useful for proper placement of light and airpuff marks in review program (Summary Options
8 and 13).
ltoff (value/constant) [light off]. The bin number when the light is turned off. See Runtime Option 5.
lton (value/constant) [light on]. The bin number when the light is turned on. Calculations and graphics for the CS are made from
here to shkon (UCS). See Runtime Option 5. See cs2on.
M
maxeye (variable) [max eye]. Option used in human experiments where the eyelid movement is optically coupled and therefore
needs to be calibrated with the Forth interface a/d converter; if a human's maximum eye opening is 15 mm then use
150 maxeye !. Normally set to 255 maxeye ! for rabbit studies where the equipment is calibrated to use the full 0-255 8bit range of the a/d converter. See Runtime Option 4 and Summary screen size 1-.
menu (function) Initializes interface chips on Forth card, closes all files, sets programdrive, displays the copyright, and shows the
Runtime Opening Menu.
minimum (variable) The minimum value in seconds of the intertrial interval. See range, random. See Runtime Option 4.
N
need (function) Check to see if a word has already been defined. See \if, \; and \|.
nothing (function) Sets up vectors for interstimulus intervals during a trial. Also sets up graphics display of no marks. Can be
useful for preventing any stimulus marks in review program (Summary Options 8 and 13).
O
P
pause (variable/switch) On causes a session to pause between blocks of trials, allowing experimenter to inject drugs or change
electrode position between blocks; off (the normal condition) causes uninterrupted sequence of trials. See Runtime
Option 7.
(c) copyright 1995 Dave Lavond. All rights reserved.
50
pcspulse (value/switch) [preCS pulse]. Normally on, causes synchronization pulse to be output at the beginning of the trial; off
causes either CS or UCS pulse to be the first pulse in the trial. Used to prevent oscilloscope from triggering on the
preCS (baseline) pulse. See Runtime Option 7.
picture (variable/switch) Normally on, causes graphics display to computer monitor; off causes text only to print out to the monitor.
Since drawing to screen takes considerably more time that writing a line of text, picture off is used for very fast trials.
See Runtime Option 7.
\| (function) [backslash pipe]. If definition needed, compile from here to pipe. See need.
portb (constant) [port b]. The address of the hardware interface controlling tone (1), light (2), airpuff (8), shock (16),
synchronization (64) and output pulses (128, see pulseon), and tape (32). To turn all stimuli off type 0 portb
pc!<return>. To turn the tone on type 1 portb pc!<return>, etc.
printing (variable/switch) If on, prints a hardcopy; if off, prints to computer monitor. Used by Summary program only. The Forth
command printer on actually turns “on” the printer, meaning that characters which are normally sent to the monitor
are now routed to the printer, not that it plugs in the printer or flips the printer’s on switch.
programdrive (string) [program drive]. Identifies drive where program can find the Summary program. For example, " a"
programdrive s!<return>. See datadrive, librarydrive.
pts (value/constant) [p-t-s or points]. The total number of bins to collect during a trial. For example, 100 is pts and 400 scale pts
are equivalent if the binwidth is previously set to 4000 (4000 microseconds, or 4 milliseconds). Runtime uses pts;
Summary screen 84 is actually trialdur which gets converted to pts. See bin, scale. See Runtime Option 5. See trialdur.
pulseon (value/constant) [pulse on]. The bin number when an external pulse is given. Used to trigger an oscilloscope sweep. If
the value of pulseon exceeds the trial duration (exceeds pts) then the pulse is effectively turned off. See Runtime Option
5.
Q
R
random (function). Returns a pseudorandom number with values determined by minimum and range. See minimum, range.
range (variable) The value in seconds of the maximum deviation of the intertrial interval from its minimum value. For example,
for an average 30 second intertrial interval with a range of 20-40 seconds, use 20 minimum ! 20 range ! See minimum,
random. See Runtime Option 4.
recalc (function) Recalculate measurements from data disk. This routine asks you for the name of the data file to analyze and
does the initial analysis of each trial. To use from Forth, you must load Summary Option 1 when tsr is on. See
Summary Option 1. See .summary, tsr.
reset (function) Reinitialize programmable chips on Forth interface card. During a session, sometimes the stimuli (e.g., the tone)
stop functioning. I usually attribute this to an electrical spike that has upset the hardware. Usually this can be fixed by
entering the interpreter and issuing the command reset<return><return>. If this does not work, note the trial you are
on, turn the computer off and back on, and beginning training where you left off. In the newer versions, the Runtime
program now keeps track of the last trial given, so it will ask if you want to continue where you left off.
review (function) Start the review program. See Summary Options 8 and 13.
roadrunner (function) On a relatively slow IBM-PC (4.7 or 8 MHz) this will make the sound beep-beep to get your attention
(actually it is bell-bell).
run (function) Start the z-score analysis. See Summary Option 14.
S
s& (function) [s and]. A shock alone trial. See Runtime Option 4.
\; (function) [backslash semicolon]. If definition needed, compile from here until semicolon found. See need.
safety (variable/switch) On saves data to floppy, off does not. Initially used for debugging, it is also used to turn off collection to
floppy so that the minimum intertrial interval can be used for random unpaired conditioning. See Runtime Option 7.
scale (function) Converts a number representing milliseconds into a number representing the corresponding number of bins. For
example, if bin equals 2 milliseconds, then 1000 scale pts stores 500 into pts. See bin. See Runtime Option 5.
shkoff (value/constant) [shock off]. The bin number when the shock is turned off. See Runtime Option 5.
shkon (value/constant) [shock on]. The bin number when the shock is turned on. Also represents the time when the airpuff arrives
at the eye. Calculations and graphics for the UCS are made from here to the end of the trial (to pts). See Runtime
Option 5. See uson.
size (function) If a file is open, return its size (in units of screens, i.e., 1024 byte units). size 1- gives the number of the last screen
of the file. A MasterForth definition.
stop (function) Prevents compilation of everything on the screen after the word stop.
summarize (function) Loads the Summary Menu.
summary (function) If this word is in the dictionary (i.e., sifting summary<return>) then at least part of the Summary program has
been loaded. To start fresh, type forget summary<return>, which is the condition found when the Runtime program is
first booted up.
.summary (function) [dot summary or print summary]. Start the summary print out routine. See Summary Options 1, 2, and 3.
See recalc.
(c) copyright 1995 Dave Lavond. All rights reserved.
51
T
t& (function) [t and]. A tone alone trial. See Runtime Option 4.
t&a (function) [t and a]. A tone and airpuff (or shock) trial. See Runtime Option 4.
t&s (function) [t and s]. A tone and shock trial. See Runtime Option 4.
tl& (function) [t l and]. A tone and light trial. See Runtime Option 4.
tl&a (function) [t l and a]. A tone, light and airpuff (or shock) trial. See Runtime Option 4.
tl&s (function) [t l and s]. A tone, light and shock trial. See Runtime Option 4.
tape (variable/switch) Turn on/off tape recorder during trial to collect data. See after, before. See Runtime Option 7.
#t/blk (variable) [number of trials per block]. Number of trials per block during a session. Equal to #trls divided by #blks. See
Runtime Option 4.
!time (function) [store time]. Sets the computer date/time-of-day timer to the beginning by typing 0 0 !time<return>. This is
necessary when the accumulated time gets too large for proper timing of the intertrial intervals. Used by Runtime
program.
tone (function) Sets up vectors for interstimulus intervals during a trial. Also sets up graphics display of marks for the tone. Can
be useful for proper placement of tone mark in review program (Summary Options 8 and 13).
tonealonecrsinusperiod (variable/switch) [tone alone crs in us period]. Who came up with this name? Well, I could not think of
anything else. If on, then tone alone trials will be searched in the UCS period for conditioned responses. This can only
be used for tone alone trials that are type 1 in the trial type table. If off, then conditioned responses are only looked for
in the period between the CS and UCS onsets, even on CS alone trials when the UCS is not actually delivered.
tone-lt (function) Sets up vectors for interstimulus intervals during a trial. Also sets up graphics display of marks for the tone and
light. Can be useful for proper placement of tone and light marks in review program (Summary Options 8 and 13).
tone-lt-air (function) Sets up vectors for interstimulus intervals during a trial. Also sets up graphics display of marks for the tone,
light and airpuff. Can be useful for proper placement of tone, light and airpuff marks in review program (Summary
Options 8 and 13).
toneoff (value/constant) [tone off]. The bin number when the tone is turned off. See Runtime Option 5.
toneon (value/constant) [tone on]. The bin number when the tone is turned on. Calculations and graphics for the CS are made
from here to shkon (UCS). See Runtime Option 5. See cs1on.
trialdur (variable) [trial dur]. Trial duration in milliseconds. Related to pts. Used by Summary. See pts.
trialsequence (function) [trial sequence]. The block of trials for the session. May be defined by the user (see user) or selected from
these already defined sequences: 90%, UNP, 75%T, 75%L, TRACET, EXTINCTIONT, 75%TL. See Runtime Option 4.
trl# (variable) [trial number]. The beginning trial number. Also, the current trial number. See Runtime Option 4. Used during
the Runtime session; used by Summary program in analysis.
#trls (variable) [number of trials]. The total number of trials in a session. Equal to #blks times #t/blk. See Runtime Option 4.
tsr (variable/switch) [t-s-r]. Terminate and stay resident. If on, load in Summary program and exit to Forth. You can then
manually activate analysis as many times as you wish. This prevents you from having to reload the same Summary
Option over and over again for analysis of multiple data or library disks. For example, if tsr is on and you load
Summary Option 1 (analysis of data from data disk),then analysis is loaded and waits for your command recalc
.summary<return> to analyze the first disk. After completion, type recalc .summary<return> again to do another data
disk. You can also change other parameters (e.g., criterion level, see critlevel) and reanalyze the same data with new
parameters. Type summarize<return> to reenter Summary Menu. If off, analysis of one data file will be allowed and
then you are returned to the Summary Menu. Edit on Summary screen 1. Used by Summary program only.
types (variable) Number of different trial types. Used by Summary program
U
un1 (variable) [un one]. If 0 do not analyze first unit channel, if 1 do analyze. Used by Summary program only.
un2 (variable) [un two]. If 0 do not analyze second unit channel, if 1 do analyze. Used by Summary program only.
unit1x (value/constant) [unit 1 x]. Y-axis amplification of unit channel 1. See Runtime Option 4; Summary Options 8 and 13.
unit2x (value/constant) [unit 2 x]. Y-axis amplification of unit channel 2. See Runtime Option 4; Summary Options 8 and 13.
unitduration (variable) [unit duration]. The duration in microseconds of the discriminator pulse for units, this is used to calculate
the maximum number of counts that are possible during one binwidth as a safety check. See Runtime Option 4.
#units (variable) [number of units]. The total number of unit channels to collect or analyze. See Runtime Option 4.
use (variable/switch) Normally off, tells runtime whether there was a previous trial with data to save. Used for debugging. See
Runtime Option 7.
user (function) A user-defined block sequence of trials. Later resolved as trialsequence. [The word "user" is not mandatory.
Another name could be used just so long as it is resolved as in ' anothername is trialsequence. The number of trials in
the definition must match #t/blk.]
uson (variable) [us onset]. Onset in milliseconds of the UCS. Related to shkon. Used by Summary. See shkon.
V
version (function) Identifies compilation date of Runtime program. To use, type version type<return>.
W
(c) copyright 1995 Dave Lavond. All rights reserved.
52
X
xmaximum (constant) [x maximum]. The maximum number of points possible in the horizontal dimension for drawing. Might be
seen on Runtime Option 7. Used by Runtime; used by Summary Options 8 and 13.
xscalex (value/constant) [x scale x]. X-axis scale multiplier, this determines the horizontal magnification of the graphics display.
Used in conjunction with xscale/. Used by Runtime, might be seen in Runtime Options 4 and 7; used by Summary
Options 8 and 13.
xscale/ (value/constant) [x scale slash]. X-axis scale divisor, this determines the horizontal miniaturization of the graphics display.
Used in conjunction with xscalex. Used by Runtime; used by Summary Options 8 and 13.
Y
Z
zscores (function). If this word is found in the dictionary then the zscores analysis (Summary Option 14) is loaded.
(c) copyright 1995 Dave Lavond. All rights reserved.
53
45 Bibliography
Anderson, A. & Tracy, M. (1984). Mastering Forth. New York, Prentice Hall Press.
Berger, T.W., Latham, R.I. & Thompson, R.F. (1980). Hippocampal unit-behavior correlations during classical
condtioning. Brain Research, 193, 229-248.
Berger, T.W., Rinaldi, P., Weisz, D.J. & Thompson, R.F. (1983). Single unit analysis of different hippocampal cell types
during classical conditioning of the rabbit nictitating membrane response. Journal of Neurophysiology, 50,
1197-1219.
Brodie, L. (1984). Thinking Forth: A Language and Philosophy for Solving Problems. Englewood Cliffs, New
Jersey, Prentice-Hall, Inc.
Eggebrecht, L.C. (1983). Interfacing to the IBM Personal Computer. Indianapolis, Indiana, Howard W. Sams.
Intel. (1986) Intel Yellow Pages Software Directory. Santa Clara, California, Author.
Intel. (1987). Intel Microsystem Component Book. Santa Clara, California, Author.
Lavond, D.G., Logan, C.G., Sohn, J.H., Garner, W.D.A. & Kanzawa, S.A. (1990). Lesions of the cerebellar interpositus
nucleus abolish both nictitating membrane and eyelid EMG conditioned responses. Brain Research, 514, 238248.
Lavond, D.G. & Steinmetz, J.E. (1989). An inexpensive interface for the IBM PC/XT and compatibles. Behavior
Research Methods, Instruments & Computers, 21, 435-440.
National Semiconductor. (1981). Logic Databook. Santa Clara, California, Author.
Rector, R. & Alexy, G. (1980). The 8086 Book: Includes the 8088. Berkeley, California, Osbourne/McGraw-Hill.
Roemer, R.A. (1975). Some interactive computer applications in physiological psychology laboratory. American
Psychologist, 30, 295-298.
Royer, J.P. (1987). Handbook of Software and Hardware Interfacing for IBM-PCs. Englewood Cliffs, New Jersey,
Prentice-Hall.
Scandrett, J. & gormezano, I. (1980). Microprocessor control and a/d data acquisition in classical conditioning. Behavior
Research Methods & Instrumentation, 12, 120-125.
Solomon, P.R. & Babcock, B.A. (1979). KIM and the rabbit: The use of the KIM-1 microprocessor to control classical
conditioning of the rabbit’s nictitating membrane response. Behavior Research Methods & Instrumentation,
11, 67-70.
Solomon, P.R., Weisz, D.J., Clark, G.A., Hall, J. & Babcock, B.A. (1983). A microprocessor control system and solid state
interface for controlling electrophysiological studies on conditioning. Behavior Research Methods &
Instrumentaiton, 15, 57-65.
Willen, D.C. & Krantz, J.I. (1984). 8088 Assembler Language Programming: The IBM-PC, 2nd Edition. Indianapolis,
Indiana, Howard W. Sams.
(c) copyright 1995 Dave Lavond. All rights reserved.