2.8" QD Disk Emulation

[Jeff]

something is wrong...the traces show 3 reads on Save. 3rd read is after the Verify Error.
Also cant Load from any banks now..

Possible : The Akai sector use the same sync word and this image wasn't blank. Maybe this cause this issue. Anyway this doesn't solve the verify error after the write.

[Jeff]

Any thoughts on next steps ? I will measure the read duration and ready window.
We know the data is correct and can be read, so it must be how the verify read is working, somehow chopping some data out maybe.

Yes. Maybe the delay between the end of write and the start of the read is too long for some reasons. That's why i want to check the window size and the full rotation timing at the milliseconds. Also the last usb stick write sector may introduce some delay. Reducing the 8 seconds track length is maybe a workaround. Waiting for your QD rotation and ready measurements

[AMSynths]

Some timings...

A Load is 5.031 seconds with Ready asserted 30 ms after Read, Read stops when Ready is unasserted

A Verify Read is 4.981 seconds with Ready asserted 180ms behind Read and Read extends 200ms after Ready is unasserted

[Jeff]

Some timings...

A Load is 5.031 seconds with Ready asserted 30 ms after Read, Read stops when Ready is unasserted

A Verify Read is 4.981 seconds with Ready asserted 180ms behind Read and Read extends 200ms after Ready is unasserted

This is interesting. What about the delay between 2 ready assertion (full rotation timing)?

[AMSynths]

Gotek 5.06 seconds between the first and second Ready asserts
Real QD is 8.85 seconds
But the whole sequence is different - see below

Using 3.4.4.6 fw I can see the SAVE sequence is incorrect when compared with the real QD
Two traces attached, looking at Read Data and Ready.

The Real QD does an initial read to see if its a valid QD and whether its been written to before as one cycle.
The Gotek does a quick read then pauses before doing a read/write cycle.
This cycle extends beyond the Ready being unasserted
Then there is another verify cycle with a verify error at the end
Then a third read cycle after the verification error

The real QD does 3 Read/write cycles in a SAVE
The check QD when Ready is unasserted as soon as the Roland software confirms its ok
The read continues to the end of the QD
Then a true write cycle and then the verify read

Hope that helps, the Gotek is definitely different than a Real QD on SAVE.

3.4.5.1 fw gives ERR on Gotek and does not read or write
3.4.4.2 fw gives continuous read with no break between the 3 read cycles (Check QD, Save, Verify)

[Jeff]

What is the yellow trace ? The ready signal ? If so i don't understand why there is a first short ready time on the last trace. For me if the QD drive pass the head switch while the motor on is asserted, the ready signal asserted and its state is latched until the stop switch is passed. The Motor on signal is a trigger, not a direct command. But maybe this is different with Roland QD drives, the motor state is maybe not latched ?

EDIT : According to the Roland service manual the motor state and ready signal is latched as expected. So how this short Ready is possible ? Is the Roland playing the reset signal at this point ? Or are you showing me something else ? Is it a Real QD drive trace or a Gotek trace ?

08 Sept Read QD SAVE.jpg (106.05 KiB) Viewed 48284 times

[Jeff]

3.4.5.1 fw gives ERR on Gotek and does not read or write

You probably used the non quickdisk version. The QD firmware is in the quickdisk folder.

[Jeff]

This remember something that i have already fixed last week. Which firmware version are you using ?

08 Sept Gotek SAVE.jpg (110.45 KiB) Viewed 48274 times

[AMSynths]

3.4.5.1 fw was from the QD folder
The traces are Read Data and Ready

The Read trace show say Real - its the Real QD
Ready is unasserted once the QD is checked as being ok, the read continues as the motor is on until the end of the disk is read

In the Gotek trace you can see the check read (the very first blip) happens before Ready is asserted
The read then continues after the Ready is unasserted

[Jeff]

3.4.5.1 fw was from the QD folder

Just tried to be sure and still read .QD files without problem . The file to use is "HxCFEUSB_V3_4_5_1a_QuickDisk.UPD"

[AMSynths]

This fw can read a QD file, but write gives verify error and any further reads of the same file fail with Illegal QD

[Jeff]

The Read trace show say Real - its the Real QD
Ready is unasserted once the QD is checked as being ok, the read continues as the motor is on until the end of the disk is read

The QD drive doesn't do this automatically. There is something that force it to unassert the ready signal.

We definitively missing channels to figure out what is going on... would be nice to see the motor on, the ready signal, the write gate and the reset signal on the same screen...

Could you check if the reset line is asserted during a save sequence ?

[Jeff]

This fw can read a QD file, but write gives verify error and any further reads of the same file fail with Illegal QD

Which QD file are you using ?

[AMSynths]

Roland Formatted QD, it has bank name of AA

[Jeff]

This fw can read a QD file, but write gives verify error and any further reads of the same file fail with Illegal QD

Which QD file are you using ?

And what about this version ? :
viewtopic.php?f=2&t=773&start=240#p21227

Nothing was changed in the QD code since this version, so if the 3.4.5.2 doesn't work, the 3.4.4.6 shouldn't work too.