Are there directory devices with a name longer than 3 letters

[mk79]

All versions of the QubIDE driver seem to do this.

Interesting, thanks!

The "open" code of QubIDE's BOOT device will then walk the list of device drivers and count the number of "mdv" occurences - If there's more than one, it detects "there must already be a floppy device driver that has renamed itself to mdv" - In this case, it will chain in and rename itself "mdv" to be the boot device - It needs to detect this in order to find out what needs to be reverted after boot from "mdv".

As far as I can see it makes the opposite, it doesn't make itself auto-boot if a FLP driver has already decided to rename itself to MDV, so FLP takes precedence over WIN. And FLP only renames itself if it detects a disc in the drive during boot. Really interesting approach. I'm wondering if this approach would also make sense for QL-SD, but with the new network driver layer in v1.09 the ROM is very full again, only 76 bytes are currently left

Marcel

[tofro]

All versions of the QubIDE driver seem to do this.

Interesting, thanks!

The "open" code of QubIDE's BOOT device will then walk the list of device drivers and count the number of "mdv" occurences - If there's more than one, it detects "there must already be a floppy device driver that has renamed itself to mdv" - In this case, it will chain in and rename itself "mdv" to be the boot device - It needs to detect this in order to find out what needs to be reverted after boot from "mdv".

As far as I can see it makes the opposite, it doesn't make itself auto-boot if a FLP driver has already decided to rename itself to MDV, so FLP takes precedence over WIN. And FLP only renames itself if it detects a disc in the drive during boot.

That was apparently changed in Version 1.24 from/to the opposite.

Really interesting approach. I'm wondering if this approach would also make sense for QL-SD, but with the new network driver layer in v1.09 the ROM is very full again, only 76 bytes are currently left

The original QL-SD driver, being somewhat of a a derivate of QubIDE, did the very same.
Putting code in "Open" of "BOOT" ensures you have a routine that is called at start-up only once, but after all ROMs are guaranteed to have initialized. As long as all OPENs return ERR.NF, that's a method that can be used by everyone.

[RalfR]

As far as I can see it makes the opposite, it doesn't make itself auto-boot if a FLP driver has already decided to rename itself to MDV, so FLP takes precedence over WIN.

But the Miracle HD always starts first (BOOT file permitted), even if there is a disk in a connected Disk I/F.

[ql_freak]

Thanks a lot for your answers. It's more complicated, than I have thought :-(

I just wanted to write a program, to make the original Lattice C executable. It's too complicated, I then just did it manually (ALCHP(...), LBYTES(...) and SEXEC ...

Unfortunately this didn't work, it's not so easy to make an executable from the original Lattice C (phase 1 and 2) :-( The Lattice C compiler from EJC seems to be patched a lot. I have now found HISOFT C 5.0 Lattice C for Atari ST and will try, if it runs with the TOS emulator from PDQC. If this also won't work, I will give up.

We have a really good C compiler (EJC), which can produce reentrant ROMable code, but it cannot be made public (at least not the 2 compiler phases), because of copyright reasons :-|

BTW: Is the source code for the TOS emulator (filename "pdqc") available (public)?

[NormanDunbar]

Bug or definition problem in DEV_NAME. It doesn't return the next block in addr, but the current one. So on RAM it returns with the addr of RAM, you call it again, then it tries to go to the next block, only then realising that it's finished and returning an empty device string afterwards.

Sorry Marcel, I missed this reply. I think it possible that you are correct, it's always the final one returned which is NULL. I'll take a look at the code and fix it.

Cheers,
Norm.