Microdrive

[Mike]

Hi,

just want to post some update on progress.

I found a lot more information by reading the Minerva 1.98 source. It's quite well documented and structured. I realize that this is the way to go to reach higher level of hw-compatibility. I'm not sure though, how much the minerva differs from the JM rom and others.

/Mike

[MIST]

3. wait for a gap interrupt
4. start reading from $18022/$18033 - if it's a header, check for sector #21
5. goto (4) if it's not the correct sector header (basically wait for sector header #21 to come by)

Really go back to 4? Not to 3?

Also is there also a gap between the sector header and the sector data? In a mdv file only a gap of 148 Bytes exists between the sector data nd the next sector header. And are these lengths real? Is the gap 148 byte lengths? And how long is the gap between the header and the data?

[tofro]

3. wait for a gap interrupt
4. start reading from $18022/$18033 - if it's a header, check for sector #21
5. goto (4) if it's not the correct sector header (basically wait for sector header #21 to come by)

Really go back to 4? Not to 3?

Also is there also a gap between the sector header and the sector data? In a mdv file only a gap of 148 Bytes exists between the sector data nd the next sector header. And are these lengths real? Is the gap 148 byte lengths? And how long is the gap between the header and the data?

You're right - back to (3)

And yes, there's a gap between sector header and sector data on physical tapes- needs to be, as the headers are never written after formatting, data, however, quite often. So the second gap is needed to make sure we've got enough safety room between the two parts.

Gap lengths I'm pretty sure I have somewhere, but where????

Tobias

[tofro]

Gap lengths I'm pretty sure I have somewhere, but where????

Talking to myself again.....:

Gap lengths can't really be measured in bytes - As we said above, there's no such things as bytes in a gap

(From SMSQ/E sources:)
In terms of time passing, gaps are 2800µs - 3580µs (first is during format, second during write. No idea at the moment why this is so)

(From Minerva sources:)
Sector header format:

Code: Select all

shbeg ; sector header
        ds.b    1       $ff
sno     ds.b    1       sector number
        ds.b    nml     medium name
        ds.b    2       randow number
shend

Data Sector format:

Code: Select all

blbeg ; block
        ds.b    1       file number
        ds.b    1       block number
        ds.b    2       checksum
blpre   ds.b    6+2     preamble (6 zeroes and 2 $FF's)
bldata  ds.b    bdl     block data
blcs    ds.b    2       checksum (embedded in the long block we format with)
bx      ds.b    84      extra bytes
blend

(NOTE: bdl is 512)
(NOTE 2: checksums ar simply he arithmetic sum of the above)

Tobias

[MIST]

Thanks again. Very helpful!

Looking at the 174930 bytes drive image i see some differences:

- There's another 10*0+2*ff preamble before the header and the data
- nml seems to be 10
- there's another 2 bytes at the end of the header. Perhaps a checksum? You header does not have one which is hard to believe
- There are 120 bytes of $5a after the sector checksum

Giving a total of 686 bytes per header/sector pair.

This is the qlay format, isn't it? Is that the format to use?

[tofro]

Right, nmL - the length of the medium name is 10 - Should have added that.

And no, that's not Qlay - That's the format how the Minerva ROM writes a "real" physical microdrive.

And no, on the "real thing" the sector headers don't seem to have a checksum. (Checked again, a sector header does have exactly 14 bytes, and that''s what's read and written)

Also note the data block (the "sector") has 2 checksums - the first one apparently only to make absolutely sure file and block # are OK, the second one only to verify the data block contents.

BTW: Empty sectors seem to be pre-filled with $aa55 during format.

(And I really don't know how a proper micro drive image file should look like, because I have never seen one.... - I'd guess Daniele has the specifications, maybe?)

Tobias

[MIST]

I meant the 174930 byte images. That's the qlay format?

It seems a little odd that microdrive images are barely used in emulation.

[Paul]

I guess before emulator development started QL already realised that 100k isn't enough for anything serious and disk drives were available?

[MIST]

Emulators typically first try to mimic the original machine perfectly and on top of that start to implement add-ons. That's why I'd like to add a microdrive to my hdl implementation as well. I'd really like to see something that gives me the original feeling.

Yesterday i made my HDL implementation do SCART TV signals so i was able to use a real TV instead of a VGA screen.

[MIST]

BTW: How long does a random sector access take at most? 100k+overhead at 100khz should be something over 10 seconds. Is that correct?