MDV Low Level Routines

[pjw]

tcat,

I just got rid of my last microdrive and microdrive cartridge, as I dont have anywhere to store them and all the paraphernalia needed to maintain 80's technology (cables, monitors, and bits and bobs). However, I never would have if I could have avoided it! So I have followed your quest and appreciate the work you are doing.

It would be really great if you could write up your findings, either as articles for publication or in one or more of the Wiki's - preferably both.

Keep QL-ing!

Per

[Outsoft]

tcat,

I just got rid of my last microdrive and microdrive cartridge, as I dont have anywhere to store them and all the paraphernalia needed to maintain 80's technology (cables, monitors, and bits and bobs). However, I never would have if I could have avoided it! So I have followed your quest and appreciate the work you are doing.

It would be really great if you could write up your findings, either as articles for publication or in one or more of the Wiki's - preferably both.

Keep QL-ing!

Per

Tomas makes an excellent work!

We will write an article for the Giorgio's site and soon will be published.

Stay tuned.

Next step...mDump 3

[Martin_Head]

Hi,

In the map, the last sector holds information on last block allocated.
I am not sure I understand the use of this info in the map.
When I duplicate a tape, I copy this information over, but perhaps I should use that of the destination?

Tom

When files are saved on the microdrive, The blocks are separated by, I think about 12 sectors (the interleave). The "last sector" in the map is used to work out the next sector to try to use. Basically. What was the last sector allocated, Subtract 12 from it, to get the next sector to use.

In the Minerva source code see, \dd\mdvbu.asm and search for md_lsect

[Ralf R.]

In the Minerva source code see, \dd\mdvbu.asm and search for md_lsect

I sometimes wonder, how those very early copy tools like Expresso Coppee were written as there were very few information about hardware or direct mdv access around in these days.

[tofro]

Most of the microdrive stuff, excluding some small detail changes in the sector layout (words instead of bytes used) are very similar to how the Sinclair Spectrum microdrives work. The same concepts could have been applied and the same tricks used.

The actual programming interface is (kind of) documented in the Technical Manual - Even today there is not much better documentation around. And the rest was probably done using a ROM disassembly.

Tobias

[Ralf R.]

Most of the microdrive stuff, excluding some small detail changes in the sector layout (words instead of bytes used) are very similar to how the Sinclair Spectrum microdrives work. The same concepts could have been applied and the same tricks used.

In theory, Jochen Merz should know this, as he has written a ZX-Microdrive book somewhere in the 80s. Though I never read it.

[tcat]

When files are saved on the microdrive, The blocks are separated by, I think about 12 sectors (the interleave). The "last sector" in the map is used to work out the next sector to try to use. Basically. What was the last sector allocated, Subtract 12 from it, to get the next sector to use.

Hi Martin,

I can see this interleaving in the map attached, it is for Super Basic program saved onto a tape.
When the program is loaded, MD motor sometimes stops and then restarts, I believe this is to make sure QDOS has time to tokenise program into memory until next block comes by.

basic program map

word_map.png (7.68 KiB) Viewed 3862 times

I am not sure this also applies for binary files, as they get loaded without tape restarting?

Tomas

[tofro]

I am not sure this also applies for binary files, as they get loaded without tape restarting?

Binary files are loaded with the QDOS equivalent of LBYTES which uses a quite intelligent (and pretty fast) scatter/gather algorithm that picks all the sectors in a file as they come by (even if out of order) and places them in the right place in memory, regardless of the order in which they are. That makes the loading of binary files the fastest file operation in the QL.

SuperBASIC programs are a bit slower to load because first, they need to be read in order because the system doesn't know where in memory the next chunk will go (SuperBASIC programs are stored in ASCII form on tape and in tokenized form in memory, so the program will actually use less space in memory than on tape), and second, the program must be, as you rightly say, tokenized while loaded - This causes the pauses while loading.

[Ralf R.]

That makes the loading of binary files the fastest file operation in the QL.

The old "flrun" system from Tony Tebby also uses this. As the corresponding SB program was saved in tokenized form, tokenizing was not necessary, so as fast as EXing a program.

[tcat]

Tobias, Martin,

Thank you, now to the last block allocated, FDFD value in the map, does not seem right, or perhaps I cannot interpret it correctly?

I can also imagine, that some copy protection may obfuscate this value?

Many thanks
Tomas