Hard sector format

HxC Floppy emulator support for all others computers...
Post Reply
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:
Sun May 27, 2018 9:57 pm
Heath emulation on the Gotek is working!! I was able to copy all the files from a mostly full diskette image with no errors :-).
Perfect ! :D
snhirsch wrote:
Sun May 27, 2018 9:57 pm
If you have any updates to help with the Northstar issues, let me know and I'll try them.
Sure ! I have just tested the gotek with the latest firmware with the kryoflux :
All tracks are perfectly aligned and stable : no index jitter !

i have increased the index duration with this firmware :

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

let me know if this help or not.

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Sun May 27, 2018 10:33 pm
snhirsch wrote:
Sun May 27, 2018 9:57 pm
Heath emulation on the Gotek is working!! I was able to copy all the files from a mostly full diskette image with no errors :-).
Perfect ! :D
snhirsch wrote:
Sun May 27, 2018 9:57 pm
If you have any updates to help with the Northstar issues, let me know and I'll try them.
Sure ! I have just tested the gotek with the latest firmware with the kryoflux :
All tracks are perfectly aligned and stable : no index jitter !

i have increased the index duration with this firmware :

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

let me know if this help or not.
No, didn't really help. Conversion from KF is very bad with about a dozen errors. An HFE created from NSI file is a bit better, but still has 4-5 errors in linear read.

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:
Sun May 27, 2018 10:52 pm
Jeff wrote:
Sun May 27, 2018 10:33 pm
snhirsch wrote:
Sun May 27, 2018 9:57 pm
Heath emulation on the Gotek is working!! I was able to copy all the files from a mostly full diskette image with no errors :-).
Perfect ! :D
snhirsch wrote:
Sun May 27, 2018 9:57 pm
If you have any updates to help with the Northstar issues, let me know and I'll try them.
Sure ! I have just tested the gotek with the latest firmware with the kryoflux :
All tracks are perfectly aligned and stable : no index jitter !

i have increased the index duration with this firmware :

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

let me know if this help or not.
No, didn't really help. Conversion from KF is very bad with about a dozen errors. An HFE created from NSI file is a bit better, but still has 4-5 errors in linear read.
With the conversion from KF, could you set the disk bitrate to 250000 with the edit tools before exporting to HFEv3 ?

EDIT: Which dump are you using ? I will convert it with various parameters change and send you some HFEv3 to test.

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

Re: Hard sector format

Post by snhirsch »

Mark Garlanger: We are seeing a case where Heath CP/M diskettes created from H8D are working in the Gotek emulator, yet HDOS diskettes only function if converted from a raw Kryoflux capture. HDOS emulation created from H8D starts to boot, then halts with an error:

?00 Read error during boot
Boot aborted

That message appears to be from HDOS, so clearly it is making some headway in the bootstrap process.

Is this because of a missing HDOS volume header? If so, can you help us out and explain what it is and why it's important?

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Sun May 27, 2018 11:40 pm
With the conversion from KF, could you set the disk bitrate to 250000 with the edit tools before exporting to HFEv3 ?

EDIT: Which dump are you using ? I will convert it with various parameters change and send you some HFEv3 to test.
Setting bitrate did not help (Note: There are (2) bitrate options - unclear what the difference is, so I applied both).

I just uploaded the KF dump in question as ns003.tar.gz

MarkGarlanger
Posts: 9
Joined: Sat May 19, 2018 6:04 pm

Re: Hard sector format

Post by MarkGarlanger »

snhirsch wrote:
Mon May 28, 2018 12:11 am
Mark Garlanger: We are seeing a case where Heath CP/M diskettes created from H8D are working in the Gotek emulator, yet HDOS diskettes only function if converted from a raw Kryoflux capture. HDOS emulation created from H8D starts to boot, then halts with an error:

?00 Read error during boot
Boot aborted

That message appears to be from HDOS, so clearly it is making some headway in the bootstrap process.

Is this because of a missing HDOS volume header? If so, can you help us out and explain what it is and why it's important?
Yes, CP/M always has a volume number of "0". On HDOS, in order to read the boot track, the volume number on track 0 is 0. But the volume number on tracks 1-39, are as specified on the boot track. Sector 10 on track 0, is the Label Identification Sector. The first byte of that sector should be the volume number used on the rest of tracks on the disk.

The lost of the volume number, checksums, and all the other info header block, was the motivating factor for creating the new H17Disk format. With H8D, either the user has to specify whether the disk is HDOS or CP/M or the program has to guess on what type of disk it is.

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

Re: Hard sector format

Post by Jeff »

Ok thanks !

I have just updated the hxc library to handle these special cases :

https://hxc2001.com/download/floppy_driv ... t_beta.zip

Let me know if this solve the issue.

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Mon May 28, 2018 8:28 am
Ok thanks !

I have just updated the hxc library to handle these special cases :

