Jump to content
IGNORED

New versions available


F.G. Kaal

Recommended Posts

On 10/28/2022 at 1:27 PM, F.G. Kaal said:

The most part of Gdm2k is written in Clint Pulley's C99 and optimized by 3 optimizers. Things of which I thought that could be done shorter/faster are written in assembly.

 

Gdm2k is a direct copy of Dm2k only all file IO is replaced by the MDOS XOP variants. The X(ecute) option is now dissabled because I don't know how to do it. I also don't know if memory is an issue ... Gdm2k starts with a malloc() for file buffers. Examples for some new neat options for Gdm2k are welcome 🙂

 

Fred

Another nice update would be to have it read an entire file at a time during copy, or perhaps even multiple files. That would speed it up quite a bit. c",)

Link to comment
Share on other sites

  • 4 weeks later...
On 10/28/2022 at 1:27 PM, F.G. Kaal said:

The most part of Gdm2k is written in Clint Pulley's C99 and optimized by 3 optimizers. Things of which I thought that could be done shorter/faster are written in assembly.

 

Gdm2k is a direct copy of Dm2k only all file IO is replaced by the MDOS XOP variants. The X(ecute) option is now dissabled because I don't know how to do it. I also don't know if memory is an issue ... Gdm2k starts with a malloc() for file buffers. Examples for some new neat options for Gdm2k are welcome 🙂

 

Fred

I've had a few issues with unreadable floppy disk sectors, thus only partially copied files. The destination file remains however, in an incomplete state. I suggest a deletion of such files be implemented in a future release. c",) For now, I'm doing it manually.

Link to comment
Share on other sites

On 11/29/2022 at 12:51 PM, Brufnus said:

I've had a few issues with unreadable floppy disk sectors, thus only partially copied files. The destination file remains however, in an incomplete state. I suggest a deletion of such files be implemented in a future release. c",) For now, I'm doing it manually.

I'm not going to add this. I have encountered enough stupid tools that needed to do some task(s) and ends with a "General Error", "Major Fault" or  "Something went wrong" message and deleting all the work what was done so far so that I had no clue what went wrong and why.

 

For (G)dm2k I like the feature that if I try to rescue some data from a bad floppy that I still can have the bits and pieces that could be read. This can be just enough to continue with the little project ;-)

 

Fred

  • Like 4
Link to comment
Share on other sites

On 11/30/2022 at 7:00 PM, F.G. Kaal said:

I'm not going to add this. I have encountered enough stupid tools that needed to do some task(s) and ends with a "General Error", "Major Fault" or  "Something went wrong" message and deleting all the work what was done so far so that I had no clue what went wrong and why.

 

For (G)dm2k I like the feature that if I try to rescue some data from a bad floppy that I still can have the bits and pieces that could be read. This can be just enough to continue with the little project ;-)

 

Fred

I understand your arguments. I've also had good experience by the way by copying those files that didn't generate any errors. then retrying with the bad ones... then it's quite often just able to read them.

Link to comment
Share on other sites

On 10/28/2022 at 7:07 PM, InsaneMultitasker said:

DM (Directory Manager) was written by Clint in C, compiled by TIC and assembled with TASM.  If DM code would help to understand how some of the MDOS  processes are handled, I am happy to share the current source for reference. (I have updated it periodically for minor bug fixes and feature changes).

Progress is slow, found out that TIC's stack is bottom up and the DM program also uses sneaky the stack space (from R14 up) as a buffer.

Have to rewrite quitte a few bits and pieces.

 

Added X to GDM2K and added the code needed without a call to it. I first have to rewrite this for C99C and also read the UTIL XOP's manual.

Had something strange this afternoon; I'm testing with the Geneve emulator, copying the GDM2K program to a floppy image everytime.

Just added the code, GDM2K can start.

Added a call to my execute() function, which only tells me if it is an MDOS or TI program and it doesn't want to start anymore.

 

Is there a maximum size for a program to run under MDOS ?

GDM2K is now almost 32Kb and claims 24Kb RAM with malloc() for buffers.

 

Is there a maximum size for a program segment?

GDM2K is in 8Kb chunks but DM is 16Kb and DN is the remainder of 6Kb.

 

I also see a difference in the header of GDM2K and DM:

GDM2K is >50 >47 and the last file GDM2N is >00 >47

while DM is >FF >46 and DN is >00 >46

 

What is the difference (if any)?

