Assembling a program on real TI hardware - interesting results

[+InsaneMultitasker]

forgot to ask... where was the file created and how did it get copied to the disk image.  One of the two bad files on the disk image seems to have an incorrect EOF marker in the File Descriptor Record, and is off by one byte.  I did not have time to inspect the other or look any further.

 

[wolhess]

Hi @InsaneMultitasker,

 

I changed the ROS to 814F and now I can assemble the four source files all with a 10 character name.

 

The config shows me a 2000K RAMDISK and a 6184K RAMBO RAM. Is this true? Or is the RAMBO RAM limited to 2000K?

In the newer ROS the cofig program shows always a RAMBO RAM of 2000K even I used the complete RAM for the RAM disks.

 

Then I tested the version with the coruppted file and it shows me the DSR ERROR.

I corrected the file and tried it again at then it assembles without any error.

 

It seems that my problem was two damaged source files and for the newer ROS the file name length more than 8 characters.

 

Thank You very much for your help.

 

Now I'm happy.

 

 

 

[wolhess]

14 minutes ago, InsaneMultitasker said:

forgot to ask... where was the file created and how did it get copied to the disk image.  One of the two bad files on the disk image seems to have an incorrect EOF marker in the File Descriptor Record, and is off by one byte.  I did not have time to inspect the other or look any further.

 

I made the disk image with Ti99Dir 7.2a 20200628 and copied the files from the tipi folder direct to the new created dsk image.

 

In the past I had some more file problems with Ti99Dir as I copied a lot of files for my BBS "MYTBOX99".

In those cases I used the tiimagetool from Michael Zapf (mizapf) and after loading the bad files with this tool it was corrected and working. 

[F.G. Kaal]

The first time I have seen extra data at the end of a file was at the time I was busy creating Dm2k (arround the year 2000 obviously). This allways happened when copying files from my SCSI drive to some other device. I found out that this has something to do with the number of allocation units (or clusters) reserved for a file on the drive and the number of allocation units (AU) the file actual occupies on the drive. When requesting the file information from the SCSI drive (level 2 call >24 "access direct input file") the SCSI DSR returned the number of sectors (= number of AU's x sectors per AU) reserved for the file and not the number of sectors the file data occupies on the drive.

 

For example: When copying a file from a floppy disk to SCSI the number of AU's reserved for the file is the same as the number of AU's needed for the file's data. When an edit session is started and the file grows in length some more AU's is needed. To prevent to much fragmenting of a file it is possible that more than just one AU is requested (at least that is what I do in the IDE DSR). Because an AU for a drive >16MB is more than 1 sector there is always more sectors reserved on a drive than needed for the file's data.

 

How to detect of a DSR of some device is ding it correctly:

i.e. Copy some DV80 files with various sizes from the device under test to a floppy using DM2K (Dm2k uses the level2 >x4 call) or some other copy program.

Copy the same files with a simple basic program record for record from the device under test to another floppy.

If the files lengths on both floppies are the same the DSR of the device under test is correct. If not then the DSR is doing it wrong.

 

In the FDR (File descriptor record):

 

Offset 14 "Number of sectors currently allocated" defines the number of sectors for the data of the file.

Offset 28 through 254 "Data chain pointer blocks" defines the total number of AU's reserved for this file on the disk. 1 AU is 1 or 2 or 4 or 8 or 16 sectors.

Offset 16 "End of file offset" belongs to the last sector of offset 14 and not the last sector of the last AU of the data chain pointer blocks.

 

Now what I'm trying to say with this story is that it depends where the source file is coming from and how good the DSR is or what program is used to copy the file.

 

[+FALCOR4]

3 hours ago, InsaneMultitasker said:

When I view the two protected files (from RDISK.DSK) using MENU/BOOT, there is problem with the file. I did not inspect the File Descriptor Record to determine the issue with the file but here is what I see as an example:  I'm guessing somewhere in the creation or transfer of these files, the EOF marker or record count has been corrupted.  Hard to tell which device may have caused it without further testing.

 

 

You and Fred understand this much better than I do.  I did play around with it some more this morning and am convinced it has nothing to do with the filename length (8+ chars) or the protection bit.  The fact that the E/A editor doesn't error out until the file is completely loaded should have been my clue that there may be an EOF issue.  The files seemed to have been corrupted somewhere along the line as you point out.

[+InsaneMultitasker]

The EOF byte in the FDR (which exists both on physical disk and in a TIFILES header) is incorrect in the corrupted files.  Its value is one greater than the actual end of the last record.   This suggests to me that one of the DSRs is at times calculating the offset incorrectly. 

 

And, unless I am mistaken, the pointer is wrong in the working files as well.  The most likely reason the COPY directive fails during assembly is that those files contain no END directive, so the assembler continues reading the file until the EOF is reached or in this case, an error is encountered.  

 

For example, here is RFILE1-S viewed in Disk Utilities.

 

And after correcting the EOF byte in the FDR (also present in a TIFILES header)  by -1, level 3 read finishes as expected.  I inspected two other files and their EOF pointer is incorrect as well.

 

The question here, as @F.G. Kaal points out in his post earlier, is determining where the problem is occurring.  Is it the TI Disk Controller, TIPI, or TI99Dir. (we might have ruled out ROS by nature of the earlier tests.)    Including @jedimatt42 for awareness.

 

[+InsaneMultitasker]

I have corrected all file FDRs -- every file had the same issue.  Try copying these files to your ramdisk and assembling. If this results in successful assembly, we can assume level 2 copies were successful and move on to level 3 record IO as follows:  load one of the two previously non-working source files from the ramdisk.  Save the file from the editor to the two devices:  TIPI and floppy.  Attach the newly created TIPI file here. Also copy the file from floppy to TIPI then attach here.  We can compare the resulting files.

 

 

RFILE-fixed.dsk

[wolhess]

14 hours ago, InsaneMultitasker said:

I have corrected all file FDRs -- every file had the same issue.  Try copying these files to your ramdisk and assembling. If this results in successful assembly, we can assume level 2 copies were successful and move on to level 3 record IO as follows:  load one of the two previously non-working source files from the ramdisk.  Save the file from the editor to the two devices:  TIPI and floppy.  Attach the newly created TIPI file here. Also copy the file from floppy to TIPI then attach here.  We can compare the resulting files.

 

 

RFILE-fixed.dsk 360 kB · 5 downloads

On the way to do this there were some errors:

 

First I worked with the fixed files from the disk image RFILE-fixed.dsk, see the following steps and the document with some screen shots.

1. I put the disk image RFILE-fixed.dsk to E:\ti99\TEST

2. I made a new folder on the tipi called TIPI.XB.DEV.FILETEST.ORIG and copied the files to this folder using Ti99Dir.

3. Then I converted the v9t9 files to tifiles using Ti99Dir.

4. With DM2K I copied the files to the HRD DSK9 and did nothing else.
5. I copied the files back to tipi in a different folder TIPI.XB.DEV.FILETEST.TIRDTI

6. Using the TI EA to assemble the source RFILE1-S9. (ASM1, ASM2 and EDIT are on physical drive DSK1.

    --> I could assemble the program without an error!

7. I tried to load RFILE1-S (not the S9 version) with EDIT but this doesn't work.
   --> I got * ERROR* and I/O ERROR CODE 7

8. Then I want to check if the RFILE1-S could be assembled, so I copied the files 99DSRLNK-S, 99SUB2-S and 99VDP4-S to my physical. DSK2.
    to make sure the EA finds the COPY source files.
   --> The EA could assemble the program without an ERROR

9. I tried again to load the main source file RFILE1-S but got the same error as in item 7.

10. So I used the EA V to load and edit and save the RFILE1-S file and this was working!

--> After editing the file with EA V the EOF offset in the file header was >47 and before it was >46.

In the pdf I made some screen shots.

FILE-COPY-HRD-TEST1.pdf

 

 

Second I worked with the bad files from the disk image RFILE.dsk

1.      Copied the disk image with the none working files from RFILE.dsk to E:\ti99\TEST

2.       Open the diskimage in TiDir and copied the files to TIPI.XB.DEV.FILETEST.RFNOW

3.      Using TiDir to converted the v9t9 files to tifiles

4.      Using Dm2k to copy the files to HRD DSK9.

5.      Using TI E/A to assemble the file RFILE1-S9 and check if the problem is there.
-> **DSR ERROR:02F4
     *  ERROR
     I/O ERROR CODE 0
The problem is there!

6.      Edit DSK9.RFILE1-9S from HRD with the editor of TI E/A 1981 does not work!
-> * ERROR *
     I/O ERROR CODE 7

7.      Edit DSK9.RFILE1-9S from HRD with editor of Fred Kaal’s EA V and save it to:
         TIPI.XB.DEV.FILETEST.RFEDIT.RFILE1T-9S

8.      Load DSK9.RFILE1-S9 from HRD with EA V and save it to DSK1.RFILE1F-S9
-> * ERROR *
I/O ERROR CODE 0

9.      Save it to HRD DSK9.RFILE1F-S9 is working!

10.   Load DSK9.RFILE1F-S9 from HRD with TI E/A 1981 works now, saved it to DSK1.RFILE1F-S9 does also work. So I saved it to DSK9.RFILE1FF-S

11.   Using Dm2k to copy the files from HRD DSK9.RFILE1F-S9 and Floppy DSK1.RFILE1FF-S to the tipi folder.

12.   Using Ti99Dir to make a new disk image RFILECPY.dsk and copied the following files to it:
RFILE1-S9          The original bad file that doesn’t assemble
RFILE1T-S9        The loaded and saved file to TIPI with EA V.  
RFILE1F-S9        The loaded and couldn’t save to floppy but save to HRD file with EA V
RFILE1FF-S        The saved file from EA V to HRD, load it again and saved it to floppy DSK1.

 

RFILECPY.dsk

 

On the HRD4000B I have the ROS 814F loaded, so the assembling with file names up to 10 characters is working.

 

 

If I should do any more testing, please let me know.

 

 

 

 

 

 

 

[+InsaneMultitasker]

Lot of good detail! For these steps, was step 6 completed with the RAMdisk? I cannot tell for sure because in step 5, you say you copied the files to TIPI. 

8 hours ago, wolhess said:

First I worked with the fixed files from the disk image RFILE-fixed.dsk, see the following steps and the document with some screen shots.

1. I put the disk image RFILE-fixed.dsk to E:\ti99\TEST

2. I made a new folder on the tipi called TIPI.XB.DEV.FILETEST.ORIG and copied the files to this folder using Ti99Dir.

3. Then I converted the v9t9 files to tifiles using Ti99Dir.

4. With DM2K I copied the files to the HRD DSK9 and did nothing else.
5. I copied the files back to tipi in a different folder TIPI.XB.DEV.FILETEST.TIRDTI

6. Using the TI EA to assemble the source RFILE1-S9. (ASM1, ASM2 and EDIT are on physical drive DSK1.

    --> I could assemble the program without an error!

 

[wolhess]

@InsaneMultitasker,

Yes, in step 6 I could complete the assembly without an error. In the pdf document you will see it in details.

 

 

[F.G. Kaal]

I will check the editor of EA V although it is still the same editor as supplied with the editor assembler module. The same file load and save functions are used. If the EOF marker is incremented by one then also the byte at the EOF offset of the last file sector must be checked, this must be >FF.

 

 

 

 

[+InsaneMultitasker]

RFILE1-S is incorrect on my fixed disk (edit:  even though the screenshots I took clearly show the file was  fixed!) so I may have compounded the errors.  I viewed every file before I saved the disk image and they all worked fine, but now some do not.  I might have saved my work to a different folder without knowing it?   I'll try to sort that out tonight.  The question still remains as to why the EOF offset is wrong in the first place, and what program or DSR is causing this situation. 

 

Edit:  I wonder if I had the disk image open with TI99Dir at the same time without realizing it, could that have caused the problem with my fixed image? 

[+InsaneMultitasker]

Completed some testing last night and shared results with another member to check my info. First step is to reduce the number of variables and possibilities to get to the root cause. 

[F.G. Kaal]

23 hours ago, F.G. Kaal said:

I will check the editor of EA V although it is still the same editor as supplied with the editor assembler module. The same file load and save functions are used. If the EOF marker is incremented by one then also the byte at the EOF offset of the last file sector must be checked, this must be >FF.

 

 

 

 

Now I think about this ... checking the/a editor for some EOF byte is a bit of nonsence. An editor relies on the DSR for its information. When loading a file it does an OPEN, enough READ's and a CLOSE. For saving a file it does an OPEN, enough WRITE's and a CLOSE. The same goes for the Dm2K program for copying files. It uses the Access-Direct_Input-File and a Access-Direct-Output-File function's without touching the content of the information. It is a DSR's responcebility to keep track of the offset of a record in a sector and place the end-of-record byte (>FF) at the correct location.

[+dhe]

FWIW - I had this exact same problem when I was playing with Fortran99, about ever other time, I'd open the source file for editing and I'd have to delete a bunch of garbage at the end of the file.... I wasn't doing anything crazy like running multiple copies of Classic99 or closing the application in the editor, and it wasn't always consistent. I don't blame Classic99 because Tursi has said many times, don't use disk images.... and that MAME is a fine option! ?