DX10 Home Computer Software Development System

[+mizapf]

TASM fails to assemble a file that ends with a END <label>. On its second pass, it issues an error message that it could not open the file. The actual problem is that this error sometimes occurs for other files as well, and I could not find out when exactly this happens. My observation was that at some time, TASM stopped working. I suspected a) a problem in MAME; then I could reproduce it on my real system, hence b) an error in the SCSI file system that occurs when a certain amount of data has been stored on the device; then I found it on floppies, hence c) an error in GeneveOS (MDOS).

 

It turned out to be an error in TASM; a misplaced pointer overwrites code in TASM. Still, I'd like to find out where exactly the issue originates, because the error only occurs after TASM runs for the second time. That is, something in the Geneve state has changed. It could still be an issue in the OS that only shows up for TASM.

 

You could say, just use Genasm, but* it is tempting to trace that error because I can reproduce it easily, and it could still be a bug outside of the program.

 

(*besides the fact that I dislike single-pass compilers/assemblers from a technical point of view, and it produces ugly object code, and speed is no excuse for me)

[+9640News]

4 minutes ago, mizapf said:

TASM fails to assemble a file that ends with a END <label>. On its second pass, it issues an error message that it could not open the file. The actual problem is that this error sometimes occurs for other files as well, and I could not find out when exactly this happens. My observation was that at some time, TASM stopped working. I suspected a) a problem in MAME; then I could reproduce it on my real system, hence b) an error in the SCSI file system that occurs when a certain amount of data has been stored on the device; then I found it on floppies, hence c) an error in GeneveOS (MDOS).

 

It turned out to be an error in TASM; a misplaced pointer overwrites code in TASM. Still, I'd like to find out where exactly the issue originates, because the error only occurs after TASM runs for the second time. That is, something in the Geneve state has changed. It could still be an issue in the OS that only shows up for TASM.

 

You could say, just use Genasm, but* it is tempting to trace that error because I can reproduce it easily, and it could still be a bug outside of the program.

 

(*besides the fact that I dislike single-pass compilers/assemblers from a technical point of view, and it produces ugly object code, and speed is no excuse for me)

Well, I take it you have fixed the misplaced pointer overwrite issue?  If so, I would then start to question whether either a Memory XOP or DSR XOP (which uses the Memory XOP) is not mapping things correctly whether this being a bug in MDOS or a TASM programming bug issue.  Possibly, there is a memory page not being mapped correctly, thus overwriting something in MDOS.  As this is likely only tied to TASM, I would have a suspicion TASM is mapping something into the 21 bit memory space on either a MEM XOP call or that gets mapped during a DSR call that then uses a MEM XOP call.

 

I would watch out for memory writes in the >0000 to >7FFF range, and more than likely, more specific to >2000 to >7FFF when physical page >00 is mapped in at >F110 during an XOP call with the MAME debugger.

 

You might also inspect the "buffer" if TASM uses it, that stores the complete list of memory pages and either zero them out with >00 or with >FF in case they are random bytes in the program image file.

 

One possibility is to take a memory "dump" of 8K pages MDOS is using prior to calling TASM.  Then, do another memory dump of the individual 8K pages after TASM and look for some significant code overwrites.   It has been so long since I looked at MDOS code specifically, that I do not know if the various XOP's use some of their own workspaces, or if they just use workspace room up in the >Fxxx range.  I know there is a reserved range, just don't recall the address range.

 

I doubt TASM uses it, but probably the least tested MEM XOP is the one that uses and releases shared memory.  I'm not aware of any program that uses it.  There is a remote chance TASM could have called that function/XOP, and something remained that causes TASM to cough on the second time around if shared memory did not get released properly.

 

What happens if you type the & key and hit <ENTER> before calling TASM the second time?  That should release memory, but not 100% sure it would release something that was possibly in a "shared" state.

 

Just throwing ideas out there.

 

Beery

 

 

 

[+TheBF]

3 hours ago, BeeryMiller said:

My particular use would be on the Geneve, either in GPL or MDOS mode. I would really hope that one could select/click the files to transfer, and then it would go and do its thing without any manual intervention.  Take MDOS source for example as there are probably 100+ source files.  Yes, that is an extreme case, but would not want manual intervention if that is what you are thinking.

 

Beery

Sounds like a design spec to me. 

My idea of using Classic99 as the go-between is definitely one file at a time so not ideal for your needs. 

I will put it on my stack anyway and see where it goes.

 

[+mizapf]

31 minutes ago, BeeryMiller said:

Just throwing ideas out there.

Thanks, really appreciated. I'm just in the middle of debugging, I already found where the wrong value causes the issue, but not yet how it came into the system. The problem with those errors is that they may originate hundreds of thousands of instructions earlier before they show up.

 

I'll drop a note when I find out more.

[jbdigriz]

Some of the files in this thread have links to ftp://www.dragonsweb.org/pub/ti/docs and subdirectories thereof. Please note that all content has been moved to ftp://ftp.dragonsweb.org and thereunder, if you're looking for any of those files.

 

Thanks, and sorry for any inconvenience.

jbdigriz

 

[+FarmerPotato]

On 2/13/2022 at 7:42 PM, jbdigriz said:

Some of the files in this thread have links to ftp://www.dragonsweb.org/pub/ti/docs and subdirectories thereof. Please note that all content has been moved to ftp://ftp.dragonsweb.org and thereunder, if you're looking for any of those files.

Are these files still online somewhere? I can see three files with

curl ftp.dragonsweb.org/pub 

 

but ftp is mostly blocked by firewalls these days. 

[jbdigriz]

3 hours ago, FarmerPotato said:

Are these files still online somewhere? I can see three files with

curl ftp.dragonsweb.org/pub 

 

but ftp is mostly blocked by firewalls these days. 

Doing some extended maintenance and still waiting to get replacement for a failing drive on a file server with a degraded array. Working on it.