[Coco] Extended Color BASIC memory

Kip Koon computerdoc at sc.rr.com
Thu Apr 4 02:22:04 EDT 2013


William,
Duh!  I thought $BC01 was way to big!  Thank you for correcting me.  I
definitely didn't catch that one.  Got to keep those addressing modes
straight.
Kip

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of William Astle
Sent: Thursday, April 04, 2013 1:05 AM
To: coco at maltedmedia.com
Subject: Re: [Coco] Extended Color BASIC memory

That bit getting loaded into A is the upper 8 bits of the first usable
graphics page after the Extended Basic or Disk Basic system variables. 
Thus, that code will work on a cassette system or a disk system. It will
also work properly if someone set up some non-default environment with the
FILES command.

Normally, $BC will have 6 in it for cassette basic and 14 for disk basic
right after startup. The "lda" is getting the value at $BC, not $BC into A.
Thus, the result is that Y will have $0601 or $0E01 in the typical case of a
cold start.

The JMP transfers control back into the PCLEAR command after all the
parameter checking at which point it sets up things correctly for basic to
continue, relocates the program, and gets on with things.

On 13-04-03 10:41 PM, Kip Koon wrote:
> Allen,
> The 6809 machine code in the date statement disassembles as shown in 
> the following listing.
> -------------------------------------
> 0000: C6 01          ldb        #01
> 0002: 96 BC          lda        0x00BC
> 0004: 1F 02           tfr         d,y
> 0006: 7E 96 A3     jmp      0x96A3
> --------------------------------------
> AccB is loaded with $01.
> I'll have to check with the variable definitions in the unraveled 
> series to see what $00BC is but AccA is loaded with the contents of 
> memory location $00BC.  AccD (AccA+AccB concatenated) is TFR 
> (transferred) to Index Register Y.
> The JMP instruction is jumping back into ECB at address $96A3 with a 
> parameter of $BC01 in index register Y.  Do I have this right?  My 
> 6809ing is still quite a bit rusty.
> I'm still learning the great commands to include files into and 
> extract files from RS-DOS disk image files, so I finally just created 
> a text file with "123456789", changed the extension to "bin" and 
> edited the resulting file named pclear0.bin with WINHEX changing the 
> contents to the hex bytes shown in the data statement below.
> I was curious to see what the hex code machine language was doing 
> also, so I thought I'd find out.  It didn't take me long to do since I 
> had already compiled 6809dasm.  I used 6809dasm compiled and run in 
> CYGWIN to get the resulting disassembly listing.
> Hope this helps.  Have fun!
> Kip
>
> -----Original Message-----
> From: coco-bounces at maltedmedia.com 
> [mailto:coco-bounces at maltedmedia.com] On Behalf Of Allen Huffman
> Subject: [Coco] Extended Color BASIC memory
>
> <portions deleted>
>
> 5
> FORA=0TO8:READA$:POKE1024+A,VAL("&H"+A$):NEXTA:EXEC1024:DATAC6,1,96,BC
> ,1F,2,
> 7E,96,A3
>
> So... Someone wanna re-remind me what this actually does to accomplish 
> PCLEAR 0?
>
> -
> Allen Huffman - PO Box 22031 - Clive IA 50325 - 515-999-0227 
> (vmail/TXT
> only) Sent from my iPad.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco




More information about the Coco mailing list