[Coco] strange bug in toolshed

[Tormod Volden]

On Sun, Jan 26, 2014 at 10:54 PM, Christopher R. Hawks wrote:
> On Sun, 26 Jan 2014 21:51:34 +0100
> Tormod Volden <lists.tormod at gmail.com> wrote:
>
>> On Sun, Jan 26, 2014 at 9:37 PM, Christopher R. Hawks wrote:
>
>         Well, it's 110 spots out of 171, but, however we want to do it.
> Back in the day, a 'dependant' make was preferable to a 'make clean
> all'. Sometimes it made more than an hour difference. Today, not so big
> a deal.

OK, if the numbers are like that it is another question. Maybe fix up
the 61 others? :)

> BTW: the original error is caused by level1/dalpha/bootfiles/kernel
> being 4098 bytes in size. padrom carps about it being more than the
> 4096 size requested and level1/dalpha/bootfiles/makefile fails. and so
> does the os9 gen in level1/dalpha/makefile (like you posted).

Right, I can see this error now. I'll have to check what have added
two bytes. But I think more is wrong. If I skip the kernel file, and
just add the boot file, the disk is unreadable afterwards:
 rm nos96809l1v030209dalpha_80s_1.dsk
 os9 format -e -t80 -ss -dd nos96809l1v030209dalpha_80s_1.dsk
-n"NitrOS-9/6809 Dragon Alpha #1"
 os9 dir nos96809l1v030209dalpha_80s_1.dsk
(lists the empty disk)
 os9 gen nos96809l1v030209dalpha_80s_1.dsk -d -b=bootfiles/bootfile_cohr_ss80
 os9 dir nos96809l1v030209dalpha_80s_1.dsk
now returns error 216 or hangs.

I think my test yesterday was with an earlier revision, and I didn't
get the padrom error then.

What I got to before running out of time was that it looks like
init_lsn0() finds a value in lsn0->dd_lsnsize and sets bps to a wrong
value, causing wrong seeks in _os9_read().

Tormod