I have read somewhere about the MDOS program header but I can't remember where.

 

 

 

  • Like 2
Link to comment
Share on other sites

3 hours ago, F.G. Kaal said:

Is there a maximum size for a program to run under MDOS ?

GDM2K is now almost 32Kb and claims 24Kb RAM with malloc() for buffers.

 

Is there a maximum size for a program segment?

GDM2K is in 8Kb chunks but DM is 16Kb and DN is the remainder of 6Kb.

the MDOS task loader loads into space from >0400 to >0DFF, or approximately 55K.  You can also request memory in 8k blocks to use as buffers, program space, etc.  The maximum program segment is typically 15-16k.  I forget the exact number offhand.  Some Linkers use 8k images but there is no need to limit this unless you have gaps in the memory layout. 

4 hours ago, F.G. Kaal said:

I also see a difference in the header of GDM2K and DM:

GDM2K is >50 >47 and the last file GDM2N is >00 >47

while DM is >FF >46 and DN is >00 >46

See the GENLINK documentation for information about the headers, flags, etc.  Geneve programs use F and G to indicate the desired memory speed, assuming pages are available.  00 and FF are similar to the ea5 loader flag to tell whether there is another file in the chain. 

  • Like 3
Link to comment
Share on other sites

On 12/2/2022 at 9:07 PM, Brufnus said:

I understand your arguments. I've also had good experience by the way by copying those files that didn't generate any errors. then retrying with the bad ones... then it's quite often just able to read them.

Is there a way to notify the user that "Hey, I had an error, but I was able to copy part of it, so check the target file"?

 

  • Like 1
Link to comment
Share on other sites

3 hours ago, acadiel said:

Is there a way to notify the user that "Hey, I had an error, but I was able to copy part of it, so check the target file"?

 

Well, there aren't really any configuration options I think; it does return an error message of course, and some files can prove useful partially copied, but program files and archives not so much of course.

 

Still, I love having two windows at my disposal and it's nice to be able to go up and down directory levels simply by pressing enter. The other managers are, IMHO, lacking in this aspect.

 

What would be nice, too, would be an integrated "Archiver 3" so that one could create and extract archives directly between these two windows. I don't know if any Archiver 3 or 4 source code is available?

  • Like 1
Link to comment
Share on other sites

On 12/5/2022 at 11:18 PM, InsaneMultitasker said:

the MDOS task loader loads into space from >0400 to >0DFF, or approximately 55K.  You can also request memory in 8k blocks to use as buffers, program space, etc.  The maximum program segment is typically 15-16k.  I forget the exact number offhand.  Some Linkers use 8k images but there is no need to limit this unless you have gaps in the memory layout. 

See the GENLINK documentation for information about the headers, flags, etc.  Geneve programs use F and G to indicate the desired memory speed, assuming pages are available.  00 and FF are similar to the ea5 loader flag to tell whether there is another file in the chain. 

Thanks for the info great InsaneMultitasker.

 

Found this indeed in the GENlink manual.

Max length per segment is >3DFA

'F' (>46) for fastram (if available)

'G' (>47) for slowram.

first byte >FF (or at least != >00) : This is not the last segment

first byte >00 : This is the last segment

 

I think that the >50 I use (that I found in some manual) has not a special meaning.

I am going to add something to my linker L99 to make it possible to create bigger segments than 8Kb.

 

 

Yesterday evening I could succesfully load DM from GDM2K and could load GDM2K again from DM with command line arguments. It was also posible to return from GDM2K back to DM back to GDM2K back to MDOS. So far so good.

 

GDM2K is a little bit smaller then 32Kb now and malloc's 12KB RAM space. 8KB for a data buffer and 4Kb for the file panels. So there is about 10KB left. The X function is operational, now I just have to check what the Z function does exactly. 🙂

 

Fred

 

 

 

 

 

  • Like 2
Link to comment
Share on other sites

On 12/6/2022 at 7:12 PM, Brufnus said:

Well, there aren't really any configuration options I think; it does return an error message of course, and some files can prove useful partially copied, but program files and archives not so much of course.

 

Still, I love having two windows at my disposal and it's nice to be able to go up and down directory levels simply by pressing enter. The other managers are, IMHO, lacking in this aspect.

 

What would be nice, too, would be an integrated "Archiver 3" so that one could create and extract archives directly between these two windows. I don't know if any Archiver 3 or 4 source code is available?

