The Sinclair QL Forum

Hi,

is the mirodrice code in QDOS, Minerva and SMSQ/E dependent on CPU instruction timings? I seem to remember it is not. But wanted to ask here, in case someone is more familiar with the microdrives.

All the best
Peter

Peter,

Microdrive read and write, as such is not CPU-speed related.
The actual reading and writing of a header and a sector is done with a fixed bit rate not depending on CPU speed.

While the Minerva code says for read and write:

* The nominal time for a single byte on a microdrive is 40us. In the read/
* verify routines, we wish to cope with as wide a range of variation in tape
* drive speeds as we can. Two basic scenarios come up: a tape recorded on a
* slow drive being read back on a fast one, and visa versa. A nominal variation
* of 10% is documented, but as it works out, we can cope here with a variation
* in byte timings from 20us to 80us, i.e. a factor of two either way, which
* corresponds to worst case drives being 41% out of spec in opposing senses.

One could assume the code to work on CPUs roughly twice as fast as the timeout counters are constructed for.

BUT:

The length of gaps (inter-sector and header-data) is determined during FORMAT by CPU delay loops.
The timeouts when reading and writing (e.g. how long to wait for valid data after a gap interrupt), is also determined by CPU speed.

Tobias

Peter wrote:is the mirodrice code in QDOS, Minerva and SMSQ/E dependent on CPU instruction timings? I seem to remember it is not. But wanted to ask here, in case someone is more familiar with the microdrives.

Yes, some of the code needs the right timing to be compatible with QDOS.

The FORMAT command is probably the most sensitive to CPU speed.

M68008 wrote:Yes, some of the code needs the right timing to be compatible with QDOS.

The FORMAT command is probably the most sensitive to CPU speed.

But I don't (quickly) see the code distiguish QL, GC, SGC, while their speed differences are huge.

If I remember well, SMSQ/E does not support microdrive.

As for GC and SGC with Minerva and QDOS, maybe the (S)GC copy the ROM in RAM and proceed with some code patching at startup ?

François

FrancoisLanciault wrote: As for GC and SGC with Minerva and QDOS, maybe the (S)GC copy the ROM in RAM and proceed with some code patching at startup ?

That's what happens - SMSQ/E actually has all the microdrive timings for GC and SGC in a table at gl_mdvtm (in file mdv_asm) which is patched between GC and SGC at startup.

I guess the GC/SGC ROMs do something similar with Minerva and the other ROMs.

Tobias

tofro wrote:I guess the GC/SGC ROMs do something similar with Minerva and the other ROMs.

The sources in sys_gold that are delivered along with the SMSQ/E sources is the patch part of the original (S)GC ROMs.

Marcel

FrancoisLanciault wrote:As for GC and SGC with Minerva and QDOS, maybe the (S)GC copy the ROM in RAM and proceed with some code patching at startup ?

That's it of course. I was just superficially looking at Minerva sources. And knowing Minerva supports the 68020, I wrongly guessed that the microdrive code was "SGC ready", forgetting the patch ROM.

The constants used for the delay loops don't even scale in a simple manner between GC and SGC, probably all hand-tuned.

Thanks to all
Peter