Tektronix 4924 Tape Drive Emulator - Page 1
Forum section: electronics / projects

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 01, 2020, 01:53:06 pm
content: 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.pdfFrom 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#post582351Since 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.

author: artag
author_rank: Super Contributor
timestamp: August 01, 2020, 06:12:57 pm
content: I have an HP 9135A disc drive which might also be useful for testing.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 01, 2020, 07:58:49 pm
content: WaveyDipole,The 8-inch referred to 8-inch floppy drives in the Tektronix 4907The tape drive is a Tektronix 4924 with a 3M DC300 tape.I have configured my 4924 tape drive (and expect thetape emulator) to respond toGPIB address 5.The 'parsing' of commands to the tape drive (and tape drive emulator) is just based on theMSA = 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:/*Tektronix 4924 Tape Emulator device CommandsPrinciple 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) = commandDevice MSA command numbers (assuming Emulator is GPIB device number 5)MPAMSAAction Data? 4050 BASIC statement3712PrintY - PRINT @5: <variable(s)>3715PrintY- WRITE @5: <binary>371PrintY- SAVE@5: <binary program in memory>3727FindY- FIND @5: <file#>3728MarkY- MARK @5: <# files,size in bytes>377KillY- KILL @5: <file#>3729 SecretN- SECRET @5: <mark current file header with Secret flag>372CloseN- PRINT@5,2: <close current file>370StatINY- PRINT@5,0: <w,x,y,z> send tape drive environment parameters379CDY- PRINT@5,9: <change directory to path$> **new cmd for EMULATOR**Device Talk commands (assuming Emulator is GPIB device number 5)6913InputY - INPUT @5: <variable(s)>6914InputY- READ @5: <binary variable(s)>694InputY- OLD @5: <binary program>690StatOUT Y- INPUT@5,0: <w,x,y,z> get tape drive environment parameters69 9 Header Y- INPUT@5,9: <return current file header string>696TypeY- TYPE @5: <return type of next data in file>6919TlistY- TLIST @5: <return header info for every file>6930ErrorY- INPUT@5,30: <return error code and clear SRQ>*/

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 01, 2020, 08:08:10 pm
content: 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.inoI believe once we get the secondary addresses for primary address 5, I can begin to write the code for each of the commands.Monty

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 07, 2020, 02:28:46 pm
content: Bumping this thread.Waveydipole - have you had a chance to work on this fork of your AR488 project?

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 26, 2020, 10:32:58 am
content: 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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 26, 2020, 01:29:05 pm
content: Quote from: WaveyDipole on September 26, 2020, 10:32:58 amNo problem, COVID-19 has me working from home.Just post here or PM me if there is anything I can do to help.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: October 04, 2020, 11:53:12 am
content: 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.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 18, 2021, 09:38:01 pm
content: 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 5which would be equivalent toFIND @2,27: 5All 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.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 19, 2021, 02:39:09 pm
content: 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 5However, 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++readOr;++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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 19, 2021, 04:47:28 pm
content: Quote from: WaveyDipole on January 18, 2021, 09:38:01 pm@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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 19, 2021, 04:48:55 pm
content: my GPIB cable photo didn't show up.Here it is:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 19, 2021, 04:54:28 pm
content: Here is the Tek 4924 Tape Drive Service Manual GPIB sequence table for the FIND command - matches my logic analyzer capture!

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 19, 2021, 05:04:27 pm
content: I see I left out the final two GPIB transactions of the 4050 controller:UNTALK followed by UNLISTEN

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 19, 2021, 05:06:50 pm
content: updated screenshot

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 19, 2021, 07:59:46 pm
content: 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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 19, 2021, 10:19:35 pm
content: 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.inoHere are my comments in the INO file about storing the entire file header as the SD FAT filename:Code: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 openedFILE HEADER FORMAT:1 1 2 2 3 31...5....0....5....0....5....0....5....nnn BINARY .................Sxxxxxxwhere 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 areaS means SECRETxxxxxx MARKed filesize in bytesSome 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 rewrittenFILE 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:*1-5 not recovered6 ASCII PROG /PaperTape/ 97 ASCII PROG /A/D Smpl/ 40*8 not recovered9 ASCII PROG /UNIVAC / 610 ASCII PROG /PDP / 611 ASCII PROG /ScopeUtil/ 4512 ASCII PROG /Curr Loop/ 613 ASCII PROG /LORAN-C / 814 ASCII PROG /MINIBUG / 1015 ASCII DATA / "" Data / 316 ASCII PROG /QUANTEX / 2517 ASCII PROG /GPIB GET / 618 ASCII PROG / " " / 1519 ASCII PROG /HP I/F / 520 ASCII TEXT /" " / 721 ASCII PROG /HP Mod / 422 ASCII PROG /HP Menu / 623 ASCII PROG /"" Log-on/ 324 ASCII PROG /"" Term / 325 ASCII PROG /"" Store / 326 ASCII PROG /"" Restor/ 327 ASCII PROG /"" Store / 328 ASCII PROG /"" Restor/ 3*29 not recovered30 ASCII PROG /"" RestEd/ 431 ASCII PROG /""Frmt Ct/ 3*32 not recovered33 ASCII PROG /""ASR I/F/ 334 ASCII PROG /"" Instr / 3935 ASCII PROG /HP/Amdahl/ 336 ASCII PROG /" " / 1037 ASCII PROG /" " / 638 ASCII PROG /" " / 639 ASCII PROG /" " / 440 ASCII DATA /" " / 641 ASCII PROG / ARGUS / 342 ASCII PROG / "" / 643 ASCII PROG / "" / 344 BINARY DATA / "" / 2945 ASCII PROG / "" / 1746 ASCII PROG / "" / 1047 ASCII PROG /FFT Ops / 348 ASCII PROG / " " / 649 ASCII PROG / " " / 1050 ASCII PROG / " " / 351 ASCII DATA / " " / 3*52 not recovered53 ASCII PROG /Spec Anal/ 21*54 not recovered55 BINARY DATA /"" Logo / 356 ASCII PROG /"" Delter/ 357 ASCII PROG /"" Main / 4158 ASCII PROG /"" Smart / 3259 ASCII PROG /""Tutoril/ 1960 BINARY DATA /""Tutoril/ 2861 BINARY DATA /""Tutoril/ 2362 BINARY DATA /""Tutoril/ 1463 BINARY DATA /""Tutoril/ 2464 BINARY DATA /""Tutoril/ 1465 ASCII PROG /""THarDis/ 1466 ASCII PROG /""TapeDup/ 2867 ASCII DATA /""Strcase/ 1568 ASCII DATA /""FM B'cs/ 1569 ASCII DATA /"" Beslnl/ 1570 ASCII DATA /"" PlsdRF/ 1771 ASCII DATA /""UHF TV / 1572 ASCII DATA /""Sat.IF / 1573 ASCII DATA /""UW Oven/ 1674 ASCII DATA /""IndCook/ 1475 ASCII DATA /""IndCook/ 1576 ASCII PROG /""Labeler/ 877 LAST 3Take file 6 as an example:Code:6 ASCII PROG /PaperTape/ 9I would name this file on the SD Card as:Code:6 ASC PROG _PaperTape_or6 PROG _PaperTape_.ASCor put the file number as the extensionAP_PaperTape_.6In 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.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 22, 2021, 06:18:06 pm
content: 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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 22, 2021, 06:44:59 pm
content: @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 GNDGPIB 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 separatelyICSP Pins: MicroSD Pins:1 = MISO (12) DO2 = +5V +5V3 = SCK (13) CLK4 = MOSI (11) DI5 = NC6 = GND GNDNano 10 is SS CSBut I was stumped trying to map the remaining signals to your AR488 code.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 26, 2021, 11:52:19 am
content: 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.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 26, 2021, 01:23:26 pm
content: 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?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 27, 2021, 02:27:33 pm
content: 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 0D0 = RS232 - RX */#define DIO8 9 /* GPIB 16 : PORTD bit 1D1 = 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 challengingI 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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 27, 2021, 02:30:21 pm
content: Even pin D3 on the Nano is available - could be the GPIB REN signal?

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 28, 2021, 08:35:59 pm
content: QuoteMy 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 1The 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 fmtFormat the SD card++storage infoDisplay the card type, capacity, format++storage listList 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 listLists 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.QuoteYes, 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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 29, 2021, 10:07:35 pm
content: 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 aPololu A-Star 328PB Microthat has theATmega328PBCPU 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.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 30, 2021, 12:11:20 am
content: I just found a Nano V3 board with the ATmega328PB CPU and ordered it.From reading several internet posts - I may have to fiddle with the bootloader, but I expect I can get it to work with the Arduino IDE, and it should have the new E0 and E1 digital / analog ports on A6 and A7.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: January 30, 2021, 09:14:05 pm
content: That 328PB chip is interesting. If it has the capability to use A6 and A7 as digital pins then that might be useful. I couldn't find a Nano on eBay with a 328PB. Where did you find it? I did wonder whether one might be able to replace the chip, but by the time you add the cost of the chip and a Nano board you have reached the cost of a Pololu board so it is probably not worth the effort. I have also found the MCP23S17 chip which can expand the number of GPIO ports by 16 using the SPI interface so there is another way of adding GPIO pins to a Uno/Nano/32u4 or other small Arduino board.Regarding the serial port, the external TTL board still connects to the Rx/Tx pins on the processor. If those pins get used as GPIO pins, then it *might* still be possible to program the board using the reset button. As you have noted, this is, by all accounts, a bit of a fiddle as one has to get the timing right, but I have never tried that so cannot say whether it works or not. The Pololu board does have the six pin ICSP/SPI header which is where the AVR programmer will plug in. It does not use the Tx/Rx pins so that approach would free up those two pins and programming would be no problem.Incidentally, I have run into problems with the SD card reader again. It wouldn't initialise the card. I removed it and put it into the laptop and it couldn't mount the filesystem. I formatted the card in Windows with FAT32 but the Ardiono card reader still will not initialise it. I have ordered another reader and am waiting for it to arrive.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 30, 2021, 09:58:35 pm
content: Here is where I ordered the Nano board with the 328PB for $7.63 (since apparently the 328PB is a lot less expensive than the 328P):https://www.importedelectronics.com/products/arduino-nano-v3-0-pins-soldered-atmega328p-5v-ch340g-1-mini-usb-cable?_pos=3&_sid=5691ae0a5&_ss=rAccording to the Pololu pinout diagram -all 24of the328PBIO pins aredigital capable and provide interrupt capability, plus there are up totwo USART, SPI, and i2C interfaces:Of course the Pololu A-Star Micro 328PB pins are in a different order than the Nano - andthe Nano only provides 22 of the IO pins (no PE0 or PE1).Note the A6 and A7 pins are also definable as part of a SPI1 interface in addition to being digital pins with interrupt capability.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 03, 2021, 02:01:19 pm
content: I do hope you get a 328PB on there. The photo shows a 328P....Unfortunately I can't find a seller in the UK so might have to buy a Pololu board. Unless I can find a UK supplier, this will come from the EU so there will be at least 20% tax plus any import charge. The Mega2560 Pro Mini is slightly cheaper (from China) than the Pololu so may be a better option for me here in the UK.My SD card reader has arrived and seems to be working OK so I can resume work on the project.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 03, 2021, 02:43:04 pm
content: I don't know if a board from Australia might be easier for you to purchase?https://www.serveronthemove.com.au/products/nano-v3-new-atmega328pb-with-2020-16mhz-optiboot-bootloader-and-ch340?variant=31787535401094

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 05, 2021, 02:07:07 am
content: I received my Pololu A-Star 328PB Micro today, added the A-Star link in Pololu doc to the Arduino IDE and managed to get the board programmed with the Blink example - but I didn't order the Pololu recommended USB-TTL adapter, I got a different brand, but it didn't have the extra DTR or RTS pin to reset the board, so I kept pressing the reset button on the board and did get it programmed with the Blink code, and I doubled the blink rate to make sure it was working. I've ordered a different USB-TTL adapter with the correct pins to reset the Arduino for programming.I think I will order one of artag's Arduino Micro to GPIB boards and connect the A-Star Micro to that board first.I also received the Pololu microSD adapter which has 5V to 3.3V level shifters to connect to the A-Star Micro extra pins.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 05, 2021, 06:55:14 pm
content: Waveydipole,I think the A-Star 328PB Micro is a good fit for the GPIB Tape Drive emulator.Here is my diagram for using the Pololu A-Star 328PB Micro with Artag's GPIB PCB plus a Pololu MicroSD adapter with level-shifter:I've got PCBs and GPIB connectors ordered - should get them by mid-February.Do you see any issues with using the different Arduino pins for this?I plan to put a header on the top end of the A-Star to connect to a USB-TTL adapter for programming, and then to connect to +5V and GND power on the Tektronix from a ROM Pack, which is near the GPIB connector on the rear of the Tektronix 405x computers for usage.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 10, 2021, 09:44:38 am
content: If I may a couple of observations? The MicroSD adapter board makes use of SCK0 on the central 6-way connector, but SCK0 is also presented on PB13 which is used for DIO7 (GPIB pin 15). I also expect it will be necessary to cut the track to PD1 in order to be able to use it as a GND otherwise that would interfere with TXD0. The same will be required for PB5 and one possibility is to link across to the unused PE3 or maybe PE1 which is nearer. It might be easier to re-work Artag's adapter board which I can probably have a go at if I can find Atrag's original design files to use as a starting point. Having said all of that, I think there are, at least, possibilities.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 12, 2021, 02:44:29 pm
content: Do you have a GitHub account?I have created a private repository for the code I have so far here:https://github.com/Twilight-Logic/AR488_Store.gitI can give your account so that you can access edit files and push updates.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 12, 2021, 03:08:30 pm
content: yes, my account is mmcgraw74

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 12, 2021, 03:55:16 pm
content: I have sent you an invitation as a collaborator.The code is still a long way from a workable program. It has been re-structured extensively and everything, including all GPIB functions, will need to be tested at some point. You will see the storage code in module AR488_Store_Tek_4924.h and AR488_Store_Tek_4924.cpp. I have created an outline that provides a couple of storage management functions and allows a GPIB secondary address to be passed as a command to a handle function, but the individual handler functions are yet to be written. I moved the GPIB functions to AR488_GPIB.h and AR488_GPIB.cpp so that the code can be shared between modules.At this point the code compiles with no errors but with a handful of warnings, one of which relates to the included SD library which I'm not sure I can fix. The program is as yet untested.Two functions I have added to the GPIB library are:void gpibSendFromFile(File sdfile);bool gpibWriteToFile(File sdfile);It should be possible to call them directly from AR488_Store_Tek_4924.cpp.Many of the controller specific functions have been removed, however, as mentioned previously, the SD library is "huge" by microcontroller standards so I'm not sure how well this will work on a 328P or 328PB at this point.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 17, 2021, 06:08:33 pm
content: Quote from: WaveyDipole on February 10, 2021, 09:44:38 amGood catch on pin 13 PB5 conflict as it is SCK0.I updated my diagram to connect PE1 with a jumper wire to the AR488 PCB pin D10.I also put NC next to the A-Star 328PB Micro pins that won't be connected to the AR488 PCB, including the A-Star PDO,PD1,PE3,PB5 and PE0 pins.There would only be three jumper wires - two grounds and PE1 to the AR488 D10 pin, so I think that is fine for testing.My OSHPARK PCB order does not show shipment yet, so in the meantime, I plan to wire the microSD card to the 328PB Micro, and see how much free space is left after uploading your current Arduino code.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 17, 2021, 11:06:44 pm
content: I don't know how fast the Arduino 328P can transfer GPIB data, but I'll bet it is faster than the Tektronix computers.Here is a table of the older 4051 computer GPIB performance on various BASIC commands. The 4051 used PIAs and a little control logic for GPIB.The 4052 and 4054 had about 10x BASIC performance advantage over the 4051 with custom 16-bit bit-slice microcoded architecture emulating the Motorola 6800 opcodes and adding hardware floating point. I didn't find any documentation on their GPIB performance but it could have been faster.The last generation was the 4052A and 4054A with the same bit-slice CPU performance as the 4052/4054 but added the TI 9914 GPIB integrated circuit.The 4052A GPIB Guide had this table of GPIB performance:

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 19, 2021, 06:59:59 pm
content: Quote from: mmcgraw74 on February 17, 2021, 06:08:33 pmWith pins having multiple functions one has to be careful. Hopefully your amendments will work OK.Quote from: mmcgraw74 on February 17, 2021, 06:08:33 pmThat I fear may be an issue:QuoteWe will have to see how it goes.I have been looking at some of the files and information on your GitHub. Thinking ahead.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 19, 2021, 11:10:13 pm
content: QuoteQuoteMy Nano program used the SDfat library - I believe it is smaller than the SD library.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 22, 2021, 06:33:03 pm
content: I will investigate the SdFat library.UPDATE: Had a quick look this morning. Just compiling the basic "Cardinfo" example for the SD library and the similar "SdInfo" example for the SdFat library, yields the following on a Uno:SD library:QuoteSdFat library:QuoteThe Pololu A-Star has the same amout of memory so not surprisingly the results are identical.That's a 26% difference!It looks like it will be worth the effort to re-write using the SdFat library. I will get to work on it ASAP.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 27, 2021, 08:32:38 am
content: Have maybe 90% done the conversion to the SdFat library but have ran into a bigger problem. Although this library uses lass dynamic memory and is a bit more flexible to work with, it seems to require much more program memory. Although it represents only 2% more memory on a Mega 2560, I am now up to 120% of program memory used on a 328P(B)!Above I quoted the usage statistics of the "SdInfo" example. If one looks at the QuickStart example which is not much bigger, the usage stats on a UNO are:QuoteThat's 71% of program memory used for just 200 lines of code! I could do some more digging to find out why, but that's a relatively huge usage for a small demo program.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 27, 2021, 02:12:14 pm
content: I have almost completed my assembly of the Pololu 328PB Micro on Artag's AR488 Pro Micro v3 board.I would think I should test just the 328PB with the current AR488 GPIB code using a custom pin layout before assembling the SD card reader to the board.Then assemble the SD Card reader and retest with your new code using SdFat?I think the larger code footprint may be ok as the SdFat library has the hard part of the code, the actual tape APIs should make heavy use of the library and your GPIB code.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 28, 2021, 12:06:17 am
content: Yippee!!My Pololu Microstar 328PB Micro has successfully passed GPIB tests with standard AR488 version 0.48.28 with my 328PB Micro Custom Layout and hardware serial!In addition - I am using EZGPIB program!!Here is a photo of my Pololu 328PB Micro soldered to artag's AR488 v3 board.Here is a list of how the 328PB Micro pinout is connected to the AR488 v3 board:My changes to the AR488 Config.h file were to add the custom layout from the pinout list:Code:// AR488_CUSTOM defs for Pololu Microstar 328PB Micro#define DIO1 3 /* GPIB 1 */#define DIO2 A2 /* GPIB 2 */#define DIO3 A0 /* GPIB 3 */#define DIO4 A1 /* GPIB 4 */#define DIO5 8 /* GPIB 13 */#define DIO6 9 /* GPIB 14 */#define DIO7 SCL1 /* GPIB 15 */#define DIO8 6 /* GPIB 16 */#define IFC 4 /* GPIB 9 */#define NDAC A6 /* GPIB 8 */#define NRFD A5 /* GPIB 7 */#define DAV A4 /* GPIB 6 */#define EOI A3 /* GPIB 5 */#define SRQ 7 /* GPIB 10 */#define REN 5 /* GPIB 17 */#define ATN 2 /* GPIB 11 */And I changed the version string in the Config.h to:Code:#define FWVER "Prologix GPIB-USB Controller version 5.1"//, AR488 ver. 0.48.28, Custom Pololu 328PB Micro layout 02/27/2021"I also patched the EZGPIB.exe per posts in the AR488 thread.Since the 328PB Micro does not have a USB to serial interface - I have connected the TTL serial pins on the "top" edge to a DSD=Tech SH-U08F USB to TTL adapter from Amazon:https://www.amazon.com/gp/product/B07BBPX8B8This adapter uses an FTDI IC that has RTS/CTS which can be changed to other handshake signals inside the box.I have the RTS connected to the Reset pin of the 328PB so that Arduino upload can reset the CPU.I also connected the CTS of the TTL adapter to +5V on the 328PB to allow the EZGPIB.exe program to discover the 328PB - which reported "Prologix GPIB-USB Controller v5.1", exactly like a Prologix GPIB-USB Controller in my next picture reported.I was have issues just using the AR488 with the serial console so I downloaded the EZ-GPIB.exe and patched it and then it detected my 328PB as shown in the EZGPIB debug console:Here is my AR488 328PB connected to the HP 34970A:I learned some HP 34970A commands and created a short program on EZ-GPIB with the Prologix GPIB-USB v2 adapter first, the was able to run the same program with my 328PB!And here is the front of the HP 34970A monitoring channel 101 which is directly connected to the 9V battery:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 28, 2021, 12:15:48 am
content: I still can't figure out how to get inline pictures in my posts.but the EZGPIB screenshot was a duplicate.Here is the EZGPIB debug console showing my board was detected as a Prologix GPIB-USB:My next step will be attaching the Pololu MicroSD adapter with level shifters - it should look like this:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 28, 2021, 12:49:48 am
content: My previous post had a link to the USB-TTL adapter I used. The back of this adapter photo shows the part number as DSD Tech SH-U09C, not the part number in my previous post.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 28, 2021, 12:53:08 am
content: I am using the USB to TTL adapter RTS signal to reset my Pololu 328PB as that signal is supported by the AVRDUDE software.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 28, 2021, 12:56:58 am
content: One more update - you can see in my photo of plugging the 328PB into the HP 34970A GPIB connector - I have unplugged the RTS signal from the USB-TTL converter, as EZ-GPIB asserts the RTS, which resets the 328PB and results in not detecting the 328PB.To update the Arduino program on the 328PB - I plug the RTS back into the USB-TTL converter.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 28, 2021, 01:04:36 am
content: I thought I posted my photo of the 9V battery being voltage monitored by the HP 34970A.Here is that photo:

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: February 28, 2021, 01:49:32 pm
content: It looks like you are making really good progress on the hardware side of things!I also have made some progress on the software side. I logged an issue about the memory usage on the SdFat authors GitHub page and he came back with some suggestions. I have tried these out this has reduced the memory requirement:QuoteThis is an improvement but comes at the cost of long filenames and disabling ExFAT. Apparently the standard Arduino SD library supports only FAT16/32. The modification basically disables ExFAT and long filenames. I am hoping that the latter can be worked around. I am almost at the point where I was before I changed the library. I need to do some more work to tidy up the code and finish the final two functions, then we will have a proper basis of comparison.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: February 28, 2021, 02:53:21 pm
content: Excellent!I don't think long filenames are required for this application, Tektronix tape drives only had numbers from 1 to 99 for the file "names".I also don't think we need ExFat - my entire collection of Tektronix programs (which also includes some manuals) is 350MB zipped, so maybe 1GB of BASIC text programs.Instead of using a long filename to have the file header information as I previously thought, I can put all the file headers in each directory in a single file containing one 72 character string for each file header.The tape file header is read by the Tektronix computer when the file is opened with a "FILE #" command, so the computer knows the data type(s) for that file.The computer creates the original file header as a "NEW" file type.The first time that file is opened and written to by a program will then change the file header to match the program operation.Examples:A NEW file that is first written with a PRINT A$ command, will cause the computer to read-modify-write the file header to an ASCII DATA file type.A NEW file that is opened and a SAVE command is executed will first have the file header modified to indicate ASCII PROGRAM file type.A NEW file that is opened and a BSAVE command is executed will first have the file header modified by the computer to indicate BINARY PROGRAM file type.All the burden for understanding the file type and rules on what data to expect on a READ command are on the computer, not the tape drive, since the tape drive could be used with different systems including terminals and some of the early scopes.I expect the computer to read a byte at a time from the tape drive after using the FIND # command and decide when to stop the transaction.The tape drive will indicate end of file if there is no data remaining in that file.In order for the computer to read the file header, it sends a special PRINT command with secondary address 0 to the tape drive:Code:STATUS 0 (MTA 69)(MSA 96)(ReturnedStatus)(UNT) Input command from 4050, return four status numeric variablesSTATUS 0 (MLA 37)(MSA 96)(A,B,C,D)(UNL) Print command from 4050, receive four tape parametersex: PRINT @5,0:0,0,1 disable Headers so they can be read with INPUT after FINDex: PRINT @5,0:0,0,0 enable Headers for normal file operations

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 01, 2021, 01:51:50 am
content: Maybe the SdFat 2.0 version has too much capability for this project.I deleted the SdFat 2.0 library and downloaded the latest 1.0 library from the Releases list.Then I ran SdFormatter in the 1.0 examples and reformatted my 32GB MicroSD card.Then I ran SdInfo in the 1.0 examples and got this report:Code:SdFat version: 10102Assuming the SD is the only SPI device.Edit DISABLE_CHIP_SELECT to disable another device.Assuming the SD chip select pin is: 10Edit SD_CHIP_SELECT to change the SD chip select pin.type any character to startinit time: 13 msCard type: SDHCManufacturer ID: 0X3OEM ID: SDProduct: SC32GVersion: 8.0Serial number: 0X2FF11AB0Manufacturing date: 8/2013cardSize: 31914.98 MB (MB = 1,000,000 bytes)flashEraseSize: 128 blockseraseSingleBlock: trueOCR: 0XC0FF8000SD Partition Tablepart,boot,type,start,length1,0X0,0XC,8192,623257602,0X0,0X0,0,03,0X0,0X0,0,04,0X0,0X0,0,0Volume is FAT32blocksPerCluster: 64clusterCount: 973584freeClusters: 973583freeSpace: 31902.37 MB (MB = 1,000,000 bytes)fatStartBlock: 9362fatCount: 2blocksPerFat: 7607rootDirStart: 2dataStartBlock: 24576type any character to startHere is the memory footprint from Arduino 1.8.13 for the SdInfo program:Code:Using library SdFat at version 1.1.4 in folder: C:\Users\mcgrawmc\Documents\Arduino\libraries\SdFat"C:\\Program Files (x86)\\Arduino\\hardware\\tools\\avr/bin/avr-size" -A "C:\\Users\\mcgrawmc\\AppData\\Local\\Temp\\arduino_build_246140/SdFormatter.ino.elf"Sketch uses 12220 bytes (37%) of program storage space. Maximum is 32256 bytes.Global variables use 803 bytes (39%) of dynamic memory, leaving 1245 bytes for local variables. Maximum is 2048 bytes.I think this SdFat 1.0 version gives us more program space and memory space than the 2.0 version - and should be compatible API calls.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 01, 2021, 02:05:52 am
content: Not to mention I did this on my Pololu A-star 328PB Micro board with Micro SD adapter" alt="" class="bbc_img" />I moved the +5V power wire from the serial adapter end of the board to the ISP connector to eliminate the low-voltage regulator drop on the +5V.I also cut the GND pin from top and bottom sides and wired it to Vcc for the CTS signal and added the orange wire from the USB-TTL adapter into the header.Next step is to design a case for the assembly and 3D print it.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 01, 2021, 02:09:21 am
content: Actually I installed a 4.7K pullup resistor from Vcc to the CTS pin (just in case I try to plug a ground wire into the first position of the header.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 04, 2021, 01:01:39 pm
content: I copied four files with long filenames to the MicroSD card from my PC.Then loaded/compiled/ran the Directory example in same SdFat version 1.0 as SdInfo above, same MicroSD SSD.My four files with long filenames were copied to the root folder and showed up in each of the listings.The Directory example created a folder and two files and showed the MicroSD contents including the created Folder1 as it created and deleted the two files and then Folder1 was deleted successfully:Code:Type any character to startPlease use an empty SD for best results.Created Folder1Created Folder1/file1.txtchdir to Folder1Created File2.txt in current directoryList of files on the SD.Folder1/file1.txtFile2.txta-star-328pb-micro-schematic.pdfMy Tektronix GPIB breadboard in June 2018.jpgMy Pololu 328PB with MicroSD card.jpgIMG-2366.jpgfile1.txt and File2.txt removed.List of files on the SD.Folder1/a-star-328pb-micro-schematic.pdfMy Tektronix GPIB breadboard in June 2018.jpgMy Pololu 328PB with MicroSD card.jpgIMG-2366.jpgFolder1 removed.List of files on the SD.a-star-328pb-micro-schematic.pdfMy Tektronix GPIB breadboard in June 2018.jpgMy Pololu 328PB with MicroSD card.jpgIMG-2366.jpgDone!I think SdFat version 10102 is a keeper

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 04, 2021, 01:05:17 pm
content: and here is the memory footprint on the Pololu A-Star 328PB Micro for the Directory Functions example:Code:Sketch uses 15278 bytes (47%) of program storage space. Maximum is 32256 bytes.Global variables use 1065 bytes (52%) of dynamic memory, leaving 983 bytes for local variables. Maximum is 2048 bytes.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 10, 2021, 06:32:27 pm
content: I have begun prototyping my 4924 tape emulator on the 328PB Micro with the Tektronix 4050 BASIC "TLIST" command, which lists the files on a tape in numeric order.Here is the output of my TLIST command - including extra text indicating the detected file type (ASCII or HEX):Code:TLIST of files in TEST directory1 ASCII PROG [LIST-F.FD] 30 FileType = ASCII2 ASCII DATA [Advitm ] 10 FileType = ASCII3 BINARY DATA 29 FileType = HEX4 ASCII PROGRAM SECRET 26 FileType = HEX5 ASCII PROG [DUPL ASCI] 18 FileType = ASCII6 ASCII PROG [4924 dupe] 33 FileType = ASCII7 ASCII PROG [Bubl Sort] 30 FileType = ASCII8 ASCII PROG  11 FileType = ASCII9 ASCII PROG  14 FileType = ASCII10 ASCII PROG  12 FileType = ASCII11 ASCII PROG [TLIST EXT] 15 FileType = ASCII12 LAST 3 FileType = ASCIITektronix 4050 tape files have several attributes:File number - used to access the fileFile data type - ASCII or BINARYFile type - PROGRAM or DATASECRET - this attribute indicates the PROGRAM is encryptedFile size - this column indicates how many 256 byte blocks were allocated for this file when it was MARKedYou will notice that some of the files show additional information like a filename.Tektronix published information in the 4050 Programmers Reference Guide on how to access this file header and modify the header with additional information.However, there were several constraints on these modifications as shown in the fragment of the manual below:My code so far does not have the GPIB device mode code, I only have the SdFat v2 library for Micro SD card file input/output and my test program.The sketch currently uses 12808 byte of program storage (39%) and 1014 bytes of RAM (49%).If the 328PB Arduino does not have enough room for the full program, I have a Pandauino Atmega 644 board coming that has 64KB of flash and 4KB of RAM:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 13, 2021, 01:30:55 am
content: Another update on my Tek 4924 emulator functions.I have TLIST and FIND functions coded, with the ability to run the FIND command with the required file number parameter.I have also created some test files using shortened versions of Tektronix utility programs that had tape headers modified to add names of the programs.The Tek 4050 BASIC programs tend to make heavy use of ASCII control characters in PRINT statements:- CR is only allowed as the delimiter for every line- LF is used inside PRINT statements to get to a newline without requiring a new PRINT statement- HT provides a TAB function- FF clears the storage tube screen- and a couple of othersSince Arduino uses LF for a newline, I took advantage of the ArduinoOutStream to use CR as a line delimiter instead of LF for example.Since the Arduino serial monitor appears to drop the CRs, I use RealTerm which has a font displaying control characters and supports CR with a true carriage return after printing the CR control character.Here is a RealTerm screen showing opening and printing one of my BASIC test program files.Notice only a CR at the end of each line, and LFs inside PRINT statements:I also received the Atmega 644 Narrow board from Mouser, added the hardware support for this board to the Arduino IDE and compiled the same program from the 328PB board.You can see in the IDE compiler output that the 644 Narrow board has 64KB of flash and 4KB of RAM - double the flash and RAM compared to the 328PB.If we don't have enough RAM for the final emulator program in the 328PB - I plan to have the 644 Narrow board mounted to the AR488 board with a MicroSD adapter as my backup plan.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 13, 2021, 01:34:19 am
content: Wow, that second attachment was unreadable. I didn't notice that I didn't crop the width.Hope this is readable this time:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 14, 2021, 03:29:56 am
content: Even more progress!On the hardware side, I have my Pandauino 644-Narrow connected to the AR488 PCB from artag, and have added an Adafruit MicroSD adapter.The assembly works with EZ-GPIB, even though the 644-Narrow uses the CH340G USB to TTL serial IC, I didn't have to ground the pins 9 and 10 as indicated in another eevblog thread. In fact, grounding those pins caused EZ-GPIB to fail to detect the boardRealterm indicated both CTS and DSR to be asserted. What I did have to do was add a 100 ohm pullup resistor on the ATmega644 reset input, which prevents EZ-GPIB from resetting the ATmega644 during serial discovery. I did have to run EZ-GPIB twice to get it to detect the 644-Narrow running AR488 code with my custom pinout, and I was able to duplicate my results of interfacing to the Agilent 34970A data acquisition instrument.Then I added the Adafruit MicroSD adapter and was able to read the MicroSD card that I had used in the Pololu 328PB.I wanted to integrate my MicroSD reader code into the AR488, and added three new 'Prologix' commands:Code:++tlist This command emulates the 4924 tape drive listing all the files on a tape++find # This command will find the file number # and the full SD card filename will be saved for the next command++old This command loads the current file number into Tek 4050 as a BASIC programHere is a screenshot of running the full program. I modified the AR488 version string for use with the EZ-GPIB software.Here is the Arduino memory utilization of the program so far - tragically, I won't fit in the 328PB, but that is why I got the Pandauino 644-NarrowIt looks like I'll have plenty of room for the rest of my Tektronix 4924 GPIB tape drive emulator code

author: mmcgraw74
author_rank: Regular Contributor
timestamp: March 14, 2021, 03:48:34 am
content: Here are photos of my board stack with artag's AR488 GPIB connector board and my Pandauino 644-Narrow ATmega644 with an Adafruit MicroSD adapter:The 644-Narrow is 0.1" wider than the 328PB, but I pushed the header pins to make it fit.I also pushed four pins on one side 0.1" closer to avoid the 3.3V signal in the middle.I only have two jumper wires - a +5V power to the MicroSD as I must have damaged the PCB trying to remove that pin to mount it on top of the board, and pin 4 as the MicroSD chip select.And one 100 ohm resistor from the reset switch to a header pin next to a +5V pin that I can add a jumper so EZ-GPIB identifies this board as a Prologix board without triggering reset. I remove the jumper to upload new Arduino code to the board.Here is my AR488 custom pin layout for the 644-Narrow board:Code:/*******************************//***** AR488 CUSTOM LAYOUT *****//***** vvvvvvvvvvvvvvvvvvv *****/#ifdef AR488_CUSTOM// AR488_CUSTOM defs for Pandauino 644-Narrow#define DIO1 11 /* GPIB 1 */#define DIO2 24 /* GPIB 2 */#define DIO3 26 /* GPIB 3 */#define DIO4 25 /* GPIB 4 */#define DIO5 16 /* GPIB 13 */#define DIO6 17 /* GPIB 14 */#define DIO7 27 /* GPIB 15 */#define DIO8 14 /* GPIB 16 */#define IFC 12 /* GPIB 9 */#define NDAC 3 /* GPIB 8 */#define NRFD 2 /* GPIB 7 */#define DAV 1 /* GPIB 6 */#define EOI 0 /* GPIB 5 */#define SRQ 15 /* GPIB 10 */#define REN 13 /* GPIB 17 */#define ATN 10 /* GPIB 11 */#endif/***** ^^^^^^^^^^^^^^^^^^^ *****//***** AR488 CUSTOM LAYOUT *****//*******************************/

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: April 02, 2021, 08:50:14 am
content: I see you are making great progress with the project. I am sorry I have not been able to contribute much for the last few weeks. I am currently caring for my 81-year old mum who has been in and out of hospital for the last 3 weeks and time has been very limited.However, I see you have given up on the 328p and decided to use another board for the project. I must admit that my motivation waned somewhat when I discovered that the memory on the 328p was just too small. I had not come across the Panduino before, but its similarly small footprint seems handy to fit the Artag adapter board. Interesting to note that it works nicely with EZ-GPIB and you now have a couple of commands working. At some point you will need to send GPIB data to the memory card instead of the serial port, which was the next problem I started to grapple with but didn't quite get around to.I am not sure how long the current situation will last or how much time I can contribute to the project in the current circumstances although I will keep an eye on developments.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: April 02, 2021, 12:50:58 pm
content: Take care of your mum - family comes first!I did design my first PCB and sent it to Oshpark this week.The PCB will mount the 644-Narrow directly and use the ISP header connections to power the MicroSD adapter without the rework I did on my prototype.I organized the GPIB data pins to route them to the same ATmega 644 port.Next, I'll try to modify the nifty 3D printable case posted on the AR488 thread to fit my stack of boards.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: April 09, 2021, 02:01:17 pm
content: I received my PCB order from Oshpark yesterday and assembled one of the boards - it worked with EZ-GPIB to access my Agilent 34970A Data Acquisition Unit!Here is the Tape Emulator plugged into the Agilent for testing with EZ-GPIB:The assembly is only about 0.1" taller and 0.1" wider than artag's AR488 design with a Pro Micro.The 644-Narrow board with the ATmega644 processor is quite a bit longer than the Pro Micro, so there are no mounting holes for the GPIB connector, but I plan to modify the 3D case design posted recently in the AR488 thread, which mechanically supports both the GPIB connector and the stack of boards without using the GPIB mounting holes.Here is the new custom layout for my Tape Emulator PCB:Code:/*******************************//***** AR488 CUSTOM LAYOUT *****//***** vvvvvvvvvvvvvvvvvvv *****/#ifdef AR488_CUSTOM// AR488_CUSTOM defs for Pandauino 644-Narrow in Monty's Tektronix 4924 Tape Emulator PCB connector#define DIO1 10 /* GPIB 1 */#define DIO2 11 /* GPIB 2 */#define DIO3 12 /* GPIB 3 */#define DIO4 13 /* GPIB 4 */#define DIO5 14 /* GPIB 13 */#define DIO6 15 /* GPIB 14 */#define DIO7 16 /* GPIB 15 */#define DIO8 17 /* GPIB 16 */#define IFC 22 /* GPIB 9 */#define NDAC 21 /* GPIB 8 */#define NRFD 20 /* GPIB 7 */#define DAV 19 /* GPIB 6 */#define EOI 18 /* GPIB 5 */#define SRQ 23 /* GPIB 10 */#define REN 24 /* GPIB 17 */#define ATN 31 /* GPIB 11 */#endif/***** ^^^^^^^^^^^^^^^^^^^ *****//***** AR488 CUSTOM LAYOUT *****//*******************************/

author: mmcgraw74
author_rank: Regular Contributor
timestamp: April 09, 2021, 02:04:52 pm
content: I don't know why my photos didn't show up.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: April 09, 2021, 02:12:46 pm
content: The 2-pin jumper in the photo connects the 100 ohm resistor from the RESET pin on the reset switch to +5V, and is only used to prevent the board reset when running EZ-GPIB.I still have to run EZ-GPIB twice to have it identify the board as a Prologix GPIB adapter, and then it successfully runs my quick test program to acquire three voltage samples from the Agilent.The jumper must be removed to upload a program from the Arduino IDE, and will be removed when running my Tape Emulator connected to a Tektronix computer.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: May 26, 2021, 05:19:39 pm
content: Quote from: WaveyDipole on February 12, 2021, 02:44:29 pmWaveyDipole,That link used to work, but I now get a 404 error trying to access it.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 03, 2021, 06:43:12 pm
content: It is still there as a private repository and I haven't changed anything.The link is still:https://github.com/Twilight-Logic/AR488_Store.gitI am not sure whay you can't access it?Maybe a GitHub glitch. I can remove you and send you another invite? Just a bit worried that may loose access altogether but its the only thing I can think of right now.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 03, 2021, 10:20:42 pm
content: Quote from: WaveyDipole on June 03, 2021, 06:43:12 pmSorry, I posted that I had fixed it on the AR488 forum.I had replaced my laptop, so I had not been authenticating to github. Soon as I logged into github, I could access the AR488_Store files.Right now, I'm cleaning up the pieces of Emulator code I had running on the AR488 and will migrate it to AR488_Store so I can send my changes to you. You should be able to run the code with a Mega2560.Here is a snapshot of running several of my Emulator commands on my 644_Narrow board with my GPIB adapter:" alt="" class="bbc_img" />

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 03, 2021, 10:31:55 pm
content: My new Tektronix 4924 Tape Emulator PCB eliminates all my jumper wires when I was plugging into an artag AR488 Pro Micro GPIB adapter PCB.Here is the top view of the new assembly and a side view:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 03, 2021, 10:33:46 pm
content: still having trouble figuring out how to post images hereHere is the top view of my new Tektronix 4924 Emulator assembly:" alt="" class="bbc_img" />

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 03, 2021, 10:40:48 pm
content: TLIST is a Tek 4050 BASIC command to list all the files on a tape with their Header information.FIND is a command to locate and open a file on the tape.OLD is a command to load an ASCII PROGRAM that has been openedThe read1 command is not a BASIC command, but my test of the INPUT A$ command on an ASCII file that has been opened to read a single string (data or program statement).The cd command is one I intend to add to the menu program allowing multiple "tapes" to be stored in separate MicroSD card directories.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 05, 2021, 03:34:19 pm
content: @WaveyDipole,I created a Monty1 branch on AR488_Store.I had lots of errors trying to compile your original files - I put the compile errors.txt file output from my Arduino 1.8.13 IDE in my branch AR488_Store folder.I also tried to move my files into AR488_Store and had similar compile errors. I put this effort in my branch AR488_Store-TLIST...etc folder.I uploaded my working code into my branch AR488-644-TLIST... etc folderI also uploaded the zip of all the Tektronix 4924 test files on my microSD card, and uploaded a Tek4924sd folder with the files unzipped.You should be able to compile and run my AR488-644-TLIST... version (which sends output to serial and does not use GPIB yet) using a Mega2560 with a level-shifter microSD adapter (Adafruit or Pololu) attached to SPI pins, CS pin,+5V and ground.I use Realterm as the serial console - since it shows all the control characters, and Tek BASIC barfs on linefeed characters that are not inside text in a PRINT statement.My current code changes the line termination on output to CR.I am using a Sandisk Ultra 32GB microSD card, formatted as FAT32.My code assumes all files are in separate directories on the microSD card, with the /root/ directory being the default directory.There will not be subdirectories in any of the directories.Each directory will contain up to 99 files which is the limit of file numbers in Tek 4050 BASIC.I am taking advantage of SdFat long filename support and putting the contents of the tape file header into the FAT32 filename, and I am not using the file extension.This is a list of the filenames in the /utilities/ directory.My code extracts the emulated tape file number from the first number in the filename.File type is based on extracting other characters from the file 'headers':ASCII orBINARY andPROG orDATADetection ofSECRET programs is based on finding an "S" in that position in the header - see file number 4.Programs that added comments to the file header had to avoid putting an "S" at that location - or the file would be unusable.File size is the last number (number of blocks) * 256 bytes per blockCode:[font=courier]1 ASCII PROG [LIST-F.FD] 3010 ASCII PROG  1211 ASCII PROG [TLIST EXT] 1512 LAST 32 ASCII DATA [Advitm ] 103 BINARY DATA 294 ASCII PROGRAM SECRET 265 ASCII DATA [492Scope ] 186 BINARY DATA [4924 dupe] 337 ASCII PROG [Bubl Sort] 308 ASCII PROG  119 ASCII PROG  14

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 07, 2021, 12:44:10 pm
content: @WaveyDipole,I have updated my latest dev build of the emulator on my Monty1 branch of AR488_Store.I need help porting this build into your AR488_Store program - I can't build your program so I have continued my development changes in your original AR488 program.Here is a screenshot of my latest dev build, I have added functions to read1 allowing an ASCII or BINARY file to be read one record at a time:

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 07, 2021, 11:32:17 pm
content: Thanks for all your work. I will have a look at earliest opportunity.UPDATE: Had a look this morning but am a bit puzzled. Had a look in the 'AR488-644-TLIST-continuedDev' directory but couldn't see the 'AR488_Store_Tek' files. The point behind keeping the storage hardware routines in their own separate file was to be able to e.g. add 'AR488_Store_Pet' and other possible storage devices in the future and be able to select between them. I see that the Tek code has been moved to the main .ino file. I am happy to run with that for now if it helps with progressing development.I was still on version 1.8.12 and have now upgraded to the latest version which is 1.8.15. In the meantime I also downloaded version 1.8.13 to test with. There were a few warnings, but no errors and the code did compile. The IDE reports that there is insufficient memory on the Uno and Polulu boards so I selected the Mega2560 board.Here are a few observations about the warnings:The warnings on line 547 and 612 (comparison between signed and unsigned integer expressions) arise because 'nMax' is defined as a const uint16_t while 'number' is is a type int. For consistency variables being compared need to be of the same type, either type 'int' or type 'uint16_t'.Either change 'nMax' to 'const int' or 'number' and 'index' (an maybe also 'filenumber') to type 'uint16_t'. That should get rid of that particular warning.Warnings about unused variables can usually be ignored. Either they will get used eventually when the code is complete, of they can be removed once it has been established that they are no longer required. The warning should then go away.Line 2119, 2131, 2139 and 2147 :e.g.void help_h(char *params)void readf_h(char *params)void read1_h(char *params)void old_h(char *params)void tlist_h(char *params)Since 'params' is not actually being used, and assuming it is not going to be used, can be defined as:void help_h()void readf_h()void read1_h()void old_h()void tlist_h()Their references in cmdHidx will need to be cast to type 'void' by changing them to:{ "readf", 3, (void(*)(char*)) readf_h }{ "read1", 3, (void(*)(char*)) read1_h }{ "help", 3, (void(*)(char*)) help_h }{ "old", 3, (void(*)(char*)) old_h }{ "tlist", 3, (void(*)(char*)) tlist_h }That will get rid of those warnings.Line 2178: warning: statement has no effectf_name; //clear previous f_name prior to tlistI presume the intention was to clear 'char f_name' of all characters? In C++ you do this with:memset(f_name, '\0', 46)That fills the memory assigned to the array will null bytes.Hope this helps a little.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 08, 2021, 06:37:46 pm
content: I can't compile with Arduino 1.8.13 or 1.8.15 your original AR488_Store. I get a message "arSerial was not declared in this scope"My attempt at merging my code into AR488_Store is in AR488_Store-TLIST-FIND-OLD-CD-READ1-READf-HELP-TYPE folder.What folder are your able to compile?

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 08, 2021, 07:27:58 pm
content: Quote from: mmcgraw74 on June 08, 2021, 06:37:46 pmThat's odd. I just downloaded it onto a computer other than my usual development machine and had no problem compiling for the Mega 2560 or Pololu 328PB. There were a handful of warnings, including a memory warning for the Pololu 328PB, but no errors. I did get an error when compiling for the Pololu 32u4 that prevented a successful compile although I didn't think we were using that board. Which board were you compiling for? Could you show me the actual output from the compiler please?Quote from: mmcgraw74 on June 08, 2021, 06:37:46 pmI had a go at the 'AR488-644-TLIST-continuedDev' folder. Haven't tried the 'AR488_Store-TLIST-FIND-OLD-CD-READ1-READf-HELP-TYPE' yet. Will give it a go though.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 08, 2021, 08:30:48 pm
content: I uploaded a new file into AR488_Store folder "compile errors on 8-June.tx".I am using Arduino 1.8.15 on Windows 10 and compiled AR488_Store for my ATMEGA644 board, that compiles my AR488-644-TLIST-ContinuedDev without any errors.arSerial looks like it is defined in AR488_Config.h in both my ContinuedDev folder and AR488_Store, but the Config.h in AR488_Store is 2KB larger.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 09, 2021, 09:15:24 am
content: Thank you. I have had a look at the compile errors file. You mention an ATMega644 board. I hadn't picked up on that from earlier posts or even from the names of the directories! I have not programmed or compiled for one of those previously so that may be the issue. It doesn't seem to appear on the list of AVR boards. I will check it out and report back. I may need to adjust the Config.h to include support for that board.UPDATE: A little further digging suggests that the 644 (and 1284) are NOT supported by the Arduino IDE out of the box but I did find the following URL to add the board to the IDE:https://raw.githubusercontent.com/Lauszus/Sanguino/master/package_lauszus_sanguino_index.jsonIs this the one that you used?UPDATE2: A quick test with that board shows it does produce the error you mention among other things because there is no section in Config_h that defines the serial port/device to use. I need to create a new section in the Config_h for it as well as a layout. Do you already have a pinout in mind?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 09, 2021, 01:45:57 pm
content: The Panaduino 644-Narrowhttps://pandauino.com/en/644-narrow-1284-narrow-atmega644-atmega1284/with Atmega644 CPU uses the MightyCore library:https://github.com/mrguen/644-1284-Narrow/blob/master/install/MightyCore-Pandauino.exeto add the Panaduino 644-Narrow and 1284-Narrow to Arduino.This board is the smallest one I have found that hasmore I/O pins, anddouble the flash and RAMcompared to the 32u4AND the 5V pin compatibilityfor direct connection to drive GPIB.I created my own Oshpark custom board to connect the 644-Narrow to the GPIB connector and Pololu MicroSD adapter with 3.3v level-shifter.My custom pinout is in the AR488_Config.h file in my continuedDev folder:Code:/*******************************//***** AR488 CUSTOM LAYOUT *****//***** vvvvvvvvvvvvvvvvvvv *****/#ifdef AR488_CUSTOM// AR488_CUSTOM defs for Pandauino 644-Narrow plugged into artag's AR488 v3 GPIB connector PCB#define DIO1 11 /* GPIB 1 */#define DIO2 24 /* GPIB 2 */#define DIO3 26 /* GPIB 3 */#define DIO4 25 /* GPIB 4 */#define DIO5 16 /* GPIB 13 */#define DIO6 17 /* GPIB 14 */#define DIO7 27 /* GPIB 15 */#define DIO8 14 /* GPIB 16 */#define IFC 12 /* GPIB 9 */#define NDAC 3 /* GPIB 8 */#define NRFD 2 /* GPIB 7 */#define DAV 1 /* GPIB 6 */#define EOI 0 /* GPIB 5 */#define SRQ 15 /* GPIB 10 */#define REN 13 /* GPIB 17 */#define ATN 10 /* GPIB 11 */#endif/***** ^^^^^^^^^^^^^^^^^^^ *****//***** AR488 CUSTOM LAYOUT *****//*******************************/This pinout for GPIB and microSD does not use the serial port TX/RX pins.Here is the 644-Narrow pinout diagram.Note ALL the PINs have Interrupt capability, although my sketch with custom layout does use the interrupts and had no issue interfacing to an HP data acquisition box using the 644-Narrow and my custom GPIB adapter as I previously posted in this thread.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 09, 2021, 02:28:59 pm
content: Quote from: mmcgraw74 on June 09, 2021, 01:45:57 pmOk, will have a look at that.Quote from: mmcgraw74 on June 09, 2021, 01:45:57 pmYes, makes sense.Quote from: mmcgraw74 on June 09, 2021, 01:45:57 pmSorry. Should have realized that, but thank you for the confirmation.Quote from: mmcgraw74 on June 09, 2021, 01:45:57 pmThat would explain the problem. The AR488 as it stands expects at least one serial port to be configured for communication with the PC. Are you intending to dispense with communication over serial/USB altogether? If so, then the references to the serial port, especially the verbose responses could be removed saving a bit of program memory. It also simplifies things considerably.Quote from: mmcgraw74 on June 09, 2021, 01:45:57 pmI noticed you had designed a new adapter board. Interrupts are not strictly necessary and I might be removing the feature from my next version. It doesn't seem to add anything really except complexity.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 09, 2021, 02:56:58 pm
content: I am using serial now for development, but the 'production' 4924 tape emulator will not need a serial interface, just the GPIB with primary and secondary addressing.The firmware can be updated over USB, and the SD files can be updated by plugging the microSD card into a PC.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 09, 2021, 02:59:23 pm
content: I have been putting my serial messages into the EEPROM with the F( ) formatting to keep them out of the flash. These messages won't be needed over GPIB.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 09, 2021, 05:20:06 pm
content: Quote from: mmcgraw74 on June 09, 2021, 01:45:57 pmI generally don't use Windows but I found further information in mrguen's manual for the Panduio. He refers to MCUdude's MightyCore toolkit:https://github.com/MCUdude/MightyCore#how-to-installThe instructions there provide the JSON URL to add to the Additional Boards Manager URL's box in Preferences in the IDE which is:https://mcudude.github.io/MightyCore/package_MCUdude_MightyCore_index.jsonSo now I have the same board toolkit installed in Boards Manager.Quote from: mmcgraw74 on June 09, 2021, 02:56:58 pmOk, so that is understood. There will be no need to communicate over serial in "normal" operation. The CH340 USB/UART chip still connects to TX0/RX0 for uploading the firmware, but we are not going to use it for communication over USB. I presume that configuration (e.g. GPIB address) will be set in firmware or via the Config file? There might be enough pins to add an 8-way DIL switch, although of course, the adapter board is already designed and purchased, so perhaps can we skip that idea.Quote from: mmcgraw74 on June 09, 2021, 02:59:23 pmA good idea, always. Flash gets used up pretty quick otherwise.Funny how all of the Panduino graphics deliberately hide the details of the chips on the board!Yet, they are obvious and easy enough to find: either a 644 or a 1284 MCU and a CH340 UART so not sure what the big secret is!I will have a think about how to address the serial port (error) problem and revise the AR488_Store code accordingly. Incidentally, I don't mind removing the AR488 tag from it altogether if it suits.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 09, 2021, 05:50:20 pm
content: No need for adjustable GPIB device address, I would just hardcode address 5 in the config file.There is a full schematic for the Pandauino board in the user manual and both page 1 and 2 are in the github doc folder:https://github.com/mrguen/644-1284-Narrow/blob/master/doc/Narrow%20v1.0%20schematics%20-%201.jpg

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 10, 2021, 07:02:48 pm
content: Been studying the sketches and trying to catch up a bit.Just a question: the version you have in the 'AR488-644-TLIST-continuedDev.ino' directory adds you routines into the main command list, i.e. so that they are called with ++find, ++cd, ++readf etc. Is it the intention to call these commands using Prologix format, or is this for test purposes?I did wonder whether the intention might be to eventually port these functions to the code that responds to remote commands over GPIB, but I also notice that you have defined a couple of ArduinoStream objects which also point to Serial ports. Unless this is all for test purposes, it does appear that we do require an active serial port? I just want to clarify and establish which bit of code (directory) I need to work with?It seems developing Tek storage functions at your end is coming on apace. I need to catch up but I want to make sure that I am heading in the right direction....If you want, I can also add the //------------- separators to my parts of the code. They do make individual functions and sections of code stand out a bit better.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 10, 2021, 07:20:45 pm
content: all my ++ commands are for test.I imagined that the routines will directly map to GPIB secondary addresses, and the ArduinoOutStream cout(Serial) would change to ArduinoOutStream cout(GPIB)?For example if the 4924 emulator primary address is 5 we have a good start on theblue highlightedsecondary address commands with my serial commands: tlist, find, old, cd, read1These commands are the minimum to run most of the hundreds of Tektronix 4050 programs I have recovered. The ones that write to files would wait for the WRITE routine to be written. The MARK command is only used to create new file(s), which wouldn't be hard to code with SdFat.[ Specified attachment is not available ]

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 10, 2021, 08:07:35 pm
content: Ok, that begins to make sense. So for my part, I need to get the Store part working so that the routines can be dropped in and tested. To that end I have ordered a 1284 chip to help along with development. I already have a development board knocking around with an AtMega16 plugged in, but that has half the memory of a Uno//Nano/32u4, so far too little to be useful. The 644 and 1284 are both pin compatible so should just drop into the same board.How are you going to get the SD Card formatted? I started work on some ++ commands to do that and manage the file system, swap "tapes" etc, but if we are not using the serial port then all ++ commands will be null and void from now on so any configuration will either have to be hard coded or made available in Config.h which is quite easy to do. This also means that a blank SD card will either need to be pre-formatted before insertion into the reader, or automatically formatted when the script is first run with it inserted. Of course, if the card is already formatted, that will need to be detected so as not to not format it again. I made some progress along those lines by automatically creating a directory for the tapes. I will have to familiarise myself with the current arrangement and adapt accordingly.I will start work on getting the store part to compile then on the 644/1284 and hopefully have something ready and available to test once the chip arrives.I am currently on something called a Low Fodmap Diet on doctors orders and feel quite poorly, but I will do my best to get things moving.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 10, 2021, 09:18:51 pm
content: My plan for getting the data files on the microSD card is to tell the user to format the card as FAT32, then unzip the file that will contain all the program and data files into the proper directories.I will be creating that zip file from my github archive, and will edit all the file commands to add @5: which will then cause BASIC to access the tape emulator at primary address 6. BASIC will add the secondary address number based on the command name when the tape emulator is being addressed.The tape emulator will only respond to commands to its primary address 5, and the secondary address will map directly into my routine for that command. Ex GPIB primary address 5, secondary address 19 is the TLIST command and the code will return the list of files in the current microSD card directory.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 10, 2021, 09:35:38 pm
content: If you are ordering a 1284 board,are you also ordering a Pololu microSD with 3.3V regulatorhttps://www.pololu.com/product/2587?You should be able to connect the Pololu microSD to the 1284 board with a breadboard and jumper wires.I can send you one of my 4924 Tape Emulator boards with a GPIB connector already soldered on, but you would need a Tektronix computer to test it with GPIB. I know someone in the UK with a working Tektronix 4052 that could be interested in helping test the tape emulator.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 11, 2021, 06:53:59 am
content: I already have a MicroSD card reader here. Its not Pololu branded, but so shouldn't need to order one. It just hooks up to the SPI connector (MOSI, MISO, CLK) and has the neccessary 3.3V regulator and level shifter onboard. For project purposes plan to connect it with Duupont jumper wires as you suggest.One of your emulator boards might be useful as that will make it easier for me to connect up to the GPIB bus, which would otherwise require 16+ jumper wires.I can probably emulate some commands at a basic level by using a terminal and a test fixture script but that is probably all I can hope to achieve without owning a Tek 4052. There are also a couple of simulators available which may be worth trying out. At this stage its not too important but I would like to be able to test at least at some rudimentary level the responses to primary/secondary addressing over GPIB.BTW, I think that perhaps we might remove the BlueTooth unit for now? Also, thinking about it, if the config will be hard coded (in the Config.h file) then do we really need to use EEPROM? I don't know whether you plan to support it, but I think it would be best to remove all unnecessary code.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 11, 2021, 12:09:04 pm
content: I agree with removing Bluetooth support as the Pandauino boards have no network capability.Yes, any microSD adapter with 5V to 3.3V level shifters should work fine.Here is my Tektronix 4924 Tape Emulator adapter board schematic.I used the same connector as on artag's AR-488 board, but removed the mounting holes from the GPIB connector model, and created a 644-Narrow model and microSD connector model.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 11, 2021, 12:10:33 pm
content: Schematic wasn't very readable - I posted the schematic and gerber PCB files on AR488-Store.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 11, 2021, 02:17:37 pm
content: Thank you. The image shows the 328PB version but I presume there is now a 644 version?I will remove Bluetooth as well as Verbose mode since if there is to be no serial comms then that will be superfluous. I have moved GPIB interface parameter configuration to Config.h so am now going to start removing ++ commands that set interface parameters.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 11, 2021, 03:09:23 pm
content: I'm not sure what 328PB image you are referring to - here is a better photo of my Tektronix 4924 Tape Emulator with the ATMEGA644PA CPU on the 644-Narrow Pandauino board, Pololu MicroSD adapter and GPIB connector:

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 11, 2021, 05:44:03 pm
content: Sorry, it seems I got mixed up with the files and looked at an older version of the emulator. Thank you for the drawing and the photo. Both will be very helpful and should help me wire it up properly.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 15, 2021, 09:32:03 am
content: Quote from: mmcgraw74 on June 09, 2021, 01:45:57 pmMonty, I am struggling to reconcile the layout definition above with the attached circuit diagram as the connected pin numbers seem different? I had assumed that pin numbers/names on the inside of the 644-Narrow box represented the pin markings on the Panduino Narrow board, but I don't see A0-A7 so I am guessing these are referred to as pins 24-31?. I can only presume that since you successfully connected up and were able to communicate with your HP data acquisition box, that the definition above is the one to follow but could you please clarify?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 15, 2021, 12:37:09 pm
content: Quote from: mmcgraw74 on April 09, 2021, 02:01:17 pmWaveyDipole,You are correct, thanks for finding my error - the pinout above in my post from April 9 is the correct pinout with my new Tektronix 4924 Emulator PCB.I got a replacement laptop in early May, reinstalled Arduino and picked an earlier file with the AR-488 PCB to continue work on the emulator. I didn't do any more live GPIB testing with EZGPIB or I would have caught my mistake.I have updated all the config.h files on AR488-Store master except for your main AR488-Store files.The new custom pinout matches the schematic I posted for the new PCB and this view of the gerber files for my new Tektronix 4924 Emulator PCB with Panaduino 644-Narrow, GPIB connector and Pololu microSD adapter pinouts:I have attached the Pandauino pinout diagram again. Yes, the Pandauino Arduino pins are all numbers in my config.h file, although I'll bet the Port names could also be used. Note the +5V and GND at the bottom of the pinout diagram are on the ISCP header, not the corner pins of the Pandauino!

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 17, 2021, 06:34:25 am
content: That's great and very helpful. Thanks.The 1284 IC arrived yesterday and I am hoping to give it a test today. In the meantime, your adapter is showing as being at 'Sorting Centre, Chicago, Cook County, Illinois, United States' as of the 16th June. No update for today yet, but its evidently on its way. In the meantime, I will hopefully be able to hook it up with some Dupont wires to the breadboard.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 19, 2021, 01:46:13 pm
content: Since the Pandauino board includes the ISCP header installed, I found the easiest way to solder the ISCP header pins to my GPIB adapter was to remove the plastic spacer from the ISCP header and heat one ISCP pin at a time from the top of the board and push it down a bit. You only want the ISCP pins to barely penetrate the GPIB adapter PCB to make it easier to get the soldering iron under the GPIB connector.The three photos in this post are closeup views of the ISCP to GPIB connections.You also need a tall header to connect the Pololu MicroSD adapter to the GPIB adapter PCB.I put the ISCP plastic spacer back on top of the now shorter pins - the pins may need to be trimmed slightly so they won't touch the microSD adapter PCB. The ISCP plastic spacer now gives a little mechanical support to the overhanging microSD adapter PCB.I also trimmed the rest of the Pandauino board pins after soldering them to the GPIB adapter PCB to prevent them touching the metal shell of the GPIB connector.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 19, 2021, 07:41:34 pm
content: Monty,Your adapter arrived today. Thank you. At present, it seems I can't buy a Panduino board anywhere so I will continue using the development board that I dug out of my box of bits for now. I have connected it up to my setup on the breadboard using Dupont wires and based on your layout have created a pre-defined layout definition for the 644P/1248P. I have successfully connected it up with and read data from my Solarton DMM. I also upgraded the crystal on the development board from 8Mhz to 20Mhz so the 1284P running is running at full speed. It definitely feels snappier than using an Uno or Nano!This week I have spent quite a lot of time working on the AR488-Store code but there is still a little more work to do before I am ready to upload an update to the Github. If you could give me a pointer to the latest versions of your Tek 4924 functions, that would be appreciated. In the meantime, I will be hooking up the SD card reader and getting the contents of Tek4924sd.zip onto an SD card. One slight problem I have at the moment is that I am using the SPI port header for the programming cable but it ought to be possible to connect the SD card reader directly to pins on port B so I will be exploring that option.I think I will save your adapter for when I can get hold of a Panduino and then assemble as you have indicated. Thank you for the photos and clear instructions.Regards.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 19, 2021, 08:55:38 pm
content: WaveyDipole,Sorry, I thought you had a 1284-Narrow board. Thehttps://pandauino.com/en/buy/indicates European users can by directly. Otherwise, I can buy one and ship it to you.My latest code is in this folder:https://github.com/Twilight-Logic/AR488_Store/tree/Monty1/src/AR488-644-TLIST-continuedDev

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 20, 2021, 09:08:10 am
content: Quote from: mmcgraw74 on June 19, 2021, 08:55:38 pmThat's great. Thanks. Funny that panduino.com doesn't come up in a Google search on the term 'panduino'. You would think it would be one of the first entries in the search results. Seems I can't do anything on that site without registering - not even view the cart! I did register and eventually got the confirmation e-mail but it contained a password in clear text - which I immediately changed! The site does not inspire confidence and I feel rather hesitant to buy from them at the moment. I only wanted to see what the total cost was including shipping. I didn't realise the Panduino was that expensive either. It hardly seems to compete with the Nano or Micro Pro and even the Mega 2560 can be had for less. It seems I can buy from Mouser but the shipping cost is 16.50$ with likely import duty to be added on top of that. Seems there is a significant factory lead time as well. Still its an option to consider eventually, but to avoid delay in development I will use what I have available for now.Quote from: mmcgraw74 on June 19, 2021, 08:55:38 pmThat's what I thought. Just wanted to confirm. I presume the contents of Tek4924sd.zip go directly into the root of the SD card? That's where I have put them for now.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 20, 2021, 12:45:44 pm
content: You had a typo in your search. Search forPandauinoor 644-Narrow or 1284-Narrow.Yes, this board is new and was in a crowdsource a couple of years ago.ATMEL got interested and their Crowd Supply branch is the one manufacturing the board and has Mouser as their distributor.Mouser shows 63 1284-Narrow in stock. I can order one and ship to you, but the shipping fee they have sounds better than mine. They have a Mouser in Hungary that is likely the one you would use.Yes, unzip the contents to the root of the microSD card formatted as FAT32. There will be three folders, and my code defaults to open the \root\ folder.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 20, 2021, 03:22:14 pm
content: Ah, so that was it! My eyes somehow missed the 'a'. Thank you for pointing it out.When I checked Mouser from here it showed a 8-week lead time on the 644 Narrow and an 18-week lead time on the 1284 Narrow! Now that I am registered at the Pandauino.com website, I can properly see the cart and after putting in my address details I can get the shipping cost. Despite the initial indication of €4.95, it turns out that it isn't any cheaper than Mouser unfortunately. In total it works out at around 50$ regardless and that is before any import duties. I am wondering whether it would be cheaper to design my own board.Incidentally, do you mind if I use your circuit diagram in my documentation?I have now connected and tested the SD card reader. It can co-exist with the programmer but does change the reported device signature so it is necessary to unplug the power lead from the SD card reader before programming. The example "Cardinfo" sketch was uploaded successfully and reads the contents of the SD card just fine even with the programmer connected. I used CS pin 3 rather than the default of 4. My initial reasoning was to avoid a clash, but on closer inspection it appears that the programmer does not use a CS pin at all. I am guessing that it takes the role of the master and assumes the Arduino to be the only slave device on the SPI bus.In any case, I am now in a position to be able to move on to working on the device mode parts of the sketch in earnest and adding your routines in, health issues permitting.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 20, 2021, 05:30:12 pm
content: I don't mind you using my circuit diagram in your documentation.Like I said, I see stock of 63 1284-Narrow at Mouser US, so I could get one and ship it to you much quicker than making your own boardMonty

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 28, 2021, 10:22:53 am
content: I have uploaded my current work on AR488-Store. The code has been substantially re-written and all of the GPIB functions are now in the GPIB-device class. Bluetooth and Eeprom functions have been removed. There will still be a number of warnings, but there should be no errors.I have added one of your functions (TLIST) into AR488_Store_Tek. I can only test using a terminal program, but it seems to work when the entire command sequence is sent together using cut and paste. When typing them one at a time manually, the delay between commands seems to cause some of the text to be omitted or EOI gets detected before any text appears in the terminal. I don't have a Tek 4050 to test this on though. You will see that only minor changes were needed to your original function, for example, setting the GPIB bus to the correct state before and after the function is executed as well as directing the output to GPIB rather than to serial. I left the original lines in place but commented out so you can see what I have done. The output is streamed in the original fashion using ArduinoOutStream into an 82 character line buffer (80 chars + CR + LF) - this is assuming an 80 character display width. The buffer is then passed to the GPIB bus function that sends its contents across the GPIB bus.Assuming that this actually works on the 4050, then we can start to add in other commands.There is still a bit of tidying up to do but this should now compile and hopefully run that one test command.BTW, are all of your functions in TLIST-continuedDev now complete or still in development?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 28, 2021, 12:32:42 pm
content: Great progress.I'll test your new code on my Tektronix 4052 and report back!I have not changed continuedDev in a couple of weeks.I was waiting to test the new GPIB Store code before more work.Monty

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 28, 2021, 09:17:51 pm
content: Hmm, I tried to compile your new version and the 2nd include statement errors with No such file or directory:AR488_GPIBdevice.hCode:Arduino: 1.8.15 (Windows 10), Board: "ATmega644, Yes (UART0), EEPROM retained, Standard pinout, 644P / 644PA, BOD 2.7V, Disabled, External 16 MHz"AR488_Store:13:10: fatal error: AR488_GPIBdevice.h: No such file or directory#include "AR488_GPIBdevice.h"^~~~~~~~~~~~~~~~~~~~compilation terminated.exit status 1AR488_GPIBdevice.h: No such file or directoryThis report would have more information with"Show verbose output during compilation"option enabled in File -> Preferences.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 29, 2021, 07:32:32 am
content: My apologies. It seems that although two of the files (AR488_GPIBdevice.h and AR488_GPIBdevice.cpp) were present in my local directory, they had not been added to the repository with 'git add' and so they were not uploaded when I did a 'git push'. They have now been added so all files should be present and correct and you should be able to download the missing files from the repository.Incidentally, I wasn't sure which secondary address to assign to the TLIST command. According to the information here:https://github.com/mmcgraw74/Tektronix-4050-GPIB-Flash-Drivethe TLIST command is assigned to secondary address 115 (decimal) or 73 (hex). On the other hand, the .ino file here:https://github.com/mmcgraw74/Tektronix-4050-GPIB-Flash-Drive/blob/master/Tek-GPIB-Tape-Emulator%20command%20template.inoshows it assigned to secondary address 105 (decimal) 69 (hex) which according to the above is assigned to the DIRECTORY command. I imagined that DIRECTORY might correspond to your CD function but couldn't be sure. For testing purposes I have assigned TLIST to secondary address 115 for now and this is the address you will have to send, but it can easily be changed to 105 if required.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 29, 2021, 01:55:00 pm
content: I had to change the SD card CS pin to 4 to work with my board.Compile was successful with no errors - but a warning that we were at 80% of RAM:Sketch uses 24918 bytes (38%) of program storage space. Maximum is 64512 bytes.Global variables use 3309 bytes (80%) of dynamic memory, leaving 787 bytes for local variables. Maximum is 4096 bytes.Low memory available, stability problems may occur.I plugged the 4924 Tape Emulator into my Tektronix 4052 and typed:TLIST @5:The system reported this error message:MAG TAPE CARTRIDGE REQUIRED IN IMMEDIATE LINE - MESSAGE NUMBER 57Actually this may be progress, but likely the system needs the Tape Emulator to report status or some other command that I haven't coded yet.For example, the 4924 Operators Manual Table 2-3 shows 4924 Error Messages with error 7 "No Cartridge Inserted"I don't think the 4050 is making that call, since when I try it as a BASIC command: INPUT @5,30:A the system hangs.The system doesn't hang on the TLIST @5: command, so it is figuring there is no cartridge some other way.Does your code provide debug messages to serial port - such as Secondary Address received for Primary Address 5?I could use that to discover what command the system is sending to the tape emulator.Otherwise I will have to get my logic analyzer hooked up to the GPIB bus to look at the transfers.The Secondary Address for "STATUS" is 0 according to the 4924 Tape Drive Service Manual Table 1-2 on page 1-6.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 29, 2021, 06:33:48 pm
content: Yes, there is a debug option which sends to the default Serial port. In AR488_Config.h uncomment at least://#define DEBUG_STOREI think I may have left it un-commented already. This should show the HEX code for the secondary address being received. Un-commenting the following will show a bit more information://#define DEBUG_STORE_COMMANDSBy default the output will go to Serial. This can be changed in the 'Debug Port' section after #define DB_SERIAL_ENABLE. The line '#define DB_SERIAL_ENABLE' should already be un-commented, although under normal running it should be commented out.You are probably correct that the tape drive would need to return the correct status showing online and ready first. That would make sense. That shouldn't be difficult. I will have a look at the documentation. There are no tapes so theoretically the system should always be online unless the SD card doesn't mount. The problem is that at present the Arduino will crash if the SD card is not present. For testing purposes it might be sufficient to just send an OK code but in the long run it might be better to find a way to handle and escape any SD load failure and return a suitable error status.You are right that with the 644 the system reports 81% of dynamic memory used. On the 1284 it reports 20%.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 30, 2021, 08:11:48 am
content: Thank you for the detailed output. This is really helpful. I obviously need to have a look at why both NDAC and NRFD are ending up inactive when the TLIST function is executed.The list in the output corresponds to addresses that have a function implemented, most of which are just empty functions with the exception of TLIST. Those 'not found' do not yet exist in the array that lists the implemented functions, so they are 'not found'. The list of secondary addresses should correspond to those functions mentioned in your example .ino file.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 30, 2021, 12:35:40 pm
content: How about the printing of all the commands received on each debug output line? Is that from both debug statements being enabled and I only need to enable one at a time?I'm going to look at the transactions following the receipt of the TLIST command to see what else the system is sending - or possibly it is what else the TLIST program is sending?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 30, 2021, 01:38:12 pm
content: Here is my decode of the GPIB states.I also added the missing columns of ADDR (same as DATA for GPIB) and the REN and EOI signals.The Tektronix 4924 Service Manual indicates the system will assert EOI at the end of a transaction (with the CR in the case of my test program).The error reported by the system might be due to the code trying to react to the TLIST, while the system is trying to send the PRINT command to Secondary Address 116?Particularly since the system did not send the CR on this PRINT command to sec addr 116 transaction (my PRINT statement has no data so the system just sends a CR according to the 4924 Service Manual page B-13 table for the PRINT command).Code:HPIB STATE - State ListingLabel > ADDR STAT DATA Time ATN SRQ IFC NDAC NFRD DAV REN EOIBase > Hex Hex Hex Relative Bin Bin Bin Bina Bina Bin Bin Bin__________ ____ ____ ____ _________ ___ ___ ___ ____ ____ ___ ___ ___-70 8D 8C 8D 137.6 us 0 0 1 1 0 0 0 1Sec Addr (72H) 114 decimal-69 8D AC 8D 40.41 us 0 0 1 1 0 1 0 1-68 8D A4 8D 504 ns 0 0 1 0 0 1 0 1-67 8D A5 8D 18.79 us 1 0 1 0 0 1 0 1-66 8D AD 8D 456 ns 1 0 1 1 0 1 0 1-65 8D 2D 8D 26.66 us 1 0 1 1 0 1 0 0-64 80 2D 80 27.71 us 1 0 1 1 0 1 0 0-63 A0 2D A0 104 ns 1 0 1 1 0 1 0 0-62 E0 2D E0 8 ns 1 0 1 1 0 1 0 0-61 E0 2D E0 8 ns 1 0 1 1 0 1 0 0-60 F0 2D F0 8 ns 1 0 1 1 0 1 0 0-59 F0 2D F0 8 ns 1 0 1 1 0 1 0 0-58 F2 2D F2 8 ns 1 0 1 1 0 1 0 0-57 F2 25 F2 33.17 us 1 0 1 0 0 1 0 0-56 F2 35 F2 3.600 ms 1 0 1 0 1 1 0 0-55 F2 35 F2 8 ns 1 0 1 0 1 1 0 0-54 F2 3D F2 8 ns 1 0 1 1 1 1 0 0-53 F2 1D F2 37.58 us 1 0 1 1 1 0 0 0CR (0D)-52 F2 3D F2 38.68 us 1 0 1 1 1 1 0 0-51 F2 BD F2 21.95 us 1 0 1 1 1 1 0 1-50 F2 BC F2 56.97 us 0 0 1 1 1 1 0 1-49 F2 A4 F2 528 ns 0 0 1 0 0 1 0 1-48 F2 B4 F2 416 ns 0 0 1 0 1 1 0 1-47 F2 BC F2 18.37 us 0 0 1 1 1 1 0 1-46 F2 B4 F2 8 ns 0 0 1 0 1 1 0 1-45 F2 B4 F2 8 ns 0 0 1 0 1 1 0 1-44 F2 BC F2 8 ns 0 0 1 1 1 1 0 1-43 F2 B4 F2 8 ns 0 0 1 0 1 1 0 1-42 F2 A4 F2 9.864 us 0 0 1 0 0 1 0 1-41 F2 B4 F2 23.51 us 0 0 1 0 1 1 0 1-40 A0 B4 A0 32.61 us 0 0 1 0 1 1 0 1-39 A0 94 A0 38.58 us 0 0 1 0 1 0 0 1UNTALK (5F)-38 A0 84 A0 800 ns 0 0 1 0 0 0 0 1-37 A0 8C A0 93.54 us 0 0 1 1 0 0 0 1-36 A0 AC A0 28.65 us 0 0 1 1 0 1 0 1-35 A0 A4 A0 472 ns 0 0 1 0 0 1 0 1-34 80 A4 80 27.14 us 0 0 1 0 0 1 0 1-33 C0 A4 C0 136 ns 0 0 1 0 0 1 0 1-32 C0 B4 C0 124.3 us 0 0 1 0 1 1 0 1-31 C0 94 C0 27.28 us 0 0 1 0 1 0 0 1UNLISTEN (3F)-30 C0 84 C0 480 ns 0 0 1 0 0 0 0 1-29 C0 8C C0 137.8 us 0 0 1 1 0 0 0 1-28 C0 AC C0 41.30 us 0 0 1 1 0 1 0 1-27 C0 A4 C0 432 ns 0 0 1 0 0 1 0 1-26 FF A4 FF 34.70 us 0 0 1 0 0 1 0 1-25 FF A5 FF 27.27 us 1 0 1 0 0 1 0 1-24 FF AD FF 496 ns 1 0 1 1 0 1 0 1-23 FF A5 FF 24 ns 1 0 1 0 0 1 0 1-22 FF A4 FF 2.625 ms 0 0 1 0 0 1 0 1-21 C0 A4 C0 28.82 us 0 0 1 0 0 1 0 1-20 C0 F4 C0 8 ns 0 0 1 0 1 1 1 1-19 C0 A4 C0 8 ns 0 0 1 0 0 1 0 1-18 C0 B4 C0 112 ns 0 0 1 0 1 1 0 1-17 C0 BC C0 1.992 us 0 0 1 1 1 1 0 1-16 C0 B4 C0 8 ns 0 0 1 0 1 1 0 1-15 C0 B4 C0 8 ns 0 0 1 0 1 1 0 1-14 C0 BC C0 8 ns 0 0 1 1 1 1 0 1-13 C0 B4 C0 8 ns 0 0 1 0 1 1 0 1-12 C0 A4 C0 9.864 us 0 0 1 0 0 1 0 1-11 C0 B4 C0 23.51 us 0 0 1 0 1 1 0 1-10 C8 B4 C8 24.24 us 0 0 1 0 1 1 0 1-9 DA B4 DA 8 ns 0 0 1 0 1 1 0 1-8 DA 94 DA 38.49 us 0 0 1 0 1 0 0 1Primary Addr (35H) Device 5 Listen Addr-7 DA 84 DA 368 ns 0 0 1 0 0 0 0 1-6 DA 8C DA 102.4 us 0 0 1 1 0 0 0 1-5 DA AC DA 19.66 us 0 0 1 1 0 1 0 1-4 DA A4 DA 400 ns 0 0 1 0 0 1 0 1-3 88 A4 88 30.91 us 0 0 1 0 0 1 0 1-2 8C A4 8C 144 ns 0 0 1 0 0 1 0 1-1 8C B4 8C 122.5 us 0 0 1 0 1 1 0 10 8C 94 8C 28.02 us 0 0 1 0 1 0 0 1Sec Addr (73H) 115 decimal = TLIST1 8C 84 8C 432 ns 0 0 1 0 0 0 0 12 8C 8C 8C 137.1 us 0 0 1 1 0 0 0 13 8C AC 8C 14.29 us 0 0 1 1 0 1 0 14 8C A4 8C 376 ns 0 0 1 0 0 1 0 15 8C A5 8C 18.92 us 1 0 1 0 0 1 0 16 8C AD 8C 496 ns 1 0 1 1 0 1 0 17 8C 2D 8C 26.62 us 1 0 1 1 0 1 0 08 80 2D 80 28.77 us 1 0 1 1 0 1 0 09 A0 2D A0 80 ns 1 0 1 1 0 1 0 010 A0 2D A0 8 ns 1 0 1 1 0 1 0 011 E0 2D E0 8 ns 1 0 1 1 0 1 0 012 E0 2D E0 8 ns 1 0 1 1 0 1 0 013 F0 2D F0 8 ns 1 0 1 1 0 1 0 014 F2 2D F2 24 ns 1 0 1 1 0 1 0 015 F2 25 F2 59.75 us 1 0 1 0 0 1 0 016 F2 35 F2 4.007 ms 1 0 1 0 1 1 0 017 F2 35 F2 8 ns 1 0 1 0 1 1 0 018 F2 3D F2 8 ns 1 0 1 1 1 1 0 019 F2 1D F2 24.94 us 1 0 1 1 1 0 0 0CR (0D)20 F2 3D F2 39.10 us 1 0 1 1 1 1 0 021 F2 BD F2 22.05 us 1 0 1 1 1 1 0 122 F2 BC F2 56.44 us 0 0 1 1 1 1 0 123 F2 A4 F2 624 ns 0 0 1 0 0 1 0 124 F2 B4 F2 424 ns 0 0 1 0 1 1 0 125 A0 B4 A0 85.34 us 0 0 1 0 1 1 0 126 A0 94 A0 38.06 us 0 0 1 0 1 0 0 1UNTALK (5F)27 A0 84 A0 328 ns 0 0 1 0 0 0 0 128 A0 8C A0 1.120 us 0 0 1 1 0 0 0 129 A0 AC A0 37.65 us 0 0 1 1 0 1 0 130 A0 A4 A0 456 ns 0 0 1 0 0 1 0 131 A0 B4 A0 264 ns 0 0 1 0 1 1 0 132 80 B4 80 26.46 us 0 0 1 0 1 1 0 133 C0 B4 C0 136 ns 0 0 1 0 1 1 0 134 C0 94 C0 37.93 us 0 0 1 0 1 0 0 1UNLISTEN (3F)35 C0 84 C0 200 ns 0 0 1 0 0 0 0 136 C0 8C C0 1.112 us 0 0 1 1 0 0 0 137 C0 AC C0 37.78 us 0 0 1 1 0 1 0 138 C0 A4 C0 496 ns 0 0 1 0 0 1 0 139 C0 B4 C0 424 ns 0 0 1 0 1 1 0 140 C0 A4 C0 34.24 us 0 0 1 0 0 1 0 141 C6 A4 C6 64 ns 0 0 1 0 0 1 0 142 FF A4 FF 8 ns 0 0 1 0 0 1 0 143 FF A5 FF 27.26 us 1 0 1 0 0 1 0 144 FF A4 FF 2.625 ms 0 0 1 0 0 1 0 145 C0 A4 C0 28.82 us 0 0 1 0 0 1 0 146 C0 F4 C0 8 ns 0 0 1 0 1 1 1 147 C0 A4 C0 8 ns 0 0 1 0 0 1 0 148 C0 B4 C0 112 ns 0 0 1 0 1 1 0 149 C8 B4 C8 59.64 us 0 0 1 0 1 1 0 150 DA B4 DA 8 ns 0 0 1 0 1 1 0 151 DA 94 DA 38.50 us 0 0 1 0 1 0 0 1Primary Addr (35H) Device 5 Listen Addr52 DA 84 DA 488 ns 0 0 1 0 0 0 0 153 DA 8C DA 1.112 us 0 0 1 1 0 0 0 154 DA AC DA 36.97 us 0 0 1 1 0 1 0 155 DA A4 DA 480 ns 0 0 1 0 0 1 0 156 DA B4 DA 424 ns 0 0 1 0 1 1 0 157 8A B4 8A 30.50 us 0 0 1 0 1 1 0 158 8B B4 8B 128 ns 0 0 1 0 1 1 0 159 8B 94 8B 38.46 us 0 0 1 0 1 0 0 1Sec Addr (74H) 116 decimal60 8B 84 8B 296 ns 0 0 1 0 0 0 0 161 8B 8C 8B 1.112 us 0 0 1 1 0 0 0 162 8B AC 8B 36.63 us 0 0 1 1 0 1 0 163 8B A4 8B 480 ns 0 0 1 0 0 1 0 164 8B B4 8B 264 ns 0 0 1 0 1 1 0 165 8B B5 8B 18.66 us 1 0 1 0 1 1 0 166 8B BD 8B 640 ns 1 0 1 1 1 1 0 167 8B 3D 8B 27.53 us 1 0 1 1 1 1 0 068 8B BD 8B 46.35 us 1 0 1 1 1 1 0 169 8B BC 8B 56.44 us 0 0 1 1 1 1 0 170 8B A4 8B 696 ns 0 0 1 0 0 1 0 171 8B B4 8B 264 ns 0 0 1 0 1 1 0 172 80 B4 80 84.37 us 0 0 1 0 1 1 0 173 A0 B4 A0 128 ns 0 0 1 0 1 1 0 174 A0 94 A0 38.46 us 0 0 1 0 1 0 0 1UNTALK (5F)75 A0 84 A0 440 ns 0 0 1 0 0 0 0 176 A0 8C A0 1.112 us 0 0 1 1 0 0 0 177 A0 AC A0 37.02 us 0 0 1 1 0 1 0 178 A0 A4 A0 432 ns 0 0 1 0 0 1 0 179 A0 B4 A0 424 ns 0 0 1 0 1 1 0 180 80 B4 80 25.80 us 0 0 1 0 1 1 0 181 C0 B4 C0 136 ns 0 0 1 0 1 1 0 182 C0 94 C0 37.92 us 0 0 1 0 1 0 0 1UNLISTEN (3F)83 C0 84 C0 368 ns 0 0 1 0 0 0 0 184 C0 8C C0 1.120 us 0 0 1 1 0 0 0 185 C0 AC C0 37.61 us 0 0 1 1 0 1 0 186 C0 A4 C0 336 ns 0 0 1 0 0 1 0 187 C0 B4 C0 416 ns 0 0 1 0 1 1 0 188 C0 A4 C0 34.41 us 0 0 1 0 0 1 0 189 C2 A4 C2 64 ns 0 0 1 0 0 1 0 190 DF A4 DF 8 ns 0 0 1 0 0 1 0 191 FF A4 FF 8 ns 0 0 1 0 0 1 0 192 FF A5 FF 27.26 us 1 0 1 0 0 1 0 193 FF F5 FF 115.1 ms 1 0 1 0 1 1 1 194 FF F5 FF 8 ns 1 0 1 0 1 1 1 195 FF FD FF 8 ns 1 0 1 1 1 1 1 196 DF FD DF 42.09 us 1 0 1 1 1 1 1 197 DF DD DF 8.768 us 1 0 1 1 1 0 1 198 DF FD DF 5.004 s 1 0 1 1 1 1 1 199 FF FD FF 3.312 us 1 0 1 1 1 1 1 1Time Printed: 30 Jun 2021 08:05:59

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: June 30, 2021, 07:25:11 pm
content: Quote from: mmcgraw74 on June 30, 2021, 12:35:40 pmThe output you are seeing is from two debug levels. The first one (#define DEBUG_STORE) is at a general level for the module and is showing the command processor looping through the command addresses and stopping at the one it finds - hence the lengthening list of numbers as you progress through the commands. If it doesn't find a command handler in the list (i.e. because we have not implemented it yet) it will print 'not found'. If it does, then it will print "Executing secondary address command: xx".The second (#define DEBUG_STORE_COMMANDS) shows messages from within the actual command function. As each command function is added, messages from other commands will appear on separate lines. From your output, we have addressed the emulator and the command 115 has started the TLIST handler, but it didn't complete the function as we didn't get an "End TLIST handler" message.The string of numbers was helpful to me at the time but it does look confusing. All that is actually needed is to determine whether the secondary address command was received and whether a handler was found and executed or not.Your surmise regarding the next PRINT command is probably correct. The response to the TLIST command is to output some data, i.e. a list of file headers as documented:TLIST 9 (MTA 69)(MSA 105)(Header)(UNT)After sending 105 [hex 73] The computer would need to listen  the '(header)' response before sending UNT. Quite how that works with the 4050 - whether it happens automatically or whether the BASIC program needs to read the response into a variable (or file) - I am uncertain.Sending the next PRINT command while the emulator is in send mode would confuse things since both devices would now be in send mode at the same time. Since the sender sets DAV and the recipient the NDAV/NRFD signals, you would have a situation where both computer and emulator are trying to send and waiting for NDAC/NRFD, but neither is in the correct mode to assert them. That might explain error 69.I would like to determine two things:1. whether both computer and tape drive send EOI or just one of them (i.e. the tape drive)2. whether the status code is sent as a single byte or as ASCII outputIn the meantime, I investigated a bit further and noticed that your function had a 'return' in the section starting:Code:if ((f_name == 'L') && (filenumber == number)) {At that point I realised that the function would have been exiting here without an 'End TLIST handler' message. This also explained a puzzle I had been trying to figure out as to why I was getting no EOI signal on my LA trace!I have modified the function slightly, replacing the 'for' loop with a 'while' loop and taking advantage of the boolean nature of the 'file.openNext' method which returns 'true' so long as there is a next file to open and returns 'false' when there are no more files to process, to iterate over the directory. Your original 99 file limit was also retained. Program execution now drops out of both loops as soon as the 'lastfile' flag is set, whereupon everything is closed off, an EOI signal is sent, and the GPIB bus set to an appropriate state before finishing the function. Both loops still drop out immediately the last file is reached and termination code does not need to be duplicated in two places. To be fair, 'return' is still going to be faster as there would be no need to re-evaluate the conditions for the inner and outer loop.I have also cleaned up the debug output a bit. Hopefully it is now a bit clearer.I have added an ERROR function as well as had an attempt at the FIND command. When I tested ERROR it returned a blank instead of '0'. I am uncertain whether the data is meant to be returned as a byte or an ASCII character, hence my earlier question and possible need for adjustment. I will have a further dig around the documentation. I have not yet made any attempt to test FIND.I spotted this line which may need to be re-worked:Code:if (!dirFile.open(directory, O_RDONLY)) {sd.errorHalt("Open directory failed - possible invalid directory name");}Not sure, but I think it may send to the default serial port which might not be available. Maybe the if statement could be used to set an error code instead?The updated files have been uploaded to the GitHub repository.The output below is from my PuTTy session on the PC (ignore the GPIBbus debug messages):Code:> ++mode 1Interface mode set to: CONTROLLER> ++addr 5Set device primary address to: 5> ++mtaGPIBbus::sendMTA: address device: 5GPIBbus::sendMTA: cstate: 1GPIBbus::sendMTA: cstate: 3addressDevice: 5> ++msa 115> ++read eoi1 ASCII PROG [Root Menu] 42 ASCII DATA [DIR LIST] 43 NEW 34 NEW 35 LAST 3> ++untGPIBbus::sendMTA: cstate: 2>As you can see, I successfully received your file header list sent by the TLIST function. One assumes the same output would be forthcoming on the 4050.Debug output on emulator:Code:Executing secondary address command: 73Started TLIST handler...Reached last file.End TLIST handler.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: June 30, 2021, 07:42:51 pm
content: Quote from: WaveyDipole on June 30, 2021, 07:25:11 pmThe sderror line was in the example program I found.I'll download the new code with your latest changes and test it again - this time just trying to test the TLIST command.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 01, 2021, 01:32:49 pm
content: Here is a small python3 program to reverse the hex characters in the output:Code:#!/usr/bin/python3import sysinfilepath = ""outfilepath = ""linecount = 0origline = ""modline = ""hexcode = ""flag = 0def convertHex(codestr):codeval = int(codestr,16)codeval = 255 - codevalnewcode = "{:02X}".format(codeval)return newcodeif len(sys.argv) == 2:infilepath = sys.argvif len(sys.argv) == 3:infilepath = sys.argvoutfilepath = sys.argvif (infilepath == ""):infilepath = input("Filename: ")if (outfilepath != "" ):cnvfile = open (outfilepath, 'w')with open(infilepath) as lafile:origline = lafile.readline()while origline:linecount += 1if (linecount>7 and flag == 0):modline = origline[0:13]hexcode = origline[13:15]if (hexcode):modline = modline + convertHex(hexcode) + " "hexcode = origline[18:20]modline = modline + convertHex(hexcode) + " "hexcode = origline[23:26]modline = modline + convertHex(hexcode) + " "modline = modline + origline[26:]if (outfilepath != ""):cnvfile.write(modline)else:print(modline, end='')else:flag = 1if (outfilepath != ""):cnvfile.write(origline)else:print(origline, end='')else:if (outfilepath != ""):cnvfile.write(origline)else:print(origline, end='')origline = lafile.readline()lafile.close()if (outfilepath != ""):cnvfile.close()I figured taking a few minutes to write the program would be more useful than working through the output manually and decoding each byte by hand! I am not sure what LA you are using but I did wonder though whether it has an option to set the polarity of the capture (i.e. to pulse going low rather than high). What logic analyzer are you using BTW?UPDATE: program updated to take an input and output file parameter. Called without filename parameters it will prompt for an input filename. Called with only the input filename as a parameter it will output to screen.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 01, 2021, 01:45:11 pm
content: I'm using an HP16500B logic analyzer.I'll check on inverting the data

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 01, 2021, 05:32:04 pm
content: Section 3-7 of the 16500B manual covers "Assigning Edge Triggers". It might be that one of the options to select the down or falling edge might be the one to choose, but I am not sure. One the other hand if the machine 'knows' that it is decoding the GPIB protocol, then it ought to be able to determine that a low going pulse is the correct direction to signal that a bit is 'on'.That 16500B seems to have a very minimalistic design but from the manual I can see that it is rather sophisticated and can be programmed for various tasks. There's a HP16500A on eBay UK for what might be considered a reasonable UK price. Better price, in fact, than a Hantek 4032 that I was thinking of getting, although obviously a lot bigger. Seems to have a 50MHz anf 35MHz card in the back and comes with cables and pods as well as lots of clips. I would expect that the clips are far better than those cheap far east ones. I can see from your posts that it is possible to export the capture image and data. Are any disks required to start it up? How difficult is it to find the program it? How long a timeframe will it capture for GPIB?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 01, 2021, 05:48:25 pm
content: I didn't find any way to invert the data in the Waveform view or state LIST view.I do have the GPIB inverse assembler hardware - I just couldn't get it to work. I think my problem is the POD numbering changed for the 16500, and the HP Inverse assembler supports the earlier 1650 or 16510.I also have a 1650 and can hook up GPIB to it - it doesn't support network or floppy. I am using the floppy drive in my 16500B to save the Waveform screen print and state listings, and have a USB floppy to transfer the files to my PC. I think one reason I haven't done this is I don't have the GPIB inverse assembler files available on the HP-IB tape to use with the 1650.I upgraded my 16500B from hard disk to SSD based on info on this site:https://www.philpem.me.uk/elec/testgear/hp16500b/startWithout the hard disk, you do need floppy disk with the system files to boot the logic analyzer. Then the boot floppy can be removed and you can use the floppy to save or load files. Obviously the hard disk is much faster and you can save setups to the hard disk easier.The HP GPIB Inverse Assembler program does properly invert the address and data for GPIB.The 100/500MHz Logic Analyzer plugin supports 4K samples. These can be clocked or transitional. I was capturing in transitional mode which captures on any signal transition and measures the relative time between transitions - so you get longer traces than with a fixed clock. The GPIB inverse assembler disassembles the GPIB state transactions and adds the timing too.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 01, 2021, 06:55:46 pm
content: The unit I was looking at is a 16500A rather than B and has a floppy inserted in the back of it. Not sure whether it has a hard drive. It does apparently have an error with the touch screen interface. I understand these units can be operated with a mouse though?Replacing the hard disk with an SSD seems a good idea. The other thing I thought of was to replace the floppy drive with one of those drop-in replacement SSD card floppy emulators. Do you have the floppy image files by any chance?I am curious when you mention "GPIB inverse assembler hardware". Is this a card that plugs into one of the slots at the back? Its a shame if it not working is down to manufacturing changes in the pod hardware. My program will invert the hex values, but obviously can't provide the additional timing information.I take it then, that the data is saved to floppy during the capture? Or is it captured in memory and the memory dumped (saved) afterwards?Would the 16500A do GPIB "out of the box" or does it need additional hardware/programming? Is the additional hardware required only for inverse GPIB decoding?Does the 16500 scan for modern protocols such as I2C or SPI ?Sorry for all the questions, but I am trying to determine whether a basic unit with ribbon cables, pods and OS floppy purchased off eBay would be of use immediately or whether I would need to hunt around for various bits for it such as floppies, plug-in modules and decoders/programs. Or would I be better off buying a Salaea, DsLogic or Hantek USB connected LA?When I searched for the 100/500MHz Logic Analyzer plugin, I found listings for the HP1661C but that unit is rather more expensive. I would be happy to have a reliable unit that runs at 50MHz for now.BTW, I have just updated the output converter program posted earlier as had I spotted an error in it.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 01, 2021, 09:21:27 pm
content: The 16500A is floppy only, doesn't have the disk controller board.The 16500 mouse is an HP proprietary HP-IL interface, might be hard to find - I don't have one, but my touch screen works.I see that the Keysight link to the 16500B floppy disks that is on the philpem doesn't work anymoreI don't think I would recommend the 16500A.The HP 10324B GPIB/RS-232C/RS-449 BUS Preprocessor module plugs into another module which has pod connectors for HP Logic Analyzers. I finally got it to do something by removing an expansion logic analyzer module, then powering the LA back up and loading the CHPIB_I inverse assembler file for the 16510A. It said I needed to move two of the cables - and when I was done and tried to trigger on a BASIC command that triggered without the 10324B - it only captured one event, and didn't look like it supported secondary GPIB addresses, so I'm back to my direct connection setup.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 01, 2021, 10:11:38 pm
content: On the good news front, I was able to get the TLIST data from the emulator if I used the INPUT @5,19:A$,B$,C$,D$,E$ command as shown in the first photo. This is not a good substitute for the TLIST command as I had to know how many files prior to issuing the command and then assign each file to a different string.Here is the logic analyzer timing diagram showing the burst transfers of each text string from the emulator to BASIC:You can see in the 4052 photo that the TLIST @5: command still didn't work, but I figured out why.The 4924 manual does not show a TLIST command - my badThe 4050 manual indicates TLIST @5: would send the internal tape TLISTto GPIB device 5- not what we wantOn the good news front - that command would work if the system supported a TLIST from a 4924, but that won't happen.I don't see TLIST in any of my recovered programs. It is needed with the tape drive to see what files are on the tape, but my plan with the emulator is to create a MENU program in every folder including the /root/ folder. One way to get something equivalent would be to code the TLIST secondary address command to open a specific file (like FIND 2 would open the file in my root folder) and then use READfile to display the list of files.So, how do I get my FIND, CD, READfile and OLD code enabled on AR488_STORE?The filenumber parameter passed to FIND will be from GPIB from the system as an integer (CR delimited)The directory parameter passed to CD will be from GPIB from the system as a character string (also CR delimited)

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 01, 2021, 11:23:04 pm
content: I just saw your question on FIND yesterday:QuoteThe data passed from the system to the emulator for the FIND command is an ASCII number with a leading space (Tek 4050 BASIC) and followed by a CR delimiter.The directory string for the CD command is ASCII text and does not have any leading space and will also be CR delimited.I want to use the secondary address 9 (decimal 105) for this command. It is not a standard BASIC command, so I can generate this command with PRINT @5,9:"utilities" for example to have the emulator change the current directory to \utilities\.The BASIC FIND @5:12 command will work for example to find file 12 in the current directory.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 02, 2021, 10:04:46 am
content: Quote from: mmcgraw74 on July 01, 2021, 10:11:38 pmThat's interesting. Each string variable appears to accept one line up to the line terminator (CR). I found some information in a PDf file '070-2270-00_4051_GPIB_HW_Supp_Jul81.pdf' sections 4-10 to 4-16 which describes exactly this behaviour of the INPUT command. It reads data into the variable up until a CR character is received. It would seem then, that what is required is to read into a single variable and output a line at a time in a loop until the variable contains a null string "". In other words it seems we would need to iterate over INPUT @5,19:A$ until no further data is forthcomming. The interesting thing is that we have some communication in principle though.Quote from: mmcgraw74 on July 01, 2021, 10:11:38 pmWhat is the OLD command? I see an OLD/APPEND 4/100 (hex 64). Is this the one?READfile I presume is READ 14/110 (hex 72) so that is straightforward.I will get to work on those and they are easily moved to the correct secondary address later if I get it wrong initially.Quote from: mmcgraw74 on July 01, 2021, 11:23:04 pmThank you for the information.BTW, would you like to allow directory names of 8 or 10 characters? The variable 'directory' is defined as being 13 characters long (including /'s and NULL), but in the CD function the comment indicates 8 characters? There may, of course, be a reason why the latter is shorter.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 02, 2021, 12:26:41 pm
content: The OLD command erases the RAM memory and loads a program from a file that was first selected using the tape FIND command.Since the original 4051 only had 8KB of RAM, many of the original programs would use the APPEND command to overlay additional segments to the program that was loaded with the OLD command. Same call to the tape drive as OLD, you need to FIND the file to APPEND and and use the BASIC APPEND command (not OLD) to fetch the overlay. The system BASIC ROM would perform the different action with the data based on the use of OLD or APPEND in the program.I already have the OLD, FIND, CD, and READ_file code working (using serial out) in my continuedDev code that you migrated into AR488_Store. We just need to enable them in AR488_Store and I will test them against the 4052.The table of GPIB Secondary Addresses on page 7-10 of the 4050 BASIC Reference Manual first column is the value that would be used to redirect the BASIC ROM to override the BASIC command and add the secondary address value in the GPIB addressing.The PRINT statement can be use to send any of the GPIB commands in the table that either have no parameters like OLD or parameters like FIND 12. Example: PRINT @5,4: will be identical to OLD @5: and PRINT @5,27:12 is the same as FIND @5:12The INPUT statement can be used to send GPIB commands that return data. Example INPUT @5,0: A.B.C.D will read the STATUS of the 4924 tape drive.Yes, theGPIBDecimal secondary addresses we need for OLD, FIND, CD and READ_file are:OLD 100FIND 123CD 105 (this command is only supported on the floppy & harddisk options to report the directory. In my emulator CD will be used to change the directory with a PRINT command. Example: PRINT @5,9:"utilities" will change the tape emulator directory to \utilities\)Lets use 127 for the Tape Emulator READ_file command (not defined in Tek BASIC)

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 02, 2021, 01:53:38 pm
content: Quote from: mmcgraw74 on July 02, 2021, 12:26:41 pmIf preceding and/or trailing slashes are not added then the program needs to add them?Also are both backslashes '\' and forward slashes '/' to be acceptable?In the function comments it shows forward slashes. I have copied in the CD function but for now have assumed that the slashes will be provided by the user and have not done anything to add them automatically.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 02, 2021, 03:47:27 pm
content: My continuedDev CD code already added the slashes. Maybe not the most elegant way.void tek_CD(char *direct) {// limit the emulator dir name to single level 8 characters PLUS leading and trailing "/" plus NULLchar *param;if (direct != NULL) {param = strtok(direct, " \t");// cout << " \n";// set directory = /param/;strcpy(directory, "/");strcat(directory, param);strcat(directory, "/");cout << F("directory= ") << directory << " \r " << endl;} else {cout << F("Null directory");}f_name = 0; // delete any previous filename that was open}

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 02, 2021, 04:05:25 pm
content: Quote from: WaveyDipole on July 02, 2021, 01:53:38 pmI think I needed forward slashes to work with sdFAT.It will be ok for me to add the slashes to the directory name in the BASIC programs I will be converting to work with the Tape Emulator.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 02, 2021, 05:18:59 pm
content: Its not difficult to add a substitution so that when a '\' is found in the input it automatically gets converted to '/' for compliance with SdFat. This would allow BASIC notation to be used and the conversion happens in the background in the emulator. Also slashes can easily be added when not present as your updated example indicates.I think your idea to have the emulator add the slashes is a good one. The function can just ignore and strip any slashes found in the input, whether forward or back.Can I ask whether the TLIST command is meant to list all files (up to 99) in the currently selected directory, or all files in ALL directories? I am a little confused about the purpose of the first 'for' loop? It seems to be the second (inner) one that does all the work to list files in directory name held in the variable 'directory'.Quote from: mmcgraw74 on July 02, 2021, 12:26:41 pmUnfortunately, 127 is not a valid secondary address. Valid addresses run from 96 - 126 (decimal) or 60 - 7E (hex).UPDATE: just need to add another question. While working on adding the tek_FIND function from your AR488-644-TLIST-continuedDev, I came to the realisation that while the Tek documentation seems to indicate that the function opens a file but does not return anything. Your implementation seems to return a single character for the file type. Should the letter be used to set 'f_type'? or should it be returned via GPIB? It also seems to print other output to serial via 'cout'. Do we need this as output over GPIB or was this just for debug purposes?If output over GPIB is required, then the way the function is called would have to change from:FIND 27 (MLA 37)(MSA 123)(FileNumber+CR)(UNL)to:FIND 27 (MTA 37)(MSA 123)(FileNumber+CR)(UNT)since we now need the emulator to talk and return something.In the event that the file is not found, I see that the function simply sets f_name to NULL in any case.I am rather suspecting that output of any kind is not required and the function simply needs to set f_name and f_type for use by subsequent commands?Other than that, the function does appear to be working. Still working on it. though.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 03, 2021, 04:43:44 pm
content: Quote from: WaveyDipole on July 02, 2021, 05:18:59 pmTLIST code will not be needed as it was not supported on the 4924 tape drive AND Tek BASIC TLIST only works with the internal tape drive.Tape Emulator must support the HEADER (BASIC 9, Secondary Address 105) command in order for DATA files to be accessed based on ASCII or BINARY type.So we can't use 105 (as it is used for HEADER on the 4924 and we need a HEADER command) or as you pointed out 127 for CD. How about 115? Since TLIST is not supported by the 4924 we should be able to use 115 for the Tape Emulator CD command.As I think about trying to use READ_file - there is no BASIC command to just read multiple ASCII strings and print them to the screen except for TLIST. So we can forget about READ_file code. The READ_one code is needed for the READ command at secondary address 110.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 05, 2021, 01:09:00 pm
content: Ok, so far I have implemented as follows:4  OLD/APPEND (imported in but untested)Tektronix:Emulator: (tek_OLD) appears to read a file and output its contents to the 40509  HEADER (seems to be working)Tektronix: allows files to be accessed based on ASCII or BINARY typeEmulator: (tek_CD) allows selection of a directory (“tape”)19  LIST/TLIST (seems to be working)Tektronix:Emulator: (tek_TLIST) returns a list of file headers27  FIND (seems to be working)Tektronix:Emulator: (tek_FIND) finds and sets the current file by using its file number30  ERROR (not working at present - returns no data)Tektronix: Returns the error status of the tape driveEmulator: Return the error status of the SD Card emulatorI still need to add:14  READ(READ_one_ code)Just taking a step back fistly, do I have the correct code in command 9 [hex 69] ?Regarding 127, having had a closer look at the original HPIB standard, as I mentioned, it seems they allocated 96-126 (or 60-7E hex) for secondary addresses, but 127 (7F) does not appear to be being used for anything. Maybe the engineers at Tek felt it best not to use it in case the standard changed in the future hence it was left undefined. I suppose it could be used though.I think I understand from the code that how a file is read would depend on the file type. For example, a BINARY program would need to be read in its entirety, loaded into memory and run. BINARY data might, I suppose, be loaded in its entirety or in part, but would obviously not be run. I expect that the controlling program would determine how many bytes of data to load. For example, a record or array size might determine how many bytes of data to read and load into the entity in which case the READ function would need to know the number of bytes to send. A program in text form would likely to be read in its entirety and would be loaded into an editable area in the 4050's memory. Text data, on the other hand, might be read a line at a time. It looks like both tek_READ_one and tek_READ_file seem to implement some aspects of these different ways of handling a file. The READ and WRITE commands are going to be interesting ones to implement.I will obviously use the tek_READ_one as the starting point. Would for example:Code:cout << F("ASCII Program\r");cout << F("Type SPACE for next item, or type q to quit\r \r ");Need to be transmitted back over GPIB to the 4050 to prompt the user to take an action to read the next chunk, or was this for testing only?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 05, 2021, 03:00:19 pm
content: Quote from: WaveyDipole on July 05, 2021, 01:09:00 pmGreat progress! But you didn't upload this version to AR488_STORE yet?I haven't seen your code, but expect it will simply return the filename string to the system for the HEADER command. I am putting the complete HEADER info into the long filename for each file. This makes this call very easy.HEADER (9 ).Tektronix:requests the HEADER to extract filetype (ASCII, BINARY, NEW, LAST) and datatype (PROGRAM, DATA, SECRET PROGRAM) and filesize (computed from number of 256 byte blocks reported in the HEADER).Emulator:Returns the SDcard filename of the file selected with a FIND command. The Emulator also extracts filetype and datatype to use for subsequent Tektronix commands.Example: filetype BINARY, datatype DATA. A subsequent Tektronix READ command will be expecting BINARY data to be returned and I have encoded all BINARY files as HEX, so the Emulator will be converting HEX to bytes first, then returning BINARY bytes on GPIB based on the TYPE bytes preceding the next data item. In addition, the Tektronix may request the TYPE (6) before requesting the data as Tektronix prints BASIC error messages on a TYPE mismatch before fetching the READ data (numeric or string).Although my original reason for encoding the BINARY files in HEX was the 7-bit ASCII limitation for transferring those files from the Tektronix to my PC. For the Tape Emulator, I may as well encode the HEX back into BINARY data to save a step in the Emulator code.LIST/TLISTI proposed this is nowCDin previous post (19 )Tektronix:sends command with one ASCII string as directory parameter. Example: PRINT @5,19: A$Emulator:changes SDfat directory to the string parameter with proper slashesQuoteYour description of READ is incorrect, see my READ description in my example of the HEADER command in this post.The BASIC program running in Tektronix is in control, and the Tektronix has a small buffer for each of the BASIC commands to the GPIB device. The Emulator has a very tiny (one 256 byte 'tape' data block) buffer to handle one request at a time from Tektronix.The Tektronix READ command will only expect one parameter to be returned, either one number or one string. For ASCII data files, there are several delimiters for numeric variables. Here is a snippet of comments showing the ASCII delimiters and BINARY data types at the beginning of tek_READ_one. For BINARY data files, character strings don't have quotes as the data length is specified in the datatype bytes. Also no CRs are needed for numeric or string variables, but I expect the Emulator needs to assert EOI on the last byte of data sent to Tektronix.Code:/*Tektronix 4050 DATA Types: ASCII and BINARYASCII DATA- ASCII Program lines are delimited with CR (unless changed) and files delimited by FF for EOF- ASCII DATA numeric items are delimited with Space, Comma, Semicolon, Colon, or CR- ASCII DATA string items are delimited by leading and trailing Quotation Marks- To use a Quotation mark inside a character string requires double quotes: ""Help""BINARY DATA- Each data item contains its own header identifying the length of the item and the type- This two byte Header is generated by the talker sending the binary data- The two byte data header has the following form:MSB LSB MSB LSB|T3 T2 T1 L13 L12 L11 L10 L9 | L8 L7 L6 L5 L4 L3 L2 L1|| BYTE 1 | BYTE 2 |L13 to L1 comprise the length of the item including the two header bytes.Since all numbers in Tek 4050 BASIC are 8-byte floating point, the binary number data length = 10BINARY data types for READ and WRITE commands----------T3, T2, T1 are the types of BINARY data0 0 0 Unassigned0 0 1 Binary number0 1 0 Binary string0 1 1 Unassigned1 0 0 Unassigned1 0 1 Unassigned1 1 0 Unassigned1 1 1 EOFTek 4050 BASIC "TYP" command returns a value based on next item in an open file:TYP Description--- -----------0 Empty File or File Not Open1 End of File Character2 ASCII Numeric Data or Character String3 BINARY Numeric Data4 BINARY Character String*/

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 05, 2021, 06:48:10 pm
content: Ok, I have moved CD to 19 (73H).Regarding READ, All I am primarily concerned with from my point of view in terms of coding is with what is transmitted over the GPIB BUS and in what direction. If all that is necessary for FIND is to receive the GPIB secondary address and send back some output based on the file type, then this makes it easier from my point of view. I am happy to leave all of the file encoding/decoding to you....However, I do need a little clarification. For example, lets take this section of code in theFINDREAD function:Code:case 'P':cout << F("ASCII Program\r");cout << F("Type SPACE for next item, or type q to quit\r \r ");sdin.getline(buffr, line_buffer_size, '\r'); // fetch one CR terminated line of the programcout << buffr << '\r'; // send that line to the serial portwhile (1) {while (Serial.available()) { //any character for next data item or 'q' to quit read1incoming = Serial.read();if (incoming != 'q') {incoming = '\0'; // clear the flagsdin.getline(buffr, line_buffer_size, '\r'); // fetch one CR terminated line of the programif (sdin.eof()) {cout << "__EOF__" << endl;return;}cout << buffr << '\r'; // send that line to the serial port} else { // incoming was 'q'incoming = '\0'; // clear the flagcout << "__Quit__" << endl;return;}}}So thee are being sent from emulator to PC:Code:cout << F("ASCII Program\r");cout << F("Type SPACE for next item, or type q to quit\r \r ");sdin.getline(buffr, line_buffer_size, '\r'); // fetch one CR terminated line of the programcout << buffr << '\r'; // send that line to the serial portwhile here we seem to be waiting for input from the serial port which I take to be simulating something being sent from the 4050 to the emulator?):Code:while (1) {while (Serial.available()) { //any character for next data item or 'q' to quit read1incoming = Serial.read();if (incoming != 'q') {incoming = '\0'; // clear the flag.....} else { // incoming was 'q'.....}}}So we wait for any key other than q and then we send e.g. a line (or item) of data:Code:sdin.getline(buffr, line_buffer_size, '\r'); // fetch one CR terminated line of the programSo the thing is, in reality is the emulator sending a prompt for a key-press and a human sitting there pressing the key or, as seems more likely, is something being sent repetitively by the BASIC program or command? If in reality the "conversation" is between BASIC program and emulator, then what exactly is being sent from the 4050 to the emulator to request the next chunk? Is it just another read command or some character? Do we actually need to send the prompts? Or as I suspect, is the CR (or EOI for BINARY PROGRAM and BINARY DATA) sufficient to signal the end of the chunk? Secret also seems to behave like BINARY (i.e. with HEX conversion), so I presume EOI would apply here as well?Any clarifications would be helpful and I do apologise for all the questions. I have also been busy looking at the Tektronix manuals today and clarifying some things including making a comparison between 4050 GPIB commands (4050 BASIC reference) and the ones supported on the 4924. This has proved to be enlightening and I understand now what you mean about the TLIST command.BTW, I have pushed the latest version of the code up.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 05, 2021, 08:27:48 pm
content: You are correct, the conversation is between the BASIC program and the Emulator with the Tektronix as the controller for GPIB traffic based on the BASIC command being executed.FIND for the Emulator involves getting one filename at a time from the current SDfat directory by SDfat index and extracts the first number from the filename (which the filename is in the format of the Tektronix tape file HEADER) which is the 4924 tape filenumber. Since SDfat does not necessarily store files in filename sequence, my code for the emulator iterates through files from first SDfat index until the extracted filenumber equals the requested FIND filenumber. The serial output of filetype is just for debug. There is no Emulator response required for the FIND command. The Tektronix sends EOI with the CR to terminate the FIND command as shown in the 4924 service manual section starting on page B-5 with 4051 MODE GPIB sequences. The 4924 doesn't send anything to Tektronix for this command.The fragment of FIND code you posted is just determining the file type from a specific character in the HEADER (SDfat filename).The returned char for the FIND is just the filetype for Emulator use if the next call is a READ.I have merged several fields to get the filetype returned if this call is successful in FINDing the requested filenumber:B = Binary Program (encoded in Hex)P = ASCII ProgramS = ASCII Secret Program (encoded in Hex)D = ASCII Data fileH = Binary Data file (encoded in Hex)N = New file (file created by MARK command, but not written to yet. Tektronix updates the header when file is written depending upon the command: SAVE, BSAVE, WRITE, WBYTE)L = Last fileCode:char tek_FIND(int num) {// char f_name; //the filename variable/* FINDs and OPENs file (num)Returns: string result= "A" for ASCII, "H" for HEX (Binary or Secret file), "N" for Not FoundFIND iterates through each file in a directory until filenumber matches numsince SdFat file index is not sequential with Tek 4050 filenames*/if (!dirFile.open(directory, O_RDONLY)) {sd.errorHalt("Open directory failed");}for (int index = 0; index < nMax; index++) { //SdFat file index number// while (n < nMax ) {file.openNext(&dirFile, O_RDONLY);// Skip directories, hidden files, and null filesif (!file.isSubDir() && !file.isHidden()) {file.getName(f_name, 46);int filenumber = atoi(f_name);if (filenumber == num) {// debug print the entire file 'header' with leading space, and CR + DC3 delimiterscout << F(" ") << f_name << "\r ";// all BINARY files are in HEX formatif ((f_name == 'B') && (f_name == 'P')) {dirFile.close(); // end of iteration through all files, close directoryreturn 'B'; // BINARY PROGRAM file} else if ((f_name == 'B') && (f_name == 'D')) {dirFile.close(); // end of iteration through all files, close directoryreturn 'H'; // BINARY DATA file ** to read - parse the data_type} else if (f_name == 'S') { // f_name is location of file type SECRET ASCII PROGRAMdirFile.close(); // end of iteration through all files, close directoryreturn 'S'; // SECRET ASCII PROGRAM file} else if (f_name == 'P') { // f_name is location of file type (PROG, DATA,...)dirFile.close(); // end of iteration through all files, close directoryreturn 'P'; // ASCII PROGRAM file} else if (f_name == 'N') { // f_name is location of file type (ASCII,BINARY,NEW, or LAST)dirFile.close(); // end of iteration through all files, close directoryreturn 'N'; // ASCII LAST file} else if (f_name == 'L') { // f_name is location of file type (ASCII,BINARY,LAST)dirFile.close(); // end of iteration through all files, close directoryreturn 'L'; // ASCII LAST file} else {dirFile.close(); // end of iteration through all files, close directoryreturn 'D'; // ASCII DATA file, also allows other types like TEXT and LOG to be treated as DATA}}//f_name=0; // clear f_nameif (file.isDir()) {// Indicate a directory.cout << '/' << endl;}}file.close(); // end of iteration close **this** file}cout << F("File ") << num << " not found" << endl;f_name = '\0'; // clear f_namedirFile.close(); // end of iteration through all files, close directoryreturn 'O'; // File num NOT OPEN (or NOT FOUND)}

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 07, 2021, 05:13:10 pm
content: Sorry we seem to be at cross purposes and it is my fault! The snippets of code that I pasted in the last post are from the READ function and that is the one I was interested in when writing that post. I stated 'FIND' in error. Mea culpa!Nevertheless, I do appreciate the provided detailed explanation of the FIND function as I had similar questions about that in a previous post. This clarifies things for me and confirms what I had already concluded so was very helpful.Sometimes the smallest problem can send one around a 'needle in a haystack' type of search and the case in point was the problem with the ERROR function that was returning the result twice. I spent all day today trying to figure that one out and it turned out to be down to a mis-timing of the EOI signal. The HPIB standard calls for it being sent "with" the last character. My code was sending it once the handshake on the last character was complete but as the LA traces showed, technically this was AFTER the last character an too late. It needed to be sent during the handshake so that its timing coincides exactly with the receiver reading the characterThis led to a conundrum: how does the program know that the current character being sent is the last one? With a fixed buffer and known length of the data this is easy. The last character is the length of the data - 1 (C++ arrays start at 0). But what if we want to send multiple chunks (buffer full) of data in succession as when sending binary data, e.g. a binary program? Or what if the data is being read from a file? How do we know that the character we currently reading is the last one before EOF? Once we reach EOF and drop out of the read loop it is too late....That's the problem I need to solve next. I have solved the problem with the ERROR function and it now sends a single result. CD and FIND still work although a couple of other errors came to light, but at least that allowed me fix them. I now need to have a close look at the READ_one function as this is where the EOF conundrum will come into play. It has been suggested that the peek() function might be helpful, but I will now leave this for another day.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 07, 2021, 05:46:18 pm
content: I saw this morning that you had uploaded a version 5.20 two days ago, so I downloaded it and tried a couple of things.FIND @5:1 may have worked, but I see a Tektronix GPIB transaction after that command that I need to look at. It may be a HEADER command request - I don't know if the Emulator HEADER code is in v5.20.I tried OLD @5: after the FIND and the Tektronix HUNG. I captured a trace for that too and will upload it after I answer your questions just posted.QuoteI believe the answer depends upon which command is being handled:For example:OLD - I believe the Tektronix will expect one ASCII character string - CR delimited at a time from the Emulator, with the Emulator asserting EOI ONLY when EOF is reached. The Tektronix will have to parse the character string for syntax errors, then encode and store the tokenized version of the string into memory, before accepting more characters. When we get OLD working, I think we will find the Tektronix delaying its acceptance of the next character from the Emulator until it has finished processing the last string. What I see in captured ASCII program data blocks from tape is just a CR character on the line following the last program statement. I believe this causes the Tektronix to terminate the OLD statement. However I suspect that if the last program statement ends at the end of the file that EOF (ASCII 127) from the Emulator with EOI asserted will also terminate the OLD statement.OLD for Binary Programs should be similar with the Tektronix holding off accepting another byte from the Emulator while is stores the previous tokenized statement (I don't know what the BASIC tokens are, nor what terminates a tokenized statement). Same termination should apply - Emulator will only terminate on EOF but Tektronix may terminate OLD earlier based on NULL statement logic.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 07, 2021, 11:34:31 pm
content: I'm still having trouble getting the OLD command to work after a FIND command.I don't see the emulator posting a debug message, although I see the logic analyzer trace showing the correct primary address of 5 and secondary address of 4 for the OLD command.I also want to mention that there is a detailed 4051 GPIB Hardware Supplement manual describing how the 4051 (and 4052) handle GPIB with discrete logic and BASIC firmware:http://www.bitsavers.org/pdf/tektronix/405x/070-2270-00_4051_GPIB_HW_Supp_Jul81.pdf

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 08, 2021, 10:45:03 am
content: I had added OLD but hadn't got around to actually testing it, so I couldn't really confirm whether it should be working at this point. Bearing in mind the problem with EOI discovered yesterday, I have been having a working on and testing the OLD function this morning, using file 1 which contains a short BASIC program (ASCII data) as an example. The function is relatively short so was an ideal candidate to test reading a file and sending EOI with the last character of the file. While working on it I found as follows:Firstly, the function uses the getline() method which reads up to the end of line delimiter. This means it works only for ASCII files. Is that what was intended?Secondly, the getline() method strips the CR line terminator so it was necessary to include a bit of code to add a CR back to the end of each line before sending it over GPIB. When sending ASCII data over GPIB, ASCII line terminators are ignored and striped and a line terminator (LF, CR or CR+LF) appended as determined by the setting of the EOS parameter. However, when using EOI as a terminator, all characters are sent without any processing. As a result, the CR was getting stripped by getline() but no line terminator was being appended in accordance with the setting of EOS. Without the CR being added back in, text would be received at the other end without line terminators.Finally, if the function is intended to deal with ASCII data only, then it should probably be restricted to working on only those file types it can support. My initial thought was to look at the f_type variable and proceed only if it indicated certain file types such as P, N, L, D and possibly S? On the other hand, if it needs to work on both ASCII and BINARY, it may as well be re-written to treat all file types as binary data. That way, it doesn't matter what file type it gets called on and will simply return the entire contents of the file asserting EOI on the last character. It would probably be a matter of using read(buffer, bufferlength) where bufferlength is set to 'line_buffer_size' instead of getline(). There would also be no need to add in the stripped CR. I will experiment with this but won't change it for now.In the meantime I have just pushed 0.05.23 which includes all the work yesterday and the work just done this morning on the OLD function up to the repository. The functions CD, FIND, ERROR and OLD should (theoretically) be working. If any are not working, I would be interested in seeing the serial console output on the emulator.It does not surprise me that the Tek computer tokenizes the BASIC keywords. This technique is used to save memory space on other computers of the period.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 08, 2021, 02:15:26 pm
content: The Tektronix OLD command only works with ASCII files. Tektronix made an optional ROMpack for the 4051 to add BOLD and BSAVE commands for files to the internal tape - but there are not equivalent commands for the external 4924 tape, so we can ignore the need to support BINARY programs - and none of the 100's of programs I have recovered have been in BINARY form.We do need the Emulator to terminate ASCII program lines with CR, as I did with my continuedDev version, but the EOI would only be asserted by the Emulator on a GPIB byte if the end of SDfat file was reached. During the sending of ASCII program statements to the Tektronix, the Emulator would try to send a character at a time - with the GPIB handshaking protocol indicating whether the Tektronix was ready for the data, until the Emulator reaches the end-of-file or the Tektronix terminates the command as the controller (which it will do upon a BASIC parsing error or empty line with a CR).In my experiments yesterday - I don't believe the Tektronix requests the file HEADER after the FIND and prior to the OLD command unless the PROGRAM requests the HEADER (which none of mine do). I think the Tektronix BASIC parser will terminate the OLD command if the input string of characters is not a proper BASIC statement.I will check out your new 5.23 version today!

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 09, 2021, 01:24:16 am
content: I have some good news and some bad news.First the good news:FIND is working (FIND @5:1 and FIND @5:2)CD is working (PRINT @5,19:"UTILITIES")READ is working (READ @5:A$)Now the bad news:OLD isn't working (PRINT @5,4: this got the result in the console screenshot, no hang on the Tektronix - but no program. OLD @5: showed nothing on the console, see the waveform output - makes no sense)Here is the console screenshot:I couldn't get the OLD @5: command to work so what you see in the console screenshot was PRINT @5,4: which puts the Emulator in LISTEN modeThe emulator serial output shows it decoded the primary address of 5 and the secondary address of 64, and although the serial output shows it started the handler - no data was sent to the Tek, likely because the Emulator was addressed to LISTENI know I used OLD @5: with my 4924 and the command worked, but the 4924 is not working nowI found a -12V fuse that was open and the +5V output reads 10VLooks like the 5V filter capacitor has diedI don't know if the logic is fried, but I'll put a different capacitor in it tomorrow without connecting the logic board and see if I can get the proper 5V output.Here is the logic analyzer listing for OLD @5:Code:HPIB STATE - State ListingLabel > Time DATA ATN NDAC NFRD EOI REN SRQ IFC DAVBase > Relative Hex Bin Bina Bina Bin Bin Bin Bin Bin__________ _________ ____ ___ ____ ____ ___ ___ ___ ___ ___-11 8 ns 80 0 1 1 1 0 0 1 1-10 8 ns 80 0 1 1 1 0 0 1 1-9 8 ns A0 0 1 1 1 0 0 1 1-8 4.048 us A0 0 1 0 1 0 0 1 1-7 8 ns A0 0 0 0 1 0 0 1 1-6 23.50 us A0 0 0 1 1 0 0 1 1-5 29.39 us 80 0 0 1 1 0 0 1 1-4 96 ns 82 0 0 1 1 0 0 1 1-3 8 ns 8F 0 0 1 1 0 0 1 1-2 40 ns 9F 0 0 1 1 0 0 1 1-1 8 ns DF 0 0 1 1 0 0 1 10 38.42 us DF 0 0 1 1 0 0 1 0Primary Addr (20H) 32 decimal Device 0 Listen Address1 70.60 us DF 0 0 0 1 0 0 1 02 11.45 us DF 0 1 0 1 0 0 1 03 41.00 us DF 0 1 0 1 0 0 1 14 23.53 us DF 1 1 0 1 0 0 1 15 27.06 us DF 1 1 0 0 0 0 1 16 27.18 us DD 1 1 0 0 0 0 1 17 8 ns 99 1 1 0 0 0 0 1 18 168 ns B9 1 1 0 0 0 0 1 19 14.90 us B9 1 0 0 0 0 0 1 110 20.64 us B9 1 0 1 0 0 0 1 111 32 ns B9 1 1 1 0 0 0 1 112 30.06 us B9 1 1 1 0 0 0 1 013 39.26 us B9 1 1 1 0 0 0 1 114 21.97 us B9 1 1 1 1 0 0 1 115 70.66 us B9 0 1 1 1 0 0 1 1 Primary Addr (46H/70 dec) Device 6 ?? Talk Address16 39.78 us B9 0 1 0 1 0 0 1 1 ---17 8 ns B9 0 0 0 1 0 0 1 118 23.50 us B9 0 0 1 1 0 0 1 119 22.69 us BF 0 0 1 1 0 0 1 120 37.94 us BF 0 0 1 1 0 0 1 0 Sec Addr (40H/64 dec) ?????21 77.96 us BF 0 0 0 1 0 0 1 022 11.43 us BF 0 1 0 1 0 0 1 023 34.71 us BF 0 1 0 1 0 0 1 124 37.66 us BF 0 0 0 1 0 0 1 125 152 ns FF 0 0 0 1 0 0 1 126 31.46 us FF 1 0 0 1 0 0 1 127 50.51 us FF 1 0 1 1 0 0 1 1Time Printed: 08 Jul 2021 13:00:53It makes no sense at all.I need to repair my 4924.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 09, 2021, 09:51:44 am
content: Quote from: mmcgraw74 on July 09, 2021, 01:24:16 amRead works only inasmuch as it reads a line from the file and sends it to the serial port. The code hasn't been updated yet to send to GPIB.Quote from: mmcgraw74 on July 09, 2021, 01:24:16 amCan't figure the LA output at the moment either. What GPIB address is the Tek on?I don't suppose you have another device connected with the GPIB address 6?Is there any chance you can try this again with #define DEBUG_DEVICE_ATN un-commented and show the console output please?Incidentally, I did have a look at the 4051 documentation, in particular Appendix B of the 4924 service manual which provides a table of GPIB command sequences, including '"ALTERNATE" MODE GPIB SEQUENCES' when a 4924 is used. Given the command sequences in your post, am I correct in assuming that we are using standard 4051 mode and not the "alternate" mode? In any case, its the odd number (CPA) that should be greater than the even (DPA) number so this still doesn't make sense.Quote from: mmcgraw74 on July 09, 2021, 01:24:16 amYes, that seems to make sense. If the emulator is being asked to LISTEN (MLA) then it will switch to a listening state (data lines in input_pullup state) so will not be in a state to send anything.BTW, I have read up a bit more on the OLD/APPEND command and now understand that it is specific to ASCII programs as you pointed out so I guess OLD needs to be adjusted to respond only to files of type 'P'? However, that is aside from the problem of why there was no response in the first place.Quote from: mmcgraw74 on July 09, 2021, 01:24:16 amI don't have the circuit diagram but lets hope that there is nothing more than just a faulty filter capacitor, although it does sound like maybe the 5V regulator has failed? Hopefully none of the logic ICs have been affected.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 09, 2021, 07:48:21 pm
content: Just came across this Tek 4051 on eBay. Wondering whether it is worth a punt?Would make it easier to test things, but just wondering why the screen is fully lit like that?https://www.ebay.co.uk/itm/133812508227Its over a couple of hours drive from me to pick it up (assuming I can "win" it) so I don't want to travel that far it its not repairable.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 09, 2021, 08:05:15 pm
content: Yes, well worth it. All Lights on the Right Mean the ROMs didn't boot, same with the screen. I can help you fix it.You can make an offer for less - he may take it!Monty

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 10, 2021, 01:48:36 pm
content: Was wondering whether it might be a symptom of not booting from ROM(s) and nothing more serious than that. Sometimes ICs need re-seating but ROMs can go corrupt. They can usually be replaced if one can get hold of either an image file and has the equipment to burn it onto a new EEPROM chip, or already prepared EEPROM chips.I repaired a Tek 468 oscilloscope a while back. It had a dead CPU and faulty clock but as it turned out, the ROMs were still good. I don't have an EEPROM burner but managed to obtain both image files and ready burned replacement ROMs chips. The original chips are unobtainable so the replacement chips being alternatives and having a slightly different pinout, required adapters, but they do work. For now I have left the originals in place and am keeping the newer chips as spares in case the originals should fail. The scope otherwise required very little maintenance and seems to work pretty well with measurements being pretty much spot on.Regarding this project though, I spent a lot of time yesterday browsing through the manuals and your implementation notes on the GitHub repository to better understand the header and binary formats and other bits and this will all come into play in the next stages of development. I do think, however, that I am getting to a point where it will start to become more difficult to test things so having real Tek hardware would be useful.I was wondering, regarding the filename/header format, for example:9 ASCII PROG  14In your file names, what does the last two digit number represent?Which part is considered the "comment" string? Is it the bit in square brackets?Are you planning on sticking with 44 characters for the file header/name?The filenames in the examples seem to vary between 34 and 36 characters in length but I notice you have defined f_name as 46 characters long which I assume is because Tek header = 44 characters plus CR + '\0' ?Just seeking to understand.BTW, apparently the 4051 is up for nearly double the starting price elsewhere so I expect the seller will be looking for somewhere around that price. It also turns out the drive may be between 3.5 - 4 hours so up to an 8 hours return trip. Not sure it is worth it but still thinking about it and will probably wait to see how the auction works out. A courier option would have been more convenient.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 10, 2021, 06:50:42 pm
content: Quote from: WaveyDipole on July 10, 2021, 01:48:36 pmThe ebay seller posted his 4051 on the facebook "Tek 4051 BASIC" forum last month and asked what the problem could be. I indicated the likely issue was one or more DRAMs were defective and the ROM memory test failed. I suggested what he could do to debug and the made no more posts. I suggested that he remove the expansion memory board shown in his photos to see if base memory in the 4051 was ok. If that didn't help, then likely the problem was in base memory and he could substitute socketed memory from the expansion board into the main board until the main board worked.QuoteYes, the comment in the file 9 header is in square brackets.The last number in the header is the number of 256 byte blocks.Tek allowed multiple digits for this number for large data files.The tape file header format is shown in the 070-2056-01_4050_BASIC_Reference_Manual Jul 79 on bitsavers.org page 7-42.The \0 is supposed to be a NULL character.The Tektronix programs to edit the file header added a CR and NULL character to the end of the header.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 10, 2021, 06:53:07 pm
content: Quote from: WaveyDipole on July 10, 2021, 01:48:36 pmYou might send him an email - and ask if he could meet you halfway.Since the auction includes "Make an offer", this means the seller might take a lower offer.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 10, 2021, 07:42:03 pm
content: I made good progress - my other Tektronix computer is a model 4054A, I tried my minor edit to your 0.05.23 code (changed CS from 3 to 4 for my board to work) and gotCD, FIND and OLD all to work!(see first photo).Three tests:CD "ROOT" (PRINT @5,19:"ROOT"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loadedCD "GAMES" (PRINT @5,19:"GAMES"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loadedCD "ROOT" (PRINT @5,19:"UTILITIES"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loadedAll three successful.Next two photos show that if a complete program (/ROOT/1/) is loaded - it runs:FIND and CD also worked on my 4052 computer, but OLD resulted in a hang that required cycling power on the 4052 to clear.As a possible explanation to the difference - the 4052 has a different ROM version AND discrete GPIB hardware compared to my 4054A which has a TI 9914 GPIB controller and therefore different GPIB code in its ROM.One more difference - on my 4052 I had to disconnect power to the Emulator or the 4052 locked up and had to be power cycled with power to the Emulator disconnected, then I could power on the Emulator for testing. I didn't have that problem on my 4054A - I powered the Emulator from a 5V iPhone charge cube, then turned on the 4054A without issue.The original 4051 computer has completely different ROM code than either the 4052 or 4054 - so I think it is a good idea to check out the Emulator with all three Tektronix computers. I don't have a 4051, but there are a couple of people in the facebook group that do.I thought the READ code worked - because of the serial debug messages, but READ hung on both the 4052 and 4054A and it is my mistake. The READ command ONLY supports BINARY data, not ASCII data - and I was trying to READ ASCII data and program files with the Emulator.I tried to edit your READ_one code to use it with the INPUT command 13 (6D hex) instead of READ 14 (6E hex), but you said the READ command was not sending data on GPIB yet.Can you have the INPUT command 6D hex use the READ_one code (it can be renamed from READ_one to INPUT)?After I test the INPUT command for getting ASCII data to the Emulator from ASCII PROGRAM or ASCII non-program (DATA, TXT or LOG) files, we can divide that section of code into INPUT (ASCII files only) and READ (BINARY DATA files only).I haven't repaired my 4924 tape drive yet, but will work on that now.I'm excited by the progress: CD, FIND and OLD make LOTS of programs work on the Emulator.INPUT will be needed to support ASCII data files and READ will be needed to support BINARY data files.My port of Adventure to the 4052/4054 requires INPUT of ASCII data files - there are 55 DATA files!.It also requires PRINT to save the Adventure game to a file.Here is my 4054A running Adventure from a 4907 floppy disk (8-inch disk):

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 11, 2021, 01:52:03 pm
content: Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmI mentioned that I was using pin 3 a while ago but it a lot of ground has been covered since then and a lot of information exchanged! I ended up using pin 3 because pin 4 is used by default by the USBASP programmer I am using to upload the code to the 1284p and there is no means to change that. The code assigns pin 4 by default if it has not been defined. I will try to remember when publishing to keep the configuration at pin 4.I can see how not being able to communicate with the SD card reader would have caused problems but what is a bit strange is why some of the functions still worked? I can understand CD working as it doesn't actually access the SD card, but the other functions do. OLD is a bit different to FIND in that it uses ifstream rather than file, but even so, both functions need to access the card for information. READ also uses ifstream and you did get something out of that even though it was only to the serial monitor screen. Weird. I still can't explain the LA output either.Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmThat is very encouraging.Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmInteresting that is should behave somewhat differently on each computer. I will see if I can find the manuals for the 4052 and 4054 and if the information is available, compare the GPIB sequences.Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmI got the same understanding from my perusal of the manuals. The ASCII code is probably superfluous in FIND.Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmCorrect. From my reading of the manuals, a number of things have to come together here first before read can work:1. as I understand it, FIND opens a file, CLOSE closes it. It is my understanding that requesting HEADER via the INPUT command will also open a file. Once a file is opened by FIND it can be accessed using other commands such as READ, WRITE, INPUT etc until closed by CLOSE or a new file is opened by FIND. FIND closes the previously opened file. Not sure whether the same applies to OLD as there seems no point holding the file open after the emulator has read the program, although a program can't a program be appended to or modified?2. in READ, the binary data header needs to be implemented. The BASIC program does not send any information with the READ command to determine how many bytes to read. The number of bytes to read is determined by first reading the binary header. The header will have been created when writing the data into the file. The binary format "knows" nothing about BASIC variable types just how many bytes to read. I am trying to figure out whether a header is required for each item, i.e:valuestringstringvalueOr whether one header would be required fro the group:value|string|string|valueThe problem with the latter though is how to determine how long each string is? I therefore imagine it must be the former. Of course, it would be up to the BASIC program to correctly read back each item into the correct variable type. So if it writes the sequence A,B$,C$,D then it must also read back the same sequence into the same variable types INT,STR,STR,INT regardless of the actual letter designations used.Also, regarding files in gerenral, what command is used to assign and save the file header information to a new file? I don't see a CREATE command or any other command for setting the file description?Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmYes, certainly I can do that and it does sound like a plan. I agree we should first concentrate on getting the ASCII part working. Am I correct in assuming that in ASCII DATA files, each item is delimited by a CR? I know that works for A$ which reads a string(and therefore up to CR), but what about reading a numeric value into B (i.e. an int)?Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmNice to hear that we are making progress. You have a working 8in floppy disk? The last time I saw one of those was in my workplace some 30 years ago and it was obsolete back then! The old defunct drives were massive even by 5.25 in standards.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 11, 2021, 03:46:21 pm
content: Quote from: WaveyDipole on July 11, 2021, 01:52:03 pmI think you meant the ASCII code is probably superfluous in READ. I agree, we should take the ASCII code in READ and move it to a new routine INPUT.Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmQuoteIn order to access the tape file HEADER, you first send the FIND @5:X command for file X then INPUT @5,9:A$ to fetch the HEADER. At this point the file itself cannot be accessed without doing another FIND @5:X command.Yes, doing another FIND command does an implicit close on the previous open file.OLD causes an implicit CLOSE of the file after the Tektronix interrupts the command or EOF is reached.OLD always deletes the current program in memory before loading the new one. APPEND does NOT delete the program in memory, but that file is appended (and replaces) a specific line number (typically a REM statement) in the current program and renumbers the lines in the appended file from that point. There is no difference to the Emulator for OLD or APPEND - that's why it is the same secondary address for that command.QuoteThe BINARY DATA file format is your first example - a two-byte header in front of EACH numeric or string variable including the data type and length. No need for CR between BINARY data items, no need for quotes around string data items.QuoteTypically, the tape file HEADER is created by the Tektronix during creation of a new file with the MARK command to the tape drive. This is described in the 4050 BASIC Reference Guide 070-2056-02. First FIND the file to replace with the file that will be MARKed NEW in the HEADER and created with the number of 256 byte blocks to satisfy the number of bytes requested in the MARK command. Typically this would be done by a FIND to the LAST file. MARK can create multiple files of the requested size at that point if desired. BASIC will then automatically create a new LAST file after the NEW file(s) are created. Typically it is the Tektronix that creates and modifies the HEADER. There were utility programs written by Tektronix that could add comments and ensure that the rules described in the BASIC Reference Guide for HEADERs were satisfied (no numbers in the comment, no S in the comment at the location indicating a SECRET file, etc).QuoteNot quite. Tek BASIC supports several delimiters between numeric and/or strings in an ASCII DATA file. The system reference page 12-2 shows the allowed delimiters in BASIC program statements - which also applies to ASCII data files: [Space, comma, colon, semicolon and quote].I don't expect the Emulator to worry about delimiters for data boundaries in ASCII data files - the PROGRAM will dictate when the next data item is needed and the Tektronix will just hold off handshaking in the middle of a BASIC INPUT statement until the previous numeric or string variable has been processed, and the Tektronix will end the transaction when the INPUT statement is completed. When the next INPUT statement is started, the Tektronix will initiate a new transaction, and so on. The Emulator will continue to leave the file open until EOF, or a FIND or CLOSE command.Also the "DATA" field in the file HEADER does NOT have to contain "DATA" and some ASCII data files have "TEXT" or "LOG" in that field. So the only test needed in the Emulator is for the "P" in PROGRAM to distinguish between program files and all data files).Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmQuoteYes, I now have two Tektronix 4907 8-inch disk drive systems that I have repaired and are fully operational! And they are big and heavy.You can also see my Tektronix 4924 Tape Drive on top of the 4907's.I have also recovered several Tektronix 8-inch floppy disks and posted the files on my repository.I had thought I needed to emulate the directory structure of the floppy disk system, but I think the approach we now have in the emulator is much simpler (single level of directories), and I can modify the floppy disk programs I have recovered to use files in different microSD card directories instead of hierarchical directories.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 12, 2021, 09:55:33 am
content: I have pushed up an update with what, I hope, is a working INPUT. Currently it reads whole lines of text only but should return the next line each time INPUT is called, provided that the file already is open.Quote from: mmcgraw74 on July 10, 2021, 07:42:03 pmThis is why I need to resolve the matter of the header record as this will be crucial to the next stages of development. It is accessed by a number of commands including FIND, HEADER, MARK, OPEN, KILL, READ, WRITE. I have seen the Tektronix specification in the manual and imagine that when the 405x requests the header record it will need to be transmitted in the correct Tek format. The emulator stores the information in the filename in a somewhat different format, so when FIND finds the file, it will need to extract the header information which will need to be stored or converted into Tek header format while the file remains open.Incidentally, I discovered that the last number in the header information is the number of records allocated. It seems that records can be 128 or 256 bytes long. Will the emulator be expected to support both?The filename format includes:xxxxxx MARKed filesize in bytesMARK records the number of 128 or 256 byte 'records' allocated. Is the intention here to record the actual file size in bytes rather than the number of records?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 12:38:08 pm
content: Quote from: WaveyDipole on July 12, 2021, 09:55:33 amI have been recovering dozens of Tektronix 4050 series program tapes by reading every block in every file. The 4924 tape drive was introduced with the 4051 in 1975 and replaced a 4923 tape drive which was designed to work with the 4000 series Tektronix terminals. The 4923 tape drive only supported 128 byte blocks and the 4924 tape drive could be configured for either, but the 4924 tape drive default is 256 byte blocks.None of the 100's of 4050 tape drive programs I have recovered use 128 byte blocks - as the 4051 internal tape drive was designed to support 256 byte blocks - so we don't need to support anything but 256 byte blocks. In addition, I don't think the block size is of any importance as their is no Tek BASIC command that fetches a data block. For my Tape Dump program I use a different company "TransEra" ROM cartridge with data block read and write commands.The first block on the 4050 tapes I have recovered by reading the all the blocks with my Tape Dump program only uses the HEADER string at the beginning of the block, which can only be read by a 4051 program using the PRINT @x,19: BASIC statement where x=33 for the internal tape drive or x=4924 primary GPIB address for the external tape drive.The ONLY 4050 programs that have this statement are the ones that read the original tape header and rewrite the header with comments supplied to the program by the user.The BASIC TLIST command to the internal tape only - reads the file HEADER from each file and lists the information to the 4050 display by default, or can be redirected to PRINT each file HEADER to a GPIB device. Tek BASIC replaces the last number (number of 256 byte blocks in the file - not including the HEADER block) with the calculated file size.This calculated file size will match the filesize requested with the MARK command which created the file - not the amount of the file that is used.The TLIST command is really only useful to a user that wants to either remember which file number to open on a previously recorded tape, or is trying to add or replace files on the tape with the MARK command and wants to find the LAST file to use that file number as the starting file number for the MARK command.I used the 4051 computer for 3 years in the late 1970's, developing programs. When I purchased my vintage 4052 and 4054 computers twenty years later, I couldn't find a 4051. I noticed the 4052 and 4054 computers (introduced in 1979) added several new BASIC commands including a HEADER command. When you run the HEADER command on either the internal tape or 4924 tape, you must run this command immediately after a FIND command and Tektronix PRINTs the file header information for that file exactly like the print in the TLIST - where the filesize is printed in bytes, not number of blocks. However, the file that you have printed the header is no longer open and another FIND command must be issued before the file can be accessed.I have created the filename for each file on the microSD card in the Emulator in the same byte for byte format as the 4050 tape header with three exceptions:The leading space before the filenumber is stripped when the filename saved (and I don't use the file extension)The trailing CR and DC3 are stripped when the filename is savedThe starting location of the number of blocks of the LAST file is shorter by one byte than all the other filesMy Emulator code adds the leading space and trailing CR and DC3 to the header string before sending it to the system to match what Tek BASIC documentation on the header format.Apparently TEK BASIC on the 4054A (the A-Series 4052 and 4054 added the TI 9914 GPIB ASIC and many new BASIC instructions, so the firmware is different than the 4052) does not access the file header before the OLD command, since we don't have that working yet on the Emulator.I do believe TEK BASIC will access the file header before executing a program READ statement from tape - as Tektronix will need to process each binary data item header for each READ.Thanks for the updated code - I will test that now and we will see if the INPUT command also requires the header be accessed.Since the file header is an entire block of 256 bytes - I don't know if Tek BASIC ROM expects to access the header like a user with the special PRINT statement followed by an INPUT command for the ASCII header string after a FIND command, with a subsequent additional FIND command to access the data items based on the data file type, but we will find outI replace the 4924 5V power supply fuse yesterday and the tape drive appeared to start working and I was able to use the front buttons to fast forward and rewind the tape, but when I turned it off and connected it to my 4052 and turned it on again - it is not workingI don't plan to debug the 4924 issue today.I hope your updated code for INPUT works on the 4054A. I have prepared a fourth directory on the microSD card with my Adventure game port where the statements that access the 55 data files have been changed to access these files on the emulator. Fingers crossed.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 01:53:08 pm
content: Quote from: WaveyDipole on July 12, 2021, 09:55:33 amI tested your new drop and INPUT provides data but doesn't work right yet.Here is a photo from my 4054A:Here is the ADVKEYS file 1 being INPUT:Code:DATA 1,133488,1,6771679,2,36315,2,8849417,3,4673330,4DATA 1641035,5,1987117,6,234943,6,387847,7,7400652,8DATA 92813,8,249958,9,9462081,10,2517217,11,7523733,11DATA 7763223,12,1512460,13,8969927,14,7412167,14,12721DATA 15,9459313,15,1515430,16,10541692,16,9046363,17DATA 10386,18,211942,18,5511277,19,197385,20,115990,21DATA 1191644,22,53591,23,12562,23,405292,25,60879,26DATA 5963048,27,38576,28,1305,29,10150041,29,7478239,30DATA 8824300,31,7307409,32,41708,33,945573,35,9466352,36DATA 2145145,37,8929575,38,2233302,39,5279045,41,6111523DATA 42,7523588,100,14,100,6674000,101,369,102,5,102DATA 89070,103,499,104,19,104,8960908,105,517,106,23DATA 106,408142,107,387,108,21,108,562,109,4,109,81056DATA 150,7536914,151,11425101,152,7533245,153,1289448,154DATA 3516401,155,636,156,4191,157,35917,158,504325,158DATA 8824505,158,8783307,200,2524729,200,291920,201DATA 1697949,202,221453,203,248,203,2544612,204,5572845DATA 204,10706,204,104358,205,4373864,205,9,206,10541692DATA 207,221141,207,9851065,208,10386,209,8833780,210DATA 221423,211,1236540,212,313242,212,347870,212,3748DATA 213,8745885,214,1905,215,1588264,216,190310,217DATA 274600,218,1592479,219,1126054,219,1929708,220DATA 119741,221,405215,300,12716,301,111864,302,5646856DATA 302,404,303,2720472,303,10302,304,4882,304,1402110DATA 304,352487,305,82878,305,84854,306,9292709,307DATA 822045,307,199744,308,108970,309,117759,309,8321691DATA 310,405501,311,3426,312,2150731,313,319778,313DATA 2707727,314,1233737Notice that each INPUT is only reading the first number on each of the separate lines in the file.The "DATA" text is ignored - there are no quotes.This is the same file contents that work with the files located on the 4907 GPIB floppy drive.The program is running line 174 in a loop to fetch two variables and save them in two different numeric arrays.The K0 array should contain the first number (Adventure room number) and the K5 array will contain the large number (value encodes which room is accessed from which direction from the K0 room number.The program hung on line 174 with the FOR loop index stopped at 29, there are only 28 DATA statements in file 1 and K0 contains only the first number of each line.I just checked the contents of K5 array - it contains the second value on each of the 28 DATA statements.Sounds like the Emulator is fetching a new line for each INPUT statement instead of only fetching a new line when the contents of the previous line have been consumed.Tek BASIC when READing variables in DATA statements does not consume a whole DATA statement, just the variables requested.Great progress, though! We are getting very close to running Adventure, the most complex program for the 4052/4054 that I have written

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 02:08:31 pm
content: I just looked at your new INPUT code in AR488_Store_Tek.cpp and see in your comment that it reads a "line at present".We need it to 'ignore' lines and just return one GPIB byte at a time to Tektronix, which needs to include the CR.Is there an SDfat call other than read a line that we can use for INPUT that would be byte at a time?We will need the same functionality in the READ code later.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 12, 2021, 03:42:06 pm
content: Yes, the input code is pretty basic at this stage and your test does provide an indication that the function is being recognised.Is that the standard format of the Tektronix data file? If so then curious that the word DATA is repeated on every line. Are there any other keywords that might appear? Also, how does it treat text (string) data? In double quotes? I assume yes, because otherwise how could a comma in text be distinguished from a delimiter? Not a big deal and the main point is that each item of data is between commas.Now that I know what the data file looks like, I can work with that. In SDfat, getline(0 can read to a specific delimiter, but only one delimiter. Here it would seem we need to distinguish between comma, CR and space so that's not going to work. We can't read a line at a time either (well we could but then you would have to preserve the remainer of the line somewhere and work out how far you had got on the previous input request) so I think it will indeed need to read byte by byte and parsed. Shouldn’t be too difficult though.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 04:46:00 pm
content: Quote from: WaveyDipole on July 12, 2021, 03:42:06 pmThere is no standard format for a Tektronix ASCII DATA file. The file contents were typically created by a BASIC program which would dictate whether the data items were written one at a time with separate PRINT statements which would generate a CR after each data item, or multiple data items (numeric or string or both) in a PRINT statement (this is the way my Adventure DATA files were created). In either case, the BASIC program did not need to know where CRs were located.Yes, the 'DATA' text is unnecessary - but totally ignored by Tektronix as it is not quote delimited as all ASCII character strings must be quote delimited.QuoteYes, I agree that the Emulator response for an INPUT GPIB command should be byte by byte ASCII characters - no need for any parsing. I expect there must be an SDfat call that can stream binary data without any parsing. Let Tektronix BASIC parse the GPIB bytes, driven by the BASIC INPUT statement being executed.READ on the other hand, may be different, or may not be different, based on whether the Tektronix BASIC ROM issues an INPUT @2,6: command to fetch the TYPE of the next BINARY data element prior to each READ of a BINARY data element. I seriously doubt the BASIC READ command will operate that way (too much GPIB overhead - huge performance impact).I imagine the READ command will be a byte by byte transfer - just like INPUT and the BASIC ROM will be expecting the first two bytes are the TYPE - in binary, followed by the numeric or string variable with the data length encoded in the TYPE bytes.From the 4924 Tape Service Manual page B-4 description of the INPUT @2,6 GPIB command to fetch the TYPE, I expect this is just for a user program to examine the TYPE of the next binary data item. My BASIC programs that used BINARY data files made no such call. They just did READ commands to fetch the numeric or string variables.Using BINARY data files on Tektronix programs was a lot faster than using ASCII data files - due to the elimination of processing ASCII numbers into Tek BASIC 64-bit internal floating point format (Tek BASIC did not support integer data type).

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 06:30:52 pm
content: Quote from: mmcgraw74 on July 12, 2021, 04:46:00 pmIn support of my contention above, the INPUT @x,6:A command only returns one ASCII integer with the TYPE, it doesn't return the length of the data item, so it can't possibly be used by the BASIC ROM.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 12, 2021, 07:11:25 pm
content: I see from the screenshot how your program is printing only the first number in each line to the screen.I am now totally baffled. If the the emulator is not expected to look at delimiters, and as can be seen from your screenshot, Tek BASIC is parsing because it is chopping the data into numbers, and furthermore the INPUT or other commands do not indicate how many bytes to send, then how is the emulator to know how many bytes to send each time an INPUT command is called?Each INPUT command cannot send just one byte either as each data type is different in size and each INPUT command can include multiple variables and mixed variable types so the data length BASIC expects back needs to correspond to the sizes of the variables requested.So does the emulator just keep sending until the Tek 405x signals it to stop in some way? If so, then what is the signal? The Tek can't send a data byte at the same time as the emulator is already doing so. Nor does EOI seem likely because EOI is usually signalled by the sender.I did come across this description in the manual for the input command:QuoteSo is the answer to send the next "record" or 256 bytes and let the Tek decide how to process the information? That would seem in line with your comment about parsing, but we have already seen that sending a whole line didn't result in the data being read correctly either.I did wonder whether it is a simple matter of handshaking but again, that didn't work for sending a complete line. What I could try is a simple "send to the next comma" and see what happens.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 07:30:48 pm
content: The Tektronix is the GPIB controller and is either the source of the data or listener for the data and completely controls the pacing of the bytes on input, so the GPIB device always operates one byte at a time, not on data blocks.All I'm saying is the Tektronix does the data parsing for INPUT and READ commands - the tape emulator would only have to parse a BINARY data stream if requested by the program using the INPUT @x,6: command, which I have NEVER seen in any Tektronix program.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 12, 2021, 07:58:10 pm
content: Quote from: mmcgraw74 on July 12, 2021, 07:30:48 pmI take your point on that. When I do a ++read to read my DMM for example, the controller addresses the meter and tells it to send a reading. The meter sends a reading of a specific length. The controller does not know how long that stream of data will be. It only knows that whatever the meter sends it will be terminated with a specific terminator byte or bytes (CRLF sequence) and maybe an EOI signal. Thats how it knows when to stop receiving and forwarded the data to the controlling program which interprets it and does something with it.So I guess applying this in reverse, the emulator (which is a device like the meter) receives a command from the controller (Tek) in response to which it has to send some data. That stream of data has to be finite just like the meter reading. It can't just keep sending indefinitely. I agree that the Tek hardware knows or cares nothing about that chunk of data it just received but passes it on to BASIC to interpret. However, it does need to know when to drop out of the receiving loop and pass control back to the BASIC interpreter.So yes, the GPIB handshake process itself is a byte by byte process and knows nothing about terminators or the data content being passed, but each end must know when to start and stop. With my DMM, the signal to stop is a CRLF sequence or an EOI. So what is it with the Tek? It could, I suppose, be a timeout?I am working on the assumption that the Tek uses standard delimiters like the comma. One of the manuals did state it can use others such as space and CR but the common default for ASCII data is the comma. The version I have just pushed up simply reads up to the next comma or end of file. I would interested to see what it does.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 08:43:02 pm
content: Quote from: WaveyDipole on July 12, 2021, 07:58:10 pmThe Emulator should not care about delimiters during the INPUT command. The Tektronix will decide if the INPUT command is satisfied and end the command, OR if the Emulator hits the end of file, it will return the EOF character 127 with EOI asserted to end the command.I will download and check out your version 28 right now

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 12, 2021, 09:40:12 pm
content: Version 28 did not get as far as your previous version - the Tektronix hung on line 174 in the program (photo in previous post) with only K0(1) holding a value and K5(1) was uninitialized with J=1.I believe we need to open the buffer in the FIND command after the file is found.The INPUT command would just access that buffer and when the INPUT is terminated by the Tektronix, leave the buffer open for the next INPUT command.If the INPUT function reaches EOF, it would return the EOF character with EOI asserted to the Tektronix to end the command, and the INPUT function would close the file, otherwise the file would remain open until EOF was reached or a new FIND command is issued by the Tektronix - in which the FIND routine would close the previous file and open a new file and buffer.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 13, 2021, 07:39:47 am
content: Thank you for giving it a try. Clearly I was on the wrong track.Quote from: mmcgraw74 on July 12, 2021, 08:43:02 pmIn that case, maybe the INPUT command would have to just send the whole file with EOI on the last byte just like in the OLD command and rely on the Tek to control the transmission via the handshaking.Quote from: mmcgraw74 on July 12, 2021, 09:40:12 pmI agree and have already implemented that. FIND has to leave the file handle open otherwise the emulator can't subsequently read from or write to the file. I have also changed the stream type from ifstream to fstream as FIND does not know whether the file will subsequently be read from or written to. In the version just uploaded I have copied the contents of the OLD function into INPUT. The only change is that it checks for the D file type instead of P and closes the file once it has reached EOF. As you mention, this will rely on the Tek to control the input through handshaking.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 13, 2021, 12:28:44 pm
content: I'm downloading your version 29 to test right now!

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 13, 2021, 01:05:16 pm
content: Hmm, it stopped with a GPIB error message on line 174 again after reading only one value for K0 and K5.Further attempts at INPUT@5: also generate the GPIB error message 69 (see 4050 BASIC Reference booklet error messages).I see that the file is opened on entering the INPUT command. I think this is one problem as the BASIC program will issue one INPUT command each time through the loop.I still think the open needs to move into the FIND command and the INPUT and even OLD will just consume the open buffer.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 13, 2021, 01:32:17 pm
content: Sorry, missed that. Should have removed that line. Just comment it out and try again. The file is already being opened in FIND. Each INPUT (and therefore open()) would reset the file pointer to zero otherwise.Also noticed that this line:if (sdin.peek() == EOF) {Needs to be corrected to this:if (sdinout.peek() == EOF) {The perils of copy and paste!BTW, the Pandauino arrived about an hour ago!

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 13, 2021, 03:48:23 pm
content: I commented out the ifstream sdin(path) line in INPUT - hung on line 174 without getting any data.I don't think the path statements are needed in INPUT anymore either.I still think INPUT is closing the stream on first exit.Glad to hear the Pandauino arrived!I wouldn't wait for the auction to end - I would make an offer - say 100 pounds before the auction is over.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 13, 2021, 04:32:48 pm
content: Quote from: mmcgraw74 on July 13, 2021, 03:48:23 pmQuote from: mmcgraw74 on July 13, 2021, 03:48:23 pmI concur.Quote from: mmcgraw74 on July 13, 2021, 03:48:23 pmThere appears to be nothing that actually closes it, but the implication might be that it is reading to EOF every time it is called, in which case the read is not being controlled. It just runs as far as it can. This has me really baffled and I am not sure what to try next.Quote from: mmcgraw74 on July 13, 2021, 03:48:23 pmI tried an offer of 120GBP and 130GPB and both were automatically rejected. I don't think it will go for less than the starting price especially as he had it advertised for 250 elsewhere.Do you have any logic analyser traces when using INPUT?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 13, 2021, 07:01:38 pm
content: Are you going to bid at the last moment?

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 13, 2021, 07:05:37 pm
content: Quote from: mmcgraw74 on July 07, 2021, 11:34:31 pmI have been catching up on my reading and had a look at section 4 of this manual again and went step by step through the handshaking process. It seems there are two ways that the Tek controls the process. one is by holding off the NRFD and NDAC lines. The manual states that the processes involved take at most 12ms and the emulator timeout is set at 5000ms (5 seconds) so there should be no problem with the timeout being too short.The second is by asserting ATN when it has read enough data to satisfy all variables in the current INPUT statement. The emulator should, at this point, immediately terminate the send loop and go to attention to await the next command. This is the element that I think was missing with the result that the loop would instead run to the end of the file on every INPUT command, starting at the beginning of the file again with each subsequent INPUT request.I have re-jigged the code again to process the file byte-by-byte instead of by line or buffer-full, but also added the means to drop out as soon as ATN gets asserted. I am hoping that this will now interact correctly, allowing the Tek to control the emulator data flow. After each INPUT command is stopped, the current file pointer should remain at the last read position and the next INPUT command should pick up where the previous one left off until it reaches EOF. I could only test as far as ensuring that the complete file is sent across GPIB, which it is.I have uploaded the updated code.BTW, yes, I think I will now leave the bidding it as late as possible. Still a couple of hours left an no bids.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 13, 2021, 08:20:55 pm
content: I tried your v29 build on my 4054A - similar result, line 174 was run once, both K0 and K5 got one number, J=2, BREAK key twice returned to BASIC.I then tried simpler experiment on the 4054A:PRI @5,19:"ROOT"FIND @5:2INPUT@5:A$,B$,C$this worked BUT A$,B$,C$ ONLY contained the three directory strings NOT the entire header string from file 2.I imagine this is because there are no quotes around the string and Tektronix used space as a string delimiter in this case.However now trying a second INPUT@5:D$ resulted in hang in I/O until I pressed BREAK key twice. D$ contained no data.So it appears leaving the first INPUT command prevents further data access.I'll have to take my laptop into the other room with the 4054A to capture the serial debug output.Taking the logic analyzer into the other room would require I make space near the 4054A - so I'll try the laptop first.BTW - the 4052 continues to hang on poweron if the Emulator is powered. I have to poweron the 4052, then plug the USB cable into the Emulator.The 4052 appeared to match the 4054A results on a similar experiment - but had an error message on the second INPUT command instead of hanging in I/O until I pressed the BREAK key twice.PRI @5,19:"ROOT"FIND @5:2INPUT@5:A$,B$this worked BUT A$ and B$ only contained the first two directory strings, not the rest of the header info in file 2 (matched the 4054A).However INPUT@5:A$,B$ resulted in Tektronix printing a GPIB error 69 (this is different)Here are the serial debug messages for the 4052 test:Note I updated the Config.h version number to 29 with today's dateCode:AR488-Store ready (device).++verAR488 GPIB storage, ver. 0.05.29, 13/07/2021Executing secondary address command: 73stgc_073_h: started CD handler...OTstgc_0x73_h: received directory name: ROOTstgc_0x73_h: set directory name: /ROOT/stgc_0x62_h: started CLOSE handler...stgc_0x62_h: closing: ...stgc_0x62_h: done.stgc_0x73_h: end CD handler.Executing secondary address command: 7Bstgc_0x7B_h: started FIND handler...stgc_0x7B_h: received parameter: 2stgc_0x7B_h: found: 2 ASCII DATA [DIR LIST] 4stgc_0x7B_h: type: Dstgc_0x7B_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /ROOT/2 ASCII DATA [DIR LIST] 4...stgc_0x62_h: started CLOSE handler...stgc_0x62_h: closing: 2 ASCII DATA [DIR LIST] 4...stgc_0x62_h: done.stgc_0x6D_h: done.Here is the debug serial console output - note CLOSE handler after first INPUT AND no second "started INPUT handler"

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 13, 2021, 11:10:21 pm
content: Quote from: mmcgraw74 on July 13, 2021, 08:20:55 pmNot sure what you mean? Unless you have a different version, the file seems to contain only 3 directories on 3 lines?/root//Games//UTILITIES/So I'm not sure what is missing? Each CR at the end of the line would be interpreted by the Tek as a a delimiter for each of the 3 strings read into A$, B$ and C$.Quote from: mmcgraw74 on July 13, 2021, 08:20:55 pmIs this on another file? In the file above I would expect there to be no more data after the 3 elements had been read. Having said that, the emulator ought to be just dropping the transmission if it can't read any more data and not hanging the Tek.Quote from: mmcgraw74 on July 13, 2021, 08:20:55 pmThere are 3 variables and 3 items read so after that we have reached EOF hence I think the close. However, perhaps the call to close should be removed as the file will be closed on the next FIND or manually on CLOSE.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 14, 2021, 12:17:28 am
content: My mistake on the contents of ROOT/2, Yes, the file only contains the three subdirectories on my original sd card image.But my 4052 test I only input two strings, not three on the first INPUT and the second INPUT hung.So INPUT is still not working correctly.Same thing happens on my 4054A

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 14, 2021, 08:21:44 am
content: Fair enough and it is clearly evident that this is still not working right. The console output shows that we are getting to the end of the file and apparently not breaking out after the first INPUT command. However, I am struggling to see what else we are missing. I had a look over the manual again this morning hoping that a fresh pair of eyes might help.Section 4 of the 070-2270-00_4051_GPIB_HW_Supp_Jul81.pdf manual describes in detail the processing of the INPUT command which in summary is as follows:Initially the 4051 sets attention and the device responds by goint to attention and accepting the command from the Tek. The primary and then secondar address is sent using normal handshaking.The device waits until ATN goes up and starts sending data. The manual again describes the normal handshaking process.Apparently the Tek accepts data until "a CR delimiter is received, an alternate delimiter is received, or until 72 characters are received, whichever occurs first.". At this point the Tek stops the data transfer by holding NRFD low and processes the information. This takes between 4ms and 12ms. The Tek "searches the contents of the I/O buffer for valid numeric data which it then converts to floating point format and assigns to a variable in RAM. If a string is specified, it will read all the characters up to the delimiter into the string variable.The Tek then resumes collecting more data up to a delimiter or 72 characters from the device and again stops and processes the buffer.After all variables have been assigned, the Tek "terminates the operation by activating ATN and issuing an UNTALK/UNLISTEN sequence over GPIB".So what I understood from this is that the ATN comes at the end of each INPUT command once all the provided variables have been read to stop transmission.Of all the ASCII data files looked at so far, none have lines linger than 72 characters, so the Tek should read each line up to the CR, and then pause (for up to 12ms) and process that line. If all variables in the INPUT statement have been satisfied it should then issue ATN and stop transmission. If not, then it should proceed to read up to the next delimiter or until 72 characters have been reached and again process that line until such time that all variables have been read. It then issues ATN to stop transmission. If there is any more data to be read then the process is repeated in the next INPUT statement.As you pointed out, the interpretation of the terminators is left up to the Tek so the emulator sends byte-by-byte and waits for the Tek to stop transmission once the INPUT statement has been satisfied.I have pushed up an update. It doesn't really change anything much except that the close function is commented out and it adds a a couple of debug information bits. I would like to see the console output when we are reading one variable at a time. I will let you know if I have any bright ideas in the meantime.BTW, I have also been doing a bit of work on the binary format in READ, i.e. reading the binary header then reading x bytes according to the length specified in the header. Are there any files on the SD card that I can test with this? I have it working in principle in both actual binary and HEX format but would like to test it on real data files. Did you do any testing of the binary read?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 14, 2021, 12:06:40 pm
content: I will check out your v30 version and get back to you.Yes, files 3 and 6 in the UTILITIES directory are both BINARY data files captured from tape.However, my capture program is over serial, so my BASIC program to recover an entire tape converts each byte of a binary file into two ASCII HEX characters to ensure that the serial program does not interpret and strip control characters from the transfer.My continuedDEV.ino READ_file and READ_one both have logic for BINARY files (PROGRAM or DATA) to convert each two ASCII HEX characters into a single binary byte. I have been using Realterm successfully as the PC serial program at 115200 8n1 to display the ASCII and BINARY files over debug serial output.I will try to capture a single numeric and single string variable GPIB transfer on my 4052 with my logic analyzer.I have found this website HEX to binary converter useful in decoding one of my ASCII HEX files to binary to examine with HxD:https://tomeko.net/online_tools/hex_to_file.php?lang=en

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 14, 2021, 07:16:19 pm
content: that was only the first half of the trace listing.Here is the second half of the trace listing:500 8 ns CE 1 0 1 1 1 0501 8 ns CE 1 0 1 1 0 0502 21.38 us CE 1 0 0 1 0 0503 32.94 us CE 1 1 0 1 0 0504 89.16 us CE 1 1 0 1 1 0505 3.312 us FF 1 1 0 1 1 0506 29.66 us FF 1 0 0 1 1 0507 59.69 us FF 1 0 1 1 1 0508 32.77 us CD 1 0 1 1 1 0509 8 ns C9 1 0 1 1 1 0510 8 ns DF 1 0 1 1 1 0511 8 ns C9 1 0 1 1 1 0512 9.176 us C9 1 0 1 1 0 0513 8 ns C9 1 0 1 1 1 0514 8 ns C9 1 0 1 1 0 0515 25.74 us C9 1 0 0 1 0 0516 33.46 us C9 1 1 0 1 0 0517 84.29 us C9 1 1 0 1 1 0518 3.320 us FF 1 1 0 1 1 0519 303.7 us FF 1 0 0 1 1 0520 59.68 us FF 1 0 1 1 1 0521 82.38 us F1 1 0 1 1 1 0522 8 ns F1 1 0 1 1 1 0523 8 ns DD 1 0 1 1 1 0524 8 ns D1 1 0 1 1 1 0525 9.176 us D1 1 0 1 1 0 0526 8 ns D1 1 0 1 1 1 0527 8 ns D1 1 0 1 1 0 0528 33.22 us D1 1 0 0 1 0 0529 32.93 us D1 1 1 0 1 0 0530 77.34 us D1 1 1 0 1 1 0531 3.320 us FF 1 1 0 1 1 0532 14.26 us FF 1 0 0 1 1 0533 59.68 us FF 1 0 1 1 1 0534 48.17 us DF 1 0 1 1 1 0535 8 ns C9 1 0 1 1 1 0536 8 ns DF 1 0 1 1 1 0537 8 ns C9 1 0 1 1 1 0538 9.176 us C9 1 0 1 1 0 0539 8 ns C9 1 0 1 1 1 0540 8 ns C9 1 0 1 1 0 0541 38.09 us C9 1 0 0 1 0 0542 32.94 us C9 1 1 0 1 0 0543 72.46 us C9 1 1 0 1 1 0544 3.320 us FF 1 1 0 1 1 0545 18.08 us FF 1 0 0 1 1 0546 59.68 us FF 1 0 1 1 1 0547 44.36 us CA 1 0 1 1 1 0548 8 ns FF 1 0 1 1 1 0549 8 ns CE 1 0 1 1 1 0550 8 ns CA 1 0 1 1 1 0551 9.168 us CA 1 0 1 1 0 0552 8 ns CA 1 0 1 1 0 0553 8 ns CA 1 0 1 1 1 0554 8 ns CA 1 0 1 1 0 0555 42.43 us CA 1 0 0 1 0 0556 32.94 us CA 1 1 0 1 0 0557 68.12 us CA 1 1 0 1 1 0558 3.312 us FB 1 1 0 1 1 0559 8 ns FF 1 1 0 1 1 0560 22.42 us FF 1 0 0 1 1 0561 59.69 us FF 1 0 1 1 1 0562 40.01 us DF 1 0 1 1 1 0563 8 ns FF 1 0 1 1 1 0564 8 ns DF 1 0 1 1 1 0565 9.184 us DF 1 0 1 1 0 0566 8 ns DF 1 0 1 1 1 0567 8 ns DF 1 0 1 1 0 0568 19.55 us DF 1 0 0 1 0 0569 32.42 us DF 1 1 0 1 0 0570 97.78 us DF 1 1 0 1 1 0571 3.320 us FF 1 1 0 1 1 0572 21.04 us FF 1 0 0 1 1 0573 59.68 us FF 1 0 1 1 1 0574 41.39 us DF 1 0 1 1 1 0575 8 ns DF 1 0 1 1 1 0576 8 ns FF 1 0 1 1 1 0577 8 ns DF 1 0 1 1 1 0578 9.176 us DF 1 0 1 1 0 0579 8 ns DF 1 0 1 1 1 0580 8 ns DF 1 0 1 1 0 0581 17.65 us DF 1 0 0 1 0 0582 32.94 us DF 1 1 0 1 0 0583 92.91 us DF 1 1 0 1 1 0584 3.312 us FF 1 1 0 1 1 0585 26.98 us FF 1 0 0 1 1 0586 59.68 us FF 1 0 1 1 1 0587 35.46 us CE 1 0 1 1 1 0588 8 ns EE 1 0 1 1 1 0589 8 ns CE 1 0 1 1 1 0590 9.184 us CE 1 0 1 1 0 0591 8 ns CE 1 0 1 1 1 0592 8 ns CE 1 0 1 1 0 0593 23.58 us CE 1 0 0 1 0 0594 32.94 us CE 1 1 0 1 0 0595 86.98 us CE 1 1 0 1 1 0596 3.312 us FF 1 1 0 1 1 0597 31.85 us FF 1 0 0 1 1 0598 60.22 us FF 1 0 1 1 1 0599 30.06 us CF 1 0 1 1 1 0600 8 ns CE 1 0 1 1 1 0601 8 ns DF 1 0 1 1 1 0602 8 ns CE 1 0 1 1 1 0603 9.176 us CE 1 0 1 1 0 0604 8 ns CE 1 0 1 1 1 0605 8 ns CE 1 0 1 1 0 0606 28.98 us CE 1 0 0 1 0 0607 32.94 us CE 1 1 0 1 0 0608 81.57 us CE 1 1 0 1 1 0609 3.320 us FF 1 1 0 1 1 0610 37.25 us FF 1 0 0 1 1 0611 59.68 us FF 1 0 1 1 1 0612 31.38 us CB 1 0 1 1 1 0613 8 ns FB 1 0 1 1 1 0614 8 ns CF 1 0 1 1 1 0615 8 ns CB 1 0 1 1 1 0616 9.176 us CB 1 0 1 1 0 0617 8 ns CB 1 0 1 1 1 0618 8 ns CB 1 0 1 1 0 0619 27.13 us CB 1 0 0 1 0 0620 33.46 us CB 1 1 0 1 0 0621 82.90 us CB 1 1 0 1 1 0622 3.312 us FB 1 1 0 1 1 0623 8 ns FF 1 1 0 1 1 0624 35.92 us FF 1 0 0 1 1 0625 59.69 us FF 1 0 1 1 1 0626 26.50 us FD 1 0 1 1 1 0627 8 ns F1 1 0 1 1 1 0628 8 ns DF 1 0 1 1 1 0629 8 ns D1 1 0 1 1 1 0630 9.176 us D1 1 0 1 1 0 0631 8 ns D1 1 0 1 1 1 0632 8 ns D1 1 0 1 1 0 0633 33.06 us D1 1 0 0 1 0 0634 32.41 us D1 1 1 0 1 0 0635 78.02 us D1 1 1 0 1 1 0636 3.320 us FF 1 1 0 1 1 0637 13.05 us FF 1 0 0 1 1 0638 60.21 us FF 1 0 1 1 1 0639 48.86 us DF 1 0 1 1 1 0640 8 ns FF 1 0 1 1 1 0641 8 ns DF 1 0 1 1 1 0642 9.176 us DF 1 0 1 1 0 0643 8 ns DF 1 0 1 1 0 0644 8 ns DF 1 0 1 1 1 0645 8 ns DF 1 0 1 1 0 0646 38.46 us DF 1 0 0 1 0 0647 32.94 us DF 1 1 0 1 0 0648 72.09 us DF 1 1 0 1 1 0649 3.312 us FF 1 1 0 1 1 0650 19.51 us FF 1 0 0 1 1 0651 59.68 us FF 1 0 1 1 1 0652 42.93 us DF 1 0 1 1 1 0653 8 ns FF 1 0 1 1 1 0654 8 ns DF 1 0 1 1 1 0655 9.184 us DF 1 0 1 1 0 0656 8 ns DF 1 0 1 1 1 0657 8 ns DF 1 0 1 1 0 0658 43.34 us DF 1 0 0 1 0 0659 32.93 us DF 1 1 0 1 0 0660 73.48 us DF 1 1 0 1 1 0661 3.320 us FF 1 1 0 1 1 0662 17.06 us FF 1 0 0 1 1 0663 59.68 us FF 1 0 1 1 1 0664 45.37 us DF 1 0 1 1 1 0665 8 ns DF 1 0 1 1 1 0666 8 ns FF 1 0 1 1 1 0667 8 ns DF 1 0 1 1 1 0668 9.176 us DF 1 0 1 1 0 0669 8 ns DF 1 0 1 1 1 0670 8 ns DF 1 0 1 1 0 0671 41.42 us DF 1 0 0 1 0 0672 32.94 us DF 1 1 0 1 0 0673 69.14 us DF 1 1 0 1 1 0674 3.312 us FF 1 1 0 1 1 0675 21.42 us FF 1 0 0 1 1 0676 59.68 us FF 1 0 1 1 1 0677 41.02 us DF 1 0 1 1 1 0678 8 ns FF 1 0 1 1 1 0679 8 ns DF 1 0 1 1 1 0680 9.184 us DF 1 0 1 1 0 0681 8 ns DF 1 0 1 1 1 0682 8 ns DF 1 0 1 1 0 0683 18.54 us DF 1 0 0 1 0 0684 32.41 us DF 1 1 0 1 0 0685 92.54 us DF 1 1 0 1 1 0686 3.312 us FF 1 1 0 1 1 0687 26.29 us FF 1 0 0 1 1 0688 59.68 us FF 1 0 1 1 1 0689 36.15 us CE 1 0 1 1 1 0690 8 ns CE 1 0 1 1 1 0691 8 ns DF 1 0 1 1 1 0692 8 ns CE 1 0 1 1 1 0693 9.176 us CE 1 0 1 1 0 0694 8 ns CE 1 0 1 1 1 0695 8 ns CE 1 0 1 1 0 0696 22.89 us CE 1 0 0 1 0 0697 32.94 us CE 1 1 0 1 0 0698 87.66 us CE 1 1 0 1 1 0699 3.320 us FF 1 1 0 1 1 0700 32.22 us FF 1 0 0 1 1 0701 59.68 us FF 1 0 1 1 1 0702 30.22 us C8 1 0 1 1 1 0703 8 ns FF 1 0 1 1 1 0704 8 ns C8 1 0 1 1 1 0705 9.176 us C8 1 0 1 1 0 0706 8 ns C8 1 0 1 1 1 0707 8 ns C8 1 0 1 1 1 0708 8 ns C8 1 0 1 1 0 0709 28.82 us C8 1 0 0 1 0 0710 32.94 us C8 1 1 0 1 0 0711 87.99 us C8 1 1 0 1 1 0712 3.312 us FF 1 1 0 1 1 0713 96 ns FF 1 1 0 1 1 0714 8 ns FF 1 1 0 1 1 0715 30.74 us FF 1 0 0 1 1 0716 60.21 us FF 1 0 1 1 1 0717 31.07 us F1 1 0 1 1 1 0718 8 ns F1 1 0 1 1 1 0719 8 ns D5 1 0 1 1 1 0720 8 ns D1 1 0 1 1 1 0721 9.176 us D1 1 0 1 1 0 0722 8 ns D1 1 0 1 1 1 0723 8 ns D1 1 0 1 1 0 0724 27.97 us D1 1 0 0 1 0 0725 32.94 us D1 1 1 0 1 0 0726 82.58 us D1 1 1 0 1 1 0727 3.312 us F1 1 1 0 1 1 0728 8 ns FF 1 1 0 1 1 0729 36.23 us FF 1 0 0 1 1 0730 59.68 us FF 1 0 1 1 1 0731 26.20 us CF 1 0 1 1 1 0732 8 ns C7 1 0 1 1 1 0733 8 ns DF 1 0 1 1 1 0734 8 ns C7 1 0 1 1 1 0735 9.176 us C7 1 0 1 1 0 0736 8 ns C7 1 0 1 1 1 0737 8 ns C7 1 0 1 1 0 0738 32.31 us C7 1 0 0 1 0 0739 33.46 us C7 1 1 0 1 0 0740 77.71 us C7 1 1 0 1 1 0741 3.320 us FF 1 1 0 1 1 0742 13.36 us FF 1 0 0 1 1 0743 59.15 us FF 1 0 1 1 1 0744 49.61 us CF 1 0 1 1 1 0745 8 ns FF 1 0 1 1 1 0746 8 ns CF 1 0 1 1 1 0747 9.176 us CF 1 0 1 1 0 0748 8 ns CF 1 0 1 1 0 0749 8 ns CF 1 0 1 1 1 0750 8 ns CF 1 0 1 1 0 0751 38.24 us CF 1 0 0 1 0 0752 32.41 us CF 1 1 0 1 0 0753 72.84 us CF 1 1 0 1 1 0754 3.312 us FF 1 1 0 1 1 0755 18.23 us FF 1 0 0 1 1 0756 60.22 us FF 1 0 1 1 1 0757 49.93 us DF 1 0 1 1 1 0758 8 ns FF 1 0 1 1 1 0759 8 ns DF 1 0 1 1 1 0760 9.184 us DF 1 0 1 1 0 0761 8 ns DF 1 0 1 1 1 0762 8 ns DF 1 0 1 1 0 0763 37.38 us DF 1 0 0 1 0 0764 32.94 us DF 1 1 0 1 0 0765 73.16 us DF 1 1 0 1 1 0766 3.320 us FF 1 1 0 1 1 0767 18.43 us FF 1 0 0 1 1 0768 59.69 us FF 1 0 1 1 1 0769 43.99 us DF 1 0 1 1 1 0770 9.200 us DF 1 0 1 1 0 0771 8 ns DF 1 0 1 1 1 0772 8 ns DF 1 0 1 1 0 0773 42.26 us DF 1 0 0 1 0 0774 32.93 us DF 1 1 0 1 0 0775 68.30 us DF 1 1 0 1 1 0776 3.312 us FF 1 1 0 1 1 0777 22.26 us FF 1 0 0 1 1 0778 59.68 us FF 1 0 1 1 1 0779 40.18 us CE 1 0 1 1 1 0780 8 ns FF 1 0 1 1 1 0781 8 ns CE 1 0 1 1 1 0782 9.184 us CE 1 0 1 1 0 0783 8 ns CE 1 0 1 1 1 0784 8 ns CE 1 0 1 1 0 0785 18.85 us CE 1 0 0 1 0 0786 32.94 us CE 1 1 0 1 0 0787 91.70 us CE 1 1 0 1 1 0788 3.312 us FF 1 1 0 1 1 0789 27.66 us FF 1 0 0 1 1 0790 60.22 us FF 1 0 1 1 1 0791 34.25 us CE 1 0 1 1 1 0792 8 ns CE 1 0 1 1 1 0793 8 ns DE 1 0 1 1 1 0794 8 ns CE 1 0 1 1 1 0795 9.176 us CE 1 0 1 1 0 0796 8 ns CE 1 0 1 1 1 0797 8 ns CE 1 0 1 1 0 0798 24.78 us CE 1 0 0 1 0 0799 32.42 us CE 1 1 0 1 0 0800 92.54 us CE 1 1 0 1 1 0801 3.320 us FF 1 1 0 1 1 0802 25.74 us FF 1 0 0 1 1 0803 59.15 us FF 1 0 1 1 1 0804 37.22 us DF 1 0 1 1 1 0805 8 ns C7 1 0 1 1 1 0806 8 ns FF 1 0 1 1 1 0807 8 ns C7 1 0 1 1 1 0808 9.176 us C7 1 0 1 1 0 0809 8 ns C7 1 0 1 1 1 0810 8 ns C7 1 0 1 1 1 0811 8 ns C7 1 0 1 1 0 0812 21.81 us C7 1 0 0 1 0 0813 32.94 us C7 1 1 0 1 0 0814 88.74 us C7 1 1 0 1 1 0815 3.312 us FF 1 1 0 1 1 0816 298.2 us FF 1 0 0 1 1 0817 59.68 us FF 1 0 1 1 1 0818 81.64 us F1 1 0 1 1 1 0819 8 ns FF 1 0 1 1 1 0820 8 ns D1 1 0 1 1 1 0821 9.176 us D1 1 0 1 1 0 0822 8 ns D1 1 0 1 1 1 0823 8 ns D1 1 0 1 1 0 0824 33.44 us D1 1 0 0 1 0 0825 32.94 us D1 1 1 0 1 0 0826 77.11 us D1 1 1 0 1 1 0827 3.320 us FF 1 1 0 1 1 0828 14.49 us FF 1 0 0 1 1 0829 59.68 us FF 1 0 1 1 1 0830 47.95 us DF 1 0 1 1 1 0831 8 ns FF 1 0 1 1 1 0832 8 ns DF 1 0 1 1 1 0833 15.44 us DF 1 0 1 1 0 0834 8 ns DF 1 0 1 1 1 0835 8 ns DF 1 0 1 1 0 0836 33.64 us DF 1 0 0 1 0 0837 33.46 us DF 1 1 0 1 0 0838 76.38 us DF 1 1 0 1 1 0839 3.312 us FF 1 1 0 1 1 0840 14.70 us FF 1 0 0 1 1 0841 59.15 us FF 1 0 1 1 1 0842 48.27 us DF 1 0 1 1 1 0843 9.200 us DF 1 0 1 1 0 0844 8 ns DF 1 0 1 1 1 0845 8 ns DF 1 0 1 1 0 0846 39.58 us DF 1 0 0 1 0 0847 32.94 us DF 1 1 0 1 0 0848 70.98 us DF 1 1 0 1 1 0849 3.320 us FF 1 1 0 1 1 0850 19.56 us FF 1 0 0 1 1 0851 60.22 us FF 1 0 1 1 1 0852 42.34 us DF 1 0 1 1 1 0853 8 ns FF 1 0 1 1 1 0854 8 ns DF 1 0 1 1 1 0855 9.176 us DF 1 0 1 1 0 0856 8 ns DF 1 0 1 1 0 0857 8 ns DF 1 0 1 1 1 0858 8 ns DF 1 0 1 1 0 0859 16.16 us DF 1 0 0 1 0 0860 32.93 us DF 1 1 0 1 0 0861 94.40 us DF 1 1 0 1 1 0862 3.312 us FF 1 1 0 1 1 0863 24.97 us FF 1 0 0 1 1 0864 59.68 us FF 1 0 1 1 1 0865 36.85 us BF 1 0 1 1 1 0866 8 ns FF 1 0 1 1 1 0867 8 ns BF 1 0 1 1 1 0868 608 ns BA 1 0 1 1 1 0869 8 ns BA 1 0 1 1 1 0870 8 ns BE 1 0 1 1 1 0871 8 ns BA 1 0 1 1 1 0872 9.176 us BA 1 0 1 1 0 0873 8 ns BA 1 0 1 1 1 0874 8 ns BA 1 0 1 1 0 0875 21.03 us BA 1 0 0 1 0 0876 32.94 us BA 1 1 0 1 0 0877 89.51 us BA 1 1 0 1 1 0878 2.688 us FA 1 1 0 1 1 0879 632 ns FF 1 1 0 1 1 0880 29.30 us FF 1 0 0 1 1 0881 59.68 us FF 1 0 1 1 1 0882 39.38 us DF 1 0 1 1 1 0883 8 ns CE 1 0 1 1 1 0884 8 ns FF 1 0 1 1 1 0885 8 ns CE 1 0 1 1 1 0886 9.176 us CE 1 0 1 1 0 0887 8 ns CE 1 0 1 1 1 0888 8 ns CE 1 0 1 1 0 0889 19.13 us CE 1 0 0 1 0 0890 33.47 us CE 1 1 0 1 0 0891 90.90 us CE 1 1 0 1 1 0892 3.312 us FF 1 1 0 1 1 0893 27.93 us FF 1 0 0 1 1 0894 59.68 us FF 1 0 1 1 1 0895 34.51 us C6 1 0 1 1 1 0896 8 ns F7 1 0 1 1 1 0897 8 ns C6 1 0 1 1 1 0898 9.184 us C6 1 0 1 1 0 0899 8 ns C6 1 0 1 1 1 0900 8 ns C6 1 0 1 1 0 0901 25.06 us C6 1 0 0 1 0 0902 32.41 us C6 1 1 0 1 0 0903 86.02 us C6 1 1 0 1 1 0904 3.312 us F7 1 1 0 1 1 0905 8 ns FF 1 1 0 1 1 0906 32.79 us FF 1 0 0 1 1 0907 59.68 us FF 1 0 1 1 1 0908 29.64 us F9 1 0 1 1 1 0909 8 ns F1 1 0 1 1 1 0910 8 ns DF 1 0 1 1 1 0911 8 ns D1 1 0 1 1 1 0912 9.176 us D1 1 0 1 1 0 0913 8 ns D1 1 0 1 1 1 0914 8 ns D1 1 0 1 1 0 0915 29.40 us D1 1 0 0 1 0 0916 32.41 us D1 1 1 0 1 0 0917 81.68 us D1 1 1 0 1 1 0918 3.320 us FF 1 1 0 1 1 0919 37.67 us FF 1 0 0 1 1 0920 59.68 us FF 1 0 1 1 1 0921 24.77 us CB 1 0 1 1 1 0922 8 ns FF 1 0 1 1 1 0923 8 ns CB 1 0 1 1 1 0924 9.176 us CB 1 0 1 1 0 0925 8 ns CB 1 0 1 1 1 0926 8 ns CB 1 0 1 1 1 0927 8 ns CB 1 0 1 1 0 0928 34.27 us CB 1 0 0 1 0 0929 32.94 us CB 1 1 0 1 0 0930 82.54 us CB 1 1 0 1 1 0931 3.312 us FF 1 1 0 1 1 0932 37.35 us FF 1 0 0 1 1 0933 59.68 us FF 1 0 1 1 1 0934 25.09 us CF 1 0 1 1 1 0935 9.200 us CF 1 0 1 1 0 0936 8 ns CF 1 0 1 1 1 0937 8 ns CF 1 0 1 1 0 0938 33.94 us CF 1 0 0 1 0 0939 32.42 us CF 1 1 0 1 0 0940 77.13 us CF 1 1 0 1 1 0941 3.312 us EF 1 1 0 1 1 0942 8 ns FF 1 1 0 1 1 0943 13.94 us FF 1 0 0 1 1 0944 59.68 us FF 1 0 1 1 1 0945 48.50 us F2 1 0 1 1 1 0946 8 ns FF 1 0 1 1 1 0947 8 ns F2 1 0 1 1 1 0948 9.176 us F2 1 0 1 1 0 0949 8 ns F2 1 0 1 1 1 0950 8 ns F2 1 0 1 1 0 0951 38.82 us F2 1 0 0 1 0 0952 33.47 us F2 1 1 0 1 0 0953 71.19 us F2 1 1 0 1 1 0954 3.320 us FF 1 1 0 1 1 0955 19.87 us FF 1 0 0 1 1 0956 2.992 ms FF 0 0 0 1 1 0957 27.75 us FF 0 1 1 1 1 0958 8 ns FF 1 0 0 1 1 0959 8 ns FF 0 0 0 1 1 0960 8 ns F3 0 0 0 1 1 0961 8 ns FF 0 0 0 1 1 0962 8 ns 93 0 0 0 1 1 0963 8 ns 92 0 0 0 1 1 0964 112 ns 92 0 1 1 1 1 0965 40 ns 93 0 1 1 1 1 0966 8 ns 93 0 1 1 1 1 0967 8 ns 92 0 1 1 1 1 0968 64 ns 92 0 0 1 1 1 0969 40 ns 92 0 1 1 1 1 0970 71.73 us 92 0 1 1 1 0 0971 8 ns 92 0 1 1 1 1 0972 8 ns 92 0 1 1 1 0 0973 48.43 us DF 0 0 0 1 0 0974 26.90 us DF 1 0 0 1 0 0975 1.165 ms DF 1 0 1 1 0 0976 8 ns DF 1 0 1 1 0 0977 8 ns DF 1 0 1 1 0 0978 8 ns DF 1 1 1 1 0 0979 77.57 us DF 1 1 1 1 1 0980 3.320 us FF 1 1 1 1 1 0981 3.300 s FF 1 1 1 1 1 0982 32.33 ms FF 1 0 0 1 1 0983 599.6 us FF 1 0 1 1 1 0984 8 ns FF 1 0 1 1 1 0985 8 ns FF 1 0 1 1 1 0986 8 ns FF 1 1 1 1 1 0987 108.7 us BF 1 1 1 1 1 0988 8 ns FF 1 1 1 1 1 0989 8 ns BF 1 1 1 1 1 0990 608 ns AD 1 1 1 1 1 0991 8 ns BD 1 1 1 1 1 0992 8 ns AD 1 1 1 1 1 0993 9.184 us AD 1 1 1 1 0 0994 8 ns AD 1 1 1 1 1 0995 8 ns AD 1 1 1 1 0 0996 1.011 s AD 1 1 1 1 0 0997 33.33 ms AD 1 0 0 1 0 0998 598.6 us AD 1 0 1 1 0 0999 8 ns AD 1 0 1 1 0 01000 8 ns AD 1 1 1 1 0 01001 104.3 us AD 1 1 1 1 1 01002 2.688 us ED 1 1 1 1 1 01003 624 ns FF 1 1 1 1 1 01004 617.4 ms FF 1 1 1 1 1 01005 32.41 ms FF 1 0 0 1 1 01006 597.5 us FF 1 0 1 1 1 01007 8 ns FF 1 0 1 1 1 01008 8 ns FF 1 0 1 1 1 01009 8 ns FF 1 1 1 1 1 01010 55.33 us F2 1 1 1 1 1 01011 8 ns FF 1 1 1 1 1 01012 8 ns D2 1 1 1 1 1 01013 9.176 us D2 1 1 1 1 0 01014 8 ns D2 1 1 1 1 1 01015 8 ns D2 1 1 1 1 0 01016 631.6 ms D2 1 1 1 1 0 01017 33.93 ms D2 1 0 0 1 0 01018 599.1 us D2 1 0 1 1 0 01019 8 ns D2 1 0 1 1

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 14, 2021, 07:19:11 pm
content: good grief - it still didn't get all the trace.Here is the end of the trace (hopefully)Code:1019 8 ns D2 1 0 1 1 0 01020 8 ns D2 1 0 1 1 0 01021 8 ns D2 1 0 1 1 0 01022 8 ns D2 1 1 1 1 0 01023 36.31 us D2 1 1 1 1 1 01024 3.312 us FF 1 1 1 1 1 01025 662.5 ms FF 1 1 1 1 1 01026 31.47 ms FF 1 0 0 1 1 01027 599.6 us FF 1 0 1 1 1 01028 8 ns FF 1 0 1 1 1 01029 8 ns FF 1 0 1 1 1 01030 8 ns FF 1 1 1 1 1 01031 67.88 us CE 1 1 1 1 1 01032 8 ns CE 1 1 1 1 1 01033 8 ns DE 1 1 1 1 1 01034 8 ns CE 1 1 1 1 1 01035 9.176 us CE 1 1 1 1 0 01036 8 ns CE 1 1 1 1 1 01037 8 ns CE 1 1 1 1 0 01038 912.2 ms CE 1 1 1 1 0 01039 35.54 ms CE 1 0 0 1 0 01040 869.8 us CE 1 0 1 1 0 01041 8 ns CE 1 0 1 1 0 01042 8 ns CE 1 1 1 1 0 01043 50.68 us CE 1 1 1 1 1 01044 3.312 us FF 1 1 1 1 1 01045 23.98 s FF 1 1 1 1 1 01046 19.00 ms FF 0 1 1 1 1 01047 27.76 us DF 1 1 1 1 1 11048 8 ns FF 0 1 1 1 1 01049 8 ns FF 0 1 1 1 1 01050 8 ns F7 0 1 1 1 1 01051 8 ns FB 0 1 1 1 1 01052 8 ns 92 0 1 1 1 1 01053 124.7 us FF 0 0 0 1 1 01054 34.31 us FF 1 0 0 1 1 01055 156.9 us FF 0 0 0 1 1 01056 28.28 us FF 0 1 1 1 1 01057 8 ns FF 1 0 0 1 1 01058 8 ns FF 0 0 0 1 1 01059 8 ns F3 0 0 0 1 1 01060 8 ns F7 0 0 0 1 1 01061 8 ns 92 0 0 0 1 1 01062 120 ns 92 0 0 1 1 1 01063 8 ns 92 0 1 1 1 1 01064 136 ns 92 0 0 1 1 1 01065 8 ns 92 0 0 1 1 1 01066 8 ns 92 0 1 1 1 1 01067 60.49 us 82 0 1 1 1 1 01068 9.200 us 82 0 1 1 1 0 01069 8 ns 82 0 1 1 1 1 01070 8 ns 82 0 1 1 1 0 01071 49.94 us CF 0 0 0 1 0 01072 27.43 us CF 1 0 0 1 0 01073 123.3 ms CF 1 0 1 1 0 01074 8 ns CF 1 0 1 1 0 01075 8 ns CF 1 0 1 1 0 01076 8 ns CF 1 1 1 1 0 01077 63.82 us CF 1 1 1 1 1 01078 3.320 us FF 1 1 1 1 1 0Time Printed: 14 Jul 2021 09:29:31Hopefully here is the complete trace zip file:INP5_6V.zip(6.46 kB - downloaded 53 times.)

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 14, 2021, 08:15:10 pm
content: Thank you for the detailed posts!From the first post I see that the graphic shows the first 74 bytes read up to E19.40 then a slight pause then an ATN and the byte 01101101 or hex 6D which is the MSA for INPUT. That is in line with the expected behaviour of the Tek but not quite as described. I was expecting a UNT first and then a new cycle of MTA, MSA, data, UNT. The Realterm screenshot shows that the next 74 characters are being read up to -5 when the process evidently hangs. I am not seeing an 'ATN asserted!' after the E19.40 though.On the graphic, the ATN comes after the handshake on the CR character is complete and the emulator starts handshaking the next character. There is a slightly elongated NDAC bump at this point and then both NDAC and NRFD stay low which means that the Tek is not ready to receive and we have a short pause. The Tek is likely processing the first 74 characters that have been received. Then comes ATN and 6D, however the emulator has already started the next handshake at this point and is not actively listening to the ATN. It is still sitting waiting for NRFD to go high. ATN and NRFD do eventually go high and the Tek has places the 6D on the bus and waits for an acknowledgement of the ATN and MSA command which does not come. Meanwhile the emulator being in send mode continues its attempt to send more data (i.e. the emulator send loop continues) until the process hangs.I think the emulator needs to check for ATN being asserted during the handshake, probably at the point where the emulator is waiting for NRFD to go high to indicate that the receiver is ready. If it gets an ATN at this point, it needs to immediately drop out of the handshake and go into listening mode.The other problem is that the MSA apears to be being sent on ATN without preceding UNT to finish the last transmission and or MTA + MSA to start the new INPUT command. There is an issue with that at present, in that the emulator does not remember whether it is in talk or listen mode between successive assertions of the ATN signal. It relies on MTA/MLA being sent followed by MSA to determine that.I will need to have a think about how to deal with this.I will also review your further post with the logic analyzer output tomorrow morning.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 14, 2021, 08:39:52 pm
content: Sounds like progress!I will make another attempt to get my 4924 tape drive working again. It should give a definitive trace, but I'll have to create a tape with the same data file.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 14, 2021, 10:28:32 pm
content: The 4924 5V power supply NPN transistor is bad. I've ordered a NOS cross reference, but won't get it for a week or so

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 15, 2021, 11:15:31 am
content: Quote from: mmcgraw74 on July 14, 2021, 10:28:32 pmI hope you don't have a leaky electrolytic capacitor or something causing an excessive current draw. At least the transistor is a relatively simple fix.I have had a go at implementing possible fixes for the two things I mentioned in my previous post and have uploaded the updated code. Since I don't own a Tek computer, I am unfortunately limited in how far I can test this.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 15, 2021, 01:24:02 pm
content: I just tried your v31 on my 4054A and 4052.the OLD function is not working, but INPUT, CD, FIND are working.INPUT does take a long time for first command (Send Error reported in debug log), then works for subsequent INPUT.So I did a FIND@5:2 which opened /root/2Then:Code:INPUT@5:A$ It took some a couple of seconds to return to BASIC prompt(maybe a timeout?)A$ Returned /root/INPUT@5:A$ Returned to prompt quickerA$ Returned /Games/INPUT@5:A$ Returned to prompt quickerA$ Returned /UTILITIES/PRI@5,19:"ADVENTURE"FIND@5:51 file 51 is ADVENTURE programOLD@5: Hung TektronixSerial debug output for this experiment:So this is progress for INPUT.Apparently CD works, but OLD Hangs Tektronix power cycle of Tek and Emulator required4052 2nd test of CD and OLD:Power up Tek, connect EmulatorFIND@5:1OLD@5:Tek hung had to be power cycled.Here is the serial debug output for this experiment:

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 15, 2021, 02:18:39 pm
content: Ok, so some progress on the INPUT issue at lastThe 'Send error' can be ignored. It indicates that either ATN was detected or both NDAC and NRFD were high indicating a fault condition. Either should cause the send loop to abort which is what we are now seeing. The writeByte() function was not originally written to anticipate the controller interrupting the send process as this situation never came up before. I could change change it to send a specific error code for each condition so as to be able to differentiate them. For now I will change the debug message to say something like 'ATN or ERR on send'.Not sure why the delay before the first INPUT command, but I have also noticed a couple of seconds a delay here with my setup before any any file data is output. The GPIB command comes through on the emulator console almost immediately. It might be a delay reading the SD Card or it may be something else such as timeouts. I have GPIB timeout set at 5 secs but the length of delay in this case is about 2.5 seconds which seems to be comparable to what you have reported. I will look into it.Regarding OLD, any chance of a snapshot of the trace? I need to see the transition between the two commands (FIND and OLD) if possible. FIND is a listen command, whereas old is a TALK command. I am interested in whether the Tek is sending a UNL at then end of FIND, or at least an MTA before the MSA for OLD. Thanks.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 15, 2021, 05:18:23 pm
content: Thank you although a decoding of the hex characters doesn't seem to make much sense. There are UNT and UNL characters evident but also a 7F (127). There seem to be NULL and other random characters being sent while ATN is asserted which doesn't make sense. Anything send during ATN should be a a primary or secondary address, or a GPIB command character.The randomness of the characters is such that I would begin to wonder whether there is a problem with the mechanical connection or something nearby inducing EMF into the wires...HPIB STATE - State ListingCode:Label > Time STAT DATA ATN NDAC NFRD EOI DAV SRQBase > Relative Binary Hex Bin Bina Bina Bin Bin Bin__________ _________ ________ ____ ___ ____ ____ ___ ___ ___0 37.52 us 10010100 25 0 0 1 1 0 0MLA1 65.79 us 10000100 25 0 0 0 1 0 02 11.45 us 10001100 25 0 1 0 1 0 03 18.10 us 10101100 25 0 1 0 1 1 04 31.74 us 10101100 7D 0 1 0 1 1 0SECRET?5 8 ns 11101101 7F 1 1 0 1 1 0?6 8 ns 10101100 7F 0 1 0 1 1 0?7 336 ns 10101100 7B 0 1 0 1 1 0FIND8 83.62 us 10100100 7B 0 0 0 1 1 09 8 ns 10101100 7B 0 1 0 1 1 010 8 ns 10100100 7B 0 0 0 1 1 011 25.38 us 10110100 7B 0 0 1 1 1 012 42.34 us 10010100 7B 0 0 1 1 0 013 96.24 us 10000100 7B 0 0 0 1 0 014 11.44 us 10001100 7B 0 1 0 1 0 015 15.93 us 10101100 7B 0 1 0 1 1 016 19.30 us 10101101 7B 1 1 0 1 1 0DATA17 37.15 us 10101101 78 1 1 0 1 1 018 8 ns 10101101 60 1 1 0 1 1 0`19 24 ns 10101101 20 1 1 0 1 1 0SPC20 61.41 us 10100101 20 1 0 0 1 1 021 8 ns 10101101 20 1 1 0 1 1 022 8 ns 10100101 20 1 0 0 1 1 023 1.311 ms 10110101 20 1 0 1 1 1 024 15.68 us 10010101 20 1 0 1 1 0 025 129.4 us 10000101 20 1 0 0 1 0 026 11.45 us 10001101 20 1 1 0 1 0 027 38.81 us 10101101 20 1 1 0 1 1 028 41.80 us 10101101 31 1 1 0 1 1 0129 64.15 us 10100101 31 1 0 0 1 1 030 8 ns 10101101 31 1 1 0 1 1 031 8 ns 10100101 31 1 0 0 1 1 032 37.77 us 10110101 31 1 0 1 1 1 033 20.42 us 10010101 31 1 0 1 1 0 034 124.7 us 10000101 31 1 0 0 1 0 035 11.44 us 10001101 31 1 1 0 1 0 036 15.79 us 10101101 31 1 1 0 1 1 037 32.86 us 00101101 31 1 1 0 0 1 038 27.70 us 00101101 3D 1 1 0 0 1 0=39 160 ns 00101101 1D 1 1 0 0 1 0(group separator)40 8 ns 00101101 1D 1 1 0 0 1 041 8 ns 00101101 0D 1 1 0 0 1 0CR42 68.24 us 00100101 0D 1 0 0 0 1 043 8 ns 00101101 0D 1 1 0 0 1 044 8 ns 00100101 0D 1 0 0 0 1 045 37.76 us 00110101 0D 1 0 1 0 1 046 43.93 us 00010101 0D 1 0 1 0 0 047 101.2 us 00000101 0D 1 0 0 0 0 048 11.45 us 00001101 0D 1 1 0 0 0 049 39.82 us 00101101 0D 1 1 0 0 1 050 21.98 us 10101101 0D 1 1 0 1 1 051 56.33 us 10101100 0D 0 1 0 1 1 0?52 32.90 us 10100100 0D 0 0 0 1 1 053 8 ns 10101100 0D 0 1 0 1 1 054 8 ns 10100100 0D 0 0 0 1 1 055 53.48 us 10100100 5F 0 0 0 1 1 0UNT56 27.04 ms 10110100 5F 0 0 1 1 1 057 24 ns 10111100 5F 0 1 1 1 1 058 42.91 us 10011100 5F 0 1 1 1 0 059 17.82 us 10000100 5F 0 0 0 1 0 060 8 ns 10001100 5F 0 1 0 1 0 061 8 ns 10000100 5F 0 0 0 1 0 062 23.31 us 10010100 5F 0 0 1 1 0 063 35.98 us 10000100 5F 0 0 0 1 0 064 11.45 us 10001100 5F 0 1 0 1 0 065 34.52 us 10101100 5F 0 1 0 1 1 066 27.51 us 10101100 7F 0 1 0 1 1 067 232 ns 10101100 3F 0 1 0 1 1 0UNL68 87.06 us 10100100 3F 0 0 0 1 1 069 8 ns 10101100 3F 0 1 0 1 1 070 8 ns 10100100 3F 0 0 0 1 1 071 26.14 us 10110100 3F 0 0 1 1 1 072 38.26 us 10010100 3F 0 0 1 1 0 073 115.8 us 10000100 3F 0 0 0 1 0 074 11.45 us 10001100 3F 0 1 0 1 0 075 23.56 us 10101100 3F 0 1 0 1 1 076 35.50 us 10100100 3F 0 0 0 1 1 077 112 ns 10100100 39 0 0 0 1 1 0?78 8 ns 10100100 38 0 0 0 1 1 0?79 8 ns 10100100 00 0 0 0 1 1 0?80 27.30 us 10100101 00 1 0 0 1 1 0DATA81 837.4 us 10110101 00 1 0 1 1 1 082 8 ns 10110101 00 1 0 1 1 1 083 8 ns 11111101 00 1 1 1 1 1 084 4.477 s 10111101 00 1 1 1 1 1 085 18.28 ms 10111100 00 0 1 1 1 1 0?86 25.98 us 10110100 00 0 0 1 1 1 087 8 ns 10100100 00 0 0 0 1 1 088 8 ns 10101100 00 0 1 0 1 1 089 8 ns 10100100 00 0 0 0 1 1 090 2.808 us 11100100 3F 0 0 0 1 1 0UNL91 8 ns 11111101 3F 1 1 1 1 1 092 8 ns 10100100 3F 0 0 0 1 1 093 64 ns 10100100 7F 0 0 0 1 1 0?94 8 ns 10100100 3F 0 0 0 1 1 0UNL95 20.42 us 10110100 3F 0 0 1 1 1 096 36.64 us 10110100 39 0 0 1 1 1 0?97 8 ns 10110100 38 0 0 1 1 1 0?98 8 ns 10110100 30 0 0 1 1 1 0?99 8 ns 10110100 20 0 0 1 1 1 0?100 38.46 us 10010100 20 0 0 1 1 0 0101 63.45 us 10000100 20 0 0 0 1 0 0102 11.45 us 10001100 20 0 1 0 1 0 0103 19.38 us 10101100 20 0 1 0 1 1 0104 23.01 us 10101101 20 1 1 0 1 1 0DATA105 27.54 us 00101101 20 1 1 0 0 1 0106 28.23 us 00101101 66 1 1 0 0 1 0f107 192 ns 00101101 46 1 1 0 0 1 0F108 35.46 us 00100101 46 1 0 0 0 1 0109 8 ns 00101101 46 1 1 0 0 1 0110 8 ns 00100101 46 1 0 0 0 1 0111 23.94 us 00110101 46 1 0 1 0 1 0112 24 ns 00111101 46 1 1 1 0 1 0113 34.98 us 00011101 46 1 1 1 0 0 0114 38.77 us 00111101 46 1 1 1 0 1 0115 21.96 us 10111101 46 1 1 1 1 1 0116 69.57 us 10111100 46 0 1 1 1 1 0?(F)117 35.77 us 10100100 46 0 0 0 1 1 0118 8 ns 10111100 46 0 1 1 1 1 0119 8 ns 10100100 46 0 0 0 1 1 0120 23.31 us 10110100 46 0 0 1 1 1 0121 26.36 us 10110100 44 0 0 1 1 1 0?(D)122 8 ns 10110100 40 0 0 1 1 1 0?(@)123 37.91 us 10010100 40 0 0 1 1 0 0124 74.29 us 10000100 40 0 0 0 1 0 0125 11.45 us 10001100 40 0 1 0 1 0 0126 38.40 us 10101100 40 0 1 0 1 1 0127 37.62 us 10100100 40 0 0 0 1 1 0128 168 ns 10100100 00 0 0 0 1 1 0?129 32.02 us 10100101 00 1 0 0 1 1 0DATA130 49.58 us 10110101 00 1 0 1 1 1 0Time Printed: 15 Jul 2021 08:53:45Its a bit odd that there seems to be no hex 64 (MSA for OLD) being sent?Noted regarding hex 7F (127) being EOT. I have also seen the DC3 (device control 3) byte in a listing somewhere (manual?) and wondered what its purpose is.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 15, 2021, 05:35:04 pm
content: According to the 4924 tape service manual, 127 is the EOF character in a file.I have seen NULL and DC3 characters in ASCII data files, particularly in tape file headers I have extracted from recovered tapes.BTW - I have been making sure to put a CR with nothing else after the last line in ASCII PROGRAMs. This may cause the Tektronix to stop fetching more lines of characters and end the OLD command.But the current OLD not working issue - no lines are transferred.I'll check the 4924 description of the SAVE command - it could be the 4924 or Tektronix adds an EOF character after the Tektronix ends the SAVE command

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 15, 2021, 05:51:57 pm
content: I just checked one of my latest tape dumps - and I see character 255 (FFh) immediately after a CR with no other characters after the last BASIC program statement.Example:Code:190 ENDYes, 4924 service manual page A-3 description of end-of-file mark:end-of-file mark: The byte (hexadecimal FF) written onto a tape to mark the logical end of a file.Likely only written by Tektronix on SAVING ASCII PROGRAM files - I don't see it on ASCII DATA files, and the BINARY DATA type bytes encode EOF as type 7

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 16, 2021, 08:23:06 am
content: I knew I saw DC3 recently somewhere....From the 4924 service manual, 2-09. No description is given for its purpose though.[ Specified attachment is not available ]

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 16, 2021, 12:14:07 pm
content: See page 7-42 in the 070-2056-01 4050 Graphics System Reference manual section of the FIND statement usage of  to terminate the file header string:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 16, 2021, 06:20:24 pm
content: I tried to figure out why OLD command was not working, but I was not successful.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 17, 2021, 07:50:20 am
content: I haven't worked it out either yet, but FIND followed by OLD works here via the terminal. I noted that your second image of the console output shows only the debug messages from the FIND command, but nothing at all from OLD, so it looks like OLD is not being received but I don't know why.In the graphic we can see a UNL during the first ATN phase, but it is completely missed - DAV goes down on the next byte - hex 20. We also see SRQ asserted. Why and by which device? This might be causing the Tek to attempt a serial poll, but I am not seeing GPIB command 18. After the missed UNL things appear to go awry.Is there a chance of getting another capture of the trace from FIND + OLD please? Could you also enable //#define DEBUG_DEVICE_ATN please. It might be best to do two separate scans first of the complete FIND which should show us the state of the GPIB bus when it is completed, and then the attempted OLD.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 17, 2021, 05:39:00 pm
content: If I CD to a directory manually, FIND a data file with two numbers per line, INPUT A,B - the first two numbers are correct.However, the second INPUT A,B command done manually, results in the numbers in incorrect order.Here are the commands:Code:PRI @5,19:"ADVENTURE"FIND @5:1INPUT @5:A,BA1B133488INPUT @5:A,BA1641035B5INPUT @5:A,BA92813B8Here is the first couple of lines of the contents of the /ADVENTURE/1 ASCII data file (each line is  delimited:Code:DATA 1,133488,1,6771679,2,36315,2,8849417,3,4673330,4DATA 1641035,5,1987117,6,234943,6,387847,7,7400652,8DATA 92813,8,249958,9,9462081,10,2517217,11,7523733,11DATA 7763223,12,1512460,13,8969927,14,7412167,14,12721You had asked before whether the "DATA" in the file above would interfere with INPUT of the variables.Here is page 10-22 of the BASIC Reference showing how Text is ignored in extracting a VALue from a string:The Emulator should continue reading from the same line if the contents have not been consumed.It appears the Emulator is reading the second line to satisfy the second INPUT command and the third line to satisfy the third INPUT command.I think the FIND command is not terminating properly, because I wrote a program to run all the test commands above and the program generates an error on the line number with the FIND command and stops the program execution.Likely the Tektronix must timeout on the GPIB bus condition if the FIND command is typed individually.I may have been able to capture the FIND command typed manually:Here are the waveform and trace listings:BAD_FIND.zip(1.98 kB - downloaded 49 times.)Sorry the columns are in a different order in my latest trace listings, I eliminated the SRQ signal - which appears to be mysteriously wiggling in the trace. I also eliminated the STATUS bits which included the SRQ pin. Maybe the emulator is not setting the SRQ to output mode - or is initializing it as zero?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 17, 2021, 11:01:18 pm
content: I uploaded a new microSD card zip file for testing, including my Adventure game with data files converted to INPUT format.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 18, 2021, 09:05:56 am
content: Thanks for the update to the SD files.In the meantime, I did spot something in the information your posted which may possibly have a bearing. It seems that the emulator responded to UNL but not to UNT. It was also responding to UNT and UNL only after the attention period had ended so I did wonder whether that might be causing a timing issue. You mention nthat enabling DEBUG_DEVICE_ATN cause OLD work (sort of). Since all that does is print more messages to the console, which, in effect, takes more time, that also might indicate a timing issue. I have posted an update that should ensure that state changes in response to UNL and UNT happen within the attention period. Whether it fixes the problem remains to be seen....I haven't looked at the problem you reported with INPUT yet.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 18, 2021, 12:07:43 pm
content: Thanks, I'll check out your new version.It also appears that each INPUT command may consume an entire ASCII line of characters, so in the Adventure files I uploaded, I changed the DATA files to match the program INPUT statements. I also removed spurious characters like quote marks for strings and "DATA" in the numeric ASCII DATA files. I did a test of an INPUT statement of a character string with quotes and the resulting string had the quote characters included - which is not what I wanted. Without the quotes, the strings are terminated by , which is what is needed.All of my prior ports of Adventure were actually using binary data files - created with WRITE statements and consumed by READ statements. Binary data files will not have  termination as the data headers define exactly the type of variable and exactly the length.I'm hoping your UNL/UNT changes will fix the INPUT (and other) command termination.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 18, 2021, 01:24:16 pm
content: I just took a few minutes to have a brief look at the INPUT problem you mention and I agree that each INPUT statement seems to be reading from the beginning of a new line. However reading the description of INPUT from the 070-2270-00_4051_GPIB_HW_Supp_Jul81.pdf manual, it seems to suggest that this behaviour is in line with what might be expected: "Data bytes are received in this fashion until a CR delimiter is received, an alternate delimiter is received, or until 72 characters are received, whichever occurs first. After one of the above occurs, the 4051 stops the data transfer....". Reading the first sentence under the heading THE UNADDRESSING SEQUENCE it says: "After the 4051 has assigned data to each variable specified in the input parameter list, the 4051 terminates the operation by activating ATN...".Admittedly I also thought the Tek would process the buffer contents into the variable pairs supplied to each subsequent INPUT statement until it had processed all the data in the buffer. Only then would it have to read the tape and get more data.However, looking at it, the INPUT statement has two variables. Tek reads data as described up to CR (which comes before 72 characters are read) and assigns the first two values to A$ and B$ (i.e. each variable specified in the parameter list). On the subsequent INPUT it reads the next buffer full of data up to CR and again and assigns the first two values to A$ and B$. This repeats for each INPUT statement.Could it be that the data needs to be read into an array rather than a bit at a time?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 18, 2021, 07:18:12 pm
content: As I noted in my last post - I agree that Tektronix will read an entire ASCII  terminated string for each INPUT command, so the program needs to INPUT all the variables in string in that command, or unaccessed variables in that string will be lost.I modified my Adventure data files and program - and got the program to load the four initialization data files and begin accessing the other data files with INPUT statements. However, I had to add FOR/NEXT delay loops after each CD, FIND and INPUT statement in the program. It still has errors on random FIND or INPUT statements. I hope we can figure out how to properly terminate the Emulator commands so delay loops are not needed.I also updated the ROOT, GAMES and UTILITY programs. My 4052 is able to load /ROOT/1 which is a menu and can run the menu to load the GAMES or UTILITY menus and the GAMES menu can load a couple of my games programs. All of those files in my latest upload of the sd card image as Tek4924sd3.zip had to have delays after each command to the emulator.I hope to repair my 4924 this week, and grab logic analyzer traces that should help.I also tried these files with time delays on my 4054A which has different GPIB code since it uses a TI 9914 GPIB IC - but it is supposed to be faster on GPIB, so all the manually added timing loops are likely too short

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 18, 2021, 09:58:52 pm
content: I agree. It shouldn’t need any timing delays. GPIB handshaking is supposed to ensure that it runs at the rate of the slowest device on the bus.I managed to get that 4051 off eBay. Auction finished a few minutes ago and I now need to arrange to collect it. I just hope it can be repaired. It seems dead money though as there seemed to be no interest so I would probaby have zero chance to sell it in the future. If it can get repaired then it should make testing things easier.If you can get your 4924 going, then the logic analyser traces would undoubtedly be very helpful.BTW what tapes does it use? Standard QIC-120s or QIC-150s? Or did they do what Compaq liked to, that is, add additional lugs or notches to customize so that standard media would not fit and they could charge extortionate costs for their own branded media?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 18, 2021, 11:49:30 pm
content: Quote from: WaveyDipole on July 18, 2021, 09:58:52 pmExcellent! The seller had posted that 4051 asking for help back on June 16 on the Tek 4051 facebook group:https://www.facebook.com/groups/1157781747606102/permalink/4323203177730594/. I posted a suggestion to help troubleshoot and we never heard from him again. I can certainly help you get that one working - yes I suspected one or more bad DRAMs. That has been one of my 4054 problems, and I also had to replace a couple of DRAMs on a 4907 floppy controller. Philip Greenstock never posted again - and I figured he didn't want to fix it. I'm glad you got it - and a good price too.QuoteThe 4050 computers used 3M DC300 tapes. I found some DC600 tapes worked when I bought my 4052 and 4054A in 2000. My latest tape purchase was 3M DC6250 tapes. The biggest issue with that entire series of tapes is the drive belts from the DC100 tapes disintegrate in the 40 years since they were produced. Similar fate now for the DC600 and newer tapes. I purchased a box of DC6250 tapes about three years ago when I got my 4052 and 4054 working again and all the belts and tapes are in great shape.There was no keying on the DC300/600/6250 tapes. When we get the Emulator working - you won't need any tapesLets get your 4051 working - and then I can send you a formatted tape. There is an EBAY auction for 8KB of 4051 DRAM, that may help if there are bad DRAMs:https://www.ebay.co.uk/itm/333954433557?epid=3045752685&hash=item4dc13c4215:g:OGMAAOSwfBNgciAVOne option missing from your 4051 is the Option 1 RS-232 Serial Interface - which included an Option ROM for BASIC commands to set baud rate, etc. This option was a PCB inside the ROM backpack. I do have a 4051 RS-232 Printer Interface ROM Pack that I can't use with my computers as 4052/4054 ROMs were different than 4051 ROM Packs and were keyed to prevent them from plugging into the other system. The printer interface only wired the TX pin and handshake pins, but I think it would be easy to add an RS-232 buffer to the UART RX pin so you could send and receive programs to the 4051 from a PC at 2400 baud

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 18, 2021, 11:57:57 pm
content: I see several DC6250 tapes for sale on EBAY like this one:https://www.ebay.co.uk/itm/383109575317

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 20, 2021, 02:06:29 am
content: Great news - I fixed my 4924 Tape Drive!I replaced the power supply 5V output pass transistor - no change.I have an older 4923 Tape Drive that I have been using for spare parts - I swapped the entire power supply board (same assembly part number - same components) - that worked.4924 Tape GPIB address DIP switches set to 4 for primary address and 4051 command mode.First test:FIND @4:2INPUT @4:A$I heard the FIND @4:2 cause the tape drive to seek to file 2, which is an ASCII program called TECO (text editor for 4052 Assembler program in file 1).I heard it INPUT the first line of the file into A$. Yes, the Tektronix supports INPUT from ASCII program OR DATA files.I captured the entire FIND followed by INPUT of one CR terminated character string in one trace - complete trace listing zip file is attached.4924FINP.zip(5.67 kB - downloaded 71 times.)I also captured four waveforms from this trace:First one shows the FIND @4:2 commandSecond one shows the INPUT @4:A$ commandThird one shows the A$ being sent to the TektronixFourth one focuses on the end of the INPUT commandHere is a photo of the 4052 screen with the text returned from the INPUT command.The first two lines highlighted in yellow showed me the command worked, but I forgot to trigger the logic analyzer.The last two lines were typed with the logic analyzer triggering on the first DAV, and both commands were captured and I then stopped the logic analyzer, save the setup and data, captured the waveforms and the trace listing.Last photo is the working 4924 tape drive on top of my 4052 computer. The 4052 Assembler tape (3M DC6250 tape with working drive belt) is in the 4924.I can take more logic analyzer traces tomorrow.This should help us figure out how to support all the Tektronix tape commands

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 20, 2021, 11:45:26 am
content: Monty, glad you got your 4924 up and running. I am glad that the drive is running with the power supply board from the other unit so at least you know everything else in the unit is OK. I expect that the faulty power supply board can now be repaired and serviced out of circuit and put back once repairs are done.You mentioned in your earlier post that the 3A fuse blown. In the event of overvoltage due to Q1004 failing, CR33 should crowbar, effectively shorting the supply to ground which would casue the fuse F72 should blow. Since you have replaced the pass transistor and the voltage is still high, then it sounds like either the 741 op amp IC or possibly the 5.6V zenner (VR13) might be faulty. Might also be worth checking R17.I was going to pick up the 4051 today, but unfortunately while driving to put some fuel for the trip in the car last night I heard a loud whining noise a couple of times, both times on bends. I checked with a couple of local mechanics this morning and the consensus is that the cause might be a worn wheel bearing. I am hoping to have it properly assessed later this afternoon, but in the meantime I don't think it wise to do a 6 hour round trip at high speed on the motorway so have postponed the trip for now.In the meantime, thank you for the detailed capture showing the 4051 operating the 4924 during FIND and INPUT commands. I have decoded what is being sent and there are some features of interest.Image 1:3F 24 7B 20 32 CR  5F 3FThe initial 3F (UNL) comes before DAV and doesn't look like its being picked up. Next we have MLA and 7B which is the FIND command. We then get a SPACE followed by 32 (the number 2) which is followed by CR, UNT and UNL. The 2 is obviously a reference to file 2, but why the space?Image 2:3F 44 6D (0 FF CR)The UNL again precedes the first handshake. This is followed by MTA and 6D which is the INPUT command. There is no handshake during the 0 and FF so I think this might be the bus changing state and settling. There is also a CR at the end but since the trace then ends, it is not possible to determine whether there is a handshake.Image 3Too compressed to decodeImage 420 20 20 28 66 69 6C 65 20 33 29 CR 5F 3FThree spaces followed by "(file 3)" and a CR. The trace ends with UNT and UNL.Other items of interest:the SRQ line stays asserted the entire time. Is there an error condition requiring attention again? In any case, it doesn't seem to have impeded the functioning of the drive so probably does not have a bearing.there is no EOI during INPUT. The single EOI that does appear comes at the end of the FIND command. Is this because INPUT has not reached the end of the file at this point? If so, then that might explain why there is no EOI.REN seems to get un-asserted at the end of the transmission. Other signals except SRQ get un-asserted at the same time so this looks like the bus going idle. The emulator doesn't have features that would require remote control so this should have any effect.I am not sure what all of this means yet but we do need to compare that against what the the current code is doing. I think I would like to start seeing what the trace from just the FIND command looks like using the current emulator code please.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 20, 2021, 12:55:08 pm
content: Quote from: WaveyDipole on July 20, 2021, 11:45:26 amTektronix always inserts a space in front of a numeric variable stored in ASCII form. This is even true for the tape file header.QuoteThe trace listing is complete for the entire FIND @4:2 then INPUT@4:A$ sequence captured with8 nsecaccuracy on any transition. Each transition has a timestamp indicating how much time has elapsed since the last transition.QuoteCheck out the trace listing.QuoteYes, that matches the printout on the 4052 for the contents of A$QuoteI believe this must be a wiring error on the SRQ signal - this signal is zero on every capture.QuoteI think this is important. Service manual page B-6 indicates on INPUT the 4924 will send the  character last and the Tektronix will then end the command with UNT & UNL. ASCII INPUTs are always  terminated, so I think this makes sense.The Appendix B table of 4051 mode GPIB sequences shows the Tektronix using EOI on CLOSE, FIND, KILL, MARK, PRINT, SAVE, SET STATUS, and WRITE commands, but the 4924 only sends EOI on the TALK command when it reaches the EOF of a file. I think this means it is the Tektronix that ensures the EOI marker is always at the end of each command that writes to a file to cause the 4924 to add the EOF character after the last write. And the 4924 will replace the previous EOF with the new data on receipt of another write, and add the EOF when it receives the EOI so there is only one EOF in an ASCII program or data file.QuoteOk, I'll capture an emulator FIND command and put it in the next post.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 20, 2021, 02:31:01 pm
content: Hmm - first I ran into an issue. I have the Emulator plugged into the 488 cable from the 4052 to the 4924, and I have left the 4924 powered in case we need more traces and I don't want to turn it off.The issue is - with the 4924 attached plus the Emulator, the Tektronix hangs on the first access to the Emulator.This could be a bus drive issue, although I captured a trace which showed the SRQ signal had lots of transitions.I then left the 4924 powered and disconnected the 488 cable to the 4924 for the following experiment and logic analyzer trace capture:With the 4924 powered and USB disconnected from the Emulator, I turned on the 4052, then plugged in the Emulator cableThen I started the Realterm serial console to the EmulatorI had no issue entering the PRI@5,19:"ROOT" commandI then started the Logic Analyzer and typed FIND@5:1 with no issueI then typed OLD@5: and the Tektronix was locked up and wouldn't return to promptI then stopped the logic analyzer and captured the attached waveform images and complete FIND and OLD of the short /ROOT/1 menu programFirst image should be the FIND commandSecond image should be the OLD commandAnd last is the complete trace listingEM_FOLD.zip(7.09 kB - downloaded 54 times.)And here is the serial debug output:Code:Executing secondary address command: 7Bstgc_0x7B_h: started FIND handler...stgc_0x7B_h: received parameter: 1searchForFile: searching /ROOT/...searchForFile: found file 1searchForFile: done.stgc_0x7B_h: found: 1 ASCII PROG [Root Menu] 4stgc_0x7B_h: type: PattnRequired: Answering attention!attnRequired: Reading byte...3FattnRequired: GPIB command received: 0Unlisten received.Unlisten done.End ATN loop.attnRequired: END attnReceived.attnRequired: Answering attention!attnRequired: Reading byte...20End ATN loop.attnRequired: END attnReceived.attnRequired: Answering attention!attnRequired: Reading byte...45attnRequired: addressed to talk >>>attnRequired: Reading byte...64attnRequired: secondary addressing command received: 64End ATN loop.Executing secondary address command: 64stgc_0x64_h: started OLD/APPEND handler...stgc_0x64_h: reading /ROOT/1 ASCII PROG [Root Menu] 4...stgc_0x62_h: started CLOSE handler...stgc_0x62_h: closing: 1 ASCII PROG [Root Menu] 4...stgc_0x62_h: done.stgc_0x64_h: done.attnRequired: Answering attention!attnRequired: Reading byte...attnRequired: Reading byte...End ATN loop.Talking...

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 20, 2021, 06:35:04 pm
content: Thank you for all of the additional information.Quote from: mmcgraw74 on July 20, 2021, 12:55:08 pmGreat. Thanks. That explains the hex 20.Quote from: mmcgraw74 on July 20, 2021, 12:55:08 pmSorry, I don't see it attached to this post or the previous one?QuoteI think this is important. Service manual page B-6 indicates on INPUT the 4924 will send the  character last and the Tektronix will then end the command with UNT & UNL. ASCII INPUTs are always  terminated, so I think this makes sense.Agreed. Thank you for the list of commands which terminate with an EOI. I have made a note and will remove asserting EOI from the INPUT response.The traces from the emulator do actually look rather messed up. It is difficult to work out the pre-able, but there does appear to be a 7B for FIND, something possibly comes just before ATN is unasserted and then we have a space. There might just be another character being send before ATN is asserted again and we have 5F and 3F (UNT, UNL). Ignoring SRQ, the bus then goes idle.The second trace is more interesting. One can make out a 3F at the beggining, which seems to come before DAV. We then have a space while ATN is still asserted and a 46 (F) with EOI. This appears to persist into the second ATN asserted period. There is a long pause after which we get an IFC.The 4924 operators manual states that "Once addressed as a talker to execute an inout operation, the 4925 (sic) continues to send data over the GPIB until it receives either the GPIB UNTALK or IDC (Interface Clear command". Since it can't receive UNT while sending, we have previously seen that the Tek asserts ATN to cause the send loop to abort. Here we have IFC and then ATN. I had a look back at the previous traces and didn't see IFC being asserted. The GPIB controller would probably send an IFC on startup but that doesn't appear to be the case here. The final two characters are 45 (MSA(5) and 64 (OLD). The bus then appears to go idle.Firstly, the emulator is not designed to "hear" IFC yet. Secondly, there seems to be some ambiguity as to what's happening at the end of the FIND command. I haven't examined the trace log yet which is what I intend to do next.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 20, 2021, 07:08:53 pm
content: Quote from: mmcgraw74 on July 20, 2021, 12:55:08 pmThe trace listings are small zip file attachments in the previous posts (actually close to 60KB of text but zipped to 1/4 that size).Here is the trace listing from today with the FIND then OLD:EM_FOLD.zip(7.09 kB - downloaded 56 times.)Second attachment is the 4924 trace of FIND then INPUT of A$

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 22, 2021, 07:45:45 am
content: I spotted the second ZIP file in the post just above, but missed the one in the earlier post just before the images. I now have both. Thank you.I picked up the 4051 yesterday. The size of it - specifically the depth - was a bit unexpected and it is going to be a struggle to find space to accommodate it. There was a bit of disintegrating filter material in the carrier over the fan. I cleared this away to prevent bits getting sucked inside and gave it a good wipe down. The top cover was then removed to have a look inside.Apart from the usual dust and grime that might gather inside a piece of equipment of this age, the inside looks intact. I don't see any signs of damage or components in distress. I haven't looked inside the power supply case yet though. It also seems to have a full complement of memory chips. A bank of them that runs almost out of view under the CRT is soldered in. The larger group that sit further back and under the neck of the tube are socketed. This does allow for the possibility of a bank to be removed and be used as spares if needed, although there is also that listing you mentioned for the upgrade pack which might be worth getting. In addition to the GPIB port, the unit also comes with two additional D-type ports on the back: J40 which is 9 pin, and J41 which is 15-pin. I have not yet determined their purpose, although there is an instruction next to J40 stating that the unit needs to be powered off before connecting a joystick which probably explains the purpose of J40.The unit also came with a cartridge in one of the slots to the rear marked “4051 BINARY PROGRAM LOADER”, product number 4051R05 and lists some functions:CALL “BOLD”CALL “BSAVE”CALL “BAPPEND”, 100CALL “LINK”, 200It also refers to the Operator Manual for further details.The first order of business will be to disconnect and check the power supply to make sure all voltages are present and correct. Once that is confirmed, I plan to leave the internal tape drive disconnected and cartridge removed and do a power up test. At present, I am unsure how to get to the logic boards located below the CRT. This will be a necessary step at some point to check that all chips are seated properly. I presume there must be at least one of more ROM chips inside somewhere but I haven't located them yet. I also need to have a read of the operators manual to familiarise myself with the principle controls.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 22, 2021, 12:31:57 pm
content: I have checked the power supply. The fuses on the +20V and -20V rail were good, but the regulated +15V rail was out of range and needed adjustment. This resulted in all other rails (+12V, -12V and +5V) reading slightly high. After adjustment, it reads +15.040V, so comfortably within the expected range. All other rail voltages are also now comfortably within limits.The display has changed from a full glow and now has a patchy appearance but is still very different from the power-up screen condition I saw the "Introduction to the Tektronix 4051: Part 1" video here:Hitting Page does nothing and there is no cursor. The BREAK, I/O and POWER lights are all lit. When the ribbon cable to the tape drive is disconnected, the BUSY light comes on as well.I now need to decide what to look at next.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 22, 2021, 12:55:12 pm
content: Outstanding purchase!All the manuals for the 4051 have been posted here - including the two service manuals and a folder with scans of the 4051 BASIC ROM:http://www.bitsavers.org/pdf/tektronix/405x/This link contains captured ROM images including some of the 4051 ROM Packs that I captured:http://www.bitsavers.org/bits/Tektronix/405x/Tektronix also had an active user community and published a newsletter "Tekniques" with user articles and programming tips and tricks.Tekniques articles are available here:http://bitsavers.trailing-edge.com/pdf/tektronix/tekniques/And my github repository of programs I plan to 'port' to the Tektronix 4924 Tape Emulator:https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-FilesSeveral Tektronix 4051, 4052 and 4054 repair articles have been posted tovcfed.orgincluding my repairs.The 4052 uses the same tape drive, storage tube, display board with a different mainboard than the 4051.The joystick connector is the small one - I hacked a Kraft PC joystick and successfully connected it to the joystick port. Now I have a Tektronix joystick.I don't believe any of the games used the joystick. The POINTER command required a keyboard key press to read the position of the joystick. This obviously targeted digitizing applications.The 15-pin connector only worked with the Tektronix 4631 and 4632 Hard Copy units that would print the contents of the storage tube screen by scanning the screen and sending the signal to a linear CRT in the 4631 which imaged 3M light-sensitive paper for a printout like the ones I captured from the original Battlestar Galactica TV series:First attachment shows closeup of part of the 4051 screen with the Personnel ReportSecond attachment shows Aurora handing the printout from the 4631 (disguised in the foreground) to Colonel TighThird attachment shows the 4631 hard copy of the 4051 screenFourth attachment is a press photo of the Battlestar Galactica crew with a Tektronix 4051https://vintagetek.org/tektronix-in-movies-shows/link has an article about the Tektronix computers and other equipment loaned to film Battlestar Galactica original TV series.I also highly recommend you visit thehttps://www.facebook.com/groups/1157781747606102Tek 4051 BASIC facebook group which has several 4051 and 4052 users.Here is the link to the post on the 4051 you purchased and my suggestion on troubleshooting:https://www.facebook.com/groups/1157781747606102/permalink/4323203177730594/Last attachment is my Tektronix 4054A, 4052 and 4631 hard copy unit family photo:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 22, 2021, 12:58:40 pm
content: I just saw your last 4051 photo.This screen is expected when powering on a 4051 - the screen does this and you press the PAGE key to clear the screen.If the PAGE key doesn't do anything - the BASIC ROM didn't finish testing memory.You can try to type a simple program:100 PAGE110 PRINT "HELLO"Then type RUN

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 22, 2021, 01:07:34 pm
content: If all the lights are on to the right of the screen - the system ROM did not complete system initialization and none of the keys will work.If only the Power light is on - the system ROM did complete system initialization and BASIC is running.If pressing the PAGE key does not clear the screen - it may be that key isn't working (after 40 years of non-use).I had a couple of keys that needed to be carefully exercised - now all the keys work. The contacts are Cherry keyswitches with gold plating, so they should work better with use.If you type PAGE and press return, the screen should clear (with a background flash), then you should see a blinking cursor.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 22, 2021, 01:17:07 pm
content: When you get your 4051 working - I highly recommend you purchase this Tektronix 4051 10-in-1 ROM pack from vintagetek.org on EBAY:https://www.ebay.com/itm/114758122653?hash=item1ab81dfc9d:g:WyYAAOSwcJxgbKotThis is a new design from one of the Tektronix hardware engineers that designed the Tektronix 4052, and includes ALL the 4051 ROMs and more in one slot:4051R01 Matrix Functions4051R05 Binary Program Loader4051R06 Editor4051R07 Signal Processing I4051R08 Signal Processing II4051R12 Graphics Enhancement4051R14 GPIB Enhancement4051 DDT51.8 6800 Assembly language Debugger4051 Extended BASIC4051 Extended FontsYou also get a documentation CD-ROM with all the ROM Pack User Guides!The EBAY page for this MaxiROM Pack has two photos of a new 4051 "CLIST" command which shows the all the 4051 ROM CALL functions, including ALL the MAXIROM CALLs.The CLIST command is included in the 4051 and 4052/4054 R14 GPIB Enhancement.The internal BASIC ROMs of the 4051 and 4052/4054 do NOT include a CLIST command.My 4054 upgraded to 4054A DOES include a CLIST command, which is very handy.Here is my ROM mapping table for the MaxiROM new CALL commands (from the two CLIST photos in the EBAY post):Code:EXEC This is a standard CALL in all 4051 for assembly language programsRATE, etc These CALLs are included in the 4051 Option 1 RS-232 Comm backpackRPSAFE I don't recognize these? Maybe ROM Pack utilities?RPKILLRPWIPERPCOPYBOUNDS, etc 4051R12 Graphics EnhancementWAIT, etc 4051R14 GPIB EnhancementCONVL, etc 4051R07 Signal Processing IIDN, etc 4051R08 Signal Processing IIDEBUG DDT 51.8 Debugger for 4051 assembly language programsEDITOR 4051R06 EDITORFONT00, etc 4051 Extended FontsWHILE 4051 Extended BASICThere are some very interesting new commands in the Extended BASIC ROM including QDRAW (which I imagine may be similar to the Fast Graphics ROM call?), structured BASIC calls like WHILE and CASE, VLIST and a couple of different CLIST, PEEK and POKE, MTPACK and TNAME.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 22, 2021, 03:33:04 pm
content: Quote from: mmcgraw74 on July 22, 2021, 12:58:40 pmThat would explain why the post is connected directly to the display board.Quote from: mmcgraw74 on July 22, 2021, 12:58:40 pmTried typing this "blind" and then RUN <enter> but nothing.Quote from: mmcgraw74 on July 22, 2021, 12:58:40 pmQuote from: mmcgraw74 on July 22, 2021, 01:07:34 pmAll the lights are on. The BUSY light goes out sometimes but BREAK and I/O always stay on. The POWER light also stays on but this is only to be expected while the unit is powered on. Evidently then, the system ROM did not complete system initialisation so I guess it doesn't get as far as the BASIC ROM.Quote from: mmcgraw74 on July 22, 2021, 01:07:34 pmI did forget about pressing the return, but even with Page + Return unfortunately I get nothing.Quote from: mmcgraw74 on July 22, 2021, 01:17:07 pmYes, once it is working, that does sound like a good idea. Thanks for the link and the details of the commands. I have made a note.I have both volume 1 and volume 2 of the service manual. I found some information about further disassembly and have managed to remove the front bezel and keyboard and access the system and memory boards. I have taken some photos and will have a more detailed look another time.Thank you for the Battelstar Galactica pictures! I did come across and downloaded one picture of the Galactica bridge and will add the pictures you posted to my collection!I have so far resisted joining Facebook, but have just joined using a throwaway account. I have also requested to join the Tek 4015 group and am awaiting acceptance.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 22, 2021, 05:05:04 pm
content: Here is a photo of the Battlestar Galactica bridge with Tektronix 4051's with the screens in use.I also found a Battlestar Galactica article in Miami Herald TV Guide newspaper insert indicating the extras on the set were playing games on the computers to make it more realistic, and they continued playing games when the cameras were off!

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 23, 2021, 09:13:27 am
content: Went to post an update this morning on the Facebook group and found that my account has been locked out. No explanation given, just a dialog to request a review. I logged out and back in again but now don't get any options for anything, just a message that says "Help us confirm its you" but the Continue button is greyed out so I don't appear to even have the option to contact anyone. Only signed up yesterday and my only activity was to make a couple of posts on the group!I tried your advice to disconnect the memory expansion board. It was easy enough to do by just unplugging the ribbon, but I got the same result. Just spent the last hour swapping memory chips two at a time using those from the last bank on the expansion board, but to no avail. It is, of course, possible that there is more than one faulty chip so for all the effort this is still inconclusive.Unfortunately I can no longer report back to the group.UPDATE: just tried another browser and in addition to the above there was a Captcha verification which didn't appear in Chrome. I got past the Captcha and Facebook then did a verification by sending a code to my mobile phone. I then got a message saying that I am back on Facebook. Just going to post the update there.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: July 23, 2021, 12:39:20 pm
content: I created a thread on vcfed.org about repairing your 4051 - that may give additional help!https://www.vcfed.org/forum/forum/genres/other/1217766-new-tektronix-4051-owner-needs-help-repairing-his-4051

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 24, 2021, 09:17:24 am
content: Thanks for creating the post and passing my comments submitted to the Facebook group. The feedback received from members so far has been appreciated and given me some useful lines of investigation to pursue so in this respect it has been very helpful.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 24, 2021, 07:54:24 pm
content: Monty, I attempted building the ROM reader on a breadboard and I have it partially working. Unfortunately at the moment it only reads the top half of the ROM but the bottom half is gibberish. I tried it with a couple of the ROMs and got the same result. It is possible I got something wrong with the wiring so I will re-check this tomorrow and have another go, but it seems to be working in principle. Once I get it working as it should be then I will read and make a copy of all of the ROMs and compare them with those you linked on bitsavers.org.I have finally been able to post on vcfed although my initial post will not appear for some time as the first few will be moderated. Its been up a couple of hours now but still awaiting moderation.UPDATE: Got the ROM reader program working this morning. Re-checked the wiring and found an error. Once I corrected it I could read the entire ROM. I read the two ROMs I tried last night and they compare exactly with the copies I downloaded from bitsavers.org. Now that it is working properly, later on I will go ahead read and compare all of the other ROMs.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: July 27, 2021, 04:03:03 pm
content: I have now checked all of the remaining ROMs including those on the system board, those in the expansion pack and the two in the Binary Program Loader cartridge and they all look good so we can rule out any problems with ROMs. Once I get the PSU back up and running I will be able to get back to re-checking and diagnosing the main board.In the meantime, I checked the fan and tape drive. There is not a lot I can do with the fan. It is running OK but a bit noise. I was hoping to lubricate it but it can't be disassembled for maintenance. On the tape drive the drive motor works fine and the rubberised wheel that makes contact with the tape didn't look too bad either. Unfortunately, the head looked rather crusty. I cleaned it with IPA, then tried Servisol and then rinsed with IPA again. It cleaned up a bit and the read/write elements look fine, but the remainder of the face has quite a bit of oxidisation and might be pitted. I wound't risk running a tape through it as it would probably scrape the magnetic coating off it! In any case, once we get the emulator working, the tape will be surplus to requirements anyway so I'm not too worried about it. For now I have put it back into the machine so it can remain connected.I realised the changes I made in the last version of the emulator code were based on a false premise. Once can't start processing the secondary GPIB commands while ATN is still asserted. There was obviously still something not quite right with 31 and 32, but 33 is definitely not going to work properly. I have obviously been sidetracked over the last few days with getting the 4051 I purchased working so have not done much with the code since last Wednesday. I enjoyed playing with a couple of 4051 emulators today (as you may have seen from my comment on vcfed) and ran a handful of demo programs - at least on Brad's emulator. All good fun!

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 25, 2021, 02:12:53 pm
content: Now that the Tek4051 is repaired and working, I tried connecting the 4924 emulator to it. So far the results are an error message:QuoteIt took me a while but I did find the explanation in one of the manuals.QuoteI will need to figure out what the problem is but so far I have not been able to communicate using GPIB.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 25, 2021, 02:38:03 pm
content: I get that message if the Tape Emulator is not powered and I do an emulator command.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 25, 2021, 04:48:02 pm
content: That would make sense since, in effect, there would be no devices on the bus. In this case, the emulator is powered. I have debugs enabled to allow me to see any byte that the Tek may send but I am seeing nothing at all being sent. I did think that maybe connecting my DMM and using READ or RBYTE might result in some data being read, but unfortunately I got the same error. I am just in the process of reviewing the GPIB circuitry.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 25, 2021, 07:17:27 pm
content: I checked my photos of the Tape Emulator board I sent you - and I mounted the GPIB connector on the bottom side of the board in the same orientation as my board.Here is one of those photos. Did you install the 644 board the same direction as my board? The 644 TX pin should be in the upper right corner of the Tape Emulator board.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 25, 2021, 07:30:50 pm
content: I just rechecked the error message I get on my 4054A when I try a GPIB command to address 5 with the Tape Emulator plugged in but not powered - and it was the error 69.But then if I plug in the power to the emulator, the commands work.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 26, 2021, 10:13:34 am
content: Thanks for checking. I did some more tests with the logic analyser and the results are curious. I posted the details on VCFED but I think there may be another hardware fault. I will be removing the main board again to have a closer look.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 26, 2021, 02:13:34 pm
content: Can I just confirm something with the emulator board. I notice at least 3 pins on the SD card header are taken from the 6-pin header but the pins on the Panaduino board are facing the wrong way up. From your photos I can see that you removed the header and I presume reversed it? Unfortunately the pins do not quite line up. Its only my a millimetre or less but so they might bend but I may end up using short wires instead. I'm not sure I am going to be able mount the SD card reader the same way as you did yours as the pinout is somewhat different to the Pololu version but the pins are in the same order so aside from a slight spacing issue it shouldn't be too much of a problem to solder it in. Its just that pins will have to be bent slightly left or right. I presume however, that those 3 pins with tracks to the SPI header do need connecting up?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 26, 2021, 04:03:39 pm
content: I didn't have details on the exact location of the 6-pin header on the Pandauino board, so the hole locations in my board may not line up exactly.I didn't remove the header from the board, I just loosened each of the pins and pushed each pin down from the top of the board to penetrate the Tape Emulator PCB holes.I did one pin at a time - starting with the ones toward the center of the board and soldered that pin to the Tape Emulator board.If you don't have a Pololu micro SD adapter - you don't need to move the six pins and should be able to jumper those pins to your micro SD adapter and then add one more jumper wire from the CS pin on the 1284 board to your micro SD adapter.The six holes in the Tape Emulator are in the same order as the six pins on the 644/1284 board.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 26, 2021, 10:03:22 pm
content: Quote from: WaveyDipole on August 26, 2021, 02:13:34 pmI missed responding to your last question.Yes the three pins with traces to the 6-pin header need to be connected.Here is my wiring for that board:

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 28, 2021, 12:33:02 pm
content: Thanks. I have now built the Panaduino based Tape Emulator board. It seems to be working. I had to change a couple of things. One was the compiled clock speed which is 16Mhz on the Panaduino, but was 20MHz on the development board. The other was to change the SD card CS pin number back to 4. After that was done, the SD card could be read and I tried the Artillery game again. It loaded fine and all of the commands, FIND, PRINT and OLD worked OK each time. I suspect you are correct in that the problems I was having with the other setup might have been down to wiring. I specifically suspect the cheap breadboard.I have had to use two long Type B USB cables, one for the Emulator and one for the Cypress LA board, which I fortunately already had to hand. The advantage with the Panaduino board is that there is no need for any heavy GPIB cables.On another note, it seems that Tek MaxiROM has now disappeared from eBay. I had it on my watch list since I purchased the 4051 and was intending to purchase it once the computer was repaired and now that the computer is working I had planned to wait for the new month which is just a few days away to make the purchase into next months budget. I have contacted the seller to find out whether there will be any more made available, but with it being a crowd-sourced project and the price being reduced from $50 to $40 I fear that was the last of the stock. I am waiting for them to get back to me and will keep an eye out anyway.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 28, 2021, 07:53:54 pm
content: Great news getting your 4051 repaired and the Tape Emulator board is working. Now it should be easier to debug the remaining codeToo bad about the MAXIROM cartridge no longer posted on EBAY. I did post a note on Facebook as a couple of the members of the Tek 4051 BASIC group do volunteer work for the vintagetek museum - maybe they can help.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 30, 2021, 02:30:39 pm
content: Thank you. I got a reply back from the seller, vintagetek (Bob Haas), as follows:QuoteUnfortunately this confirms what I suspected. I am hoping that someone on Tek 4051 BASIC can help.I asked them whether the technical details and gerbers are available so that I can make at least the PCB myself but am not holding out much hope. The online image has the IC number blurred out and even if I could find out what it was I would still need the ROM content. I imagine this is to deter clones from Far East sources which is understandable.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 30, 2021, 04:39:02 pm
content: With such small volume - I don't see clones from the Far East being an issue.Bob Haas was the hardware engineer on the Tektronix 4052/4054 and then the 4041 computers. Great guy.Bad timing on them selling all the modules. It might be possible to PM one of the facebook folks that ordered the MAXIROM to dump the ROM contents.The new board looks very simple - 20V8 GAL for decode and one ROM. Looking at one of the photos they posted, the previous board had four 27128 EPROMs, so a 27512 bay be the part on the new board.The 4051 ROM Packs were limited to 8KB each (up to four 2Kx8 ROMs or EPROMs).So each 27128 can hold two of the 4051 ROM Packs - not the Hi/Lo labels on each of the original MAXIROM EPROMs. This provides up two eight ROM Packs in the four 27128 or in a single 27512.Jos Dressen created the 4052 Multi-Function ROM Pack - which I have which used an AMD 27C010 1-Megabit EPROM to store the images.If you can get the MaxiRom image - we may be able to modify one of the extra PCBs Jos sent me to make a 4051 MAXIROM. Jos' board also included a 6850 serial interface.I'll do some more checking around and try to find someone who purchased a MAXIROM and would download the ROM image.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: August 31, 2021, 11:41:14 am
content: I got a reply from VintageTek to my request for gerbers and technical information. They didn't send me any technical information, but just the following:QuotePerhaps they have received another inquiry or needed some more for their internal use. I appreciate it must be difficult when demand is very limited and difficult to predict. I will be keeping an eye out on eBay for them to re-appear.BTW, I thought I could make out the sequence AL20V8 on the photo of the IC, but a search for that didn't find anything of interest. Adding the 'G' makes all the difference....I did come across a 4051E01 ROM Expander on eBay but at $225 that's quite a lot of money.The board by Jos sounds interesting and I would have liked to know more, but I guess I should now wait for the MaxiROM to re-appear.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 31, 2021, 01:12:55 pm
content: Great news!Jos' board was designed for the 4052/4054 ROM Packs which are not compatible with the 4051, so a lot of changes would be required to support a 4051 - and since Jos doesn't have one, he didn't offer one.The MAXIROM specifically targets the 4051 - so you wouldn't need a 4051 ROM expander or 4050 ROM expander that supported both 4051 and 4052/4054 computers.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 31, 2021, 08:49:12 pm
content: Quote from: mmcgraw74 on July 20, 2021, 02:06:29 amJohn,I went back to this post (Reply #205 on previous page of this thread) where I was able to get my 4924 Tape Drive to work for a short time.I had the 4924 FIND @4: 2, then INPUT @4: A$.As I reported in that post - file 2 is a TECO text editor program file - yes Tek BASIC can INPUT from an ASCII program file.I posted a zip file "4924FINP.zip" in that thread, but did not decode the cycles.Since the TAPE Emulator is not yet working on INPUT - I spent some time manually decoding the logic analyzer trace file and am attaching that zip to this message.4924FINP - decoded.zip(6.49 kB - downloaded 65 times.)This program file can be found on my repo here:https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/blob/master/4052A-4054A-Assembler/4052A-Assembler%20uni%20format/TECO-editor.uniThe INPUT @4: A$ command only inputs the first CR delimited text string, and the decoded trace listing is a match for the first line of the program.Following the CR sent by the 4924, I see Tek BASIC assert ATN and Tek BASIC send UNTALK then UNLISTEN and then Tek BASIC deasserts ATN and the transfer is complete.Logic Analyzer screenshots of this 4924 transaction are in the post #250

author: mmcgraw74
author_rank: Regular Contributor
timestamp: August 31, 2021, 09:28:23 pm
content: QuoteThe SRQ signal must be miswired. I shredded a ribbon cable to connect a GPIB connector to the HP 10342B Bus Preprocessor that I was hoping to use with the logic analyzer for disassembling the GPIB traces. I haven't gotten the 10342B to work - so I plugged a header pin connector into the ribbon cable and wired the logic analyzer pin by pin. I don't see the Tek seeing an SRQ asserted - so I think it is safe to ignore that signal in the traces for now.The Tek BASIC INPUT command does not read a whole file, nor a whole record. The INPUT command inputs ASCII strings or ASCII numbers and is stopped (delimited) by the CR in the data. No EOI is needed, since the Tek BASIC does not indicate how many variables are in the INPUT command - the ASCII data is input until a CR is received and Tek BASIC will end the command with UNTALK/UNLISTEN.REN is always asserted by Tek BASIC when it starts a program or an immediate command and is deasserted when the program ends (see the 4051 GPIB HW Supp page 1-8, item 10c). The manual also indicates that when REN is asserted - device front panels are disabled and the devices look for commands on GPIB.On a sad note - my 4924 only worked the first time I powered it on. I had to move it and disconnected power and it no longer worksAlso, when I returned from vacation and powered on my 4052 - I can't read the screen, but the computer is working. I think it is a high voltage problem because I can see the blinking cursor and briefly see typed characters which quickly fade out.My 4054A computer is working, but I would have to move the logic analyzer to the other room to connect to the 4054A if we need more traces.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 01, 2021, 12:59:24 pm
content: Quote from: mmcgraw74 on August 31, 2021, 09:28:23 pmAh, that explains the SRQ signal then. I agree. It can be ignored for now.Quote from: mmcgraw74 on August 31, 2021, 09:28:23 pmThat is understood. EOI is sent only when the end of the file is reached. I did some work on PRINT and INPUT as they are reciprocal and for working with text data files. I have PRINT writing raw data to file on the SD card and I think I may have nailed the problem with INPUT causing the Tek to get stuck and requiring a BREAK. In addition to asserting EOI at the end of the file, it also has to send the EOF character (FF). That signals the Tek to end the transmission with UNT and UNL, otherwise it just sits there expecting more data. What I still don't have is variables being read back correctly. For example:PRINT@5:A$,BINPUT@5:A$,BI expected this would write a string and a number to an ASCII data file and read it back, but A$ ends up containing the string with the number tacked on to the end. I notice from the tek 4050 Series Basic Reference, that the PRINT command makes use of formatting options using the USI and IMAGE commands. The text states that the format string optionally "can be" specified in an IMAGE statement, but doesn't state whether formatting using the USI command is mandatory. I had experimented with the USING command to format the output of four variables which does work, but since there seems to be no corresponding command to format the variables for the INPUT statement, it all ends up in the first string variable anyway.Do you have a definitive test I could use for the readback of variables? I found the ADVKEYS data file we used for testing previously, but I don't have the program that can read back that data and which I presume was tested and working properly on one of your Teks? Would it be possible to have a copy please?Quote from: mmcgraw74 on August 31, 2021, 09:28:23 pmInteresting observation and I noticed the same behaviour of REN on the handful of traces I carried out over the last couple of days. I hadn't linked it to a the program being executed, but I have only been running individual commands at the cursor which individually can be considered a one line program. REN gets asserted a few milliseconds before ATN and gets de-asserted a few milliseconds after the final ATN during which UNT + UNL are sent. After reading your comment I tried running a short two line Hello World program on the 4051 with no GPIB comms and monitored on the LA. I do see the same behaviour as you mention. I believe the panel gets disabled on the device being addressed. certainly that's what happens with my DMM.Quote from: mmcgraw74 on August 31, 2021, 09:28:23 pmSorry to hear that. Seems a bit odd though.Quote from: mmcgraw74 on August 31, 2021, 09:28:23 pmYou may be correct and you mentioned a weird fog in the centre on the VCFED thread. Do the characters shrink towards the centre as they fade out? If not, then it might not be the EHT choke. Does it use a storage tube like the 4051? If so then maybe its related to one of the unregulated supplies (+320v and +185v on the 4051).Quote from: mmcgraw74 on August 31, 2021, 09:28:23 pmSince I now have a working 4051 to test with, I can now do my own LA traces so there should be less of a need for me to rely on them being sent over unless it is something related specifically to the 4052 or the 4054.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 01, 2021, 04:24:32 pm
content: QuoteI'll break down your latest questions into individual replies.You cannot PRINT a string AND another string or numeric variables in a single BASIC statement.Tek BASIC strips the quotes from a string variable in all PRINT commands (to the screen or to tape or GPIB device), and then sends a CR to terminate that string.PRINT is able to send multiple numeric variables in a single statement, and that operation will ALSO be terminated with a CR.Consequently - the INPUT command from a file on tape or GPIB device ALWAYS has a CR and the tape or device returning the CR causes Tek BASIC to end the INPUT of the data. THEN Tek BASIC parses that buffered data for the variable(s) - either a single ASCII character string, or as many numeric variables as that INPUT command contains.This PRINT/INPUT behavior will result in Tek BASIC hangs during the INPUT - if the variables cannot be parsed.Example - I entered the following program into my 4054A:Code:100 A$="This is a test string"110 B=532120 FIND 13130 PRINT @33:A$,B140 CLOSE150 FIND 13160 INPUT @33:A$165 INPUT @33:B170 PRINT A$,B180 ENDI have attached my photo of the 4054A with the program list and resultsNote that running this program resulting in Tek reporting EOF in line 165.This is because the string and the number were printed to the tape, then CR terminated.The line 160 input returned the string PLUS the 532, so if we did PRINT A$ we would see both the string concatenated with 532.When Tek then tried to run line 165 - there was no more data in the file - and EOF was detected.I then recalled line 160 and added the B to the INPUT, and I typed 165 with CR - which deleted line 165 and reran the program. That didn't fix the problem - since both A$ and B were PRINTed to the same line, and Tek BASIC requested more data from tape and got EOF.Then I edited the line 130 PRINT statement to remove B, and added a line 135 PRINT statement to write the B separately.Now running the program resulted in no hang or EOF and both the A$ and B printed.As further proof - I loaded my TapeDump8 program into the 4054A (using serial), and did a dump starting with file 13, and my dump program continues until it reaches a LAST file.The second photo attachment shows ALL the bytes in File 13:I'm not sure why this dump shows two File 13 Header strings, I may not have downloaded my latest TapeDump8 program - since I didn't have my USB flash drive plugged in which DOES have the latest program.I am using Notepad++ to display the dump file contents and have enabled viewing ALL characters including control characters.Line 4 - the file header, CR terminatedLine 5 - a blank line filled with spaces - this is the remainder of the first tape file block of 256 bytesLine 6 - A$ properly terminated with CR and no quotesLine 7 - B ASCII printed numeric variables always have a leading space, and as the only numeric variable in that PRINT statement in the new line 135, it is CR terminatedLine 8 - the ASCII character 127 which is used as the EOF marker

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 02, 2021, 08:50:27 am
content: I have tested bearing in mind your comments that you can't mix both numbers and string variables in the same statement except in my test I had the numeric variables first. As you pointed out, it is possible to print several numeric variables in a single PRINT statement and read them back with INPUT:PRINT@5:111,222,333,444,555FIND@5:3INPUT@5:A,B,C,D,EThis read back the 5 values into variables A to F. I then tried printing a string variable to the file and reading back the 5 numeric variables first with one INPUT command and then the string variable using a second input command (INPUT F$) but ran into a hang. Further investigation reveals that individual PRINT statements work fine and terminate with a CR as you describe, but subsequent PRINT statements seem to overwrite the previous line, in other words, the write operation starts at the beginning of the file each time. When I edited the file manually and added in a test string on a second line, I could then read back the numbers with one INPUT statement and the string with a second INPUT statement. I need to figure out why the write operation seems to restart at the beginning of the file each time.I also copied the PRINT routine into WRITE and the INPUT routine into READ. A minor amendment needed to be made to allow them to operate on BINARY DATA files but a test shows that it is possible to mix numeric and string variables in one WRITE statement and read them back. At the moment these two routines are writing binary bytes. There is no conversion to the HEX representation of bytes, but this can be added as you have already provided the code for this. The Tek writes, reads and handles the header byte pairs so there is no need for the emulator to handle this. It just needs to write and read back the raw data.Hopefully today I can solve the file pointer problem and we should then have working PRINT and INPUT.Looking ahead, I realised that it will not be possible to read/write/amend the file header as described in the manual. The example shows that the header is read from the first record in the file which would work fine with the 4924. However, on SD, the header information is stored in the filename so it can't be read from the file content. That problem comes further down the line but once we get around to commands like MARK, KILL and SECRET, the handling of the header will need to be resolved.I am also a little unclear about the CLOSE command which I note you have used in your program. If I open a file with FIND and then do CLOSE, nothing actually happens on the GPIB bus. CLOSE@5: seems to do nothing either. CLOSE@5:1 gives me an IO error. I am not sure how to actually issue a CLOSE on a file on the emulator as I see no activity there in response to the command being issued. The closest I can come is to issue a FIND@5:x where x is another file. The 4924 doesn't actually list a CLOSE command in the table of operating commands.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 02, 2021, 12:29:20 pm
content: UPDATE: I think that with a little help I may have solved that PRINT problem and PRINT/INPUT it now seems to behave as you describe. I will tidy up and push it up to the repository in a while so you can give it a try.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 02, 2021, 12:54:47 pm
content: Quote from: WaveyDipole on September 02, 2021, 08:50:27 amThe editing of the file header is not typical in programs - in fact, the only program I have found that does that is from Tektronix as a utility, to help add user information to the file header.I don't know if Tek BASIC reads the file header. I believe (but am not positive) that BASIC reports errors if you attempt to write or print to the wrong type of file. This should be easy to verify.According to the BASIC reference manual - pages 7-30 and 7-31, the CLOSE statement, FIND statement, END statement or pressing BREAK key twice, will flush the mag tape write buffer contents to the tape.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 02, 2021, 12:57:11 pm
content: Quote from: WaveyDipole on September 02, 2021, 12:29:20 pmI'll check it out!

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 02, 2021, 02:43:15 pm
content: Quote from: mmcgraw74 on September 02, 2021, 12:57:11 pmJust pushed up version 0.05.35.Thanks for the info on the header. I guess it makes things easier if we don't have to worry about editing the header information. The MARK command just needs to create a filename header in the appropriate format and with the correct number sequence and SAVE needs only to re-write the existing file name to make it a PROG type.I did a bit more digging and it seems CLOSE is listed as one of the commands in the alternative commands table. Since we are not using alternative sequences, we probably don't need to worry about it too much. FIND closes the previous file and OLD automatically close a file after it has read it. I found it curious that neither CLOSE, END or pressing BREAK twice appeared to send anything to the GPIB bus so I had a look on the logic analyser. When CLOSE or END is executed, only the REN line goes low briefly but nothing else happens. When BREAK is hit twice, nothing happens at all on the GPIB bus so its a bit of a mystery quite how the data is flushed to tape....

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 02, 2021, 05:31:28 pm
content: I have downloaded your version 0.05.35.I had to change a couple of things to make it compile:1 - I edited the Store_Tek_4924.h file to set SD_SCK_MHZ(50) as the parameter name wasn't found2 - I commented GPIBdevice.h line 1. I googled ArduinoCloudProvidersExamples and the Arduino.cc page indicates it is only compatible with boards with the SAMD CPU.3 - Then I updated the Config.h line 10 to display the 0.05.35 version number when I use the ++ver command on the serial console.I can use INPUT on ASCII PROGRAM files but not ASCII DATA files?How do I enable the serial debug output to see those commands on the serial console?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 02, 2021, 06:15:59 pm
content: I enabled debug serial console and cmd parser.I found a change needed to be made in FIND command.I decided to create a file 0 in each directory with the header string for each of the files.My file 1 in each directory is a menu program - the last selection will emulate a TLIST command by printing each of the lines in file 0.The 5.35 code for FIND starts looking for file 1.I edited Store_Tek_4924 line 349 and changed (filenum > 0) to (filenum >=0).Then when I recompiled, I did this test on my 4052 (non-persistent display but I can see the lines printed for a moment):PRINT @5,19:"UTILITIES"FIND@5:1OLD@5:RUNI then selected 2 to get a TLIST and it worked!I then moved the Tape Emulator to my 4054AI was able to load the "UTILITIES" file 1, however the 4054A hung on the line 100 INIT statement and didn't print anything.I had to power cycle the 4054A - and I power cycled the Tape Emulator.I loaded "UTILITIES" file 1 again and deleted line 100.Now the program printed the menu and waited for my INPUT.I typed 2 and the 4054A and it hung again and required power cycling.So good news with my changes on the 4052.Please try that with your 4051.I will need to hook a laptop with serial to my 4054A to see what is happening on the serial debug console.New feature request - If the Tape Emulator detects REN going inactive it should exit the current command (and flush writes if necessary) and return to idle.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 02, 2021, 09:23:05 pm
content: Ok - more progress.I wanted a longer test for the current features, so I have uploaded a new Tek4924sd set of files to the Store.Two new folders:SYSTAPE - all the files from the Tektronix 4050 System Software tape, ported to use the Tape Emulator for file access.ADVENTURE - my port of adventure from the 4907 floppy drive system to use Tape Emulator for file access.Adventure will start and load some data files until it runs out of memory on your 4051.This game requires 64KB of RAM - so is limited to the 4052 and 4054 computers for now.I ported this from a Commodore PET version that runs in 32KB. But the Commodore version makes heavy use of integer variables, integer arrays and string arrays.Tek BASIC does not support integers - all numbers are in double-precision floating point and take 8 bytes of memory per numberI do think with the 4051 CALL "EXEC" command, we could create assembler programs to handle the integer arrays and try to squeeze this Adventure version into a 4051 with 32KB of RAM (after the Tape Emulator is done).In the meantime - I tried the SYSTAPE on my 4052:PRINT@5,19:"SYSTAPE"FIND@5:1OLD@5:RUNThis file 1 is a menu program - I picked the first selection and it loaded file 2 which finds there is more than 8KB of RAM and it loads file 7.But since I can't read all the screen in my 4052 until I fix the display, I didn't try to manually enter Y data points to see a simple Y-Plot.Then I decided to try to run Adventure and ran into a Tape Emulator bug.PRINT@5,19:"ADVENTURE"FIND@5:51 (the main program is file 51 not file 1)OLD@5:RUNI could see on my 4052 it print "Welcome", then I saw a GPIB error 69 on line 179.Line 179 contains the FIND @5:2 command to open file 2.Previous to that the lines opened file 1 and read 131 pairs of numbers.I noticed in my early testing with my continuedDev version that I had to add time delays in Adventure between successive INPUT commands.I don't think that should be necessary if the Tape Emulator needs more time before it is ready for a command, it should be able to delay Tek BASIC using GPIB protocol.Here is the debug output when the delay is too short.You can see in line 62 the first INPUT from file 1, the numbers 1 and 133488.Then I see another 1 being printed on the debug console - that doesn't look right.Then the emulator reports ATN or ERR during send and then done and then the next INPUT command.There are errors on every transaction - and on the Tektronix side it did get the data, but the Emulator didn't respond on the INPUT in the next section of code.Adventure - debug1.zip(1.71 kB - downloaded 94 times.)

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 03, 2021, 08:22:53 am
content: Quote from: mmcgraw74 on September 02, 2021, 05:31:28 pm1. I added the parameter to AR488_Config.h. The storage section in mine now looks like this:#define EN_STORAGE#ifdef EN_STORAGE#define SDCARD_CS_PIN 4 // SS pin on Pandauino 644-Narrow / 1284-Narrow (644P/1284P)#define SDCARD_CLK 16 // Clock speed in MHz#define EN_TEK_4924// #define EN_PET_9060#endifSince the SD card reader doesn't have its own clock, my assumption was that this should match the speed of the Arduino clock? I previously had it set to 20MHz as my dev board has a 20MHz crystal. Adding the parameter to the Config file allows it to be set as required. The parameter '#define SDCARD_CS_PIN 4' can actually be commented out as it will use pin 4 by default anyway.2. That line is spurious. Not quite sure where it came from but I have deleted it.3. Since we now have the same setup that uses the same CS pin number, I will be pushing up the AR488_Config.h file from the next update.Thank you for the details of your tests which are encouraging. I will look over them in detail and investigate any anomalies. Just to reply to one point:Quote from: mmcgraw74 on September 02, 2021, 05:31:28 pmThat's curious because I was actually testing with ASCII DATA files. Is it possible that the letter 'D' is not in the correct position in the file name? Did you notice from the emulator console what type is was identified as?It might just be worth checking the number of spaces in the filename and make sure that 'D' is the eighth character. The INPUT function should work on both ASCII DATA and ASCII PROG files.QuoteThank you for the detailed report on your testing. I picked up a couple of things while skimming through it but I plan to have a more detailed look later and carry out the tests you suggest.Quote from: mmcgraw74 on September 02, 2021, 05:31:28 pmI will make this change and test on my 4051.QuoteI agree. Versions 05.32 and 05.33 had a problem in that regard but neither 0.31 nor version 05.35 should need any delays. Of course, 05.31 will not have the latest developments and fixes. I will test Adventure on the 4051 a bit later to see how it behaves.I have also noted the new feature request and will have a think about how this can be implemented.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 03, 2021, 10:14:24 am
content: I updated line 349 of Store_Tek_4924 as suggested and I do now get the TLIST. Selecting a program returns back to the "UTILITIES menu", although looking at line 450 of file 1 in UTILITIES that looks like what it was meant to do so I guess the test was a success!

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 03, 2021, 11:51:00 am
content: QuoteYou are correct, I found that my filenames in that folder were not aligned properly - the serial debug output pointed out my error.I fixed all those filenames in my latest sd image zip file upload.You should be able to test the Adventure file input commands.I wrote a short test program on my 4054A yesterday and duplicated the hangs:100 PRINT@5,19:"ADVENTURE"110 FIND@5:1120 FOR J=1 TO 131130 FOR K=1 TO 100140 NEXT K150 INPUT A,B160 PRINT A,B170 NEXT J180 ENDI tried changing the delay in line 130 but it didn't affect the results.Typically the program would hang (but BREAK key worked) at line 150 with J=2 or J=3 on my 4054A.Running this on your 4051 might work with smaller or no delays.Sometimes my 4052 would complete the loop of 131 data pairs - mostly not.The 4054A uses the TI 9914 GPIB IC - so it has quite a bit faster GPIB performance than the 4052 (which has the same discrete GPIB interface as the 4051), plus both of them are about 10x faster CPUs than the 4051.I suspect I will need to get a logic analyzer trace of my 4052 and 4054A running this test program to compare to the 4051 result.We should be able to add each of the following sections of code that access the other data files - some of which INPUT strings.When all those data files can be read successfully on my 4052 and 4054 with the delay code removed - Adventure will work

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 03, 2021, 12:08:17 pm
content: The Tektronix Tekniques newsletter - Vol 6 No 3 Fall 1982 pages 18-19 had an article on the introduction of the 'new' A-Series 4052A and 4054A.http://www.bitsavers.org/pdf/tektronix/tekniques/vol6/Tekniques_Vol_6_No_03.pdfIt said the BASIC performance for some commands was up to 20% faster and the GPIB performance was 4X faster than the original 4052 and 4054.In addition 38 new BASIC commands were added including IF/THEN/ELSE, DO/EXIT IF/LOOP and character strings supporting full 256 ASCII characters instead of original 128 characters.Another BASIC enhancement which was not published at that time was the 4052A/4054A CALL "EXEC" assembly language command - used in the 4052A/4054A Assembler program, whose documentation included the A-Series ROM entry points and all the new 16-bit bit-slice CPU opcodes!After the 4052A/4054A Assembler program was published - Tektronix followed with the 4051 Assembler program which also included 4051 ROM entry points.I posted both of these assembler programs and docs on my Tektronix 4051/4052/4054 program repository:https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 03, 2021, 12:39:41 pm
content: I ran the program after a small modification on the 4051 and it ran up to the final entry no. 314. The first time I ran it I was prompted for an entry so I modified it to request the data from device 5. I also had to change the case for the word "ADVENTURE" to "Adventure". No big deal. The modified version I ran:Code:100 PRINT@5,19:"Adventure"110 FIND@5:1120 FOR J=1 TO 131130 FOR K=1 TO 100140 NEXT K150 INPUT@5:A,B160 PRINT A,B170 NEXT J180 ENDThis ran all the way through to the final entry no. 314. I then removed lines 130 and 140 leaving:Code:100 PRINT@5,19:"Adventure"110 FIND@5:1120 FOR J=1 TO 131150 INPUT A,B160 PRINT A,B170 NEXT J180 ENDThis also ran up to entry no. 314. I ran it five times times more and it ran without an error. One slight anomaly I noticed was that some numbers were being represented with exponents. For example entry no. 206 was printed as 1.0541692E+7. I presume this is due to the size of the number in question which has 8 digits. There were a handful of others in the listing.I will carry out and post a logic analyser trace a little later.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 03, 2021, 01:53:00 pm
content: Excellent result!Yes, some of the integers have exponents due to the number of significant digits.Can you add test code to process all four data files 1 through 4.Your test code doesn't have to worry about the arrays - you can put the results in simple variables for the test.If you remove the print variable code and then just print the J value from each completed loop, completion of all four tests is an extensive test of the INPUT command on the 4051!BTW - lines 246 to 257 read a set of strings and concatenate them into a single string while saving pointers to each one in the V9 array. No need to do anything like that in the test - just read each of the strings.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 03, 2021, 02:18:05 pm
content: Will do. Running out of time today, but maybe tomorrow. Just had a quick look at files 2 - 4 and I see they are in different formats. Did you want me to modify the program accordingly for the data in each file and run each one separately? I don't mind doing arrays, perhaps for file 3 where 5 variables per line are involved. It will be good programming practice in any case.I have just done a LA capture of the GPIB bus while the test program was running. I have attached the text output from the Sigrok PulseView IEEE decoder and some images of the traces.Overview of transmission:Start of transmission - switching to the Adventure directory:Selecting file 1:Burst of data reading each pair of variables.Final two bursts and transmission ends:

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 03, 2021, 02:21:27 pm
content: I was thinking to add all the file tests into one test program - but just printing the final loop count on each file to show the complete file was read successfully. Then you wouldn't need to page the screen.I guess each test could be written individually with data printout to verify the output matches the data file, then combine them all and REM or delete the output print statements.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 03, 2021, 02:23:58 pm
content: I can also generate binary versions of these files to be used for READ/WRITE tests.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 03, 2021, 02:30:32 pm
content: No problem. I can do all 4 as a single batch.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 04, 2021, 04:20:39 pm
content: I did some troubleshooting on my 4052 display issue - it appears to be the Collimator circuit that isn't working.Here is the description of that circuit and the schematic page:I clipped onto resistor leads and connected to a voltmeter.Q361 was off and the R359 adjustment pot voltage changed on the collector pin as I adjusted that pot.When I pressed the PAGE key to ERASE the screen, the voltage dipped briefly toward zero.Q162 appears to be the problem. When I press the PAGE key neither the emitter or collector voltage changed, although the base voltage changed from -4V to 0V.I've ordered a replacement transistor - the Tektronix Common Semiconductor Manual indicated the P/N is 2N4250.The symptom I have is similar to the description of the Collimation circuit:QuoteMy voltage on P58 pins 3 and 5 was around 0.4V

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 04, 2021, 04:40:33 pm
content: Not deterred by my 4052 display issue - I decided to capture the 4052 running the simple INPUT test program on the Adventure file 1.I change the output PRINT statements to PRINT @40: which is the Option 1 Serial interface port. I connected my USB serial adapter to the 4052 serial connector - configured the port for 9600-8N1 and used Tera Term to send the test program to the 4052 and to show the output of the test program.I also connected the Tape Emulator to the same PC and used RealTerm to display the Tape Emulator serial debug output.Here is my slightly modified test program:Code:100 PRINT@5,19:"ADVENTURE"110 FIND@5:1120 FOR J=1 TO 131130 FOR K=1 TO 100140 NEXT K150 INPUT@5:A,B160 PRINT@40:A,B170 NEXT J180 PRINT@40:"DONE"190 ENDI started with a time delay of 100, and on the first run - all the data was received, but I didn't have the logic analyzer capture the data.Then I changed the delay to 10 and only got to J=17, and still didn't have the LA connected.I then connected the logic analyzer and tried the delay of 10 but all the data was received.Then I changed the delay to 1 - started the LA and all the data was received.We should be able to compare the screenshots and zip of the trace file - attached.First screenshot is running the "CD Adventure" command:Second shot is the Tek BASIC UNTALK/UNLISTED at the end of every command - no need to show this againThird image is FIND@5:1Next is the INPUT@5: A,Blast attachment is the trace file. The LA doesn't have enough samples for the entire trace.FNDINP.zip(8.1 kB - downloaded 42 times.)Sorry - last attachment is the first set of A,B from file 1

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 04, 2021, 06:19:20 pm
content: I put together a test program as you suggested and gave it a try and ran into some problems.Here is the program:Code:100 REM Adventure File 1110 PRINT@5,19:"Adventure"120 FIND@5:1130 FOR J=1 TO 131140 INPUT@5:A,B150 NEXT J160 PRINT "File 1 total: ", J-1, "pairs of numbers read"200 REM Adventure File 2220 FIND@5:2230 FOR J=1 TO 114240 INPUT@5:A$250 INPUT@5:B260 NEXT J270 PRINT "File 2 total: ", J-1, "string/number pairs read"300 REM Adventure file 3320 FIND@5:3330 DIM K0(5)340 FOR J=1 TO 228350 INPUT@5:K0(J)360 NEXT J370 PRINT "File 3 total: ",J-1, "groups of 5 numbers read"400 REM Adventure file 4410 T = 0415 X = 0417 Y = 0418 Z = 0420 FIND@5:4430 FOR J=1 TO 38440 INPUT@5:A$450 NEXT J460 X = J470 PRINT "File 4 sub-total: ", X, "statements read"480 FOR J = 39 TO 76490 INPUT@5:A500 Y = Y + 1510 NEXT J520 PRINT "File 4 sub-total: ", Y, "numbers read"530 FOR J = 77 TO 114540 INPUT@5:A$550 Z = Z + 1560 NEXT J570 PRINT "File 4 sub-total: ", Z, "items read"580 T = X + Y + Z590 PRINT "File 4 total: ", T, "lines read"600 ENDWhat happened was that it finished running up to line 200 but hung. on line 220. Hitting break twice resulted in this error message being displayed:QuoteI did manage to repeat the process and capture the result on the logic analyser but have not had time to analyse it properly yet. A quick look shows the INPUT loop running and finishing normally, but the subsequent FIND statement does not run.Good news on identifying the problem with your 4052! I take it that the biasing resistors around Q162 were OK then? What voltage did you get at the emitter?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 04, 2021, 06:28:24 pm
content: I think I saw the same error message when I tried running the full Adventure program (file 51).I'll try your longer test program on my 4052.Monty

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 04, 2021, 06:55:51 pm
content: I had the same result on my 4052 - although I can't see the error message - the program stopped immediately after the line 160 "File 1 total" was printed.I have enabled DEBUG_SERIAL_INPUT and DEBUG_CMD_PARSER and I see "EOF reached!" after the last data pair.All the data pairs prior print out the two data numbers with a comma between, then there is a print of a single digit on the next line. This digit happens to be the same as the first digit of the first data number -weird.In addition - every data pair is followed by "ATN or ERR during send!!" although the data was received by TEK BASIC.The following line is "stgc_0x6D_h: done." messageExcept on the last data pair - there is no "ATN or ERR during send" message, but there is an "EOF reached!" message with a blank line and then the "ATN or ERR during send!!" message, followed by the stgc message - and no other messages.Here is a snippet of the end of the serial debug output:Code:stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...308,1089703ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...309,1177593ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...309,83216913ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...310,4055013ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...311,34263ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...312,21507313ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...313,3197783ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...313,27077273ATN or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...314,1233737EOF reached!ATN or ERR during send!!stgc_0x6D_h: done.I'm adding a screenshot of the RealTerm display of ALL the characters at the end of the debug log:Notice that all the data pairs except the last one are terminated by CR.The last data pair has a different termination of CRLF.I'll bet there is an output statement with an LF prior to the EOF reached?

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 04, 2021, 07:22:39 pm
content: The output on the serial console here is identical:Code:Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...313,3197783ATN detected or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...313,27077273ATN detected or ERR during send!!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...314,1233737EOF reached!ATN detected or ERR during send!!stgc_0x6D_h: done.After the last ATN, the one after 'EOF reached!' the interface should be going back into a listen state to receive the next command but something is going wrong here. If one breaks out and the FIND command is run manually it works. I am going to update the writeByte() function to separate out the detection of the ERR and ATN conditions so we can see which one is actually occurring.The weird repetition of the first character is because the loop has read the next character after the CR, but the Tek has interrupted the transmission. That's why the fuction goes back a char before the next read. I am thinking that maybe it should be programmed to send and stop at the CR rather than waiting for the Tek to interrupt. The Tek should perhaps only interrupt when its buffer of 74 chars have been filled. I don't think that explains it sticking on the next FIND command though.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 04, 2021, 08:12:08 pm
content: I commented out the Store_Tek_4924.cpp line 705 to suppress the ATN or ERR messages in the INPUT command and uncommented the line 696 close function.This is allowing the file 1 to be closed and the next loop on file 2 starts to run:Code:Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...313,3197783stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...313,27077273stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...314,1233737EOF reached!stgc_0x62_h: started CLOSE handler...stgc_0x62_h: closing: 1 ASCII DATA [ADVKEYS ] 8...stgc_0x62_h: done.stgc_0x6D_h: done.Executing secondary address command: 7Bstgc_0x7B_h: started FIND handler...stgc_0x7B_h: received parameter: 2searchForFile: searching /Adventure/...searchForFile: found file 2searchForFile: done./Adventure/2 ASCII DATA [ADVSHOR ] 20stgc_0x7B_h: found: 2 ASCII DATA [ADVSHOR ] 20stgc_0x7B_h: type: DExecuting secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...You're in open forest near both a vstgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...valley and a road.101Ystgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...You're in open forest.stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...101Ystgc_0x6D_h: done.However - this loop does not finish.I have gotten to loop2 of 38, then 79, then it just stopped before the loop2 began

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 04, 2021, 08:15:59 pm
content: And I just tried it again and loop 1 and 2 completed, but loop 3 stopped but Tek is still busy.And I pressed BREAK several times and the Tek (or Emulator) must be hung.Here is the debug log finishing loop2 and starting loop3:Code:Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...You're at ne end.stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...33Ystgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...You're at sw end.stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/2 ASCII DATA [ADVSHOR ] 20...33EOF reached!stgc_0x62_h: started CLOSE handler...stgc_0x62_h: closing: 2 ASCII DATA [ADVSHOR ] 20...stgc_0x62_h: done.stgc_0x6D_h: done.Executing secondary address command: 7Bstgc_0x7B_h: started FIND handler...stgc_0x7B_h: received parameter: 3searchForFile: searching /Adventure/...searchForFile: found file 3searchForFile: done./Adventure/3 ASCII DATA [ADVMAP ] 16stgc_0x7B_h: found: 3 ASCII DATA [ADVMAP ] 16stgc_0x7B_h: type: DExecuting secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/3 ASCII DATA [ADVMAP ] 16...,2,2,5,5,3,stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/3 ASCII DATA [ADVMAP ] 16...,3,8,8,0,0,stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/3 ASCII DATA [ADVMAP ] 16...,3,3,6,6,1,stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/3 ASCII DATA [ADVMAP ] 16...,1,4,4,0,0,stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/3 ASCII DATA [ADVMAP ] 16...,5,5,1,1,4,stgc_0x6D_h: done.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 04, 2021, 08:19:59 pm
content: That's interesting to note. It would affect the timing of things I suppose, but strange.Will hopefully have some time to investigate things further tomorrow.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 06, 2021, 12:04:35 pm
content: I have been making a bit of progress and the program now runs through all files without a problem, but I had to make a couple of modifications to the original program. There was en error in line 350 and line 450 needed an amendment. Here is the full program listing:Code:100 REM Adventure File 1110 PRINT@5,19:"Adventure"120 FIND@5:1130 FOR J=1 TO 131140 INPUT@5:A,B150 NEXT J160 PRINT "File 1 total: ", J-1, "pairs of numbers read"200 REM Adventure File 2220 FIND@5:2230 FOR J=1 TO 114240 INPUT@5:A$250 INPUT@5:B260 NEXT J270 PRINT "File 2 total: ", J-1, "string/number pairs read"300 REM Adventure file 3320 FIND@5:3310 REM Note empty var before comma = 6 vars330 DIM K0(5)340 FOR J=1 TO 228350 INPUT@5:K0360 NEXT J370 PRINT "File 3 total: ",J-1, "groups of 5 numbers read"400 REM Adventure file 4410 T = 0415 X = 0417 Y = 0418 Z = 0420 FIND@5:4430 FOR J=1 TO 38440 INPUT@5:A$450 NEXT J460 X = J - 1470 PRINT "File 4 sub-total: ", X, "statements read"480 FOR J = 39 TO 76490 INPUT@5:A500 Y = Y + 1510 NEXT J520 PRINT "File 4 sub-total: ", Y, "numbers read"530 FOR J = 77 TO 114540 INPUT@5:A$550 Z = Z + 1560 NEXT J570 PRINT "File 4 sub-total: ", Z, "items read"580 T = X + Y + Z590 PRINT "File 4 total: ", T, "lines read"600 ENDNaturally a bit more tweaking was required to the emulator code.I also wanted to check something. This is an excerpt from file 3 of the adventure program:Code:,2,2,5,5,3,3,8,8,0,0,3,3,6,6,1,1,4,4,0,0,5,5,1,1,4,4,2,2,0,0,3,3,2,2,8,8,5,5,0,0,1,1,6,6,4,4,3,3,0,0Why does INPUT still treat this as 5 variables, not 6? Wouldn't the preceding comma imply a null variable in the first position? Setting K0 to 5 elements works, but setting it to 6 fails.I have pushed up the updated code.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 06, 2021, 01:30:28 pm
content: Quote from: WaveyDipole on September 06, 2021, 12:04:35 pmCheck out the 4050 BASIC Reference manual page 7-88 section on the INPUT command.Every INPUT command brings inoneASCII string that is CR delimited. Then Tek BASIC looks for the variable parameters in that INPUT statement. If it cannot satisfy all the variables within that string - Tek BASIC will automatically issue another INPUT command.Top of page 7-89 indicates ANY non-numeric characters preceding a numeric value are ignored.That is why Tek BASIC finds 5 numeric variables in each ASCII string in file 3.Monty

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 06, 2021, 02:18:27 pm
content: Ah, that makes sense. I would be interested to know how 0.05.37 works out on your 4054.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 06, 2021, 04:21:13 pm
content: I have been trying v37 on my 4052 first.I can't make it through your latest test program. It stops at random INPUT statements, I run from that statement and it goes farther, but still can't complete the test after restarting a half-dozen or so times.Also - the debug output of the actual file data is getting clobbered by CRLF.I edited your v37 Store_Tek_4924.cpp debugStream statements in the INPUT command so I can see the data.Line 757 - I added a new line after 757:debugStream.print("\r ");This prevents the CRLF of the line 757 println from clobbering the first two data characters in the RealTerm output.I also changed the debugStream.println(F("receiver requested stop!")); and the ATN detected statement to print with trailing \rNow - as an example the debug output looks like this.Note that I intentionally added a space in front of the single data statements.Sometimes the INPUT statement reads multiple strings without calling out "receiver requested stop" like the first INPUT in the trace below.The printing of those subsequent data statements has no leading space - since there are not leading spaces in those filesCode:Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...There are fresh batteries here.Dead batteries are lying here.A burly troll stands in front of you.A huge fierce green dragon bars the way!A huge fierce green snake bars the way!A 20-ton dead dragon lies here.receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...18 receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...25 receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...23 receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...24 receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...21 receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...52 receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/4 ASCII DATA [ADVITM ] 12...0receiver requested stop!stgc_0x6D_h: done.------------Line 490 j=47Executing secondary address command: 73stgc_073_h: started CD handler...venturestgc_0x73_h: received directory name: Adventurestgc_0x73_h: set directory name: /Adventure/stgc_0x62_h: started CLOSE handler...stgc_0x62_h: closing: 4 ASCII DATA [ADVITM ] 12...stgc_0x62_h: done.stgc_0x73_h: end CD handler.Executing secondary address command: 7Bstgc_0x7B_h: started FIND handler...stgc_0x7B_h: received parameter: 1searchForFile: searching /Adventure/...searchForFile: found file 1searchForFile: done./Adventure/1 ASCII DATA [ADVKEYS ] 8stgc_0x7B_h: found: 1 ASCII DATA [ADVKEYS ] 8stgc_0x7B_h: type: DExecuting secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...1,133488receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...1,6771679receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...2,36315receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...2,8849417receiver requested stop!stgc_0x6D_h: done.Executing secondary address command: 6Dstgc_0x6D_h: started INPUT handler...stgc_0x6D_h: reading /Adventure/1 ASCII DATA [ADVKEYS ] 8...3,4673330My 4054A couldn't get as far as the 4052.In fact it had error 69 on the PRI@5,19:"adventure" directory command.I had saved the test program to file 52 in the adventure directory, and manually accessed that directory and OLDed the program successfully.After commenting out the directory line 110:Upon running the program it always posted GPIB error 69 after reading two pairs.I even added PRINT A,B and it printed the two pairs of numbers then posted a GPIB error 69.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 07, 2021, 07:14:42 pm
content: Ok, so not much progress on the 4052 and 4054.I tried to do a little work on the MARK function today and got so far and the ran into a problem. Seems I can't create a new file on the SD for some reason.... If I can get this function done then I will have the elements for deleting, renaming and creating files that might be needed for other functions such as KILL and SAVE.I am scratching my head as to what else to do with INPUT.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 07, 2021, 10:03:26 pm
content: I found a weird section of code in GPIBdevice.cpp for GPIBbus_SEND// Otherwise ignore non-escaped CR, LF and ESCif ((databuffer!= CR) || (databuffer!= LF) || (databuffer!= ESC)) err = writeByte(databuffer, false);I don't know why we would be checking on LF or ESC characters on SEND of ASCII data, and we don't want to check for them on binary transfers.CR is the terminator for ALL ASCII transfers - PRINT or INPUT.LF characters ARE in ASCII programs AND ASCII data files and are legitimate control characters.I don't know that is a problem - but I do see some debug statements with partial strings - I don't know that the above statement is a problem, but I don't understand the logic.Monty

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 08, 2021, 08:54:59 am
content: It about handling terminators and the escape character when sending text vs binary. Line terminators can vary with the settings of various terminal applications and the OS being used, but the interface wants to send the terminator set by the ++eos command. By default that's CRLF, but can also be set to CR, LF or none. So line terminators are stripped and the configured terminator is sent instead. With the emulator, I have set EOS by default to 1 so that it always sends CR only as the line terminator.When sending text, we also don't want to inadvertently send ESC characters. In addition, '+' has a special meaning so ESC, CR, LF and '+' can all be 'escaped' so that when sending binary (i.e. when using EOI as the terminator), their byte equivalents can be included in the data.I believe I have completed the MARK command so new files can now be added. It should now be straightforward enough to add KILL and SAVE so that new files can be created and programs saved.I will come back to INPUT, but I needed a bit of a diversion.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 08, 2021, 02:58:49 pm
content: I have just pushed up update 05.38. No progress on INPUT, but MARK and SAVE have been implemented and should be working. I will have a look at KILL next and then have another look at INPUT.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 08, 2021, 05:25:58 pm
content: I downloaded version 38 and tried MARK and SAVE which worked.But looking at your MARK code, I don't think the Tape Emulator should automatically find the LAST file.The way Tek BASIC works - you need to first find the file you want to use to MARK, then execute the MARK command which will start at that file that you did a FIND and MARK one or more new ones based on the number of files requested, then a new LAST file is created after the last MARKed file.You are warned in the documentation - that MARKing at an existing file will replace that file and you will also lose access to all subsequent files.Obviously an issue with our current Tape Emulator is the lack of TLIST command - so I had to know which file was the LAST file before testing your MARK command. Your code automatically started with the LAST file - but I still have no way of knowing what file(s) were created as Tek BASIC does not report that.My 'current hack' on TLIST was to manually create a list of the file headers in that folder - but if new files are MARKed or old files are KILLed - my 'hack' won't be current. It also involved changing file 1 in every folder to add the 'hack' to show the list of files in that folder.This code won't quite work on Tek BASIC - and will require a little bit of code in the menu program.I believe we should go back to secondary address 19 for the 'new' TLIST and use secondary address 9 for the change directory command which aligns with the published uses for secondary commands.I propose the 'new' TLIST would use the INPUT@5,19:A$ format and require PRI@5,9:"directory" command be the preceding command.To make this work with an INPUT command - the Tape Emulator would return one filename string in filenumber numeric order with each INPUT@5,19:A$ command.The 'TLIST' code in the menu program would print A$, then check character 8 for an "L", if not found, continue with another INPUT command.Example 'TLIST' program for Utilities: (tape emulator responses to each INPUT@5,19:A$ in 'code' section)610 PRINT@5,9:"UTILITIES"620 INPUT@5,19:A$630 PRINT A$640 IF SEG(A$,8,1)<>"L" THEN 620650 ENDCode:0 ASCII DATA [TLIST ] 31 ASCII PROG [Util Menu] 302 ASCII DATA [Advitm ] 103 BINARY DATA 294 ASCII PROGRAM SECRET 265 ASCII DATA [492Scope ] 186 BINARY DATA [4924 dupe] 337 ASCII PROG [Bubl Sort] 308 ASCII PROG  119 ASCII PROG  1410 ASCII PROG  1211 ASCII PROG [TLIST EXT] 1512 LAST 3We should be able to use part of my original ContinuedDev program TLIST which iterated through each filenumber in sequence - since the SdFAT order is not filename sequential.One advantage of this 19 command returning a single file header at a time - is it could also be used after a FIND command to return the header for THAT file.Maybe there is no need to restrict the prior command to an INPUT@5,19:A$ command? The filename (header) of the current file is a global variable in Tape Emulator.If the program intent is to do a TLIST - then perform the DIRECTORY COMMAND, then TLIST to get file 1 to the LAST file headers. If after the directory command there is no filename (NULL filename), then a subsequent TLIST would do a FIND 1 to get the header and subsequent additional TLIST would FIND incremental headers.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 08, 2021, 07:47:01 pm
content: Quote from: mmcgraw74 on September 08, 2021, 05:25:58 pmThank you for the confirmation.Quote from: mmcgraw74 on September 08, 2021, 05:25:58 pmOk, that is my mis-understanding. I though that the files were added to the end of the current list, but I can change it to start from the current file as determined by the preceding FIND command. That will be slightly more interesting as it may or may not need to rename LAST depending on the start point and the number of files requested.Quote from: mmcgraw74 on September 08, 2021, 05:25:58 pmYes, had the same problem while working on it but fortunately your original TLIST is available at the terminal from ++tlist. You can also ++cd directory and ++old to have a look at the file.Quote from: mmcgraw74 on September 08, 2021, 05:25:58 pmAgreed.Quote from: mmcgraw74 on September 08, 2021, 05:25:58 pmI think I follow all that but will re-read it again tomorrow when I am not so tired. Having read this I found that HEADER@5: as shown in the 4924 operators manual does nothing except show a syntax error so using PRINT@5,9 could be used to change directory as per the current CD function.On the other hand I discovered that LIST@5: tries execute the current CD command (19) and according to the BASIC reference is meant to list the program either a single line, complete or between the requested line numbers. I hadn't realised it was possible to list the program before using OLD. It doesn't seem to be supported on the 4924, but could be on the emulator if required. I suppose that might be useful for identifying the program. If we don't want to keep that functionality, then command 19 can be re-assigned to the new TLIST as you describe, otherwise we could use 8  (does nothing on the 4051 except generate a syntax error) so that the two commands are adjacent numerically or we did talk about using 31 which is undefined for TLIST before. Maybe we should try it - at least temporarily?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 08, 2021, 08:11:58 pm
content: The 4924 didn't support sec address 19 - so I think it is perfect for the TLIST. Particularly if someone with the Tape Emulator is trying to find how to TLIST - 19 should be what they try.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 09, 2021, 01:34:47 am
content: Ok, fair enough, but I also just had the thought that any process that alters the file names could also update the file 0? This would include MARK, SAVE where the file is changed from NEW to ASCII PROG and KILL.BTW, by what process are files changed to ASCII DATA or BINARY DATA? Is it when a NEW file is written to by INPUT or WRITE? What about BINARY PROG?

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 09, 2021, 02:28:36 am
content: Quote from: WaveyDipole on September 09, 2021, 01:34:47 amPage 2-16 in the 4050 Graphics System Reference (070-2056-01) shows two PRINT statements that are directed at the internal tape drive to allow the header to be accessed. In a later section they show an example program to modify the header to add comments.So, I think the answer is - Tek BASIC rewrites the internal AND external tape headers.There is a 4924 Tape Duplicator program on my repo:https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/blob/master/NICE_UTILITIES/6_4924%20Tape%20Duplicator.UNIYou can see the PRINT@x,0: and INPUT@x,0: commands that are setting and reading the 4924 Status respectively. They are changing the third byte of 4924 status to gain access to the 256 byte block with the Tape Header so they can rewrite it to make a copy of an entire tape including any comments in the headers.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 09, 2021, 11:39:04 am
content: I think I have misunderstood the purpose of the IO parameter after the LIST command. It seems that specifying a GPIB address sends the program listing to a specified device which I imagine could be a printer.I have got the KILL command working this morning and have moved the current CD command to secondary address 9. I have also got secondary address 19 sending consecutive filename entries when using INPUT@5,19:A$ as requested. The list rolls around to file 0 after it reaches LAST. After changing directory using PRINT@5,19:A$ the list will reset and start at the beginning of the new directory. I have also updated FIND to set the index to the current file so that when an INPUT@5,19:A$ is done immediately after a FIND, it will print the current file header.I have uploaded the updated code.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 09, 2021, 12:25:40 pm
content: Yes - I use LIST@40: to send the current program listing in memory to my Option 1 RS-232 serial interface connected to my PC.I will download and give your updated version of the Tape Emulator a try now

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 09, 2021, 12:59:31 pm
content: v39 CD(9) and new HEADER(19) commands worked fine!I put my A-Series Hilbert.uni (as ASCII PROG file 7) and my latest HilbertOrder6-sm.uni (as ASCII PROG file 5) programs in the Games folder.I was able to load and run file 5 on my 4052.However, I hung the Tape Emulator trying to load file 7 - as the 4052 cannot parse the new A-Series syntax.Here is the serial debug output for that:Code:gc_0x7B_h: received parameter: 7searchForFile: searching /GAMES/...searchForFile: found file 7searchForFile: done.stgc_0x7B_h: found: 7 ASCII PROG [HILBERT ] 3stgc_0x7B_h: type: PExecuting secondary address command: 64stgc_0x64_h: started OLD/APPEND handler...stgc_0x64_h: reading /GAMES/7 ASCII PROG [HILBERT ] 3...Tek BASIC stopped the program load and printed a syntax error message on the underscore on the _order variable in line 100.I pressed the CLEAR key and attempted to FIND@5:5, but the Tape Emulator was hung and had to be power cycled.I think the OLD command didn't handle the Tek attempt to end the command?

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 09, 2021, 04:55:51 pm
content: I tend to agree. It would have been still stuck in the send loop.I did an LA scan when pressing CLEAR on the 4051 and it did absolutely nothing on the GPIB bus. The thing is, if it gets stuck on syntax, then the Tek must send something to discontinue transmission. I will create a short program with a syntax error and capture what the Tek does. It is most likely holding NRFD and asserting ATN like for INPUT but I don't think I have implemented the necessary checks in OLD yet. We also talked about clearing on REN being asserted. I still need to have a look at that one as well.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 10, 2021, 01:08:07 am
content: I got the replacement transistor for my 4052 display board - installed it and now my 4052 is working again!I'm running the Hilbert curve program - to prove this is a new photoThe blue LED in the upper left corner is from my Tape Emulator board - plugged into a short GPIB cable, so it is easier to access.I have edited the menu programs on SD card and uploaded a new zip file to your Store.Delete the old files - I removed the "0" files from all folders and edited the menu programs to support the new CD(9) and TLIST/HEADER(19) commands.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 10, 2021, 10:40:26 am
content: Good to hear that you 4052 is up and running again!I have downloaded your new ZIP (v6) containing the SD card programs.I also ran your modifier Hibert program. It loaded much quicker and shows 19kb of memory available when the program is loaded. I couldn't list the program as the after line xxx I got an error telling me the line was too long, however the program ran and drew the matrix.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 10, 2021, 12:34:58 pm
content: Quote from: WaveyDipole on September 10, 2021, 10:40:26 amYes - I picked 64 bytes for the DATA statements which makes them 73 characters long including the CRI also had to remove the space between the line number and DAT and the space between the DAT and first quote.Since OLD parses the statement and tokenizes the command - it didn't complain.I'm not surprised that LIST complains as the ASCII statement is 73 characters including the CR.I was hoping this technique of converting to characters would get enough room to store an Order 7 Hilbert - but that is 4x the number of vectors - so no way it would fit in a 4051. Someone would have to write a routine that did not require recursive calls so the 4051 would have a 'real' program to do any size Hilbert curve.I also got a reply on my Hilbert post in vcfed saying Sierpenski triangles are also space filling curves. However all the programs I saw were for bitmap drawing - not vectors. I was looking at drawing vector triangles - but you need to fill the interiors to look right and that is a bit of code I haven't done.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 10, 2021, 12:41:31 pm
content: With my 4052 working again - we need to figure out why the INPUT command doesn't work reliably on the 4052.The 4054A shows an additional issue - the BASIC INIT command in almost every program hangs the computer AND the Tape EmulatorWhen this happens - I have to power cycle both the Tek and the Tape Emulator.I suspect the 4054A 9914 IC and BASIC ROM are changing the REN state during the INIT and the Tape Emulator doesn't respond correctly - but that will take getting a trace to see exactly what is happening on the GPIB bus.The 4054A also has same problem with the Adventure INPUT statements as the 4052.It also has a problem with the CD(old 19 or new 9) command in the folder menu programs - it gives error 69 most of the time.If I RUN at that line number (like I do for the INPUT command hangs) it typically completes that command and continues.Both 4052 and 4054A will complete the menu program TLIST (after the CD is repeated on the 4054A).

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 10, 2021, 10:23:59 pm
content: I did a handful of LA captures with and without INIT in the first line of a short program. The REN line is asserted as soon as the BASIC program starts running in both cases. Without INIT, NRFD and NDAC both get asserted for 4ms just before REN ends after the program terminates. With INIT, the IFC signal is asserted for approximately 250uS in addition to REN and simultaneously NRFD and NDAC are asserted for as long as the program runs.I think the relevant signal is IFC (Interface Clear) and the emulator needs to clear GPIB and reset to idle whenever an IFC signal is detected. This means that the IFC signal will need to be detected during any read or write loop.Quote from: mmcgraw74 on September 10, 2021, 12:41:31 pmI have been looking at your traces in post 262, but I believe that would like to see a trace of CD using v39 that when you have time please.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 11, 2021, 06:40:48 pm
content: Some of my problems with input are still around timing - but I now have Adventure working on my 4052!I found some Commodore 64 characters with ASCII values above 127 in my data files - I posted the new SD card image 7 on Store.I also moved the Adventure main program to file 1 - and changed all the menu programs to load that file.I created new files 51,52 and 53 which should be able to create and verify all the data files - but I guess we don't have PRINT to file working yet? I can't save my Adventure game, although there was no GPIB error. When I tried to LOAD that file - BASIC was hung on the first INPUT. I put NEW files with those filenames in the Adventure directory for the save games.After my data file changes - the number of times INPUT fails is reduced considerably on my 4052. But my Adventure program currently has long delay loops of 100 between each INPUT command from a file.please try my data file creation programs on your 4051 after you get PRINT to file to work.Otherwise just try file 53 - which I have changed to bypass file creation and just do the verify of the current files.On my 4052 - it verifies the file 2 against data statements in the program but always fails on file 3.In the meantime - here is a photo of running my port of Adventure in BASIC on my 4052 from the Tape Emulator. This time Adventure loaded without INPUT errors. I'd say one out of three times - huge improvement. Second photo shows a collection of treasures.I still have some minor display problem - some of the characters are misaligned - I suspect maybe a bad voltage on the display board (leaky capacitor?). It doesn't keep me from using the 4052 to test.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 12, 2021, 02:08:12 pm
content: Quote from: mmcgraw74 on September 11, 2021, 06:40:48 pmThat's good news!. I just tried to run your program file no. 53 in "Adventure" as suggested. Unfortunately it didn't run but that seems to be down to memory (or rather shortage of it). I got the following:Code:MEMORY IS FULL IN LINE 16 - MESSAGE NUMBER 39I ran MEM and it returned 308. That seemed odd considering the file is 21kb long so I deleted the program from memory and MEM returned 30699. I then loaded up file 53 again and MEM returned 8963. After another RUN attempt I got the same as above. There is evidently insufficient space to DIM the variables in that statement.I then tried file 51 which did run and created files 0-9 but stopped on file 10. The output is shown in the photo. Yes, the PRINT command is present on the emulator. It was added in version 05.34. At present it writes to files marked 'DATA' but this will require amending to further distinguish between files of type ASCII DATA and type BINARY DATA.Support has also been added for CALL "BSAVE" and CALL "BOLD" which require the Binary Program Loader cartridge on the 4051. The command CALL "BSAVE" writes to files of type type NEW or BINARY PROGRAM. In the same way that SAVEing to NEW renames the file to ASCII PROG, BSAVE renames a NEW file to BINARY PROG. The counterpart, CALL "BOLD" reads from type BINARY PROGRAM.Detection of IFC to clear the interface to idle state has also been added.I am holding fire on uploading it until I have had the chance to fully analyse the information in your latest post and LA traces. Thank you for the providing the details.SRQ - this seems very odd. I am now using the same adapter board and SRQ goes HIGH on mine and stays HIGH on all the traces. When you read the LA trace was anything else connected? BTW, the layout I created uses direct writing to Arduino ports to change pin states but doesn't use interrupts.Thank you for providing the traces and details of your captures. I have uploaded 0.05.40 so you can test whether the IFC handling works and helps at all. Once I have more fully analysed the details in your post (e.g. the CD issue), there may be other amendments.Incidentally, adding CALL "BSAVE" and CALL "BOLD" was an interesting exercise as both commands use the same secondary address number 17 (0x71). It turns out that it is possible to support more than one command on a singe secondary address. In this case CALL "BSAVE" is a listen command and CALL "BOLD" is a talk command so it was just a matter of determining whether the command was asking the emulator to talk or listen and calling the appropriate function. I imagine that CALL "BAPPEN", which also uses the same secondary address, can further be added because it adds line number parameters so on detecting those, the emulator would modify the behaviour of the function that responds to BOLD. We then end up with 3 commands on the same secondary address.Well, it occurred to me that a similar approach could be applied to the CD command. Currently PRINT@5,9:"directory" sets the working directory. I could be set up so that INPUT@5,9:A$ also reads back the current directory name.Another idea that ocurred to me was to have the PRINT command produce output on the terminal screen. In the same way that you can send a listing to a printer, you could sent it to the PC screen or over serial to somewhere...

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 12, 2021, 03:20:26 pm
content: Quote from: WaveyDipole on September 12, 2021, 02:08:12 pmYou should be able to change all three MAKE programs to remove the DIM statement and use plain variables to reduce the memory footprint. No need to keep the entire arrays in memory.On the SRQ subject - maybe the 4051 automatically enables the SRQ interrupt. The 4052 and 4054A may disable the SRQ by default and only enable it if the program uses an ON SRQ statement with interrupt handler code.Hmm - I tried a short SRQ test program on my 4054A with10 RETURN100 ON SRQ THEN 10I see a lot of noise on the SRQ line with the LA. Maybe the 644 can't drive that line hard enough?I don't have any other equipment connected to GPIB - just a short HP GPIB cable to the LA - and the Tape Emulator plugged directly into the 4054 on top of the GPIB cable.I'll check out your new version now.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 12, 2021, 05:18:13 pm
content: I tried your new version on my 4054A - no difference.Typing INIT hangs the 4054A and Tape Emulator.Running Adventure, the LA Waveform looks different than on v39 - but BASIC stops at line 171 with J=3 like before.I also attached a zip of the trace listing

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 12, 2021, 11:42:12 pm
content: I took some time with EXCEL to edit the trace.I figured out how to compute absolute time and added that column.Also added column that inverted the GPIB data.And added an ASCII decoded column with blanks for data invalid. I used /DAV & /NDAC & /NFRD to enable the ASCII output text.Then I manually edited in the UNTalk, UNListen, PRI 5 Talk or Listen, FIND and INPUT commands.I also found the technique to get Notepad++ to freeze the heading lines of the trace:Clone the trace to Other ViewRight click the divider bar and rotate leftAdjust the divider bar to show the header lines at the topScroll the bottom view and the header lines are always visibleHope this helps.ADVHANG2edited.zip(5 kB - downloaded 45 times.)

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 13, 2021, 11:26:50 am
content: Quote from: mmcgraw74 on September 12, 2021, 05:18:13 pmLooking at the LA output it seems that the emulator is going to idle, however I did omit something. There was a flag that should have been reset. Theoretically it should not have made a difference since the next MTA or MLA received ought to indicate whether the emulator should talk or listen but ideally the flag should have been cleared. I have now amended the code to clear that flag.Thank you for the updated LA output. I just had a look and realised that there is something a bit odd going on. Here is the first few entries:Code:Label >Time usec Time msec DATA DATA ASCII ATN NDAC NFRD EOI DAV REN IFCBase > Relative Absolute Hex Hex Bin Bina Bina Bin Bin Bin Bin__________ _______ ________ ____ ___ ____ ___ ____ ____ ___ ___ ___ ___-4 505.4 0.505 82 7D 0 0 1 1 1 0 0-3 8 0.505 00 FF 0 0 1 1 1 0 0-2 40 0.505 20 DF 0 0 1 1 1 0 0-1 8 0.505 A0 5F 0 0 1 1 1 0 00 2.008 0.507 A0 5F 0 0 1 1 0 0 01 78.74 0.586 A0 5F UNT 0 0 0 1 0 0 02 11.45 0.598 A0 5F 0 1 0 1 0 0 03 104 0.598 A0 5F 0 1 0 1 1 0 04 23.35 0.621 A0 5F 0 0 0 1 1 0 05 30.46 0.652 A0 5F 0 0 1 1 1 0 06 245.1 0.897 00 FF 0 0 1 1 1 0 07 40 0.897 58 A7 0 0 1 1 1 0 08 8 0.897 DA 25 0 0 1 1 1 0 09 2.176 0.899 DA 25 0 0 1 1 0 0 010 111.9 1.011 DA 25 PRI 5 L 0 0 0 1 0 0 011 11.44 1.022 DA 25 0 1 0 1 0 0 012 104 1.022 DA 25 0 1 0 1 1 0 013 23.36 1.046 DA 25 0 0 0 1 1 0 014 29.90 1.076 DA 25 0 0 1 1 1 0 015 214.5 1.290 CA 35 0 0 1 1 1 0 016 8 1.290 00 FF 0 0 1 1 1 0 017 48 1.290 80 7F 0 0 1 1 1 0 018 8 1.290 84 7B 0 0 1 1 1 0 019 2.048 1.292 84 7B 0 0 1 1 0 0 020 38.56 1.331 84 7B FIND 0 0 0 1 0 0 021 11.44 1.342 84 7B 0 1 0 1 0 0 022 104 1.342 84 7B 0 1 0 1 1 0 023 23.36 1.366 84 7B 0 0 0 1 1 0 024 30.58 1.396 84 7B 0 0 1 1 1 0 025 284.6 1.681 84 7B 1 0 1 1 1 0 026 80.70 1.762 84 7B 1 0 0 1 1 0 027 385.1 2.147 80 7F 1 0 0 1 1 0 028 8 2.147 00 FF 1 0 0 1 1 0 029 40 2.147 DF 20 1 0 0 1 1 0 130 40 2.147 FF 00 1 0 0 1 1 0 131 8 2.147 FF 00 1 0 0 1 1 0 132 8 2.147 DF 20 1 0 0 1 1 0 133 18.00 20.147 DF 20 1 0 1 1 1 0 134 136 20.147 DF 20 1 0 1 1 0 0 135 23.64 20.171 DF 20 1 0 0 1 0 0 136 11.44 20.182 DF 20 1 1 0 1 0 0 137 104 20.182 DF 20 1 1 0 1 1 0 138 31.11 20.213 DF 20 1 0 0 1 1 0 139 188.4 20.402 DF 20 1 0 1 1 1 0 140 75.22 20.477 D7 28 1 0 1 1 1 0 141 8 20.477 00 FF 1 0 1 1 1 1 042 8 20.477 00 FF 1 0 1 1 1 0 043 40 20.477 80 7F 1 0 1 1 1 0 044 8 20.477 CD 32 1 0 1 1 1 0 145 24 20.477 CF 30 1 0 1 1 1 0 146 8 20.477 FF 00 1 0 1 1 1 1 147 8 20.477 DF 20 1 0 1 1 1 1 148 8 20.477 CD 32 1 0 1 1 1 1 149 8 20.477 CD 32 1 0 1 1 1 0 150 8 20.477 CD 32 1 0 1 1 1 0 151 1.120 20.478 CD 32 1 0 1 1 0 0 152 68.59 20.547 CD 32 2 1 0 0 1 0 0 153 11.44 20.558 CD 32 1 1 0 1 0 0 154 104 20.558 CD 32 1 1 0 1 1 0 155 8.176 20.566 CD 32 1 1 0 0 1 0 156 8 20.566 80 7F 1 1 0 0 1 0 057 8 20.566 00 FF 1 1 0 0 1 0 058 40 20.566 70 8F 1 1 0 0 1 0 059 8 20.566 F2 0D 1 1 0 0 1 0 060 24 20.566 FB 04 1 1 0 0 1 0 161 8 20.566 FF 00 1 1 0 0 1 1 162 8 20.566 FF 00 1 1 0 1 1 1 1IFC is LOW (asserted) butat the same timeso is ATN and commands are being sent: UNT, PRI 5, FIND. After this ATN goes HIGH and the parameter 2 is sent. IFC goes HIGH but is asserted briefly before and after the 2 is sent as if the Tek is still trying to force the emulator to clear. It doesn't seem to make sense for commands or data to be transmitted while IFC is still asserted. However, the emulator is responding to ATN being asserted by the TEK by going to attention and subsequently a series of commands is being transmitted while IFC is still asserted. I have therefore added a statement into the main loop to prevents the emulator from going to attention while IFC is still asserted. The emulator will wait for a short while and try again on the next iteration of the loop. If IFC is now de-asserted, it will go to attention, otherwise it will wait another period until IFC is de-asserted.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 13, 2021, 12:45:12 pm
content: Here are the original 4054 GPIB schematic and the 4054A GPIB schematic from one of the two 4054/4054A latest service manuals.And links to both the 4054/4054A version 3 service manuals:http://dvq.com/tektronix/Tek_070-2840-03_4052-4054A_technical_data.pdfhttp://dvq.com/tektronix/Tek_070-2839-03_4054-4054A_parts_and_schematics.pdfThe Technical Data only described the 4054 GPIB and mentioned that the 4054A used a 9914A IC.Here is a link to the TI 9914A GPIB Controller manual:http://www.bitsavers.org/components/ti/TMS9900/TMS9914A_General_Purpose_Interface_Bus_Controller_Data_Manual_Dec82.pdfI will download and try your new amendment to the emulator.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 13, 2021, 12:53:05 pm
content: Thank you. I didn't have those.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 13, 2021, 12:55:56 pm
content: Something is odd about my edited trace - the REN and IFC values don't look like the waveformI am making progress on getting the HP GPIB Preprocessor connected to the logic analyzer - I found a document describing how to get the GPIB inverse assembler loaded without errors. I plan to connect it to the 4054A today and see if the GPIB Preprocessor and GPIB inverse assembler output works.Hopefully it will fully decode the states so we don't have to manually examine/edit the listings.It should also provide the GPIB waveforms.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 13, 2021, 05:18:45 pm
content: No worries. I will wait for your revised data. The amendment to the flag value needed to be done anyway.Hope the pre-processor works out OK. That will no doubt be useful once working. We can have another look at the IFC signal once a new listing has been generated.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 13, 2021, 06:56:45 pm
content: I managed to get a bit further with Adventure program file 51. There is a slight bug in the code which was causing blank lines to be added to the data file:Code:151 C$=CHR(13)...578 PRINT@5:Z$;C$I am uncertain as to the reason for adding a CR to the BASIC PRINT statement, but since PRINT already terminates any string with a CR, adding another one was causing data elements to be placed on every other line in the file instead of consecutive lines. Consequently the first line passed verification but when the loop read line 2, it was comparing the second DATA element with a blank line in the file and so the verify failed. Simply changing this to:Code:578 PRINT@5:Z$creates the with data on consecutive lines and verify then works. However, I did run into a problem. After the second file was verified I got:Code:GP INTERFACE BUS I/O ERROR IN LINE 622 - MESSAGE NUMBER 69Curiously the fail seems quite consistent in that it always fails on file 12 but it does seem like the sort of thing your are getting on your 4052 and 4054? I have done a capture on the LA and will have a closer look tomorrow.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 13, 2021, 08:46:56 pm
content: Hmm, when I wrote the three Adventure MAKE programs, it looked like the emulator was not putting CR after each string - so I added the CR to each string before the print statement. Then I manually verified each data file with Notepad++ and then jumped around the file create to the file verify.Right now I'm having trouble getting the Inverse Assembler traces or waveforms to make any sense.Possibly the HP 10342B GPIB Preprocessor has some bad ICs. I can't find the schematic or service manual for it on the web.I'm thinking it would only be helpful if the data bytes weren't correct - I don't think that is our issue with the tape emulator.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 13, 2021, 08:54:53 pm
content: Quote from: WaveyDipole on September 13, 2021, 06:56:45 pmYes - that is the type error I've been seeing on my 4052. It seems like DATA files with numbers don't have this error, but the files with strings do. Maybe the files with strings are much longer - or maybe the characters are sent faster than the numbers. Tek BASIC encodes all numbers in DATA statements in binary and has to convert them to decimal ASCII in PRINT statements, where character strings in DATA statements are not in binary and are sent without modification in PRINT statements.We should check the GPIB byte timing for string characters versus byte digits.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 14, 2021, 12:59:33 am
content: John, when I get that error, I simply RUN x where x is the line number reported with the error.That works to get my 4052 to get past those errors and start running Adventure.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 14, 2021, 01:22:52 pm
content: Ok - I spent time this morning to convert the 4054 ADVHANG trace listing into a spreadsheet.First I used Notepad++ column editor to insert commas between the columns to create a ADVHANG2a.CSV file.Then used Notepad++ to convert the ns / us / msec column into numbers 0.000000001, 0.000001, and 0.001 for time calculations.I imported that file into EXCEL and added some columns for time and ASCII data calculations.1-calculated absolute time (msec) from the relative time added to the previous absolute time2-uninverted the GPIB Hex DATA and printed ASCII on valid data using /DAV & /NDAC & /NRFD calculation as the qualifier3-edited the ASCII data column for PRI talk or listen address, FIND or INPUT on secondary address, UNTALK, UNLISTEN and CR.I've attached a zip with the CSX,XLSX and PDF print files.ADVHANG2a.zip(174.47 kB - downloaded 60 times.)And here is page 1 of the resulting PDF file:I found one omission in my ASCII data edits - on line "Label 35" after the FIND secondary address command, there is a SPACE character prior to the filenumber 2 on line "Label 52", since Tek BASIC prefaces printed numbers with space.There are no spaces on the numbers in the INPUT commands - as these files were created by printing STRING data statements and there were no spaces in front of the numbers in the DATA statements.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 14, 2021, 01:46:48 pm
content: I'm going back to my direct capture of any more traces.The GPIB PreProcessor output will only provide STATE info, and somehow my configuration is not providing the correct bits in the correct order.I do have the GPIB inverse assembler source file - but I would have to learn the IA language to understand what it is doing, and I don't think we need it right now.I do wonder - since lots of INPUT commands work but sometimes they fail - whether this may be a hardware issue as my board does not have the GPIB drivers, but is directly driving with the Arduino Mega 644 IC.I will try running the Tape Emulator directly plugged into my 4052 and 4054A without any other GPIB cables.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 14, 2021, 02:29:08 pm
content: My experiments on my 4052 and 4054A plugged directly in with power from a phone charger did not have any difference in behavior.Still got GPIB errors in random locations loading the files into Adventure.We still could have a hardware issue with the direct drive from the Mega 644, or it could be software.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 14, 2021, 07:16:25 pm
content: I spent considerable time on this error 69 issue today and I think that I have may have discovered what might be main cause of the dropouts. There were a couple of minor bugs to fix along the way, but the primary cause appears to have something to do with the use of the Arduino millis() function in the timing loop. I don't know exactly what the problem is with millis(), but having tried another approach to using it per an Arduino example, resulted in the same error 69 problems occurring. Eventually when I amended the timing function in question (waitOnPinState) to remove millis() and implement the delay using a different (and perhaps less precise) method, this seemed to solve the problem. The 4051 could now successfully run the complete program 51 all the way to the end of the verification process. I also tried and was able to successfully run program 52. Reverting back to using millis() breaks it again.It should be noted that both programs required minor modification in order to run:Both programs (as previously mentioned):578 PRINT@5:Z$Program 52:583 IF I=15 THEN 585584 GO TO 570Line 583 was essentially missing from program 52 so it tried to continue with the loop and stopped with a DIM subscript error. I haven't done anything further with program 53 yet.I have uploaded an updated version (0.05.42). I am eager to see whether it passes the 4052 and 4054 test!(BTW, the zereos at the end of the first output are down to me accidentally leaning on the key!)

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 14, 2021, 10:02:51 pm
content: Great progress on the 4051 running the Tape Emulator with your v42.I first tried v42 on my 4052. No joy. The 4052 will not run Adventure any more. Most times it hangs with the I/O light on - I can stop the program with double-BREAK, but can't resume with RUN and the line number of the error. I get a new error "INVALID COMMAND ARGUMENT IN LINE 190 - MESSAGE NUMBER 19" for example. This line has a NEXT J statement. J was 28 when I pressed BREAK twice. It is always hanging on this section of code at random J loop counts.I have been watching the LEDs on the Tape Emulator plugged into a GPIB cable like an extender so the Tape Emulator is hanging to the right of the screen. The GREEN LED flashes when the Tape Emulator is accessing the micro SD card. If the GREEN LED stops flashing and the 4052 I/O Lamp is ON - the program is hung.Next I tried v42 on my 4054A and it made a considerable improvement! I can now load and run Adventure with no errors reported 4 out of 5 times - I couldn't run Adventure on my 4054A before. I still get an occasional error 69 during the program initialization (Welcome to Adventure! is being printed), but I and can continue with RUN of that line number.One difference on the 4054A running Adventure - I now get occasional error 69 when accessing a new location. I never saw this on the 4052 after the program was initialized and was playing the game.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 15, 2021, 12:18:10 am
content: Great NEWS! Tape Emulator is now working on my 4052 AND 4054A!!I got to thinking about the Tape Emulator Green LED on the board - it isn't anything to do with the micro SD card - it is connected to the serial TX pin!I disabled the setup section that initializes the Comm port and Debug port.Then I uploaded my modified v42 to the Tape Emulator and the weird problems are GONE on both 4052 and 4054!!I think we can now work on the remaining tape functions!I ran Adventure on both 4052 and 4054A with no issues.I then tried to run the SysTape programs - and the Y Plot worked but the other selections reported no program found.I checked that folder and the filenames for files 10 and higher were not formatted correctly so the emulator could not detect the file type.I also had to mod my v42 to increase the number of files to 110 - as there are 106 files in the System Tape.I corrected the filenames on those files and tried the 4054 Special Functions on my 4054A and the program indicated it only worked on a 4054.I checked that file (103) and the test for the 4054 did not support the 4054A - so I added that test and here is a screenshot of one of the features only in the 4054 and 4054A computers - dashed lines:I have uploaded a new micro SD image zip to your repoIt's Miller Time!

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 15, 2021, 11:23:46 pm
content: I was trying to fix some of the SysTape files and then started with the first file and compared to the original tape dump and fixed all the files.I recommend you try to run SysTape (ROOT menu selection) - I still have some things that aren't working.I also 'ported' COLOSSAL16 to the tape emulator, added it to the games menu and added a file 9 in that folder to use for save games.My 4052 is not writing CRs after each PRINT to the save game file - not sure why, but it hangs on trying to LOAD file 9 because there are only two CRs in the whole file.I ported COLOSSAL16 from a Commodore game - it is similar to Adventure and works on the 4051 emulator, should work on your 4051 (including SAVE and LOAD - use file 9).I just uploaded the new SD image to your repo with all the changes above.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 16, 2021, 05:00:44 pm
content: I believe I found the remaining bugs in the SysTape files - I posted a zip of the fixed SysTape on your repo.I would like to know how it runs on your 4051.My next step is to begin building the 'real' SD image folders - porting the programs to use the Tape Emulator for file access, and adding folder menu programs if not already in that tape.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 16, 2021, 07:02:31 pm
content: I have just pulled v9 of the Tek4924sd archive and copied it to my SD card. Program 1 from the SysTape directory ran fine and from the menu I was able to choose all the types of graphs, enter data and produce a plot. I then ran the tutorial although only for a short while so it was not an in depth test, but it did show me at least a couple of plot examples. I also tried the Firmware Verification Program (4051 only) - option 7. This sat for a few minutes with BUSY and IO on but it didn't return to either the cursor or the error. Perhaps it just takes rather more that 'bout a minute' when you have a full compliment of 32k of RAM? I aborted after about 5 mins but will have another go tomorrow and leave it running for longer to see what happens.After Tuesday's effort I had to have a break on Wednesday, but I did manage to do a little bit of work on the 4051 Emulator. There is still quite a bit to do before I have a working importer for the 4924 emulator directory structure.This morning I made a start on modifying the MARK function as discussed but I didn't have a lot of time as I had to go out in the morning and had a medical appointment later in the day, so I didn't get to complete it. Hopefully I can get that done in the next couple of days. I am also putting together a synopsis of the currently working commands.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 16, 2021, 08:17:28 pm
content: Quote from: WaveyDipole on September 16, 2021, 07:02:31 pmThat program doesn't return to BASIC - if no error is reported, your 4051 passed the test. You have to power cycle your 4051.QuoteSounds good.I don't think we need to work on READ or WRITE - as I have to modify all the SD card programs to support the @5 GPIB address, I can replace READ with PRINT and WRITE with INPUT as they are equivalent - just take more file space and maybe are a little slower - which is not a problem for the SD card or performance.The internal tape is quite a bit slower than the Tape Emulator for file read/write and super slow for FINDing a file.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 20, 2021, 02:12:24 pm
content: QuoteThis is a comment I made in an older post on Sept 16 at 08:17:28pmTek BASIC EOF is 255 not 127 as I stated in that post.Reason to bring this up again - in running the 4050R12 Enhanced Graphics ROM demo tape picture files - file 9 which is the SIN(X)/X plot hangs every time on both the 4052 and 4054A. Since I disabled the debug output - I don't know what the last Arduino debug message was.I wonder if the emulator code is looking for character 127 as EOF? There is one near the end of that picture file. I wonder if this is what is stopping the loading of the picture file. All I have to do is run that program line again and the file load completes and the picture is displayed.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 20, 2021, 07:00:23 pm
content: I did pick up on the fact that EOF was hex 0xFF at some point from the manual but off the top of my head I am uncertain whether the emulator is looking for a 0x7F (127) anywhere so I will check the rest of the code and amend accordingly.I have been dealing with family matters and a bit of a saga with a replacement for my ailing tower PC (see PM) which is why I haven't been on for a few days, but hopefully tomorrow I can finish sorting out the MARK function and check this out.I am curious why turning off the debug messages is necessary. While it is true that processing them takes time, the GPIB handshaking protocol is designed to wait for the slowest device to catch up. There is a timeout parameter as a GPIB interface cannot wait indefinitely for a signal but I can't imagine the timeout period on the Tek 4054 or 4052 would be so short as to present a problem. I haven't seen anything about setting the GPIB timeout on the Tek, but if there is such an option somewhere it might be worth exploring and increasing the timeout period. I will have a dig into the manuals tomorrow to see whether I can find any information on this.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 20, 2021, 11:31:18 pm
content: I haven't seen any Tek setting for changing the GPIB timeout.I was thinking that if the serial output was blocking the Arduino from GPIB - that might cause the timeout.Printing 72 characters (11-bits with 8-bits plus Stop/Start/Parity) at 9600 baud is 80msec.The 4051 GPIB Hardware Supplement page 4-2 indicates: According to the IEEE Standard, each peripheral device on the bus must respond to ATN within 200nsec by setting NDAC low and NRFD either high or low (IEEE std page 93). The 4051, however, allows a peripheral device up to 45 usec to respond.The next page has this information on error message 69:After 45 μs, the 4051 releases NRFD and checks to see if NRFD and NDAC are not both high.If they are both high, the 4051 assumes that there is an error and the PRINT operation isaborted. The 4051 prints a GPIB interface error message on the screen (message 69). If NDACis low and NRFD is low, the 4051 waits for NRFD to go high before continuing with the addressoperation. If NDAC is low and NRFD is high, the 4051 assumes that all devices are ready toreceive the first peripheral address and the 4051 prepares to place the primary listen addresson the Data Bus.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 22, 2021, 12:49:39 pm
content: I haven't seen any such setting either, but yes, print operations take time. I have been careful to print messages after an action has taken placed and not during it. Occasionally I have put messages inside loops for test purposes but I generally avoid that. It wouldn't take too much time to break it down so that debug messages can be shown on a per-function basis. I have already done that to some extent, but all GPIB secondary commands are at present lumped into one group.Incidentally, I tend to run the serial port at 115,200 baud so delays might be reduced when compared to running at 9600 baud. I could try at 9600 and see whether it affects the 4051.I have now updated the MARK command and it will hopefully work as described. If not please let me know and I will adjust it further. I had a lot of distractions yesterday so apologies if I have missed anything. I have uploaded the code to the repository.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 22, 2021, 03:32:26 pm
content: Sorry, I am also using 115200 baud on serial debug.I have only encountered one issue running the tape emulator with debug enabled - and this issue is not at random locations in the loop running INPUT commands - and happens on both my 4052 and 4054A running the 4050R12 Enhances Graphics demo files, trying to load the selection 1 picture of (SIN X)/X which is file 9 in folder "GrpR12demo".The picture program is file 8, and the error occurs on line 575 INPUT @5:B$.The Y value is 16 every time.All I have to do is RUN 575 to get past this point and load the rest of the picture.B$ is dimensioned to 5000 in line 130.Each INPUT is CR terminated and I append the CR that Tek BASIC strips off back into B$ in line 576.Using HxD to examine the file 9 SIN XX and searching for all the HEX 0D, the sixteenth CR is at offset 156A, and the string being INPUT is only 363 bytes long as the previous 0D is at offset 13FF.The R12 Enhanced Graphics picture format is 3 7-bit characters for each 10-bit X/Y endpoint with one bit indicating MOVE or DRAW. They have a CALL "IMAGES" command which only accesses the internal tape to read the entire file up to the EOF (FF).In order to access the files on the tape emulator I figured out how to emulate that ROM call with the INPUT command, by reading the file until the CR terminates that input string, append the CR and concatenate all the strings.Looking at the original demo tape files - I did not see an FF for end of file on many of the files, so I added a CR to the end of the data and manually counted how many strings were in each picture and put that count in DATA statements in line 555 and READ that data into R array for the 13 picture files. I stop the INPUT loop when I have read all the data - which may be more than the true data size as the tape files are in multiples of 256 byte blocks. I then crop the data to the proper file length stored in DATA statements 556 and 557.I don't see any other tape emulator issue - than on this particular picture file.I have uploaded my latest image - now named TapeEM-full-1.The main menu works, along with SysTape, Games, Adventure, GraphingT1 - all of which should work on your 4051. Since you don't have the MAXIPACK yet, you can't run the R12 demo - but you should be able to create a simple program with the loop attempting to read SIN XX and see if your 4051 passes.I still think this is an INPUT command timing issue.I will download your latest code and try it. If I have the same issues as before, I will disable debug prints and see if that eliminates the random issues.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 22, 2021, 04:06:59 pm
content: I downloaded your latest image and tried the R12 demo.SINX/X picture 1 had error 69 on line 757 at Y=16.I did RUN 575 and now the program just hung (no error, but BUSY and I/O lamps on).Double BREAK - line 575, Y=24.RUN 575 - another hang, double-BREAK, line 575, Y=36.I gave up and commented out the debug print in setup, and changed the version string to 44a.Now 44a behaves like 42a - still stops at line 575 on SINX/X for Y=16.But after RUN 575 - the picture loads, displays and the demo progresses through all 13 pictures and back to the main menu without any other issue.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 23, 2021, 08:43:08 am
content: I made no changes to anything other than the MARK command so I wouldn't expect it to have made any difference to running the graphics demo just yet. However, I have downloaded TapeEM-full-1 and have started to look at the problem you describe. At this point I have some more questions, though not all are related to the demo:1. the MARK commandI did notice today that the MARK command is still not working as per description. I started MARK at the file immediately after file currently selected with FIND but re-reading your description it seems that it actually starts from and includes that currently selected file. I will need to make that adjustment.Then, I also noticed this statement in your previous post:Quote from: mmcgraw74 on September 08, 2021, 05:25:58 pmThis statement seems to suggest that MARK, as already noted, starts at the currently selected file and creates the number of requested files, overwriting the current file and adding further files until the number of requested NEW files has been is created. It then appends a LAST file and everything after that numerically is deleted? I find that really odd as a) there is a potential to inadvertently loose the currently selected file and b) there is no means to create or clear one or more files on a tape without deleting everything that comes after the current file so one could inadvertently loose an awful lot of files! KILL only works with one file so it would seem that if someone wants to clear multiple files and reset them to new within a group of existing files they would have to use KILL multiple times?I guess this is probably all related to the limitations of working with tape, but it does mean I will need to amend the MARK command again. Before I do though, I would like to just clarify that statement. Is my understanding above correct?2. Filename formatI notice that in the new TapeEM-full-1 archive you are using actual file sizes so I did a bit of work to update the functions that rename and create new files to append the size of the file in bytes to the end of the file name rather than the record size. I have followed the specification here where the file length is exactly 39 characters:https://github.com/mmcgraw74/Tektronix-4050-GPIB-Flash-Drive/blob/master/Tek-GPIB-Tape-Emulator%20command%20template.inoAs per specification, the file size field has six digits. By default, numbers are formatted as right justified and left padded with spaces which means the filename length will be slightly longer when compared with existing ones on TekSD/TapeEM, although the position of each field corresponds exactly with the existing file names and the specified format. I wanted to confirm whether the file size should be left or right justified? Right justified would yield filenames that are consistently 39 characters long. Otherwise the file name would vary in length depending on the number of digits in the file size, unless the file size field was padded with spaces. I had not observed and spaces at the end of the file names used so far. I am uncertain as to what was envisaged?3. The SINX/X picture fileI did have a bit of a look at the SINX/X picture file and program 8. I see they have been changed recently and the recent version is the one that corresponds with the discussion in your post. I can read a string with INPUT@5:A$ multiple times manually. I wrote a small program that read in a loop and did get it to run once all the way through but since then it seems to have consistently stuck at the 24th iteration which is a bit strange since in your experiment it consistently stuck on the 16th. So far I do not know the reason for this but will keep investigating.This is the listing of the simple program that I used:Code:10 PRINT@5,9:"GrpR12demo"11 FIND @5:913 LET B=015 FOR I=1 TO 12420 INPUT @5:A$22 PRINT I25 IF A$ <> "" THEN 6030 NEXT I40 PRINT "Iterations: ", I42 PRINT "Variables: ", B50 END60 B=B+170 GO TO 30Please forgive the haphazard numbering!

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 24, 2021, 08:35:37 am
content: I ran the program again this morning and to my surprise it ran all the way through to the end. I ran it a couple of times more to make sure and got the same result. Remembering your comments about having to turn debug messages off, it realised that since I was not connected to the emulator via serial, debug messages were effectively turned off. I then opened a terminal and connected to the emulator in via the serial port to observe the debug messages and ran the program and sure enough it stopped on iteration 24. I disconnected from the terminal and ran the program again and this time it ran all the way to the end. I also tried with debug messages turned off but with a terminal connected to the serial port. No messages were displayed and the program ran all the way to the end. The experiment seems to confirm your finding that turning on debug messages which adds the burden of the Arduino having to process numerous print actions can and does interfere with the process. Connecting to the serial port does not, of itself, appear to cause any problem.The next question is, when you were testing the SINX/X picture file using program 8, were debug messages turned on or off, and was a terminal connected to the serial port?For my part, I will check whether there is any debug message in particular that is causing problems.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: September 24, 2021, 11:51:26 am
content: Quote from: WaveyDipole on September 23, 2021, 08:43:08 amYes - that is the 4050 behavior on internal or external tapes.QuoteI thought the Tek BASIC would be consuming the file 'header' - but that is not the case. I get the filename info from my dumps of the tape files - others from my edits to the TLIST that I then uploaded (which then have filesize instead of #of blocks). I haven't found an issue with the SdFAT filename length being greater than the Tek BASIC header so far - but I'll make sure to test each folder before I upload a new image in the future.QuoteI see your new post of today.Yes - the only way I run now is with debug turned off.When running on my 4052 - the USB cable is connected to my PC with Arduino IDE opened but no serial console is opened.When running on my 4054A - the USB cable is only connected to a USB power cube.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: September 24, 2021, 02:43:49 pm
content: Quote from: mmcgraw74 on September 24, 2021, 11:51:26 amOk, I will adjust the MARK command to conform to that way of operating. Deleting the surplus files could prove to be interesting but we will see how it goes.Quote from: mmcgraw74 on September 24, 2021, 11:51:26 amIts not a big deal. Even at 39 characters, the filenames are still shorter than the Tek record which is 44 characters. Allowing for the last two which are CR and DC3, it actually has 42 characters of information. As long as the file size number is contained somewhere within character positions 34-39 it should still be read as a numeric string and converted to a numeric value with spaces being ignored. The appearance of a TLIST output does seem a little neater when the final number is right justified and the filename starts and ends in exactly the same position on each row.Quote from: mmcgraw74 on September 24, 2021, 11:51:26 amThank you for confirming that. With debugs turned off and nothing being sent to the serial port, just reading the variables in a loop worked OK on the 4051. Curious why program 8 evidently halts at exactly in the same place on both the 4052 and 4054. I can't test this any further really without a real world test using the MaxiROM cartridge so will have to park it for now until I obtain a MaxiROM myself. However, I will look at whether I can improve things.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: October 02, 2021, 03:21:15 pm
content: I just uploaded a new SD card image including the latest Games folder.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: October 03, 2021, 06:30:18 pm
content: Thank you. I have downloaded it and will have a look tomorrow.Now that I have almost finished building my new PC and moving everything across from the old PC tower, I am finally in a position to get back to so coding! Over the last couple of days I have re-written the MARK command to work as per the Tek. There were a couple of hurdles but it now seems to be working properly. I will post the updated code tomorrow after I have had a chance to clean it up a bit.I am also hoping to be able to order a MaxiROM soon. I had confirmation from Bob Haas that they are in. He has been away this week but hopefully they will be going up for sale on his return.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: October 03, 2021, 06:57:29 pm
content: Read my PM on this forum. The SD image isn't working right.Glad you got your PC sorted out.

author: WaveyDipole
author_rank: Frequent Contributor
timestamp: October 04, 2021, 11:03:37 am
content: I have now uploaded the next update which should have MARK working as it should be.

author: mmcgraw74
author_rank: Regular Contributor
timestamp: January 27, 2023, 03:35:34 pm
content: I never posted that we got the Tektronix 4050 computer GPIB Flash Drive working!See my github repository for more information and the latest firmware and Tektronix 4050 Flash Drive files:https://github.com/mmcgraw74/Tektronix-4051-4052-4054-Program-Files/tree/master/Flash_DriveYou can build my Tektronix 4050 GPIB Flash Drive yourself from my User Guide in the above repo, or send me a PM if you would like to order an assembled Flash Drive with MicroSD preprogrammed.Rememberthis Tektronix 4050 GPIB Flash Drive will ONLY work with the Tektronix 4051, 4052 or 4054vector graphics computers, since it uses GPIB secondary addresses for the commands.NOTE: GPIB secondary addresses are no longer in use to command GPIB devices, the commands are now sent using GPIB data bytes. See this other eevblog forum thread for the project that controls more modern GPIB devices:https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/