Page 1 of 8

Microdrive data line format

Posted: Mon Aug 26, 2013 9:20 pm
by gertk
Trying to figure out the Microdrive signals...

When I connect the oscilloscope to Data1 and Data2 and run the test program from the service manual I get a picture like this:

A null (0) is written into the TRACK1 register ($18022)
small_data1_data2.jpg
After writing 255 in the TRACK1 register it changes to this:
small_data1_data2_255.jpg
How do I interpret this ?

Re: Microdrive data line format

Posted: Tue Aug 27, 2013 1:55 am
by dex
Shouldn't this be the opposite?
Higher frequency for 1 bits (byte 255) and lower for 0 bits (byte 0)?

Re: Microdrive data line format

Posted: Tue Aug 27, 2013 11:44 am
by gertk
What I also try to find out is why the pattern is continuous, it never stops unless you reset a bit in the control register. I understand that the ULA is quite simplistic but somehow these bits/bytes have to be timed.

Re: Microdrive data line format

Posted: Tue Aug 27, 2013 10:26 pm
by gertk

Code: Select all


* reverse engineering the mdv write routine
* by Gert van der Knokke
* based on the initial work of Richard Zidlicky
* on entry A3 points to $18020 Microdrive control/status and IPC status register
* D1 is the number of bytes to transmit (fixed ?)
* A1 points to the first byte of the byte(s) to be transmitted

L051E4 MOVEQ   #$0E,D0   * common mdv write routine
       MOVE.B  D0,(A3)	 * set MDSELECT, MDSELECT_CLK and MD_WRITE
       MOVE.B  D0,(A3)	 * and again (why?)
       MOVEQ   #$01,D6	 * preset bit number 1 in D6
       LEA     $0002(A3),A2 * setup A2 to $18022 MD transmit register
       MOVEQ   #$09,D5	 * set up counter for 10 bytes

L051F2 MOVEQ   #$00,D4	 * setup D4 to all '0' 

L051F4 BSR.S   L0521A	 * send 10 of these
       SUBQ.B  #1,D5	 * decrement counter
       BGE.S   L051F4	 * if greater or equal to zero
       
       MOVEQ   #-$01,D4  * setup D4 to all '1' 
       BSR.S   L0521A 	 * send this
       BSR.S   L0521A	 * and again
       
       MOVE.W  #$0F0F,D3 * setup checksum?
       MOVEQ   #$00,D4	 * clear D4

L05206 MOVE.B  (A1)+,D4	 * get databyte from A1 in D4 and  increment A1
       ADD.W   D4,D3	 * add databyte to checksum in D3
       BSR.S   L0521A	 * and send it
       DBF     D1,L05206 * decrement byte counter and repeat if not done 
       
       MOVE.W  D3,D4     * copy D3 into D4
       BSR.S   L0521A	 * and send lower 8 bits
       LSR.W   #8,D4	 * move upper 8 bits to lower 8 bits
       BSR.S   L0521A	 * and send these also
       JMP     (A4)	 * return ?

L0521A BTST    D6,(A3)   * test XMIT buffer full bit
       BNE.S   L0521A	 * wait if so
       MOVE.B  D4,(A2)	 * send byte to transmit data register
       RTS		 * done
I added comments for each statement, in the original text there were just a few comments and the BTST D6,(A3) was commented as 'wait for 8049 busy' which seemed unlikely as bit 1 of the MD_SYSTEM register is the XMIT buffer full flag.

If I understand this code correct then a block of data starts with 10 bytes of 'null' , then 2 bytes of 0xff and then a (fixed?) number or data bytes followed by a two byte checksum.

Still I do not understand how a byte is transmitted over the two data lines:

* If the transmit register is a sort of shift register why does it continue to generate output after a byte has been transmitted :?
* Static testing results in a square wave of 100 kHz on DATA1 if a 1 is poked into the transmit register and a 50 kHz square wave when a 0 is poked into the transmit register.
* DATA2 is always a 100 kHz square wave, just the polarity changes relative to DATA1 when poking data into the transmit register.
* How is the 8 bit data divided over the two data lines ?
* Is bit 0 transmitted first or bit 7 ?

