[Coco] Issues with NitrOS9 build

Fri Jan 24 23:41:19 EST 2014

I did a CMP of the os9boot files on the 40 track disk 
(nos96309l2v030209coco3_40d_1.dsk) and the os9boot file on the 80 track disk 
(nos96309l2v030209coco3_80d.dsk) and found that the only differences were 
two bytes in each Dx module (IT.TYP and IT.CYL) and of course, the CRC bytes 
for each of those (4) modules.

So why the failure of the 80 track image?

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 