erichenneke Posted September 26, 2015 Author Share Posted September 26, 2015 A simple way might be to just link the data as segment at the begin of AUTORUN.SYS (runtime). I check the segments and the area $8000.... appears to be unused. A short test also worked. AUTORUN.SYS: <your segment starting at $8000> <original content of autorun.sys) Thanks JAC! However, I will need a bit more hand holding on this I am afraid. Excited to learn more about this though! So, right now I have the data in a file called BPT.XEX. I created BPT.XEX by loading the data I needed into memory and then using TBXL BPUT command to copy the correct portion of memory to the BPT.XEX file. Then I use a BGET in my TBXL game program to load the data from BPT.XEX back into the correct memory location each time it executes. Given that context, I have some questions about the approach you are describing... 1) What is the best way to edit the existing AUTORUN.SYS file? I have never done that before. I see you have it open in Eclipse, but I am not sure how i would go about opening the AUTORUN.SYS and edit/modify it. 2) You say to "link the data as a segment at the beginning of AUTORUN.SYS" and you propose location $8000. Again, this is new ground for me so how do I "link the data as a segment" ? Remember, the data I want to load is currently in a file called BPT.XEX and it needs to be loaded into a specific location of memory to work properly in the program. My goal is to have everything in one single file ( the TBXL runtime, the compiled TBXL CTB program itself, and the data that is currently in BPT.XEX file ). I am really interested in trying this and learning something new! thanks, Eric Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted September 26, 2015 Share Posted September 26, 2015 Hmmm, think you can use: a) copy+append on the A8 with DOS, i.e. copy your BPT.XEX onto another disk or drive and name it e.g. Autorun.SYS, then copy Autorun.SYS onto another disk or drive and add /A for append mode - you should now have a longer Autorun.SYS file that also contains your BPT.XEX file; example: step 1) COP D1:BPT.XEX,D2:Autorun.SYS; step 2) COP D1:Autorun.SYS,D2:Autorun.SYS/A; b) use a Packer+Linker on the A8 or PC, e.g. Superpacker by Bewesoft on the A8 or Superpacker by TeBe on the PC. After the packer has loaded, load in your XEX file, then load the Autorun.SYS file and at the end save everything as a new file. Since you did not pack the data, you just linked it (copied it) together into one file... Well, thats how I do it. There are several other ways I guess... Quote Link to comment Share on other sites More sharing options...
erichenneke Posted September 27, 2015 Author Share Posted September 27, 2015 Hmmm, think you can use: a) copy+append on the A8 with DOS, i.e. copy your BPT.XEX onto another disk or drive and name it e.g. Autorun.SYS, then copy Autorun.SYS onto another disk or drive and add /A for append mode - you should now have a longer Autorun.SYS file that also contains your BPT.XEX file; example: step 1) COP D1:BPT.XEX,D2:Autorun.SYS; step 2) COP D1:Autorun.SYS,D2:Autorun.SYS/A; b) use a Packer+Linker on the A8 or PC, e.g. Superpacker by Bewesoft on the A8 or Superpacker by TeBe on the PC. After the packer has loaded, load in your XEX file, then load the Autorun.SYS file and at the end save everything as a new file. Since you did not pack the data, you just linked it (copied it) together into one file... Well, thats how I do it. There are several other ways I guess... I tried (a) using the DOS append. It looks like it did append the files but gets an error 170 when executed. I assume this is become the code is still looking for the D:BPT.XEX file ( which I intentionally deleted to make sure it wasn't still using it... which, clearly it is still trying to do ). Seems I am still missing a step to make this approach work? I tried out the SuperPacker from Bewesoft of the A8 but it just gives me an error 130 no matter what i do ( Directory, load DOS file, etc. ) So, then i tried Superpacker on the PC. I loaded the BPT.XEX, then the Compiled TBLX file executable, and saved it all. It will run only if I have the separate BPT.XEX file available, so clearly it also is still looking externally for the BPT.XEX file. Again, seems I am missing a key step in the process? Quote Link to comment Share on other sites More sharing options...
erichenneke Posted September 27, 2015 Author Share Posted September 27, 2015 Hey, i was going to attach a couple of stub programs as examples to show exactly what I am trying to do, but I no longer see an option to add an attachment to my post. I know I previously had added attachments here. How do I add an attachment so you can see the example I am talking about? thanks!!! Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted September 27, 2015 Share Posted September 27, 2015 (edited) Does your data file begin with FF FF (Start Adr Lo) (Start Adr Hi) (End Adr Lo) (End Adr Hi), then the actual data bytes? See this: http://www.atarimagazines.com/compute/issue71/insight_atari.php Edit: It's called a Binary Header. Also, if you load the data this way, there is no need for the OPEN/BGET/CLOSE stuff. Edited September 27, 2015 by Kyle22 Quote Link to comment Share on other sites More sharing options...
erichenneke Posted September 27, 2015 Author Share Posted September 27, 2015 Here I am attached a couple of simple test files to mimic the exact same thing I am trying to accomplish with my actual program files. LINKSEG.XEX is just a very simply compiled TBXL (turned into an executable using the TBLINKER utility) that loads data from the second file called HELP.OUT and prints the data to the display. My goal is to get this all into one single file. actually, it is only letting me attach the LINKSEG.XEX file. I will try to post the HELP.OUT file in another post. linkseg.xex Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted September 27, 2015 Share Posted September 27, 2015 If you would ARC (preferably) or ZIP all the necessary files, it would be helpful. You may attach either ARC or ZIP files. Quote Link to comment Share on other sites More sharing options...
erichenneke Posted September 27, 2015 Author Share Posted September 27, 2015 (edited) Kyle! Many thanks, the binary header was the key! I had created my data file using TBXL BPUT and then I was reading it back in using BGET, so there was no header involved and with that approach it didn't matter. But to append it all into one executable and eliminate the need for the "BGET stuff" (as you said ) I had to add the header data at the beginning of the file. Edit: After that, using SuperPacker (PC version) worked like a champ! Learned something new today. Excellent. Thanks again !! -Eric Edited September 27, 2015 by erichenneke 1 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted September 27, 2015 Share Posted September 27, 2015 Well, I am no programmer, so I guess the Error 170 appears, because your program still has the RUN"D:BPT.XEX" somewhere in the code and the program (even after linking/appending with other files) still searches for that file... But you already know that you want to "load" the BPT.XEX file into memory adress $8000, so I think you have to remove the RUN"D:BPT.XEX" from your TB XL code and add new code instead, that will simply access data from $8000 (because the data is already there and there is no longer a need to load/run an external file)... Quote Link to comment Share on other sites More sharing options...
erichenneke Posted September 27, 2015 Author Share Posted September 27, 2015 Well, I am no programmer, so I guess the Error 170 appears, because your program still has the RUN"D:BPT.XEX" somewhere in the code and the program (even after linking/appending with other files) still searches for that file... But you already know that you want to "load" the BPT.XEX file into memory adress $8000, so I think you have to remove the RUN"D:BPT.XEX" from your TB XL code and add new code instead, that will simply access data from $8000 (because the data is already there and there is no longer a need to load/run an external file)... Yes, that's what it was. And the key piece I was missing was the binary header information that Kyle22 called out. After including the binary header I was able to remove the BGET D:BPT.XEX from the program completely. And then the process "b" that your described worked great using superpacker. Thanks so much! -Eric 1 Quote Link to comment Share on other sites More sharing options...
erichenneke Posted September 27, 2015 Author Share Posted September 27, 2015 Yes, that's what it was. And the key piece I was missing was the binary header information that Kyle22 called out. After including the binary header I was able to remove the BGET D:BPT.XEX from the program completely. And then the process "b" that your described worked great using superpacker. Thanks so much! -Eric By the way Charlie, I still wasn't able to get the "a" approach you described working where you suggested to use DOS COPY and then DOS COPY with /A to append the data binary(with appropriate binary headers included) with the compiled executable to create a new executable file. That approach still doesn't work for some reason, but it does with Superpacker. -Eric Quote Link to comment Share on other sites More sharing options...
1050 Posted September 29, 2015 Share Posted September 29, 2015 Just some advise on perhaps related subjects I'd like to inject here and not at all up to speed on the complete subject either with zero experience with SuperPacker too. BUT all autorun.sys files should be scoured to remove (convert to INITAD - 02E2h?) any reference to setting the RUNAD vector at 02E0h as this vector is already loaded to fire up DUP.SYS when done loading autorun.sys files. Of course you can use this very technique to do as you want, I'm only here to let you know that it is already in use and to advise you to stay away from it for the most part for general use. Autorun.sys files should then only use the INITAD vector loaded at 02E2h for running/installing their code and this is the normal way to do it and wind up looking at a DUP.SYS menu screen. Unless you want something else to happen. Far too many do not have this basic knowledge and their autorun.sys file stacks created by DOS copy /A then do not work as expected - I'm trying to avoid that pitfall here. Autorun.sys files are a powerful tool to be mastered and more should be masters of them rather than walking away from the technique defeated only by a lack of basic knowledge on the subject. DOS copy /A works backwards in that the first file in the list is appended to the end of the last file in the list and the combined file now has the last file name in the list. Which also means that the last file is now 'ruined' and no longer exists as it used to be - Only the first file remains as it was before this append operation. You should then be using the last file in the list and not the first one named... This only becomes obvious when you know that it's the last file that is the appended one. Another Gotcha to look out for there. And then of course what you want to happen first should then be made last in the list, AND the very last to be appended if you are appended more than two files with two (or more) append operations, say are we having fun yet? Different DOS do this differently, MyDOS will NOT use a second pair of double FF in the file header for the appended file, but DOS 2.0 will keep the double FF file header intact in the appended file, and at the same time make it happen starting on a new sector on the destination disk. MyDOS will use a short sector approach and eliminate the unused sector information between the two files, storing the appended results as tightly as possible. You want to get tricky, you can use this dead sector space in DOS 2.0 to hold undocumented data. But MyDOS may contract the information if it is used for a simple file copy. Hoping I didn't confuse too much? Also hope my memory is up to snuff. Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted September 29, 2015 Share Posted September 29, 2015 By the way Charlie, I still wasn't able to get the "a" approach you described working where you suggested to use DOS COPY and then DOS COPY with /A to append the data binary(with appropriate binary headers included) with the compiled executable to create a new executable file. That approach still doesn't work for some reason, but it does with Superpacker. -Eric Well, it is really easy. Attached you will find two examples with copy+append mode. Example 1 shows Turbo-DOS copying+appending (append1.jpg), Example 2 shows a DOS 2.x variant copying+appending (Append2.jpg + Append3.jpg)... copy+append with TurboDOS copy+append with DOS 2.x, step a copy + append with DOS 2.x, step b Quote Link to comment Share on other sites More sharing options...
erichenneke Posted October 1, 2015 Author Share Posted October 1, 2015 Well, it is really easy. Attached you will find two examples with copy+append mode. Example 1 shows Turbo-DOS copying+appending (append1.jpg), Example 2 shows a DOS 2.x variant copying+appending (Append2.jpg + Append3.jpg)... append1.jpg copy+append with TurboDOS append2.jpg copy+append with DOS 2.x, step a append3.jpg copy + append with DOS 2.x, step b thanks! Yep, I was doing it ass backward. 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.