-
Notifications
You must be signed in to change notification settings - Fork 91
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
Non-zero-indexed track numbers not handled correctly #418
Comments
So this is a straightforward |
Yes, pretty much. In the image, track 0 contains sectors whose track number is 1. The GW then writes those to physical track 1, and not to physical track 0 where they should be. |
Just tested and it seems to work okay for me. This is using latest 1.16.3 Greaseweazle tools.
View a.scp in HxC and I see T1.0 sectors in physical track 0, etc etc. as expected. |
You're not trying to specify a |
Ah, I was using Greaseweazle tools 1.13 still. I'll see if I can still reproduce it with 1.16.3. |
Any update? |
The Philips P2000 uses a special version of the Amstrad CPC format, in which the tracks are numbered from 1 rather than from 0. This means that when you seek physically to track 0, you see sectors whose metadata says they belong to track 1. In image files, these are still presented as physical track 0, but the sector data in that track is labelled as track 1. I've attached an example DSK image of the P2000 Disk Basic where this can be seen, and a screenshot of HxE Floppy Emulator showing the aberrant track numbering.
P2000 Disk Basic.dsk.zip
When writing such an image with the Greaseweazle, the GW software seems to ignore the physical numbering of each track. The sectors whose data says track 1 are written to physical track 1, thereby leaving track 0 empty (or with whatever data was there previously). This creates a floppy that is not readable by the P2000.
HxE Floppy Emulator handles this format correctly, and can convert it to a raw flux format. The Greaseweazle is then able to write that raw flux file with no issues. GW only goes wrong when it's given a DSK file. The issue may also exist with other formats, but I have only encountered it with this one and there may not actually be any other machines with this odd kind of track numbering anyway.
The text was updated successfully, but these errors were encountered: