Tektronix 4924 Tape Drive Emulator

[WaveyDipole]

I have started this thread at the request of a contributor (mmcgraw74) to my other thread regarding the AR488 GPIB interface. This would be a specific use case for a GPIB interface in device mode and would need to interpret the GPIB secondary address as commands being issued to the "tape drive" . Data sent to the "tape drive" would be stored on an SD Card.

mmcgraw74, provided a reference to a manual which contains detailed information on how the Tek 4050 communicates with the 4924 tape drive:

http://bitsavers.org/pdf/tektronix/405x/4924/070-2131-00_Tektronix_4924_Digital_Cartridge_Tape_Drive_Service_Manual_Feb1982.pdf

From this information is ought to be possible to re-construct the operation of the tape drive.

The thread here also discusses the project:

http://www.vcfed.org/forum/showthread.php?64018-Tektronix-405x-GPIB-Flash-Drive&p=582351#post582351

Since the tape drive is a device, the requirement for the emulator differ considerably from the requirements for the AR488 controller. Both needs to communicate over GPIB, but the emulator, being a device, does not require controller features nor the complete Prologix command set. Furthermore, data received from GPIB does not need to be sent/received over USB (virtual COM port) but sent to an SD Flash card. The emulator will require the means to accept secondary addresses as commands. These secondary addresses, when received, will need to be mapped to a specific emulator command handlers. As a device, there is no requirement to conform to the Prologix command syntax at all, although some means of setting at least a GPIB address would need to be provided.

Rather than adding to the AR488 code base, the sensible way to proceed seems to be to start a new project, stripped the AR488 code down the the functionality required for running in device mode and then build up the secondary address handling and SD Flash handling routines.

[artag]

I have an HP 9135A disc drive which might also be useful for testing.

[mmcgraw74]

WaveyDipole,

The 8-inch referred to 8-inch floppy drives in the Tektronix 4907

The tape drive is a Tektronix 4924 with a 3M DC300 tape.

I have configured my 4924 tape drive (and expect the tape emulator) to respond to GPIB address 5.

The 'parsing' of commands to the tape drive (and tape drive emulator) is just based on the MSA = My Secondary Address - with the primary address matching the GPIB address 5 for the emulator as a Talker or a Listener.

Here is a list of the MSA commands (My Secondary Address in Tektronix vocabulary = MSA) that I believe need to be supported by the emulator.

"Action" column indicates what the emulator needs to do.  Note than several commands map to the same action on the emulator (and tape drive).
I believe this is because the 4050 will be doing all the work and each GPIB byte transfer should be written or read from a file.

The Tek 4050 computers handled string and binary variables differently with headers generated by the 4050 for binary variables.  The tape drive just writes the bytes from the 4050 or reads the bytes and sends them to the 4050 for most of the BASIC commands.

I believe the list of commands (MSA) will offer complete compatibility between the 4050 and the 4924 tape drive:

Code: [Select]

/*
   Tektronix 4924 Tape Emulator device Commands
   
   Principle of operation:
   - Listen for 4924 GPIB primary address plus secondary address
   - Primary address (My Primary Address - MPA) indicates whether 4924 is talker or listener
   - Secondary address (My Secondary Address - MSA) = command
   
   Device MSA command numbers (assuming Emulator is GPIB device number 5)
   
   MPA MSA Action Data?  4050 BASIC statement
   
   37 12 Print Y       - PRINT  @5: <variable(s)>
   37 15 Print Y - WRITE  @5: <binary>
   37 1 Print Y - SAVE @5: <binary program in memory>
   37 27 Find Y - FIND   @5: <file#>
   37 28 Mark Y - MARK   @5: <# files,size in bytes>
   37 7 Kill Y - KILL   @5: <file#>
   37 29      Secret N - SECRET @5: <mark current file header with Secret flag>
   37 2 Close N - PRINT@5,2: <close current file>
   37 0 StatIN Y - PRINT@5,0: <w,x,y,z> send tape drive environment parameters
   37 9 CD Y - PRINT@5,9: <change directory to path$> **new cmd for EMULATOR**


   Device Talk commands (assuming Emulator is GPIB device number 5)

   69 13 Input Y       - INPUT  @5: <variable(s)>
   69 14 Input Y - READ   @5: <binary variable(s)>
   69 4 Input Y - OLD    @5: <binary program>
   69 0 StatOUT Y  - INPUT@5,0: <w,x,y,z> get tape drive environment parameters
   69   9       Header  Y - INPUT@5,9: <return current file header string>
   69 6 Type Y - TYPE   @5: <return type of next data in file>
   69 19 Tlist Y - TLIST  @5: <return header info for every file>
   69 30 Error Y - INPUT@5,30: <return error code and clear SRQ>
   
   
   
*/


[mmcgraw74]

WaveyDipole,

I have more info on how the Tektronix 4050 BASIC handles the tape header, binary header, etc in my Arduino file:

https://github.com/mmcgraw74/Tektronix-4050-GPIB-Flash-Drive/blob/master/Tek-GPIB-Tape-Emulator%20command%20template.ino

I believe once we get the secondary addresses for primary address 5, I can begin to write the code for each of the commands.

Monty

[mmcgraw74]

Bumping this thread.

Waveydipole - have you had a chance to work on this fork of your AR488 project?

[WaveyDipole]

Sorry, no. Illness, home projects over the summer and other factors have prevented me from doing so. I am, however, starting to get back to some of the Arduino work that has queued up. The job is bigger that I had imagined, but still very much on my to-do list.

[mmcgraw74]

Sorry, no. Illness, home projects over the summer and other factors have prevented me from doing so. I am, however, starting to get back to some of the Arduino work that has queued up. The job is bigger that I had imagined, but still very much on my to-do list.

No problem, COVID-19 has me working from home.

Just post here or PM me if there is anything I can do to help.

[mmcgraw74]

My last post was a bit vague - I don't have COVID-19, but the pandemic still has the company I work for having most of us still working from home.

[WaveyDipole]

Glad you don't have Covid. Keep safe!

I have, and am dealing with family matters which are taking up a lot of my time and I am sorry that this has sat on the shelf for so long. However, it has not been forgotten about.

I recently made a couple of updates to the base AR488 code and now that has been published, have been refreshing my mind as to the requirements for the project and setting up a test rig. I have also been trying to get to grips with the basics of working with an SD card reader.

As for the project, there appear to be several steps needed:

1) It seems that apart from enabling secondary GPIB addressing in the AR488 code, some means needs to be provided to test the functionality of the commands that you have listed. I have no vintage computing equipment that would generate such BASIC commands and send them to the storage emulator on the GPIB bus. I am therefore working on a controller command that would allow me to do something like:

++addr 2
++storage 27 5

which would be equivalent to

FIND @2,27: 5

All commands seem to have a similar format, so one ++ command should take care of it. The bottom line is that I need a means to send a secondary address and a parameter to the emulator device.

2) Once that is sorted and I have a way of sending the appropriate GPIB sequences to the emulator, it will then be necessary to build a mechanism to get the emulator to respond to and acknowledge such command sequences.

3) Functionality will need to be added to interface and work with the SD card reader. I imagine a command will need to be implemented to recognize, identify and format an SD card. Handlers will also need to be written to read/write content sent over GPIB to the SDcard rather than USB/Serial as at present.

4) The next step will be to flesh out the commands so that they can respond in an identical manner to the Tek storage device.

5) Since the SD Card system is FAT32, it will need to be agreed how to map files onto the FAT file system. Since there appear to be no file names involved, it is unclear to me at the moment how the system identifies specific files. There is also a mechanism for storing records, again unclear to me at present but all will need to be thought about.

I have started working on 1 which will then allow me to move to no. 2. When item 2 is ready, it should be possible to test in principle whether secondary addressing is working and responding as expected. Any adjustments that need to be made can then be made and then we can move to step 3 and 4. Both of these will require your input and views and you mentioned that you might be in a position to code much of this? In the meantime, could you fill me in a little on how the Tek storage deals with files and records? Do you have something in mind already as to how this might be implemented on the SD Card?

As I mentioned, a lot more work appears to be involved than imagined at first, but I still it possible to implement an emulator.

Regards.

[WaveyDipole]

I spent a couple of hours playing with the code and working on no. 1 this morning and ended up realising that my approach to sending secondary address commands is not going to work. The original idea was:

