Page 4 of 5
Re: Microdrive
Posted: Sat Aug 08, 2015 10:59 am
by 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.
Re: Microdrive
Posted: Sun Aug 09, 2015 10:42 am
by 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
Re: Microdrive
Posted: Mon Aug 10, 2015 7:49 pm
by MIST
Martin_Head wrote:
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
Re: Microdrive
Posted: Mon Aug 10, 2015 7:56 pm
by tofro
Can we have a bit of drum roll and fanfare, please?
Great!
Re: Microdrive
Posted: Mon Aug 10, 2015 8:16 pm
by vanpeebles
DurDumDumDum TooooT TOooooOooOoooOoT!
Great work!
Re: Microdrive
Posted: Tue Aug 11, 2015 9:29 am
by Mike
Wow! Great work!
Did you use a development board, or design your own? Which fpga?
Re: Microdrive
Posted: Tue Aug 11, 2015 11:29 am
by tofro
Mike wrote:
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
Re: Microdrive
Posted: Tue Aug 11, 2015 12:39 pm
by Mike
Ah, that's Altera fpga. Ok, perhaps i should buy one. One more dev board on the pile
Anyway, excellent work done here!
Re: Microdrive
Posted: Tue Aug 11, 2015 2:17 pm
by 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.
Re: Microdrive
Posted: Tue Aug 11, 2015 8:51 pm
by Mike
MIST wrote: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
