#16 BDS Toolshed bugs

open
nobody
None
5
2013-02-06
2007-05-26
No

Just compiled the Turbo C++ version of toolshed and tried to use the resulting .exe files to compile NitrOS-9. Can't get past 'make all'.

The BDS version of mamou will not accept any command of the types LDA #'%' Bad Operand
LDB #E$Share,s Bad Operand

There seems also to be a problem with os9.exe as there is a Task Manager type error. " os9.exe has encountered a problem and needs to close. etc." ModName: cc3270.dll

msys reports "Two or more sources requires target to be a directory"

What is worse is that reverting to the old toolshed programs does not help. Since installing Turbo C++ I am no longer able to run 'make dsk'. Files are not being transfered to the dsk images.

Discussion

  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    Strange but after sitting overnight the status has improved. Now all old tools work and NitrOS-9 compiles to dsk images. Replace the old os9.exe with that from the Turbo C++ build and again everything works. However, replace the old mamou.exe with the Turbo build and the same errors above with the use of the # symbol are still present.

    What changed? Your guess is as good as mine. All I did was install Adobe Reader 8.0 and I don't see how that could have been relevant.

     
  • Boisy Pitre

    Boisy Pitre - 2007-05-27

    Logged In: YES
    user_id=42881
    Originator: NO

    Regarding the bad operand, set a breakpoint in the mamou_parse_line function and trace through the logic in the BDS debugger. This may be a slight platform inconsistency.

    Not sure about os9. Need more detailed information on where this is happening. You may need to run this in the debugger.

    Regarding make, I think BDS has its own make utility and that is being executed instead of the old MSYS one. You may have to be explicit as to which MAKE you want to run.

     
  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    Assume I don't know how to use Turb C++ (which is just about right) how do I set a breakpoint in the mamou_parse_line function (if I can find it) and use the BDS debugger?

     
  • Boisy Pitre

    Boisy Pitre - 2007-05-27

    Logged In: YES
    user_id=42881
    Originator: NO

    I went back and read your initial bug report, and:

    LDB #E$Share,s

    is indeed a bad operand. It should be:

    LDB E$Share,s

    A different set of code operates on immediate operands starting with '#' and that code doesn't think commas should be part of a symbol or literal.

    So this is not a bug.

    BTW, I went ahead and made some changes to the repository. Please do a CVS update. I've renamed rma.c, rlink.c, os9.c, mamou.c and decb.c to rma_main.c, rlink_main.c, os9_main.c, mamou_main.c and decb_main.c to cope with an issue in BDS where the target name cannot be the same as the name of another file in that project (weird, but true).

     
  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    OK. Made some progress! I still don't know how to use the BDS debugger but have found exactly how the BDS build of mamou differs from the msys build.

    Two OS-9 files had problems, dcheck and rbf. The LDB #E$Share,s is in rbf.asm and if that was not intended, then rbf in the latest NitrOS-9 release is flakey unless the old mamou build ignores the # in this context.

    All the #'X' type errors were in dcheck. The BDS build of mamou will get past these errors if the source is changed as follows:

    cmpb #'%' ; $25
    becomes
    cmpb #'% ; $25
    The only difference is the removal of the trailing '. In fact, EDTASM, asm, and other assemblers for the Coco use the #'symbol syntax. This may be a source problem rather than a mamou bug.

    I have not yet tried the change with the old version of mamou.

     
  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    !!!!CORRECTON!!!!

    Looking at the rbf.asm code, the # should be there but the ',s' should go!
    ldb #E$FNA get error code
    L0A0C leas $02,s purge attributes from stack
    coma set carry
    puls pc,x restore & return

    L0A11 ldb #E$Share,s get shareable file error
    bra L0A0C return

    Clearly L0A11 should be ldb #E$Share

     
  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    Regards the CVS update. Perhaps I updated too soon.
    C files have been renamed as have the build .bdsproj files.
    However, toolshed.bdsgroup was not yet updated and still contains cli terminators such as
    decbcli.bdsproj which now do not exist.

     
  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    There is still a significant bug in BDS mamou. Even though I can build the NitrOS-9 disks and they look OK under MESS, I can't boot into the 80 track Level2 6309 disk.

    If I exchange the BDS mamou for the Win32 mamou, then the disk will boot. It does not matter which build of os9.exe is used.

    I expect it will take some time to determine what is going wrong.

     
  • Boisy Pitre

    Boisy Pitre - 2007-05-27

    Logged In: YES
    user_id=42881
    Originator: NO

    The toolshed.bsdgroup should be good to go. I reobtained all the files from CVS freshly and did a build of decb, os9, mamou, rma and rlink. All built just fine.

     
  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    The tools build, but I'm having a problem using mamou. I believe I have tracked the problem to a specific type of construction. For example ioman is OK up to service routine vector table. At that point the Win32 and BDS builds give different values.

    fdb UsrIO-*-2
    This type of code seems to be calculated incorrectly. In rb1773desc.asm the code is fine up to
    fcb initsize-*-1 initalization table size

    So I can't get NitrOS-9 disks made using the Turbo build of mamou because the above math calculations are not done correctly.

     
  • Robert Gault

    Robert Gault - 2007-05-27

    Logged In: YES
    user_id=859353
    Originator: YES

    Boisy, this should help you find the bug in Turbo mamou.

    rb1773desc.asm has
    fcb initsize-*-1 initalization table size
    The old Win32 mamou obtains $000F while the new Turbo mamou get $0011
    However, if the code is changed to
    fcb (initsize-*)-1 initalization table size
    then the Turbo mamou get the same result as the old version; $000F

    I don't have the ability to troubleshoot the C++ version so I'll leave it to you. I believe this to be the only bug in mamou but time will tell. Why this shows up on my system but not yours is a mystery.

     
  • Robert Gault

    Robert Gault - 2007-05-28

    Logged In: YES
    user_id=859353
    Originator: YES

    There is at least one additional Turbo mamou bug on my system.
    ffind64.asm Level2 6309 just after L0A89 has
    ldq #$01000100
    This is correctly compiled by the older Win32 mamou but Turbo mamou creates
    ldq #$00000000

     
  • Boisy Pitre

    Boisy Pitre - 2007-05-29

    Logged In: YES
    user_id=42881
    Originator: NO

    The LDQ problem has been fixed. This was due to a change I made to the source a couple of weeks ago. Update your CVS tree.

    The other issue with incorrect computation of expressions has to do with the way I rewrote evaluator.c. Instead of evaluating expressions left to right, it evaluates them right to left (e.g. 3-2-1 becomes 3-1 which becomes 2. It should be 3-2-1 becomes 1-1 which becomes 0). I'll have to rework the code to do this properly.

     
  • Robert Gault

    Robert Gault - 2007-06-03

    Logged In: YES
    user_id=859353
    Originator: YES

    The latest revision of evaluator.c has introduce a new set of bugs. For example, in level2 rbf.asm there is a section
    Create
    pshs y Preserve path desc ptr
    leas -$05,s Make 5 byte buffer on stack
    IFNE H6309
    aim #^DIR.,R$B,u
    ELSE
    lda R$B,u force directory bit off
    anda #^DIR.
    sta R$B,u
    ENDC
    lbsr FindFile try & find it in directory
    bcs Creat47 branch if doesn't exist

    * File already exists
    ldb #E$CEF else exists error
    Creat47 cmpb #E$PNNF not found?
    bne Creat7E

    * File doesn't exist, create it
    cmpa #PDELIM full path?
    beq Creat7E yes, return
    pshs x preserve filename pointer
    ldx PD.RGS,y get register stack pointer
    stu R$X,x save updated pathname pointer
    * These 4 did have < in front, made 3 byte cmnds but some are 2!
    ldb PD.SBP,y get physical sector # of segment list
    ldx PD.SBP+1,y
    lda PD.SSZ,y get size of segment list in bytes

    The new mamou with updated revaluator.c yields for the same section
    L0038 pshs y
    leas ,s
    aim #$00, ,u
    lbsr L0721
    bcs L0046
    lbd #$DA
    L0046 cmpb #$D8
    bne L007A
    cmpa #$2F
    beq L007A
    pshs x
    ldx ,y
    stu ,x
    ldb ,y
    ldx ,y
    lda ,y

    It should has generated
    L0038 pshs y
    leas -$05,s
    aim #$7F,$02,u
    lbsr L078C
    bcs L0046
    ldb #$DA
    L0046 cmpb #$D8
    bne L007E
    pshs x
    ldx $06,y
    stu $06,x
    ldb <$16,y
    ldx <$17,y
    lda <$19,y

    As you should expect from the above, mamou can't be used to compile NitrOS-9.

     
  • Nobody/Anonymous

    Index.. Great! :)

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks