[FRAM71] Pre-Production Batch

[Michael Lopez]

Hi Dave,

Thanks very much for the excellent links & information :-).

As I understand from previous information I have read, if the FORTH module is installed the HP41 Translator module may cause some conflicts due to it containing a sub-set of FORTH hence not advisable, If anyone has tried this it would be good to hear about your experience.

Thanks,

Michael

[Didier Lachieze]

The Forth/Assembler module and the HP 41 Translator PAC are mutually exclusive: you cannot have both installed at the same time as both require the usage of the hard-configured ROM at E0000.

[cruff]

(04-24-2015 01:58 AM)Dave Frederickson Wrote:  Did you go for the deluxe 1Mb model or the standard 512k?

I just went with the standard size. I didn't feel like opening it up to switch a jumper to select the alternate bank. Lazy, I know. :-)

[Michael Lopez]

Thanks Didier for confirming the potential issue.

Cheers,

Michael

[Dave Frederickson]

(04-24-2015 12:53 PM)cruff Wrote:  

(04-24-2015 01:58 AM)Dave Frederickson Wrote:  Did you go for the deluxe 1Mb model or the standard 512k?

I just went with the standard size. I didn't feel like opening it up to switch a jumper to select the alternate bank.

In exploring the different features of the module I got used to moving jumpers. Also, a future firmware update will remove the need to move a jumper to switch FRAM's.

[cruff]

Plugged it into my 2CDCC version 71B, configured it to maximum memory with the HP-IL module installed, snapped a picture. :-)

Thanks, Hans!

[Dave Frederickson]

(04-25-2015 07:03 PM)cruff Wrote:  Plugged it into my 2CDCC version 71B, configured it to maximum memory with the HP-IL module installed, snapped a picture. :-)

You should be able to do better than 360k. Per the example on p.14 of the User's Manual.

Code:

>POKE"2C000","131415161718191A1B9C9DAE00000000"
>
>MEM
 393637 
>SHOWPORT
0.05  16384  2
0      4096  0
0.01   4096  0
0.02   4096  0
0.03   4096  0
5    327680  0
5.01  32768  0
5.02  16384  0

The max RAM memory is:
512k: Total address space
- 64k: System ROM
- 32k: C0000 block is unusable as RAM
- 32k: Used by the HP-IL module per EduCALC Tech Note #4
= 384k address space available for RAM

Dave

[Michael Lopez]

Hi cruff,