I think that all this will exceed the maximum program size of ~55KB.

Link to comment
Share on other sites

36 minutes ago, F.G. Kaal said:

GDM2K is a little bit smaller then 32Kb now and malloc's 12KB RAM space. 8KB for a data buffer and 4Kb for the file panels. So there is about 10KB left. The X function is operational, now I just have to check what the Z function does exactly

If you want to explore memory management for buffering, a separate topic would be good.  Paging memory is easy.  File IO operates on 24-bit addressing (page+16bit address), not the local 64K memory window, which can be frustrating if not set up properly. 

 

On 12/6/2022 at 12:12 PM, Brufnus said:

What would be nice, too, would be an integrated "Archiver 3" so that one could create and extract archives directly between these two windows. I don't know if any Archiver 3 or 4 source code is available

i released BLOB, a command line decompressor, with the last Directory Manager update as written in other topics. It should work equally well with GDM2K if/when Fred decides to implement calling the program.  However, it won't integrate with the two windows as it is standalone program, but may be an option for you.

Link to comment
Share on other sites

7 hours ago, InsaneMultitasker said:

If you want to explore memory management for buffering, a separate topic would be good.  Paging memory is easy.  File IO operates on 24-bit addressing (page+16bit address), not the local 64K memory window, which can be frustrating if not set up properly. 

 

i released BLOB, a command line decompressor, with the last Directory Manager update as written in other topics. It should work equally well with GDM2K if/when Fred decides to implement calling the program.  However, it won't integrate with the two windows as it is standalone program, but may be an option for you.

Link to comment
Share on other sites

7 hours ago, InsaneMultitasker said:

If you want to explore memory management for buffering, a separate topic would be good.  Paging memory is easy.  File IO operates on 24-bit addressing (page+16bit address), not the local 64K memory window, which can be frustrating if not set up properly. 

 

i released BLOB, a command line decompressor, with the last Directory Manager update as written in other topics. It should work equally well with GDM2K if/when Fred decides to implement calling the program.  However, it won't integrate with the two windows as it is standalone program, but may be an option for you.

While BLOB won't integrate with the two windows, I would think you could pass command line arguments for filepath/orgination file (Window 1) and destination path (Window 2).

 

At least I think that would work.

Link to comment
Share on other sites

12 minutes ago, 9640News said:

While BLOB won't integrate with the two windows, I would think you could pass command line arguments for filepath/orgination file (Window 1) and destination path (Window 2).

Agreed.  This is how Directory Manager calls BLOB, so yes, it would/should work if Fred adds the support to his eXecution routine.

  • Like 1
Link to comment
Share on other sites

On 12/8/2022 at 3:20 AM, InsaneMultitasker said:

Agreed.  This is how Directory Manager calls BLOB, so yes, it would/should work if Fred adds the support to his eXecution routine.

Forgot about blob, but if I get it to work I will do this. For now big problems ... executing a file from GDM2K doesn't want to work anymore.

 

Found a minor glitch in my assembler (XA99) ... it doesn't know the correct size when a DXOP SYSC,0 is done and SYSC @DUTLXOP is used in pass 1. Using XOP @DUTLXP,0 does fix this problem. I need to add some kind of allignment test between the two passes of the assembler. But that is for some other time.

 

After fixing this GDM2K still doesn't want to execute a program. The runprog() function can load the first 256 bytes of the program to execute, it finds it is an MDOS program, asks for a command line and it call's runtask().

 

Then runtask() calls loadtask() and that one should return with a value of zero

 

original code from runtask:

    if((child = loadtask(tname,argstr)) == 0)
      child = pathload(tname,argstr);

    if ( child == 0 ) {
      printf("Error - Unable to load %s\n",tname);
      return;
    }
    else {
    }

my code:
    child = loadtask(wbuf, tname, argstr);
    printf("L child=%u\n", child);
    printf("L name=%u %-15.15s\n", wbuf[0], &wbuf[1]);
    printf("L pferr=%u lferr=%u\n", lferr, pferr);
    printf("L pagnr=%u\n", pagnr);
    chkkey();

    if(child == 0)
    {
        if ((child = pathload(tname, argstr)) == 0)
        {
            errno = 1;
        }
    }
    else
    {
        errno = 1;
    }

Original code is wrong ... if loadtask() does not return 0 the program continues with the taskswitch part.

 

