Duodisk thinks all disks are write protected

I know nothing about the booti nor how it works on a hardware level. But... have you tried looking at the write protect switch readings? There are some of the disk diagnostics which will report back the reading of the switch.  I think computer inspector may be the easiest to find, but you'll need to make the disk first with ADTPro or AsciiExpress.  The IIe disk diangostics disk should also have a WP switch check. All the things you've spectulated on seem a little "off"  but unstable power can always cause random issues. It's totally possible the booti interferes with the WP signal (pin 10 on the 19-pin disk connector), but you'd expect was encountered in testing/use before if that is a common result.  WP could affect, but also be soemthing local to the drive and controller which is different from the booti. Do you have the latest booti firmware installed? If you have a second disk controller you may want to try swapping in another just as a sanity check. 

jeff d wrote:

I know nothing about the booti nor how it works on a hardware level. But... have you tried looking at the write protect switch readings? There are some of the disk diagnostics which will report back the reading of the switch.  [emphasis added]

A properly-functioning Booti wouldn't cause that sort interference on its own.  But cards in different slots will interfere with each other if there's a fault in the motherboard's LS154 line decoder (C10), in which case the //e itself could by caausing the Booti to interfere with the Disk II.  User tony359 documented how faulty line decoders in a Europlus caused exactly that sort of problem in this YouTube video, where one bad decoder caused IO conflicts and a second bad decoder caused ROM conflicts.

But @jeffd is absolutely right, the next step is to examine the write protect switch readings.  You can do that with these Monitor commands, and they may provide more detailed clues than running those diagnostic programs.  Follow these steps and make note (or share a picture) of what it prints on the screen:

1. First take all diskettes out of the DuoDisk completely.  (Diskettes wouldn't be harmed, but they would interfere with the WP sensor.)
2. At the  ]  prompt in BASIC, enter the command  CALL-151  to enter the Monitor.  This will change the command prompt to  *
3. At the  *  prompt, enter this command and check for typos before pressing return:  C0ED C0E9 I C0EA C0E8 N C0E3 I C0E2 N
4. The Monitor should print several lines of cryptic-looking numbers, three of them in inverse.  If drive 1's WP sensor is working correctly, the inverse lines should contain the numbers  00  and  00  and  7F .  See the picture below for how it should appear on the screen.
5. To check drive 2, enter this command:  C0ED C0E9 C0EB I C0E8 N C0E3 I C0E2 N
6. The Monitor should print several lines of numbers again, two of them in inverse.  If drive 2's WP sensor is working properly, the inverse lines should contain the numbers  00  and 7F .

(NOTE: These commands are tuned for an Apple //e with a DuoDisk attached to an Apple IO Controller in slot 6.  Any other model may print different results.)

Here's a picture of how it should look on the screen, with added notes.  The command to test drive 1 is underlined in red; the command to test drive 2 is underlined in blue.

capture763.png

Sorry if that's a bit arcane, but the output might give us a lot of clues if there's a fault somewhere.  Those commands are esoteric-looking, but they perform a lot of operations thanks to Woz's nifty ROMs and circuits.  (The first command performs  13  functions, while the second command performs another 12!)

If the DuoDisk passes both tests, try re-installing the Booti and run the test again to see if it affects the result.  If it doesn't pass, tell us what got printed on the screen or share a picture of it.

(PS: You can force the DuoDisk to 'fail' this test by putting a write-protected floppy in the drive, which should cause it to print  FF  instead of  00  or  7F.)

Your screen shot shows  ]CALL-155  ??

LaserMaster wrote:

Your screen shot shows  ]CALL-155  ??

It's essentially the same operation, just an old (old old) habit. It doesn't matter which one you use.

 CALL-155  initializes the processor, makess a beep and enters the monitor;   CALL-151  just silently enters the Monitor.  They are interchangeable, but  CALL-151  is the variant that became most widely used...perhaps because it's quieter!

S.Elliott wrote:

LaserMaster wrote:

Your screen shot shows  ]CALL-155  ??

It's essentially the same operation, just an old (old old) habit. It doesn't matter which one you use.

 

 CALL-155  initializes the processor, makess a beep and enters the monitor;   CALL-151<

Thanks, nice tip!