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 READY FOR USE!

Post by infiniteneslives » Mon Dec 23, 2013 3:29 pm

So I've been running into issues lately with using variables to index arrays. It took me awhile to nail down exactly what was happening. But I've managed to pin this fatal bug down!

So I've got a simple routine that initializes my hero's metasprite. I initially hardcoded everything to index=0, but now I want to use a variable in order to reuse the routine for initializing other metasprites as well.

Code: Select all

	;init our hero!
	msprID = 0
	tempLL = msprID
	metaSprite.state[tempLL] 	= STILL
	metaSprite.character[tempLL] = HERO
	metaSprite.oam[tempLL] 	= $00	; the xx in $02xx	
	metaSprite.xSpeed[tempLL] 	= 0
	metaSprite.ySpeed[tempLL] 	= 0
	metaSprite.xSize[tempLL] 	= 1	;one 8x8 sprite currently
	metaSprite.ySize[tempLL] 	= 1

	;For now, hardcode a sprite up in the top left to get things going
	;TODO: init based on type, location, size, and state etc.
	spriteRam[tempLL] = $10	;Y pos               ***Line #60***
	tempLL += 1
	spriteRam[tempLL] = $00	;tile number        ***Using the variable tempLL here causes Y pos above to be overridden to $00...
	spriteRam[2] = $00	;attrs: 7-flipV 6-flipH 5-Behind 1:0-palette
	spriteRam[3] = $10	;X pos
The above code compiles to:

Code: Select all

.SEGMENT "ROM0"
.DBG LINE, "source\sprite.uc", 38
.PROC spriteInitMetas
.DBG FUNC, "spriteInitMetas", "00", EXTERN, "spriteInitMetas"
.DBG LINE, "source\sprite.uc", 48
	lda	#$00
	sta	msprID
.DBG LINE, "source\sprite.uc", 49
	lda	msprID
	sta	tempLL
.DBG LINE, "source\sprite.uc", 50
	lda	#$02
	ldx	tempLL                                ;X <= tempLL = 0
	sta	metaSprite_state,x                ;everything is working great indexing with X
.DBG LINE, "source\sprite.uc", 51
	lda	#$00
	sta	metaSprite_character,x
.DBG LINE, "source\sprite.uc", 52             ;still working, all these variables getting set to $00
	sta	metaSprite_oam,x
.DBG LINE, "source\sprite.uc", 53
	sta	metaSprite_xSpeed,x
.DBG LINE, "source\sprite.uc", 54
	sta	metaSprite_ySpeed,x
.DBG LINE, "source\sprite.uc", 55
	lda	#$01
	sta	metaSprite_xSize,x                ;still working, Sizes getting set to $01
.DBG LINE, "source\sprite.uc", 56
	sta	metaSprite_ySize,x
.DBG LINE, "source\sprite.uc", 60             ;***sprite.uc line #60****
	lda	#$10                                  ;loading Y position = $10 
	sta	spriteRam,x                          ;X = tempLL = 0, working great, stores $10 into Y pos as expected.
.DBG LINE, "source\sprite.uc", 61
	inc	tempLL                               ;incrementing tempLL just as I asked
	_L000000:                                   ;mysterious label?  What use could this serve???
.DBG LINE, "source\sprite.uc", 62             ;wait a min, you incremented tempLL, but didn't update X which is supposed to equal tempLL... !!!!
	lda	#$00                                  ;okay sure, you're loading $00 for the tile number like I want.
	sta	spriteRam,x                          ;WHAT?  BAD uc65!  no bone!  why did you overwrite the Y-position?!?!?!
.DBG LINE, "source\sprite.uc", 63             ;you just neglected my request to store $00 as the tile number...
	sta	spriteRam+2                         ;okay, now you're doing what I told you to again, but I stopped using the tempLL variable because you were acting up...
.DBG LINE, "source\sprite.uc", 64
	lda	#$10
	sta	spriteRam+3
.DBG LINE, "source\sprite.uc", 76
	lda	#$01
	sta	tempLL
	_L000001:
So it looks to be an off by one error or something like that. tempLL gets incremented, but X is supposed to equal tempLL for indexing. Since X didn't get updated, the Y position got stomped on when trying to store the tile number... Perhaps the creation of that mysterious unused label has something to do with it? IDK...

I'm providing an exact compiled copy of the above code with assembly files and all.
https://dl.dropboxusercontent.com/u/183 ... _broke.zip

