MDV Low Level Routines

[tcat]

Martin,

Thank you.

$FE is truly BAD sector.
While $FF may have two meanings>

inside map = slightly BAD sector marker,

at the map end = meaning OFF tape, as that part did not make it through in time to be formated, or was truncated for higher media reliability.

If above is correct, this implies that my drive 2 is slower than drive 1.

Tomas

[tofro]

Minerva explains it like that:

Code: Select all

st_map  equ     $f8     map file number
st_free equ     $fd     verifified ok twice
st_grot equ     $fe     failed one or other of the verifies
st_bad  equ     $ff     not seen, or neighbour was not seen, on either verify

And if you look in the code, "not seen" evaluates to "sector header read failed" or "not there at all" (because it didn't fit on the tape), and "$fe" is either "block checksum failed" or "verify failed" (even with an OK block checksum). For $fe, however, the sector header must have been readable properly.

Interestingly, the format routine (at least the Minnie one) will also flag all sectors as bad that are direct neighbors of an originally "unseen" sector. This is done, apparently, to widely avoid bad tape spots. Here the Minnie code does not really align with what you see on the tape's map. Apparently, the Jx ROM doesn't do that.

A format is rejected if either sector 0 (the map) couldn't be properly formatted (for obvious reasons, as the tape would be unusable), the tape formatted to less than 200 sectors (then the whole thing is apparently considered unreliable), or the verify could see a sector 255 properly formatting (that would mean the tape is running waaayyy too slow)

Note that if the tape runs slower, the density of the data on the tape will be higher. Thus, more sectors will fit on the tape than on a drive with higher speed. I think you got it exactly the other way round.

Tobias

[tcat]

Tobias,

Thank you.

Now I dare to ask a H/W related question here in software section

My QL board is Issue 6, I have seen some recommended modification in QL Service Manual pertaining to MDV performance.

I cannot tell if my board has or has not this mod right from production. But generally what can be expected of this mod? As the mod really consists of some track tripping and bridging close to MDV2, can it perhaps adjust the speed of Drive 2?

Many thanks.

Tomas

[tcat]

Hi,

As a next exercise I wish to learn to duplicate tapes using low level routines.

Being aware that source and target media will have $FF, $FE sectors at different places, I need to decide how to adjust the Source MAP to avoid writing to Bad blocks on target media.

I wonder what could a suitable algorithm be?

note: 1 - source, 2 - target
[0] exit if stat 2 < stat 1
[1] read both MAPs 1,2
[2] loop through 1 used sectors $00..$F0
[3] if sector on 2 is $FD go [2]
[4] sector on 2 is $FE,$FF, find nearest $FD on 1
[5] on 1 write sector $[file][block] over nearest $FD00, on 1 mark previous $[file][block] as $FD00
[6] go 2
[7] end loop exhausted

Do I have to also rewrite block headers on target?
Do I have to also reorder source blocks to match the new order in modified MAP?


Tomas

[tofro]

Depends on what you want: If you want a fairly exact copy that only differs where it needs to, you'd need to mark sectors in the target as "bad" when they are in the source. Then only move bocks to other sectors when you need to (because the target has an unusable sector where the source didn't.)

Block headers are always written when you write a sector afaik.

If you are moving a block to another sector, you simply move its (file number|block number) entry to another place in the map. No re-ordering is necessary.

I think I would simply merge the two maps first, remembering which blocks need to be moved from their original place on the target, then do a 1:1 copy of blocks from src to dst (except for the sectors that need to be moved), then copy the to be moved blocks to new (empty) sectors. You'd need the merged map and a list of sectors that need to be moved. Last, write the new mapping sector.

[Ralf R.]

Would be interesting to see, how "Expresso Coppee" has done exact copies, which it has done. On MC level. One should exemanine the program.

[tofro]

Ralf,

it has been mentioned before, there's no such thing as an "exact mdv copy" - It is simply impossible.

There might be a "close enough" mdv copy - And maybe tcat is close enough.

Tobias

[tofro]

BTW, tcat:

If you want to be able to copy copy-protected cartridges, you should copy all sectors that can be copied, even those that are marked as "unused" in the map.

Tobias

[Ralf R.]

Tobias,

perhaps you are right, but "Expresso Coppee" was even able to copy "The Pawn", which is one of the hardest ones (as far as I know).

Nevertheless, I think, I have send a copy to Rich. Maybe he can send it privately, just for examine it.

[Martin_Head]

I wonder what could a suitable algorithm be?

note: 1 - source, 2 - target
[0] exit if stat 2 < stat 1
[1] read both MAPs 1,2
[2] loop through 1 used sectors $00..$F0
[3] if sector on 2 is $FD go [2]
[4] sector on 2 is $FE,$FF, find nearest $FD on 1
[5] on 1 write sector $[file][block] over nearest $FD00, on 1 mark previous $[file][block] as $FD00
[6] go 2
[7] end loop exhausted

If you are going to do one sector at a time it's going to be slow. Worse case, where the tape needs to go right around to find the next sector it wants . You are looking at around 25 minutes (7 seconds for a rotation * say 216 sectors = 1512 seconds = just over 25 minutes. And if you add in verifying each written sector, you are up to about 1 Hour of the cartridge continuously running.

You could try to get clever, and do the sectors out of order so, and keep going around until you have caught them all.

I think it would be better to read the entire source, and destination cartridges into memory (like making an image file). Then do all your copying/moving of sectors, and map manipulation in memory. Then write all sectors back out to the destination cartridge in one go. And then verify all the sectors in one go. This should only take about 14 seconds.

Something you would have to watch out for, is copy protection systems which mess about with the map. If the map cannot be trusted, you are asking for trouble trying to move sectors about.

Martin Head