a - springerextras.springer.com/2003/978-1-4020-7269-7/forth softwa… · web viewthe training...

AReference Manual

for theRuntime and Summary Programs

forClassical Conditioning

by Dave Lavond

with assorted advice and interference fromChristy Logan

Dragana IvkovichDick ThompsonJudy Thompson

Revised 31 March 1994Revised 1 September 1995Revised 21 February 1997

Revised 6 March 1997Revised 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 Features3.2 Dictionary Structure3.3 Dictionaries3.4 Words in the Dictionary3.5 Don't Forget to Forget3.6 Manipulating the Runtime and Summary Programs

4 The Forth Editor4.1 The Summary Auto(matic Parameter) Function4.2 The Search Function4.3 Other Editor Commands4.4 The Editor is used by Runtime and Summary Options4.5 The Runaway Printer

5 The Setup5.1 What You Need5.2 Legal Issues5.3 Original, Working and Backup Copies5.4 Booting the Software5.5 Making a Turnkey System5.6 Data, Library and Graphics Disks5.7 Optimizing Data Disk Storage

6 The Runtime Program6.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: Comment10 Runtime Option 3: Changing the Run Default11 Runtime Option 4: Intertrial Parameters12 Runtime Option 5: Intratrial Parameters13 Runtime Option 6: Instructions for User Trial Sequence14 Runtime Option 7: Softswitches15 Runtime Option 8: Run Summary Program

15.1 Overview of Running a Session15.2 Things You Need15.3 Defaults15.4 Review of Forth Classical Conditioning/IBM-PC Interface15.5 To Run (or "A Sample Run")15.6 Data Storage

16 Runtime Offline Data Collection17 Compiling Your Own Runtime18 Changing the Runtime Default Choice19 Changing the Runtime Default Drives20 Changing the Runtime Default Directory21 Runtime and Summary Program Interactions22 The Summary Program

22.1 General Overview22.2 Using the Summary Programs

23 Summary Option 0: Exit Summary, Enter Forth24 Summary Option 1: Analysis from Raw Data Stored on a Data Disk25 Summary Option 2: Analysis from Data Stored on a Library Disk


26 Summary Option 3: Analysis from Data Stored in RAM27 Summary Option 4: Analyze with No Printout28 Summary Option 5: Creating a New Trial Type Table

28.1 The Hard Way28.2 The Easy Way28.3 Limitations of All Methods28.4 The Meaning of Numbers

29 Summary Option 6: Display Contents of Library Disk30 Summary Option 7: Load RAM with Library Calculations31 Summary Option 8: Graphics Review of Data Disk (w/Laser Printer for Pictures)

31.1 To Start31.2 To End31.3 General Control31.4 Moving from Trial to Trial31.5 Averaging Data31.6 Average a Range of Trials31.7 Average a Range of Trials by Hand31.8 Average Several Trials by Hand31.9 Average Several Consecutive Trials31.10 Averaging Averages31.11 What are All Those Numbers?31.12 A Note about the Cursor Display31.13 Printing the Picture to a Laser Printer

32 Summary Option 9: Summary Program Parameters for Analysis33 Summary Option 10: Save RAM Calculations to Library Disk34 Summary Option 11: Serial Communications35 Summary Option 12: Analyze Interspike Data36 Summary Option 13: Graphics Review with Cross-Correlations37 Summary Option 14: Z-score Analysis38 Directions for a Typical Summary

38.1 Some General Comments to Keep in Mind39 Explanation of Summary Printout

39.1 Details on A/D (Eyelid) Analysis39.2 The Header39.3 Bad Trials39.4 CR Trials39.5 Criterion39.6 Session Summary39.7 Block by Block Analysis39.8 Details on Unit Analysis

40 Askiing41 Adlibbing42 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 Stimuli42.6 The Summary Printouts are Not the Same42.7 The Summary Printout is Not What I Remember the Runtime to be Like42.8 The Summary Printout Prints Weird Characters and Ejects Many Pages42.9 The Summary Prints out Only Zeros42.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 Tricks43.1 Inversion43.2 Invert43.3 Condensed Printing on a Laser Printer43.4 Measure CRs only on Trials in Which a CR Occurred43.5 Measure UCRs only on Trials in Which a UR Occurred43.6 Enough Already43.7 A Block of This, A Block of That

44 Glossary45 Bibliography


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.

1

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-to-reel 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


2

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 8088-based 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, Woodruff-Pak, 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


3

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


4

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-case-sensitive; 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


5

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 Forth-written 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 pts252 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


6

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 #trlsand constants are defined like this

100 constant badunitsBoth "#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 typingbadunits .<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 toneonThis 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 Hewlitt-Packard calculators for number operations. The book Mastering Forth by Martin and Tracy, who incidentally wrote our version of Forth, is a good introduction.


7

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


8

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>), thenusing data 0 edit<return>do your editing, then typeflush<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 importantcr 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.


