uc65, a Mid-Level Language Compiler READY FOR USE!

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
infiniteneslives
Posts: 2100
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by infiniteneslives » Thu Jul 11, 2013 2:22 pm

Awesome to see such rapid progress with this qbradq, good work! I'll be out of town next week and probably won't have much time to play around with it till I return, but this is pretty exciting.
Bregalad wrote:I can already see this language mixed up with both assembly and C in a big project :
- Time sensitive things : Assembly
- Medium sensitive things : This language
- Complicated logic not sensitive to timing : C
Except with C integration bankswitching becomes an issue again, although not necessarily depending on how you set things up I guess.

Shiru, I don't believe there is any requirement for MMC3 if you can fit it in NROM you should be good I'd imagine. From what I understand MMC3 choice is due to need/desire to support bankswitching with a similar sturcture to MMC3 as we were discussing in this thread. I'm curious as to your plans on this front though qbradq with various structures of bankswitching. Does the current build support banking? I don't see it on the project page.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

tepples
Posts: 22019
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by tepples » Thu Jul 11, 2013 2:34 pm

Do I need to get working on my math library again so that you can have 8-bit multiply, divide, square root, arctangent, and binary-to-decimal subroutines written in assembly language to use in your programs?

User avatar
qbradq
Posts: 951
Joined: Wed Oct 15, 2008 11:50 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by qbradq » Thu Jul 11, 2013 5:04 pm

Currently the rom statement allows you to place your code into any segment you wish. Using that you can implement banking on your own. Just make sure the banking happens in the fixed segment. There's no plan currently to do any sort of automated banking.

The choice of MMC3 is because I have an MMC3 dev board thanks to INF :) To use this for NROM you just need to change the memory.cfg a bit. I think for release 0.4 I'll have an NROM configuration.
tepples wrote:Do I need to get working on my math library again so that you can have 8-bit multiply, divide, square root, arctangent, and binary-to-decimal subroutines written in assembly language to use in your programs?
I would appreciate it, but it wouldn't fit the core language very well unless the routines supported n-byte arithmetic (or at least 32-bit). It would be useful as a subroutine library though.

tepples
Posts: 22019
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by tepples » Thu Jul 11, 2013 5:47 pm

qbradq wrote:
tepples wrote:Do I need to get working on my math library again so that you can have 8-bit multiply, divide, square root, arctangent, and binary-to-decimal subroutines written in assembly language to use in your programs?
I would appreciate it, but it wouldn't fit the core language very well unless the routines supported n-byte arithmetic (or at least 32-bit). It would be useful as a subroutine library though.
The library as I envision it would be useful even with only 16-bit arithmetic. Several quantities in Thwaite, where the library originated, use the same coordinate format as Balloon Fight and presumably a bunch of other NES games: 16-bit using 8.8 fixed point, where the high byte holds the pixel and the low byte the subpixel.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by thefox » Thu Jul 11, 2013 9:08 pm

Something I forgot to mention earlier: how about 24-bit data types?

EDIT: Or is "long" a 24-bit type?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
infiniteneslives
Posts: 2100
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by infiniteneslives » Thu Jul 11, 2013 9:30 pm

thefox wrote:Something I forgot to mention earlier: how about 24-bit data types?

EDIT: Or is "long" a 24-bit type?
I believe so:

Code: Select all

Type name 	Byte Width 	Use
byte 	     1 	unsigned integer
word 	     2 	unsigned integer
long 	     3 	unsigned integer
dword 	    4 	unsigned integer
address 	  2 	memory address 
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by Shiru » Thu Jul 11, 2013 11:11 pm

More questions, as I'm trying to get my head around this.

What is the intended way to include constant arrays of data, like level maps? They needs to be larger than 256 entries. Another thing that is often needed is an array of pointers, like when I have level maps as separate arrays and want to make a list of them to access by index.

