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 got CD, FIND and OLD all to work!
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 loaded
- CD "GAMES" (PRINT @5,19:"GAMES"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loaded
- CD "ROOT" (PRINT @5,19:"UTILITIES"), FIND @5:1, OLD @5: then I listed a couple of lines of the program that was loaded
All three successful.
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.
The READ command ONLY supports BINARY data, not ASCII data -
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'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):
(Attachment Link)
The READ command ONLY supports BINARY data, not ASCII data -
I got the same understanding from my perusal of the manuals. The ASCII code is probably superfluous in FIND.
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.
Correct. 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:
[header]value[header]string[header]string[header]value
Or whether one header would be required for the group:
[header]value|string|string|value
The 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 general, 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?
Yes, 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)?
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):
(Attachment Link)
Nice 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.
In 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.
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.In 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.
This 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 bytes
MARK 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?
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.
DATA 1,133488,1,6771679,2,36315,2,8849417,3,4673330,4
DATA 1641035,5,1987117,6,234943,6,387847,7,7400652,8
DATA 92813,8,249958,9,9462081,10,2517217,11,7523733,11
DATA 7763223,12,1512460,13,8969927,14,7412167,14,12721
DATA 15,9459313,15,1515430,16,10541692,16,9046363,17
DATA 10386,18,211942,18,5511277,19,197385,20,115990,21
DATA 1191644,22,53591,23,12562,23,405292,25,60879,26
DATA 5963048,27,38576,28,1305,29,10150041,29,7478239,30
DATA 8824300,31,7307409,32,41708,33,945573,35,9466352,36
DATA 2145145,37,8929575,38,2233302,39,5279045,41,6111523
DATA 42,7523588,100,14,100,6674000,101,369,102,5,102
DATA 89070,103,499,104,19,104,8960908,105,517,106,23
DATA 106,408142,107,387,108,21,108,562,109,4,109,81056
DATA 150,7536914,151,11425101,152,7533245,153,1289448,154
DATA 3516401,155,636,156,4191,157,35917,158,504325,158
DATA 8824505,158,8783307,200,2524729,200,291920,201
DATA 1697949,202,221453,203,248,203,2544612,204,5572845
DATA 204,10706,204,104358,205,4373864,205,9,206,10541692
DATA 207,221141,207,9851065,208,10386,209,8833780,210
DATA 221423,211,1236540,212,313242,212,347870,212,3748
DATA 213,8745885,214,1905,215,1588264,216,190310,217
DATA 274600,218,1592479,219,1126054,219,1929708,220
DATA 119741,221,405215,300,12716,301,111864,302,5646856
DATA 302,404,303,2720472,303,10302,304,4882,304,1402110
DATA 304,352487,305,82878,305,84854,306,9292709,307
DATA 822045,307,199744,308,108970,309,117759,309,8321691
DATA 310,405501,311,3426,312,2150731,313,319778,313
DATA 2707727,314,1233737
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. There is no specific SDfat call that I know of to read to the next delimiter so I think it will indeed need to read byte by byte and parse. Shouldn’t be too difficult though.
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.
The INPUT command. This causes the 4924 to transfer the
contents of its current file to the 4051 as a string of ASCII
characters. The 4051 stores the first "logical record" (the
characters up to the first CR character in the string) in the string
variable A$, which must be dimensioned large enough to accept
it.
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.
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.
I 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.
The 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 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.
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.
I wouldn't wait for the auction to end - I would make an offer - say 100 pounds before the auction is over.
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
AR488-Store ready (device).
++ver
AR488 GPIB storage, ver. 0.05.29, 13/07/2021
Executing secondary address command: 73
stgc_073_h: started CD handler...
OTstgc_0x73_h: received directory name: ROOT
stgc_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: 7B
stgc_0x7B_h: started FIND handler...
stgc_0x7B_h: received parameter: 2
stgc_0x7B_h: found: 2 ASCII DATA [DIR LIST] 4
stgc_0x7B_h: type: D
stgc_0x7B_h: done.
Executing secondary address command: 6D
stgc_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.
I then tried simpler experiment on the 4054A:
PRI @5,19:"ROOT"
FIND @5:2
INPUT@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.
Here is the debug serial console output - note CLOSE handler after first INPUT AND no second "started INPUT handler"