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 1

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

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 3

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

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