WaveyDipole
Experienced Member
Thank you for that helpful analysis!
It think this might explain a couple of things. For example, I found that using 'FF' as padding characters works, but using '00' or '20' generates a MAG TAPE ERROR. Without receiving an 'FF', the Tek would not have detected an end of the file condition which is probably why it displays the MAG TAPE ERROR. It probably also explains all of those '20' characters present at the end of the Option30 Demo files.
What is still unexplained is why there is no 'FF' at the end of either the data or the end of the last 256-byte segment in either the recovered Option30 Demo files or any files saved with BSAVE on the flash drive? Yet, as you explained, the spreadsheet data for BOLD shows that the 4924 sends an FF at the end of the data, but before the remaining part of the last 256-byte block.
I experimented with this in the JavaScript emulator. I first programmed it to send an FF at the end of a binary program file written on the flash drive and then padding with character 20 until the end of the 256-byte block. In effect this is faking what the 4924 does based on your findings. This worked and the file loaded without error. I then padded the file on disk with character 20. When running BOLD on this, the Tek loaded the file but produced a MAG TAPE ERROR. I then changed the byte immediately after the end of the data to an FF leaving the padding in place, again faking the 4924. That worked and the error was gone. Clearly that FF as shown in the screenshot is needed. So why, then, is it not present in the recovered files?
It seems that even without the FF, the Tek "knows" exactly where the program file ends and stops loading, although it would still not have received an FF which might be the reason for the error. I have added an FF byte to the end of the program data in the attached files. Could you check whether they load on the 4054 please? It might work with the updated version I posted yesterday but it might be better to try it with the earlier 0.05.77 version.
I will have a few things to sort today so I will come back to this a bit later, but your post has some interesting observations.
It think this might explain a couple of things. For example, I found that using 'FF' as padding characters works, but using '00' or '20' generates a MAG TAPE ERROR. Without receiving an 'FF', the Tek would not have detected an end of the file condition which is probably why it displays the MAG TAPE ERROR. It probably also explains all of those '20' characters present at the end of the Option30 Demo files.
What is still unexplained is why there is no 'FF' at the end of either the data or the end of the last 256-byte segment in either the recovered Option30 Demo files or any files saved with BSAVE on the flash drive? Yet, as you explained, the spreadsheet data for BOLD shows that the 4924 sends an FF at the end of the data, but before the remaining part of the last 256-byte block.
I experimented with this in the JavaScript emulator. I first programmed it to send an FF at the end of a binary program file written on the flash drive and then padding with character 20 until the end of the 256-byte block. In effect this is faking what the 4924 does based on your findings. This worked and the file loaded without error. I then padded the file on disk with character 20. When running BOLD on this, the Tek loaded the file but produced a MAG TAPE ERROR. I then changed the byte immediately after the end of the data to an FF leaving the padding in place, again faking the 4924. That worked and the error was gone. Clearly that FF as shown in the screenshot is needed. So why, then, is it not present in the recovered files?
It seems that even without the FF, the Tek "knows" exactly where the program file ends and stops loading, although it would still not have received an FF which might be the reason for the error. I have added an FF byte to the end of the program data in the attached files. Could you check whether they load on the 4054 please? It might work with the updated version I posted yesterday but it might be better to try it with the earlier 0.05.77 version.
I will have a few things to sort today so I will come back to this a bit later, but your post has some interesting observations.