[Coco] NitrOS9 build errors

[Tormod Volden]

On Tue, Jan 21, 2014 at 3:55 PM, Gene Heskett wrote:
> And if people would just read carefully, the descriptions in the
> superdesc.asm file, about 98% of the questions would be answered.
>
> All we need to do people, is to get all of us on the same, _correct_ page.
>
> The broken makefiles in the repo are NOT helping matters when they build
> both the 5.25" 80 track descriptors and the 3.5" 80 track descriptors from
> the same specs.  The only time we need that double track density flag which
> shows up as a set d2 in offset $10 of the disks LSN0, is for the 5.25 disk.

So the options set up in the OS9FORMAT macros are wrong? We should
drop the -dd? A patch would help matters considerably :p

> DW doesn't care, ever that I know of, but once the error is on the disk
> surface as data, the only way I know about how to fix it is dEd.
>
> As for hard drives, the only problem thing I am aware of, and it took me
> years to find it, is how the boot drive is actually specified at build time
> (or later with dEd) in the boot_tc3 boottrack module. There was room in the
> module to do it sensibly, so I patched it several years ago now.  Now you
> can specify drive 0, and actually get drive 0, where before, with the
> woefully inadequate description, a zero failed.  And it failed by not
> stating that it was _the_ byte actually put on the scsi bus to address the
> drive so drive zero in scsi nomenclature is actually a set d0 in the byte
> used for drive address.

Are you talking about a problem that is still there? If this is what I
think you are talking about it is how the ITDRV number which can be
specified at build time now actually means the drive number, and not
an encoded only-one-bit-set value as per below. So everything is fine
then, isn't it?

Tormod

>
> Drive 1 would be a set d1, drive 2=set d2 etc. Drive 7, set d7 is the
> controller itself intended to facilitate more than one drive talking to the