+- CBMSTUFF FORUM (https://www.cbmstuff.com/forum)
+-- Forum: CBMSTUFF PRODUCTS (https://www.cbmstuff.com/forum/forumdisplay.php?fid=1)
+--- Forum: SuperCard Pro (https://www.cbmstuff.com/forum/forumdisplay.php?fid=3)
+---- Forum: PC disks (https://www.cbmstuff.com/forum/forumdisplay.php?fid=11)
+---- Thread: Case of the "fat" SCP capture (/showthread.php?tid=441)
Case of the "fat" SCP capture - Jackson - 01-06-2018
Before you even ask-- I'm using a true 48TPI drive, reading at any density makes no difference, and I made sure that I chose the correct type.
Like any other issue that is related to this one, I'm stuck in the "all tracks are at one side" dilemma. The workaround right now is to use "C64/128" for capturing each side, but is there any way to reliably craft an image that combines each in one 80 track SCP capture? I don't want to waste time reading the spec and staring at a hex editor for hours straight.
EDIT: SCP is smart, HxC is probably dumb. See below.
RE: Case of the "fat" 360k SCP capture - admin - 01-06-2018
I will have to look into this when using a 48tpi drive. I always use a 96 tpi drive.
RE: Case of the "fat" 360k SCP capture - Jackson - 01-06-2018
Woops, the disk is actually 320K, but that shouldn't matter. It's DSDD any way. Here is what HxC gives:
https://i.imgur.com/y0iCHy4.png
The raw sector conversion from HxC, although, is properly beautiful and works in every emulator I've tried. I don't know where the issue lies exactly, and I haven't tried rewriting the image back to a regular DSDD diskette either.
RE: Case of the "fat" 360k SCP capture - Jackson - 01-06-2018
Ok, so the issue looks to be not that it's SCP's fault, but it's HxC. The specification says that there's a flag for both heads being used. HxC presumably does not take this to count, and therefore gets confused on which track goes where.
I have no idea how HxC is seeing my 1.44M captures correctly, though. I haven't looked in the HxC source code.