[FRAM71] Pre-Production Batch

[Paul Berger (Canada)]

In the documentation Hans gives sample programs to load images into your FRAM71 using a serial connection, however since I do not have a PILBOX, and I found the setup using a serial connection through a 82164A required what seemed like lot of setup, so I came up with this alternate solution.

My solution is to load a ASCII HEX dump of the image from a file instead of across a serial link. In the package of ROM images that has been made available these are the xxxxxxx.MEM files. The .MEM files as distributed are DOS text files ie the records are terminated with a CRLF sequence which is not compatible with the 71B's idea of a text file, which is no surprise I think every system HP built has a different text file format. The 71B text file format starts each record with one byte of 00 and a second byte with the record length, I found the easiest way to convert the files was to us HP's lifutil to copy the DOS files to a LIF format diskette with the conversion option "DOS text to HP BASIC ASCII" however it would probably be a trivial exercise to write a program to make the conversion.

Below are two of my programs that are the equivalent of Hans' programs to load the OS image and to load the hard FORTH image respectively. These programs could also be used to load other ROM images as well, things you may need to modify are the source file name in line 20, target address in line 30, and the size of the image in line 40. The size may seem a bit cryptic but here is how it works on each pass of the loop starting on line 40, one record containing 64 bytes of data is read from the file the 32*64 is 2048 or the ASCII HEX equivalent of 1K bytes of binary code so in the example of the OS image the size is expressed as 64*32-1 or 64K so if you image was 16K line 40 would read "FOR I=0 TO 16*32-1"

Code:

10 DIM A$[64]
20 ASSIGN #1 TO "SYS2CDCC:TAPE"
30 A=HTD("00000")
35 DISP "WRITING...."
40 FOR I=0 TO 64*32-1
50 X$=DTH$(A+I*64)
60 READ #1;A$
70 POKE X$,A$
80 NEXT I
90 ASSIGN #1 TO *
100 DISP "DONE"
110 END

Code:

10 DIM A$[64]
20 ASSIGN #1 TO HRDFORTH:TAPE
30 A=HTD("30000")
35 DISP "WRITING...."
40 FOR I=0 TO 32*32-1
50 X$=DTH$(A+I*64)
60 READ #1;A$
70 POKE X$,A$
80 NEXT I
90 ASSIGN #1 TO *
100 DISP "DONE"
110 END

I also wrote a simple C program to convert binary images to DOS text HEX dumps. It was written for an ancient version of Waterloo C but I think the only function that might not be standard in it is 'nibble = div(inbyte,0x10)' this div function does an integer divide and returns and integer quotient and remainder. The program is very rough and has fixed input and output file names, but it does work.

Code:

/*
 * BIN2HEX - Convert Binary Image files to a DOS Hex file 
 *           with 64 byte records terminated by a CRLF as per 
 *           normal DOS conventions.                              
 * 
 *           The program opens a files names TEST.BIN and translates 
 *           it to HEX file OUT.HEX.
 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>



FILE
        *fpi,
        *fpo;



/*
 * Main program
 */
main(int argc, char *argv[])
{
        unsigned char inbyte, low_nib, high_nib;
        int byte_count;
        auto div_t nibble;   /* nibble.quot high nibble nibble.rem low nibble */


        // Open files
        fpi = fopen("TEST.BIN", "rb");
        fpo = fopen("OUT.HEX", "wb");

        byte_count = 0;
        while (! feof(fpi))
        {

           inbyte = fgetc(fpi);
           nibble = div(inbyte,0x10);
           if (nibble.quot < 10 )
           {
              high_nib = nibble.quot + 0x30;
           }
           else
           {
              high_nib = nibble.quot + 0x37;
           } /* endif */
           if (nibble.rem < 10 )
           {
              low_nib = nibble.rem + 0x30;
           }
           else
           {
              low_nib = nibble.rem + 0x37;
           } /* endif */
           fputc(high_nib, fpo);
           fputc(low_nib, fpo);
           byte_count++;
           if (byte_count % 32 == 0)
           {
              fputc(0x0d,fpo);
              fputc(0x0a,fpo);
           }
           else
           {
           } /* endif */
        } /* endwhile */

        fclose(fpi);
        fclose(fpo);
}

One other problem you may encounter is if your 71B has had extra 32K memory modules installed inside, they will most likely be found and configured ahead of the 32K FRAM71 space you may wish to load the hard FORTH image to, so that FRAM71 "chip" will not be located at 0x30000. The 71B maps RAM into the address space with the largest chunks first and in the order that they are found, so memory that was installed internally will likely be attached to port 0 and will always be found ahead of memory in the card reader bay which is on port 5. Even before I received my first FRAM71 I had a requirement to know where specific memory modules got plugged into the memory map so I wrote this program that parses the OS's table where it keep track of this.

Code:

 10 REAL S1(15) @ S2=15 @ FOR S3=1 TO 15 @ S1(S3)=2^S2/4 @ S2=S2-1 @ NEXT S3 @ S1(15)=.5
15 DIM T$[255]
20 B1=HTD("2F9E6")
30 B2=B1 @ B3=B1+5 @ K$="FF"
35 DISP "System RAM"
40 GOSUB 300
50 DISP "Misc Memory"
60 B2=B1+5+L @ B3=B2+5 @ K$="EF"
70 GOSUB 300
100 END
300 DISP "Port Dev Seq Size Addr"
310 IF PEEK$(DTH$(B2),2)<>K$ THEN 500
320 L$="" @ L$=PEEK$(DTH$(B3-1),1)&PEEK$(DTH$(B3-2),1)&PEEK$(DTH$(B3-3),1) @ L=HTD(L$)
330 T$=PEEK$(DTH$(B3),L)
340 FOR X=1 TO L/10
350 Z=(X-1)*10 @ Z2=Z+1 @ S$=T$[Z2,Z2] @ Z2=Z2+1 @ D$=T$[Z2,Z2] @ Z2=Z2+1 @ P$=T$[Z2,Z2]
360 Z2=Z2+1 @ S=S1(HTD(T$[Z2,Z2]))*(HTD(T$[Z+9,Z+9])+1)
370 A$=T$[Z+7,Z+7]&T$[Z+6,Z+6]&T$[Z+5,Z+5]&"00"
380 DISP USING "AA,aaAA,aaaa,aaAA,2D,aa,AAAAA";" ",P$,D$,S$,S,"  ",A$
390 NEXT X
400 RETURN
499 END
500 DISP "Problem with memory config buffer"
510 END

Here is a sample of the output from the program for my 71B that has three 32K memory modules hard wired inside it. Misc memory will contain ROM and freed port memory. The memory modules found are listed in the order they are discovered so the addresses will seem to jump around you will note the three 32K modules on Port 0 have lower addresses than the one 32K "chip" found on port 5.

Code:

System RAM
Port Dev Seq Size Addr
  0   0   0    4  80000
  0   1   0    4  82000
  0   2   0   32  30000
  0   3   0   32  40000
  0   4   0    4  84000
  0   5   0    4  86000
  0   6   0   32  50000
  5   1   0   16  70000
  5   2   0   32  60000
  5   3   0   16  78000
Misc Memory
Port Dev Seq Size Addr
  0   8   0   16  90000
  4   0   0   32  98000
  5   0   0   16  A8000