[Coco] Graphics on NitrOS9 Level 1 v3.3.0 (CoCo 1)

[L. Curtis Boyle]

I think you are correct - I sent David a possible patch to try.

L. Curtis Boyle
curtisboyle at sasktel.net



> On Feb 6, 2018, at 5:45 PM, Arthur Flexser <flexser at fiu.edu> wrote:
> 
> I'm not an OS-9 user, but I can tell a certain amount from the code and the
> comments/labels.
> 
> It appears that the routine is supposed to be entered with one of the bits
> of A set, and with B equal to zero.
> 
> The routine determines which particular address from a table of 2-byte
> addresses is to be used.  If bit n of A (n = 0 to 7) is set on entry, then
> the loop will execute n+1 times and exit with 2 x n in the B register.
> That number will be used as an offset from the start of the table of 2-byte
> addresses.
> 
> One plausible guess for the source of the bug is that instead of B being
> set to zero prior to entering the loop, A got set to zero instead, causing
> the loop never to exit since the set bit of A that is being searched for
> does not exist.  So you might look and see if there is a CLRA shortly
> before the loop that is supposed to be CLRB.
> 
> Art
> 
> 
> On Tue, Feb 6, 2018 at 6:00 PM, David Ladd <davidwladd at gmail.com> wrote:
> 
>> Rogelio,
>> 
>> So using MAME's debugger I was able to find that where we think it gets
>> locked up is actually it is stuck in a loop that it never gets out of.
>> After doing some digging through GrfDrv and VTIO for level1 I did find the
>> only routine that matched the routine it is forever locked in a loop is in
>> VTIO
>> 
>> Here is the code
>> {code}
>> AddrFind
>>         bita  #$01       ; Done all shifts ?
>>         bne   AddrDone
>>         addb  #$2        ; increment addr offset ptr
>>         lsra
>>         bra   AddrFind   ; Test again
>> AddrDone
>> {code}
>> 
>> So from what MAME is showing me A register is always 0.  So hopefully
>> someone more versed in 6809 assembly and the VTIO for level1 could possible
>> look into this that understands how this routine should be working.
>> 
>> 
>> +-----------------------------------------------------------------------+
>> | David Ladd a.k.a. PacoOtaktay a.k.a. Drencor                          |
>> | YouTube: http://www.youtube.com/user/PacoOtaktay                      |
>> | YouTube Gaming Live: https://gaming.youtube.com/user/PacoOtaktay/live |
>> | Websites: http://dwladd.com     &     http://www.theterrorzone.com    |
>> | G+:  https://plus.google.com/113262444659438038657                    |
>> | G+:  https://plus.google.com/+DavidLaddPacoOtaktay                    |
>> |                                                                       |
>> | Do you have your CoCo 3 yet?                                          |
>> +-----------------------------------------------------------------------+
>> 
>> 
>> On Mon, Feb 5, 2018 at 10:12 AM, Rogelio Perea <os9dude at gmail.com> wrote:
>> 
>>> On Mon Feb 5 2018, David Ladd wrote:
>>> 
>>> So after some looking at NitrOS-9 L1 it does seem there is a issue with
>>>> VTIO and possible GrfDrv as well.
>>>> 
>>>> So far VTIO does not seem to automatically load GrfDrv as it should.
>> If
>>>> you merge GrfDrv in the OS9Boot file on startup so it is in memory then
>>>> when VTIO tries to call GrfDrv the system locks up.
>>>> 
>>>> Graphics display codes that start with $15 to $1F are directed to go
>>>> through GrfDrv.  Which this functionality seems to be currently
>> broken...
>>>> 
>>> 
>>> Thanks for the reply and the tech insight David, will take care of
>>> reporting suspected bugs at the Sourceforge page as noted.
>>> 
>>> 
>>> -- RP
>>> 
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> https://pairlist5.pair.net/mailman/listinfo/coco
>>> 
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>