Jump to content
IGNORED

MyDOS 4.55 autorun?


tschak909

Recommended Posts

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?

  • Thanks 1
Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

@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.)

 

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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. (?)

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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 by _The Doctor__
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 2
  • Thanks 1
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...