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