
                         FLASH LOADER RELEASE NOTES                                  
                         --------------------------
 
                              December 2, 1996

                       Flash Loader 2.5c - October 6, 1996
                      Target Loader 2.5  - November 12, 1996

____________________________________________________________________________
                                   
                                   CONTENTS

1.0  INTRODUCTION
2.0  TERMINOLOGY
3.0  A NOTE ON NS486SXF REVISIONS
4.0  FILES IN THIS DISTRIBUTION
5.0  COMMUNICATIONS PORT (UART)
6.0  RUNNING THE TARGET LOADER
7.0  BOARD SETUP
8.0  USING THE FLASH LOADER TO DOWNLOAD INTO RAM
9.0  UPDATING THE TARGET LOADER
10.0 DETECTION OF CPU SPEED AND DRAM SIZE
11.0 ICA INFORMATION
12.0 APPLICATION BOOT ENVIRONMENT
13.0 BOOTING FROM PCMCIA
14.0 CHANGES TO THE FLASH LOADER AND TARGET LOADER

____________________________________________________________________________

1.0  INTRODUCTION

  This document provides information not found in the Flash Loader Reference 
  Guide.  The Flash Loader Reference Guide should be consulted for information 
  on use of the Flash Loader.

  Some information in this file is replicated in the Flash Loader Reference
  guide.  This info was not in the older versions of the guide, so it is
  left in this file for ease of access.

2.0  TERMINOLOGY

  The term Flash Loader refers to the DOS application "FLASHLDR.EXE" which
  is run on a host PC.  The term Target Loader refers to the program
  located in the boot block of the flash chip on the NS486SXF evaluation
  board.

3.0  A NOTE ON NS486SXF REVISIONS

  This version (2.5) of the Target Loader should be used with the NS486SXF
  revision B2 and newer.  If you have older version of the NS486SXF you
  should use the software provided with that chip.  The Flash Loader
  (DOS based utility) itself will work with any version of the Target
  Loader, so you can use this version of the Flash Loader if desired.

  If you have a revision B2 or newer part, you can run any version of the 
  Target Loader.  However, several features were added to this version of
  the Target Loader, and software for the NS486SXF evaluation board may
  depend on these features.  Therefore, it is recommended that you run
  this version of the Target Loader or newer.  See the section
  "UPDATING THE TARGET LOADER" for information on how to update to this
  version.

4.0  FILES IN THIS DISTRIBUTION

  The Flash Loader Reference Guide lists the files included with the
  Flash Loader.  The file "FLASH1.ICO", which is not referenced in the
  guide, is simple a Windows icon for the Flash Loader program.  The install
  program creates an icon to launch the Flash Loader from Windows.

5.0  COMMUNICATIONS PORT (UART)

  The Flash Loader communicates with the Target Loader through a serial
  port.  The supplied straight through male to female serial cable should
  be used to connect the target DEBUG port (J7) to an open serial port
  on the host PC.  The file "FLASHLDR.FLC" has an entry to indicate which
  serial port on the PC is used for the Flash Loader.  This defaults
  to COM1, but can be changed as needed.

  The Flash Loader can communicate with the Target Loader at many different
  baud rates.  The default is 9600, as set up in the "FLASHLDR.FLC" file.
  Since large downloads may take a long period of time at 9600 bps, you
  may wish to use a faster baud rate.  Simply change the "baud=9600"
  option in the "FLASHLDR.FLC" file.  Under DOS and Windows 95, you
  can probably use as fast as 115200 bps reliably.  Under Windows NT,
  it is difficult to connect to the target at faster than 9600 bps.
  However, if you try repeatedly (using the "init" or "conn" commands)
  you may be able to connect.  After connecting, the connection usually
  works OK under Windows NT.  Note that if you put the window running the
  Flash Loader in the background you may loose connection to the target,
  at which time an error message will be printed.

  Also note that if you connect to the board at faster than 9600 bps
  and then open a terminal "vt command or external terminal program" the
  repeating 'A' characters (see next section) will be displayed at the
  last baud rate you connected at.  (So if the terminal is opened at 9600
  bps, you may see garbage or blank spaces.)  This is not a problem.  If you
  reset the board, the output will once more be at 9600 bps.

