[71B, FRAM71] Using a USB GPIB interface to load files on a 71B

[cruff]

I wrote a perl script, copyil.pl, and a companion 71B BASIC program, COPYIL, to copy files from a Linux/Unix/OS X box to the 71B using a Prologix GPIB-USB controller (FW version 6.101) and the 82169A HP-IL/HP-IB Interface. With a bit of change this should work with the Prologix GPIB-Ethernet or, with possibly even more changes, other vendor's GPIB interfaces. This should also be usable on Windows with some suitable binmode settings made in the perl script.

The configuration that I've tested with is MacBook Pro <-> GPIB-USB (address 2) <-> 82169A (transparent mode, address 1 assigned by the 71B) <-> 71B (HP-IL controller).

You can point copyil.pl at multiple LIF files or directories to download several during one session. Any directory with a name of :main or :port(d) (case insensitive) will be used to set the destination device name for the files contained within. By default, the target device name is :MAIN.

Code:

copyil.pl [-bdr] [-h hexaddr] [-p port] pathname [...]

       -b         => TRANSFORM TEXT INTO BASIC after copy
       -d         => Turn on debug output
       -r         => Send using "raw mode" (no handshaking)
       -h hexaddr => Convert a binary file to hex encoded
       -p port    => Set the port name

To bootstrap COPYIL into 71B, you first run copyil.pl -r copyil.b71 on the host, then issue COPY :2 on the 71B.

It can also be used to upload binary image files, such as for ROMs, if you run copyil.pl -h <hex address> binary-image-file. COPYIL does this by POKEing the hex data received from the host. Note to those uploading images, be sure to target a FRAM area that has been configured in the middle of system RAM, so as to avoid either clobbering COPYIL at the low end of memory and the stacks and buffers at the high end of memory. You are responsible for determining the correct address, CONFST, below may be useful.

There is rudimentary handshaking and some error detection. Always start copyil.pl first, then run COPYIL on the 71B.

  copyil.zip (Size: 5.09 KB / Downloads: 4)

I also wrote a program, CONFST (named after the symbolic address of the OS tables), inspired by Paul's MEMBUF, that displays the configured devices and memory type as a string (SRAM, IRAM, ROM, IO) . RAM and ROM sizes are reported in KB, IO registers in nibbles.

Code:

Pt Dv Size Addr  Type
 0  0   4K 40000 SRAM  
 0  1   4K 42000 SRAM  
 0  2   4K 44000 SRAM  
 0  3   4K 46000 SRAM  
 5  3  32K 30000 SRAM  
 0  5  16K 50000 ROM   
 4  0  16K 58000 ROM   
 5  0  32K D0000 ROM   
 5  1  32K C0000 ROM   
 5  2  32K B0000 IRAM  
 0  4  16N 20000 I/O:0

  confst.zip (Size: 2.09 KB / Downloads: 3)

[Dave Frederickson]

(05-16-2015 11:09 PM)cruff Wrote:  Note to those uploading images, be sure to target a FRAM area that has been configured in the middle of system RAM, so as to avoid either clobbering COPYIL at the low end of memory and the stacks and buffers at the high end of memory.

When copying ROM images into FRAM71, the preferred technique is to FREEPORT a module, determine it's address using MEMBUF, then POKE the ROM data into the IRAM. This avoids clobbering main memory. Finally, the IRAM is reconfigured to ROM.

Note that the easiest way to load ROM images is from an HP-IL mass storage device, like ILPer, using ROMCOPY. HC ROM's, however, will still need to be POKE'd.

Dave

[cruff]

(05-16-2015 11:51 PM)Dave Frederickson Wrote:  When copying ROM images into FRAM71, the technique is to FREEPORT a module, determine it's address using MEMBUF, then POKE the ROM data into the IRAM. This avoids clobbering main memory. Finally, the IRAM is reconfigured to ROM.

I tried that, but for some reason didn't get it to work correctly. However I was also in the middle of development of the utility, so could have had some other problem. :-(

[Dave Frederickson]

(05-17-2015 12:15 AM)cruff Wrote:  

(05-16-2015 11:51 PM)Dave Frederickson Wrote:  When copying ROM images into FRAM71, the technique is to FREEPORT a module, determine it's address using MEMBUF, then POKE the ROM data into the IRAM. This avoids clobbering main memory. Finally, the IRAM is reconfigured to ROM.

I tried that, but for some reason didn't get it to work correctly. However I was also in the middle of development of the utility, so could have had some other problem. :-(

One thing I've learned about FRAM71 is that many times it takes several attempts before succeeding. I'm still working on bank-switching two HC ROM's on-the-fly, to duplicate Hans' feat.

Dave

[Dave Frederickson]

(05-16-2015 11:09 PM)cruff Wrote:  I also wrote a program, CONFST (named after the symbolic address of the OS tables), inspired by Paul's MEMBUF, that displays the configured devices and memory type as a string (SRAM, IRAM, ROM, IO) . RAM and ROM sizes are reported in KB, IO registers in nibbles.

The evolution of this program would be a LEX file. Time to brush up on your assembly skills. Here's a start: SHWPORTS

Of course we could add some new keywords for working with FRAM71, like:

• FCW - FRAM Config Write: Performs POKE"2C000","Config String"
• FCR$ - FRAM Config Read: Performs PEEK$("2C000",32)
• Perhaps some functions for POKEing ROM images into memory

Suggestions?

Dave

[cruff]

(05-22-2015 09:23 PM)Dave Frederickson Wrote:  Of course we could add some new keywords for working with FRAM71, like:

• FCW - FRAM Config Write: Performs POKE"2C000","Config String"
• FCR$ - FRAM Config Read: Performs PEEK$("2C000",32)
• Perhaps some functions for POKEing ROM images into memory

Suggestions?

It seems to me that a function to swap F-blocks without having to enter a 32 nibble string would be useful. Possibly support for something like the 41CL's module catalog for selecting entry by name, or it might even be possible to just scan the F-blocks for the appropriate LEX/ROM name and not need to store a catalog.

It also sounds like an F-block catalog function could be useful.

Also a function to zero out F-blocks so you don't need to move a jumper to accomplish it, with a suitable password or prompted Y/N to prevent accidental overwrites.

Maybe an F-block copy function.

I've wanted to write some Saturn assembly for fun, I'll have to start re-reading the IDS documentation again.