6502 High Level Assembler - NESHLA

[tebe]

http://neshla.sourceforge.net/

 

NESHLA generates pure 6502 code (CC65 works different)

 

 

Example:

byte setamt[] = {0,0,0,0,0,0,0,7}
function vram_init()
{
vram_set_address_i(PAL_ADDRESS)
vram_write(#0x30)
vram_write(#0x21)
vram_write(#0x22)
vram_write(#0x0F)

vram_set_address_i(NAME_TABLE_0_ADDRESS)
lda #0
ldy #8 // 1024 bytes
do {
	lda setamt-1,y
	ldx #128
	do {
		vram_write_a()
		dex
	} while(not zero)
	dey
} while(not zero)

vram_write_string_inl(NAME_TABLE_0_ADDRESS+0x40, strTitle)

vram_clear_address()
}

function palette_memset()
{
unvblank_wait()
vblank_wait()

vram_set_address_i(PAL_ADDRESS)

ldy #16
do {
	vram_write_regx()
	dey
} while(not equal)

vram_clear_address()
}

[flashjazzcat]

Necrobump. This looks interesting...

 

And this:

 

https://code.google.com/p/uc65/

Edited January 19, 2014 by flashjazzcat

[Van]

This project @ Nesdev seems similar

http://forums.nesdev.com/viewtopic.php?f=2&t=10242

Of course it is primarily for NES code but could be useful for other 6502 systems. The good thing is, it is in active development so it should improve.

Yogi

[+Gemintronic]

Not being an asm programmer my opinion is pretty weak. That being said, would uc65 be useful? You'd always be guessing at what assembly it actually outputs. When people plan out their kernels cycle by cycle this seems like a problem.

[Stormtrooper of Death]

I only know Atmas II assembler....

[flashjazzcat]

Not being an asm programmer my opinion is pretty weak. That being said, would uc65 be useful? You'd always be guessing at what assembly it actually outputs. When people plan out their kernels cycle by cycle this seems like a problem.

There's not really that much smoke and mirrors going on with uc65, from what I can gather at least, and you're always free to inline pure ASM when you absolutely have to know what's going on cycle for cycle (and you have the ra65 output to look at as well). I guess I was just attracted to these projects because of the frustrations and limitations of C discussed in the other thread. Something like uc65 outputs pure assembler, without bulky stack overheads, etc, and makes for fairly well structured code. The purpose I had in mind was to try and make GUI development more attractive to a wider audience, when the time comes.

[Van]

Not being an asm programmer my opinion is pretty weak. That being said, would uc65 be useful? You'd always be guessing at what assembly it actually outputs. When people plan out their kernels cycle by cycle this seems like a problem.

I agree to some extent. If your project relied on cycle counting, you probably wouldn't need a HL assy tool. But you could hand optimize the assembly, Again if you take the time to optimize, you prob should just write straight assembly anyway.

My impression is it's a lib of macros and that can be useful, if you already know assembly. You'd still need to manage memory resources and understand the underlying HW, all of which is abstracted by HL languages such as C.

Yogi

[flashjazzcat]

Well, some of the pseudo high-level constructs are present in MADS, but they're not the most elegant looking constructs. Structures and such like are damned useful in MADS, though, and uc65 looks like a nice compromise. A library of macros are all very nice, but as I say the code can end up looking a mess. The code examples on the uc65 wiki look quite nice.

[gozar]

There's not really that much smoke and mirrors going on with uc65, from what I can gather at least, and you're always free to inline pure ASM when you absolutely have to know what's going on cycle for cycle (and you have the ra65 output to look at as well). I guess I was just attracted to these projects because of the frustrations and limitations of C discussed in the other thread. Something like uc65 outputs pure assembler, without bulky stack overheads, etc, and makes for fairly well structured code. The purpose I had in mind was to try and make GUI development more attractive to a wider audience, when the time comes.

 

uc65 kind of reminds me of Action!.

 

Something else to add to my list of things to learn... :-)

[+Gemintronic]

It looks like the author of NESICIDE is also interested in uc65. NESICIDE is the first robust integrated IDE for C development targeting the NES. I wouldn't doubt that a project template could be set up to target the Atari 400/800/XL series using uc65.

[roland p]

The code in the first post looks nice.

Dealing with all kinds of loops and branches to labels can be a real pain.

 

If the assembler allows labels, all opcodes, and .byte statements then you can always go low-level if you want. Best of both worlds.

[_The Doctor__]

why do wonderful threads like this die for lack of interest when they are so da*n intriguing!