> On 2018-03-05, at 22:21, Francesco Messineo <francesco.messineo@gmail.com> wrote: > >>> I would expect that cbmlink just writes sectors, starting from 1,0 and >>> ending to 35,16. I don't think it even knows about directory, BAM and >>> so on. On a 1541, even disk id (the two characters you give at format >>> time) gets changed from the .d64 image. On a 3040 they don't. >>> I don't know how much "metadata" is present on a .d64 image though. >> >> D64 is a high-level image so it doesn't contain low-level metadata. Disk ID for example is stored in sector headers during formatting, not only in directory. Actually that one, visible in the directory listing is less important ;-) To preserve the low-level metadata you'd need to use G64 rather than D64. Also have a look at: > > yes, I knew about disk ID being stored in every sector's header. I > thought that the cbmlink server part could overwrite the sector > headers, but maybe it's only changing the ID stored in 18,0. > The fact that the 3040 doesn't write anything in 18,0 when used > through cbmlink is still annoying though. I am still unconvinced/unsure whether it "doesn't write anything" or writes only the high-level data in a 1541 style, which is kind-of-fine[*] for 1541 but not enough for 4040. >> http://e4aws.silverdr.com/project64/incdos/ >> >> Section 3.3 * - it actually may cause unnoticed discrepancies for example between the visible and the actual ID. -- SD! - http://e4aws.silverdr.com/ Message was sent through the cbm-hackers mailing listReceived on 2018-03-05 23:06:52
Archive generated by hypermail 2.2.0.