Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Only minor problems with a recent build

Developers
2013-08-19
2013-11-17
  • Bill Pierce
    Bill Pierce
    2013-08-19

    After doing a complete re-install of my Windows Vista 64 bit system, then of course, a complete re-install of mingw, toolshed and lwtools, I have only found a few minor problems with the build. I have not had a chamce to test the disks yet, but I did this also right after my re-install of Windows and the disks were fine then.
    The problems I found were basically the same that have been mentioned on the Coco List recently, but even most of those have disappeared. Here is a list of what I found:

    1. When DAlpha sources are built for NitrOS9, I get an error with PadRom stating the filesize is to small for the padrom data.

    2. PacOS9, I get an error No rule to make Main90.r. This has been mentioned several times but apparently no one even looked because it seems the makefile for pacos9 has not been updated for LWTools. It is still in the old CVS format. I see no reason this would not build if the makefile were corrected. I may attempt to fix this using one of the other games as an example but I cannot upload any results as I have no update access (and do not want it at this time).

    3. CCbKrn... It seems from the notes that this file was created as a replacement for Krn, but it was never put into the build process. When the disks are created, I see a copy error for this file in almost every NitrOS9 disk build. If it is not used and not assembled, it needs to be removed from the module list in the disk creation routines.

    4. Multiple disks creation. The build process seems to be creating 2 different disks for each of the NitrOS9 disks. The 2 disks are named differently, example:
      Nos96809l2_40d_1.dsk
      Nos96809l2v030209_coco3_40d_1.dsk
      This seems to occur on EVERY NitrOS9 disk created. I do not see it happening in the 3rdparty disks.

    These seem to be the only errors I am now getting on a fresh build. Who ever has been working on the sources and makefiles, thank you. A lot is working again :-)

    I do have a couple of suggestions though.
    1. Naming conventions of disks. There are several disks with 2-3 letter names that could be renamed properly. The names are of these disks are confusing and in some cases, misleading. For example:
    CC.dsk - This should be renamed to MW_C_Compiler.dsk.
    rof.dsk - This should be named Fractulus.dsk or Resque_On_Fractulus.dsk
    mm.dsk - Could be Microscopic_Mission.dsk or Microscopic.dsk
    These disks definately need more descriptive names.

    1. I also feel there should be an emulator build for the NitrOS9 disks. 60 percent of the people still messing with the Coco and Nitros9, do so on the emulators. The "emudsk.dr", "dd_h0.dd", "h0.dd", and "h1.dd" are being assembled in the build process, but not only are there no disks being built using them, the drivers are not even copied to ANY of the "nitros9/l26809/modules/rbf" directories so that one could make such a boot even though they are listed in the script files. Also, the "emudsk.dr" file has a 6309 conditional in it. Only one file is being built and I do not know if it is the 6809 or the 6309 version. It would be nice if both versions were built and labeled as such. Even nicer would be a "nos96809l2v030209_coco3_emu.dsk" and "nos96309l2v030209_coco3_emu.dsk" in both 40 & 80trk versions.

    2. Also, as a last note, there are several disks being built in the 3rdparty dirs that could be combined as a lot of them contain only one or a few files. The disks I'm referring to are the ones under the "utils" dir such as the "Boisy_utils", "DLadd_utils", "dasm", "smartwatch", and "winfo" disks. All of these files would fit on one disk and I see no reason a disk couldn't be created with these files in directories with the above names. A "nos9_utils.dsk".

    I hope my notes have been informative to those who care and are fixing things. If I run into any problems with the disks that were built, I will report it here.

    Thanks
    Bill Pierce

     
    • the duplicated disk images are in fact soft links to the file that work well on unix but not on mingmw. i dont know the reason behind those links. short names ?

       
      Last edit: Tormod Volden 2013-11-17
  • Robert Gault
    Robert Gault
    2013-08-19

    Bill,
    If you got a "No rule to make Main90.r." you got further than I did. I get "no rule to make main90.o needed bu main90.a." Actually none of these files will build. You can remove main90.a and main90.o from the all and all2 lists and you will then get the error on board90.
    It is definitely a problem with the migration to lwtools. Unfortunately, I can't find anything else using C code that I can use as a model for creating an appropriate makefile to use with pacos9.

     
  • Bill Pierce
    Bill Pierce
    2013-08-28

    Mr Gault,
    PacOS9 is not written to use the C compiler. It is written in standard OS-9 RMA assembler which uses OS9 C's "make" when assembling modular sources. It would use the standard rma/rlink makefile cmds. In OS9, you wpuld use: "RMA file1 file2 file etc" & "RLink -o=PacOS9 -M=6 file1 file2 file3 etc -l=/dd/lib/sys.l"
    I do not know enough about LWTools or ToolSHed to know the correct translation to their formats. In the repo, the "sys.l" would be the "sys6x09L2.l" in the "LIB" folder.
    I think LWAsm uses xxx.o instead of the xxx.r used by RMA/RLink in OS9. I would thin the standard format use in all the makefiles would work, though I may be wrong. I do know the current makefile is way off mark with the current format. Also, in the sources, I think the refernces to "os9defs" would have to be changed to the newer "renamed" version. There may be other references as well, I have not really looked at the sources closely.

     
  • Tormod Volden
    Tormod Volden
    2013-11-17

    Bill, thanks for documenting these issues here. Even better, please file a bug for each remaining issue in the bug tracker (under "Tickets"), it makes it easier to see what's left as we progress. So your point 4 is a "feature", and 3 has been dealt with. No 1 is a problem with the Dragon Alpha kernel growing too big - not many of those systems around anyway :) No 2 needs someone to get their hands dirty. We would be happy to upload any fixes or improvements, just attach a patch here if you have no upload rights.

     
  • Tormod Volden
    Tormod Volden
    2013-11-17

    For No 1, the Dragon Alpha kernel actually has the right size (probably no coincidence) so no padding is needed. I have fixed up ToolShed to not have os9 padrom complaining if the file already is of the right size.