[Coco] NitrOS9 and 6309 code

Fri May 31 18:26:34 EDT 2019

On Friday 31 May 2019 05:45:04 pm Robert Gault 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.
>
> Robert
>
> Gene Heskett wrote:
> > On Friday 31 May 2019 01:15:15 pm Jeff Teunissen wrote:
> >> On Fri, May 10, 2019 at 11:03 PM Jeff Teunissen <deek at d2dc.net>
> >> wrote:
> >>
> >> Yay, quoting myself, how solipsistic.
> >> [snip]
> >>
> >>> At this point, I figured that the 6309-marked modules were the
> >>> ones that wouldn't run on a Motorola chip (hey, cool, an
> >>> opportunity to do some hacking myself), but then while reading
> >>> some of the source code I saw that some of those modules (Basic09,
> >>> gshell) indeed HAD 6309 code in them, but were still marked as
> >>> suitable for a Moto system. OK, fair enough, I can fix that.
> >>>
> >>> Imagine my surprise when, having changed the module type of gshell
> >>> from Objct to Obj6309 and transferring the resulting module to my
> >>> CoCo, it suddenly started failing with Error #234 (Non-existent
> >>> Module), and wouldn't work until I changed it back.
> >>>
> >>> What gives? [snip]
> >>
You didn't tell it to verify, which would have fixed both the header 
parity and the modules crc.

Now, one of the things I wrote into vfy was the ability to fix that. 
Unforch vfy has no builtin checking facility, so its entirely possible 
to reach into the os9boot file, find the named module and fix it to 
obj6309, when the modules will not run any 6309 codes.  So the moral is 
to only use the 6309 markjed .dsk to build a boot file AND the track34, 
but that needs a freshly formatted disk so track 34 is not allocated.

os9gen will silently NOT rewrite track 34 if there's code there already. 
only one way I know of to cheat that is to format the disk, or, since I 
haven't been able to format a disk in a decade. run kernal2dir on the 
disk and then delete the kernal you can then see with a dir, which will 
then clear those 18 bits in the allocation map that represent track 34.

> >> Curiouser and curiouser -- it seems that NitrOS9 can't run programs
> >> that are marked Obj6309, aborting them with Error 234. Is this a
> >> bug, or is it intentional?
> >
> > Do you have a 6309 in that machine? I do, and I build my boots from
> > 6309 modules, and its never been a problem that I've encountered.
> >
> > Cheers, Gene Heskett

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>