| | Slammer
Registered: Feb 2004
Posts: 416 |
Kick Assembler
I recently did a new 6510 assembler and I hereby make it open to the public so you can use it too.
Kick Assembler is the combination of an assembler for doing 6510 machine code and a high level script language. With the assembler functionalities, you can write your assembler programs, and with the script language, you can write programs that generate data to use in the assembler programs. This could be data such as sine waves, coordinates for a vector object, or graphic converters. In addition, you can combine assembler commands and scripting commands which is a powerful combination. A little example: Where other assemblers can do simple unrolling of loops, Kick Assembler can base the unrolling of a loop on a list generated by the script language and select the content of the loop body based on the content of the list. This makes it more flexible when generating speed code.
The script language can handle values such as Numbers, Booleans, Strings, Lists, Vectors, Hashtables, Matrixes and you can define your own structures if the build in doesnt meet your needs. The assembler contains a replica of the java math library + a special 3d library for doing vector math (Rotation, move and projection matrixes). You can also define your own functions.
Finally, I want to mention that the assembler contains some special objects that makes it easy to import graphics (and convert it into you own spooky format which fits into the part you are working on) and music. Since finding the correct play address for a tune has recently been an issue in the *stupid* ASM Sid Player Example- thread I will here show how its done in kick Assembler. You simply load you PSID file into a variable in the script language and then read the things you need to know from the variable.
// Load the music into an object in the script language
.var music = LoadSid("C:/C64Music/Tel_Jeroen/Closing_In.sid")
// init the music
lda #music.startSong-1
jsr music.init
// play the music
jsr music.play
(The full example is listed in the manual)
Feel free to check out the assembler at http://www.theweb.dk/KickAssembler.htm
|
|
... 251 posts hidden. Click here to view all posts....
|
| | Slammer
Registered: Feb 2004
Posts: 416 |
Quote: Groepaz, lol :) not at all, the speedcode is the same all the time, only it loads the tunel data while the torus is displayed, then simply copies the torus data over the tunel one. Have you ever checked how that routine works ?=)
copyfault, loading speedcode is stupid and will be always slower than generating doesnt matter how you do it.
besides you dont need copy code routine. If you want to do it fast do it all low level: lda #opcode sta (),y iny ....
Oswald: When you like lda #opcode sta (),y then you must like the lastest version of Kick Assembler since it has all the opcodes incoperated as constants. So if you want to store an immediate lda command then you do like this:
lda #LDA_IMM
sta ($30),y
which is more readable than
lda #$a9
sta ($30),y
Burglar: Thanks :-) One of the reasons I made the Assembler was to make it easier to make C64 demos, so more coders would return to the scene ;-) |
| | Burglar
Registered: Dec 2004
Posts: 1101 |
Quote:Burglar: Thanks :-) One of the reasons I made the Assembler was to make it easier to make C64 demos, so more coders would return to the scene ;-)
hell, I even tested the whole thing, I was blown away by the ease of the vector example. makes you eager when you dont want to get into (= too stupid) the mathematics of 3d, but still want to use it ;) |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
Slammer, right I understand that macros and scripting is very powerful, but being an old fart used to TASM I just had to troll around a bit :) But now you made me really curious, so when I finally will decide to make that damn step for cross coding kick ass will be the first to check out :) |
| | Style
Registered: Jun 2004
Posts: 498 |
Oswald: Do it now. I thought ca65 was awesome, and kickass...well.... kicks its ass.
|
| | chatGPZ
Registered: Dec 2001
Posts: 11386 |
one thing i always wanted to see in an assembler (and pretty much the only thing i really miss in ca65 :=P) would be the possibility to define a section for linking which is not continues as usual but interupted by various "dont use" areas. image you are coding a FPP style routine... every $400 bytes you would use 40 bytes, but everything else would be free to use (ok, over simplyfying here, but thats not the point). now if you could tell the linker what areas not to use, the linker would skip them (and if its a code section insert a JMP over that area). the linker could also sort data in a way to use the gaps most efficiently. etc. you get the idea :) |
| | Monte Carlos
Registered: Jun 2004
Posts: 359 |
@Copyfault:
Perhaps i should try it this way round.
Don't know how its better.
Monte
|
| | Oswald
Registered: Apr 2002
Posts: 5094 |
is it possible to have macros for 16 bit addition, with automatic adress type recognition?
so we could write stuff like add16 #56,$fc or add16 $1000,$2003, etc etc :) this would make life so much easyer, I hate all the similar over and over again repeating code patterns for doing stuff thats only one instruction on a modern cpu. |
| | Cruzer
Registered: Dec 2001
Posts: 1048 |
@Oswald:
// define macro...
.macro add16 (adr, number) {
lda adr
clc
adc #<number
sta adr
lda adr+1
adc #>number
sta adr+1
}
//use it...
:add16($fe,3)
:add16($2000,$ffff)
You need to define different macros for different address modes though, like immidiate (the version above), absolute (add one address to another), absolute,y etc.
@Slammer: Maybe addressing mode recognition would be an idea, so it could distinguish between :add16(2,2) and :add16(2,#2) ?
|
| | Oswald
Registered: Apr 2002
Posts: 5094 |
yeah if adressing mode recognition would be supported then a whole new world opens for pseudo opcodes \o/ :) inc16,add16 etc etc :D |
| | Slammer
Registered: Feb 2004
Posts: 416 |
I agree. A way to make pseudo commands so you could avoid making add16, sbc16, move16 etc, for all addressing modes would be nice. I thought of difference ways of doing this with macros, and I dont think there is any solution that will be satisfactory. However, if we make a special .pseudocommand directive then it would be possible. The biggest difficulty is to make a convenient notation. Lets take a look at the addressing modes:
No argument
Immediate
Indirect zeropage,x
Indirect zeropage,y
Abolute
Absolute,x
Absolute,y
Indirect
(From the above is missing Zeropage, Zeropage,x , Zeropage,y and Relative, but they are automatically derived from the above when needed, so we dont have to consider those.)
Now how should a macro call with parameters in each of these modes look? Since it's not a macro, we can skip the parenthesis around the call so we can use it for the indirect modes, and we must use another separator than comma for separating the argument since its used in some addressing modes. I need some suggestions here because the ones I thought of look like garbage.
However, Using the existing system is not that bad. You can implement the add16 command like this:
.enum {IMM, ABS, ABSX, ABSY}
.macro add16(mode, arg1, arg2) {
clc
:add8_nc(mode,arg1,arg2)
:add8_nc(mode,arg1+1,arg2+1)
}
// Add8 no carry
.macro add8_nc(mode, arg1, arg2) {
lda arg1
.if (mode==IMM) adc #arg2
else .if (mode==ABS) adc arg2
else .if (mode==ABSX) adc arg2,x
else .if (mode==ABSY) adc arg2,y
else .print "Error: Invalid mode!"
sta arg1
}
The usage of the command is like this:
:add16(IMM,point1,$0800)
:add16(ABS,point1,point2)
ldx #27
:add16(ABSX,point1,pointTable)
|
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 27 - Next | |
