Nitros9 for the masses (was) Re: [Coco] COCO4 Emulator

[John Hogerhuis]

On 5/7/06, James Hrubik <jimhrubik at earthlink.net> wrote:

> Out of curiosity, how would writing a 6809/6309 emu compare in
> difficulty to rewriting NitrOS-9 for the same chipset?  I thought
> that perhaps the two tasks would be similar in nature.
>
> And, as one poster implied, are there really some grey areas with
> regard to whether or not NitrOS-9 is a reverse engineered OS-9?  My
> impression was that it was completely rewritten, first for the 6309,
> then for the 6809, and that there were no licensing restrictions.

I don't want to see a can of worms opened here, but just on the legal
point it wouldn't matter if it was rewritten from scratch just based
on APIs. The implementation would still be tainted if the developers
that created it had intimate knowledge of the implementation of the
original OS-9 by virtue of disassembling parts of it for whatever
reason.

This is why when professional reverse engineering is done it usually
involves two teams. One to reverse engineer (disassemble) and make a
written spec, and another team that works completely independently of
the first based only on the spec. This is the "clean room" kind of
reverse engineering which can be expected to hold up in court.

See http://en.wikipedia.org/wiki/Clean_room_design

I think the current situation with OS-9 is live-and-let-live. As long
as the coco community is not a commercial threat, it probably has
nothing to worry about.

In any event, if one were to make a version for X86, NitrOS-9 would
not be a starting point. A bunch of 6809 assembly code is not portable
to another architecture unless that architecture is basically an
extension of the first. Intel architecture is an entirely different
beast (IO mapped versus memory mapped hardware access, for example).
It would be a rewrite, of OS-9 based on APIs. The problem with OS-9
APIs of course is that they are based on 6809 register set and SWI
instructions so even the APIs aren't portable (they are really ABIs,
application binary interfaces).

-- John.