Additionally, if I make one change by hard coding the tempLL to 1, things work as expected.

Code: Select all

spriteRam[1] = $00   ;tile number 
Here's a compiled copy for comparisons sake. Probably not of much use if one understands my explaination above, it's no surprise that this works.
https://dl.dropboxusercontent.com/u/183 ... _works.zip


Separate unrelated question:
Is there anyway to declare the default ram segment BSSX? For example: say one has a sprite.uc file, and declares oam segment "ram 2" at the top of the file. But then you want the rest of the file to be the default segment BSSX. I can't find a way to declare the default segment for the rest of the file. You can't put them at the bottom of the file either if you want code above to utilize said oam array. Only way I've found is put them in a separate file and import them. The other means was to not use BSSX, but I don't think that's the best route.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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

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

Post by qbradq » Thu Dec 26, 2013 3:28 pm

INL,

Thank you so much for your continued bug reports! I have created issue 5 for this issue and have reproduced it in the test files. I took some time off for the holidays, but am working on things now :)

I'm glad you figured out continue / break. I will try to re-write that section to be more clear.

As for the default BSS segment, that is ram 1. So to return to the default, just use ram 1.

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

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

Post by qbradq » Fri Dec 27, 2013 9:40 am

There's a new build on the first post, RC5, which contains the fix for Issue 5 described above. I still haven't dug into the import issue, I should be working on that today after I get caught up on some house work :)

The fix should also avoid some other issues I hadn't considered with the optimizer. Basically the fix was to watch for reference changes, and invalidate the register states that held those referenced values.

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

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

Post by infiniteneslives » Sat Dec 28, 2013 3:05 am

So rc5 fixed me up in that one spot, but I seem to have found another similar issue...

https://dl.dropboxusercontent.com/u/183 ... BROKEN.zip

There are .uc.BROKEN .s.BROKEN .uc.WORKS and .s.WORKS sprite files in there which toggle the issue on and off.

sprite.uc

Code: Select all

	;reset to first sprite
	tempLL = metaSprite.oam[msprID]	;spriteRam[tempLL] -> Y position of first sprite

	attrPtr1 = $0200; + tempLL	;point to Y location of sprite to be update
	attrPtr2 = $0203; + tempLL	;point to X location of sprite to be update

	tempJ = 0 ; column * 8
	tempA = spriteRam[tempLL] ; Y location of next sprite to update (redo first sprite)
					;this allows for sprites of width 8

	tempI = 0 ; row * 8
	tempLL += 3
	tempB = spriteRam[tempLL] ; X location of next sprite to update
	result = tempB		  ; extra storage of X location to reset for each row
Compiles to:

Code: Select all

.DBG LINE, "source\sprite.uc", 327
	ldx	msprID
	lda	metaSprite_oam,x
	sta	tempLL			;setting tempLL = index of first sprite in SpriteRam[]
.DBG LINE, "source\sprite.uc", 329
	lda	#$00
	sta	attrPtr1_a		;setting pointer to Ypos of first sprite
	lda	#$02
	sta	attrPtr1_b
.DBG LINE, "source\sprite.uc", 330
	lda	#$03
	sta	attrPtr2_a		;setting pointer to Xpos of first sprite
	lda	#$02
	sta	attrPtr2_b
.DBG LINE, "source\sprite.uc", 332
	lda	#$00
	sta	tempJ			;tempJ = 0
.DBG LINE, "source\sprite.uc", 333
	ldx	tempLL
	lda	spriteRam,x
	sta	tempA			;tempA = Ypos of first sprite
.DBG LINE, "source\sprite.uc", 336
	lda	#$00
	sta	tempI			;tempI = 0
.DBG LINE, "source\sprite.uc", 337
	clc
	lda	tempLL
	adc	#$03
	sta	tempLL			;tempLL += 3
.DBG LINE, "source\sprite.uc", 338
	lda	spriteRam,x		;tempLL incremented by 3!!!!, but X didn't!!!
	sta	tempB
.DBG LINE, "source\sprite.uc", 339
	lda	tempB
	sta	result
I'm not sure what's up... It's pretty similar to the original issue, but i doubly confirmed I'm using rc5 uc65.jar

That and I confirmed that updating to rc5 fixed my previous related issue.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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

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

Post by qbradq » Sat Dec 28, 2013 5:28 pm

Woops, I forgot to test for the STA case, and that code was not working. I've added another regression test for that case and fixed the issue. Please try RC6, now attached to the first post.

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

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

