Hard sector format

HxC Floppy emulator support for all others computers...
Post Reply
Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Sat Jun 02, 2018 4:57 pm

snhirsch wrote:
Sat Jun 02, 2018 4:37 pm
I verified proper termination on the floppy bus. The Gotek is in the middle between the controller and physical floppy. The physical drive has a 150-ohm resistor pack. All connections have been clean with non-residue cleaner.

Step pulses have a short burst of ringing (about +- 0.1V) around the leading edge with a duration << 0.1 usec. Pulses are 4.5 usec in duration. The duration does not vary with step rates. The "fast" step rate is 12 msec. The slow step rate is about 50 msec (!). Based on what I see, I do not believe signal quality is responsible for the behavior.
Can you share the oscilloscope screen capture ? The rising / falling rate maybe be important too.

Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Sat Jun 02, 2018 5:06 pm

snhirsch wrote:
Sat Jun 02, 2018 2:40 pm
You'd mentioned the input architecture before. The situation is not optimal, since the transition for logic 0 to 1 on a 3.3V device is at a lower level. Have you thought about a simple buffer board to use in difficult cases? Maybe Lotharek could offer such a device.
I think that Lotharek prefer to provide a complete floppy emulator solution which make more sense :wink:
snhirsch wrote:
Sat Jun 02, 2018 2:40 pm
To me, it is interesting that the slow step rate never shows a NO INDEX PULSE error. Even if a glitch occasionally causes a double-step (or missed step), why does the index pulse issue go away completely? Does the Gotek firmware pause sector pulses while responding to a step? If so, that is probably different behavior from a mechanical floppy. Maybe the slower step gives the Gotek more time to resume pulses?
How often have you this seek error message ?

Unfortunately have checked the stock here and there is some heathkit machines but no northstar machine :(...

snhirsch
Posts: 160
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch » Sat Jun 02, 2018 5:23 pm

Jeff wrote:
Sat Jun 02, 2018 4:57 pm
snhirsch wrote:
Sat Jun 02, 2018 4:37 pm
I verified proper termination on the floppy bus. The Gotek is in the middle between the controller and physical floppy. The physical drive has a 150-ohm resistor pack. All connections have been clean with non-residue cleaner.

Step pulses have a short burst of ringing (about +- 0.1V) around the leading edge with a duration << 0.1 usec. Pulses are 4.5 usec in duration. The duration does not vary with step rates. The "fast" step rate is 12 msec. The slow step rate is about 50 msec (!). Based on what I see, I do not believe signal quality is responsible for the behavior.
Can you share the oscilloscope screen capture ? The rising / falling rate maybe be important too.
Both edges are razor sharp and essentially vertical. This is a 100 Mhz. scope and I'd estimate the actual slew time to be on the order of ns. Transition speed probably exceeds the scope bandwidth. I'll see if I can figure out how to capture a shot, but there's not much chance the pulse quality is to blame.

snhirsch
Posts: 160
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch » Sat Jun 02, 2018 5:32 pm

Jeff wrote:
Sat Jun 02, 2018 5:06 pm
snhirsch wrote:
Sat Jun 02, 2018 2:40 pm
You'd mentioned the input architecture before. The situation is not optimal, since the transition for logic 0 to 1 on a 3.3V device is at a lower level. Have you thought about a simple buffer board to use in difficult cases? Maybe Lotharek could offer such a device.
I think that Lotharek prefer to provide a complete floppy emulator solution which make more sense :wink:
snhirsch wrote:
Sat Jun 02, 2018 2:40 pm
To me, it is interesting that the slow step rate never shows a NO INDEX PULSE error. Even if a glitch occasionally causes a double-step (or missed step), why does the index pulse issue go away completely? Does the Gotek firmware pause sector pulses while responding to a step? If so, that is probably different behavior from a mechanical floppy. Maybe the slower step gives the Gotek more time to resume pulses?
How often have you this seek error message ?

Unfortunately have checked the stock here and there is some heathkit machines but no northstar machine :(...
The seek message occurs only on the slow seek rate and occurs about 4-6 x during the scan. But, as I mentioned the scan can never get past sector 592 with slow step rate! No matter how many retries I attempt it won't get by that sector. I can watch it seek back to track zero and step in over and over (that sequence is how I finally measured the step rate). I suspect the very slow rate is fooling the firmware: When a certain interval has gone by, it assumes stepping is done and starts presenting data even though more pulses are yet to come.

I do not think there's a reason to accommodate very slow step rates, but the fact that the NO INDEX PULSE errors aren't happening makes me wonder if the Gotek needs that extra time to settle into a good state after track change. More of a hint about the index pulse issues than a problem that needs to be addressed. I've never seen a step rate that slow on any other old machine. Usually the longest is around 30-35 msec.

snhirsch
Posts: 160
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch » Sat Jun 02, 2018 5:46 pm

I've been thinking more about the seek errors and I think I understand why we see them and not the index pulse errors with very long step timing. Since the diskette system will seek to zero and back to retry most types of low-level errors, tell me if this makes sense:
  • When reading a track that it's arrived at sequentially, the controller thinks it's missed an index pulse (the original error we've been fighting with).
  • Controller seeks back to zero, then steps in at a very slow rate.
  • At some point during this slow pulse train, firmware timer believes pulses are complete and goes into "provide track data" mode, but has not actually arrived at the expected track.
  • During transition to the data state, a pulse is missed since it arrives too soon for firmware to detect
  • Controller sees an unexpected track nibble and tries again and again.
  • Same series of events until retries are exhausted. Since the most recent problem is seek error, that's what gets displayed on the console.

Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Sat Jun 02, 2018 9:19 pm

snhirsch wrote:
Sat Jun 02, 2018 5:46 pm
I've been thinking more about the seek errors and I think I understand why we see them and not the index pulse errors with very long step timing. Since the diskette system will seek to zero and back to retry most types of low-level errors, tell me if this makes sense:
  • When reading a track that it's arrived at sequentially, the controller thinks it's missed an index pulse (the original error we've been fighting with).
  • Controller seeks back to zero, then steps in at a very slow rate.
  • At some point during this slow pulse train, firmware timer believes pulses are complete and goes into "provide track data" mode, but has not actually arrived at the expected track.
  • During transition to the data state, a pulse is missed since it arrives too soon for firmware to detect
  • Controller sees an unexpected track nibble and tries again and again.
  • Same series of events until retries are exhausted. Since the most recent problem is seek error, that's what gets displayed on the console.
The track change handler/tracking is asynchronus and always enabled. i don't think that the firmware is missing steps, but the error maybe indirectly generated by some index signal timing instability during track change : index event is maybe seen by the machine as an sector event or "vice & versa". i am almost sure that this is the case with the "no index pulse" error with the "fast" step.

I will check this tomorrow.

Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Sun Jun 03, 2018 10:54 am

Is this firmware working better, worst, or not at all :

http://hxc2001.com/vrac/HS/HxCUSBFE2.UPD

(try it with the 6.hfe image in normal step rate & slow step rate).

snhirsch
Posts: 160
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch » Sun Jun 03, 2018 3:06 pm

Jeff wrote:
Sun Jun 03, 2018 10:54 am
Is this firmware working better, worst, or not at all :

http://hxc2001.com/vrac/HS/HxCUSBFE2.UPD

(try it with the 6.hfe image in normal step rate & slow step rate).
Definitely progress!

On sequential surface scans with fast step, it gets all the way through without errors about 1/3 of the time. On slow step, it always passes (I quit after 10 tries). However, when copying files from the emulated disk both step rates show repeated errors. Since CP/M is constantly returning to the directory track I'm guessing that multi-track seeks are triggering the problem now.

But, the fact that surface scan passes at all is a BIG step. That's the first time I've ever seen it work :-) Hopefully this is helpful in figuring out an overall solution.

Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Sun Jun 03, 2018 8:52 pm

Ok. (which error do you still have ?)

Is this firmware working better, worst, or not at all versus the HxCUSBFE2.UPD :

http://hxc2001.com/vrac/HS/HxCUSBFE3.UPD

snhirsch
Posts: 160
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch » Sun Jun 03, 2018 9:46 pm

Jeff wrote:
Sun Jun 03, 2018 8:52 pm
Ok. (which error do you still have ?)

Is this firmware working better, worst, or not at all versus the HxCUSBFE2.UPD :

http://hxc2001.com/vrac/HS/HxCUSBFE3.UPD
Sorry. When they occur, errors are NO INDEX PULSE. Have not seen any seek error with firmware 2 or 3.

The good news:

Version 3 firmware is much improved in every respect. Surface verification now runs to completion at fast step rates and slow. I made 8 passes with each and saw no errors. File copying at fast step rate is still very problematic with dozens of NO INDEX PULSE errors - always on the first sector of the track (Sector 0, 10, 20, etc). File copying with slow step is mostly working! I copied the entire contents of the emulated floppy to the hard drive 5 times in a row and saw only a single NO INDEX PULSE error. All but one bulk copy operation ran error-free.

So there's still a problem when performing multiple-track seeks at 12 msec. rates. But everything is moving in the right direction - thanks very much! It seems we are close :-).

Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Sun Jun 03, 2018 10:51 pm


snhirsch
Posts: 160
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch » Mon Jun 04, 2018 12:05 am

Jeff wrote:
Sun Jun 03, 2018 10:51 pm
And with this one ? :

http://hxc2001.com/vrac/HS/HxCUSBFE4.UPD
This one seems to have been a step in the wrong direction. It fails surface scan at both step speeds. Many errors copying out files at both speeds. Always NO INDEX PULSE.

Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Mon Jun 04, 2018 7:37 am


snhirsch
Posts: 160
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch » Mon Jun 04, 2018 1:37 pm

Jeff wrote:
Mon Jun 04, 2018 7:37 am
And with this :
http://hxc2001.com/vrac/HS/HxCUSBFE5.UPD
This is somewhere in between 3 and 4. File copy using fast step is not as bad as 4, but sequential scan using fast step is almost hopeless (gave up after ten errors or so). Neither file copy nor scan is as good as 3 using slow step - scan shows 4-6 errors and file copy about the same.

Error are always NO INDEX PULSE.

Jeff
Site Admin
Posts: 6698
Joined: Fri Oct 20, 2006 12:12 am
Location: Paris
Contact:

Re: Hard sector format

Post by Jeff » Mon Jun 04, 2018 2:15 pm

a new try :

https://hxc2001.com/vrac/HS/HxCUSBFE6.UPD

(can you try 1.hfe as well 6.hfe with this firmware ?)

Post Reply