Let us know how it goes if you try method #2. Like I say, I expect the tag bytes issue will complicate things. I put even odds on Xenix using the first 512 bytes of each sector and discarding the remainder, so when you make your raw disk image, you may need to introduce twelve-byte gaps between every 512 bytes of data that you wish to copy. This should be pretty easy to detect, though. In case folks are following along, I'll spell things out.
I'd experiment with the help of a raw disk image that you generate with a Python program like this:
#!/usr/bin/python3
with open('/tmp/raw_image.bin', 'w') as f:
for _ in range(200):
for ch in 'abcd':
f.write(ch * 512)
f.write(ch.upper() * 12)
Copy the data in /tmp/raw_image.bin onto a disk or convert it to a .dc42 (I think utilities to do this are bundled with lisaem). Then, on the Lisa, dd a few kilobytes from the floppy in Xenix, e.g. dd if=/dev/<floppy device> of=/tmp/sample bs=1024 count=4. Investigate the resulting /tmp/sample file somehow, perhaps with od -c /tmp/sample | more (if od is present on Xenix):
- If you never see any uppercase letters, then Xenix ignores the last 12 bytes of each sector.
- If you see runs of 512 lowercase letters interleaved with runs of 12 uppercase letters, then Xenix uses the full sector.
- If you see runs of 500 lowercase letters interleaved with runs of 12 uppercase letters, then Xenix ignores the first 12 bytes of each sector.
If, for some inexplicable reason, you should ever find yourself in north Texas... let me know because I owe you a beer. It took some fiddling around with the sector size, but this worked swimmingly. Xenix does not appear to discard 12 bytes, though; it instead appears to discard 20. On attempt number two, I added an additional four capital letters to the first instance in the file (so, AAAAAAAAAAAAAAAA) and found that it was still discarding them. On attempt three, I incremented the hex values of the characters after the 16 AAAAs and checked for the character that did show up, which ultimately turned out to be the 21st byte in the sequence. I'm not adept or knowledgeable enough with filesystems at the elemental level to know if 20 bytes is reasonably expected or bananas crazy, but it looks like we have a winner. Maybe you could shed some light on whether or not that's "normal"?
Today was a long day at work, so I had just enough energy left in me to try this little experiment and call it a day. I'll take another swing at this tomorrow and see if I can get some tarred data moved over (like the C source for a tiny kermit client) and update with my results. Thank you again for the advice and test code - both were absolutely invaluable!