Week 1 January 21, 1999
	The PC and AC-104 were set up and unpacked. Curiously, the AC-104 runs IBM PC DOS 2000 instead of MS-DOS. The complete MATRIXX/AC-104 package includes: ISI MATRIXX (XMath, SystemBuild, etc.) ISI AC-104 ISI RealSim Microsoft Visual C++ IBM PC DOS 2000 Phar Lap TNT DOS Extender The MATRIXX software was given to Chris Mattus to install on the server (so students could run the software from any location within the department). MATRIXX uses the flexlm license manager, so the department's existing flexlm license manager (Windows NT version) needed to be updated with the license information for MATRIXX. To obtain the license key, we phoned ISI, who promptly provided us with a license key good for 51 (1 user + 50 extra) users. A license for 1 user of RealSim was also provided. The Phar Lap TNT DOS Extender software was installed on the PC, logged in as admin.
Week 2 January 28, 1999
	Installed Visual C++ on the PC as admin. A RealSim install was attempted, but it required write permissions to the MATRIXX directory, which was now on the server. The RealSim install was postponed until Chris Mattus could log on to the server with admin (write) access, which occurred later in the day. A client install (necessary to use the server installation) of MATRIXX was performed successfully on the PC. Since communication with the AC-104 is performed over Ethernet, a second Ethernet card needed to be installed in the PC. The first Ethernet card was used to connect the PC to the campus network, including the server on which MATRIXX was installed. Although the AC-104 could have been placed on the same network segment as the PC, it was decided to place it on a dedicated network, so it was not exposed to campus traffic. In the future, the AC-104 might be moved to the campus segment which would allow, for example, professors to demonstrate the use of the AC-104 in a studio classroom, or other remote, network-enabled locations.
Week 3 February 4, 1999
	With the second Ethernet card in place, an FTP session was attempted with the AC-104. (The AC-104 runs an NCSA FTP server upon bootup; this is how programs are transferred into the unit.) The FTP connection opens successfully, but whenever the AC-104 tries to open a connection to the PC, which occurs whenever a directory listing is requested or a "get" command is sent, the AC-104 becomes completely unresponsive: The FTP session hangs, new FTP sessions will not open, even ping requests are lost. A call was placed to ISI's technical support area. Found a bug in the "autocode.bat" file, while attempting to run the super_cruise demo, in the RealSim binary (bin) directory. The "autostar_command" variable (about halfway down the file) should be assigned to "$ENV{ISIHOME}/bin/autostar_60.6", not "$ENV{ISIHOME}/bin/autostar". The demo will still not execute because of linker errors resulting from unresolved symbols (some libraries missing?). Initial impressions of MATRIXX package: This software is reminiscent of UNIX packages (perhaps because it was ported from UNIX?!), where components are linked together by shell scripts, or in this case, DOS batch files and PERL (!) scripts. While more acceptable in the UNIX world, the use of DOS batch files, especially those requiring user input, results in a shoddy user interface. Most Windows packages today are, in comparison, polished and present the user with a fairly consistent interface. While the core MATRIXX tools, XMath, SystemBuild, and RealSim, have clean interfaces, the code to tie the components together is crude. Using MATRIXX, a cruise control demo was opened in SystemBuild and, after much hassle, was simulated. The only apparent way to edit the properties of a particular block is to select "Block Properties" from the Edit menu. It would make more sense if the block was double-clickable; instead a double-click on a block does nothing. In comparison, simulink lets you edit the properties of any block by double-clicking it, resulting in a simpiler interface than that presented in SystemBuild.
