Hard sector format

HxC Floppy emulator support for all others computers...
Post Reply
snhirsch
Posts: 170
Joined: Tue Dec 08, 2015 1:42 am

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Thu May 31, 2018 7:33 am
snhirsch wrote:
Wed May 30, 2018 9:59 pm
And, when I dig a little deeper into the Northstar diskette layout, it turns out they have a logical sector skew of +5 - at least on CP/M formats. So, I was half-correct :-). The machine is indeed not fast enough to read contiguous sectors, but they handle it in the CP/M BIOS rather than through physical format. This is evident from the cpmtools 'diskdefs' used to access files in an NSI image:
Have you a KF dump showing this skew ?
It's done completely within the program logic of the CP/M BIOS. It is not relevant to how HxC or KF function. It's only important when adding files to or reading them from the NSI image. If you want to see the effect of it, find a section of text in the NSI image that extends further than one physical sector (512-bytes). If the continuation of that text happened to be on the same track, it will be found 5 sectors (2560 bytes) further in the image. This obviously does not apply if the data is continued on the next track.

Bottom line: Nothing you need to worry about unless you plan to add capability for extracting files from the NSI image. I mentioned it only to make the point that the computer was not able to read contiguous sectors. Logically staggering them allows enough time to read the next allocated sector of the file without waiting a full revolution. Every CP/M system I've ever encountered used a skew. My mistake was in assuming the Northstar applied a physical skew. We now know that isn't the case and that the skew is logically applied.

Have you made any progress on correcting the Northstar read errors?

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

Re: Hard sector format

Post by Jeff »

snhirsch wrote:
Thu May 31, 2018 2:01 pm
Have you made any progress on correcting the Northstar read errors?
No, didn't work on this yet. What can you tell me about the errors you got with the NSI-Based HFE files ? Is the error come at specifics sectors (at the track begin for example) or it is purely random ?

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Thu May 31, 2018 8:59 pm
snhirsch wrote:
Thu May 31, 2018 2:01 pm
Have you made any progress on correcting the Northstar read errors?
No, didn't work on this yet. What can you tell me about the errors you got with the NSI-Based HFE files ? Is the error come at specifics sectors (at the track begin for example) or it is purely random ?
Most of the sectors that show errors are multiples of 10, which means first sector on track. The third sector of the track also seems to appear more often than a random distribution would produce. I do not have the source for the linear read command, so I cannot say for sure whether it tries to read sectors in order or not. For whatever reason, sector "600" is very common over all the images I've tried.

The errors now are always "NO INDEX PULSE". One thought: Is it possible the controller state machine needs a "quiet" span on the media between the sector checksum and next index pulse in order to reset and start watching for that pulse? Are you generating anything during that interval? If so, remember that a hard-sector format has no trailer. For example, zero bytes in that interval may cause problems.

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

Re: Hard sector format

Post by Jeff »

The northstar format have a pseudo random part right after the crc. i currently only send a constant value, but i think that should generate the right pattern. i suspect that the crc generator is "used" to generate this pattern.

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Fri Jun 01, 2018 12:32 am
The northstar format have a pseudo random part right after the crc. i currently only send a constant value, but i think that should generate the right pattern. i suspect that the crc generator is "used" to generate this pattern.
Not quite following that. If you send a constant value, how does that generate a pseudo-random pattern? Does the current pattern extend to or over index? If so, it may be worth trying with a shorter pattern. Maybe a try with no trailer is worthwhile?

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

Re: Hard sector format

Post by Jeff »

snhirsch wrote:
Fri Jun 01, 2018 1:32 am
Jeff wrote:
Fri Jun 01, 2018 12:32 am
The northstar format have a pseudo random part right after the crc. i currently only send a constant value, but i think that should generate the right pattern. i suspect that the crc generator is "used" to generate this pattern.
Not quite following that. If you send a constant value, how does that generate a pseudo-random pattern? Does the current pattern extend to or over index? If so, it may be worth trying with a shorter pattern. Maybe a try with no trailer is worthwhile?
What i said is that there is a pseudo random part on the real media but for the moment i only generate a block with the same value.

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

Re: Hard sector format

Post by Jeff »


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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Fri Jun 01, 2018 6:09 am
New try :

https://hxc2001.com/download/floppy_driv ... CUSBFE.UPD

And all these images (try them one by one) :

https://hxc2001.com/vrac/HS/tests/n/
I wish I had better news, but I'm seeing NO INDEX PULSE errors on all of them. The one that comes closest to working is "6.hfe". The first time I read it, it threw only one error at sector 600. Subsequent times, I would see errors at 342 and 400 as well. Not entirely repeatable.

This shouldn't be so difficult. We must be missing something very fundamental. Or, possibly, something goes wrong with the emulation at times?

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

Re: Hard sector format

Post by snhirsch »

The default head-step rate on the Northstar is 12 msec, but it has an alternate slow setting of 24 msec (intended for very old drives). When I use the slow step rate, the error is different. Instead of "NO INDEX PULSE" I get "SEEK ERROR". I'm assuming this means the track nibble in the track/sector byte is not correct and the software believes it's on the wrong track. Why would a slower step pulse change things in such a manner? Even more interesting: With the slow head-step surface check gets to sector 592 and cannot proceed past that point regardless of how many times I retry. Could this indicate a timing issue in the firmware? It's also interesting that in 6 or 7 tries I never saw "NO INDEX PULSE" errors with the slow step.

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

Re: Hard sector format

Post by Jeff »

snhirsch wrote:
Sat Jun 02, 2018 2:46 am
The default head-step rate on the Northstar is 12 msec, but it has an alternate slow setting of 24 msec (intended for very old drives). When I use the slow step rate, the error is different. Instead of "NO INDEX PULSE" I get "SEEK ERROR". I'm assuming this means the track nibble in the track/sector byte is not correct and the software believes it's on the wrong track. Why would a slower step pulse change things in such a manner? Even more interesting: With the slow head-step surface check gets to sector 592 and cannot proceed past that point regardless of how many times I retry. Could this indicate a timing issue in the firmware? It's also interesting that in 6 or 7 tries I never saw "NO INDEX PULSE" errors with the slow step.
This seek error is odd. Are the terminations installed on the floppy bus ? Maybe there is some kind of signal overshoot/ringing on the step signal which make the emulator stepping twice or more time ? Have you an oscilloscope to check this ? (Check the step signal at the gotek connector)

One thing to not forget about the gotek : This is a bad hardware in many aspects and one of the those is the fact that there is no Schmitt trigger buffer on the inputs and that the "5V tolerant" 3.3v pins are directly connected to the floppy bus. Of course since we have here a 3.3V mcu these pins have not the normal TTL switching levels...

So care must be taken if we have a "noisy" floppy bus to avoid random stuffs.
And also the gotek floppy bus are 1Kohms versus 150 ohms for the original floppy drive.

I don't how long is the floppy ribbon but if possible can retry with a shorter ribbon (~20/30cm max).
(Signal ringing is related to the wire length)

again : if you have an oscilloscope please capture the falling and rising edge of the step signal.

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

Re: Hard sector format

Post by Jeff »

snhirsch wrote:
Sat Jun 02, 2018 1:50 am
I wish I had better news, but I'm seeing NO INDEX PULSE errors on all of them. The one that comes closest to working is "6.hfe". The first time I read it, it threw only one error at sector 600. Subsequent times, I would see errors at 342 and 400 as well. Not entirely repeatable.

This shouldn't be so difficult. We must be missing something very fundamental. Or, possibly, something goes wrong with the emulation at times?
In fact this is quite interesting because in the "6.hfe" the index came about 96us before the sector prelude. And this is seems to match the documentation saying that the recording is starting about 96us after the index hole. i have some hard time to believe that this is an "hard requirement" but if it does and if i need to match exactly this timing then yes there is improvement to do into the firmware.

I will see if i can borrow an northstar horizon/advantage. If possible this will make the development faster.

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

Re: Hard sector format

Post by Jeff »

A question : Are the Advantage & Horizon machines software compatible ? Can use the current floppy dumps on both machines ?

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Sat Jun 02, 2018 11:08 am
A question : Are the Advantage & Horizon machines software compatible ? Can use the current floppy dumps on both machines ?
The Horizon is an S100 bus computer that could use many types of disk controller. You would need to find one with a Northstar MDS-A-D controller to be compatible with the Advantage at a format level. Earlier Horizons used the "MDS-A" controller, which was FM only. Some Horizon owners used third-party soft-sector controllers. So, you'd need to find out what boards were in the machine.

The CP/M floppy dumps would probably not run on the Horizon, but should be readable if you have the right controller.

I have a Horizon and (2) Advantage machines, but shipment to France would be somewhat expensive :-).

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Sat Jun 02, 2018 8:43 am
snhirsch wrote:
Sat Jun 02, 2018 2:46 am
The default head-step rate on the Northstar is 12 msec, but it has an alternate slow setting of 24 msec (intended for very old drives). When I use the slow step rate, the error is different. Instead of "NO INDEX PULSE" I get "SEEK ERROR". I'm assuming this means the track nibble in the track/sector byte is not correct and the software believes it's on the wrong track. Why would a slower step pulse change things in such a manner? Even more interesting: With the slow head-step surface check gets to sector 592 and cannot proceed past that point regardless of how many times I retry. Could this indicate a timing issue in the firmware? It's also interesting that in 6 or 7 tries I never saw "NO INDEX PULSE" errors with the slow step.
This seek error is odd. Are the terminations installed on the floppy bus ? Maybe there is some kind of signal overshoot/ringing on the step signal which make the emulator stepping twice or more time ? Have you an oscilloscope to check this ? (Check the step signal at the gotek connector)

One thing to not forget about the gotek : This is a bad hardware in many aspects and one of the those is the fact that there is no Schmitt trigger buffer on the inputs and that the "5V tolerant" 3.3v pins are directly connected to the floppy bus. Of course since we have here a 3.3V mcu these pins have not the normal TTL switching levels...

So care must be taken if we have a "noisy" floppy bus to avoid random stuffs.
And also the gotek floppy bus are 1Kohms versus 150 ohms for the original floppy drive.

I don't how long is the floppy ribbon but if possible can retry with a shorter ribbon (~20/30cm max).
(Signal ringing is related to the wire length)

again : if you have an oscilloscope please capture the falling and rising edge of the step signal.
I'll see if I can capture the step signal at the drive. I'm using a newly built cable that's about 18" long, so I don't think length is an issue. Will double-check termination.

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.

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?

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

Re: Hard sector format

Post by snhirsch »

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.

Post Reply