tschak909 Posted January 27, 2021 Share Posted January 27, 2021 @Mathy What is the convention for autorun files under 4.55 beta 4? Calling something autorun.ar0 doesn't seem to work... -Thom Quote Link to comment Share on other sites More sharing options...
+Stephen Posted January 27, 2021 Share Posted January 27, 2021 1 1 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted January 27, 2021 Share Posted January 27, 2021 Sorry - was just having fun with this original (NSFW) - google image search it Quote Link to comment Share on other sites More sharing options...
1050 Posted January 27, 2021 Share Posted January 27, 2021 Autorun files only ever did work if you call the INIT vectors at 0x02e2-0x02e3 at the end of the autorun file itself. It's not an autorun file if it's using the RUN vectors at 0x02e0-0x02e1 which are not allowed and just won't ever be processed. It's on you to make sure your autorun files comply with both these autorun rules. Not a MyDOS thing BTW. But it does comply to those strict pre-existing rules. So it's likely most have never even heard about those rules mainly because they don't use autorun files much. It's no big thing either way. Anyfile.ar0, anyfile.ar1, anyfile.ar2 work fine if the files are correctly vectored as actual autorun files. I guess we could have broke the mold and called them autoinit files instead? 1 Quote Link to comment Share on other sites More sharing options...
Mathy Posted January 28, 2021 Share Posted January 28, 2021 @tschak909 Hello Thom 21 hours ago, tschak909 said: @Mathy What is the convention for autorun files under 4.55 beta 4? Calling something autorun.ar0 doesn't seem to work... 17 hours ago, 1050 said: Autorun files only ever did work if you call the INIT vectors at 0x02e2-0x02e3 at the end of the autorun file itself. It's not an autorun file if it's using the RUN vectors at 0x02e0-0x02e1 which are not allowed and just won't ever be processed. It's on you to make sure your autorun files comply with both these autorun rules. Not a MyDOS thing BTW. But it does comply to those strict pre-existing rules. So it's likely most have never even heard about those rules mainly because they don't use autorun files much. It's no big thing either way. Anyfile.ar0, anyfile.ar1, anyfile.ar2 work fine if the files are correctly vectored as actual autorun files. I guess we could have broke the mold and called them autoinit files instead? What he says! 1050 knows MyDOS better than I do. Sincerely Mathy Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 28, 2021 Author Share Posted January 28, 2021 Seems to work fine under MyDOS 4.53, but whatever. -Thom Quote Link to comment Share on other sites More sharing options...
1050 Posted January 28, 2021 Share Posted January 28, 2021 So that's interesting. Have you tried autorun.sys as the file name? Please do. If it loads then that means somehow you have the wrong DOS.SYS while beta 4 DUP.SYS is giving you a fake news menu screen. It can occur rarely that DOS.SYS from one version is hooked up with DUP.SYS of another version. This is usually avoided with the ATR distribution method, but it's not perfect by far. And mistakes can still be made. Especially when H. Write DOS files to the boot device isn't done at that appropriate time needed. The code from 4.53 in this area of DOS.SYS is the same and is the source for 4.55 beta 4 so I'm at a loss to explain it so far. And first instance of this complaint so thanks for the bug report. 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 28, 2021 Author Share Posted January 28, 2021 See here, 4.53 and 4.55, with 4.53, the NDEV driver boots. MyDOS 4.53.atrMyDOS 4.55 beta 4.atr Quote Link to comment Share on other sites More sharing options...
Jacques Posted January 28, 2021 Share Posted January 28, 2021 Using the ocassion, I'd like to ask if there's a way to prevent autoloading of .ar* files by MyDOS, e.g. via pressed key or something to get to MyDOS menu instead? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted January 28, 2021 Author Share Posted January 28, 2021 can we please not hijack the thread? -Thom Quote Link to comment Share on other sites More sharing options...
1050 Posted January 30, 2021 Share Posted January 30, 2021 Ok, it is genuinely broke. This beta 4 wants .ar1 because it did load ar0 at one time before, incremented and tried again but didn't find that file and then got H. Write DOS files to the boot disk preset to start looking for .ar1. I was not aware this could be an issue but it does need some correction somewhere so this doesn't happen again. Strange cure is to do M. Run at Address 07E0 and then H. Write DOS files to D1: and you should be good to go. I still don't have a good clue how this happened, but clearly resetting the extension to zero needs to also be done when H. Write DOS files to disk is done. Next version release will have it. A genuine bug - well done. As to blocking the autorun with a keypress, it will take some cogitation with MyRD in mind and how to keep one from messing with the other since there are already bootup keypresses at work with MyRD.ar0. But I'll keep it in mind for the next version release as well. 1 1 Quote Link to comment Share on other sites More sharing options...
+Larry Posted January 30, 2021 Share Posted January 30, 2021 @1050 I'm curious... My usual use for autorun is to load the MyDos ramdisk. I'm running Beta 4 using RAMDISK.AR0, and it works fine. I've also tested the 4.55/4 that was patched by Jon for the 65816 use, and it also works with .AR0. Maybe there is a bad version in circulation? Posting as a DCM would help prevent errors, maybe? (I say that because Puff's 4.50 is a DCM and it can't be corrupted inadvertently.) Quote Link to comment Share on other sites More sharing options...
Mathy Posted January 30, 2021 Share Posted January 30, 2021 Hello Larry 58 minutes ago, Larry said: I'm running Beta 4 using RAMDISK.AR0, and it works fine. I've also tested the 4.55/4 that was patched by Jon for the 65816 use, and it also works with .AR0. Why was 4.55/4 created? There is no need for a /3 or a /4 version. The minimum sector count length can be set using menu option "O". RAMDISK.AR0 has some bugs. Sincerely Mathy Quote Link to comment Share on other sites More sharing options...
+Larry Posted January 30, 2021 Share Posted January 30, 2021 Yes, I'm aware of the discussion of bugs in the MyDos ramdisk code. Yet, I've never had an issue, so I continue to use it. I did show one time that it is inadvertently capable of formatting your D1:, but never has happened in normal usage. I've used all of the common 4.5x MyDos versions and never seen much difference. I guess I use 4.55/B4 because it is the last one out and presumably has fewer bugs. (?) Quote Link to comment Share on other sites More sharing options...
1050 Posted January 30, 2021 Share Posted January 30, 2021 Well, I've never had the problem either, but tschak909's disk is quite large and stuffed to the gills with many items. Somewhere along the line, he wrote DOS files back to the boot disk after it found and ran a proper autorun file. I'm thinking it's just this one disk, this rare time that the issue has finally come up. But it's a very real issue. So doing M. Run at Address 7e0 is the same as doing a DOSINI run and in that string of code is where David reset the number for the ar0 series back to zero. I did the same, it should instead be upon failing to find the next ar0 series or completion of loading the last one possible ar9. Never thought about it to be honest but without doing it right, it's kinda dirty code in need of a fix. 3 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted January 30, 2021 Share Posted January 30, 2021 (edited) ok, so writing DOS out after testing Each function and writing DOS out after a session testing All functions sounds like a very good procedure indeed. Doing a compare will definitely show things have changed weather on purpose or on mistake. (attempt is to explain what's happening & that doing it shows what's modified either on purpose or by accident, hope it's helpful to other learners) Edited January 30, 2021 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
1050 Posted January 30, 2021 Share Posted January 30, 2021 Looking around to see where and how I might fix this, I come to a conclusion. I'm all wet about my suggestions so far. The first thing David does is reset the ar0 count to zero before he ever runs the autorun file load during the DOSINI run. So it doesn't matter what the number is as stored on the boot disk - it's getting set to zero anyway. Which leaves the only possibility of being that something tschak909 is doing has affected the STATE equate at 0x07BE to the effect of doing a warmstart bypass to DUP.SYS screen and it doesn't run the load autorun file because it thinks it already has done that even on an actual cold start. Which is the weird part, STATE on his disk is the same as a "normal" disk and I can't fathom how it's getting changed around on the fly. Especially before he gets to even run his autorun file... Somewhere DOS.SYS has been corrupted somehow??? It's looking like my short term solution would be to build a 2nd work disk but not from/with this DOS.SYS - DUP.SYS pair. Get those files from a "clean" new source and copy only the other files over to the new disk. This is a deep mystery to me at this time. Quote Link to comment Share on other sites More sharing options...
1050 Posted February 1, 2021 Share Posted February 1, 2021 On 1/27/2021 at 6:13 PM, tschak909 said: See here, 4.53 and 4.55, with 4.53, the NDEV driver boots. MyDOS 4.53.atr 90.02 kB · 5 downloads MyDOS 4.55 beta 4.atr 719.64 kB · 9 downloads Eventually I find the ar0 file on the disks is NOT an autorun file as depicted in post #4 as I first suspected and suggested. You were supposed to hop right up and fix that right away... David wrote a broken MyDOS that loads and runs anything for autorun files and is the only type 2 AtariDOS that will do that. I see no reason to change anything. You just need to fix your files to the standard. Here is the fixed ar0 file. NDEV.AR0 And here is the original NDEV.BAK See if you can spot the difference and then realize why a good hex editor is handy. The reason one doesn't want that behavior is due to the fact that the RUN vector is only run when the IOCB block is finally closed if that mode is allowed and the INIT addresses are run during the load process at each sector of the incoming file. This will lead to out of order code running and would make this mess look like a piece of cake - which is it is in fact. In the old days, they built their single autorun files like a swiss clock and with care and things worked out fine. But it takes detailed work fraught with additional problems of sector lengths and file endings needing to be whole sectors or the last half of the sector of the next autorun function wanted could be trashed by the INIT run. David's brilliant cure to that insane nightmare is the ar0 method with incrementing file names, but then he does the load in the wrong mode. One of the many reasons I just stole his some of his ideas and not his code. 2 1 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.