Week 4 February 11, 1999
	FTP Hang Update: A temporary workaround to the hanging FTP problems was found. By attaching a monitor and keyboard to the AC-104, it was possible to see what was occurring during the hangs. Unfortunately, the AC-104 stopped responding to user input during the hang and provided no on-screen indication of the cause of the hang. However, with the monitor and keyboard attached, it was found that if the FTP server is stopped (before any attempt is made to get a directory listing or a file), and then restarted from DOS, the hangs would no longer occur. The reason why the hangs stopped occurring after restarting the FTP server is unknown but being investigated. ISI Support suggested adding an entry in the CONFIG.TEL file (which sets TCP/IP parameters for the NCSA FTP server) that explicitly identifies the host (the computer making the connection to the AC-104) by both name and numeric IP address. Surprisingly, this permanantly fixed the hanging problems. It does not explain why restarting the FTP server fixed the problem as well (temporarily). After solving the FTP issues, another attempt at getting the super_cruise demo to work was made. The executable failed to link, as earlier. As it turns out, the Phar Lap TNT DOS Extender has two library directories: lib/ which holds libaries that can be linked using Phar Lap's own linker (386LINK), and cofflib/ which contains the same libaries, but in XCOFF format, which is the format supported by Microsoft Visual C++. After altering the LIB environment variable, which holds the path to the DOS Extender libaries, the super_cruise demo linked successfully. Note that when the Target is requested, the IP Address (or hostname) for the AC-104 must be used, because this value is passed to an FTP client to transfer the executable to the AC-104. Finally, the super_cruise demo was built and executed on the AC-104. As the demo executes, the PC presents, using the "Interactive Animation" package, a graphical display of the cruise control parameters, including Manual Throttle In, Brakes, Incline, Speed, RPM's, Speed Error, Throttle Position, Set Speed and Resume Controls, and also displays the proportional, integral, and derivative gains, and allows the user to change any (changable) parameter during program execution.
Week 5 February 18, 1999
	The plan now was to get I/O with the real world going. First, it was necessary to understand how a model, with Interactive Animation (IA) enabled, should be built and simulated in RealSim. Following the tutorial in the PDF manual, a trivial model which consisted of a single gain stage was created. The model accepted input from a graphical slider (in IA), processed it through the gain stage, and displayed the output on a graph (also in IA). Although the tutorial was designed to simulate the model on the AC-104, it did not describe how to interface signals with the outside world using the ADC or DAC cards. So, using the Hardware Connection Editor (HCE) portion of RealSim, the output was specified as being connected to the first DAC channel. [Note: The driver for the Ruby-MM DAC card had to first be installed off a floppy, even though the driver files were present on the host so that the driver would be recognized as a valid output device by the HCE.] After configuring the HCE to send output to this DAC channel (as well as the IA client), the model was executed on the AC-104. It was not practically possible to tell whether an analog signal was present at the DAC output because a proper 50-pin Centronics connector was not installed. The second half of the project was finally started with the installation of the Motorola M68MPFB1632 Modular Platform Board and the M68MPB376 MCU Personality Board, along with the ICD32 (In-Circuit Debugger) interface and associated software. The ICD is connected via a small header located on the platform board. The ICD unit connects to the PC via a standard parallel interface, but using a DB25 connector instead of the 50-pin Centronics connection customarily found at the end of a "parallel port" cable. The platform board is powered by an external 5 volt supply, connected using a "wire-clamping" connector. The ICD32 software, which is strictly DOS-based consists of an assembler, IASM32, and the background debugger, ICD32. The ICD32 package was successfully installed on the PC. Since a parallel port cable terminated with dual DB25 connectors was not available, proper communication with the MEVB could not be tested.
Week 6 February 25, 1999
	50-pin Centronics cables to connect to the AC-104's ADC and DAC cards were obtained, allowing each functional I/O pin of the cards to be broken out to a breadboard. After decoding the pinout of the connectors, (note that the pinout specified in the AIM1612 and Ruby-MM manuals details that of the header, internal to the AC-104, and that the RealSim "PC" documentation must be consulted to obtain the pinout on the Centronics connectors) the trivial gain model was run again. After locating channel one of the Ruby-MM DAC card, the Interactive Animation slider, which specified the input to the gain block, was varied as the channel output was observed on the oscilliscope. Although the voltage was supposed to range from -10V to 10V (as was the default analog output range configuration for Ruby-MM analog channels), no noticable fluctuation of the output could be seen, which indicated perhaps that the output was not being updated as the internal output state changed. To see if any A/D or D/A functions would work on the AC-104, the cpc_loop demo, which performs loopback test between A/D channels and D/A channels in addition to serial loopback between the COM1 and COM2 serial ports. Unfortunately, this demo would not compile becuase of unresolved symbol errors from the linker, referring to missing definitions of some serial subroutines. Attempts were made to link the project using the TNT linker as well as the MSVC linker, both to no avail. ISI has been contacted with this issue. A dual DB25-connector parallel port cable was installed betweent the PC104 and ICD unit. A single-line assembly language program for the 68376 was written, assembled in IASM32, and was to be downloaded into the '376 and executed. Although the ICD32 appeared to be able to communicate with the '376 at times, the connection appeared to be intermittent, as often ICD32 reported bus errors while attempting to communicate with the '376 board. Perhaps this is due to the fact that ICD32 is being run in a DOS window within Windows NT, and not in a true DOS environment.