avatar_JonB

Announce: PCW xdriver suite v1.11 for uIDE users

Started by JonB, 07:14, 06 June 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

JonB

Hi

I've just completed work on a new driver for uIDE-8 on the PCW machines.
An outline of the improvements:

       
  • Additional drives added. You now have access to all drives from C: to P: (with M: remaining the ramdisk), even with the SIO adapter fitted. Please go into each new drive and do ERA *.* to clear any garbage down from the directory tracks before use.
  • Fixed a bug in xformat.com that meant some directory information was garbled.
Download link: PCW xdriver suite v1.11

With thanks to John Elliot for his advice on getting round the six drive limit and GeoffB17 for beta testing.

Regards
JonB

GeoffB17

For Info - if you've already got a DOM, and are using it, you may not be too keen on re-formatting, as it's an 'all-or-nothing' process.


So you'll still have some garbage DIR entries.   As noted on another thread.


These do NOT cause any immediate problem, they just reduce the available DIR entries from 512 to 464 (or maybe 480).


Basically, these DIR records appear to CP/M as if they're used, and so not available, but they actually contain garbage and CP/M disregards them.


I'm playing with mine, using a combination of DU-V86 and Knife, and I've determined that if you edit the sector to contain what it SHOULD contain, then the DIR entry is activated again, and will be used as normal.   I've done one sector, on one drive, and it's a bit tedious.   It's easier in Knife, but I think there may be a way to automate the process (somewhat) in DU-V86.   Must read the manual!!


One problem re the above - DU-V86 treats the sectors as 1 to xx, while Knife sees them as 0 to (xx - 1).   So if you swap between the two progs you might have a problem?


More info later.


Oh, and I CANNOT repeat this enough - MASSIVE thanks to JonB for all his work on this project.


Geoff

GeoffB17

OK.


I've had a further 'play'.


I could automate the process further, but better to be safe.   The following seems to be quite practical.


Use the DU-V86 prog - this is on the DOM anyway.   Knife makes it much easier to manually edit a sector, but you may not have that.   DU is better in other regards.


If you cannot edit the sector, then you need to find a sector that is empty/correct.   Check the different drives,


i.e.


lc         select drive C
t1        select Track 1
s128   select the last sector, most likely to be clean/empty
d         to display, check it's clean
<         to save that sector


Once you've done that, you have a buffer with 128 bytes in comprising a clean/empty directory sector.
This buffer will be retained until you do another < to overwrite it, or exit the prog.   It will stay saved even as you change drive etc.


A clean sector will comprise 4 @ 2 line dir entries.   The first byte of each should be E5, followed by 11 space (20) bytes, followed by 20 bytes set to zero (00).


Once you've got this saved to your buffer, you need to copy this to each faulty sector in turn.


Drives C, D and E seem to be OK.


All the rest have a problem.


Sectors 1 to 8 in Track 1, followed by 13 to 16, but use the d command frequently to make sure you are not dealing with a valid DIR sector where you will see valid file names where the space chars in the empty buffer.


lf     select drive F (or whatever)
t1    select Track 1
s1    first sector
d      to display, make sure it's corrupt
>      to copy the SAVE data to the current sector
w     to write the data to the disk
d      if you d now it should show the clear dir sector data.
+      to advance to the next sector, or snn to move to sector nn
then back to the 'd' above and repeat for each damaged sector


When 1 drive is done, back to ld where d is the next drive letter.


Use 'd' to view the current buffer as often as possible, you do NOT want to overwrite a valid DIR sector as this will mess up the whole drive!


Any questions?


Geoff

GeoffB17

Further to the above, I've just sorted out ALL my DOM, and I checked some extra automation.


Makes the job a LOT faster.


BUT, I would suggest this ONLY for drives that are EMPTY.


So, if there's nothing on the drive, and there are no existing directory entries to worry about...


Follow the previous instructions to fill the save buffer with a correct dir sector data, log onto the first empty drive (for example I:), go to T1 and S1 as noted above.


Then, at the DU : prompt, enter


>;w;+;/16 and press enter.


This will repeat the commands >, w, + 16 times and presto, you've done that disk   Move onto the next one.


This does sectors 1 to 8, and 13 to 16, which are corrupt enough to be not used by CP/M.   But ALSO sectors 9 to 12 which are not quite correct, but CP/M will use them OK.   But doing all 16 in one go is so much faster!


I repeat, I'd advise this process ONLY for an empty drive (i.e. I: thru P: if you've just got the new driver).   Not for any drive that has data on, where you DO need to check the sector first.


Geoff

GeoffB17

Re: CATALOG.TXT


JonB provided the handy file for keeping a manual directory of all the drives/User areas on the DOM.


His version covered the 6 drives accessible at that time.


I found it useful, although I'm giving some thought to some extra programmes to help.   Anyway, as I moved things around, etc, I updated the file, and printed it out for reference.


So, when I got access to the extra drives, I just HAD to update the template.


I attach the blank version, in case it'll help.   No space to include P:, but the other 12 are there!!


Geoff

JonB

Geoff


Did you say that the corrupted extents had user numbers greater than 15?


If you can come up with a set of rules to detect badly formed extents, I could write a reformatter that resets them (thus freeing the space for real files).


Cheers
JonB

GeoffB17

Jon,


No, I don't think I specifically said that, but it's almost so.


Sectors 1 to 8 contain the strange format garbage, i.e. a 4 or 5 byte patters repeated, so the first byte for each sector isn't necessarily the same, but could well be > 15.  All my sectors are 'fixed' now, so I cannot check.   I've just checked the data in track 0, which does a similar thing, but the pattern varies and I'm sure it's not the same as what was in the start of T1.   


Probably, the bytes were all > 15.


The second block, sectors 13 to 16, were all Fx (F something) so YES, they WERE > 15.


Using DU wasn't a major problem, once you get into the swing of it, and as per my later note, much easier for the empty drives.   But not everyone might think that??


Geoff

Powered by SMFPacks Menu Editor Mod