When I first configured my FRAM71 V501 earlier this week I ended-up with a similar reported RAM value to yours. The reason for this apparent shortfall was kindly explained to me by Hans as being due to the limitation that V501 has over V430 due to Chip_0 not being configured correctly (see http://www.hpmuseum.org/forum/thread-251...l#pid33458 ) via the example configuration at the bottom of Page 14 in the manual.

Hans suggested the following configuration scrip instead for V501: POKE”2C000”, “9314 1516 1718 191A 1B9C 9DAE 0000 0000” . After applying this configuration & re-starting my 1BBB 71B I ended-up with a reported RAM of 393741 bytes, i.e., close to the expected 384 kB.

Hope this helps.

Cheers,

Michael

[cruff]

(04-26-2015 01:44 AM)Michael Lopez Wrote:  Hans suggested the following configuration scrip instead for V501: POKE”2C000”, “9314 1516 1718 191A 1B9C 9DAE 0000 0000” . After applying this configuration & re-starting my 1BBB 71B I ended-up with a reported RAM of 393741 bytes, i.e., close to the expected 384 kB.

Thanks, I haven't had time to test an alternate configuration yet, but was considering doing just what you suggest. When I get back home I plan on using this rainy day to learn more about using the FRAM71.

[Hans Brueggemann]

FRAM71 is currently supporting three different RAM/ROM sizes, being 32 KB, 16 KB and 8 KB. I wonder as to whether the 8 KB option is used at all by any of the FRAM71 users out there...
what is your opinion about having the 8 KB option available on FRAM71?
is it of any use at all, or is it safe to scrap the 8 KB option in favor of other things yet to come?


hans
as a side note: ultimate thanks to Sylvain and Bob for the image collection! i was able to proof that, at least in FRAM71, FORTH and 41FTH peacefully coexist and may be easily brought to surface by just swapping F_Blocks in the configuration area.
Also, V502 is almost ready and will iron out the Chip_0 bug which is present in V501. (the Chip_0 bug is _not_ present in V43x)

[Dave Frederickson]

(04-29-2015 03:46 PM)Hans Brueggemann Wrote:  is it of any use at all, or is it safe to scrap the 8 KB option in favor of other things yet to come?

I vote to scrap it. Even in trying to eek out the max memory from FRAM71 an 8k block added nothing.

Dave

[rprosperi]

(04-29-2015 03:46 PM)Hans Brueggemann Wrote:  ...I wonder as to whether the 8 KB option is used at all by any of the FRAM71 users out there...
what is your opinion about having the 8 KB option available on FRAM71?
is it of any use at all, or is it safe to scrap the 8 KB option in favor of other things yet to come?

I agree with your suggestion and Dave, scrap it! With all the ram made available by FRAM71, I can see no justification to have an 8KB block; the "extra bit" can certainly be used more effectively with some future features or capabilities.

After all, if you really need 8KB, just use 16KB, and consider the extra 8KB "room for growth".

[Paul Berger (Canada)]

(04-29-2015 03:46 PM)Hans Brueggemann Wrote:  KB. I wonder as to whether the 8 KB option is used at all by any of the FRAM71 users out

I would agree there does not seem to be much point keeping 8K it would seem all the ROMs know at this point are multiples of 16K, the base system memory is 16K and configurable space begins on a even 64K nibble boundary, so I would not think 8K size is even relevant.

Note the specs for the 71B says the base memory is 17.5K but 1.5K of that is the display buffers and they are hard configured below the 0x30000 starting point for configurable memory.

[Dave Frederickson]

I just noticed that the flashing instructions are missing from the attachment in Post #1.

Here're the instructions from V421: !_FRAM71_FW-FLASH_README

Dave

[Sylvain Cote]

I have received my first FRAM71-1MB last week and I am starting to to play with it.

First session: deactivate all memory

Code:

BLOCK:               00112233445566778899AABBCCDDEEFF
POKE  "2C000",      "00000000000000000000000000000000"
PEEK$("2C000",32) ->"00000000000000001000101010101010" (where are those 1's coming from ?)
OFF/ON
PEEK$("2C000",32) ->"00000000000000001000101010101010" (still there ???)
MEM -> 16828 (memory size ok)
mmmm, trying another strategy to set the last 16 nibbles
POKE  "2C010",      "0000000000000000"
PEEK$("2C010",16) ->"1000101010101010" (nop! not working, very strange)

Second session: add 80KB of memory

Code:

BLOCK:               00112233445566778899AABBCCDDEEFF
POKE  "2C000",      "9394A500000000000000000000000000"
PEEK$("2C000",32) ->"9394A500000000001000101010101010" (again those 1's)
OFF/ON
PEEK$("2C000",32) ->"9394A500000000001000101010101010" (at least, it's consistent and does not appears to have side effects)
MEM -> 98768 (memory size ok, 16KB+80KB)

Third session: add 160KB of memory trying another strategy to set the last 16 nibbles

Code:

BLOCK:               00112233445566778899AABBCCDDEEFF
POKE  "2C000",      "A3A4A5A6A7A8A9AAABAC000000000000"
PEEK$("2C000",32) ->"A3A4A5A6A7A8A9AAABAC000000000000" (the 1's has disappears)
OFF/ON
PEEK$("2C000",32) ->"A3A4A5A6A7A8A9AAABAC000000000000"
MEM -> 180593 (memory size ok, 16KB + 160KB)

Fourth session: add 80KB of memory (same as second session and the 1's has also returned, very strange ...)

Code:

BLOCK:               00112233445566778899AABBCCDDEEFF
POKE  "2C000",      "9394A500000000000000000000000000"
PEEK$("2C000",32) ->"9394A500000000001000101010101010" (again those 1's)
OFF/ON
PEEK$("2C000",32) ->"9394A500000000001000101010101010" (yep! confirmed, still there)
MEM -> 98674 (memory size ok, 16KB+80KB)

Next time I will explore the FRAM71 behaviour with the FREE/CLAIM PORT.

Sylvain

[Dave Frederickson]

(05-03-2015 02:13 AM)Sylvain Cote Wrote:  where are those 1's coming from ?

Per section 11 of the User's Manual, the UART is enabled when there are less than 8 Chips enabled. Those are the UART Control Registers.

Dave

[Sylvain Cote]

(05-03-2015 03:24 AM)Dave Frederickson Wrote:  

(05-03-2015 02:13 AM)Sylvain Cote Wrote:  where are those 1's coming from ?

Per section 11 of the User's Manual, the UART is enabled when there are less than 8 Chips enabled. Those are the UART Control Registers.

Dave

OK, another case of not RTFM. 8-(
I skipped that section thinking that I did not needed for now, well, I was wrong.
I saw that it was not affecting the FRAM71 behaviour but I was curious on why those bits where set most of the time.
Now I known, thank you Dave.
Sylvain

[Marcus von Cube]

(04-24-2015 08:46 AM)Marcus von Cube Wrote:  I plan to pick up mine directly from Hans. If I'm not mistaken we live close to each other. (I'm not a home at the moment so the transaction has to wait until early May.)

Better yet.

Hans delivered the module directly to my home today, and helped me to configure and install it properly. My PILbox is up and running, waiting to restore some interesting stuff to to the module such as the MATHROM LEX file.

BTW, his kind offer to bring the FRAM71 was honored with a gift from one of my many shelves.

It was fun to meet you, Hans!

[Dave Frederickson]

(05-03-2015 03:27 PM)Marcus von Cube Wrote:  Hans delivered the module directly to my home today, and helped me to configure and install it properly.

Very cool. Welcome to the FRAM71 community. I look forward to your contributions.

Dave

[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