[Coco] 6309 port of NitrOS-9 Level 1

[Tormod Volden]

On Sun, Jan 25, 2015 at 1:28 PM, Tormod Volden wrote:
> 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.
>

I have pushed this and several other fixes (all reviewed by Robert,
thanks!) to the repo. It still doesn't run though. I hope more people
can have a look at it.

BTW, for testing with XRoar using BASIC ROMs, the traditional way, use
for instance:
xroar -default-machine coco -load
$HOME/nitros9/level1/coco2_6309/nos96309l1coco2_6309_40d_1.dsk
-machine-cart rsdos -machine-cpu 6309 -gdb
(you'll need bas13.rom extbas11.rom and disk11.rom)
And then type "DOS" on the BASIC prompt as usual.

Regards,
Tormod