Microdrive

[Martin_Head]

Mist

in case this is of any help to you, There are three kinds of microdrive image files that I am aware of.

1. The QLAY .mdv image files (174,930 bytes). These seem to be the closest to a real microdrive cartridge with the preambles before the blocks. Sector order in the image files is - Sector 0, followed by sector 253, and counting down to sector 1. (There can be some padding of non existent sectors here, But I don't have official documentation of the QLAY image file format)

2. The Qemulator .mdv image files (size varies). This comprises of a special header, followed by Sector zero, then the highest good sector, followed by sectors counting down to sector 1. There are no preambles or checksums for the blocks.

3. My MDI Directory device driver image files (136,170 bytes). This comprises of 255 sectors starting at sector zero, then sector 254, followed by sectors counting down to sector 1. There are no sector preambles for the blocks.

If you want I can give more detailed layouts of these image formats.

[tofro]

And another one on the preambles (3 all-in-all) - Just for the sake of completeness. I digged a bit deeper in the ROM sources to resolve my confusion:

Actually, the preambles (one before the sector header (preceded by a gap), one in front of the block header (preceded by another gap) and another one between block header and the actual data block (no gap in front of that one) are only written to the tape. They are never actively read by ROM code, so I would expect the microdrive circuitry eats them during the course of syncing its PLL with the tape frequency.

This excerpt from Minerva sources shows this pretty well (that is the piece of code that reads the block header and the data):

Code: Select all

        moveq   #2-1,d1         block header is 2 bytes
        bsr.s   rblock          and read block header
        bra.s   bad_blok        failed
        move.b  #pc.read,d1     set up pll reset byte
        move.b  d1,(a3)         reset pll
        delay   25              wait for a zero to clock through
        move.b  d1,(a3)         reset controller
        move.w  #512-1,d1       read 512 byte block

The magic happens at the "delay 25" and the following line - There is actually a preamble rushing by on the tape in that moment, but it's not seen in the data registers - The code continues reading as if there were 12 bytes less....

Tobias

[MIST]

1. The QLAY .mdv image files (174,930 bytes).

This is the format have had a closer look at. And indeed, contains all the information. This is what i used in my tests as seen here:

https://youtu.be/tdZv0u2SDv0

[tofro]

Can we have a bit of drum roll and fanfare, please?

Great!

[vanpeebles]

DurDumDumDum TooooT TOooooOooOoooOoT!

Great work!

[Mike]

This is what i used in my tests as seen here:
https://youtu.be/tdZv0u2SDv0

Wow! Great work!

Did you use a development board, or design your own? Which fpga?

[tofro]

This is what i used in my tests as seen here:
https://youtu.be/tdZv0u2SDv0

Wow! Great work!

Did you use a development board, or design your own? Which fpga?

Till uses MiST, his own design. MiST can be bought here: http://lotharek.pl/product.php?pid=96
(Or, if you want, you can build one yourself...)

An exhaustive description is here: https://code.google.com/p/mist-board/wiki/WhatIsThis

Tobias

[Mike]

Till uses MiST, his own design. MiST can be bought here: http://lotharek.pl/product.php?pid=96
(Or, if you want, you can build one yourself...)

An exhaustive description is here: https://code.google.com/p/mist-board/wiki/WhatIsThis

Tobias

Ah, that's Altera fpga. Ok, perhaps i should buy one. One more dev board on the pile

Anyway, excellent work done here!

[MIST]

It shouldn't actually be too hard to port it to any other fpga board. Only a few things would have to be changed. Mainly the rom/tape upload which is currently done using the arm io controller would have to me replaced. Since most other FPGA boards contain flash memory it'd probably easiest to use that.

[Mike]

It shouldn't actually be too hard to port it to any other fpga board. Only a few things would have to be changed. Mainly the rom/tape upload which is currently done using the arm io controller would have to me replaced. Since most other FPGA boards contain flash memory it'd probably easiest to use that.

Thanks! Good point. Will give that a shoot when i get some spare time. I have a ZedBoard that never got used for anything sensible. Is the arm doing anything else than loading the rom?

By the way, i looked at your MIST board. Impressive work on 2 layers only