[Coco] NitrOS9 and 6309 code

[Gene Heskett]

On Saturday 01 June 2019 04:28:27 am Jeff Teunissen wrote:

> I posted these messages because I was doing exactly that, adding IFNE
> H6309 stanzas to modules that contained 6309 code, so that they would
> not be accidentally included in a 6809 disk, or at least they could be
> checked. My problem was that when I did it to gshell, or apparently
> any program module, something (shell, fork, etc.) triggered an error
> 234 and didn't allow me to run the program.
>
> Maybe it works on things in the bootfile, because they're not being
> forked or chained to, but not programs?
>
> On Fri, May 31, 2019 at 5:44 PM Robert Gault <robert.gault at att.net> 
wrote:
> > Unfortunately, Jeff has a point but Gene is correct that 6309
> > modules work with a 6309CPU.
> >
> > I just looked at the code on a nightly build of NitrOS-9. I booted
> > the disk nos96309l2v030300coco3_80d.dsk
> > and used the module SCF as a test case. Ident -m scf gave the module
> > as a 6809 obj with a CRC of $37392D. That is indeed the CRC value
> > that I got by compiling the source code for the 6309 SCF Level2
> > module.
> > If you look at the source code for SCF you will see the line
> > tylg     set   FlMgr+Objct
> > and that means regardless of how H6309 is set when assembling the
> > module, Objct will ALWAYS show 6809 code.
> >
> > I have to plead guilty here as I think I'm the last person to work
> > on the SCF source code. However, I'm willing to bet that essentially
> > the entire NitrOS-9 project has the same problem. The line probably
> > should be
> >    IFNE H6309
> > tylg     set   FlMgr+Obj6309
> >    ELSE
> > tylg     set   FlMgr+Objct
> >    ENDC
> >
> > Now to Gene's point. I booted the L2 6309 disk on a 6309 system and
> > then did ded OS9Boot
> > l scf                ie. link to SCF
> > I then edited byte $06 changing it from $D1 to $D7 and then told ded
> > w                    ie. write sector
> > v                    ie. verify
> > On rebooting, an ident of SCF gave a new CRC and 6309 obj code.
> >
> > So the NitrOS9 project does not have the correct values for
> > many/most module TYLG but when changed from Objct to Obj6309, the
> > modules are found and used if the system has a 6309 CPU.

I should point out that the only place where this would be an error, is 
when trying to load and execute a module marked as obj6309, on a 6809.
Running 6809 code on a 6309 is "legal", which removes the need to even 
test for it on any 6309 system.

So for that test I would mask out the lang nibble, and only test for 
obj6309 in the 6809 version of anything leading to the code being 
directly executed.

So runb packed code would also need this test and error report but only 
the 6809 version of runb.

In other scenes like basic09, the src is text so that wouldn't need to be 
tested.

If the makefiles are fixed to properly label this stuff, F$fork might be 
the only place where its tested for. If our assembler can do it, test 
for a 6809 flag, and include that in the 6809 code as a macro from the 
rules file. That way you could "adjust" the rule if its found to 
missfire under some condition that hasn't stuck up its hand for 
attention yet. I like haveing only one place to test, and include it as 
required or drop the whole thing out if its not needed.

I don't recall if there is a bulletproof method to actually do a runtime 
test to see which processor we're running on, one that gives a yes/no 
answer without crashing a 6809.  Has anyone written such a critter yet?

That would be the ideal universal test. Finding and setting a bit in the 
dp, and do NOT use a zero or 1 state, but the define itself stored 
there. That way we would only have to query the hardware once as we are 
loading the boot track if there is room in the boot track. If no room 
there, then put it in krn2.

Then we could, at risk of a bit of code bloat, test as required in real 
time. But only waste time testing the code we're loading by doing it 
only on 6809 hardware. Getting folks to include it in the code they 
write is a waste of time and that conversion would never be finished in 
any of our remaining years.  So its got to be done in the os before we 
jump to the execution of a program's first byte. And that I believe is 
in F$Fork.

Why did Hitachi make the md register write only??? But that would make it 
too simple.  And it might have violated their permission to clone the 
6809 in cmos. We'll probably never know.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>