Heaven/TQA Posted April 14, 2014 Share Posted April 14, 2014 I am searching for a device independent relyable loading counter (e.g. sector counter while loading) I tried VBL (using deferred one 548,549) to look at the DCB $30a,$030b but this works under Altirra differently than under Atari800win... I am using xBOOT to load parts of the demo but I can not patch the "jsr load_sector" routine to adjust the loading counter on screen. Any ideas? in a perfect world device independend "observer" solution Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 14, 2014 Share Posted April 14, 2014 Fairly sure the Altirra Boot option on XEX just injects it into RAM and probably does nothing to the DCB area. Even with real machine you can't depend on sector # since absolute sector doesn't relate to how long to go, plus you have the 128, 256, even 512 byte sector arrangement. I've thought about it, other ways but with various downsides: - short segments that update a counter (bloats file) - have VB routine keep an eye on RAM, when it changes, update pointer, decrement count Possibly the watch RAM method might be best. Clear the area first, then just OR a few bytes together. Not too much CPU time, and keeps a reasonably accurate counter. Then comes the counter itself - you don't know how big the file is, so you have to hard-code it. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 14, 2014 Author Share Posted April 14, 2014 I am anyway on ATR... what I am doing at the moment is watching $30a,$30b if that have changed and decrease counter on screen... sector loading of xBoot is via $e453... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 14, 2014 Author Share Posted April 14, 2014 well... actually I could patch the JSR $e453 haha... Quote Link to comment Share on other sites More sharing options...
xxl Posted April 14, 2014 Share Posted April 14, 2014 new test version of xB in default settings is device independent. now, with binary relocator to place xB in any memory area it is better solution than xBOOT. http://www.atari.org.pl/forum/viewtopic.php?pid=184631#p184631 and better check the amount of data loaded than look at sector which has been read. with xB you can use xBIOS_GET_FILE_OFFSET on VBI (you can convert to how much left to load) 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 14, 2014 Share Posted April 14, 2014 That's pretty impressive if it's got standard SIO activity going on. Thinking some more, maybe monitoring the DCB could work out. You could probably determine the sector size in use - in the case of an "emulator/injected load" they tend to happen so quick anyway that you don't need any counter going on. A VB would only need to detect change of the DAUX bytes then decrement the count - the careful bit of course is not using too much time as it might break at higher SIO speeds. Also, there's the modified Bresenham line-draw algorithm which I like... you can use it to generate the growing bar style progress indicator. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 14, 2014 Author Share Posted April 14, 2014 quick hack will be replacing JSR DSKINV ($e453) to JSR SHOW_BAR where SHOW_BAR updates the progress bar while jumping then to the OS routine. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 14, 2014 Author Share Posted April 14, 2014 works... I patched the JMP DSKINV in xboot to my routine and then from there back into OS. Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted April 16, 2014 Share Posted April 16, 2014 (edited) Hmm, which Xboot do you use: a) Xboot by FoX (which creates awkward, irregular, incompatible, shortened ATR images) or b) Xboot by XXL (based or derived or whatever from Xbios) ?!? -Andreas Koch. Edited April 16, 2014 by CharlieChaplin Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 17, 2014 Author Share Posted April 17, 2014 xBoot not XBOOT... so actually the one by XXL... next time it will be xBIOS... but time run out in terms of testing etc... 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.