The Sinclair QL Forum

Thank you very much.
I will try to make it.

Just out of interest:

In your GoldCard clone, have you re-engineered the CPLD equations? I thought the Ingot JEDEC wasn't known yet?

Thanks
Tobias

tofro wrote:Just out of interest:

In your GoldCard clone, have you re-engineered the CPLD equations? I thought the Ingot JEDEC wasn't known yet?

Thanks
Tobias

I have original INGIT5 JEDEC.

tofro wrote:Just out of interest:

In your GoldCard clone, have you re-engineered the CPLD equations? I thought the Ingot JEDEC wasn't known yet?

Thanks
Tobias

I have copies of the JEDEC files for Super / Gold card and QXL.

I have supplied th to other hardware dedigners. I do not know if I have broken any copyright laws.

It's a pity the original design equations are not available, as they could be re-targetted to a different CPLD.
It is possible to reverse-engineer the JEDEC but it is a truly tedious job assuming the jedec fuse map of the CPLD is available (and it's not a given that it is, some manufacturers never published this data).
The EP1810 is also a rather odd CPLD in that it is 'completely connected' and not organized in blocks interconnected with a crosspoint matrix like some other are, which sometimes makes it difficult to re-target the hardware (i.e. it may not fit into some comparably dense CPLDs), but since today much more complex CPLDs are available, not only should it be possible but also some features could be added (such as more RAM).

I realised last night that there is a slight oddity with the Tetroid interface.

Bearing in mind its ROM is basically an amalamation of the QubIDE ROM and the Trump Card ROM, I would expect the boot order to work as win1_boot, flp1_boot and mdv1_boot

However, if win1_boot and flp1_boot do not exist, it does not check for mdv1_boot

Any suggestions as to why this might be?

Just to add that the same thing occurs with the SD Card interface - if no card can be mounted, mdv1_Boot isn't tried.

I think also that any 'virtual' device simply named 'BOOT' (i.e. without any device name in front) is enumerated during the standard QDOS boot procedure - before any physical device.

I'm not sure how other interfaces ever accommodated a fall-back to MDV, but I'm pretty sure that some did...

I too would be interesting to understand how to address this point.

What's done in the QubIDE driver is the following:

1. The QubIDE driver installs a device named BOOT (that doesn't actually provide any files, but rather returns "not found" on any action). This is just to get the next step called at the proper time in the boot process.
2. The BOOT device driver's "open" routine walks the list of device drivers and counts the number of device drivers named "mdv". This makes sure this is done after all device drivers are initialized, but before the system actually tries to open "mdv1_boot"
3. In case the previous step says "1" (which indicates "no-one else wants to be the boot device replacing mdv" - Which also indicates the Trump card is using a different mechanism), QubIDE will temporarily re-name its own device (normally win1_) to mdv1_. This step makes QDOS "think" it booted from mdv1_, but instead it boots from HD.
4. After the first access to the driver, the name change is reverted back.

QDOS has the fixed boot order containing the devices "BOOT" and "mdv" - Nothing else. There's also no built-in function to retry booting from any other device in case those two fail. Any further chaining would have to be implemented in the drivers - apparently, it isn't.

(I would BTW guess if you'd put an original QubIDE and an original Trump Card into a standard QL, the very same thing - i.e. not falling back to mdv when both HD and FD don't provide a file BOOT - would be happening)

Tobias

Hi Tobias

That makes sense. It follows then that the ROM initialisation sequence itself is important - i.e. if an FLP or other device appears lower in the memory map and has already _USE'd mdv earlier in the ROM enumeration sequence, then QubIDE will take a back seat as far as boot order is concerned.

As you say, it is the responsibility of the driver code to carry out any 'chaining', if their own device fails to provide a Boot file. Interesting...

It is indeed interesting - I must admit that when I had a QubIDE I no longer booted from microdrive so would not have noticed this behaviour.

I do however, seem to recall the Miracle HD disk chained properly with the Trump Card - ie win1_boot, flp1_boot, mdv1_boot, but then I might be mistaken - it was many years ago!