2.8" QD Disk Emulation
Re: 2.8" QD Disk Emulation
So i did more tests to check if the write support is working properly : 10 QD writes with the MO5. Each disk images was successfully verified (the 400 sectors are presents with the right checksums).
The write support appears to work properly with the machine i have here.
Here is what could be wrong in your case:
- The usb stick you are using is too slow and there is some buffer overflow that corrupt the disk image content.
or/and
- The s220 does multiples write gate assertion during the track write. Need to be checked with the oscilloscope.
or/and
- The s220 use a different encoding. I currently support/decode 9.84us, 14,76us and 19,68us pulses distance. We must know if it use a longer/different pulses spacing. If this is a real MFM machine, it shouldn't but this must be checked with the oscilloscope.
or/and
There is an issue with the read part : The MO5 doesn't seems to complain but i will do a test/bench software on the mo5 machine.
What is missing here is the low level format used by the s220 to be able to validate the images.
Would be nice if you could write and post the images 0001,0002,0003 too, to check if we have a consistent content across the images.
The write support appears to work properly with the machine i have here.
Here is what could be wrong in your case:
- The usb stick you are using is too slow and there is some buffer overflow that corrupt the disk image content.
or/and
- The s220 does multiples write gate assertion during the track write. Need to be checked with the oscilloscope.
or/and
- The s220 use a different encoding. I currently support/decode 9.84us, 14,76us and 19,68us pulses distance. We must know if it use a longer/different pulses spacing. If this is a real MFM machine, it shouldn't but this must be checked with the oscilloscope.
or/and
There is an issue with the read part : The MO5 doesn't seems to complain but i will do a test/bench software on the mo5 machine.
What is missing here is the low level format used by the s220 to be able to validate the images.
Would be nice if you could write and post the images 0001,0002,0003 too, to check if we have a consistent content across the images.
Re: 2.8" QD Disk Emulation
Ok i found the glitch in your saved file : The first part of the track is repeated twice times. The size of the block match with the write buffer size (~26Kb)
That's why the track length appeared longer than it should and why the the s220 can't read it since the first one is incomplete/bogus.
Unfortunately i don't reproduce the issue with the hardware i have here, so :
I have manually fixed the data in the attached image (first part removed).
- First can you try to read the attached image ? (DSKA0000.zip)
- Can you try to save/read with another usb stick (another brand/model) ?
- Can you check the write gate signal ? Is it stable during the write ? Please also tell me how many time the s220 is writing the track.
- Try the new firmware in the newfw.zip then write on all the QD files and post them back here.
(Firmware update procedure : https://hxc2001.com/docs/gotek-floppy-e ... pdate.html)
Re: 2.8" QD Disk Emulation
I have tried with different USB sticks and they have different size and write speed, just the same.
A read of your file gives the same illegal QD message.
Updated the firmware, same results.
7 files saved - see attached.
Write Data and Write Gate - see oscilloscope trace. Gate stays on as expected. Not sure why verify has write data.
I will take a look at the read data line
A read of your file gives the same illegal QD message.
Updated the firmware, same results.
7 files saved - see attached.
Write Data and Write Gate - see oscilloscope trace. Gate stays on as expected. Not sure why verify has write data.
I will take a look at the read data line
- Attachments
-
- Write Gate and Write Data trace
- QDwriteTrace.jpg (83.45 KiB) Viewed 4735 times
-
- DSKA0000.zip
- 7 files written to QD
- (30.71 KiB) Downloaded 196 times
Re: 2.8" QD Disk Emulation
Looking at a trace of read and write data lines it becoming clearer what happens in a disk write.
The S220 reads the QD initially, to see if it contains any sample data, it doesn't - so it continues with the write.
It is writing twice and then does a read but only if its a fresh file. The writes are longer than the read in total.
This was with the ABCD banks or A bank with a sample time of 4 or 1 seconds.
The verification failure is at the end of the second write cycle, not the read.
The read block only happens the first time the file is written to.
According to the Write Timing Diagram there should be read data coming back during the write.
There is read data coming back during the write but its much lower than normal read level.
Protect and Motor On signals are the same as the diagram - correct.
The S220 reads the QD initially, to see if it contains any sample data, it doesn't - so it continues with the write.
It is writing twice and then does a read but only if its a fresh file. The writes are longer than the read in total.
This was with the ABCD banks or A bank with a sample time of 4 or 1 seconds.
The verification failure is at the end of the second write cycle, not the read.
The read block only happens the first time the file is written to.
According to the Write Timing Diagram there should be read data coming back during the write.
There is read data coming back during the write but its much lower than normal read level.
Protect and Motor On signals are the same as the diagram - correct.
- Attachments
-
- QD Write - Read and Write Data lines
- QDreadwriteTrace.jpg (89.35 KiB) Viewed 4734 times
Re: 2.8" QD Disk Emulation
Thanks a lot !AMSynths wrote: ↑Mon Aug 26, 2019 1:46 pmI have tried with different USB sticks and they have different size and write speed, just the same.
A read of your file gives the same illegal QD message.
Updated the firmware, same results.
7 files saved - see attached.
Write Data and Write Gate - see oscilloscope trace. Gate stays on as expected. Not sure why verify has write data.
I will take a look at the read data line
I really don't understand what is going on with the write Gate. It seems that the s220 write the track with two separate write parts ?
Or does it write the track twice times ? I suspect that the s220 is going nuts cause of the ready signal not going high during the write process. if so this is something i can fix this easily.
Can you compare with a real QD drive ? Does the s220 do only one write sequence ?
I really hope that this is not a requirement and i don't think that the read data line during the write is what you have on the disk. So this sound strange to me to consider this as a verify. This is will quite hard, if not impossible, to implement this in pure software. My best bet right now is the Ready signal. i know that i don't set it fast enough to high and this is maybe why the s220 is writing the track twice times.
I think that we really need to compare the write gate behaviour with a true QD drive.
EDIT : Got it ! -> The Ready signal is asserted -> the s220 write the track -> At the end of the track write the ready signal should be de-asserted, but it is not (my fault) -> The s220 immediately try to read the track to verify it, but it fail because it is at the wrong place -> the ready signal is finally de asserted -> and asserted again -> the s220 try to write again -> new failure.
Will fix this this evening !
Re: 2.8" QD Disk Emulation
That sounds like the fix and matches the timing diagram. I will test the firmware on this S220, another S220 and a S10 as soon as its updated.
Re: 2.8" QD Disk Emulation
attached the new fw (3.4.1.7)
please write to the images and post them back here (even if working )
EDIT : -> Archive updated for a small fix.
Re: 2.8" QD Disk Emulation
And finally since i am totally unsure about the normal ready size window, i prepared more QD files with 4.5 seconds, 4.7 seconds and 5 seconds ready window. If the QD in the newfw3.zip failed (they are set to 5.5 seconds) , please try the following QD files. According to the graph in the S220 service manual the window appears to be 4.5 seconds and the track seems shorter than with the MO5 (This one almost need a 5.5 seconds ready window..).
Re: 2.8" QD Disk Emulation
Not successful...traces below. 4.5 seconds and above look better with the reads but still 2 write cycles.
- Attachments
-
- 4.7 seconds
- 4_7 seconds.jpg (94.21 KiB) Viewed 4671 times
-
- 4.5 seconds
- 4_5 seconds.jpg (94.31 KiB) Viewed 4671 times
-
- New firmware 3.4.1.7
- FW 3_4_1_7.jpg (90.36 KiB) Viewed 4671 times
Re: 2.8" QD Disk Emulation
5 second timing trace
- Attachments
-
- 5 seconds
- 5 seconds.jpg (95.04 KiB) Viewed 4671 times
Re: 2.8" QD Disk Emulation
Can you add the ready trace ?
Re: 2.8" QD Disk Emulation
And very important : please post the images back.
Re: 2.8" QD Disk Emulation
here we go....
- Attachments
-
- DSKA0000.zip
- 4 files written to with latest fw
- (6.47 KiB) Downloaded 175 times
-
- Read and Ready trace
- 5 seconds Read and Ready.jpg (55.74 KiB) Viewed 4663 times
-
- Write and Ready trace
- 5 seconds Write and Ready.jpg (52.61 KiB) Viewed 4663 times
-
- Posts: 47
- Joined: Sun Jan 02, 2011 2:31 am
Re: 2.8" QD Disk Emulation
Looking at the 5 second trace, the first write cycle is taking longer than 5 seconds and the ready off cuts the data off. Looks like it takes 5.2 seconds to check disk and then write the data.
- Attachments
-
- 5 second ready signal with write data
- 5 seconds Write and Ready2.jpg (51.83 KiB) Viewed 4657 times