New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SCP files created with extra tracks #277
Comments
Also it says "end track 152" with only 77 tracks; additional info:
|
Your HxC tools are probably old. Try the beta version. |
Almost the same result, but with 99 instead of 101 tracks:
|
This is the start of the gw generated SCP file:
It clearly states $98=152 tracks instead of 77, although only 1 head is used. Therefore, the offsets to the track data is strange, every other offset is zero (for the missing second head). |
It's a HxC bug. It can't even load its own single-sided SCP files. The SCP image spec says that every other offset should be zero for a single-sided image. It's unclear whether track start/end/number values should be doubled or not. I double them. HxC doubles them. But HxC then seems to get confused about end track on import. Blame the SCP spec and lack of example image files -- HxC author is just as confused as I am. A simple workaround would be to convert to a format that doesn't anger tools authors. EG. kryoflux:
And import that to HxC. |
Also raise the bug with HxC. In the HxC gui I generated a single-sided IBM disk. 80 cyls. I exported as SCP. I then loaded the SCP. The disk now had 160(!) cyls. |
When I create an SCP file with gw, either by reading a disk or by converting an image to SCP, the tools from HxC (like the visual floppy) show me a disk with 101 tracks instead of 77 (8" floppy disk image) and won't recognise it as 8" disk with the error "This image doesn't fit on a 8" disk". The tracks 77-100 are empty, though. Is that a bug in gw or in the HxC tools?
The text was updated successfully, but these errors were encountered: