+adamantyr Posted January 20, 2017 Share Posted January 20, 2017 Hey all, Here is a question... so the TI disk system reserves space at the top of VDP memory for file buffers. You can reduce this by from 3 file support to 1 by calling the FILES subprogram, but it still takes up space from about >3B00 onwards. My question is... can you safely wipe out this section, say if you wanted to put the sprite pattern table at >3800 onwards? Obviously it would trash the sprite pattern table if you had to do a file load later on, but if you could restore the data from CPU memory afterwards it seems alright. Obviously it would be stupid to try and do a memory image load INTO this section... Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 20, 2017 Share Posted January 20, 2017 You are probably safe as long as you have no plans to invoke a disk DSR after you trash it. However, if you place the sprite pattern table at >3800, you have room for 124 sprite patterns (123 for nanoPEB/CF7+) without trashing the file buffers, which, after declaring 1 file support starts at >3BE4 (>3BDC for nanoPEB/CF7+). ...lee Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted January 20, 2017 Author Share Posted January 20, 2017 So it won't rebuild the file section? You'd have to preserve what's at >3BE4 onwards and restore it? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 20, 2017 Share Posted January 20, 2017 My question is... can you safely wipe out this section, say if you wanted to put the sprite pattern table at >3800 onwards? Obviously it would trash the sprite pattern table if you had to do a file load later on, but if you could restore the data from CPU memory afterwards it seems alright. Obviously it would be stupid to try and do a memory image load INTO this section... Yes, we are doing that in the megademo. But I believe a more detailed analysis of what you need to save and restore could reduce the required amount of CPU considerably. We also use all of the scratch pad in the demo so we save and restore that as well, but it's probably only a few bytes that need to be restored for disk access to work. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted January 20, 2017 Author Share Posted January 20, 2017 Good to know... sounds like some experimentation will be needed. I'm irked that the MSX had the ENTIRE VDP to use without an issue... they must keep all their disk handling stuff in CPU. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.