Microdrive
Re: Microdrive
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
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
Re: Microdrive
Really go back to 4? Not to 3?tofro wrote: 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)
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?
Re: Microdrive
You're right - back to (3)MIST wrote:Really go back to 4? Not to 3?tofro wrote: 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)
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?
![Embarrassed :oops:](./images/smilies/icon_redface.gif)
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
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Microdrive
Talking to myself again.....:tofro wrote: Gap lengths I'm pretty sure I have somewhere, but where????
Gap lengths can't really be measured in bytes - As we said above, there's no such things as bytes in a gap
![Wink ;)](./images/smilies/icon_e_wink.gif)
(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
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 2: checksums ar simply he arithmetic sum of the above)
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Microdrive
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?
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?
Re: Microdrive
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
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
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Microdrive
I meant the 174930 byte images. That's the qlay format?
It seems a little odd that microdrive images are barely used in emulation.
It seems a little odd that microdrive images are barely used in emulation.
Re: Microdrive
I guess before emulator development started QL already realised that 100k isn't enough for anything serious and disk drives were available?
Re: Microdrive
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.
Yesterday i made my HDL implementation do SCART TV signals so i was able to use a real TV instead of a VGA screen.
Re: Microdrive
BTW: How long does a random sector access take at most? 100k+overhead at 100khz should be something over 10 seconds. Is that correct?