In my code I always get a child = 233 the first try and then 34, 33, 32, 31 .... 28 en then I had a 0, but that was wrong, this was because of a bug in loadtask() itself:

        LI   R0,LOAPRO          ; LOAD IN THE PROGRAM
        MOV  R7,R1              ; use Data BUFfer (is parsed filename)
        XOP  @DUTLXP,0          ; DO IT
 MOV R0,@LFERR
        MOV  R0,R0              ; ANY ERROR ON RETURN?
        JEQ  LODCNT             ; BRIF NO
**      CLR  R8                 ; CLEAR PAGE 0 RETURNED <--- THIS IS WRONG
        SETO R8                 ; <-- THIS IS BETTER BECAUSE THERE IS SOME ERROR SITUATION
        B    *R13

So what I always get as an result at the first attempt running some "BIGECHO abc" program:

    child=233
    name=3 abc
    pferr=0 lferr=0
    pagnr=233

 

This all means that the program file name was parsed correct, the argument "abc" is still there, the pagnr/child is there but child is not zero ... kind find out why.

 

I also checked everything with the original code I got from DM and everything is still the same, except for the wbuf I need which is used for the parse filename function. 

 

I'm flabbergasted for the moment. Can't understand why it worked a few days ago and nothing has changed and it can't pass the call to loadtask(). 😞

 

Link to comment
Share on other sites

3 hours ago, F.G. Kaal said:

I'm flabbergasted for the moment.

I am out of the flabbergasted state ... I got a brainwave and starting a program from GDM2K is working again. This is the joy of not so good commented software. It is perfectly clear while working on it but a pain in the *ss after ten years or somebody else is re-using your hard work.

 

It suddenly struck me. This piece of code:

 

    if((child = loadtask(tname,argstr)) == 0)
      child = pathload(tname,argstr);
    if ( child == 0 ) {
      printf("Error - Unable to load %s\n",tname);
      return;
    }
    else {
    :
      taskswitch stuff
    :
    }

are two different things. Had to add a lot of printf() statements to see the light.

 

When starting an MDOS program from GDM2K then the function loadtask() should do it. If that is okay then the taskswitch stuff is executed and the program is started.

 

When loadtask() fails then it is something else (but not a TI-mode program because that is handled differently) and pathload() is executed. If that also fails then the program is unable to load.

 

I haven't figured out yet why pathload() is there.

 

But again ... so far so good 🙂 (so this also means that the CLR R8 in the above message was correct afterall !!)

Edited by F.G. Kaal
Link to comment
Share on other sites

Geneve programs are executed directly. /4a programs launch EXEC (a Geneve program) which in turn runs the /4a program based on the passed argument.  Geneve program execution also uses the PATH variable to find the program. Thus keeping commonly used programs like EXEC, QDE, BLOB, FED, etc. in a folder referenced in the PATH is a 'good thing'.

Link to comment
Share on other sites

13 hours ago, InsaneMultitasker said:

Geneve programs are executed directly. /4a programs launch EXEC (a Geneve program) which in turn runs the /4a program based on the passed argument.  Geneve program execution also uses the PATH variable to find the program. Thus keeping commonly used programs like EXEC, QDE, BLOB, FED, etc. in a folder referenced in the PATH is a 'good thing'.

Yes ... I see this now.

I am doing my tests with the Geneve emulator and a DSK1 floppy image containing my test files.

When starting GDM2K from drive A: then GDM2K also finds EXEC there. When started from E:\ I see it is using the other method witch is retrieving PATH and then the program crashes. The retrieved path is not correct here, first fix this.

 

I also see now why VIDEO80 must be called when returning from running a program in TIMODE 🙂

 

I'm getting there slowly.

  • Like 1
Link to comment
Share on other sites

3 hours ago, F.G. Kaal said:

Yes ... I see this now.

I am doing my tests with the Geneve emulator and a DSK1 floppy image containing my test files.

When starting GDM2K from drive A: then GDM2K also finds EXEC there. When started from E:\ I see it is using the other method witch is retrieving PATH and then the program crashes. The retrieved path is not correct here, first fix this.

 

I also see now why VIDEO80 must be called when returning from running a program in TIMODE 🙂

 

I'm getting there slowly.

Lot of progress this afternoon.

 

Stumble against the differences between TIC and C99C.

TIC can handle char ** and C99C can't. First changed a char ** to char * but that is not correct, This is handled as a C-string by C99C ... must be an int * this can be used as a pointer to anything.

 