9

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 programmenus.scr runtime menu file and parameters for trainingsummary.scr summary program written in Forthlaser.scr screen print file used by summary programcross.scr cross correlations file used by summary programz.scr z score file used by summary programz.blk z score file used by summary programprinter.scr comes with original forth.com, used to print out source codefloat.rlf comes with original forth.com, adds software floating pointassemble.rlf comes with orginal forth.com, adds assembly languageadlibbing.scr creates ASCII file of library disk information


10

askiing.scr creates ASCII file of data disk informationlatency.scr 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, thenboot up DOS and type

color c<return> at the DOS prompt type andforth<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 DOSdiskette and type

copy a:*.* b:<return> and follow the monitor instructions with the copy in thedrive, now type

copy con: b:autoexec.bat<return>color c<return> if you have a monochrome graphics cardforth<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 DOSformat a diskettetype 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


11

1000 more<return> -- this can take several minutesAt 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


12

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. Run2. Enter comment for data file3. Change run default4. Change session parameters5. Change isi parameters6. Instructions for user-defined sequence7. Change soft switches8. Run summary

0Ready

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


13

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


14

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


15

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 tone-airpuff 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 122232222DECIMAL255 maxeye ! 1 trl# ! \ beginning trial # 7 minimum ! 1 range ! \ iti values; 5, 1 are minimum2 #units ! 3 is unit1x 3 is unit2x \ unit collection1 #a/d ! \ a/d collection2 blksum(a)0 blksum(b)200 ( usec) unitduration ! \ Haer discriminator output duration


16

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\ normal intratrial parametersDECIMAL

\ millisec from beginning of trial:252 3 * scale pts \ trial duration, ms252 252 + 16 - scale airon \ air latency252 252 + 16 - 100 + scale airoff \ air latency252 scale toneon252 252 + 100 + scale toneoff252 scale lton252 252 + 100 + scale ltoff252 252 + scale shkon \ used for sp252 252 + 100 + scale shkoff252 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.


17

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 'AIR-ON/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# 6DECIMAL \ 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 122232222DECIMAL255 maxeye ! 1 trl# ! \ beginning trial # 20 minimum ! 20 range ! \ iti values; 5, 1 are minimum1 #units ! 3 is unit1x 3 is unit2x \ unit collection1 #a/d ! \ a/d collection2 blksum(a)0 blksum(b)200 ( usec) unitduration ! \ Haer discriminator output duration108 #trls ! 12 #blks ! 108 12 / #t/blk ! 4000 bin !\ bin is in usecs -- for the moment, use whole msecs.


18

: 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 switchestape off 4 before ! 1 after ! \ ON = tape recordingsafety off \ OFF = storage to diskpause off \ OFF = no pause between blocksfilter on \ ON = a/d filteringflash on \ ON = flash “inhibit” messageuse off \ OFF = no previous triallive off \ OFF = normal data collectionpcspulse on \ ON = start trial w/sync pulsepicture on \ ON = display graphics picture \ OFF = display numeric datadots on \ OFF = draw lines between datadatadots off \ OFF = no data dotsxmaximum pts u/ is xscalex \ 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 Micromotion3) Compiled Forth Runtime program4) Source code for Forth Summary program5) Data disk6) Library disk7) Interface card and your equipment8) IBM PC or equivalent with at least 256K RAM and 2 floppy disk drives9) A monitor and driver capable of displaying 200 x 640 graphics pixels10) Printer with compressed mode (e.g., IBM, EPSON have 17 cpi)


