[Coco] Issues with NitrOS9 build

Fri Jan 24 21:38:48 EST 2014

Hi all,

I did a rebuild after Tormod's briliant bug hunt.

I loaded nos96309l2v030209coco3_80d.dsk into VCC 1.42 and typed DOS.

I get the usual list of modules being loaded, and that stops with i2xto*W

The error, when translated, is BAD PATH NAME (error 215).

Now, I checked sysgo; it's in the root directory and has its permissions set 
correctly. Similarly, startup, and shell (in CMDS). All appear to be 
correct. What other file is involved here? I checked out the INIT module, 
and it seems correct (/DD /TERM etc).

Does anyone have any clues?

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message ----- 
From: "Bill Pierce" <ooogalapasooo at aol.com>
To: <coco at maltedmedia.com>
Sent: Saturday, January 25, 2014 7:08 AM
Subject: Re: [Coco] Issues with NitrOS9 build

>
> Tormod,
> Thank you for taking the time and breaking down how you went about finding 
> this error.
>
> I have been a blue-collar construction worker all my life (10th grade 
> dropout) and never worked in the computer industry so I never had the 
> oportunity to work on Unix or mainframe machines and never learned all the 
> little search and comparison techniques that you guys take for granted.
> My "cmd line" experience went from RS DECB to EDTASM to OS-9 (all on the 
> Coco) to (a little) MSDOS to Clicking in Windows. I then had some 
> experience programming in Visual Basic and Visual C++... Now I've dropped 
> back to the beginning and I'm teaching myself K&R C (Coco OS9 version).
> When you break something down like this, I take notes then mess around in 
> MinGW to see what it does.
> The next time something like this happens, I have a few more tools to work 
> with.
> It's nice to know that after 54 years, that knowledge can still sink 
> in.... just a little slower...
>
> Just know your extra efforts are appreciated... And used.
>
>
> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Webmaster of The TRS-80 Color Computer Archive
> http://www.colorcomputerarchive.com/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
>
>
>
>
> -----Original Message-----
> From: Tormod Volden <lists.tormod at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, Jan 24, 2014 2:38 pm
> Subject: Re: [Coco] Issues with NitrOS9 build
>
> It would have been simpler if you told us which module or even just
> which CRC was duplicated. Anyway, Robert found out, but let me explain
> how I debugged it and found *another* bug, in case someone finds it
> instructive:
>
> Since I was not sure if this was the same module copied twice or two
> modules being identical, I started to check the latter. After building
> all the modules for coco3:
>
> make -C level2/coco3/modules NITROS9DIR=$PWD
> (or simply "make PORTS=coco3" which would have built everything for coco3)
>
> I checked the CRC of all modules for duplicates:
>
> cd level2/coco3/modules
> os9 ident *.* | grep CRC | uniq -d
> (note that *.* is not a catch-all like in DOS, but matching all module
> filenames since they have an extension)
>
> So there was two CRCs duplicated. I can then for instance look at all
> "DD" modules:
>
> os9 ident *.* | grep -A9 ": DD$"
> (note that -A9 prints out 9 lines after the matching one)
>
> Although the trained eye spots "Rammer" there and the attached brain
> might know what that is about, it doesn't tell us directly which files
> that have duplicated CRC, so just check which files are duplicated:
>
> md5sum *.* | sort
>
> A quick glance on the output seems to show several duplicates, but let
> the "uniq -d" do the job:
>
> md5sum *.* | sort | uniq -d -w 16
> (we only compare the 16 first characters, the checksum)
>
> 803df7a7f2dca70b9bf7cb16d6b3d545  r0_128k.dd
> cdb23b13909676394539680edf9d2c26  ddr0_128k.dd
>
> So we find r0_128k.dd and ddr0_128k.dd have been duplicated. To which
> other files:
>
> md5sum *.* | grep 803df7a7f2dca70b9bf7
> 803df7a7f2dca70b9bf7cb16d6b3d545  r0_128k.dd
> 803df7a7f2dca70b9bf7cb16d6b3d545  r0_192k.dd
> 803df7a7f2dca70b9bf7cb16d6b3d545  r0_8k.dd
> 803df7a7f2dca70b9bf7cb16d6b3d545  r0_96k.dd
>
> So these four modules are bit-to-bit identical. Strange isn't it.
>
> grep -A1 r0_ makefile
> (or reading the makefile)
>
> shows us that they are all built from r0.asm but the RAMSize variable
> is passed from the makefile with different values for each module. So
> why do the modules end up identical all the same? Investigating
> level2/modules/r0.asm shows that RAMSize is "set" in the source file
> itself, so the value passed from the makefile is overridden... The
> "set" must be removed or at least wrapped in "IFDEF - ENDC" to leave a
> default value.
>
> A possible explanation for how this bug arised is that an assembler
> that was used before gave precedence to the makefile variable when the
> same variable was "set" in the source file. But not lwtools.
>
> Fixed. So now there will be RAM disks of different sizes in the builds 
> again.
>
> Tormod
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco 