Corrupted Object files

[RXB]

Well I deleted Classic99 and imported from TiDir but the problem is GPL Assembler can not create files anymore.

 

https://www.youtube.com/watch?v=K9fY8xtc_Bw&feature=youtu.be

[Willsy]

Change the disk settings for each disk. On the top menu, click Disk --> DSK1 --> .\DSK1\

 

Alternatively, save your files with real extensions. E.g. In the editor assembler, save the object file as (example) MYFILE.OBJ - classic99 will recognise it as an object file and read it in as a DF80. You can do the same with text files (.TXT) - Classic99 will open .TXT files as DV80.

Edited July 14, 2014 by Willsy

[RXB]

Change the disk settings for each disk. On the top menu, click Disk --> DSK1 --> .\DSK1\

 

Alternatively, save your files with real extensions. E.g. In the editor assembler, save the object file as (example) MYFILE.OBJ - classic99 will recognise it as an object file and read it in as a DF80. You can do the same with text files (.TXT) - Classic99 will open .TXT files as DV80.

It is set that way already and in the demo Video I showed it was set that way.

 

I am not having a issue with Classic99 reading or saving files really the issue is when the GPL Assembler is compiling a file it switches

from COMPRESSED OBJECT CODE to UNCOMPRESSED in the middle of the file.

This is why the GPL*LOADER will not work properly.

 

In Win994A it is not doing this with same files, so something in Classic99 and Windows 7 is the problem. You can see from the video that the file is being corrupted when made.

 

I may be forced to reinstall Windows 7 as this all started when I started using MESS. And still can not get MESS to run correctly.

[RXB]

Well research shows that April is when the problems started and due to Microsoft.

 

Here is the lowdown:

 

http://itexpertvoice.com/home/fixing-the-windows-7-read-only-folder-blues/

[Tursi]

I watched your video, and I'll see if this is helpful, apparently you didn't read the manual....

 

"Corrupt DSK RAM" - this option (which should have been off) corrupts the VDP memory (and some scratchpad) that would be used by the TI disk controller after a disk operation in order to help find programs that rely on side effects from the TI disk controller. If it affected your program, it may be relying on side effects. It does not affect your disk files directly in any way, it just scrambles memory that should be consider scrambled (some would add only in my opinion) on a real TI system (although randomly) for the sake of development. Leave it off unless you're using it (although having it on will not affect most programs, and programs that fail should likely fail on Classic99 either way).

 

At 0:56 you say that we can see it stops creating the object file correctly -- but I don't see why you say that? The entire screen of text is a valid compressed object file from top to bottom -- it doesn't change, it just has different data. Uncompressed object code has 4 characters between the tags, and hex bytes only -- that's just showing ASCII characters, which is normal for compressed object files.

 

At 2:30 when you load the file and it fails at >6390, what I would have liked to see is the Classic99 debug log, so we can check whether it detected a read error or not.

 

I would also like to see your disk configuration and compare it against where you are loading from, as well as see whether you set some of the extended options.

 

Since the files are TI files and not PC text files, extensions should not be used.

 

Finally, how about just posting that object file so I can try to load it?

Edited July 17, 2014 by Tursi

[RXB]

I watched your video, and I'll see if this is helpful, apparently you didn't read the manual....

 

"Corrupt DSK RAM" - this option (which should have been off) corrupts the VDP memory (and some scratchpad) that would be used by the TI disk controller after a disk operation in order to help find programs that rely on side effects from the TI disk controller. If it affected your program, it may be relying on side effects. It does not affect your disk files directly in any way, it just scrambles memory that should be consider scrambled (some would add only in my opinion) on a real TI system (although randomly) for the sake of development. Leave it off unless you're using it (although having it on will not affect most programs, and programs that fail should likely fail on Classic99 either way).

 

At 0:56 you say that we can see it stops creating the object file correctly -- but I don't see why you say that? The entire screen of text is a valid compressed object file from top to bottom -- it doesn't change, it just has different data. Uncompressed object code has 4 characters between the tags, and hex bytes only -- that's just showing ASCII characters, which is normal for compressed object files.

 

At 2:30 when you load the file and it fails at >6390, what I would have liked to see is the Classic99 debug log, so we can check whether it detected a read error or not.

 

I would also like to see your disk configuration and compare it against where you are loading from, as well as see whether you set some of the extended options.

 

Since the files are TI files and not PC text files, extensions should not be used.

 

Finally, how about just posting that object file so I can try to load it?

Ok Tursi here you go a video and a copy of RXB with Classic set up.

https://www.youtube.com/watch?v=7ej8fFb8n2A&feature=youtu.be

classic99-GPL-Loader.zip

[Tursi]

This was a bit of a pain in the ass to figure out. But, the problem is in the source file itself.

Line looks like this (I am going to type it as if it was uncompressed so we can read the data - remember that all hex bytes would be single ASCII characters):

96390BA38EB02E2B3100B0238B0032BB238B1FA3B3800B5BBEBA371B3105B63A5963A4B0086BA39EBBE73B8806B6917B8645B8746B0680B1286B34BFF

 

Now, a brief recap - '9' tags set an absolute load address. 'B' tags load two bytes at data at the 'current' address.

 

The way that the GPL Loader works, is it reads one line from the object file. It writes that line to GRAM, then it goes back and verifies that the data was written correctly. If not, it reports FILE ERROR OR NO GRAM.

 

Thanks to the Classic99 debug log, we know there was no DSR error, and I could see in the debugger that GRAM was being updated. With a bit of a binary search manually comparing the object file to the GROM view in Classic99, I found that the first address which was not updated correctly was at >63A4.

 

So next I set a breakpoint on writing >63A4. I stepped through that code when it hit, and verified that the correct data was set in GRAM. I added a read breakpoint so I could check the read-back code, but the write breakpoint hit a second time first. The data at >63A4 was overwritten by a new value -- and this new value caused the first verify to fail.

 

Finding that line in the source, you can see it above. Halfway through the line it changes the write address to >63A4 (in red). However, before that point, the line has already written data to addresses >6390 - >63A7, so the second half of the line overwrites the data from >63A4 - >63A7. Since the verify is done as a separate pass, this causes a mismatch and it fails. (If this had been on a separate line of the file, it would actually have worked and only the latter data would have preserved).

 

So -- check your source, especially around that GROM address. You have two things being stored at >63A4 through >63A7, and sort of just got lucky that the loader discovered it.

Edited July 19, 2014 by Tursi

[RXB]

This was a bit of a pain in the ass to figure out. But, the problem is in the source file itself.

 

Line looks like this (I am going to type it as if it was uncompressed so we can read the data - remember that all hex bytes would be single ASCII characters):

 

96390BA38EB02E2B3100B0238B0032BB238B1FA3B3800B5BBEBA371B3105B63A5963A4B0086BA39EBBE73B8806B6917B8645B8746B0680B1286B34BFF

 

Now, a brief recap - '9' tags set an absolute load address. 'B' tags load two bytes at data at the 'current' address.

 

The way that the GPL Loader works, is it reads one line from the object file. It writes that line to GRAM, then it goes back and verifies that the data was written correctly. If not, it reports FILE ERROR OR NO GRAM.

 

Thanks to the Classic99 debug log, we know there was no DSR error, and I could see in the debugger that GRAM was being updated. With a bit of a binary search manually comparing the object file to the GROM view in Classic99, I found that the first address which was not updated correctly was at >63A4.

 

So next I set a breakpoint on writing >63A4. I stepped through that code when it hit, and verified that the correct data was set in GRAM. I added a read breakpoint so I could check the read-back code, but the write breakpoint hit a second time first. The data at >63A4 was overwritten by a new value -- and this new value caused the first verify to fail.

 

Finding that line in the source, you can see it above. Halfway through the line it changes the write address to >63A4 (in red). However, before that point, the line has already written data to addresses >6390 - >63A7, so the second half of the line overwrites the data from >63A4 - >63A7. Since the verify is done as a separate pass, this causes a mismatch and it fails. (If this had been on a separate line of the file, it would actually have worked and only the latter data would have preserved).

 

So -- check your source, especially around that GROM address. You have two things being stored at >63A4 through >63A7, and sort of just got lucky that the loader discovered it.

You were right some how the 3 of my GPL Source got messed up in versions.

 

It may have been me doing some messing around with moving stuff from Classic99 to MESS and back.

 

I will have to be more careful to make more backups before I experiment with this stuff.