Next problem with C99C is char *array[n] and int *array[n]. This is not handled correctly. When passing an array like this as an argument to a function like function(array) then the first element of array is passed (array[0]) instead of the address of array. In this case in C99C the address must be passed explicitly ... function(&array[0]). Simple char and int arrays are handled correclty.

 

Last problem of this afternoon whas the parsfn(pptr[j],wstr) function used in DM. Could not find the source of this one but description was in the util document. So I made a guess what it should do. With some trial and error I changed it to this call: parsfn(pptr[j], wstr, 40);  

 

and a function like this:

/* parsfn -convert logicalname to physical name
 *
 * ln - logical name
 * pn - physical name
 * sz - max size of physical name
 */
parsfn(ln, pn, sz) char *ln,*pn; int sz;
{
#asm
       LI   0,PARFIL        ; opcode Parse Filename
       MOV  @6(14),1        ; logical name address
       MOV  @4(14),2        ; physical name address
       MOVB @3(14),*2       ; set max size (max is 255)
       CLR  3               ; alias flag
       XOP  @DUTLXP,0       ; convert
       MOV  1,8             ; error code

       MOV  @4(14),2        ; physical name address
       MOVB *2+,3           ; get size
       SRL  3,8             ; make it a word
       A    3,2             ; end of string address
       MOVB 3,*2            ; max it a C-string
#endasm
       return;
}

 

And after changing this from DM child=loadtask(wstr,argstr); into this for GDM2k child=loadtask(&wstr[1], argstr);

(because the first element of wstr is the length of the string) I could finally find find the EXEC program in the path and load and run a TI program. 🙂 🙂 🙂 

 

 

  • Like 2
Link to comment
Share on other sites

4 hours ago, F.G. Kaal said:

I also see now why VIDEO80 must be called when returning from running a program in TIMODE

In some cases, it is good practice to query the video XOP, save the current mode, set the mode, then restore at exit.  MDOS defaults to 80x24 text mode but you can also use MODE 90 (80x26.5 text mode) and MODE 60 (graphics mode 6, 80x25).  I think that EXEC saves/restores the video mode. Does GDM2K do this?  It is easy to test by setting the mode at the OS prompt.  :)    Sounds like you made good progress if a TI program is loading! :)  

  • Like 1
Link to comment
Share on other sites

On 12/7/2022 at 8:01 PM, InsaneMultitasker said:

If you want to explore memory management for buffering, a separate topic would be good.  Paging memory is easy.  File IO operates on 24-bit addressing (page+16bit address), not the local 64K memory window, which can be frustrating if not set up properly. 

 

i released BLOB, a command line decompressor, with the last Directory Manager update as written in other topics. It should work equally well with GDM2K if/when Fred decides to implement calling the program.  However, it won't integrate with the two windows as it is standalone program, but may be an option for you.

That sounds nice, where can I find that one?

Link to comment
Share on other sites

  • 2 weeks later...
On 12/8/2022 at 3:06 AM, 9640News said:

While BLOB won't integrate with the two windows, I would think you could pass command line arguments for filepath/orgination file (Window 1) and destination path (Window 2).

 

At least I think that would work.

I am integrating BLOB at the moment, but what is BLOB doing with the keyboard. After exiting BLOB and returning to GDM2K the keyboard is not functioning normal any more. All the ctrl and fctn keys of GDM2K are doing something else ... very strange.

 

... okay, added a kbmode(5) in GDM2K after executing BLOB, the keyboard is functioning normal again 🙂

Edited by F.G. Kaal
  • Like 4
Link to comment
Share on other sites

Working on GDM2K gives me this short list of interesting addresses:

 

0x0128     /* start address of command line for this task */
0x011E     /* start address of path for this task */
0x00FE     /*   0 = no ctrl-c exit */

 

Are there more interesting addresses c.q. task data to know? 

 

Link to comment
Share on other sites

There are some addresses out there.  This file from MDOS\HEAD\TASKHEADS has a listing of everything in the first >03FF bytes of the task header.  There is very little (almost none), documentation on everything in this file outside of this source file I have attached.

 

If you want to investigate some of the key presses that are returned such as DEL, CTRL-C, etc., then I would suggest using BHDMV where you can map and display contents of any page in memory "live".

 

Hope this helps some.

 

 

TASKHEADS.txt

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...