[Coco] 6309 port of NitrOS-9 Level 1

[Tormod Volden]

On Sun, Jan 25, 2015 at 12:13 PM, Tormod Volden wrote:
> On Sun, Jan 25, 2015 at 12:04 PM, Tormod Volden wrote:
>> On Sat, Jan 24, 2015 at 11:39 PM, Tormod Volden wrote:
>>> On Sat, Jan 24, 2015 at 9:37 PM, Robert Gault wrote:
>>>>
>>>> No. There is no emulator of a coco1 or coco2 that incorporates 6309
>>>> emulation far as I know.
>>>
>>> I have been testing this in XRoar. The gdb disassembler doesn't
>>> interpret the 6309 opcodes but otherwise it works fine.
>>
>> For everybody interested, this is how I test it in XRoar (after: make
>> PORTS=coco2_6309 dsk)
>>
>> xroar -default-machine coco -nobas -extbas
>> $HOME/nitros9/level1/coco2_6309/bootroms/nos96809l1_1773.rom -load
>> $HOME/nitros9/level1/coco2_6309/nos96309l1coco2_6309_40d_1.dsk
>> -machine-cart rsdos -machine-cpu 6309 -gdb
>>
>> I use the NitrOS-9 boot ROMs so I don't need the BASIC ROMs.
>>
>> Exactly how the 6309 boot crashes seems to depend on non-initialized
>> memory, which could explain the non-reproducibility. When I start up
>> XRoar as above, it freezes on the sysgo welcome screen. If I do a hard
>> reset in XRoar (shift-ctrl-R) it will after the sysgo welcome screen
>> return to the boot loading screen "Nitros9 Boot" and repeat this
>
> Thinking about it, an XRoar hard reset does indeed initialize the RAM,
> so I am not sure what is going on here.

I have resorted to good old code inspection for a while. I have
discovered a bug in the scheduling code:

$ hg diff
diff -r 19b022ee24ba level1/modules/kernel/krn.asm
--- a/level1/modules/kernel/krn.asm    Sun Jan 25 00:45:30 2015 -0700
+++ b/level1/modules/kernel/krn.asm    Sun Jan 25 13:16:04 2015 +0100
@@ -353,7 +353,7 @@
          ldu   P$SP,x                  else get process stack pointer
          ldd   R$X,u                   get the value of the process X reg
          subd  #$0001                  subtract one from it
-         std   P$SP,u                  and store it
+         std   R$X,u                   and store it back
          bne   L01FD                   branch if not zero (still will sleep)
 L01E7    ldu   P$Queue,x               get process current queue pointer
          bsr   L021A


On 6809, P$SP has the same value as R$X, hence it works fine there!

And this kicks in on the 50/60 Hz IRQ so I was thinking this can
explain the variability in XRoar - it might not reset the 50 Hz cycle
on its hard reset. Indeed it seems more reproducible with above fix -
it never freezes up any longer - but unfortunately it still crashes.

Tormod