https://hxc2001.com/download/floppy_driv ... t_beta.zip

Let me know if this solve the issue.
Sorry, same error. But, the message appears almost immediately now so something has changed. Previously there was a 10-15 second delay before the error.

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

Re: Hard sector format

Post by snhirsch »

MarkGarlanger wrote:
Mon May 28, 2018 5:37 am
snhirsch wrote:
Mon May 28, 2018 12:11 am
Mark Garlanger: We are seeing a case where Heath CP/M diskettes created from H8D are working in the Gotek emulator, yet HDOS diskettes only function if converted from a raw Kryoflux capture. HDOS emulation created from H8D starts to boot, then halts with an error:

?00 Read error during boot
Boot aborted

That message appears to be from HDOS, so clearly it is making some headway in the bootstrap process.

Is this because of a missing HDOS volume header? If so, can you help us out and explain what it is and why it's important?
Yes, CP/M always has a volume number of "0". On HDOS, in order to read the boot track, the volume number on track 0 is 0. But the volume number on tracks 1-39, are as specified on the boot track. Sector 10 on track 0, is the Label Identification Sector. The first byte of that sector should be the volume number used on the rest of tracks on the disk.

The lost of the volume number, checksums, and all the other info header block, was the motivating factor for creating the new H17Disk format. With H8D, either the user has to specify whether the disk is HDOS or CP/M or the program has to guess on what type of disk it is.
Mark, by "..first byte of that sector" (speaking of sector 10, track 0), do you mean "first byte of the data field"? Or is that label byte part of the header?

Update: Jeff, I think there will need to be control to decide whether to label as HDOS or not - unless you can find an algorithm to recognize it automatically.

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:
Mon May 28, 2018 3:01 pm

Update: Jeff, I think there will need to be control to decide whether to label as HDOS or not - unless you can find an algorithm to recognize it automatically.
This is of course what is done in the last update.

Here is the modifications :

https://sourceforge.net/p/hxcfloppyemu/code/1563/

Are you sure that you have the updated dll ? (v2.8.17.3)

EDIT : Silly me ! I forgot to push the correct volume ID to the CRC... This explain the issue with this latest version.

EDIT 2: Should be fixed now : https://hxc2001.com/download/floppy_driv ... t_beta.zip

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Mon May 28, 2018 4:48 pm
snhirsch wrote:
Mon May 28, 2018 3:01 pm

Update: Jeff, I think there will need to be control to decide whether to label as HDOS or not - unless you can find an algorithm to recognize it automatically.
This is of course what is done in the last update.

Here is the modifications :

https://sourceforge.net/p/hxcfloppyemu/code/1563/

Are you sure that you have the updated dll ? (v2.8.17.3)

EDIT : Silly me ! I forgot to push the correct volume ID to the CRC... This explain the issue with this latest version.

EDIT 2: Should be fixed now : https://hxc2001.com/download/floppy_driv ... t_beta.zip
Yes, that seems to have fixed it :-). Thanks! I was wondering if you had taken the header definition into account in the CRC. Easy to overlook.

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

Re: Hard sector format

Post by snhirsch »

I received a response back from Adam at Deviceside Data. I was mistaken in my understanding of the FC5025. The microcontroller is not fast enough to read sectors sequentially, so he reads even sectors first, then odd sectors. That's why I arrived at the incorrect conclusion about skew on the Northstar diskettes - sorry about that. Adam confirmed that the Northstar does not use any sector skew.

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:
Tue May 29, 2018 11:08 pm
I received a response back from Adam at Deviceside Data. I was mistaken in my understanding of the FC5025. The microcontroller is not fast enough to read sectors sequentially, so he reads even sectors first, then odd sectors. That's why I arrived at the incorrect conclusion about skew on the Northstar diskettes - sorry about that. Adam confirmed that the Northstar does not use any sector skew.
Yes this was what i suspected. A dump in stream mode can't hardly lie :wink:.

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

Re: Hard sector format

Post by snhirsch »

Jeff wrote:
Wed May 30, 2018 8:14 pm
snhirsch wrote:
Tue May 29, 2018 11:08 pm
I received a response back from Adam at Deviceside Data. I was mistaken in my understanding of the FC5025. The microcontroller is not fast enough to read sectors sequentially, so he reads even sectors first, then odd sectors. That's why I arrived at the incorrect conclusion about skew on the Northstar diskettes - sorry about that. Adam confirmed that the Northstar does not use any sector skew.
Yes this was what i suspected. A dump in stream mode can't hardly lie :wink:.
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:

Code: Select all

# Northstar Micro-Disk System MDS-A-D 350
diskdef northstar_d
  seclen 512
  tracks 70
  sectrk 10
  blocksize 1024
  maxdir 64
  skew 5
  boottrk 2
  os 2.2
end

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:
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 ?

Post Reply