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

[Robert Gault]

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