++addr 2
++storage 27 5

However, I observe from the Tek tape drive manual that sometimes the addresses are specified as between 1 - 30, but other times the 'talk' address is used which for secondary addresses ranges from 96 - 126. In the BASIC examples shown, the command (WBYTE, PRINT, INPUT etc) determines the direction of data flow expected by BASIC but of course its the secondary command byte that determines what the tape drive itself will do.

In the GPIB specification, a secondary address is a value between  96 - 126 (1-30 + hex 0x60) which explains why the Prologix implementation expects a value in the range 96 - 126. The primary address is added to hex 0x20 or 0x40 depending on whether the device is being addressed to listen or talk. I can therefore understand the BASIC commands expecting listen or talk address values for the primary address, but am puzzled by the inconsistent use of 1 - 30 and 96 - 126 for the secondary address. Of course, as far as the tape drive is concerned that is neither here nor there. It just expects a secondary address in the range 96 - 126, however where the range 1 - 20 is used, BASIC would need to convert the values.

From the Prologix point of view, which I have already (partially) implemented, the secondary address is specified using the ++addr command with secondary address values ranging from 96 - 126. I therefore expect the way this would work would therefore be something like:

++addr 2 96
++read

Or;

++addr 2 121
...data.....

The direction of data is determined by the command referenced in the secondary address byte value and what follows after the ++addr command must be consistent with that. I am revising my approach accordingly but am currently running into other difficulties. Will update as soon as I have something working.

[mmcgraw74]

Glad you don't have Covid. Keep safe!

@WaveyDipole,

Glad you don't have Covid either!

I shredded a ribbon cable to create a GPIB cable based on my ohmed out HP-IB connector in my HP 10269C GPIB Interface.



I still haven't gotten the HP Inverse Assembler working, but here is a trace of the "FIND @4:2" 4050 BASIC command to my 4924 external tape drive.



I have annotated the trace to show the Primary Address of 36 (decimal) which is GPIB Device 4 Primary Listen Address, Secondary Address of 123 (decimal) which is the 4050 BASIC "FIND" command, and the subsequent file# 2 then CR with EOI to end the command.

[mmcgraw74]

my GPIB cable photo didn't show up.

Here it is:

[mmcgraw74]

Here is the Tek 4924 Tape Drive Service Manual GPIB sequence table for the FIND command - matches my logic analyzer capture!

[mmcgraw74]

I see I left out the final two GPIB transactions of the 4050 controller:
UNTALK followed by UNLISTEN

[mmcgraw74]

updated screenshot

[WaveyDipole]

Thank you for the GPIB trace captures. I have copied them for reference. My apologies, but I had forgotten that the sequences were in the manual. I still have the link from a while ago. I made some progress with 1 today and hope to move on to 2 tomorrow if time allows.

[mmcgraw74]

I also posted the beginning of an Arduino program for the GPIB Flash Drive, with comments on how I expect the SD card files to work:
https://github.com/mmcgraw74/Tektronix-4050-GPIB-Flash-Drive/blob/master/Tek405xGPIBFlashDevice3.ino

Here are my comments in the INO file about storing the entire file header as the SD FAT filename:

Code: [Select]

Tek 4050 file header is always the first ASCII string in a separate 256 byte record and can be read and written without disturbing rest of the file
  - GPIB Flash drive will write the Header to the filename of the flash file with no file extension
  - Drive will return the actual FAT filesize appended to the header
  - Drive will return the header on the first INPUT @5 command after the file is opened

FILE HEADER FORMAT:
         1    1    2    2    3    3
1...5....0....5....0....5....0....5....
nnn    BINARY  .................Sxxxxxx
where nnnnn is left justified file number with spaces from 1 to 255 (fractions are rounded)
      BINARY, ASCII, NEW, or LAST as file type
      ...... File Usage: PROGRAM or DATA.  This can also be a general comment area
      S means SECRET
      xxxxxx MARKed filesize in bytes

Some Tektronix file header comment programs start the comment at location 9 in the header,
but comment characters 10-15 will be overwritten if the file is rewritten

