So - there seem to be some rules about what can go where and what will co exist and what will not.
A standard Qubide with Qubata ROM can't co exist with Qimsi - even if you move the address of the qubide out of the 0x0C000 address range (ROM Slot) - the device driver name and commands like WIN_USE conflict.
A Gold card fills the memory map of the QL upto the 2MB point - but does leave the ROM port address free after the 2nd boot - this means QIMSI can work here.
The Qubide card can be made to work without ROM - but will need the REXT driver loading up - this can be configured to use QUB as a prefix for devices and drivers.
So that would appear to just leave the problem of where to put hte QUBIDE hardware address space (256 bytes at the end of a 16K block).
I noticed the QL memory map after the 2nd boot using a gold card has the patch rom and devices in the space 0x1C000-0x1FFFF - but the patch ROM doesn't have the full 16K of the EPROM block used.
So if there was a way to disable the Gold card ROM access and allow Qubide hardware access at 0x1FF00 - would that work?
On paper it should...
Hypothetical question - Gold Card + Qubide + QIMSI
Re: Hypothetical question - Gold Card + Qubide + QIMSI
ok - so I should have read Marcel Kilgus' excellent notes on the Gold and SuperGold card boot sequences - it's all about where things are stored in the final phase.
I had assumed that the patch part of the ROM was going to end up being resident at 0x01C000, but it doesn't - it's contents are there - but the are in RAM - so my idea to highjack the last few bytes in that area - not going to work.
It was back to the drawing board, and after a small modification to the DIY Qubide (I really should leave these poor things alone
), I rerouted the DMSCL signal on the Qubide to come from the GAL 1 Select signal. I changed the address of the card to the QL I/O area (yes, yes - bad form - these addresses should not be used, etc, - but the only thing that lives up the top end of that part of the memory map there is QIMI - and with QIMSI - there is no QIMI!!
So now a new, although not so new problem - Qubata REXT still needs to see the ROM at the QUBIDE cards base address, so as there is no ROM in my card, that driver reports no card found and promptly exits.
I did get it to run with Qubide V2.02, but I don't have a partition or image to test it thoroughly with yet.
I have also introduced some flakiness in startup now - basically the QUBIDE card is providing DTACK for any access in the QL's internal I/O area, and it should only be providing DTACK for it's own GAL accesses. I will likely need to modify the GAL2 code and make a small mod to the wiring, and drive DTACK (low going) and DSMCL (high) whenever the last 256 bytes of 18000-1BFFF are accessed.
I should then be able to co exist QUBIDE, Gold Card and QIMSI on the QL together.
I had assumed that the patch part of the ROM was going to end up being resident at 0x01C000, but it doesn't - it's contents are there - but the are in RAM - so my idea to highjack the last few bytes in that area - not going to work.
It was back to the drawing board, and after a small modification to the DIY Qubide (I really should leave these poor things alone

So now a new, although not so new problem - Qubata REXT still needs to see the ROM at the QUBIDE cards base address, so as there is no ROM in my card, that driver reports no card found and promptly exits.
I did get it to run with Qubide V2.02, but I don't have a partition or image to test it thoroughly with yet.
I have also introduced some flakiness in startup now - basically the QUBIDE card is providing DTACK for any access in the QL's internal I/O area, and it should only be providing DTACK for it's own GAL accesses. I will likely need to modify the GAL2 code and make a small mod to the wiring, and drive DTACK (low going) and DSMCL (high) whenever the last 256 bytes of 18000-1BFFF are accessed.
I should then be able to co exist QUBIDE, Gold Card and QIMSI on the QL together.