tekscsi.device fix for GVP 2040/2060 (and possibly T-RexII)
by Doobrey <doobrey@doobreynet.co.uk>

Fixes a bug in tekscsi.device that stops it loading a filesystem from the RDB. Now you can boot from a SCSI drive using SFS or PFS3 (no more boring, slow FFS ..yay!)

What you need:
- A GVP 2040 or GVP 2060 card
- Replacement EPROM(s) and programmer

Instructions:

First check what type of ROM chips are on the card.
2040/2060 has either 2x 27C256 (DIP) or 2x 27C512 (DIP) in sockets U11&U12
T-Rex II has 1x 27C256 (PLCC) in socket U12 (by the SCSI connector)

Then run tekscsifix from a CLI to read the original ROM and create a fixed version.

Command line args: tekscsifix FileName ROMtype [DOUBLE]

e.g. if you have a 2060 with 2x 27C512 chips you'd use:

    tekscsifix FileName=ram:example.rom ROMtype=27C512 DOUBLE

or for a T-Rexx II:

    tekscsifix FileName=ram:example.rom ROMtype=27C256

Using the 'DOUBLE' keyword, tekscsifix will produce two ROM images,
example.rom.HI and example.rom.LO
On the 2040/2060, the 'LO' rom goes in socket U11, and 'HI' to U12.

Finally take the patched ROM image(s) and burn them to new EPROM(S), and swap them over... obviously taking care to power down the Amiga, and taking anti-static precautions etc.!

Why 'possibly T-Rex II' ?

It too has a tekscsi.device in its ROM, and suffers from the 'FFS or nothing' bug. It's most likely the same bug, but without seeing a ROM dump I can't say for sure. Anyway, if you have a T-RexxII, just run the fix as described above, it'll tell you if it found and fixed the bug or not.

Now the boring stuff for those that are interested.. The bug is very simple, two instructions were the wrong way around, the first instruction changing an address register that the second instruction needed to use. In simple terms, it can't load in a filesystem from disk as it's using a bogus sector size value because it never reads the right amount of data.

Assembly stuff for the even more interested...

...comes here after succesfully finding a 'FSHD' (Filesystem Header Block) in the RDB
  Registers: a5= *iorequest, a4= *unit
  
  movea.l ([20,a5],10),a4   ;-- a4 is now a string pointer to the device's name
  move.l  72(a4),d6         ;-- d6 is *supposed* to be the unit's sectorsize
                            ;   but a4 was changed and no longer points to the unit struct!

So the solution was simple... swap these two instructions around. Sounds easy? it is once you've found the damn problem... ;)

Disclaimer

This fix comes with with no guarantees, use at your own risk, yadda yadda, Not responsible for damages, loss or sudden urges to dance to Justin Bieber, blah blah...

Thanks to Damion Diehl, for taking the time to test this patch out.