FILE HEADER custom comment limitations:
- comment strings limited to 17 characters
- no numbers (error checking in 4050 header programs)
- no control characters (error checking in 4050 header programs)
- no SdFat reserved characters <>:"/\|?*  (what do I replace current / marker in headers that have namestrings?)
- Drive firmware will replace attempts to write reserved characters in header with '


I would label each file similar to the current header information shown with the BASIC TLIST command like this list of files from a tape below that had added File Descriptions to the header with a program:

Code: [Select]

*1-5 not recovered
 6      ASCII   PROG /PaperTape/   9     
 7      ASCII   PROG /A/D  Smpl/   40     
*8   not recovered
 9      ASCII   PROG /UNIVAC   /   6     
 10     ASCII   PROG /PDP      /   6     
 11     ASCII   PROG /ScopeUtil/   45     
 12     ASCII   PROG /Curr Loop/   6     
 13     ASCII   PROG /LORAN-C  /   8     
 14     ASCII   PROG /MINIBUG  /   10     
 15     ASCII   DATA / "" Data /   3     
 16     ASCII   PROG /QUANTEX  /   25     
 17     ASCII   PROG /GPIB GET /   6     
 18     ASCII   PROG /  "  "   /   15     
 19     ASCII   PROG /HP I/F   /   5     
 20     ASCII   TEXT /"   "    /   7     
 21     ASCII   PROG /HP Mod   /   4     
 22     ASCII   PROG /HP Menu  /   6     
 23     ASCII   PROG /"" Log-on/   3     
 24     ASCII   PROG /"" Term  /   3     
 25     ASCII   PROG /"" Store /   3     
 26     ASCII   PROG /"" Restor/   3     
 27     ASCII   PROG /"" Store /   3     
 28     ASCII   PROG /"" Restor/   3     
*29  not recovered
 30     ASCII   PROG /"" RestEd/   4     
 31     ASCII   PROG /""Frmt Ct/   3     
*32  not recovered
 33     ASCII   PROG /""ASR I/F/   3     
 34     ASCII   PROG /"" Instr /   39     
 35     ASCII   PROG /HP/Amdahl/   3     
 36     ASCII   PROG /"   "    /   10     
 37     ASCII   PROG /"   "    /   6     
 38     ASCII   PROG /"   "    /   6     
 39     ASCII   PROG /"   "    /   4     
 40     ASCII   DATA /"   "    /   6     
 41     ASCII   PROG / ARGUS   /   3     
 42     ASCII   PROG /   ""    /   6     
 43     ASCII   PROG /   ""    /   3     
 44     BINARY  DATA /   ""    /   29     
 45     ASCII   PROG /   ""    /   17     
 46     ASCII   PROG /   ""    /   10     
 47     ASCII   PROG /FFT Ops  /   3     
 48     ASCII   PROG / "   "   /   6     
 49     ASCII   PROG / "   "   /   10     
 50     ASCII   PROG / "   "   /   3     
 51     ASCII   DATA / "   "   /   3     
*52  not recovered
 53     ASCII   PROG /Spec Anal/   21     
*54  not recovered
 55     BINARY  DATA /"" Logo  /   3     
 56     ASCII   PROG /"" Delter/   3     
 57     ASCII   PROG /"" Main  /   41     
 58     ASCII   PROG /"" Smart /   32     
 59     ASCII   PROG /""Tutoril/   19     
 60     BINARY  DATA /""Tutoril/   28     
 61     BINARY  DATA /""Tutoril/   23     
 62     BINARY  DATA /""Tutoril/   14     
 63     BINARY  DATA /""Tutoril/   24     
 64     BINARY  DATA /""Tutoril/   14     
 65     ASCII   PROG /""THarDis/   14     
 66     ASCII   PROG /""TapeDup/   28     
 67     ASCII   DATA /""Strcase/   15     
 68     ASCII   DATA /""FM B'cs/   15     
 69     ASCII   DATA /"" Beslnl/   15     
 70     ASCII   DATA /"" PlsdRF/   17     
 71     ASCII   DATA /""UHF TV /   15     
 72     ASCII   DATA /""Sat.IF /   15     
 73     ASCII   DATA /""UW Oven/   16     
 74     ASCII   DATA /""IndCook/   14     
 75     ASCII   DATA /""IndCook/   15     
 76     ASCII   PROG /""Labeler/   8     
 77     LAST                      3       

