[Coco] Issues with NitrOS9 build

[Bob Devries]

Hi Bill.

I checked grfdrv; it's there in the CMDS dir, and its CRC is good, and the 
attributes are good.

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 12:49 PM
Subject: Re: [Coco] Issues with NitrOS9 build


>
> Bob, the only thing I can think of is that grfdrv also has to be in the 
> cmds dir
>
>
> 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: Bob Devries <devries.bob at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, Jan 24, 2014 9:39 pm
> Subject: Re: [Coco] Issues with NitrOS9 build
>
>
> 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
>
>
> --
> 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