dcheck optimizations

Developers
2008-05-27
2013-05-16
  • Boisy Pitre
    Boisy Pitre
    2008-05-27

    On Tuesday 27 May 2008, Robert Gault wrote:
    Gene Heskett wrote:
    Hi Robert;
    Obviously I'll be glad to be a test subject. :)

    OK, here is a patched version of dEd. Run the following test with the
    old version and then try the new one.

    Look at sector1 and sectors $xx0001 where xx is any number >0 so that
    the LSN exists on your disk.

    We have another problem Robert (& Boisy), dchecks math is also now defective.  I
    started at the MSB end of the byte at $18, clearing one bit at a time and only
    one bit, and dcheck walked right on by $318 from $320 to $314 in one cleared
    bit moved one place to the left.  Ooops.

    10+ years ago when I was working on rbf.mn, even before the BackAr fiasco, I was
    putting the multiple sector per cluster code back into rbf.mn that K.D. had
    removed with one of his "Christmas Presents",  I used a 5.25" floppy that I'd
    formatted single sector per cluster, and then hand edited it with ded to check
    it at 2 sectors, 4 sectors, and 8 sectors per cluster, by changing DD.BIT and
    shrinking the FAT table accordingly.  That I could dcheck in just a minute or
    so after writing 50 or so files to that test disk.  And it all worked as it
    should then.

    The original dcheck, having been written before K.D. gave us that busted ed 28
    rbf.mn, did properly handle the multiple sectors per cluster case, I tested it
    rather extensively at the time.  And my recent patch to dcheck, making short
    branches out of W's that were using long branch syntax, should not have
    effected that in any situation I can imagine.  I can check that however by
    running dcheck.original to see if I get the same answers.  Or better yet, the
    original dcheck from /dd/maxtor/cmds. :)

    First though, before I start on this, I've got to hack up some test floppies to
    play with, this 20 minutes a run on my 4 sector/cluster /dd is a pita.

    Stay tuned as they say on the radio. :)

     
    • Gene Heskett
      Gene Heskett
      2008-05-27

      Good grief!  What a broken login system.  izzat part of the security model?

      Anyway, going back to a 20 year old copy of dcheck from my old maxtor drives image, which came from an even older 30 meg drive on a broken B&B-XTC interface, I get exactly the same answers when I dcheck my /dd, so _maybe_ dchecks math is still ok.

      That leave the question of why does it tell me that Clusters $0318 and $0334 are in the map but not in the file structure?

      Humor me here a little bit as I work this math out.  And for the nonce, ignore $334 and another cluster near the inside of the partition its also complaining about.  FWIW I've now tested all 3 versions of dcheck (from 3.2.6, 3.2.7 as I patched it, and the original 20 year old version from the L2 distribution disks & all give the same answers

      $314 / 4 (sectors per cluster) = $C6, which when divided by a further 8 to get which byte in the map covers $318, gives $18, and since the leftmost, zeroeth bit of that byte s/b $318.  Right?  So I clear that bite by setting that byte=$7F with ded and write it.

      Now it complains that $310 is missing from the map and the file structure is not intact.  So I missed it by 8 clusters, so I $FF that $18 byte, and $7F the $19th byte which should be 8 clusters higher for $318.  But then dcheck complains again, this time naming cluster $320, off by 8 clusters the other way, so I move the cleared bit left one bit by setting byte $19 back to $FF and setting byte $18 to $FE.

      Then it complains abut $314!  And I'm running out of what little hair I have left.

      Is there a pattern detectable here that will allow us to prove that the split up rbf.mn is still correct or not, and the same question asked of both dcheck and ded.

      Also, clarify in my mind whether the data in an FD.SEG is sectors or clusters as that will help me visualize this better.

      Thanks, but fix the login please, to be told you've failed, so you close that tab and refresh the original link figuring to make another attempt at the login button only to find you are indeed logged in.  That is at best, completely non-intuitive.  And seemingly typical for srcforge.

       
    • Gene Heskett
      Gene Heskett
      2008-05-27

      Still logged in I see.  I have now made up some test floppies at 2/4/8 sectors per cluster on 5.25" 96 tpi disks.  Which brings up a question about the device descriptors dd.typ byte, currently set for $21, which mans that obviously this bytes unused bits are now being put to use.  When the new format is called, it says the disk is a 3.5" 135 tpi disk, which is not so, but does not in this case have a valid meaning that I'm aware of.

      Please explain the bit functions now used in dd.typ.

      I'm finding that any of the dchecks I have all seem to suffer from a missconception about the FAT tables when looking at these floppies, and its a bit spooky because it could bite somebody eventually just like that BackAr disaster thing.

      The problem is that you want the first sectors of the disk which contain LSN0 & LSN1 to end of the FAT to be marked as occupied in the FAT.  About the least amount of disk you can manually allocate is to about the $0A sector which would be the end of the root directory, but as I'm shrinking the FAT, and moving the root dirs FD sector and start of the directory back to where the last sector of the FAT used to be when format got done, with suitable edits in LSN0 to move it, and the FD sector moved back one sector, then the root dir moved back one sector too, then any of the dchecks I have, complains about Cluster $0000 being in the map but not in the file structure.  As this is all LSN0 and FAT stuff, so there is no FD that accounts for the allocation.

      It doesn't do that for a one sector cluster disk, nor does it do it while looking at my hard drive. It makes sense that dcheck should be noting the LSN0 and FAT sectors as being legally occupied.  I wonder what it drops when it finds DD.BIT unequal $0001?

      So that should be put in the itch drawer we scratch someday...  Before someone gets bit by storing their new startup file in the zeroth cluster...

      I'm dragging by now, need to go see what we have for dinner. :)

       
      • Robert Gault
        Robert Gault
        2008-05-27

        OK, there are several issues here and we should try not to get them confused.
        1) dEd - my patch is not quite correct and I don't yet see why it doesn't work. I'm in the process of adding many comments to the source code from an original source I have. That should make things much easier when adding or changing code.
        Currently, dEd (trial version sent to Gene) has one problem. The sector values given for the last sector on each page are off by one map byte.
        For example, with a DD.BIT of 4, dEd is showing for the first page
        BAM $000000-$002000 where it should be $000000-$001FE0
        The second page would have
        BAM $002000-$004000   and should be $000000-$003FE0
        2) dcheck - I can't look at that until dEd is finished but there may not be anything wrong with dcheck. As I currently understand the situation, Gene has a disk with a corrupted file system reporting a dcheck error. Using my dEd trail version, Gene can't remove the dcheck error but creates new ones.
        Now there may be a dcheck bug, but it could easily be a problem using dEd. Unless the clusters in question are the last byte on a map page, the test dEd should correctly indicate sector values. Since there are 4 sectors per cluster, the first byte in the map will indicate as follows:
        bit         sectors
        7           0-3
        6           4-7
        5           8-$B
        4           $C-$F
        3           $10-$13
        2           $14-$17
        1           $18-$1B
        0           $1C-$1F
        It is not the easiest process to calculate where a cluster or sector should be in the map so I usually don't. I let dcheck do the work by saving the allocation map work files (-m) and comparing them to the actual map with two windows running dEd. That makes correcting the allocation map almost easy.
        3) Fixing dEd - our source code is based on a disassembly rather than original source. I hope shortly to convert the source code from uxxxx, Lxxxx, and Pxxxx lables to real ones. Even if that does not result immediately in a correct BAM patch, it is desirable.
        4) "Fixing" dcheck - I think it is too early to tell if this is needed or not. If someone else wants to take this on, fine. I think it should stay pending until dEd and the use of it is settled.

        ================

        One final dEd comment. The BAM output is and will probably stay misleading. It assumes an entire page of the map is being used. The last map page is not likely to be full and dEd currently does not indicate this. That means the last map page will indicate sectors that do not exist are in the map.

         
    • Gene Heskett
      Gene Heskett
      2008-05-27

      Just for grins I put that 8 sector/cluster floppy back in the drive, did a dir -e to see if it was clean, one last dcheck on it too, and except for cluster $000000 in the map but not in the file structure, it was clean.

      The I cd'd to /dd/cmds and fired off dsave to put it all on /d1.  On completion, I ran another dcheck, and it complained about the clusters $08, $10, $18, $20, $28, $30, $38, $40 and $378 in the allocation map but not the file structure, and I was surprised, taken aback etc.

      Doing a dir -e on the disk, the first file, Control, had some bogus numbers, but the rest of it was fine.

      Firing up ded /d1@ to see what was wrong, the clues are that it put the Control file someplace in the middle of the root directory as I had apparently overwritten the early part of the file with the directories contents as the rest of the copying took place.

      This disk had the first 2 bits of the allocation map set when I started, first byte=$C0, representing $00 to $07, and $08 to $0F in sectors, so it should have put the Control file's FD at $10, and started the file itself in sector $11, well beyond the end of the first segment of the root directory which ended at $03+7 or sector $0A, leaving an as formatted gap from sector $0b to sector $OF.

      Cluster $378 was the beginning of the 2nd segment of the root directory, which dcheck apparently didn't include in the root directories allocation.  It was the last "not in file structure" of the list.

      I didn't have any such problems doing this way back then, what, 15 years ago?  And I'm getting an urge to point at the new, broken up in pieces rbf.mn.  Anybody else getting the same feeling?

      Although I have dsaved 3.2.6 and 3.2.7 to my hard drive now, and generated about 15 boot disks, 3 of which actually work, I am now having some of these same errors on the HD and cannot fix them with ded, and am now very wary about doing too much more, particularly when booted to a boot newer than DOS128 that Mark put on 7 long years before.  That one is I think ok.  But it doesn't run my hardware as there aren't any drivers in that boot that match whats plugged into the mpi.

      So in terms of doing anything, I need somebody to move either the rock, or the hard place that I'm between the two of now.

      Cheers, Guys.  Gene

       
    • Gene Heskett
      Gene Heskett
      2008-05-28

      The ded you sent did not display the BAM any differently than any other copy I have. sector 1 was said to be the BAM from $000000 to $0007FF.  That is if I got the right one onto the sneakernet floppy.  I mv'd the /opt/nitros9/level1/coco/cmds/ded to ded-original, which still exists.  Then I put the unpacked one in its place, backed out and into the level2/6309l2 directory, nuked the nos*, and did a make dsk.  Then I put the new nos96309l2v030207coco3_80d.dsk on a floppy...

      What a pita that operation is, I'll let this paste explain it:
      -------------
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# ls /dev
      admmidi          fd0u360     mapper              ram6                tty1   tty42      usbdev1.10       usbdev2.3_ep82
      adsp             fd0u720     mem                 ram7                tty10  tty43      usbdev1.10_ep02  usbdev3.1
      adsp1            fd0u800     midi                ram8                tty11  tty44      usbdev1.10_ep81  usbdev3.1_ep00
      agpgart          fd0u820     midi2               ram9                tty12  tty45      usbdev1.11       usbdev3.1_ep81
      amidi            fd0u830     mixer               ramdisk             tty13  tty46      usbdev1.11_ep00  usbdev3.2
      audio            floppy      mixer1              random              tty14  tty47      usbdev1.11_ep81  usbdev3.2_ep00
      audio1           floppy-fd0  mixer2              root                tty15  tty48      usbdev1.12       usbdev3.2_ep81
      bsg              full        net                 rtc                 tty16  tty49      usbdev1.12_ep81  usblp0
      bus              fuse        network_latency     scanner-1-1.4.4     tty17  tty5       usbdev1.13       usbmon0
      cdrom            fw0         network_throughput  scanner-usbdev1.13  tty18  tty50      usbdev1.13_ep03  usbmon1
      cdrw             gpmctl      null                scd0                tty19  tty51      usbdev1.13_ep81  usbmon2
      console          hiddev0     nvram               sda                 tty2   tty52      usbdev1.13_ep82  usbmon3
      core             hiddev1     par0                sda1                tty20  tty53      usbdev1.1_ep00   vbi
      cpu              hidraw0     parport0            sda2                tty21  tty54      usbdev1.1_ep81   vbi0
      cpu_dma_latency  hidraw1     parport1            sda3                tty22  tty55      usbdev1.2        vcs
      disk             hidraw2     parport2            sdb                 tty23  tty56      usbdev1.2_ep00   vcs1
      dmmidi           hidraw3     parport3            sdb1                tty24  tty57      usbdev1.2_ep81   vcs2
      dmmidi2          hpet        port                sdb2                tty25  tty58      usbdev1.6        vcs3
      dri              initctl     ppp                 sdb3                tty26  tty59      usbdev1.6_ep81   vcs4
      dsp              input       ptmx                sdc                 tty27  tty6       usbdev1.7        vcs5
      dsp1             kmem        pts                 sdc1                tty28  tty60      usbdev1.7_ep02   vcs6
      dvb              kmsg        radio               sequencer           tty29  tty61      usbdev1.7_ep81   vcs7
      dvd              log         radio0              sequencer2          tty3   tty62      usbdev1.8        vcsa
      dvdrw            loop0       ram                 sg0                 tty30  tty63      usbdev1.8_ep00   vcsa1
      fd               loop1       ram0                sg1                 tty31  tty7       usbdev1.8_ep81   vcsa2
      fd0              loop2       ram1                sg2                 tty32  tty8       usbdev1.9        vcsa3
      fd0u1040         loop3       ram10               sg3                 tty33  tty9       usbdev1.9_ep00   vcsa4
      fd0u1120         loop4       ram11               shm                 tty34  ttyS0      usbdev1.9_ep81   vcsa5
      fd0u1440         loop5       ram12               snd                 tty35  ttyS1      usbdev2.1        vcsa6
      fd0u1600         loop6       ram13               sr0                 tty36  ttyS2      usbdev2.1_ep00   vcsa7
      fd0u1680         loop7       ram14               stderr              tty37  ttyS3      usbdev2.1_ep81   video
      fd0u1722         lp0         ram15               stdin               tty38  ttyUSB0    usbdev2.2        video0
      fd0u1743         lp1         ram2                stdout              tty39  ttyUSB1    usbdev2.2_ep01   XOR
      fd0u1760         lp2         ram3                systty              tty4   urandom    usbdev2.2_ep82   zero
      fd0u1840         lp3         ram4                tty                 tty40  usb        usbdev2.3
      fd0u1920         MAKEDEV     ram5                tty0                tty41  usbdev1.1  usbdev2.3_ep81
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      get geometry parameters: No such device
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# dd if=/dev/fd0 count=1
      dd: reading `/dev/fd0': Input/output error
      0+0 records in
      0+0 records out
      0 bytes (0 B) copied, 25.6452 s, 0.0 kB/s
      [root@coyote nitros9]# setfdprm /dev/fd0 COCO7203.5
      [root@coyote nitros9]# getfdprm /dev/fd0
      DS DD sect=18 ssize=256
      [root@coyote nitros9]# dd if=/dev/fd0 of=/rbf.stf.dsk
      1440+0 records in
      1440+0 records out
      737280 bytes (737 kB) copied, 112.711 s, 6.5 kB/s

      just to read the friggin disk took 20 minutes!  The original write was just as much trouble.

      The reason I wanted to read it is the comments in the rbf.asm file seem to indicate that you didn't start with my rbf.mn ed 35 ($23) when it was dissed, but Kevins ed 28.  Its Busted in strange ways.

      I'll send that rbf.stf.dsk to Boisy, its direct off my 1GB seagate as copied from the old Maxtor I did all that work on 11 years ago.  This code has had its tires kicked and hammered from every angle I could imagine and it Just Works(TM).  This hammering includes being checked against disks with up to 8 sectors per cluster.  There are some comments in the .asm file or the listing that I put in when undoing Kevins Christmas Present that removed the multiple sector cluster abilities it had before, but which were, shall we say, a bit flaky.

      One place in particular where it does
      ldx PD.BUF,y
      ldd <$13,x
      std some other define,y
      is a define I wasn't able to backtrace to see just what it was that lived at $13,x, so I have NDI what it is, I got it from Kevin's book in a very roundabout session of reading that never did actually answer the question but did give me the clue I needed to make it work. 

      That, and the next step below that, the incd, are absolutely required to handle multiple sector clusters correctly, particularly when deleting files, the exact (I believe) cause of my disk errors on my /dd right now.

      Unforch, enough has changed that if I put it in an OS9Boot file, sysgo winds up at DeadEnd before it runs the startup.

      I know rbf now can handle 2k sectors, so its not going to be a plug-n-play replacement, but the two of them can probably be compared for methods enough to verify the current one is correct, or fix it if that's the problem.

      Have fun, I'm burned out on this for a day or 2.

      Cheers all, Gene

       
      • Robert Gault
        Robert Gault
        2008-05-28

        I just sent Gene a new version of dEd which does correctly handle DD.BIT. I'll now look at dcheck by using the current CVS verion to examine hand corrupted floppies having either DD.BIT = 1 or 4.

        Let's see if dcheck works for me.

         
        • Robert Gault
          Robert Gault
          2008-05-28

          First I need to correct something I said about dEd. It does not include extra sectors in the last map page if the full page is not used.

          =========

          I used the current dcheck to test an 80 track double sided floppy and there were no errors. I then created a double sided floppy with $5A0 sectors and DD.BIT = 4. dcheck reported errors on this blank disk.
          $002D bytes in allocation map            which is correct
          4 sectors per cluster                    ditto
          $0005A0 sectors on medium                ditto
          Sector 2 start of root directory         ditto
          $000A sectors used on disk               ditto
          cluster $000000 in map and not file structure
          cluster $000008 in map and not file structure

          The first byte in the map is $E0 or %11100000 which indicates that sectors 0-3, 4-7, and 8-$B are used. However, there are only ten sectors used on the disk so the allocation map does indicate two extra sectors are in use which aren't.
          Nevertheless that is not an error as DD.BIT = 4 and there is no provision for displaying a partially used cluster.

          What is a problem with dcheck is that it should not have reported any clusters in the map but not in the file structure and certainly not 0 and 8.

          Gene, you are correct that dcheck is buggy.

           
    • Robert Gault
      Robert Gault
      2008-05-28

      Does anyone have access to a commented source code for dcheck? The one in the repository hasn't a single comment so troubleshooting this large program will be very difficult.

       
    • Gene Heskett
      Gene Heskett
      2008-05-28

      That lack of a dcheck src is a lament I've had for years, Robert.

      I note that in the 3.2.8 release, or whatever I got doing a cvs update late last night, that ded seems to be the older one yet.  If anyone knows how to get the new one you just sent me into a disk image so that I can get it to the coco, I'd be grateful.  Putting the other one you sent into the nitros9/level1/coco/cmds directory and doing a make dsk from the level2/coco3_6309 directory either rebuilt the original & replaced yours or something as it didn't work any different when I had dsaved -m -r -s24'd that disk to /dd.

      Do we have a utility in the toolshed that can just copy it to an os9 formatted disk in /dev/fd0?
      That would be 100's of times handier than the roundabout way I tried to move it.

      Added, never mind, I found the toolshed.doc file that I can read in OOo2-4, however I can't print it as it prints in landscape mode regardless of what I select in OOo2.4.  I just wasted 59 sheets of paper & toner proving it. :(  Frankly .doc files have no business in a supposedly open project, please use .pdf for such as this, its a hell of a lot more universally accepted.  I was able to export it as a .pdf, and acroread looks as if it is displaying it in the correct orientation now.  Yup, that worked and I have a good, all portrait oriented duplex mode printout.  I'll post a squawk on the OOo list.

      I believe I have worked out a procedure that eases getting linux to handle the floppy, looks like this:
      1. insert disk formatted on coco
      2. setfdprm /dev/fd0 COCO7203.5
      3. getfdprm /dev/fd0 (fails instantly, no such device)
      4. dd if=/dev/fd0 bs=256 count=1 (wait half a minute for it to fail)
      5. setfdprm /dev/fd0 COCO7203.5
      6. getfdprm /dev/fd0
      DS DD sect=18 ssize=256
      7.[root@coyote nitros9]# dd if=/dev/fd0 count=1 bs=256 | hexdump
      0000000 0b00 1240 6801 0100 0000 0003 ff00 fa5c
      0000010 0003 0012 0000 0000 0000 056c 071c 7331
      0000020 656c 7475 2e68 7473 00e6 0000 0000 0000
      0000030 0000 0000 0000 0000 0000 0000 0000 0100
      0000040 0301 0120 5000 0102 1200 1200 0803 7500
      0000050 00c0 0000 0000 0000 0000 0000 7600 0041
      0000060 0000 0000 0000 0000 0000 0000 0000 0000
      *
      1+0 records in
      1+0 records out
      256 bytes (256 B) copied, 3.24064 s, 0.1 kB/s
      0000100
      8.[root@coyote nitros9]# dd if=/dev/fd0 bs=256 of=sleuth.dsk
      2880+0 records in
      2880+0 records out
      737280 bytes (737 kB) copied, 113.548 s, 6.5 kB/s

      And I've sent Boisy the complete sources for sleuth as updated by me 15 years ago from level 1 version 1.0 to level2 and I believe 6309 codes too.  Its a cross disassembler, and can be built for 6502 or 6805 input code with a switch define at the top of the src.  I never did that, none of that code exists around here.

      It appears that no number of setdfprm's will work, until it has been attacked by dd the first time, then it 'takes' and dd can then work, albeit very slowly it seems.  Writing is at about 3.1 KB/second.

      And after getting a decent printout of toolshed.pdf, I see its quite simple to copy something into a .dsk image, so I'll be testing he newer ded in about 5 minutes. :)

       
    • Gene Heskett
      Gene Heskett
      2008-05-28

      It displayed the range in "sectors" of the presently being viewed first block of the BAM, as it was showing $000000 to $001FFF, or a total of $2000 "secters"

      But it should call them "Clusters", in which case the range remains at $000000 to $0007FF for the first sector of the BAM when stated in Clusters.

      When I hit e to edit, those values displayed were still in the old one sector per bit format.  And were called "sectors"  They should be called "clusters"

      The first byte was said to represent $000000 to $000007, which is correct IF we think in Clusters.

      The covered range of a sector of the BAM, when stated in Clusters doesn't change just because DD.BIT changes.  This change can be reverted as it is of relatively little utility.  Sorry Robert.

      Also, when I hit enter to exit the edit mode w/o editing anything, it locked the machine up & required a tap on the rest button to reboot.

      I also had to use attr to set the e pe bits in the ded FD after doing the os9 copy up here, but thats common, no biggie.

      Now I am killing the afternoon by looking for the magic bit that will remove $318 from the dcheck output mewling.  I couldn't find it the other day, so I'm starting at $18=$7F (01111111) and marching the 0 to the right one position at a time. Maybe it will work this time, and maybe I can find a pattern to the error reporting if not.  That might help once some comments have been added to dcheck.

      1 in 10ee37 chance probably, have you (Boisy) asked Radesys if perchance they might have an old dusty copy of the sources in the basement?  Or is that a can of worms best left closed...

      Thanks, Gene

       
      • Robert Gault
        Robert Gault
        2008-05-29

        Whether dEd should present clusters or sectors in the allocation map is perhaps a matter of aesthetics. Currently BAM reports sectors, page 1  $000000-$001FFC DD.BIT=4 (not $1FFF), and could report, page 1 $000000-$0007FF clusters DD.BIT=any. What would be the effect on the user?

        As a user of dEd, seeing the allocation map reported in clusters would not provide any additional information other than a cluster is set/not_set. With the map reported in sectors, the user gets a better impression of how much of the disk is being used as the disk is formatted in sectors (LSN#) not clusters. You immediately know the disk was formatted with a DD.BIT other than 1 without looking it up in LSN0.

        If dEd accepted a cluster number as an entry, then it might be better to report BAM in clusters. In any case, the format of BAM for dEd is difficult to translate into either clusters or sectors as the byte values don't match either format.

        Maybe we should write a utility that inputs map page LSN, map byte number and value, DD.BIT, and outputs sector value(s) used or not used.

        Gene, I'll send you a disk image with the new dEd included.

         
    • Gene Heskett
      Gene Heskett
      2008-05-29

      I am leaning toward 'clusters' only for the BAM, for 2 reasons.

      1. The BAM/FAT is the only place in the system where clusters count AND that IS what dcheck calls them.

      I think one of the problems I have in making the clusters value dcheck reports relate to a location in the bit map may be related to, to use one of the errors I had on /dd, is that when dcheck says $318 is in the map, but not in the structure, I immediately grab a hex calculator & divide $318 by 8, which is the clusters covered by one byte of the map, in order to get the offset into the map where this bit might reside.  This should be byte $63 in the map, but byte $63 covers from $300 to $31F so which bit do I zero?  Hex to binary and vice-versa isn't a strong point of my math skills. :(

      When the next error is at $01EC60, that's a long ways into the map & ded shows absolute sector address at the top of the screen & I often forget to add the one sector offset needed to get at the correct bit after dividing $1EC60/8.

      Knowing that we are dealing in clusters as long as we are within the bitmap would, after the change wore off, reduce the confusion & might make it easier for the newbie to grok that.

      Your hint about saving the work files is a winner though, that allowed me to fix all 3 in map but not filesystem errors my drive had.  It appears the higher numbered of the two files is generally all zeroed out, having a bit set only if it is in error, so one can run 2 sessions of ded and fix things right up.  Great hint, thanks.

      I've been putzing around the place doing other things today, and just shut the coco down for the night, but I'll give that new ded a try tomorrow.

      Thanks Robert.

      Gene

       
      • Robert Gault
        Robert Gault
        2008-05-29

        I must say that this is the first time I've really tried to use the version of dEd with BAM. Now that I see how it works, I wish I'd switched to it earlier.

        Gene, dEd does all the work for you, when in edit mode on a map page, by displaying the cluster values for the byte highlighted and the bits involved. That means you don't need to use a calculator at all!

        For example, using the disk that dcheck claims is in error - 2 sides, 4 sector clusters, 2880 sectors, here is what dEd shows in Edit Mode.

        E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF
        FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
        FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
        etc.

        The BAM message is displayed only when NOT in the $FF region as that is outside the map. With $E0 highlighted, the message is:
        BAM: From Sector:$000000 to $000007 Bits:11100000
        This clearly shows the dcheck bug as the above map is correct and dcheck says
        clusters 0 & 8 are in the map but not the file structure. 8 is not in the map and 0 should be there as it is LSN0-3 and the sectors 0-9 are in use for id, allocation map, and root directory.

        Now there are a few things wrong with this as I did not know how it worked and made no changes. 1) This indeed should say Clusters not sectors or should be $0-$1C. 2) When you leave Edit Mode for Display Mode, the BAM message is not refreshed without an extra [ENTER].
        Nevertheless, not only are you told which byte to go to, just by scrolling, but also which bits correspond to which cluster/sector.

        So doing the editing on a disk with DD.BIT=1, I immediately find that byte $63 (base0) is sector $318-$31F and that the left most bit %10000000 is sector $318. With DD.BIT=4, just change 'sector' to 'cluster' and there is your answer without using any calculations.

         
        • Gene Heskett
          Gene Heskett
          2008-05-29

          <b>So doing the editing on a disk with DD.BIT=1, I immediately find that byte $63 (base0) is sector $318-$31F and that the left most bit %10000000 is sector $318. With DD.BIT=4, just change 'sector' to 'cluster' and there is your answer without using any calculations.</b>

          Except that auto-resize didn't seem to be working in the ded I was using.  As you moved the edit pointer around, it was still displaying the values as if DD.BIT=1, on an 8 sector cluster floppy, or on my 4 sector cluster hard drive.

          However, I did a cvs update yesterday morning (to 3.2.8?) followed by a make clean;make;cd level2/coco3_6309;make dsk, and installed that yesterday, before the trick of looking at the dcheck map files allowed me to find and fix the 3 errors I had.  So I'd better run down and recheck that statement.

          Ok, with the ded from yesterdays cvs update, I had dcheck say that clusters $318 and $334 were in the map but not the file structure.

          The two bits I had to change to clear those 2 warnings were in offset $18 and $19.  ded says they are sectors $C0-$C7 for offset $18, and $C8-$CF for offset $19.

          My mental math, aided by a cheap calc that can do hex, but confuses its binary display by removing leading zeros, goes something like this:

          $318 / 8(number of clusters per byte)= $63 which is the same but wrong answer you got.  Then divide again by DD.BIT and get $18, which appears to be correct, but ded's BAM display in edit mode says its for sectors $C0-$C7, not $300-$31F.  Ditto obviously for offset $19, which in fact covers $320-$33F

          So the question then is:  Is dchecks calling it a cluster wrong (and I think it is at this point), or is ded's BAM display wrong when in the edit mode?

          This is at best confusing.

           
          • Robert Gault
            Robert Gault
            2008-05-30

            I have sent Gene a new revision of dEd which I expect (hope) to be a final.

            There is a new command to toggle the BAM report between cluster and sector. Default is cluster. Both scan and edit now will report the in the same selected format.

            I activated an inoperative function so now if a user enters just    ded       without a path, the program with print out a usage message instead of an error.

            Boisy, with Gene's approval that this version is not buggy, I'll try to upload the source code to the project.

            =======
            Regards dcheck, I'll start looking at that code but it very unlikely I will make headway with any speed.

             
          • Robert Gault
            Robert Gault
            2008-06-01

            Gene, I'm sure you are ahead of me in adding comments to dcheck. I'd love to be able to get updates on your efforts so I can concentrate on fixing the problem rather than translating the source code.

            I did find a section where dcheck reads DD.BIT from LSN0 and at least prints out correctly what the number of sectors per cluster are: L033D-L0392. I have not found where this value is stored and if or where it is used in checking the map.