Re: Microdrive data line format

Posted: Wed Aug 28, 2013 10:47 am
by twellys
From your scope, it seems to me that the bottom trace (2) is the clock and the top trace (1) is the data coded as FM: 100kHz = '1', 50kHz = '0'.

That way, if the microdrive is slow or fast it doesn't matter because the recorded clock that matters.

Re: Microdrive data line format

Posted: Wed Aug 28, 2013 6:09 pm
by gertk
Ok, makes sense. So the tracks on the tape do not consist of interleaved bits but one track clock and one track data ?

Will try to investigate further.

BTW: As 'data analyzer' I connected the MD bus to a mbed microcontroller (a 100 MHz ARM board).

The fact that the output keeps on going means I must wait for a stream of ten '0' bytes followed by two bytes of all '1' and then try to read the block data.

Re: Microdrive data line format

Posted: Wed Aug 28, 2013 8:58 pm
by tofro
All,

the QL service manual says regarding the Microdrive format:
Data is recorded on two tracks using a standard stereo cassette head arrangement and is written in bytes, one byte to one track and the next byte to the other track. It is recovered in the same way. The tape itself is one continuous loop. Since the hardware takes care of switching between tracks the software sees the tape as one double length single track
From that, I would assume, you're not seeing clock on DATA2.

What you see, is a disallowed case ;) I guess.

Or: If you don't feed bytes into the MD transmit register (that is, keep pushing bytes in as soon as the buffer is no longer full), the bytes written would be undefined (or 0? Or the last one in?). If you have nothing more to write and the buffer runs low, you would need to reset MD_WRITE in the MD control register - That makes the write circuitry idle.

I understand the MD circuitry as follows:

You wind up the selected drive, and listen to GAP interrupts (that is, between sectors on the tape). If you see a GAP, you start reading - The sector number passes by, if it's the one you'd like to write to, start pushing bytes into MD transmit register, with MD_WRITE set. As soon as "MD transmit Buffer full" is no longer there, push in the next one, until you've written the complete sector. Reset MD_WRITE
Wind down drive. Done

Tobias

Re: Microdrive data line format

Posted: Wed Aug 28, 2013 9:37 pm
by gertk
Slowly this FM thing it is starting to make sense :D
The levels are not static definitions of one and zero.

When sending all zeros, DATA1 is 10 usecs low or 10 usecs high aka no change halfway while a '1'is encoded by 5 usecs low followed by 5 usecs high (or vice versa).

FM encoding dictates that when there is a level change halfway the bit time the bit is a '1' and if there is no level change it is a '0'.

To read a bit I have to wait for an edge, then wait 1 usec to make sure the data level is stable after the edge, sample the level of DATA1, wait 6 usecs to sample the level half a bit further and compare that level with the level sampled before.
If it has changed it is a '1' else it is a zero.

Now for DATA2...

DATA2 is shifted half a bit further on the tape to cause no disturbance in the magnetic data between tracks. I need to modify my 'get_bit' routine to read half bits.

Getting close...

Re: Microdrive data line format

Posted: Thu Aug 29, 2013 6:38 am
by gertk
This is part of a hexdump of a received datablock from the QL during the command

format mdv3_0123456789
hexdump
hexdump
Data track2 is not read out properly so half of the data is missing.

Re: Microdrive data line format

Posted: Sun Sep 08, 2013 9:27 pm
by gertk
Well, result! Yes... My first directory generated by the mbed and recognized by the QL.. :D
dir_mdv3.jpg
After some more fiddling the QL now can start and stop the virtual Microdrive and thus read in any sector it wants. The mbed MD emulator keeps track of the current sector and just cycles around and around from 0-255.
Manual loading of the boot file with LOAD MDV3_BOOT and modifying the lines which had mdv1_ in them to mdv3_
The magic RUN command was then given and behold: The Quil started...
quill_running.jpg
Next step is to attach te sdcard to the mbed and get the sectors from there instead of my (huge) include file with the Quill MDV image... :)