CC65 and the PCE

[TheOldMan]

How do you guys feel about it?

Personally....I'll adapt. Either '[' or '(' is fine

Can I macro (something like) MPR6 = $40?

[elmer]

How do you guys feel about it?

Personally....I'll adapt. Either '[' or '(' is fine

Can I macro (something like) MPR6 = $40?

Do you mean just a regular constant, i.e. "TAM #MPR6"? Sure, that would work.

If you use the "TAM6" syntax, then you could just write a macro for that on pceas.

I would fix the non standard compiler instead.

CC65

CC65 has properly compiled the standard C89-compliant code that I've thrown at it ... which HuC's small-C-based compiler doesn't.

I'm not sure what you mean.

[MooZ]

You got me wrong
I was meaning pceas.

[elmer]

You got me wrong
I was meaning pceas.

Ahhh ... I thought that was probably what you meant, thanks for the clarification.

--------------

I've asked the CC65 developers what their opinion is on putting in an option for using square-brackets instead of braces.

As a "programmer", I personally prefer the square-bracket, because it makes things easier to read (to me), and because I like to put expressions in braces, particularly when they are complex expressions, so I prefer

    lda (structure+member_offset),y

rather than

    lda structure+member_offset,y

It's just not possible to use a complex expression in some 6502 instructions if the opening brace of that expression changes the meaning of the instruction.

But, like TheOldMan, I can adapt if necessary.

[MooZ]

I agree. The code is more readable with square-brackets.

[elmer]

I've asked the CC65 developers what their opinion is on putting in an option for using square-brackets instead of braces.

They're OK with the idea in principle ... so now it's all up to the details. 

I've submitted a patch to them that will allow us to use the square-bracket syntax in any assembly source file, controlled by a ".feature" setting.

I look forward to hearing what changes they ask for.

Let me just say thank you guys for furthering the tool progression, for non-programmer types like myself it's endlessly helpful to read through your opinions and documentation! Bravo, I owe you guys some beers or sodas!

Definitely beer ... I've heard that soda is bad for you! 

As I said a year ago in this very thread ...

I'm just stirring things up a bit with a different set of expectations.

If I don't back up my observations with some action to improve things ... then you'll have every right to just dismiss me as a whining idiot.

[Arkhan]

And I guess really, the real dilemma for me is the whole Squirrel thing.

Don't worry about it. From what I've seen, we can put the player in whatever page we want, and fix the startup/irq code to handle it. It shouldn't be any worse than the Huc modifications.

My worry is getting the Huc functions to work. Guess I'll install this, and see what I can do..

Yeah, I'd figure the HuCard stuff is the trickier part since the CD one just calls into existing stuff.    Since potentially using CC65 lets us literally pick everything, we can stop things from getting shoved around how we don't want.

I haven't had time to look at PCE code due to MSXing.   


I'd also be more worried about the screen/vram related library functions, because they are more involved/goony.



As for the ( vs [.

Use both.   

tniasm for MSX supports () and [] for indirection.   It's nice to have that kind of support.

[elmer]

I've got no idea how long it's going to take to get the CC65 patch approved and put into the main line.

If anyone wants/needs a custom-build of CC65 with the new "square-bracket" option, then I can upload one to my dropbox.

[nodtveidt]

As long as by making things standard you don't introduce a whole shitload of additional bloat, I'm all for that.

[elmer]

As long as by making things standard you don't introduce a whole shitload of additional bloat, I'm all for that.

It's a tiny patch. The "documentation" and the stuff for enabling the patch by using the ".feature" command together dwarf the actual patch itself.

Here you go, it's in the "queue" ...

https://github.com/cc65/cc65/pull/269

[elmer]

FWIW, the option for using "[]" for indirection is now in the mainline CC65 repository. 

https://github.com/cc65/cc65

[MooZ]

Cool!

[freem]

alright, I've been trying to get the hang of doing PCE development with ca65 and ld65...

Managed to load a font and write to BAT, though I've been having some trouble dealing with VRAM locations...


rom and source code is available here; requires gnu make and a recent ca65/ld65 set.

With relation to VRAM troubles, I have to offset the location the file gets loaded by 4 (it was previously 3 before I changed how I was calculating the VRAM address)... not sure how to go about fixing this, so I'm hoping one of the PCE gurus will check it out and lend me a hand :p

[touko]

Hi, first you set your VRAM position badly

you did it like that:
st0 #VDCREG_MAWR
st1 #<$0804
st2 #>$0804

It must be:
st0 #VDCREG_MAWR
st1 #<($0800 >> 4)
st2 #>($0800 >> 4)

All VRAM read/write addresses must be (my_address >> 4), and for sprite patterns (my_address >> 5)

PS:Your source code is very clean 

[freem]

PS:Your source code is very clean 

thanks, that was one of my goals

you set your VRAM position badly

you did it like that:
st0 #VDCREG_MAWR
st1 #<$0804
st2 #>$0804

It must be:
st0 #VDCREG_MAWR
st1 #<($0800 >> 4)
st2 #>($0800 >> 4)

I just tried this out in mednafen, and this seems wrong... the VRAM looks like this:

All VRAM read/write addresses must be (my_address >> 4), and for sprite patterns (my_address >> 5)

That sounds right for the BAT and SATB areas, but I'm having trouble with just getting the tiles into VRAM properly...

if I just use $0800 as the VRAM source address, a la

st0 #VDCREG_MAWR
st1 #<$0800
st2 #>$0800

this is what I get in the VRAM viewer:


(edit)
and for reference, here's what the VRAM looks like when I load into $0804: