Tursi #26 Posted 23 hours ago (edited) 8 hours ago, senior_falcon said: If I understand this correctly, you can do the equivalent of CALL FILES(1) and put all the disk information so that nothing above >1FFF is used at all. The downside to this is that the stack space will be reduced by 529 bytes. Normally there are 1460 bytes of stack space available; reducing that by 529 is a deal breaker. That's just a number I chose - choose whatever values work for you. (edit: most of the CF7 is the standard TI DSR... so these statements are also true for it. They start with whatever is in >8370 when the powerup routine is called. This allows for multiple cards to reserve VDP RAM space. It just so happens that we all took what the TI Disk Controller did as the only gospel ) Edited 23 hours ago by Tursi Quote Share this post Link to post Share on other sites
senior_falcon #27 Posted 19 hours ago (edited) 7 hours ago, Lee Stewart said: The TI disk controller specs require(?) an additional buffer for one Volume Information Block (VIB) + other stuff for a total of 534 bytes. That plus one buffer (518 bytes) for one open file would seem to require starting one byte above >3BE3 - (>3FFF - >1FFF) = >3BE3 - >2000 = >1BE3 rather than >1DF3. How do you get away with room for only one buffer? ...lee The VDP stack area, (252 bytes) Disk drive info (4 bytes) , ??(6 bytes),Volume information block(256 bytes) and file name compare buffer (11 bytes) normally start at >3DEF and run to >3FFF. These are perfectly happy when left in their original location. Only the 5 byte header and 518 byte buffers have to be moved. I have no idea why this works, but it does, at least on the TI controller. As I remember, this technique did not work so well with the Myarc controller. The locations seemed to be hard coded. But it was still usable for 1 disk file and with some VDP shuffling I could get 2 disk files. Edited 18 hours ago by senior_falcon 1 Quote Share this post Link to post Share on other sites
senior_falcon #28 Posted 18 hours ago If I understand the previous comments, there are 8 bytes inserted at >3FF8 to >3FFF used by the CF7. Then (for CALL FILES(3)) everything that is normally loaded from >37D8 to >3FFF is loaded 8 bytes lower in memory. So at >37D0 are the bytes >AA,>3F,>FF,>11,>03 Is this correct? Quote Share this post Link to post Share on other sites
Tursi #29 Posted 16 hours ago 2 hours ago, senior_falcon said: If I understand the previous comments, there are 8 bytes inserted at >3FF8 to >3FFF used by the CF7. Then (for CALL FILES(3)) everything that is normally loaded from >37D8 to >3FFF is loaded 8 bytes lower in memory. So at >37D0 are the bytes >AA,>3F,>FF,>11,>03 Is this correct? Yes (though the >11 is >10 in Classic99, as that's the CRU base of the disk device that created the buffer). Quote Share this post Link to post Share on other sites
senior_falcon #30 Posted 52 minutes ago I may have found the reason the CF7 doesn't work with The Missing Link. Upon startup, TML moves the disk buffer(s) and then clears the VDP graphics tables above the disk buffers. I don't remember why I did it this way, but VDP is cleared all the way up to >3FFA. This overwrites the >AA03 header at >3FF8. Tursi didn't see that the header was checked by the DSR, but if it is, then that would explain why the CF7 does not work. I will have a new test program to post in the next day or two. The answer is binary-either it works or it does not. If not then I don't think there is anything else that can be done. 1 Quote Share this post Link to post Share on other sites