[Coco] Issues with NitrOS9 build

Bill Pierce ooogalapasooo at aol.com
Fri Jan 24 16:08:11 EST 2014


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

 



More information about the Coco mailing list