Take file 6 as an example:

Code: [Select]

6      ASCII   PROG /PaperTape/   9
I would name this file on the SD Card as:

Code: [Select]

6 ASC PROG _PaperTape_

or
6 PROG _PaperTape_.ASC

or put the file number as the extension
AP_PaperTape_.6

In order to store more than one set of tape files on the SD Card, I would add a change directory command to the Tape Emulator, and put this command in a menu program.
Once the directory command had set the SD FAT directory, all the files on that 'tape' would be accessed by the tape FIND command.

[WaveyDipole]

Thank you for your thoughts on the file layout which are gratefully appreciated.

I have so far completed step 1, inasmuch as I can capture the secondary address in device mode so as to do  something with it. I am also making some progress with step 2 and have created a module with a prototype "storage" class that will manage activities on the SDcard. However I have now run into some difficulty because as soon as I initialise the SD card reader, the interface hangs.

The SD card reader uses the SPI bus and the pins for this bus are presented on the centre 6-way connector which I am using to connect the SD card reader. However, I suspect the problem may being cased by the fact that the SPI bus signals are also mapped to various pins spread out around the Mega board. Unfortunately, each of my three existing GPIB bus layouts at least paritially overlaps with the SPI bus pins. This means that I will have to design another layout which avoids the pins related to the SPI bus. The easiest option may be to modify layout E1 or E2 to avoid the use of pins D50/52 or D51/53 and use D2/3 instead. I will have a crack at that over the weekend.

[mmcgraw74]

@WaveyDipole,

Yes, the Arduino pinout is an issue on an Arduino Nano.

The 4924 tape drive service manual pages 5-47 and 5-48 indicate REN signal is not supported, and the SRQ is only used to report tape errors.

Here is the pinout that allowed a Micro SD card to work for me on my Arduino Nano with the SD Flash library:

 *********************
 CONNECT Arduino pin 10 (SS) to MicroSD chip select (CS).  SdFat will init this pin
 *********************
 GPIB pins 10, 17-24 goto GND
 GPIB pin 17 (REN) No connect. (not used by 4924 tape)
 GPIB pin 10 (SRQ) No connect. (not used by 4924 tape)
 GPIB pin 12  GND  Shield
 */
#define DIO1  A0  /* GPIB 1  : I/O data bit 1     - Arduino PORTC bit 0 */
#define DIO2  A1  /* GPIB 2  : I/O data bit 2     - Arduino PORTC bit 1 */
#define DIO3  A2  /* GPIB 3  : I/O data bit 3     - Arduino PORTC bit 2 */
#define DIO4  A3  /* GPIB 4  : I/O data bit 4     - Arduino PORTC bit 3 */
#define DIO5  A4  /* GPIB 13 : I/O data bit 5     - Arduino PORTC bit 4 */
#define DIO6  A5  /* GPIB 14 : I/O data bit 6     - Arduino PORTC bit 5 */
#define DIO7  4   /* GPIB 15 : I/O data bit 7     - Arduino PORTD bit 4 */
#define DIO8  5   /* GPIB 16 : I/O data bit 8     - Arduino PORTD bit 5 */
#define EOI   A6  /* GPIB 5  : End Or Identify    - Arduino PORTC bit 6 -  CHANGE from 12 to A6 to make room for SPI Flash */
#define DAV   3   /* GPIB 6  : Data Valid         - Arduino PORTD bit 3 -  CHANGE from 11 to 3  to make room for SPI Flash */
#define NRFD  2   /* GPIB 7  : Not Ready For Data - Arduino PORTD bit 2 -  CHANGE from 10 to 2  to make room for SPI Flash */
#define NDAC  9   /* GPIB 8  : Not Data Accepted  - Arduino PORTB bit 0 */
#define IFC   8   /* GPIB 9  : Interface Clear    - Arduino PORTB bit 1 */
#define ATN   7   /* GPIB 11 : Attention          - Arduino PORTD bit 7 */

/* Now 10,11,12,13 will be used for MicroSD Flash card.  11,12,13 will be picked up on ICSP connector, 10 wired separately
ICSP Pins:        MicroSD Pins:
  1 = MISO (12)   DO
  2 = +5V         +5V
  3 = SCK  (13)   CLK
  4 = MOSI (11)   DI
  5 = NC
  6 = GND         GND
Nano 10 is SS     CS

But I was stumped trying to map the remaining signals to your AR488 code.

[WaveyDipole]

Thank you for the information. Interesting to note that REN is not supported and therefore not required. REN is used by the controller to remote control a device and devices will support REN if they can be remote controlled. Evidently this is not the case with the 4924. Control in this case is via secondary addressing so that makes sense.

SRQ is used by devices to indicate to the controller that the device is ready to send a response or to indicate an error condition. Since this feature is also not supported by the 4920, the GPIO pin requirement is reduced by two pins. The SPI bus requires 4 pins so the total requirement is 4 + 14 + 1 = 21 pins. That is useful to note.

I now have two layouts for the Mega that avoid the ICSP pins (MISO, MOSI, CLK, SS) and the SD device can now be loaded without things grinding to a halt.

Since I am in "layout mode" I will also have a closer look at your Nano layout and work on creating a suitable layout definition for the Nano/Uno. The only thing that still concerns me is the rather small amount of available runtime memory on the 328p MCU. There is some scope for optimisation, but we have not even begun creating the storage functions yet. Program memory should not be an issue.

[WaveyDipole]

Having had a look at your layout I note that it uses pin A6. Pins A6 and A7 are not available on the Uno due to the DIL package that was used. It is available on the Nano and clone boards that use the square TQFP-32 package as it has the additional pins. They don't have the circuitry to be used as outputs and the drawback is that they can only be used as an analog inputs.

Since EOI is a bi-directional function, mapping it to A6 might be a problem. However, I do have an idea. IFC is used by the controller to signal "I am in charge" to devices on the GPIB bus. AFAIK, it is not used by devices except to listen, so it could be mapped to pin A6. On the other hand, my code does not support listening to IFC in device mode at this time. I am not sure what it does exactly except perhaps to signal any other controller present to stand down, so perhaps it could be ignored. I propose to set up the layout as follows:

#define DIO1  A0  /* GPIB 1  : PORTC bit 0 */
#define DIO2  A1  /* GPIB 2  : PORTC bit 1 */
#define DIO3  A2  /* GPIB 3  : PORTC bit 2 */
#define DIO4  A3  /* GPIB 4  : PORTC bit 3 */
#define DIO5  A4  /* GPIB 13 : PORTC bit 4 */
#define DIO6  A5  /* GPIB 14 : PORTC bit 5 */

#define DIO7   8  /* GPIB 15 : PORTD bit 0 */
#define DIO8   9  /* GPIB 16 : PORTD bit 1 */

#define EOI    7  /* GPIB 5  : PORTD bit 7 */
#define DAV    6  /* GPIB 6  : PORTD bit 6 */
#define NRFD   5  /* GPIB 7  : PORTD bit 5 */
#define NDAC   4  /* GPIB 8  : PORTD bit 4 */
#define ATN    2  /* GPIB 11 : PORTD bit 2 */

That way everything is in the same order as on the GPIB connector. I have intentionally left pin 3 available because (a) it could be used for something where an interrupt is required and (b) it could still be used to support SRQ if a device requires it.

If you have already wired up hardware with the layout you indicated, then I can program that one as well but move EOI to pin D6.

What do you think?

[mmcgraw74]

I have been looking at your pinout proposal and have added the pins for SD Card and both IFC and SRQ:

#define DIO1  A0  /* GPIB 1  : PORTC bit 0 */
#define DIO2  A1  /* GPIB 2  : PORTC bit 1 */
#define DIO3  A2  /* GPIB 3  : PORTC bit 2 */
#define DIO4  A3  /* GPIB 4  : PORTC bit 3 */
#define DIO5  A4  /* GPIB 13 : PORTC bit 4 */
#define DIO6  A5  /* GPIB 14 : PORTC bit 5 */

#define DIO7   8  /* GPIB 15 : PORTD bit 0      D0  = RS232 - RX */
#define DIO8   9  /* GPIB 16 : PORTD bit 1      D1  = RS232 - TX */