Is the segments (banks) a must? What if I'll have more than 16K code or data to place into a segment, should I break them between segments manually, or there is/will be a way to put them linearly, if bankswitching is not needed?

It is also unclear yet how to interact with the hardware, like NMI and pad polling. I guess that should be done in assembly code, but does it have to be inlined, or could it be done in a separate assembly file?

User avatar
qbradq
Posts: 951
Joined: Wed Oct 15, 2008 11:50 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by qbradq » Fri Jul 12, 2013 4:14 am

This is great feedback Shiru, thank you!
Shiru wrote:More questions, as I'm trying to get my head around this.

What is the intended way to include constant arrays of data, like level maps? They needs to be larger than 256 entries. Another thing that is often needed is an array of pointers, like when I have level maps as separate arrays and want to make a list of them to access by index.
These needs will be addressed in the next release, 0.5. It will introduce structures, arrays of structures, tables (initialized arrays in ROM), and the address data type (pointer).
Shiru wrote:Is the segments (banks) a must? What if I'll have more than 16K code or data to place into a segment, should I break them between segments manually, or there is/will be a way to put them linearly, if bankswitching is not needed?
The segment sizes are 100% a function of the linker memory map. For NROM you'd just use a single 32KB ROM bank.
Shiru wrote:It is also unclear yet how to interact with the hardware, like NMI and pad polling. I guess that should be done in assembly code, but does it have to be inlined, or could it be done in a separate assembly file?
NMI is handled by the "frame" required subroutine. This subroutine is set as the NMI vector, and includes register push and pop code automatically. If you wanted to implement this vector in a separate assembly file, just export the label as "frame".

Pad polling can be done with the port data type. A port is basically an absolute memory reference, but it's intended purpose is to interact with hardware registers. I am working on an input example now.

Currently you can't interact with code from other assembly files (or even other uc files). This will be addressed in release 0.6 with the import statement.

User avatar
Movax12
Posts: 522
Joined: Sun Jan 02, 2011 11:50 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by Movax12 » Fri Jul 12, 2013 8:05 am

Suggestions:

-If it doesn't exist, a signed integer type (for proper comparisons).
-The language should be able to define a mapper type and output the memory configuration for know mappers without the user having to understand how to make/edit ca65 config files.
-NMI routine should be definable in code. This is leaking into the realm of an API, not sure how far you want to go, but you could have something like:

Code: Select all

.proc NMI
    inc frameCounter

    lda userNMIvector
    ora userNMIvector + 1
    beq exit
        jsr doUserNMI
    exit: 
    rti
    
    doUserNMI:
    jmp (userNMIVector)
    
.endproc

; basic example:
; turn off NMI or do something to make sure this macro is not interrupted

.macro setNMIRoutine addressImmediate
    lda #<addressImmediate
    sta userNMIvector
    lda #>addressImmediate
    sta userNMIvector + 1
.endmacro


User avatar
qbradq
Posts: 951
Joined: Wed Oct 15, 2008 11:50 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by qbradq » Fri Jul 12, 2013 8:18 am

Signed integer types were deliberately left out because they do not fit the machine architecture. However there are comparison operators that handle the negative flag, namely < 0, <= 0, > 0 and >= 0. It is in the maybe pile though.

As for automatic mapper handling, that's something I've put in the maybe pile. I'm going to see how it goes with having some pre-defined default memory maps.

Finally, the NMI routine is definable in code, as well as the IRQ routine. The "frame" and "interrupt" subroutines are automatically placed in the respective vectors. Upon entry all registers are pushed onto the stack. All return statements (and the implied return at the end of the subroutine) generate code to restore the registers from the stack and RTI.

tepples
Posts: 22019
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by tepples » Fri Jul 12, 2013 8:23 am

