[Coco] Glenside IDE + Multi-Pak + HDB-DOS

[David Ladd]

Robert,

I also thought if you plugged a real floppy controller into the Glenside
IDE board you also had to make sure you patched the floppy controllers
logic to only respond to the $FF4x range and ignore the $FF5x?

+-----------------------------------------------------------------------+
| David Ladd a.k.a. PacoOtaktay a.k.a. Drencor                          |
| YouTube: http://www.youtube.com/user/PacoOtaktay                      |
| YouTube Gaming Live: https://gaming.youtube.com/user/PacoOtaktay/live |
| Websites: http://dwladd.com     &     http://www.theterrorzone.com    |
| G+:  https://plus.google.com/113262444659438038657                    |
| G+:  https://plus.google.com/+DavidLaddPacoOtaktay                    |
|                                                                       |
| Do you have your CoCo 3 yet?                                          |
+-----------------------------------------------------------------------+


On Sun, Sep 11, 2016 at 7:56 PM, Robert Gault <robert.gault at att.net> wrote:

> Mark J. Blair wrote:
>
>>
>> <snip>
>> Interesting! I don't understand the MPI in great detail yet, but I have
>> been studying the Glenside IDE schematic today. It appears to me that it
>> makes
>>
> >use of offsets $0..$8 from its base address (either $FF50 or $FF70), and
> will drive garbage on the D bus for reads at offsets $9..$F. Is the MPI slot
> >select register at $FF7F readable by the CoCo?
>
> Yes, the MPI data at $FF7F is readable with the MSN being the slot for the
> ROM at $C000-$FEFF and the LSN being the slot for I/O at $FF40-$FF5F.
>
> If so, I can see how the Glenside IDE would at least garble MPI slot
>> select register reads
>>
> >if the Glenside card it jumpered for $FF7x. I'd like to understand the
> MPI a lot better, including any partial address decoding that might cause
>
>> unexpected conflicts with other hardware.
>>
>> Maybe I need to study this possible timing issue more to figure out what
>> is going on. The CF adapter I'm designing would be a new design using a
>>
> >CPLD for all of the logic. I want it to be usable in an MPI, so I would
> need to address any timing issues whether they lie in the hardware design
> or the HDB-DOS code.
>
>>
>> <snip>
>> It might be because my brain is addled by the cold I'm presently
>> suffering, but I don't think I understand the point you're making there.
>>
>>
>> I've been contemplating whether I should make a fully
>> Glenside-IDE-compatible CF adapter vs. taking more liberty with the design.
>> I gather that
>>
> >the Glenside IDE fully decodes the address bus rather than using the SCS
> signal so that it can coexist with a floppy controller on a Y cable. I'm not
> >sure that it makes sense to expect my new widget to be used on a Y cable
> with a floppy controller, since I plan to include an EEPROM on my widget
> which
> >would conflict with the ROM in a Y-cabled floppy controller. If I assumed
> that my widget would never be used on a Y cable, then I could use SCS for
> the
> >CF card base address, and that might even let me use a smaller and
> cheaper CPLD since I would not need to decode A15..4. But that would also
> break
> >compatibility with existing Glenside-aware software, which would at least
> need to be patched for a different base address at $FF4x.
>
>>
>>
>>
> Mark,
>
> Someone who owns the Glenside IDE and an MPI needs to determine which unit
> or software fails with the IDE set to $FF7x. You should not assume that the
> hardware forces use of $FF5x because it might be possible to alter the READ
> routines in HDBDOS to compensate for the "timing error" mentioned by Boisy.
>
> If the IDE controller is wired "badly" then you should expect both READs
> and WRITEs to fail. Boisy in the source code mentions only READ failures.
>
> Robert
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>