• Please review our updated Terms and Rules here

Problem 8" disk with complementary format

fritzeflink

fritzeflink

Experienced Member
Joined
May 19, 2014
Messages
219
Location
germany
Hi ..
sad I just made a false klick and now have to type all new.


I have a lot of 8" floppydisk to read and thought that's no problem as I have the format definitions in my archive
and 22disk will do the work.

No - I got an error from 22disk
* WARNING? * Two files found to use same diskette block
-- You may be using the wrong disk definition Block: 0002, File: BCHARIO.ASM
Click to expand...

An other problem is that the format is complementary (?) and only Anadisk with his [F7] is a small help.
I have a German software 22disk which even doesn't like to open the floppy directory. That's horrible as I haven't thought about such problems.

My format definitions are for SS and DS:

BEGIN KRA2 Krause 2 ECB CP/M3 - SSDD 15x512 8"
DENSITY MFM ,HIGH
CYLINDERS 77 SIDES 1 SECTORS 15,512
COMPLEMENT
NOTE SKEW 4
SIDE1 0 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
note SIDE1 0 1,5,9,13,2,6,10,14,3,7,11,15,4,8,12
BSH 4 BLM 15 EXM 0 DSM 281 DRM 191 AL0 0E0H AL1 0 OFS 2
END

BEGIN KRA3 Krause 3 ECB CP/M3 - DSDD 15x512 8"
DENSITY MFM ,HIGH
CYLINDERS 77 SIDES 2 SECTORS 15,512
COMPLEMENT
ORDER EAGLE
NOTE SKEW 4
SIDE1 0 1,5,9,13,2,6,10,14,3,7,11,15,4,8,12
SIDE2 1 1,5,9,13,2,6,10,14,3,7,11,15,4,8,12
BSH 4 BLM 15 EXM 0 DSM 569 DRM 191 AL0 0E0H AL1 0 OFS 2
END
Click to expand...

As I could read a lot of files I now have a source and the format definitions from *FDC.PRN in the KRAUSE.ZIP file.
Making images with IMD is no problem (included in krause.zip) but as the format is 'complement' I have no chance to
see what files are directed to the same block.

DPB2 DPB 512,15,154,2048,192,2 ; 8" 77 TRK DS DD
0022+3C00 DW ??0033 ; 128 BYTE RECORDS PER TRACK
0024+040F DB ??0034,??0035 ; BLOCK SHIFT AND MASK
0026+00 DB ??0036 ; EXTENT MASK
0027+3902 DW ??0037 ; MAXIMUM BLOCK NUMBER
0029+BF00 DW ??0038 ; MAXIMUM DIRECTORY ENTRY NUMBER
002B+E000 DB ??0039,??0040 ; ALLOC VECTOR FOR DIRECTORY
002D+3000 DW ??0041 ; CHECKSUM SIZE
002F+0200 DW 2 ; OFFSET FOR SYSTEM TRACKS
0031+0203 DB ??0042,??0043 ; PHYSICAL SECTOR SIZE SHIFT
Click to expand...

Can anybody help and brings me into the right direction ?

Is this an error by the original system writing the flopydisks or do I have a false format definition or anything else ?
 

Attachments

  • SCcopy-formate.pdf
    38 KB · Views: 1
  • krause3-ct.jpg
    krause3-ct.jpg
    223.3 KB · Views: 9
  • KRAUSE.zip
    609.3 KB · Views: 9
  • hc_1152.jpg
    hc_1152.jpg
    144.6 KB · Views: 9
  • reading_old_floppies.jpg
    reading_old_floppies.jpg
    658.4 KB · Views: 8
Last edited:
Chuck(G) said:
Unless someone beats me to it, I'll have a look at the image this weekend. Sounds like an issue with EXM, but that's just a guess.
Click to expand...

Thanks, if you like to get more images please call.
A other point for me is the complement which denies my try to understand whats happen.

Interesting from the source there is a possibility to switch what kind of writing to disk was able.



1681574635762.png
 

Attachments

  • FDC-PRN.zip
    21.3 KB · Views: 0
Hello,

Don't know what will help, but I've played a lot with 22DISK, and IMD images, and other images.

I've got the zip file, and I see the BIN/TXT version of the image near the top. Don't know if this is the important one.

Yes, I can see that the data is NOT-ed, i.e. all 1 bits swapped to 0, and 0 to 1. So I can recognise DIR entries, and the first byte that should - I expect - by 0 for User 0 shows as FF.

I can easily write a little QB prog to flip all the bytes in the file, so that the data can be viewed correctly.

If that looks OK, then another QB prog to read all the DIR entries, and verify the DIR re ALLOC blocks, and answer at least 1 question, is theImage OK, or does the problem come from the original or the image process.

As Chuck suggests, maybe the problem is one of the 22DISK format parameters? But not easy to tell from the data now!

Geoff
 
Here's the .bin file, flipped, if you want to have at it--22DISK uses the COMPLEMENT keyword to do the same.
 

Attachments

  • krausenot.zip
    203.9 KB · Views: 6
GeoffB17 said:
I can easily write a little QB prog to flip all the bytes in the file, so that the data can be viewed correctly.
Click to expand...

That will be nice. I used Powerbasic 30 years ago so it's like a new toy for me and I have learn to use it again.
 
