Brufnus Posted November 2, 2022 Share Posted November 2, 2022 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",) Quote Link to comment Share on other sites More sharing options...
Brufnus Posted November 29, 2022 Share Posted November 29, 2022 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. Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted November 30, 2022 Author Share Posted November 30, 2022 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 4 Quote Link to comment Share on other sites More sharing options...
Brufnus Posted December 3, 2022 Share Posted December 3, 2022 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. Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 5, 2022 Author Share Posted December 5, 2022 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. 2 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 5, 2022 Share Posted December 5, 2022 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. 3 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted December 6, 2022 Share Posted December 6, 2022 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"? 1 Quote Link to comment Share on other sites More sharing options...
Brufnus Posted December 6, 2022 Share Posted December 6, 2022 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? 1 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 7, 2022 Author Share Posted December 7, 2022 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 2 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 7, 2022 Author Share Posted December 7, 2022 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 7, 2022 Share Posted December 7, 2022 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. Quote Link to comment Share on other sites More sharing options...
+9640News Posted December 8, 2022 Share Posted December 8, 2022 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. Quote Link to comment Share on other sites More sharing options...
+9640News Posted December 8, 2022 Share Posted December 8, 2022 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 8, 2022 Share Posted December 8, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 9, 2022 Author Share Posted December 9, 2022 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(). 😞 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 9, 2022 Author Share Posted December 9, 2022 (edited) 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 December 9, 2022 by F.G. Kaal Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 9, 2022 Share Posted December 9, 2022 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'. Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 10, 2022 Author Share Posted December 10, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 10, 2022 Author Share Posted December 10, 2022 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. 🙂 🙂 🙂 2 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 10, 2022 Share Posted December 10, 2022 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! 1 Quote Link to comment Share on other sites More sharing options...
Brufnus Posted December 11, 2022 Share Posted December 11, 2022 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? Quote Link to comment Share on other sites More sharing options...
Brufnus Posted December 11, 2022 Share Posted December 11, 2022 On 12/7/2022 at 7:18 PM, F.G. Kaal said: I think that all this will exceed the maximum program size of ~55KB. Yeah, okay... we do have some limits to deal with, I have to keep that in mind. Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 19, 2022 Author Share Posted December 19, 2022 (edited) 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 December 19, 2022 by F.G. Kaal 4 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 19, 2022 Author Share Posted December 19, 2022 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? Quote Link to comment Share on other sites More sharing options...
+9640News Posted December 19, 2022 Share Posted December 19, 2022 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.