[Coco] Issues with NitrOS9 build

[Gene Heskett]

On Friday 24 January 2014 15:01:17 Tormod Volden did opine:

> On Fri, Jan 24, 2014 at 6:05 AM, Bob Devries wrote:
> > Hi all,
> > 
> > I just built NitrOS9 from a clean pull, and found a problem.
> > 
> > I loaded up the image file:
> > 
> > nos96309l2v030209coco3_80d_50Hz.dsk
> > 
> > This image has TWO /DD modules, and they have the same CRC.
> 
> 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
>
That is a great catch Tormod, thanks!

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

He who hoots with owls by night cannot soar with eagles by day.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.