[Coco] New Overhauled CoCoBoot / Nitros9 Lizard

[Brett Gordon]

On Sun, Feb 19, 2012 at 8:31 AM, Christopher Hawks <chawks at dls.net> wrote:

> Brett Gordon said the following on 02/18/2012 03:44 PM:
>
>> Good news Chris!  I think me and Robert Gault found a 6309 bug in the
>> v2 wizard.  there's a version 3 wizard on SF now.  I'm a wee surprised
>> that CoCoBoot didn't find the OS9Boot file on the RBF... I guess LSN0
>> works just as well.  CoCoboot's directory scanner is indeed
>> case-sensitive, btw.. and it expects "OS9Boot", and the same with
>> "ccbkrn".
>
>
>        Found the problem. The directory entry had extra characters after
> OS9Boot. The high bit of the 't' was set (indicating the end of the name in
> OS9), but, maybe the Forth name parsing was looking for a 0 to end the name
> (like a modern string). Anyway, editing the directory entry made the booting
> from RBF work! Neat Stuff!!


I'm glad you figured it out!  Interestingly enough, Forth doesn't use
C-style strings either.  CCB strings are a 16 bit pointer coupled with
a 16 bit length.  I have some special code designed to "translate" the
high-bit toggled string to a forth string for the filenames, but there
very well may be a bug rolling around there!  I'll take a look
shortly.  Thanks for pointing out the fact of the extra character
*past* the high-bit flagged byte... that clue should help me kill that
bug!


>        CCBKrn does show up in 'mdir', but, like you say, after the bootfile
> entries.

Yeah, KRN would add itself to the module directory first, then loads
OS9Boot, scans it, and add it's modules... so KRN would appear first.
With ccbkrn, however,  since all the modules are already in memory
ccbkrn just scans the memory and adds modules how it finds them, and
cckrn just happens to be last in memory.  Boisy has assured me that
module order is not a big deal, so I just saved some complexity by
doing just one module scan.


-- 
Brett M. Gordon,
beretta42 at gmail.com