jdg@elmgate.UUCP (Jeff Gortatowsky) (10/03/86)
Well after a bit of digging and disassembly my brother (a sharp troop)
found the correct combination to get the reset surviving RAM disk to play
as drive F: in a HD system (Atari 20meg). I don't have the code right now
handy but will post it this weekend (the hex file again or uuencoded). In
essence the patch was applied to two places. First, as was mentioned
before on this news group you need to change the bit set in the 'drivebits'
variable down in low memory. The BSET #3,d0 needs to be BSET #5,d0 (for
drive F:). The other patch is applied to the compare instruction in the
code that is executed when RWABS calls the RAM Disk. The RAM disk checks
the device number and if it's not the right number it passes control
through a JMP instruction to the Hard disk vector the RAM disk saved at
boot time. As I said I can't remember off the top of my head what the
exect CMP instruction is and what it must be changed to, but you should be
able to find it. If not, just wait for the posting. The above patches
imply that the RAM disk need be executed after the hard disk driver is
installed, so it may take over and save the hard disk vectors.
Anyways they are both living happily in the system. 1 360k drive A:, 1
720k drive B:, 1 4meg drive C:, 1 6meg drive D:, 1 10meg drive E:, and 1
500k drive F:. Veerrrry Niiice!
--
Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg
Eastman Kodak Company
<Kodak won't be responsible for the above comments, only those below>FISCHER-MICHAEL@YALE.ARPA (10/06/86)
Well after a bit of digging and disassembly my brother (a sharp troop)
found the correct combination to get the reset surviving RAM disk to play
as drive F: in a HD system (Atari 20meg). I don't have the code right now
handy but will post it this weekend (the hex file again or uuencoded). In
essence the patch was applied to two places. First, as was mentioned
before on this news group you need to change the bit set in the 'drivebits'
variable down in low memory. The BSET #3,d0 needs to be BSET #5,d0 (for
drive F:). The other patch is applied to the compare instruction in the
code that is executed when RWABS calls the RAM Disk. The RAM disk checks
the device number and if it's not the right number it passes control
through a JMP instruction to the Hard disk vector the RAM disk saved at
boot time. As I said I can't remember off the top of my head what the
exect CMP instruction is and what it must be changed to, but you should be
able to find it. If not, just wait for the posting. The above patches
imply that the RAM disk need be executed after the hard disk driver is
installed, so it may take over and save the hard disk vectors.
There are actually two more places that the drive number is used: in
the code that is executed when GETBPB (get bios parameter block) is called
and the code that is executed when MEDIACH (media change) is called.
Also, I believe that the hard disk driver thinks it owns drives C:, D:,
E:, and F:, although perhaps it gives up control of F: if you are not
using that partition. The safe thing is to install the ramdisk as
something > F:.
Anyways they are both living happily in the system. 1 360k drive A:, 1
720k drive B:, 1 4meg drive C:, 1 6meg drive D:, 1 10meg drive E:, and 1
500k drive F:. Veerrrry Niiice!
Have you done a SHOW INFO on drives D and F? If indeed you forgot to
correct the device number comparison for the GETBPB call, then I would
expect both to be incorrect: GETBPB calls for drive D would be
intercepted by the ramdisk driver and show a size of only 500k, whereas
calls for drive F would be passed on to the hard disk driver, which
would do who-knows-what. Perhaps your brother actually fixed all three
calls.
--Mike Fischer <fischer@yale.arpa>
-------