Target System: CUSTOM, CPU: 65C816

[noyen1973]

LPOINTER should be allowed in this configuration. Using var LABEL: byte at $123456; results in the LABEL being reduced to a 16-bit value, $3456. 65C816 should be allowed to used up to 24-bit values. procedure InitC256() bank(4); should also be allowed for long addressing (JSL/RTL).

CUSTOM 65C816 CPU should have the same settings as the SNES target system, just without the built in init.s.

Override Program Start Address doesn't seem to work, keeps using .org $800.

[leuat]

Thanks for reporting this - the "custom" type hasn't been tested much yet.

a) LPointer and bank have been added. b) addresses for custom systems with 24-bit buses can now have 24-bit address locations (at $123456 etc) c) was a bug in the compiler where procedures placed at a bank didn't really happen. Has now been fixed, and you should be able to do procdure FarAway() bank(5); etc

d) program start address is now printed correctly

Please remember that a Cl65 project will need its own configuration file + call the assembler parameters "manually", ie copy "smc.cfg" from a regular TRSE SNES project to match your "main.ras" (ie main.cfg) and set up the assembler parameters something like this: "-C @prg.cfg @prg.asm -o @prg.bin" (@prg gets replaced with the currently compiled file)

No init headers are added to the .asm file, it's all very barebone!

have triggered a new build, should be ready in about 30 minutes

[prg]

You summoned me?

[leuat]

hahaha fantastic! I use the keyword "@prg" in some settings to replace a filename, but I guess Github thought it meant you - @prg

[noyen1973]

With the CUSTOM 65816 CPU it now adds .p4510 ; 65816 processor (for Mega65?) to define the CPU but it should be .p816.

Also noticed this odd piece of code:

	; LineNumber: 12
	sep #$10        ; disable X/Y 16-bit
	lda #$33
	ldx #$1122 ; <--- Should be ldx #$22
	sta C256_zp
	stx C256_zp+1
	lda #$11
	sta C256_zp+2
	rep #$10        ; enable X/Y 16-bit

from this C256::SetTextFont($112233,2049)

The ldx #$1122 may end up as an absolute address when assembling if the assembler doesn't recognize the SEP instruction.

[leuat]

ah sorry about that, in all the haste I managed to flip which string went to the 4510/65816. Have fixed it up. Could you provide me some more info about SetTextFont, it takes a long as parameter #1? I haven't really looked at this compiler for a long time, expect there to be lots of bugs... and yeah I see that the ldx parameter is incorrect here!

[leuat]

ok the middle byte ldx should now also be fixed, added an and &0xFF to all const 24-bit numbers

[noyen1973]

Can I get the LONG variable type enabled for the 65816?

Here's the output from a procedure:

C256RND:
	phb
	phk
	plb

	; LineNumber: 47
	; ****** Inline assembler section
		lda GABE_RNG_DAT_LO
	
	; LineNumber: 50
	plb
	rtl

Does TRSE modify the data bank register? If not then I would think whoever uses assembly routines to change the data bank register would know to preserve and restore it on their own so you could get rid of the extra phb, phk, plb, and final plb. That could save 4 bytes per procedure.

[noyen1973]

When using an LPOINTER with indirect addressing, square brackets [] should be used rather than round brackets (). I was trying to find a way to write to the screen memory quickly and came up with this.

var VKYScreen: lpointer;
begin
  VKYScreen:=$afa000;
  VKYScreen[1]:=65; // letter "A"
end.

Turns into:

	sep #$10        ; disable X/Y 16-bit
	lda #<$AFA000
	ldx #>$AFA000
	sta VKYScreen
	stx VKYScreen+1
	lda #^$AFA000
	sta VKYScreen+2
	rep #$10        ; enable X/Y 16-bit
	lda #$41
	ldy #$1
	sta (VKYScreen),y ; <<<--- should be sta [VKYScreen],y

Using only round brackets () will get the 16-bit address and use the current data bank while [] will get the full 24-bit address. So LPOINTER use [], POINTER use ().