qbradq wrote:These needs will be addressed in the next release, 0.5. It will introduce structures, arrays of structures, tables (initialized arrays in ROM), and the address data type (pointer).
I think it might be wise to create a 24-bit "far pointer" type with the bank number in bits 23-16. This would allow easy manipulation of (address, bank number) pairs, and it'd cover an eventual extension to 65816.
NMI is handled by the "frame" required subroutine. This subroutine is set as the NMI vector, and includes register push and pop code automatically. If you wanted to implement this vector in a separate assembly file, just export the label as "frame".
I just wonder how clear the use of "frame" as the name of the NMI handler might be. It might also be useful to provide a default implementation of this required subroutine that just increments a variable on zero page, as seen in Lawn Mower and Thwaite.
Pad polling can be done with the port data type. A port is basically an absolute memory reference, but it's intended purpose is to interact with hardware registers.
So sort of like a volatile pointer in C?

EDIT: As for the "frame" and "interrupt", some coding styles use different NMI handlers for different parts of the game, with a JMP trampoline in RAM to switch among them. It might be wise to make a qualifier for subroutines that says "this subroutine uses interrupt calling conventions, including callee-saved A/X/Y, no return value, and RTI instead of RTS."

User avatar
Movax12
Posts: 522
Joined: Sun Jan 02, 2011 11:50 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by Movax12 » Fri Jul 12, 2013 8:25 am

If you wanted to be able to compare variables to other variables, you would need to know if a variable is signed to compare properly: http://www.6502.org/tutorials/compare_beyond.html#5

For the NMI thing, that just feels more high level to me, to have the ability to define your NMI in a statement. If you don't want to go that way it's cool.

EDIT: link.

slobu
Posts: 275
Joined: Tue Jul 12, 2011 10:58 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by slobu » Tue Jul 16, 2013 12:12 am

Holy cow! I forget to lurk for a few days and this leaps into life!

This project and infiniteneslives flash carts are pretty much the only way someone like me could possibly create their own NES game. I'll be watching and attempting to get this working for myself :)

I've mentioned this before, but, batari BASIC is something I wouldn't be shy about drawing inspiration from:
http://www.randomterrain.com/atari-2600 ... mands.html

I especially enjoy how easy it is to deal with joystick input and sprite positioning
if joy0left then player0x = player0x - 1

Bitwise operations are also dead simple to use in bB. Anything from picking individual bits from variables used as counters (i.e. if counter{4} then goto march) to defining single bits in a byte for use as boolean variables: "def isnekkid=attributes{0}"

User avatar
Movax12
Posts: 522
Joined: Sun Jan 02, 2011 11:50 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by Movax12 » Tue Jul 16, 2013 7:14 am

I've mentioned this before, but, batari BASIC is something I wouldn't be shy about drawing inspiration from:
For comparision, In ca65hl:

Code: Select all

if buttons & #BUTTON_A goto label
or

Code: Select all

if buttons & #BUTTON_A
;do stuff
endif
Bitwise stuff:

Code: Select all

setFlag foo, bit
clrFlag  foo, bit

if { flagSet foo, bit }
; do stuff
endif
How to the bit test is determined:

Code: Select all

.macro flagSet addr, bitnum
        .if .not .blank(bitnum)
            
            .if bitnum = 7
                bit addr
                set_flag_test N set
            .elseif bitnum = 6
                bit addr
                set_flag_test V set
            .else
                lda addr
                and #(1 .shl bitnum)
                set_flag_test Z clear
            .endif
            
        .else ; no bitnum specified
            bit addr
            set_flag_test N set
        .endif
    .endmacro

User avatar
qbradq
Posts: 951
Joined: Wed Oct 15, 2008 11:50 am

Re: uc65, a Mid-Level Language Compiler for the cc65 Toolch

Post by qbradq » Wed Jul 24, 2013 4:48 am

Just wanted to let you folks know I'm not dead yet :) For the past two weeks I've been closing one project and opening another at work, so my workload is essentially doubled. I am looking forward to working on uc65 again within the next two weeks or so when things settle down.

Post Reply