#define EOI    7  /* GPIB 5  : PORTD bit 7 */
#define DAV    6  /* GPIB 6  : PORTD bit 6 */
#define NRFD   5  /* GPIB 7  : PORTD bit 5 */
#define NDAC   4  /* GPIB 8  : PORTD bit 4 */
#define ATN    2  /* GPIB 11 : PORTD bit 2 */

/*  for SD card we have these pins?            */
/*              SPI - MISO : PORTD bit 12 ?? */
/*              SPI - CLK  : PORTD bit 13 ?? */
/*              SPI - MOSI : PORTD bit 11 ?? */
/*              SD Card CS : PORTD bit 10 ?? */

#define IFC    8  /* GPIB 9  : PORTD bit 8 ??  */
#define SRQ    9  /* GPIB 10 : PORTD bit 9 ??  */


Your pinout uses D0 and D1 which are also the RS232 TX/RX.  I guess this is not an issue as the Tape Emulator will not be using serial for commands to the Nano.  It does make debug a little more challenging

I think this allows the IFC and SRQ to be added on D8 and D9?

My Nano can be rewired to match this layout, as my connections are just soldered to the GPIB cable wires.

[mmcgraw74]

Even pin D3 on the Nano is available - could be the GPIB REN signal?

[WaveyDipole]

#define DIO7   8  /* GPIB 15 : PORTD bit 0      D0  = RS232 - RX */
#define DIO8   9  /* GPIB 16 : PORTD bit 1      D1  = RS232 - TX */

My apologies but the above from my earlier post contains an error. Should be:

#define DIO7   8  /* GPIB 15 : PORTB bit 0
#define DIO8   9  /* GPIB 16 : PORTB bit 1

The pin numbers (8+9) are correct, but they exist on PORTB rather than PORTD. You are quite correct that PORTD bit 0 and 1 which correspond to pins D0 + D1 are serial Tx/Rx and it was not my intention to use those pins. The serial port is required for programming (firmware upload) as well as configuration (setting the GPIB address etc). It is possible to do the former via an AVR programmer, but not the latter so the serial port does need to remain available. I was also thinking to adding some storage management functions via a ++ commands. I had envisaged something like:

++storage fmt
Format the SD card

++storage info
Display the card type, capacity, format

++storage list
List the files on the card

++storage tape new "My tape 01"
Creates a tape called "My tape 01"

++storage tape load "My tape 01"
Loads a "tape" named "My tape 01" making it available for reading/writing. All subsequent read/write operations are performed on this "tape".

++storage tape uload "My tape 01"
Unloads a "tape" named "My tape 01" taking it offline

++storage tape list
Lists the available "tapes" on the storage medium.

I am not sure whether and how much of this will be necessary or what the final form will take, but just imagining for now what might be required.

/*  for SD card we have these pins?            */
/*              SPI - MISO : PORTD bit 12 ?? */
/*              SPI - CLK  : PORTD bit 13 ?? */
/*              SPI - MOSI : PORTD bit 11 ?? */
/*              SD Card CS : PORTD bit 10 ?? */

Yes, exactly. I suppose that either pins 10-13 or the centre 6-pin connector + pin 10 could be used to hook up the SDcard device.

[mmcgraw74]

I believe getting the two extra pins from RX/TX would be worth it - particularly to stay aligned with your GPIB code and pin usage.

I could move to a different Arduino board, like the Mega2560 but it is a lot more expensive and very large by comparison.

I found a Pololu A-Star 328PB Micro that has the ATmega328PB CPU which is backwards compatible with the 328P on the Arduino UNO and adds digital IO to the A6 and A7 pins of the Nano for a total of 24 digital IO pins!.

It is attractively priced at $4.95 and is only 1.3" x 0.7".

Pololu recommends using their USB AVR Programmer which includes a second serial interface for $7.77, and can directly provide serial and power to the A-Star 328PB Micro.

The A-Star 328PB Micro does not have a USB connector - and expects an external USB to TTL Serial converter connected to header pins at one end of the board for programming - and this serial converter would also provide +5V and Ground to the board. 

This would be ok for my application as I don't expect to use the USB or serial interface, but would get +5V power for the Arduino from the Tektronix computer.

I also expect to have to design a small PCB shield which would provide the GPIB connector and microSD connector to the Arduino.