Lots of learning along the way. Found a better solution with faster results.

var VKYScreen: array[2000] of byte at $afa0000;
begin
  VKYScreen[1]=65;
end.

[leuat]

hehe you're having fun! I'm unfortunately incapacitaed by covid, but will hopefully be able to have a look at at this next week.

But - when it comes to brackets and non-brackets, the pascal standard is [] - and there are thousands of TRSE source files that already use [], so this can't be changed. but I'm thinking that I might add casting - like, casting a 24-bit to 16-bit pointer cast like myLPtr[i].16Bit := ... or toPtr16(myLPtr)[i] etc

[noyen1973]

Sorry to hear about your health situation.

You don't need to change the TRSE syntax. Change the generated source code so that if the variable is defined as an LPOINTER use '[variable]' instead of '(variable)' in the operand for indirect addressing. You might need to check the CPU type as well since this is 65816 specific.

I made a guess my number game for the C256 (around 750 bytes) so I'm getting the hang of things. I'm attempting a minesweeper clone with graphics and SID sound. Thankfully I discovered "@startassembler". Loads of fun all around, C256 and TRSE!

[leuat]

ah yes this is true, sorry, totally forgot about how to address 24-bit pointers in cl65! I thought that it was already implemented, hmmm let me check.. might be that it is all implement, but I've forgotten to turn it on for the Custom system (since I've been using this a lot to make SNES stuff)

[leuat]

there, fixed and pushed. New build will take about 30 minutes. lpointers should now use the [] addressing mode for both loading and storing

[leuat]

mind you there are some problems when allocating a lpointer - the 6502 assumes 2 bytes per pointer default, so you need to change the project settings->zeropage pointers to reflect this (that is, increase with 3 instead of 2)

[noyen1973]

Thanks for the quick updates. I spread my zero page pointers out by multiples of 3 already after I noticed it in the sources.

Can I get "@endassembler" which complements "@startassembler"?

Hope you don't mind but I may have more requests. Though @endassembler is on the top of my list right now.

[noyen1973]

Math for lpointers is only done in 16-bits. Here's an example.

var lptemp: lpointer;
	const GRPH_LUT0_PTR: integer=$2000;
...
	lptemp:=#VKY+GRPH_LUT0_PTR;

Results in this code:

	; INTEGER optimization: a=b+c 
	lda #<VKY
	clc
	adc #$00
	sta lptemp+0
	lda #>VKY
	adc #$20
	sta lptemp+1

Doesn't add the bank byte. Since the destination is an lpointer it needs this:

	lda #^VKY
	adc #$00 ; (GRPH_LUT0_PTR>>16)&$FF
	sta lptemp+2

I tried using #VKY[GRPH_LUT0_PTR] as an argument and it seems to use the same 16-bit math.

[noyen1973]

Found another problem with lpointer.

procedure testppp(ppp: lpointer);
begin
end;
var zz: lpointer;
begin
	testppp(zz);

Here's the code from it.

	sep #$10        ; disable X/Y 16-bit
	lda zz
	ldx zz+1
	sta ppp
	stx ppp+1 ; \ __missing 'lda zz+2'
	sta ppp+2 ; /
	rep #$10        ; enable X/Y 16-bit
	jsl testppp

It doesn't load the bank byte before storing it. That's all for now, time for bed.

[leuat]

@startassembler just takes a single string as input. it is used only to inject assembly before TRSE outputs anything else (which I once needed for a demo)

In order to insert regular assembly language, you use

asm("

lda #10

"); etc, which should be evident from most of the libraries that are written in asm! You can switch to assembly language anytime.

Also, lpointers don't have 24-bit operations, only 16 bit. I never implemented any "long" for the 6502, and the lpointer was an ad hoc that I got up and running for the SNES. Adding 24-bit support would allow for "long"s, but I don't have mul / div methods for these - but I can see if I can manage to get addition to work, although I was kinda hoping that data wouldn't span several banks...