Aha - Chuck already done the flip. I'll get his file and look at that, maybe still need to do something with the ALLOC thing.

Re PowerBasic - see another thread here re BASIC/z, which I think was a predecessor of PowerBASIC? Don't know how similar the two systems are??

Geoff
 
Yes, the image file is perfectly readable now. Esp re the Dir sectors (apart from the interleave making it's own complications) Alloc blocks look OK, but the DIR data starts with block 2, that means blocks 0 and 1 for directory. Need to work out how many sectors per block and see if numbers tie up. There's a fair bit of empty DIR space.

Geoff
 
The various parameters seem to tie up, apart from the bit mentioned.

AL0 shows E0, which indicates that the DIR has 3 blocks, and this agrees with the 191 DRM. And everything ties up with the 2k Allocs.

BUT, the first file in the DIR shows it uses Allocs 2, 3 and 4. But 2 is part of the directory? Although there are not enough files in the dir that the dir actually uses this space!

Also, the first file in the dir is BCHARIO.ASM, 4992 bytes, which is just over 2 Allocs, so it needs 3, which the DIR says it has.

this file is present in the unloaded listing, shows 4992 bytes, and looking at the file it has a reasonable-looking start, middle and end. So seems to be complete.

I'd try change the 22DISK def to DRM = 127, and AL0 to C0, i.e. the DIR space is 2 allocs not 3.

Chuck - is it possible that 22DISK woild read the file anyway from Alloc 2, even though this is really the dir space, but give a warning re defn being wrong?

Geoff
 
I'm not exactly sure that E0 is the correct for AL0. Should be C0 by my reckoning. Let me make a real disk (in uncomplemented form and have a look at it.

P.S. It's a lovely spring day today and I hate to waste it on bits.
 
Fritz,

The disk we've been looking at has about 70 files on it, not all the files in the zip were on the disk. A couple of the files are bigger than 1 extent (i.e. HELP data) but still 70 something dir entries. So the 128 reduced to will still be OK.

BUT you say you have a number of disks to check. Is it possible you might have some with one format, and some with the other? Take care of that. Can easy change the format back to the original settings. Those settings change whether Alloc 2 is part of the dir space, giving 192 dir entries, or part of the data space, with 128 dir entries. Or amend the DEF file for 22DISK to create a new entry

Geoff
 
Fritz,

I would suggest making the same change to the SD format as well. Will not hurt anything.

If one of these disks DID happen to use more than 128 files (extents) then depending on the order in which things were written to the disk file data or dir data written to alloc block 2 would be damaged/overwritten leading to significant problems.

By the way, which version of PowerBasic were you using - CP/M or DOS?

Geoff
 
Looking at the sample, I'm unable to determine if this is a single-sided or double-sided format. The second side is formatted, but the first side is not yet filled. Do you have a sample even close to full?
 
I will do but need some time.

switching on my dos machine I noticed that on drive D: are filesystem problems and scandisk is repairing a lot of the directory structure.
I'll save the bad d: onto scsi drive and then restore it from a backup a week ago. Saving because I will use the IMD descriptions and not type them again.
I believe it was to late yesterday and maybe the system was below win3.1 in Norton Commander as I switched it of.
This is the 1st. time scandisks has to repair on every boot in the moment since several years but say never Never. :devilish:
 

Attachments

  • chk.jpg
    chk.jpg
    255.5 KB · Views: 3
Now I got a DSDD floppy which shows me no errors in 22disk even as the SSDD from above - this is good but I'm :confused:
 

Attachments

  • kra014_without_error.zip
    715.9 KB · Views: 5
What is curious is that with ANADISK I see that the directory is block 0 and 1 = 2x2048/32 = 128 dir entrys.

From the PRN the DPB was made by DRI MACRO the info of DRM=191 but may be false as there are only 2 blocks for DRM
and even ALOC can not be E0 as this are 3 blocks which isn't schown by ANADISK.
Maybe the source isn't identical to the images ?
 
Hello,

Remember, we're talking about two (or even three) different things here.

We have the parameters that have been used when the disk was created, which should be reflected by the arrangement of the data on the disk. These parameters may (should ?) be hard-coded into the BIOS of your machine? In the DPB?

Then there are the parameters which are part of 22DISK, which reflect what the disk format is believed/thought to be - if these are correct, then the disk should be read correctly by 22DISK, it they're wrong, then there will be problems, the extent/degree of which will depend on how wrong the 22DISK parameters are.

For the disk we were looking at yesterday, it seems that there was a difference between the two. The 22DISK parameters seem to be wrong, saying there were three DIR blocks when in reality there were two only. You didn't confirm if you had made that change, and if the disk then read correctly.

If you use ANADISK, you will look at what is actually on the disk, and yes, for that disk, this SHOULD show that there are 2 blocks ONLY of DIR, and 128 DIR entries.

I'm assuming that you are using REAL disks here. Is that so? If you're using images, when/how were they made? You referred to images before, but I was thinking these were images you made from real disks you have. IMD should not alter in any way the data that is on the disk, and it is merely reading tracks/sectors on the disk and would take no notice of the parameters we're discussing.

If a mis-match between the parameters goes back to an earlier stage, then this compounds the problem. Need to clear this up.

Geoff
 
You must log in or register to reply here.
Back
Top