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?
The 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 [read] 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 output
In the meantime, I investigated a bit further and noticed that your function had a 'return' in the section starting:
if ((f_name[7] == '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:
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):
> ++mode 1
Interface mode set to: CONTROLLER
> ++addr 5
Set device primary address to: 5
> ++mta
GPIBbus::sendMTA: address device: 5
GPIBbus::sendMTA: cstate: 1
GPIBbus::sendMTA: cstate: 3
addressDevice: 5
> ++msa 115
> ++read eoi
1 ASCII PROG [Root Menu] 4
2 ASCII DATA [DIR LIST] 4
3 NEW 3
4 NEW 3
5 LAST 3
> ++unt
GPIBbus::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:
Executing secondary address command: 73
Started TLIST handler...
Reached last file.
End TLIST handler.
Home
Help
Search
Login
Register
