[Coco] NitrOS9 and 6309 code

[L. Curtis Boyle]

There are gaps. Even in the 200+ range that Gene mentioned in another post to the list, there are free entries:
Error 222 ($DE)
Error 225 ($E1)
Error 255 ($FF)


It still think “Bad Module” should be reserved for a damaged module (bad length, CRC, Header parity, etc.) vs. for wrong CPU. This would make it easier for beginners to know whether they have accidentally mixed a perfectly good 6309 module on a 6809 system, vs. trying to figure out if a module has gotten corrupted.

My thoughts, anyways. 


> On May 31, 2019, at 8:59 PM, Allen Huffman <alsplace at pobox.com> wrote:
> 
>> On May 31, 2019, at 9:52 PM, L. Curtis Boyle <curtisboyle at sasktel.net> wrote:
>> 
>> We would have to compare the leftover spots in OS9/6x09 to OSK/OS9000, etc. I don’t have the latter ones anymore, so you will have to let me know if there are any holes between 1 to 255. If not, we will just need to pick one irregardless of later OS9’s.
> 
> I looked at the current errmsg file They go all the way to 255, so I’ll have to scan through it and see what gaps exist.
> 
> If nothing else, we find an error code that is not usable on the 6809 version. Later OS-9 added more fields and such in the header, with errors associated with one of those, so it might be fine to hijack something there.
> 
> 
>>> Why would anything look at this other than the kernel (load/chain)?
>> Load, link (in case someone modified a module in memory), fork and chain I would think would be all that is needed. One could put a check in shellplus too, but it would be redundant.
> 
> Linking to an executable to use it as a subroutine module, yes? I can see that.
> 
> 		— A