Corrupted prodos image?

[Keatah]

Can someone compare or take a look at this disk image and see if it's supposed to be this way or if it's corrupted? The problem is the helpscreens file, Copy II+ doesn't copy it correctly, and ciderpress says it's 12MB. The disk isn't copy protected, and I don't see any reason for the file to be like so.

 

Such is the sad state of affairs of the Apple II archives. I've been going through them and this is just one of many on asimov that seem to be dumped incorrectly. I'd estimate 20% of all disks in the Apple II ecosphere are dumped incorrectly. Others would say it's much higher.

 

Anyhow, here is the image.

ftp://ftp.apple.asimov.com/pub/apple_II/images/masters/prodos/prodos_basic.dsk

[david__schmidt]

Hmm, I'm not sure what I'd call into blame here - the image does seem to be corrupted, as that filesize is nonsensical. Should we throw up our arms in defeat? Should we cry and wail in the streets? Is there no hope for humanity?

[Keatah]

All hope is lost!!

[+OLD CS1]

[Keatah]

I guess the little fucker isn't corrupted. The file works exactly as intended. *I* must be getting rusty-n-crusty.. And I cross-verified it with other images from another source!

 

Ciderpress seems to be in error or doesn't know what to do with it.

 

IDK, IDC, IDGAF!

Edited May 24, 2016 by Keatah

[The Usotsuki]

Sparse file, maybe? *didn't look*

[david__schmidt]

Nope, CiderPress is reporting the bytes it sees on the image. AppleCommander reports the same thing. Whomever wrote that file put those bytes in the file length portion of the filesystem structure. It's unlikely ProDOS would have done that on its own, so somebody/something changed the bytes after PD created the file. (It's reported as a Tree, by the way.)

[Keatah]

My mistake on Copy II+. C2+ reports a reasonable space of 60 blocks. And it copies the file correctly.

 

This is a dump of the file, and it's filled with $00, interspersed with snippets of command descriptions for the help system. Just load the file with a hex editor or word processor and search for "a" to find them.

 

On the disk image you "brun help" and then type "help bsave", for example, to get help on the bsave command.

 

Perhaps it is indeed a sparse file? but why would it be made as such?

HELPSCREENS.zip

[a2jer]

The file is just dumped in DOS-order, as opposed to ProDOS order. In ProDOS order, the directory block 2 would start at offset 0x400 in the file, but with DOS-order it starts at 0xB00. Basically, within each track, the 256-byte sectors are rearranged as 0, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 15, which means ProDOS blocks 0-7 are composed of sectors:

block 0: 0, 14

block 1: 13, 12

block 2: 11, 10

block 3: 9, 8

block 4: 7, 6

block 5: 5, 4

block 6: 3, 2

block 7: 1, 15

 

I'm surprised Ciderpress doesn't recognize it.

 

Here's the catalog:

/EXAMPLES
*PRODOS SYS $2000 30 14848 1984-Sep-18 00:00
*BASIC.SYSTEM SYS $2000 21 10240 1984-Jun-18 00:00
*STARTUP BAS $0801 7 2794 1984-Jul-26 09:12
*HELP BIN $2000 5 1537 1983-Oct-01 00:00
*HELPSCREENS TXT $0200 60 12358656 1983-Oct-01 00:00
*PRACTICE DIR 1 512 1983-Oct-01 00:00
*PROGRAMS DIR 3 1536 1983-Oct-01 00:00
*DATA DIR 1 512 1987-Oct-16 23:11
*EXTRAS DIR 1 512 1983-Oct-01 00:00
*DIRECTORY DIR 1 512 1983-Oct-01 00:00
Free space: 34 blocks

Yes, HELPSCREENS is a sparse file.

Edited May 25, 2016 by a2jer

[Keatah]

I opened up an issue at ciderpress:

https://github.com/fadden/ciderpress/issues/15#issuecomment-222099157

 

Ciderpress cannot copy/paste that file. It results in errors back on the native Apple II side of things. But other native Apple II copy programs can handle it just fine like the venerable Copy II+, v8.4 or v9.1. I also used the original FILER program from Apple on the original ProDos 1.1.1 User's Disk.