Files corrupted when extracted from DSK

[kolleykibber]

I'm trying to pull some files off a DSK image.  They are Maxam/Protext text files. Every time I try the ASCII files are corrupted (as I expect are the BIN files too). I've tried the DSK tool and RetroVirtualMachine on a mac.


I've tried a couple of different DSK files and get the same odd results. Usually the files are truncated, or sections of other files are inserted. The images read and run fine on the CPC and Emulators.


Is there a preferred tool for doing this kind of thing?

[SkulleateR]

I also use RVM (Mac) for this and never had any corrupted file ... works fine here ... can you upload an example DSK file ?

[Gryzor]

Can you post an image if it's not a personal one?


[EDIT] had left the page open while SkulleateR was asking the same

[kolleykibber]

Thanks for the quick replies! It's the v61.dsk file served up here:


https://www.cpcwiki.eu/imgs/a/af/BBS_Terminal_Source.zip


Just tried a fresh download, extract from RVM and if you look at BBSPROG. At the end there is :

Code Select Expand



,1
   LD (DY),HL
   ret      ;save Cursor pos in DY



If you load the same file from the DSK with Protext in the CPC, It finishes with 'end.'

[SkulleateR]

Hmm, just took the ANSI. file and it extracted fine with RVM ...

[kolleykibber]

The ANSI comes back with ok text, but a row of non printing characters added here (Using BBEDIT).



Could you give BBSPROG a go please?

[SkulleateR]

First of all I loaded up ANSI in Protext (Disk Version) on my CPC and there is no "end" there ... it's exactly the same as the extracted version ...


will try the other one ....

[SkulleateR]

Ok, this seems to be a file format thingy ? I just releaded the ANSI file onto an empty DSK file and the file is correct, even without the symbols at the end ....


UPDATE : there seem to be some codes inside the txt files that influences the export, I tried with old CPCEXT (MS-DOS) to extract the ANSI file and it only extracts 8KB from 22KB and stops then ....

[GUNHED]

Just tried a fresh download, extract from RVM and if you look at BBSPROG. At the end there is :

Had a quick run.. used an emulator and printed the file using FutureOS and this is what I got...



1 PRINT "Starting>>>"




ORG &5000
nolist


;       &400   BUFFER START
;   &1000   BUFFER END
;   &1060   SCROLL BACK START
;   &2000   Char/ansi fornt buffer
;   &3000   CHARSETS
;   &4000   DIRECTORY BUFFER
;   &4800   XMODEM
;   &4C00   CRC TABLES


;   &5000    graphics start
;   &7000   programme start
;   &9000   global data




;graphics unit start
gu equ &5000


;----------------------------------


org &6b00
   write "b:termdata.bin"
   read  "common"         ;common data




;---------------------------------


org &7000       
   write "b:termexc.bin" 
     read "main"
       read  "menus"
       read  "file"
       read  "xmodem"
       read  "rs232"
     read  "dataprog"


;----------------------------------
end.

[kolleykibber]

Thanks for all the testing!




I think i'll try to manually remove each file, sanitise it and then drop it into a new DSK and get it assembling.

[GUNHED]

Or try to load and then save it using Maxam's Editor for example.
Sometimes load/save does eliminate crazy (control) codes.

[mv]

I think the garbage at the end of the file comes from DSK file extraction tools that do not correct the file length for ASCII.

In the AMSDOS directory the size of a file is only stored as the number of 128 byte records:
https://www.cpcwiki.eu/index.php/Disk_structure
Rc stores the number of 128 byte records of the last used logical extent.

Non-ASCII files have an AMSDOS header with the "Real length" of the file:
https://www.cpcwiki.eu/index.php/AMSDOS_Header

ASCII files do not have such a header, &1a is used as an EOF marker in the last record (of up to &80 bytes) and the file is truncated.

CPCBasic does the job when drag&drop ZIP or DSK files onto the CPC screen window.
https://benchmarko.github.io/CPCBasic/cpcbasic.html?database=storage

(Just found a bug in the CPCBasic debug message, which should look like...
fnOnLoad: file: bbstext. meta: CPCBasic;A;0;683; imported
DiskImage.ts:633 readFile: ASCII file length 7680 truncated to 7594)

[GUNHED]

And Prowort files (+ some others) have file lengths precise to the byte (see DIR entry expansion). None of the PC tools does understand that.