Post by infiniteneslives » Tue Dec 31, 2013 9:16 pm

I've got another issue, seems to be to do with tables and rom segments.

First off, here's my memory.cfg I don't think it's related, but the only thing I've really changed is I don't use BSSX to reserve oam space. I designate it as BSS2 and write uc65 code that manipulates sprite oam memory.

So I switched things around to this:Here is my memory.cfg file. *comments* aren't actually in my file, added for explanation of how I use what.

Code: Select all

MEMORY {
	BSS0:	start = $0000, size = $0100;          *Zero Page*
	STAK:	start = $0100, size = $0100;          *Stack*
	BSS2:	start = $0200, size = $0100;          *sprite OAM memory spriteRam[]
	BSS3:	start = $0300, size = $0100;          *meta sprite objects. I wanted my variables in a fixed location, so sram.s puts them here*
	BSS1:	start = $0400, size = $0400;          *"default" ram space, allocated as the compiler sees fit.*
	HEAD:	start = $0000, size = $0010, fill = yes;
	ROM0:	start = $8000, size = $7FFA, fill = yes;
	VECT:	start = $FFFA, size = $0006, fill = yes;
	ROM1:	start = $0000, size = $2000, fill = yes;
}

SEGMENTS {
	BSS0:	load = BSS0, type = bss, optional = yes;
	BSS2:	load = BSS2, type = bss, optional = yes;
	BSS3:	load = BSS3, type = bss, optional = yes;
	BSS1:	load = BSS1, type = bss, optional = yes;
	HEAD:	load = HEAD, type = ro;
	ROM0:	load = ROM0, type = ro, optional = yes;
	VECT:	load = VECT, type = ro;
	ROM1:	load = ROM1, type = ro, optional = yes;
}

FILES {
	%O: format = bin;
}
So first, a minor comment. Perhaps this is the way it's supposed to be. But it caught me off guard. I found that if I don't declare 'ram 1' in the beginning of my file, all allocated ram ends up in the zero page. So the 'default' (aka no delcaration) puts variables into ZP... But this isn't where the issue is which I found.

The problem is I've created a table in rom 0. But even though I declare rom 0, the compiled assembly doesn't declare which segment of rom to put the table into.

Code: Select all

;-------------------------------------
;Meta-Sprite Character size and tiles
;-------------------------------------
; composite type (struct) used to initialize meta sprites
type metaSpriteCharacter	;meta sprite init variables
	byte firstTile	;first sprite tile number, basis of tiles and graphics
	byte numSpr	;number of sprites in metasprite object (hard math for x/ySize above)
	byte xSize	;number tiles to be updated in x directoin
	byte ySize	;8x16 sprites count as one sprite
end type

;;table for sprite data for character definitions
;VERY IMPORTANT that the indexes of this table line up with character constants 
; ie HERO=0, is first entry in table

rom 0
table msChar of metaSpriteCharacter	;must have more than one row!
;recommend copying comment line to msStart table so character defn's and oam location are proper.	
;HERO	= 0				;2x3 hero
		firstTile=$00,numSpr=4,xSize=16,ySize=16	

;BADDIE1= 1    				;2x2 baddie
		firstTile=$20,numSpr=4,xSize=16,ySize=16

;GOODIE1= 2                           	;2x2 goodie
		firstTile=$10,numSpr=4,xSize=16,ySize=16	

;BADDIE2= 3                            	;2x1 baddie
		firstTile=$29,numSpr=2,xSize=16,ySize=8		

;GOODIE2= 4                           	;2x2 goodie
		firstTile=$18,numSpr=4,xSize=16,ySize=16	

;BULLET1= 5                            	;single sprite 8x8 pixels
		firstTile=$27,numSpr=1,xSize=8,ySize=8		

;THING1	= 6                            	;tall double sprite 8x16 pixels
		firstTile=$2D,numSpr=2,xSize=8,ySize=16 	

;BOSS	= 7                            	;3x3 BIG meta sprite
		firstTile=$24,numSpr=9,xSize=32,ySize=32	
end table
But when I compile this, I get an error:

Code: Select all

C:\Users\Paul\Dropbox\nesdev\dig_deeper5>java -jar ..\uc65.jar source\global.uc
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>java -jar ..\uc65.jar source\nes.uc
source\nes.uc(166): Warning: Possible loss of precision
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>java -jar ..\uc65.jar source\sprite.uc
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>java -jar ..\uc65.jar source\main.uc
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>java -jar ..\uc65.jar source\data.uc
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>path=path;..\cc65\
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>set CC65_HOME=..
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ca65 lib\crt0.s
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ca65 source\global.s
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ca65 source\sram.s
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ca65 source\nes.s
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ca65 source\sprite.s
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ca65 source\main.s
C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ca65 source\data.s

C:\Users\Paul\Dropbox\nesdev\dig_deeper5>ld65 -o dig_deeper.nes lib\crt0.o sourc
e\global.o source\sram.o source\nes.o source\sprite.o source\main.o source\data.
o -C lib\memory.cfg
ld65.exe: Error: Missing memory area assignment for segment `CODE'
Somehow segment "CODE" is being choosen...

I found out the issue is with my xSize and ySize entries of the table...
Looking at the compiled assembly:

Code: Select all

; Assembly generated by uc65
; File: source\sprite.uc
; Built Time: Tue Dec 31 20:49:12 MST 2013
.DBG FILE, "source\sprite.uc", 18155, 1388548144


.IMPORT		metaSprite_ySize
.IMPORTZP	vBlankFlag
.IMPORT		metaSprite_xSize
.IMPORT		metaSprite_aux
.IMPORT		metaSprite_character
.IMPORT		metaSprite_ySpeed
.IMPORTZP	gameState
.IMPORTZP	buttons2
.IMPORTZP	buttons1
.IMPORT		metaSprite_state
.IMPORT		metaSprite_xSpeed
.IMPORT		spriteRam
.IMPORT		metaSprite_oam


	msChar_ySize:                                                           ;;;;;   Hey, these guys don't have a designated ROM segment like the other entries...
		.byte $10, $10, $10, $08, $10, $08, $10, $20
.DBG SYM, "msChar_ySize", "00", STATIC, "msChar_ySize"
	msChar_xSize:
		.byte $10, $10, $10, $10, $10, $08, $08, $20
.DBG SYM, "msChar_xSize", "00", STATIC, "msChar_xSize"
.SEGMENT "BSS0": zeropage
	sprPtr2: .RES 0
.DBG SYM, "sprPtr2", "00", STATIC, "sprPtr2"
	sprPtr2_a: .RES 1
.DBG SYM, "sprPtr2_a", "00", STATIC, "sprPtr2_a"
	sprPtr2_b: .RES 1
.DBG SYM, "sprPtr2_b", "00", STATIC, "sprPtr2_b"
	sprPtr1: .RES 0
.DBG SYM, "sprPtr1", "00", STATIC, "sprPtr1"
	sprPtr1_a: .RES 1
.DBG SYM, "sprPtr1_a", "00", STATIC, "sprPtr1_a"
	sprPtr1_b: .RES 1
.DBG SYM, "sprPtr1_b", "00", STATIC, "sprPtr1_b"
.SEGMENT "ROM0"
	msChar_numSpr:                                                                        ;;;;;;These entries of the table are assigned to ROM as they should be
		.byte $04, $04, $04, $02, $04, $01, $02, $09
.DBG SYM, "msChar_numSpr", "00", STATIC, "msChar_numSpr"
	msStart_oam:
		.byte $00, $20, $30, $ff, $30, $30, $30, $30, $30, $30, $ff
.DBG SYM, "msStart_oam", "00", STATIC, "msStart_oam"
	msStart_state:
		.byte $02, $02, $02, $00, $02, $02, $02, $02, $02, $02, $00
.DBG SYM, "msStart_state", "00", STATIC, "msStart_state"
	msChar_firstTile:
		.byte $00, $20, $10, $29, $18, $27, $2d, $24
.DBG SYM, "msChar_firstTile", "00", STATIC, "msChar_firstTile"
	msStart_palette:
		.byte $01, $02, $03, $00, $02, $03, $02, $01, $00, $00, $00
.DBG SYM, "msStart_palette", "00", STATIC, "msStart_palette"
So I manually modified the assembly which produced the desired result:

Code: Select all

.IMPORT		metaSprite_xSpeed
.IMPORT		spriteRam
.IMPORT		metaSprite_oam


.SEGMENT "ROM0"                                                              ;;;;;I manually added this line in to fix the issue.  No errors.  program works as expected.
	msChar_ySize:
		.byte $10, $10, $10, $08, $10, $08, $10, $20
.DBG SYM, "msChar_ySize", "00", STATIC, "msChar_ySize"
	msChar_xSize:
		.byte $10, $10, $10, $10, $10, $08, $08, $20
.DBG SYM, "msChar_xSize", "00", STATIC, "msChar_xSize"
.SEGMENT "BSS0": zeropage
	sprPtr2: .RES 0
.DBG SYM, "sprPtr2", "00", STATIC, "sprPtr2"
	sprPtr2_a: .RES 1
.DBG SYM, "sprPtr2_a", "00", STATIC, "sprPtr2_a"
	sprPtr2_b: .RES 1
.DBG SYM, "sprPtr2_b", "00", STATIC, "sprPtr2_b"
	sprPtr1: .RES 0
.DBG SYM, "sprPtr1", "00", STATIC, "sprPtr1"
	sprPtr1_a: .RES 1
.DBG SYM, "sprPtr1_a", "00", STATIC, "sprPtr1_a"
	sprPtr1_b: .RES 1
.DBG SYM, "sprPtr1_b", "00", STATIC, "sprPtr1_b"
.SEGMENT "ROM0"
	msChar_numSpr:
		.byte $04, $04, $04, $02, $04, $01, $02, $09
.DBG SYM, "msChar_numSpr", "00", STATIC, "msChar_numSpr"
	msStart_oam:
		.byte $00, $20, $30, $ff, $30, $30, $30, $30,

Also, while we're on the topic of tables...
  • It took me awhile to figure out how to use them. It was pretty much trial and error trying to make sense of the errors when compiling until I realized how to instantiate them. I'd recommend adding a simple example to the documentation.
  • It's a bummer that tables entries can't be assigned by the use of constant types.

    I wish I could do this with my "HERO" constant:

    Code: Select all

    table msChar of metaSpriteCharacter	;must have more than one row!
    ;HERO	= 0				;2x3 hero
    		firstTile=HERO,numSpr=4,xSize=16,ySize=16	
  • It's also a bummer that I can't set address type variables to equal the address of a table entry.
    I tried this:

    Code: Select all

    	fast address ptr
    	ptr = @metaSprite.state[msprID]
    
    and got this:

    Code: Select all

    source\sprite.uc(96): Error: Identifiers may not contain the dot character
    Compilation failed
So in order to set pointers to tables I moved 'fixed' tables I have a 'fake' sram.uc file which is used for importing, but then I use my manually generated sram.s file instead of having uc65 compile it for me. That way I know tables are fixed addresses, then I create constants for those entries and then use those constants to set address variables to point to said tables...

Lastly, here's a copy of my code: https://dl.dropboxusercontent.com/u/183 ... broken.zip There are properly named .s files of broken compiled sprite.s and manually fixed sprite.s
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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

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

Post by qbradq » Wed Jan 08, 2014 7:29 am

INL,

I will try to look into this as soon as I can. Can you help me understand if the table issue is a higher priority for you than the import issue?

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

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

Post by infiniteneslives » Wed Jan 08, 2014 4:28 pm

Neither are very big obstacles right now. I actually moved my tables to their own file and was able to releive the issue. I would say the table issue is a bigger issue than import file ordering.

Any thoughts of supporting stack operations in the future?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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

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

Post by qbradq » Mon Jan 13, 2014 8:10 am

You mean like keywords that push and pop variables? That shouldn't be too hard.

I've been sick sooo dang much recently I'm... well... sick of it :D But once work is caught up I'll start working on this again. Just let me know your priorities.

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

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

Post by infiniteneslives » Mon Jan 13, 2014 9:40 am

Yeah, just simple push, pop, peek would be grand. Perhaps a means to transfer the stack pointer in and out of a variable as well if you want to get fancy.

To be honest the import and table bugs aren't holding me back from anything right now, I can get around them easily. I just wanted to make you aware of them.

I've got some logic I'd like to implement in my game/demo in the near future that could benefit from having easy access to the stack. So if you're able to get those going in the near future I can help you test them shortly there after. No rush on any of this stuff though.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

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

Post by cpow » Sat Mar 14, 2020 11:11 am

Sorry for the bump. I'm just curious if anyone's actively using UC65? I noticed the download link on the website is broken.

I've fixed some issues that crept into nesicide with regard to the UC65 project Hello World template (my fault not UC65). But if nobody's using it I was considering removing it.

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

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

Post by infiniteneslives » Sat Mar 14, 2020 2:02 pm

For what it's worth, to my knowledge, I'm the only one who actually used it. And I have no plans to use it in the future, I think it's safe to say the project/language is dead at the moment.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

Post Reply