19

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 unusedPin 4 airpuffPin 5 shockPin 6 tapePin 7 trial synchronization pulsesPin 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). [Alter-natively, 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


20

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


21

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 Ô 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 Ô 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 (Ô 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>


22

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 statementsdrive 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 savingsaving forth<return>

leaving forthbye<return>

and then starting it up again to see if it worked withforth<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


23

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 parameters10. Move data from RAM to a LIBRARY disk11. Serial communications12. Convert data file to ascii for spreadsheets13. Graphics review with correlations of DATA disk14. Standard Z-scores analysis of DATA disk

Enter Selection Number: 0<return>Readyflush<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 55-65 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.


24

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.


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.


27 Summary Option 4: Analyze Data, Store on Library Disk, NoPrintout

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


25

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:

1222222222122222222212222222221222222222122222222212222222221222222222122222222212222222221222222222

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# 7990% paired (122222222)75% paired (12212222)unpaired (122112122112122121)christy’scold probe study (122232222)unusedunusedunusedtone/light blocks (1221222234434444)shock-us repl (1222234444)unusedlidocaine 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.


26

SCR# 811222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221222222221221222212212222122122221221222212212222122122221221222212212222122122221221222212212222122122221221222212212222122122221221222212212222122122221221222212212222122122221221222212212222122122221221222212212222122122221221222212211212211212212112211212211212212112211212211212212112211212211221121221121221211221121221121221211221121221121221211221121221122112122112122121122112122112122121122112122112122121122112122112211212211212212112211211222222222122222222212222222221222222222122222222212222222221222222222122222222212222222221222222222122222222212222222221222222222122222222212222222221222222222122222222212222222221222222222

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.


27

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 PRINTINGOFF (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


28

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 zero the array used to accumulate pictures for averaging.b display the averaged array (a square appears in upper

left of the screen).x add a range of trials (prompted) to the accumulation array.+ add the currently displayed trial to the accumulation array.


29

- remove the currently displayed trial from the accumulation array./ divide the number of trials added to the accumulation

array and display.7 used in Summary Option 13 only, this activates the

cross-correlation function8 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.)

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

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

l 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


30

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 1PreCS absolute deviation from baseline for eyelid channel 1CS maximum amplitude for eyelid channel 1CS cumulative area for eyelid channel 1CS peak latency to maximum amplitude for eyelid channel 1UCS maximum amplitude for eyelid channel 1UCS cumulative area for eyelid channel 1UCS peak latency to maximum amplitude for eyelid channel 1latency to 0.5 mm or greater response in CS periodPreCS count of unit channel 1CS count of unit channel 1UCS count of unit channel 1PreCS count of unit channel 2CS count of unit channel 2UCS count of unit channel 2PreCS 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


31

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:


32

SCR# 84756 252 598 252 598 504 598 40001 1 25 160 1 0 7 51 0 0 0 0 0 100 255new parameters for cold probe study.1000 250 350 250 350 750 850 20003 3 25 160 1 0 7 51 0 0 0 0 0 100 255Dragana’s problem.

this screen holds the default parameters:pts toneon toneoff lton ltoff shkon shkoff bin.usecunit1x unit2x badtime baseln#a/d #units bada/d critlvlchan1 chan2 chan3 chan4 un1 un badun 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 msecunit1x = gain for display of unit channel 1 histogramunit2x = gain for display of unit channel 2 histogrambadtime = time (in msec) after CS that cannot be a learned responsebaseln = 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 + un2bada/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


33

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


34

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 deaultsPress any other key to change defaults

E:\DAVE\FORTH\DATA.BOB

lag r n msec

0 .3865 126 01 .4199 126 42 .4513 126 83 .4825 126 124 .5120 126 165 .5389 126 206 .5659 126 247 .5943 126 288 .6170 126 329 .6372 126 36

10 .6535 126 4011 .6665 126 4412 .6718 126 4813 .6718 126 5214 .5853 126 5615 .6876 126 6016 .6905 126 6417 .6891 126 6818 .6880 126 7219 .6840 126 7620 .6799 126 8021 .6750 126 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


35

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 z-scores 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#bytescreate ranges 0 , 0 , here42 , 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).


36

SCR# 10 03sep88dgl/04jul89dgl\ rangesvariable #periods: 3rd ( --n) 3 #periods ! toneon 3 / ;4 constant d#bytescreate 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/3here 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 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 promptedb) select the trial type table to be used when promptedc) wait for the printout to be generatedd) 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 control-

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


37

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-by-block 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 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


38

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

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.5Nm/eye criterion level set at 0.5Bad nm/eye level set at 0.7Bad units set at 100Types 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


39

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


This means that the animal actually learned on the last trial of the previous day. You could also see something like


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


40

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.

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

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 filefile2 is to be the new ascii data fileand 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 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 1PreCS absolute deviation from baseline for eyelid channel 1CS maximum amplitude for eyelid channel 1CS cumulative area for eyelid channel 1CS peak latency to maximum amplitude for eyelid channel 1UCS maximum amplitude for eyelid channel 1UCS cumulative area for eyelid channel 1UCS peak latency to maximum amplitude for eyelid channel 1latency to the critlevel or greater response in CS periodPreCS count of unit channel 1CS count of unit channel 1UCS count of unit channel 1PreCS count of unit channel 2CS count of unit channel 2UCS count of unit channel 2PreCS 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

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

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.


43

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

1234567812345678123456781234567812345678123456781234567812345678750 250 600 250 600 500 600 5000pts toneon toneoff lton ltoff shkon shkoff bin.usec

The following is wrong because the number 500 is not within its proper space:1234567812345678123456781234567812345678123456781234567812345678750 250 600 250 600 500 600 5000pts 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:

1234567812345678123456781234567812345678123456781234567812345678750 250 600 250 600 500 600 5000pts 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

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


44

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

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 typeprinter 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< orFor 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


45

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


46

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

Aa& (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.

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

Cceiling (variable) cuts off the top of the unit displays so that they do not overlap and obscure the a/d data. Normally 28 ceiling !.


47

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.

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

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

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

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


48

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.

JKLl& (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.

Mmaxeye (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 8-bit 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.

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

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


49

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.

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

Ss& (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.


50

Tt& (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

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

Vversion (function) Identifies compilation date of Runtime program. To use, type version type<return>.

W


51

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

YZzscores (function). If this word is found in the dictionary then the zscores analysis (Summary Option 14) is loaded.


52

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, 238-248.

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.


53

a - springerextras.springer.com/2003/978-1-4020-7269-7/forth softwa… · web viewthe training...

Documents