[Coco] Color Forth Help Request
Stephen Pereira
spereira1952 at comcast.net
Fri Feb 20 19:18:10 EST 2015
Hi Art,
thank you very much for your attention and advice.
Yes, I am very experienced with assembly language programming the 8080, but I’m a rank beginner with the 6809. I guess it shows!
I’ll try re-assembling the code with your suggestion.
smp
--
Stephen M. Pereira
Bedford, NH 03110
KB1SXE
> On Feb 20, 2015, at 7:11 PM, Arthur Flexser <flexser at fiu.edu> wrote:
>
> 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
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
More information about the Coco
mailing list