[Coco] Fwd: Re: 64K Coco mode and the MC6883

Tue Mar 28 01:22:18 EDT 2023

Or to correct myself slightly, below, I should say that EXEC P will 
transfer program execution to the third byte of the descriptor. The 
third byte is the MSB of a 16-bit address. While it _may_ execute it 
will not have the desired effect. The desired effect is to jump to the 
location _pointed to_ by the 3rd and 4th bytes of the descriptor. If 
BASIC allowed such a construct it would be EXEC [P] which would mean to 
transfer program control to the address pointed to by the 3rd & 4th 
bytes of the descriptor.

So I'm not really familiar with using VARPTR because I don't program 
much in BASIC. But from what is being stated here and on the Sub-Etha 
site, VARPTR(P$) is actually a pointer that points to a string 
descriptor, not the string itself. So if indeed the 3rd and 4th bytes of 
that descriptor are actually the real starting address of the string, 
P=VARPTR(P$)+2 : EXEC P will not work. EXEC P will transfer program 
execution to the 3rd and 4th byte of the descriptor. These two bytes 
contain an address, they don't contain executable code. Thus, this is 
why the original instruction was to set P=VARPTR(P$)+1 : POKE P, 126 : 
EXEC P. Now you are executing code which is the JMP instruction followed 
by its operand which is the start address of the string.

Just thinking out loud here. I haven't tested this but that's the way 
I'm seeing it.

-Dave

On 3/27/2023 2:30 AM, Arthur Flexser via Coco wrote:
> That is, I think the last part of line 10 should read simply, 
> P=VARPTR(P$)+2
> (the +2 to access the 3rd byte of the 5-byte string descriptor).
>
> I see no need to add that JMP (126) byte.
>
> Art
>
>
> ________________________________
> From: Coco <coco-bounces at maltedmedia.com> on behalf of Arthur Flexser 
> via Coco <coco at maltedmedia.com>
> Sent: Monday, March 27, 2023 3:01 AM
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Cc: Arthur Flexser <flexser at fiu.edu>
> Subject: Re: [Coco] 64K Coco mode and the MC6883
>
> Line 20 should contain colons between the statements rather than 
> semicolons. That would account for the ?SN error, at least.
>
> It looks to me like there's a programming error in line 10. The intent 
> seems to be to poke the 59 bytes worth of ML code represented by the 
> data values into a string, and then execute the string data where it 
> winds up after being poked into memory.
>
> But VARPTR does not do this: it points to the location in the 
> program's variable storage area just above the end of the program 
> where the string descriptor is located. The third and fourth bytes of 
> the string descriptor point to the memory location in the string 
> storage area, near the top of memory, where the actual data values 
> reside. Those are the bytes that the exec address should point to.
>
> Art
> ________________________________
> From: Coco <coco-bounces at maltedmedia.com> on behalf of RETRO 
> Innovations via Coco <coco at maltedmedia.com>
> Sent: Monday, March 27, 2023 2:39 AM
> To: coco at maltedmedia.com <coco at maltedmedia.com>
> Cc: RETRO Innovations <go4retro at go4retro.com>
> Subject: Re: [Coco] 64K Coco mode and the MC6883
>
> Note: This message originated from outside the FIU Faculty/Staff email 
> system.
>
>
> On 3/26/2023 8:18 PM, Sean Conner via Coco wrote:
>> 10 CLEAR 999:FOR I=1 TO 59:READ B:P$=P$+CHR$(B):NEXT 
>> I:P=VARPTR(P$)+1:POKE P,126
>> 20 PRINT"HIT ANY KEY TO RUN TEST";EXEC P;PRINT
>> 30 A=253:M$="ROM-1":GOSUB100
>> 31 A=A+1:M$="ROM-2":GOSUB100
>> 33 A=A+1:M$='ROM-3":GOSUB100
>> 40 END
>> 90 DATA 52,3,173,159,160,0,39
>> 91 DATA 250,26,80,79,183,255,223
>> 92 DATA 183,128,0,183,160,0,183
>> 93 DATA 192,0,76,183,255,222,183
>> 94 DATA 128,0,183,160,0,183,192
>> 95 DATA 0,183,255,223,182,128,0
>> 96 DATA 151,253,182,160,0,151
>> 97 DATA 254,182,192,0,151,255
>> 98 DATA 183,255,222,53,131
>> 100 PRINT M$;": ";
>> 110 IF PEEK(A)=1 THEN PRINT "NO SWITCH NEEDED" ELSE PRINT "SWITCH NEEDED"
>> 120 RETURN
> Hmmm, I copied that into a file, converted it to BASIC tokens with decb,
> and then ran it in XRoar using a CoCo2 NTSC.
>
> At first, I got a ?SN ERROR IN 20
>
> I replaced line 20 with EXEC P and then ran again. It then just went
> unresponsive.
>
> Can you verify this works for you? I tried on a real CoCo 2 with the
> same results.
>
> Jim
>
> --
> RETRO Innovations, Contemporary Gear for Classic Systems
> www.go4retro.com<http://www.go4retro.com>
> store.go4retro.com
>
>
> --
> 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