simonowen / samdisk Goto Github PK
View Code? Open in Web Editor NEWA portable disk image utility, specialising in copy-protected PC-compatible formats.
Home Page: http://simonowen.com/samdisk
License: MIT License
samdisk's People
Contributors
Stargazers
Watchers
Forkers
d235j yang123vc shattered ieure glennneiger ubuntu-repo peterbortas angeldevindie mrandreastoth gnaray hjkitsamdisk's Issues
Copying a disk with '-d' option enabled copies every fourth track to destination image
How to demo:
- convert raw image to EDSK (I've used a 1228800 byte file filled with random data).
samdisk convert test.raw test.dsk
- scan the result and observe 80 valid tracks
80 Cyls 2 Heads:
500Kbps MFM, 15 sectors, 512 bytes/sector, gap3=80:
0.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1.0 15 1 2 3 4 5 6 7 8 9 10 11 12 13 14
2.0 14 15 1 2 3 4 5 6 7 8 9 10 11 12 13
3.0 13 14 15 1 2 3 4 5 6 7 8 9 10 11 12
<...>
- copy EDSK using '-d' option
samdisk copy test.dsk test-d.dsk -d
- scan the result and observe 20 valid tracks (40 were expected)
40 Cyls 2 Heads:
500Kbps MFM, 15 sectors, 512 bytes/sector, gap3=80:
0.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
500Kbps MFM, 15 sectors, 512 bytes/sector, c=4, gap3=80:
1.0 12 13 14 15 1 2 3 4 5 6 7 8 9 10 11
500Kbps MFM, 15 sectors, 512 bytes/sector, c=8, gap3=80:
2.0 8 9 10 11 12 13 14 15 1 2 3 4 5 6 7
<...>
Latest nightly release (20200607 Build) fails to convert 3" SCP copy protected disks
Previous nightly dated 20200429 Build works fine. Not sure if the change to read single sided SCP has broken this. Also the last stable release doesn't convert some 3" SCP disks.
I test the conversions using RetroVirtualMachine and FUSE. FUSE just crashes and RVM just fails to load. Those converted with nightly build work fine in both.
Using a hex editor it seems to be adding 2 sides to the converted DSK which should only have 1
KryoFlux device writing is not supported
It's possible to read directly from KryoFlux devices but not write to them, as only the read commands are understood.
The KryoFlux device creators do not provide a library or any documentation on how to drive the device from 3rd party software. The only officially supported method is to use the dtc application, either directly, or spawned from 3rd party applications to do the work. This gives little control over the process and is not an attractive solution for SAMdisk.
The only alternative is to reverse-engineer the USB protocol used by the dtc application and use the same requests directly. This has been completed for reading support only, with further work required to identify the commands and surrounding behaviour. The limited on-board buffering also requires USB streaming mode to be used to keep sufficient buffers queued up to avoid underflow during the process.
The current lack of write support is mostly due to the effort required to reverse-engineer the remaining device commands, and the availability of a fully documented competiting product (SuperCard Pro), which already supports writing.
800KB raw images may be mis-detected as MGT
From a user report:
They are trying to write a 80x2x5x1024 (= 800KB) RAW image for a CP/M machine to floppy under Windows, and override sector size and count (-s5 -z3), however image is detected as MGT and these options are ignored. I suppose that MGT detection could be improved by checking magic numbers at a different offset?
"copy --repair" duplicates sectors if no offset data are present in one disk image
I have two images of a disk - a td0 and a scp; td0 has one bad sector which is OK in scp image. Disk itself is not available. But td0 stores no track length or offset data, so copy --repair doesn't merge identical sectors:
250Kbps MFM, 20 sectors, 512 bytes/sector:
0.0 1[r] 2[r] 3[r] 4[r] 5[r] 6[r] 7[r] 8[r] 9[r] 10[r] 1[r] 2[r] 3[r] 4[r] 5[r] 6[r] 7[r] 8[r] 9[r] 10[r]
Please support conversion to DMK format
As discussed via e-mail in December 2021. This format is (currently) used in openMSX as a low level format to support emulation of original disks with copy-protections in place.
SuperCardPro image format 1.6
Hi Simon,
Maybe you're interesting in supporting new SCP 1.6 feature (footer with some metadata):
http://www.cbmstuff.com/downloads/scp/scp_image_specs.txt
I made a PR for keirf/disk-utilities@a4cf19c and also added support in aaru-dps/Aaru@c50b49d
If you are too busy I can try to make you a PR if you want.
Regards!
"overlapped" sectors on Agat disks after commit f5d026d
After commit f5d026d, this happens:
% samdisk scan --agat a840-003.scp --scale=120 -c0 -h0
[a840-003.scp]
Cyl 0 Head 0:
250Kbps MFM, 21 sectors, 256 bytes/sector:
0.0 0[o] 1[o] 2[o] 3[o] 4[o] 5[o] 6[o] 7[o] 8[o] 9[o] 10[o] 11[o] 12[o] 13[o] 14[o] 15[o] 16[o] 17[o] 18[o] 19[o] 20[o]
I guess it's because code in Track::data_extent_bytes is designed for ISO MFM disks, can't think of a quick fix for that :)
Could you provide an updated nightly?
I want to test PC formats support, and have many GBs to test it, all formats not just ipf/kryo/img formats.
If you want to test some specific format just ask.
Thanks!
[samdisk 4.0 ALPHA] Segmentation fault on macOS writing to SD card
Samdisk version: 0dc6c8a, built locally.
$ sudo samdisk copy pxe-boot-client.dsk /dev/disk4:7
Reading cylSegmentation fault: 11
$
This is under macOS Ventura 13.0.1, with an Apple M1 Max.
$ uname -a
Darwin Peters-MacBook-Pro.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000 arm64
Under samdisk 3.8.8, the above samdisk copy command works without errors.
I realise samdisk 4.0 is in alpha, so maybe this is expected.
Thanks Simon!
"open: No such file or directory" on a certain SCP image
I have a directory full of SuperCard Pro image files (from an actual SCP device via its app). They all process just fine except for one random one which causes a cryptic error in SAMdisk 3.8.8 on macOS 10.14.6:
$ ./samdisk info test.scp
open: No such file or directory
$ file test.scp
test.scp: data
$ ./samdisk info test-404.scp
Error: invalid file: test-404.scp
I've renamed the file, moved it, checked permissions, etc. and it clearly seems to have something to do with the contents of the file rather than the file itself. Any idea what might be wrong?
std::bad_alloc can happen in scan_bitstream_mfm_fm()
I'm using a 96tpi drive to read disks written on a 48tpi drive - occasionally, data from adjacent even track are picked up on odd track and this confuses scan_bitstream_mfm_fm() -- for whatever reason, next_idam_distance / next_dam_distance is computed as zero, and then next_idam_align / next_dam_bytes become negative... Boom, allocation failure of -1 bytes :)
My workaround is
auto extent_bytes = std::max(0, read_gap2 ? next_dam_bytes : next_idam_bytes);
And offending track looks like this after it's applied:
[my80-021.scp]
Cyl 11 Head 0:
sync lost at offset 24458 (24458)
sync lost at offset 26313 (26313)
sync lost at offset 26941 (26941)
sync lost at offset 27803 (27803)
sync lost at offset 29407 (29407)
sync lost at offset 30096 (30096)
sync lost at offset 32933 (32933)
sync lost at offset 33349 (33349)
sync lost at offset 34354 (34354)
sync lost at offset 36178 (36178)
sync lost at offset 37013 (37013)
sync lost at offset 39884 (39884)
sync lost at offset 47924 (47924)
sync lost at offset 52307 (52307)
sync lost at offset 52958 (52958)
sync lost at offset 53368 (53368)
sync lost at offset 54002 (54002)
sync lost at offset 54453 (54453)
sync lost at offset 55682 (55682)
sync lost at offset 59939 (59939)
sync lost at offset 61139 (61139)
sync lost at offset 63952 (63952)
sync lost at offset 65050 (65050)
sync lost at offset 65345 (65345)
sync lost at offset 66055 (66055)
sync lost at offset 66376 (66376)
sync lost at offset 69493 (69493)
sync lost at offset 70353 (70353)
sync lost at offset 70983 (70983)
sync lost at offset 74575 (74575)
sync lost at offset 75346 (75346)
sync lost at offset 76459 (76459)
sync lost at offset 77233 (77233)
sync lost at offset 77826 (77826)
sync lost at offset 78954 (78954)
sync lost at offset 79840 (79840)
sync lost at offset 80144 (80144)
sync lost at offset 81576 (81576)
sync lost at offset 82276 (82276)
sync lost at offset 82864 (82864)
sync lost at offset 83465 (83465)
sync lost at offset 85680 (85680)
sync lost at offset 694 (694)
sync lost at offset 1996 (1996)
sync lost at offset 16580 (16580)
sync lost at offset 17845 (17845)
sync lost at offset 32449 (32449)
sync lost at offset 33725 (33725)
sync lost at offset 158723 (158723)
sync lost at offset 159820 (159820)
sync lost at offset 160114 (160114)
sync lost at offset 1233 (1233)
sync lost at offset 1666 (1666)
sync lost at offset 4870 (4870)
sync lost at offset 5242 (5242)
sync lost at offset 5912 (5912)
sync lost at offset 16246 (16246)
sync lost at offset 17909 (17909)
sync lost at offset 20855 (20855)
sync lost at offset 21358 (21358)
sync lost at offset 23097 (23097)
sync lost at offset 23925 (23925)
sync lost at offset 24236 (24236)
sync lost at offset 24514 (24514)
sync lost at offset 25606 (25606)
sync lost at offset 25926 (25926)
sync lost at offset 26388 (26388)
sync lost at offset 26981 (26981)
sync lost at offset 27668 (27668)
sync lost at offset 28457 (28457)
sync lost at offset 29945 (29945)
sync lost at offset 30491 (30491)
sync lost at offset 31368 (31368)
sync lost at offset 31724 (31724)
sync lost at offset 39462 (39462)
sync lost at offset 42591 (42591)
sync lost at offset 60533 (60533)
sync lost at offset 62026 (62026)
sync lost at offset 63308 (63308)
sync lost at offset 69708 (69708)
sync lost at offset 71344 (71344)
sync lost at offset 87695 (87695)
sync lost at offset 89567 (89567)
sync lost at offset 90347 (90347)
sync lost at offset 93540 (93540)
sync lost at offset 95646 (95646)
sync lost at offset 97833 (97833)
sync lost at offset 98425 (98425)
sync lost at offset 100390 (100390)
* DAM (am=251) at offset 11079 (11079)
* IDAM (id=3) at offset 20103 (20103)
Finding cyl 11 head 0 sector 3:
sync lost at offset 1268 (1268)
sync lost at offset 1661 (1661)
sync lost at offset 5265 (5265)
sync lost at offset 16217 (16217)
sync lost at offset 17879 (17879)
sync lost at offset 21312 (21312)
sync lost at offset 23033 (23033)
sync lost at offset 23860 (23860)
sync lost at offset 24572 (24572)
sync lost at offset 24979 (24979)
sync lost at offset 25516 (25516)
sync lost at offset 26281 (26281)
sync lost at offset 27522 (27522)
sync lost at offset 28284 (28284)
sync lost at offset 28970 (28970)
sync lost at offset 29712 (29712)
sync lost at offset 30229 (30229)
sync lost at offset 31116 (31116)
sync lost at offset 31398 (31398)
sync lost at offset 33187 (33187)
sync lost at offset 35080 (35080)
sync lost at offset 38743 (38743)
sync lost at offset 41738 (41738)
sync lost at offset 58871 (58871)
sync lost at offset 60287 (60287)
sync lost at offset 60789 (60789)
sync lost at offset 61493 (61493)
sync lost at offset 67580 (67580)
sync lost at offset 69147 (69147)
sync lost at offset 75096 (75096)
sync lost at offset 84777 (84777)
sync lost at offset 86558 (86558)
sync lost at offset 87308 (87308)
sync lost at offset 88107 (88107)
sync lost at offset 89334 (89334)
sync lost at offset 90350 (90350)
sync lost at offset 92375 (92375)
sync lost at offset 93133 (93133)
sync lost at offset 94464 (94464)
sync lost at offset 95050 (95050)
sync lost at offset 97006 (97006)
* DAM (am=251) at offset 11060 (11060)
sync lost at offset 1239 (1239)
sync lost at offset 1677 (1677)
sync lost at offset 4887 (4887)
sync lost at offset 5259 (5259)
sync lost at offset 5930 (5930)
sync lost at offset 16268 (16268)
sync lost at offset 17934 (17934)
sync lost at offset 20944 (20944)
sync lost at offset 21391 (21391)
sync lost at offset 23144 (23144)
sync lost at offset 23618 (23618)
sync lost at offset 23984 (23984)
sync lost at offset 24303 (24303)
sync lost at offset 24581 (24581)
sync lost at offset 25690 (25690)
sync lost at offset 26482 (26482)
sync lost at offset 27079 (27079)
sync lost at offset 27781 (27781)
sync lost at offset 28589 (28589)
sync lost at offset 30141 (30141)
sync lost at offset 30706 (30706)
sync lost at offset 31986 (31986)
sync lost at offset 62165 (62165)
sync lost at offset 65074 (65074)
sync lost at offset 71718 (71718)
sync lost at offset 92507 (92507)
sync lost at offset 93325 (93325)
sync lost at offset 98773 (98773)
sync lost at offset 101180 (101180)
sync lost at offset 101783 (101783)
sync lost at offset 103751 (103751)
* IDAM (id=2) at offset 10309 (10309)
* DAM (am=251) at offset 11098 (11098)
* IDAM (id=3) at offset 20134 (20134)
Finding cyl 11 head 0 sector 2:
Finding cyl 11 head 0 sector 3:
* IDAM (id=2) at offset 10309 (10309)
* DAM (am=251) at offset 11098 (11098)
* IDAM (id=3) at offset 20134 (20134)
Finding cyl 11 head 0 sector 2:
Finding cyl 11 head 0 sector 3:
Warning: late track start on cyl 11 head 0 may indicate missing first sector
300Kbps MFM, 2 sectors, 512 bytes/sector, c=5:
11.0 2[dc,z] 3[nd]
6485: 644 1256 [5229]
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.