+InsaneMultitasker Posted March 6, 2013 Share Posted March 6, 2013 (edited) Here is the problem and solution I posted to the Yahoo Forums a few years ago. Be aware that the CF7/nanoPEB and other devices (ie, disk controllers) use VDP RAM which might not be reserved in emulation/simulation. I didn't specify a FWEB version in my original post, but I am fairly certain I based this on v4.40. IIRC, the v5.0 release is limited to editor and other non-loader files. FWEB PROBLEM OVERVIEW: 1. The CF7+ device stores 8 bytes of volume control data starting at VDP address 0x3ff8. 2. The CF7+ mimics the TI Disk controller, and uses VDP RAM for its IO operations. 3. A TI Disk Controller reserves VDP memory 0x37d8 to 0x3fff. 4. A CF7+ device reserves VDP memory 0x37d1* to 0x3fff. 5. TI and CF7+ both contain a 5 byte header at the beginning of this VDP RAM. When FWEB launches it reads the first available VDP address from location 0x8370. It then re-creates the header in RAM, writes it to VDP, and clears the controller-reserved VDP memory with the exception of the header. In the case of the CF7+, this is 0x37d7 to 0x3fff. Because the CF7+ device uses 8 bytes to keep track of its volume info but does not "hide" them from other programs, FWEB is able to unwittingly create a condition where the CF7+ can no longer find ivolume information. Essentially, the device gets lost and can no longer access disks, creating lockup and "file not found" conditions. FWEB PROBLEM FIX: We need to help FWEB to "properly" set the VDP pointers and inhibit its clearing the CF7+ volume info. To do this, use your favorite file editor to locate the following three HEX strings and modify as directed: 1. Find "1afb 0220 0010" and replace with "1afb 0220 0018" 2. Find "fa94 0220 fdea" and replace with "fa94 0220 fde2" 3. Find "0580 8800 fa94" and replace with "0580 0280 3ff8" All three changes should be located within the same sector. Note: There are THREE files requiring the changes. IIRC they are: FW, UTIL1 (or UT), and LOAD. DSKU 4.2 return to FW problem: After loading FW, DSKU clears PAD Ram from 0x8300 to 0x83C6. Doing so destroys 0x8370, the VDP Disk Buffer Area pointer, which creates a nasty situation for FWEB and the CF7. During powerup the TI sets this value to 0x37d7 (or 0x37cf for compact flash). DSKU 4.2 FIX: Within the file DU (first file) replace "0281 83C6" with "0281 8348". DSKU inhibits interrupts so any in-place ISR should not wreak havoc between loading the file and re-starting FW. (*Edit: 0x73d1 probably should read 0x73d0 to reflect the 8 byte difference) Edited March 7, 2013 by InsaneMultitasker 2 Quote Link to comment Share on other sites More sharing options...
Gazoo Posted March 7, 2013 Share Posted March 7, 2013 Here is the problem and solution I posted to the Yahoo Forums a few years ago. Be aware that the CF7/nanoPEB and other devices (ie, disk controllers) use VDP RAM which might not be reserved in emulation/simulation. I didn't specify a FWEB version in my original post, but I am fairly certain I based this on v4.40. IIRC, the v5.0 release is limited to editor and other non-loader files. FWEB PROBLEM OVERVIEW: 1. The CF7+ device stores 8 bytes of volume control data starting at VDP address 0x3ff8. 2. The CF7+ mimics the TI Disk controller, and uses VDP RAM for its IO operations. 3. A TI Disk Controller reserves VDP memory 0x37d8 to 0x3fff. 4. A CF7+ device reserves VDP memory 0x37d1 to 0x3fff. 5. TI and CF7+ both contain a 5 byte header at the beginning of this VDP RAM. When FWEB launches it reads the first available VDP address from location 0x8370. It then re-creates the header in RAM, writes it to VDP, and clears the controller-reserved VDP memory with the exception of the header. In the case of the CF7+, this is 0x37d7 to 0x3fff. Because the CF7+ device uses 8 bytes to keep track of its volume info but does not "hide" them from other programs, FWEB is able to unwittingly create a condition where the CF7+ can no longer find ivolume information. Essentially, the device gets lost and can no longer access disks, creating lockup and "file not found" conditions. FWEB PROBLEM FIX: We need to help FWEB to "properly" set the VDP pointers and inhibit its clearing the CF7+ volume info. To do this, use your favorite file editor to locate the following three HEX strings and modify as directed: 1. Find "1afb 0220 0010" and replace with "1afb 0220 0018" 2. Find "fa94 0220 fdea" and replace with "fa94 0220 fde2" 3. Find "0580 8800 fa94" and replace with "0580 0280 3ff8" All three changes should be located within the same sector. Note: There are THREE files requiring the changes. IIRC they are: FW, UTIL1 (or UT), and LOAD. DSKU 4.2 return to FW problem: After loading FW, DSKU clears PAD Ram from 0x8300 to 0x83C6. Doing so destroys 0x8370, the VDP Disk Buffer Area pointer, which creates a nasty situation for FWEB and the CF7. During powerup the TI sets this value to 0x37d7 (or 0x37cf for compact flash). DSKU 4.2 FIX: Within the file DU (first file) replace "0281 83C6" with "0281 8348". DSKU inhibits interrupts so any in-place ISR should not wreak havoc between loading the file and re-starting FW. Genius strikes again! I don't know how you do it. My bag of tricks is nearly empty compared to yours. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 7, 2013 Share Posted March 7, 2013 I had tried to get that fix done when you first posted it on Yahoo, but could not find the strings you mentioned... I'll double check my FW version tonight and try again. Thanks for posting this Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 7, 2013 Author Share Posted March 7, 2013 I had tried to get that fix done when you first posted it on Yahoo, but could not find the strings you mentioned... I'll double check my FW version tonight and try again. Thanks for posting this I don't think the strings cross sector boundaries... let us know what you find out Quote Link to comment Share on other sites More sharing options...
RXB Posted March 8, 2013 Share Posted March 8, 2013 Many years ago I suggested to Tony that he use a GPLDSR instead of a Assembly DSR as the GPL DSR will find and run fine. On the other hand the Assembly DSR will fail as it takes way to much for granted and fails. He wrote back and agreed but stated he thought it would be to little to late as he was not going to update FW anymore. With the Assembly at hand in the Package I put in the Miller Graphics GPL DSR instead of the included DSR and it worked. But when my SCSI drive failed I lost that package and a ton more stuff. Rich Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 8, 2013 Author Share Posted March 8, 2013 Many years ago I suggested to Tony that he use a GPLDSR instead of a Assembly DSR as the GPL DSR will find and run fine. On the other hand the Assembly DSR will fail as it takes way to much for granted and fails. He wrote back and agreed but stated he thought it would be to little to late as he was not going to update FW anymore. The problem with FW is fortunately unrelated to the DSR(DSRLNK) code and instead a factor of how F'web manages the video RAM to cope with the various controllers and boot tracking. I'm not sure where the GPL versus assembly DSRLNK would fail any differently, unless the programmer wasn't following proper convention. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 8, 2013 Share Posted March 8, 2013 A GPL DSRLNK will fail less often for a number of reasons. For example from a Cartridge input for a DSR it will always find the device. On the other hand from FW with RXB or PRK cart try to access a DSRLNK routine and it will fail, reason the DSR used. Same for Boot tracking as I have a Boot Tracking routine written in RXB that works fine. Does the same as FW does. 11 ! BOOT TRACKING IN RXB MERGE this program frist so your program knows which drive it loaded from last. *NOTE: NO ASSEMBLY USED!! 12 CALL PEEK(-31792,R,I,C,H) :: CRU=128*R+I :: CPU=256*C+H+5 :: CALL IO(3,8,CRU,255) :: CALL MOVES("R$",4,CPU,D$) :: CALL IO(3,8,CRU,0) 13 CALL MOVES("V$",20,2086,E$) :: PRINT "DEVICE:";D$:"PATH:";E$ Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 9, 2013 Author Share Posted March 9, 2013 A GPL DSRLNK will fail less often for a number of reasons. For example from a Cartridge input for a DSR it will always find the device. On the other hand from FW with RXB or PRK cart try to access a DSRLNK routine and it will fail, reason the DSR used. Can you provide a more specific example of what you are referring to? Are you pointing out that the standard DSRLNK only searches the peripheral cards from x1000 to x1F00 for devices and subprograms? (which is not a failure, btw) Quote Link to comment Share on other sites More sharing options...
RXB Posted March 10, 2013 Share Posted March 10, 2013 (edited) Basically a GPL DSR will find ANY DSR in GROM/GRAM/ROM/RAM and non GPL DSR will only find a ROM/RAM DSR. Actually a failure is if a DSR device exists in the system and it is not found by the DSR used, that would be a huge failure. Success is not defined as partial failure. To use a universal version that never fails to find any DSR device should be preferred over restricted one that only looks for a certain type. So if you are in Assembly ONLY this is fine but this also violates compatibility with many devices on purpose. This is just a logical fact. I would like to point out that the current TI community could care less about comparability with GPL and the Miller Graphics/Ryte Data version of GPL DSR. (Even if it is only takes a few more bytes for compatibility) But then I am always alone on this subject of anything remotely related to GPL, this is continually pointed out to me by a 99% Assembly community. Edited March 10, 2013 by RXB Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 10, 2013 Author Share Posted March 10, 2013 Rich, you haven't provided any specific examples. I asked for an example because I have not encountered any devices which the standard DSRLNK code will not find. It's not that I don't care about a GPL DSR. And I'm not trying to put GPL in a corner. I simply don't grasp what failures you refer to and what specifically doesn't work. Maybe we can close the gap with some examples. Quote Link to comment Share on other sites More sharing options...
RXB Posted March 10, 2013 Share Posted March 10, 2013 Oh, well here is a short video. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 10, 2013 Author Share Posted March 10, 2013 Thank you, Rich. I have never seen this sort of use before. Now even though I would not consider BASIC to be a device, I certainly see how it and similar calls/devices could be useful. I'll have to go back to my issues of The Smart Programmer to read about Millers Graphics code... 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 8, 2013 Share Posted November 8, 2013 I don't think the strings cross sector boundaries... let us know what you find out Well, I'm a bit late at responding here but I can confirm that I cannot find all the strings you mentioned... I only found the first one. Would you be willing to post a copy of your patched FW for testing? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 8, 2013 Author Share Posted November 8, 2013 Well, I'm a bit late at responding here but I can confirm that I cannot find all the strings you mentioned... I only found the first one. Would you be willing to post a copy of your patched FW for testing? If you have a disk image handy, PM it to me and I'll take a look. I moved most of my TI stuff to another room to avoid temptation as we are a more-serious-than-usual-work-crunch for the next few weeks. I will also check my folders for the image; I know someone had uploaded it to a site though I don't think it ever made it to WHT. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 8, 2013 Share Posted November 8, 2013 If you have a disk image handy, PM it to me and I'll take a look. Great! I'll send you my disk image tonight. Thanks! Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 10, 2013 Share Posted November 10, 2013 OK! Thanks to InsaneMultitasker's help, I've now got a patched version of FW 4.4 fully compatible with the CF7+/NanoPeb. This will really be a big help when developing on such a system. FW44_CF7.ZIP 5 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted November 23, 2019 Author Share Posted November 23, 2019 Much like this thread, I'm trying to resurrect my nano serial (v1) this weekend and running into trouble with some disk images including the one in post #16. Can anyone confirm the patched version Vorticon uploaded does work with a nano? It seems fine with my CF7+ so I'm guessing I have a hardware issue or that I'm not transferring the image successfully. 1 Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted March 30, 2020 Share Posted March 30, 2020 On 11/23/2019 at 12:00 PM, InsaneMultitasker said: Much like this thread, I'm trying to resurrect my nano serial (v1) this weekend and running into trouble with some disk images including the one in post #16. Can anyone confirm the patched version Vorticon uploaded does work with a nano? It seems fine with my CF7+ so I'm guessing I have a hardware issue or that I'm not transferring the image successfully. If I haven't posted again in a few days remind me - I'm just waiting for a longer list of volumes to send over to the nano's CF card, which I unfortunately have to do in Windows. I'll try to give Vorticon's image a thorough testing. Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted March 31, 2020 Share Posted March 31, 2020 Okay, so I managed to get over to Windows and loaded some volumes, including this patched FW44. DR (DiskReview) seems to be working fine, with no lockups. Is there anything else/anything specific you would like me to try out with F'Web on the nanoPEB, @InsaneMultitasker ? (Since I'd like to get it set up and tailored to my liking now that I have a working version, I'm sure I'll have at the very least an update to say everything has gone well ;)). 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 31, 2020 Author Share Posted March 31, 2020 11 hours ago, WhataKowinkydink said: Okay, so I managed to get over to Windows and loaded some volumes, including this patched FW44. DR (DiskReview) seems to be working fine, with no lockups. Is there anything else/anything specific you would like me to try out with F'Web on the nanoPEB, @InsaneMultitasker ? (Since I'd like to get it set up and tailored to my liking now that I have a working version, I'm sure I'll have at the very least an update to say everything has gone well ;)). If Disk Review works that is a good sign! 1 1 Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted March 31, 2020 Share Posted March 31, 2020 6 minutes ago, InsaneMultitasker said: If Disk Review works that is a good sign! Working like charm! :D 1 Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted April 6, 2020 Share Posted April 6, 2020 On 11/9/2013 at 8:15 PM, Vorticon said: OK! Thanks to InsaneMultitasker's help, I've now got a patched version of FW 4.4 fully compatible with the CF7+/NanoPeb. This will really be a big help when developing on such a system. I hate to be *that* guy, but I was wondering how involved it would be to patch the 80-column version of F'Web. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 6, 2020 Share Posted April 6, 2020 1 hour ago, WhataKowinkydink said: I hate to be *that* guy, but I was wondering how involved it would be to patch the 80-column version of F'Web. Very involved! I actually thought about doing this some time ago, but, after a cursory look at the ALC for Funnel-Web, I could see I was in for a lot more work than I wanted. I still may attempt it some day, but not anytime soon. The 80-column editor for Funnel-Web presumes use of a 9938 or 9958 VDP as is available in a Myarc EVPC card installed in the PEB. If it used the 9938/58 just for video, we could modify it to use the F18A without too much work, I think. But, unfortunately, it expects and uses the extra memory in the 9938/58 for text buffer space. Even if we could figure out how to convert Funnel-Web to use the extra memory in something like SAMS, I am not sure we can get a SAMS sidecar to work with the nanoPEB. It actually might be easier to modify the 40-column version to display 80 columns with the F18A than to try to modify the 80-column version. Either way, I think it will involve extensive editing of source code and re-assembling the relevant parts of Funnel-Web to work with the F18A. I cannot imagine that patching machine code has any chance of working. ...lee 2 1 Quote Link to comment Share on other sites More sharing options...
WhataKowinkydink Posted April 6, 2020 Share Posted April 6, 2020 Thank you for the clear and detailed explanation @Lee Stewart - good to know. ? 1 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted April 6, 2020 Share Posted April 6, 2020 I think you meant the Dijit AVPC card, Lee. 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.