My PCW with uIDE

[GeoffB17]

Hello All,


Things are going well with my PCW, now in it's second lease of life with JonB's add-on uIDE drives.


I had been using the machine with a 5.25" A: and a 720k B:, to give the maximum disk space, but now I've got the uIDE I've reverted to the 3" A: (still working PERFECTLY after Bryce's ministrations) with the 5.25 as B: (as it was originally from when I bought the B: back in 198?).


Gradually getting things set up with the DOM drives, which give oodles of space, and a very noticeable speed improvement too - pretty much like masses of RAMdisk but without the worry of it all vanishing whenever you reset/turn off the computer.   Working through a lot of 'house-keeping', sorting out languages/compilers etc, checking up on various things regarding the uIDE system generally.   Just been checking out that DU-V86 works fine with the drives, even to coping with the fact that the track ## just keeps on going up to 500!


Found one little oddity, that I'm still investigating.   The drives are 'advertised' as taking 512 directory entries (this include 'extents' for larger files - so it isn't necessarily 512 files.   BUT, it seems that there is really a limit of 464.   Discussed this with JonB, who suspects there must be something in the Amstrad/Locomotive implementation of CP/M, which could well be, but I'm still intrigued to understand what's happening.   Certainly, as you get to 464 files/extents, you get a system error 'No More Directory Entries' or something like.   Anyone else found this?   I've mainly hit this when trying to move directories (a.k.a. user areas) around, under normal useage it rarely crops up.   


Anyway, the uIDE is a truely wonderful thing, I hope the others who got one are finding it similarly useful.


Thanks JonB.


Geoff

[FloppySoftware]

If your drive has 48 dir. entries really available, check for mistakes in the dpb / dph structures.

[JonB]

For the record, it is:

Code Select Expand

         ; Block size = 4096 bytes
dpb:      dw 128  ;SPT - sectors per track
      db 5    ;BSH - block shift factor
      db 31   ;BLM - block mask
      db 1    ;EXM - Extent mask
      dw 2039 ;DSM - Storage size (blocks - 1)
      dw 511  ;DRM - Number of directory entries - 1
      db 240  ;AL0 - 1 bit set per directory block
      db 0    ;AL1 -            "
      dw 8000h;CKS - DIR check vector size 8000=CP/M 3 fixed disk
      dw 1    ;OFF - Reserved tracks (for warm booting)
      db 2   ;PSH - Phys sector shift (2 => 512 byte sectors)
      db 3   ;PSM - Phys sector mask (3 => 512 byte sectors)

Cheers
JonB

[GeoffB17]

Hmm, interesting.


I'd not noticed that the difference between 512 and 464 was 48.   48 is significant, as in divisible by 16, and therefore so many sectors.


Looked again at DPB info for all 6 drives, and they appear to be all the same, and contain the numbers they ought to contain.


Played some more with DU-V86, which works fine on the uIDE drives.


I'd already noticed one oddity before, but had not associated this with the missing directory entries.  I now checked this further, and realised that the oddity DID account for 32 of the directory entries, but not all 48.   But, back to another 16!


The oddity?  The format requires that ALL of Track 1 on each disk is directory.   That's 32 512 byte 'physical sectors' or 128 sectors as seen by DU-V86.   If that was so, then there should be 512 directory entries.


Using DU to check the disks, it appears that drives C, D and E may in fact be correct.   All of Track 1 seems to be formatted as directory.


Looking at F, G and H (and specifically G has been the one causing me a problem), there I see (via DU) that the first 8 sectors contain format garbage (NOT E8 bytes, but something else, the same as all Track 0) and the directory format proceeds from sector 9.   So, in actuality, NOT ALL track 1 is available for directory.   Checked the start of Track 2, and this is file data, not more directory.


BUT, the first 8 (128 byte) sectors accounts for 32 dir entries only.


So, I stepped through the rest of track 1 (which I'd not done before) and - BINGO!


Sectors 13 to 16 and also NOT formatted as directory, although in this case they're solid FF bytes.  Another 4 sectors, another 16 dir entries, making 48 in total.


The missing 48 entries!


As far as I can tell, there's no way the parameters of the DPB could do this.   The DPBs seem to be correct.   The DPB says that these sectors ARE part of the directory.   BUT, it appears that when CP/M tries to use the space, it decides that the space is NOT directory.


So...


Just to check if this is something odd with just my DOM, if anyone else has the uIDE, and DU-V86, please check drives F, G and H (check just 1 will help even) and confirm if the above seems to be the same.   I have a second DOM, now re-formatted, I'll try to check that too.


I do not know how this could have happened.   If JonB's 'format' process is doing the same format for each drive, then ?


I don't know how JonB applied the 'image' with all the files as originally supplied, maybe that image was faulty?


It's a pretty perverse problem.   Easily missed during normal use.   So no blame to anyone.   Especially JonB, who I'm sure had more than enough technical matters to worry about.


Oh, how to 'fix' it??   Erm.....?


Geoff

[JonB]

Geoff... check your email.


I think the error is in the formatter, and I think it is fixed. There is a download link, try it and let me know how it goes. If you're happy with it (and the new FID), let me know and I will release it.


Now we have the problem of moving your files on the first DOM to a newly formatted DOM. Master / Slave capability would be jolly useful now...