[Coco] Color Forth Help Request

Arthur Flexser flexser at fiu.edu
Fri Feb 20 19:11:36 EST 2015 

I meant that in the emulator, when you switched processors, are you sure
that the Disk Basic version you were using (1.1 or 1.0) remained the same?

Your source code suggests that you may not correctly understand how PSHS
and PULS work.  Are you aware that the order of the registers following
PSHS or PULS makes NO DIFFERENCE whatever?  It's the same postbyte for the
same registers, regardless of whether you PSHS X,Y,U,CC or PSHS CC,Y,U,X.
Why the code should run okay with a 6809 but not with a 6309 is not clear,
but it may be related to this possible misunderstanding.

Art

On Fri, Feb 20, 2015 at 7:02 PM, Stephen Pereira <spereira1952 at comcast.net>
wrote:

> Hi Art,
>
> I don’t know much of anything about the inner workings of the VCC
> emulator.  I just used it as a second platform to test my code and verify
> the things I am experiencing on my real physical system.
>
> Of course, the ROMS didn’t change at all on the physical system, only the
> processor did.
>
> Am I getting your question correct?
>
> smp
> --
> Stephen M. Pereira
> Bedford, NH  03110
> KB1SXE
>
>
> > On Feb 20, 2015, at 6:50 PM, Arthur Flexser <flexser at fiu.edu> wrote:
> >
> > Are you sure the Disk ROM version is identical for the  6809 and 6309
> > tests?  Those ROM calls will only work for one of the two versions.
> >
> > Art
> >
> > On Fri, Feb 20, 2015 at 6:20 PM, Stephen Pereira <
> spereira1952 at comcast.net>
> > wrote:
> >
> >> Hi Art,
> >>
> >> Thanks a million for your replies!  Greatly appreciated.
> >>
> >> Here is my code:
> >>
> >> *
> >> * BRUTE FORCE ROUTINE TO LOAD SCREENS 1 THRU 8
> >> * USING THE DECB LOADM ROUTINE
> >> * JAN 2015, SMP
> >> * ERROR CHECK & ADVICE FROM BRETT GORDON
> >> *
> >>        FCB     $84,'L,'S,'C,'R+$80
> >>        FDB     SSCR-7
> >> LSCR    FDB     *+2
> >>        PSHS    CC,A,B,DP,X,Y,U SAVE ALL JUST IN CASE
> >>        LDX     #$094C  CLEAR FILE NAME LOCATION
> >>        LDA     #32
> >> L3      STA     ,X+
> >>        CMPX    #$0954
> >>        BNE     L3
> >>        LDX     #$094C  FILE NAME LOCATION
> >> L4      JSR     $A1B1   GET KEY IN A
> >>        TFR     A,B     SAVE KEY IN B
> >>        PSHS    B,X,Y
> >>        JSR     [$A002] ECHO KEY
> >>        PULS    Y,X,B
> >>        TFR     B,A     GET KEY IN A
> >>        CMPA    #13     CR?
> >>        BEQ     NXT2    CR ENDS LOOP
> >>        STA     ,X+     STORE KEY IN FILE NAME
> >>        CMPX    #$0954  DONE IF 8 KEYS
> >>        BNE     L4
> >> NXT2    LDX     #$0954  FILE EXTENSION LOCATION
> >>        LDA     #$42    B
> >>        STA     ,X+
> >>        LDA     #$49    I
> >>        STA     ,X+
> >>        LDA     #$4E    N
> >>        STA     ,X
> >>        LDD     #$0200  FILE TYPE = 2, ASCII FLAG = 0
> >>        STD     $0957
> >>        LDX     #$0000
> >>        STX     #$00D3  OFFSET = 0
> >>        JSR     $CA07   OPEN NEXT AVAIL FILE FOR INPUT
> >>        LDD     #RET2   RETURN ADDR FOR LOADM RTS
> >>        PSHS    D
> >>        JMP     $CFE3   LOADM
> >> RET2    PULS    U,Y,X,DP,B,A,CC RESTORE ALL
> >>        JMP     NEXT    RETURN TO FORTH
> >>
> >> This code works fine on a stock CoCo 3, as well as in VCC with a 6809
> >> CPU.  It is not elegant, and I don’t think I tried any fancy stuff.
> Don’t
> >> worry about the first few lines of code - they are for linking into
> Color
> >> Forth, and that seem to be fine.
> >>
> >> As far as I can tell, this code does not initiate any disk activity when
> >> the CPU is a 6309, the machine simply goes off into never-never-land.
> >>
> >> Thanks, in advance, for whatever observations or advice you may have to
> >> offer.
> >>
> >> smp
> >> --
> >> Stephen M. Pereira
> >> Bedford, NH  03110
> >> KB1SXE
> >>
> >>
> >>> On Feb 20, 2015, at 5:54 PM, Arthur Flexser <flexser at fiu.edu> wrote:
> >>>
> >>> The only time that I'm aware of when the 6309 in emulation mode does
> not
> >>> behave exactly like a 6809 is when it encounters an illegal opcode,
> where
> >>> the 6309 vectors to an error location.  (The 6809 will just skip the
> >>> illegal opcode, usually.)  So my guess would be that that's what's
> >>> happening somewhere in Color Forth.  The 6309 error vector, not having
> >> been
> >>> initialized to anything in particular, looks like it winds up in a
> >> section
> >>> of the ROM CLOAD code.
> >>>
> >>> If the 6309 pushes registers enroute to the error vector (I'm not sure
> if
> >>> it does or not, but this would be documented), you could tell what
> >> location
> >>> the error is coming from by pointing the error vector to a routine that
> >>> could look at the stack contents and tell you what the PC register
> >>> contained at the time of the error.
> >>>
> >>> Art
> >>>
> >>> On Fri, Feb 20, 2015 at 5:20 PM, Stephen Pereira <
> >> spereira1952 at comcast.net>
> >>> wrote:
> >>>
> >>>> Hello again, all,
> >>>>
> >>>> I am happy to say that I am one of the lucky ones who was able to get
> >> one
> >>>> of the last CoCo 3 systems from Cloud-9 - I got a fully tricked out
> >> CoCo 3
> >>>> with a Pro-Tektor, a 6309 processor, and the Triad 512K RAM upgrade
> >> (Thanks
> >>>> a million for a great machine, Mark!).
> >>>>
> >>>> I discovered a problem (for me):  My Color Forth code does not run
> >>>> properly on this machine!  What I found is that I can LOADM”CC-FORTH”
> >> and
> >>>> EXEC just fine.  I can issue Color Forth commands (although I have not
> >>>> attempted every command) and things seem OK.  I can issue my added DIR
> >> or
> >>>> BASIC commands, and those works well.  Then I try to load a file of
> >> Forth
> >>>> screens with my LSCR command.  Upon execution of that command, the
> CoCo
> >>>> goes off into never-never-land.  Usually, the machine simply goes off
> >> and
> >>>> never returns.  It does not access the disk, it just disappears.
> >> Sometimes
> >>>> I get a beautiful screen of scrambled graphics, but not usually.
> >>>>
> >>>> I had the bright idea to try all this on my VCC emulator.  The 512k
> RAM
> >>>> does not make any difference.  Color Forth runs just fine.  However,
> >> when I
> >>>> change the CPU to be a 6309, VCC fails in exactly the same way as I
> >>>> described above on my real system.  Actually, on VCC, when I execute
> the
> >>>> LSCR command with a filename, I get a blank green screen with an S in
> >> the
> >>>> upper left hand corner, as if the machine is trying to load a cassette
> >>>> file.  Since I removed all the cassette file code from the Color Forth
> >>>> source code, I am puzzled why this screen appears.
> >>>>
> >>>> I am puzzled by this altogether.  Why should the 6309 not work like
> the
> >>>> 6809, if it is supposed to be code compatible?
> >>>>
> >>>> I would like to hear from anyone who may be able to assist me in
> >> figuring
> >>>> out why my code that works fine on a CoCo with a 6809 does not work
> on a
> >>>> CoCo with a 6309.  Am I doomed to purchasing a 6890 and installing
> that
> >>>> instead?
> >>>>
> >>>> Thanks very much for listening!
> >>>>
> >>>> --
> >>>> Stephen M. Pereira
> >>>> Bedford, NH  03110
> >>>> KB1SXE
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>
> >
> > --
> > 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
>

More information about the Coco mailing list