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