6.0  RUNNING THE TARGET LOADER

  As described in the Flash Loader Reference Guide, when the NS486SXF
  evaluation board is powered on or reset with the MONITOR (W6) jumper
  installed, the Target Loader will gain control of the system.  You
  can verify proper operation by opening a terminal to the target at
  9600 bps.  When the board is powered on or reset with the MONITOR
  jumper installed, you will see the following banner:

      CQI Flash Loader Target (First Stage) - V2.5, 12 NOV 96

      National Semiconductor 486SXF Evaluation Board

      Copyright (c) 1994,95,96 Cyber Quest, Inc.

  After this the Target Loader will repeatedly send the character 'A'
  to the DEBUG port.  This indicates that the Target Loader is ready
  to communicate with the Flash Loader.  You can determine the version
  of the Target Loader on your board with the above steps, as well as
  determine that the Target Loader is running.

  At this point you should refer to the Flash Loader Reference Guide and
  step through the Hello World example to gain a basic understanding of
  the Flash Loader and Target Loader operation.  In the event that you
  do see the Target Loader banner correctly but get an error when 
  using the "init" or "conn" commands in the Flash Loader, see the section
  "BOARD SETUP" in this document.

7.0  BOARD SETUP

  The NS486SXF evaluation board is shipped with the Target Loader in flash
  and the system flash tables initialized.  When connected to the target,
  the Flash Loader utility obtains a map of the Flash device from the
  target.  This map is based upon the "board" option in the Flash Loader.
  As shipped this will be set to "ns486sxf-a200-eval".  In certain cases,
  such as when the user erases the flash tables at 0xFFFFA000 and then
  does not update the flash, this option can be set wrong.  In this case,
  when connecting to the target, this message will be displayed:

      Boot table flag not found
      Reinit boot table
      Operation FAILED!  Target system not responding 
      
  Furthermore, the "map" and "dir" commands will not show the 
  proper board name of "ns486sxf-a200-eval".  In this case, you need
  to reinitialize the flash tables before the Flash Loader can properly
  download code to the Target Loader.  To do this, follow this
  sequence:

      (1)  Run the Flash Loader (type "FLASHLDR" from the Flash Loader
           directory)

      (2)  Make sure the target loader is running (see "RUNNING THE
           TARGET LOADER" in this document)

      (3)  Execute the following commands:

           FLASH CMD:  init                // connect to board
           FLASH CMD:  setsys              // set BOARD and SYSTEM parameters
           FLASH CMD:  update              // update flash tables

  After this, the Flash Loader can properly communicate with the Target
  Loader.

  The file "SETSYS.FLC" sets the "board" and "system" names.  You can edit 
  this file to give the system a meaningful "system" name if desired (the 
  default is "eval", earlier releases defaulted to "lab").  The "board" name 
  must be set to "ns486sxf-a200-eval" for proper operation.  You can follow
  the above steps to update the flash tables at any time to update the
  "system" name.

8.0  USING THE FLASH LOADER TO DOWNLOAD INTO RAM

  Normally the Flash Loader is used to download programs into Flash.
  However, it can also be used to download programs into DRAM.  The
  "map" command will display an entry called "FREE RAM" at address 0x50000.
  You may use this area of RAM to load programs into.  The size of this
  block should be listed as 16064K, which is a 16 MB block, minus the
  0x50000 bytes reserved by the Target Loader.  If the flash tables on your
  evaluation board were setup by version 2.4 or earlier of the Flash Loader,
  this block will be less that 1MB.  Version 2.5 and newer of the Flash
  Loader allow you to use all installed memory above 0x50000.  Therefore,
  if you have a 4MB or 16MB SIMM you may use the additional memory (the
  Target Loader automagically sizes the DRAM).  The following table shows
  what memory is available depending on memory size:

    DRAM SIMM SIZE     MEMORY AVAILABLE FOR RAM DOWNLOAD
    --------------     ---------------------------------
         1  MB         0x00050000 - 0x000FFFFF
         4  MB         0x00050000 - 0x003FFFFF
         16 MB         0x00050000 - 0x00FFFFFF

  Simply type "memory=ram" to instruct the Flash Loader to allow you to
  download into this area.  For example, this sequence will allow you
  to run the Hello World program from RAM:

      FLASH CMD: memory=ram
      FLASH CMD: program hello.bin addr=50000 vector=50000p
      FLASH CMD: update
      FLASH CMD: boot hello; vt

  Hit reset on the Target and ESCape on the PC to stop running the Hello 
  World program.  Note that the DRAM data may be lost when turning off
  the power to the NS486SXF evaluation board or hitting the RESET button.
  Therefore, to use DRAM for programs you must use the Flash Loader to
  download the code and the use the "boot" command to jump to the code.
  Also, the Flash Tables will still show an entry for the program
  downloaded into RAM after resetting the board.  To erase the invalid
  entry from the Flash Tables type "del <name>" (e.g., "del hello") 
  followed by "update".

  Using the Flash Loader to download code into DRAM can be useful to run
  code too large to fit in the flash or code that has been linked with
  linkers that do not support copying of data segments from ROM to RAM.
  (For example standard MASM code with a data segment linked with 
  Microsoft's linker with no special provisions for read only memory.)

9.0  UPDATING THE TARGET LOADER

  ** UPDATING THE TARGET LOADER MAY CAUSE THE FLASH RESIDENT TARGET 
  ** LOADER TO BE LOST OR DAMAGED IF THE UPDATE IS UNSUCCESSFUL.
  ** THIS WILL CAUSE THE BOARD TO BE UN-USABLE.  PLEASE READ THIS
  ** SECTION CAREFULLY IF YOU ARE PLANNING ON UPDATING THE TARGET
  ** LOADER.

  You should only attempt to update the Target Loader to version 2.5 if
  you have the revision B2 or newer NS486SXF part and you are using an
  older version of the Target Loader.  Any other attempt to update the
  Target Loader may destroy the flash program.  If this happens the
  board will be un-usable and will require special hardware to
  reprogram the Flash.

  Section 14 of this document list the changes in the Flash and Target
  Loaders.  You may want to consult this to determine if you want to upgrade
  the version of the Target Loader on your board.  (There is no reason not
  to use the new (2.5c) version of the Flash Loader, even if you do not
  update the Target Loader.)

  Also note that attempting to reprogram the Flash boot block (0xFFFFC000
  to 0xFFFFFFFF) with other programs will also cause the Target Loader
  program to be destroyed.  Normally the Flash Loader will not allow
  you to program the boot block.  However, commands in the "PRTARG1.FLC"
  file will allow you to reprogram the boot block.  Please do not
  attempt this.

  With that out of the way, the update is quite simple.

    (0)  Make sure you are in the directory with the new Flash Loader and
         Target Loader, and that no other directory in your path contains
         the Flash Loader and associated files.

    (1)  Make absolutely sure that the Flash Loader and Target Loader
         are communicating correctly.  This means the MONITOR (W6)
         jumper must be installed.  Although these jumpers should
         NOT be changed by the user, also verify that jumper W4 is on
         the 1-2 position and jumper W7 is on the 1-2 position.

    (2)  Load the Flash Loader utility by typing "FLASHLDR" in the
         Flash Loader directory.  Power on the NS486SXF evaluation board.

    (3)  Open a terminal by typing "vt"

    (4)  Press reset and make sure you see the Target Loader banner.  If
         it already indicating version 2.5 or newer, do not update the
         Target Loader.

    (5)  Hit "ESCape" on your PC to close the terminal window.  
    
    (6)  Type "init" to connect to the evaluation board.  If that is
         successful, type "map" and verify that the first line displayed
         indicates "NS486SXF-A200-EVAL board".  If it does not,
         see the section "BOARD SETUP" in this document to reinitialize
         the Flash Tables.

    (7)  Type "prtarg1" to download the new Target Loader to the
         evaluation board.  After downloading you will have to answer
         "y" to two prompts to actually reprogram the boot block.  If you
         see any errors in the download sequence, answer "n" to the prompts.
         Otherwise, answer "y".

    (8)  After updating the boot block, you will see the output of a 
         "map" command.  Notice that the entry "TARGET1" will be in the
         display at address 0xFFFFC000 to 0xFFFFFFF.

    (9)  Open a terminal by typing "vt".  Reset the board and you will see
         the Target Loader banner for the new version (2.5).
    
    (10) Hit "ESCape" on your PC to close the terminal window.  
    
    (11) Type "init" to connect to the target.  At this point you are
         running the new Target Loader.  You may want to verify this
         by typing "ica".  If you see a valid table with such information
         as the CPU Speed and RAM Size, the new Target Loader is
         functioning correctly!

  Note: you can use the command "del target1" followed by "update" to
  remove the TARGET1 entry from the "dir" output, if this is desired.
  This will not delete the program, but just remove it from the directory.
  There is no advantage to this, but some users may prefer to not see
  the Target Loader in the flash directory.

  Thats it!  Try out the features of the new Target Loader!

10.0 DETECTION OF CPU SPEED AND DRAM SIZE

  Version 2.4 and newer of the Target Loader will automatically determine the
  CPU speed and the size of the DRAM SIMM installed (1,4, or 16MB).
  This information is stored in a certain DRAM area.  When you are in
  the Flash Loader, you can use the command "ica" to display the
  CPU Speed and RAM Size.  Example output of the ICA command is:

      ICA Table:

        Valid     = TRUE (0xA1B2C3D4)
        Cmd       = TARGET_INFO (0x0005)
        Status    = 0x0000
        Data Addr = 0x00000580
        Data Size = 20

        Boot      = 0x00000000
        Orig EAX  = 0x00000000
        Orig EDX  = 0x00000007
        CPU Speed = 2512224 (25 MHz)
        RAM Size  = 4194304 (4 MB)
  
  If you using an older version of the Target Loader with the current
  Flash Loader you will get a message that the ICA is not valid when
  attempting to use the "ica" command.

  The most useful lines of information are the CPU Speed and RAM
  Size.  All of the above information is stored into the DRAM at
  a specific address before jumping to the program set to boot.  This
  allows user programs and various OSs, RTOSs, and tools to determine
  the CPU Speed (which is required to properly program the UART and
  Timers) and the DRAM Size.  Note that if a booted program reconfigures
  the DRAM controller or writes to the area uses to store this information,
  you may not be able to read the information in your application.
  Therefore, in your code you may wish to save this information before
  reconfiguring the DRAM controller (which is only necessary if
  you want to change the way the DRAM is setup) or writing to the
  areas in DRAM that hold this information.  With third party tools you
  may not have control of this, so the tool may need to save this
  information if it changes the DRAM setup or writes to certain areas
  in DRAM.  You may want to ask the third party vendor if your code will
  be able to access this information.

  The section "ICA INFORMATION" later in this document describes the
  structures set up in the DRAM area.

11.0 ICA INFORMATION

  The Target Loader sets up a structure at location 0x4F0 in DRAM.  This
  area is referred to as the "ICA".  There are five items stored in this
  structure.  In C, this structure is as follows:

      typedef struct
      {
        WORD_32        valid;                     
        WORD_16        command;  
        WORD_16        status;      
        WORD_32        data_addr;
        WORD_32        data_size;
      }  ICA_TBL_STRUCT ;

  For those not familiar with the C ordering, the first item located
  at 0x4f0 will be the 32 bit "valid" value.  In summary:

      location      size   item
      ------------- ------ -------------------------
      0x4F0 - 0x4F3 32bit  valid - set to 0xA1B2C3D4 if the ICA is valid
      0x4F4 - 0x4F5 16bit  command - will be set to 0x0005 if target
                                     information is available
      0x4F6 - 0x4F7 16bit  status - set to 0x0000 if ICA is OK
      0x4F8 - 0x4FB 32bit  data_addr - 32 bit address of structure with
                                       target information
      0x4FC - 0x4FD 32bit  data_size - size of structure pointed to by
                                       data_addr

  Assuming that these items are valid, you can then look at the structure
  at the address in data_addr.  (In the current Target Loader this is
  0x00000580, although this may change with newer versions.)  This
  structure is:

      typedef struct
      {
        WORD_32        boot_status;
        WORD_32        original_eax;     /* CPU id on some chips */
        WORD_32        original_edx;     /* CPU self-test result upon reset */
        WORD_32        cpu_speed;        /* in Hz (-1 if unknown) */
        WORD_32        ram_size;         /* in bytes (-1 if unknown) */
      }  ICA_TARGET_INFO_STRUCT ;
       
  A summary of these fields:

      location      size   item
      ------------- ------ -------------------------
      data_addr+0   32bit  boot_status - not currently used
      data_addr+4   32bit  original_eax - EAX register value at boot or
                                          reset.  In current NS486SXF
                                          parts, this will be 0
      data_addr+8   32bit  original_edx - EDX register at boot or reset.
                                          In the NS486SXF this is the
                                          CPU microcode revision.  See
                                          the Programmers Guide for
                                          more information.
      data_addr+12  32bit  cpu_speed - speed of CPU in Hz.  -1 if 
                                       unknown.
      data_addr+16  32bit  ram_size - size of DRAM in bytes.  -1 if
                                      unknown.

  The CPU Speed is determined by a timing algorithm in the Target Loader.
  This value is quite accurate.  It can vary slightly from board to board
  as the oscillator speeds may vary slightly.  A rounded off MHz speed
  of the CPU (e.g., 20, 25) is stored in the scratchpad register of the
  external UART.  You may wish to use that number to determine the
  CPU speed, or you can use the full 32bit value in the Target Information
  structure, as applicable for your application.  See the section later
  called "APPLICATION BOOT ENVIRONMENT" for more information.
  If the CPU speed is unknown (-1) you should default to 25MHz, the
  speed that the NS486SXF evaluation board is shipped at.

  The DRAM size is determined by a simple algorithm in the Target Loader.
  Note: the NS486SXF board only supports single sided 72 pin SIMMs of
  sizes 1, 4, and 16MB.  Other SIMMs may cause the board to operate
  incorrectly, not at all, or return a wrong DRAM size.  In addition to
  storing the DRAM size in bytes in memory, the DRAM controller is setup
  in the correct manner.  Therefore, user code could just read the DRAM
  controller registers to determine the amount of DRAM.  See the
  NS486SXF Data Sheet for the interpretation of the DRAM registers.

  The following pseudo-code (in C) is the recommended way to check the
  ICA and the Target Information.


    #define  ICA_TBL_ADDR  0x4F0       /* Inter-process Communications Area */
    #define  ICA_TBL_VALID 0xa1b2c3d4L /* magic validation number, if
                                          not set then somebody stepped on 
                                          that memory location and the rest 
                                          of the stuff is probably invalid */

    #define  NO_ICA_TBL_CMD         0x0000  /* no ICA command */
    #define  TARGET_INFO_ICA_CMD    0x0005  /* ICA points to Target Info */

    #define  OK_ICA_STATUS              0   /* ICA is error free */

    /* structure definitions from above should be here! */

    /* structures for reading ICA and Target Info */
    ICA_TBL_STRUCT *ica_tbl;
    ICA_TARGET_INFO_STRUCT *ica_data;

    /* point to ICA */
    ica_tbl = Make_Pointer_From_Phys_Addr(ICA_TBL_ADDR);
    
    /* see if ICA is valid */
    if (ica_tbl->valid != ICA_TBL_VALID) error();         
    
    /* see if ICA status is OK */
    if (ica_tbl->status != OK_ICA_STATUS) error();        
    
    /* see if ICA points to Target Info */
    if (ica_tbl->command != TARGET_INFO_ICA_CMD) error(); 
    
    /* get pointer to Target Info if all OK so far */
    ica_data = Make_Pointer_From_Phys_Addr(ica_tbl->data_addr);

    /* read Target Information */
   
        [Read the information you want to use]

  Sample code that reads the ICA is included with the NS486SXF evaluation
  board software.  Please see the "README.TXT" file on the software disk
  for more information.

  Note also that a version of the code used to size the DRAM and measure
  the CPU speed is included with the NS486SXF evaluation board software
  as example code.  Again, see the "README.TXT" file with the software.

12.0 APPLICATION BOOT ENVIRONMENT

  When the Target Loader jumps to the program set to boot, several things
  have already been setup.

  The DRAM controller is configured to either 1, 4, or 16MB of DRAM 
  (as automatically detected).  The DRAM starts at address 0x0.

  The ICA information described in the section "ICA INFORMATION" is set up
  in DRAM.  This includes the CPU Speed and DRAM Size.  Note:  later
  software may write over the ICA or the Target Info or reconfigure the
  DRAM.  So the ICA and Target Information should be read before this
  occurs.

  The external UART (DEBUG UART) scratchpad register (0x2FF) is set to
  the CPU speed in MHz (e.g., 20, 25).  This number is only valid
  if the ICA is valid and the Target Information "CPU Speed" is
  valid (not equal to -1).  Note: later software may change this
  register, so this value should be read before it is changed.

  All segment registers are loaded and are set to access all 4GB of
  the memory addressing range.  Outside of this, nothing is guaranteed
  about the GDT, so code should set up a GDT with known values and
  reload the segment registers when possible.  All segments are also
  set up as 32 bit segments.

  The ESP register is set to 0xFFF0.  Therefore, the initial stack will
  grow down from that address.

  The EDX register will hold the value it held upon reset or power on of
  the part.  (This is the CPU Microcode revision number, which is also
  available in the Target Information structure).

  The Target Loader may use some NS486SXF peripherals, so several registers
  may be setup different from the reset value.  All efforts have been made
  to make this unobtrusive, so user code does not need to worry about what
  peripherals have been used.

13.0 BOOTING FROM PCMCIA

  This version of the Target Loader will check for a PCMCIA memory card
  with a certain signature when booting with the MONITOR (W6) jumper off.
  In this case, the Target Loader will jump to an address in the PCMCIA
  range.  This allows automatic booting from a PCMCIA SRAM or Flash card
  if installed.  If no card is inserted or the card is not booted from, the
  Target Loader will disable the PCMCIA controller before jumping to the 
  boot program, so the Target Loader use of the PCMCIA card should not 
  affect other code.

  If the Target Loader detects a PCMCIA card, it will map the first 8MB
  of the card memory at address 0x0780_0000.  It then scans the first
  64K of that memory at every 512 byte boundary until it finds a valid
  "Flash Loader bootable program".  The first valid bootable program will
  be jumped to by the Target Loader.

  For a program in the PCMCIA card to be recognized as bootable, it must
  meet several criteria.  The program (starting at a 512 byte boundary) 
  must contain the following header:

          Offset    Size      Description
          ------    ----      -----------
          0         2 bytes   signature (0x55, 0xAA)
          2         1 byte    length of program (bytes) divided by 512
          3         2 bytes   short jump instruction to start of program
          5         1 byte    checksum

  Please note that the use of the word "program" in this description is
  the set of bytes containing the code to boot from.  Therefore, it is
  most likely a binary file that has been linked and located.

  If the Target Loader sees the proper signature (i.e., the first two
  bytes of the program are 0x55 and 0xAA respectively), it will then
  make sure that the program checksum is correct.  The checksum is a
  single byte that makes the sum of all the bytes in the program
  (including the header) modulo 256 equal to zero.

  Since the program size is indicated by the byte at offset 2 multiplied
  by 512, the program length should be a multiple of 512 bytes.  If extra
  bytes are needed at the end of the program to make it a multiple of
  512 bytes, they should be filled with zeros.

  If the Target Loader detects a valid signature and checksum, it will
  transfer execution to the instruction at byte offset 3.  Since the
  checksum is at offset 5, this must be a two byte jump instruction, such
  as a short jump.

  To use the PCMCIA boot option you must make sure your program has a valid
  header.  The suggested algorithm is as follows:

       (0) leave 6 bytes open at the start of the program for the header
           information.

       (1) increase the size of the program (binary) so that is is an
           integral multiple of 512.  (E.g., a 400 byte program would 
           become 512 bytes.) 

       (2) if the file size was increased, set the extra padding bytes to
           zero.

       (3) fill in the bytes at offsets 0 and 1 to 0x55 and 0xAA
           respectively (signature).

       (4) fill in the byte at offset 2 (length) to the length of the
           binary (in bytes) divided by 512.

       (5) put a short jump instruction at offset 3 to the start of
           your program.  The byte sequence 0xEB, 0x01 is a jump to
           offset 6, which is the simplest solution.  If the program
           is created in assembly you can simple put the short jump
           instruction in the assembly at this offset.

       (6) sum all the bytes of the program (and the extra padding bytes)
           and discard any overflow past the one byte.  Then subtract this
           value from 0 to obtain the one byte checksum.  Put this value
           at offset 5 within the header.

  Please note that the size field is only one byte, so valid sizes
  are 512 bytes (0x01 * 512) to 131,072 bytes (0xFF * 512).  However, this
  size field is only used to compute the checksum, so if the program is
  larger than 128K you can simply set the size to 0xFF and compute the
  checksum based only on the first 128K.  It is also possible to set the
  size to any length less than the program and compute the checksum based
  on that size.  The checksum is intended to verify that the program
  in the PCMCIA is valid, so it is desirable to compute the checksum based
  on the full size of the program.

  The latest release of the NS486SXF evaluation board included a sample
  bootable program and a utility to convert a binary file into a bootable
  program.  See the README file for that utility for more information.

14.0 CHANGES TO THE FLASH LOADER AND TARGET LOADER

  The differences between version 2.4 and 2.5c of the Flash Loader are
  fairly minor.  For one, 2.5c allows DRAM above 1MB to be used to download
  code into directly from the Flash Loader.

  Several changes were made to the Target Loader from version 2.4 to version
  2.5.  They are as follows:

    * The BIU "Boot ROM Access Time Register" at 0xEF54 was changed to 0x5A
      (from 0x1A).  This change sets 2 clock cycles of "RDY extension", which
      may be required for some ISA or PC/104 cards.  This will, in general, 
      improve stability of code talking to ISA or PC/104 boards that use the 
      RDY signal.
  
    * The BIU "Chip Select Access Time Register 1" at 0xEF50 was changed
      to 0xCA (from 0xAC).  This sets the logical chip select 1 (which
      is used for the boot Flash) timing to be consistant with the timing
      set in the "Boot ROM Access Time Register".  This also increases the
      number of wait states to accesses to the external UART.  Newer
      evaluation boards have an updated ("C7") version of the Altera FPGA
      that fixes various board problems.  The newer FPGA requires the
      increased UART timing.  

    * The logical chip select 2 address range was changed to 0xFFF00000 -
      0xFFFFFFFF.  This change is simply to make the setup chip select
      range agree with the evaluation board documentation memory map.  Not
      all of this range is actually used by the Flash device.

    * During boot, the target loader writes several bytes into memory to
      determine the size of the DRAM SIMM installed.  The target loader now
      restores the original DRAM contents after the check, so user code will
      not get overwritten.  This only happens when the board is reset with
      user code in the DRAM.  This is not a "safe" action, as the DRAM can
      loose data when the board is reset, as the DRAM controller will stop
      refreshing the DRAM until it is re-initialized.  However, in practice
      the DRAM does seem to hold data long enough to allow a reset, so this
      change makes the target loader boot less intrusive.  The target loader
      still writes to memory below 0x50000, so this area will always get
      changed during a reset.

____________________________________________________________________________
