[Coco] Issues with NitrOS9 build

[Tormod Volden]

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