Jump to content
InsaneMultitasker

Funnelweb and DSKU fix - CF7/nanopeb

Recommended Posts

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 by InsaneMultitasker
  • Like 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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$

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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 by RXB

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

I don't think the strings cross sector boundaries... let us know what you find out icon_smile.gif

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

  • Thanks 1

Share this post


Link to post
Share on other sites
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!  

  • Like 1
  • Haha 1

Share this post


Link to post
Share on other sites

 

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.  :D

 

 

Share this post


Link to post
Share on other sites
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.  :D

 

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

  • Like 2
  • Thanks 1

Share this post


Link to post
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.

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