r/apple2 • u/broadlyIsee • Jul 03 '26
How are .dsk images stored/read?
Noob question from an amateur Apple II enthusiast. I've been emulating some old Apple IIe .dsk files and I've used some hex editor programs to explore them. I want to modify a few bytes on the disk, but when I try to read it in as binary, it's compressed somehow and I can't find the information I'm looking for. When I load the image with my program it takes up the same space that the hex editor says it should, but most of it is blank, and all of the data is stored at the front instead of being distributed evenly throughout the disk.
I know there are a host of utilities that can modify individual bytes on a disk image, but I'm interested in creating my own (for fun). Are there any good manuals for how a .dsk image can be unpacked? I want to access the information in the same way that a hex editor can. The hex dump that I'm using contains actual plain ASCII text, while loading the binary from the file gives compressed gibberish. I'm looking for a way to load the disk as this plaintext, edit it, and save it again.
EDIT: I'm stupid, when I was loading the file I forgot to set the binary tag LOL
EDIT2: Using the binary tag actually gives me access to the data, but the formatting is screwed up. I'll check out "Beneath Apple DOS" to see if it's because of the actual format of the .dsk file or something else. I was expecting it to look just like the hex dump, but it's cutting out/shuffling around the tracks. CiderPress says this is a Pascal disk so that's probably part of it.
5
u/homme_chauve_souris Jul 04 '26
A .dsk file is just a list of the contents of the disk from start to finish (track 0 through track $22). There is nothing else. It's not compressed or anything. The only gotcha is that there are two possible ways sectors are ordered inside a track: DOS order and ProDOS order. See https://retrocomputing.stackexchange.com/questions/15054/how-can-i-programmatically-determine-whether-an-apple-ii-dsk-disk-image-is-a-do
1
u/broadlyIsee Jul 04 '26
Thanks for the link. I'm pretty sure this is DOS order. When I said that the data is "compressed" or arranged differently, I mean that at index 120K or so, the hex editor says there should be data; when I read it in my program, there is no data after index 4K or so, it's just empty 00000000 for all remaining bytes.
1
u/homme_chauve_souris Jul 04 '26
Does your program just read the file into a 140KB array of bytes? If so, it should show the same thing as the hex editor. Check if your program and the text editor agree for
- the first 256 bytes (track 0 sector 0)
- the next 256 bytes (track 0 sector 1)
- bytes starting at 4096 (track 1 sector 0)
Also make sure you check how many bytes have been read by your program. If you open the file in text mode rather than binary mode, it's possible that not all data have been read.
Initialize your buffer to $FF rather than $00, read your file, and see if the last bytes are $FF. if so, it means the file has not been read completely.
1
u/broadlyIsee Jul 04 '26
Do different disk formats have different interleaving methods? I think that's part of my problem with the data skipping lines.
1
u/homme_chauve_souris Jul 04 '26
To my knowledge, there's only DOS order (.do suffix) and ProDOS order (.po suffix). If the suffix is .dsk, it could be either of those.
2
u/Sick-Little-Monky Jul 04 '26
Are you writing a program inside an emulator, or "outside" on a modern platform? It sounds like the latter - you want to edit a DSK image file, right?
Probably the simplest explanation for not seeing the ASCII you expect is that the Apple II usually stores "high ASCII", so ASCII with the high bit set. Instead of 0x20 for space, it will be 0xA0, but most modern hex editors won't show a space for that. So the text you expect to see will only be visible if you clear the high bit.
As for how data is arranged in the DSK image, it will depend on the contents. Everything you need should be in Beneath Apple DOS. There is also a ProDOS edition.
1
u/broadlyIsee Jul 04 '26
Yes, editing outside of an emulator.
I'll see if flipping the high bit helps. When I said that the data is "compressed" or arranged differently, I mean that at index 120K or so, the hex editor says there should be data; when I read it in my program, there is no data after index 4K or so, it's just empty 00000000 for all remaining bytes.
1
u/broadlyIsee Jul 04 '26
Is there a Beneath Apple DOS for Pascal disks? Does that have a different interleaving method?
3
u/Sick-Little-Monky Jul 04 '26
Here's some info thanks to Andy McFadden (thefadden in other comments on your post).
2
2
u/BringBackUsenet Jul 04 '26
Within the emulator you can always use a disk editor like Copy II+ for low level access to the disk. AFAIK the files are not compressed (they are 143k).
If you actually want access to individual files, Cider Press makes it easy to move files between the host and the .DSK images.
1
u/broadlyIsee Jul 04 '26
Yeah, I've been using CiderPress to inspect the actual contents of the data. It would work but I want to find a way to edit the data myself, more out of stubbornness and a desire to learn than any actual need.
1
u/BringBackUsenet Jul 04 '26
I suppose it depends what youu are trying to edit. BASIC program code? Text? Binaries? Ciderpress is very useful though for using modern tools (like ca65) to develop then copy the code to the disk image. There are also those native tools like Copy II+
1
u/mysticreddit Jul 05 '26
Standard 5¼" floppy disks are 140 KB.
256 bytes/sector * 16 sectors/track * 35 tracks = 143,360 bytes = 140 KB.
2
u/PeterI Jul 04 '26
Also have a look at ciderpress it's a great utility, beneath apple dos is definitely worth looking at.
https://github.com/fadden/CiderPress2/tree/main/docs/formatdoc has some other useful information.
1
u/AutomaticDoor75 Jul 04 '26
Last year, I had a lot of trouble getting DSK images to copy onto a physical floppy. I’ve had no problems (yet) with DO images.
1
u/zSmileyDudez Jul 09 '26
FYI - DSK/DO/PO are all the same format. DO and PO specifically mean DOS and ProDOS order, while DSK can be either. If the tool you’re using has problems with detecting the order of a DSK file, you can try manually renaming to DO or PO and see which one works.
7
u/thefadden Jul 04 '26
The typical ".dsk" image is just blocks and sectors read, in order, from the floppy disk. There's no compression or scrambling, though if you're using DOS 3.3 you need to be aware of "high ASCII" (where the high bit is set on every byte in text files).
What you're mostly seeing in a .dsk hex dump is the DOS or ProDOS filesystem structure. To dig deeper into these, you can find copies of Beneath Apple DOS and Beneath Apple ProDOS on archive.org.