Difference between revisions of "Programming in MDOS"

From Ninerpedia
Jump to navigation Jump to search
Line 66: Line 66:
The answer is that the command line arguments are stored as a single string (with leading length byte) in a linked list of chunks of 6 bytes each. The pointer to this list is at address >0128 of the memory page at 0000-1FFF that was set when the program was started (so take care when you change the mapper). Here is an illustration:
The answer is that the command line arguments are stored as a single string (with leading length byte) in a linked list of chunks of 6 bytes each. The pointer to this list is at address >0128 of the memory page at 0000-1FFF that was set when the program was started (so take care when you change the mapper). Here is an illustration:


[[File:args.png|400px]]
[[File:args.png|300px]]


The command line arguments do not contain the program name, and they are not parsed, that is, you have to analyze the string in your application program. The memory location at >0128 contains a 0000 when there are no arguments. The end of the list is indicated by a next pointer that is set to 0000. Be aware that the last chunk may have arbitrary content after the end of the string. The pointers are 2 bytes each and start at word boundaries.
The command line arguments do not contain the program name, and they are not parsed, that is, you have to analyze the string in your application program. The memory location at >0128 contains a 0000 when there are no arguments. The end of the list is indicated by a next pointer that is set to 0000. Be aware that the last chunk may have arbitrary content after the end of the string. The pointers are 2 bytes each and start at word boundaries.

Revision as of 12:04, 22 October 2011

Extended Operations (XOPs)

MDOS makes frequent use of XOPs and offers them for user programs. An XOP (extended operation) is a special command of the TMS processor family which causes a context switch, transferring control to a location that is specified in a table.

Here are the details of the MDOS XOP Definitions.

Device access in TIC

Reading and writing disk sectors

The following code demonstrates how level-2 file access can be used in a TIC program. It copies a file, independent of the file format, by reading a sector and writing to a target file. Each sector is allocated when written.

This sample code is certainly not the best way to copy files (wasting a lot of time by repeatedly and writing single sectors); it is only intended to illustrate the level-2 access.

#include <stdio_h>
#include <stdlib_h> 

main(argc, argv)
int argc; char *argv[];
{
   int  res, sect, i;
   char rbuf[256];
   int  *ibuf;

   if (argc<2)
   {
       printf("Syntax: filecopy <from_file> <to_file>\n");
       return;
   }

   /* First we get the metadata */
   res = bread(argv[1], 0, 0, rbuf);
   check(res);

   /* write the old metadata as new metadata */
   res = bwrite(argv[2], 0, 0, rbuf);
   check(res);

   /* copy the file sector by sector */
   ibuf = rbuf;
   sect = ibuf[2];
   for (i=0; i < sect; i++)
   {
       printf("Copying sector %d of %d\r", i+1, sect);
       res = bread(argv[1], i, 1, rbuf);
       check(res);
       res = bwrite(argv[2], i, 1, rbuf);
       check(res);
   }
}

void check(code)
int code;
{
   if (code != 0)
   {
       printf("Error, code = %d\n", code);
       exit(7);
   }
}

Getting the arguments from the MDOS command line

There is only little documentation on the MDOS environment. One of the most interesting questions is how to retrieve the command line arguments in order to process them in the own program. TIC seems to be able to do, so our assembly language program should as well.

The answer is that the command line arguments are stored as a single string (with leading length byte) in a linked list of chunks of 6 bytes each. The pointer to this list is at address >0128 of the memory page at 0000-1FFF that was set when the program was started (so take care when you change the mapper). Here is an illustration:

Args.png

The command line arguments do not contain the program name, and they are not parsed, that is, you have to analyze the string in your application program. The memory location at >0128 contains a 0000 when there are no arguments. The end of the list is indicated by a next pointer that is set to 0000. Be aware that the last chunk may have arbitrary content after the end of the string. The pointers are 2 bytes each and start at word boundaries.

The following code is an example how to retrieve the list contents:

BUF    BSS  80           Reserve 80 bytes of space

START  MOV  @>0128,R0    Get pointer to list
       JEQ  NOARGS       If it is 0, skip all 

ST1    LI   R3,BUF       Pointer to buffer
       MOV  *R0+,R1      Store next pointer in R1
       LI   R5,6         Number of bytes in chunk
       MOVB *R0+,R2      Get length byte
       DEC  R5           Count down one for that byte
       SRL  R2,8         Move length byte to the low byte
       MOV  R2,*R3+      and write it at the head of the buffer

GL1    MOVB *R0+,*R3+    Copy the current byte to the buffer
       DEC  R2           Count down remaining string bytes
       JEQ  GOTALL       Done?
GL2    DEC  R5           No, count down chunk counter
       JNE  GL1          Chunk done? 
GL3    MOV  R1,R0        Yes, put the next address in R0
       JEQ  DONE         Is it null? 
       MOV  *R0+,R1      No, so there is another chunk
       LI   R5,6         Reset chunk counter
       JMP  GL1          End of loop

DONE ...
NOARGS ...