| |
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....
|
| |
Iapetus/Algarbi/Wood
Registered: Dec 2004
Posts: 71 |
Slammer don't forget about the label export... =-) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Basically, yes! :)
I'd very much like the pop in and out of segments concept too though.
You might consider this a named scope of some kind.
For every named scope there should be a different state (pc, and so on). You should be able to end the scope, and then continue on it later by adding an identical scope statement.
Think: namespace in c++ with a twist.
Something like this:
.segment zp {
.pc = $a0 virtual
ptr_zp: .word 0
flag_zp: .byte 0
}
.segment code {
.pc = $1000
sei
... code here ...
}
.segment bss {
.pc = $4000 virtual // or even .pc = segment(code).end or similar
flag: .byte 0
.align 256
tab: .fill 256 // should default to .fill 256,0 if it doesn't already
}
.segment zp {
ptr2_zp: .word 0
}
.segment code {
... more code ...
}
.segment bss {
... more bss ...
}
maybe even:
.segment code {
scope: {
.segment zp {
ptr_zp: .word 0
}
}
}
to allow ptr_zp to be available only in a local scope.
What do you think? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
A cool thing about segments appart from organizing large code is if the possibility to save segments separately is added in some form.
If overlapping segments are allowed (by segment flag), overloading code (and data) parts of a demo can be conveniently represented. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
I'll consider it for future version. However, the features for next version is already done. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Sounds great!
I'll be happy with "virtual" for now. :)
The usefulness of segments really shows when you start splitting your program into many files (which I often do).
With segments you can add stuff to bss and zp locally within each file. No need to keep that in a special place. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: No, not at the moment. If you need this feature now, then I suggest you use the print command to print out the labels you need and then copy them from the console into a label-file. Something like:
.print "al C:"+toHexString(myLabel1) + " .myLabel1"
.print "al C:"+toHexString(myLabel2) + " .myLabel2"
etc.
I agree that an export of the labels would be nice, so it might be included in one of the future versions
Not entierly required but is there a way to do something like this?
(i.e can I get the passed symbol name and or type from within a macro (or other construct))
.macro export(sym) {
.print ".var " + sym.name + "= $" + toHexString(sym)
}
label:
jmp label
:export(label)
Currently I'm just passing the name as a string as well.
BTW, redirecting print output to different files would be cool.
'>>' syntax perhaps, or .open and .print <file> <string>? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
tlr, you are getting over the moon with all that stuff imho. so far I have never needed anything more complex than the good ole tasm. when I will switch over finally to crossing that will be solely for the better editing capabilities, and some sutff like +/-, but definitly not for virtual or real segments, label exporting, and 3d matrices in objects... |
| |
Scout
Registered: Dec 2002
Posts: 1570 |
Quote: tlr, you are getting over the moon with all that stuff imho. so far I have never needed anything more complex than the good ole tasm. when I will switch over finally to crossing that will be solely for the better editing capabilities, and some sutff like +/-, but definitly not for virtual or real segments, label exporting, and 3d matrices in objects...
I was thinking the same thing.
Isn't the code going to be bloated with structs, macro's, functions now which make it unreadable?
?too many options error
I think i'll skip using this assembler... |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Oswald, Scout: Sure, but I already use things like the segment feature of dasm extensively in my code and I intend to port much of that to kick assembler.
Besides, Kick Assembler is already about "many options"...
Sure it can be done with pen and paper, but with a small kid at home I need all the timesaving I can get. :)
The main thing I like about kick assembler is to be able to generate stuff like sine tables parametrized directly in the source. No need to generate that externally just to fix some rounding error or thing like that.
That said, I have just started doing one part in it and so far it works out fine and I'll probably be happy with just the forthcoming "virtual".
The other stuff is just suggestions of functionality from other assemblers which I thought might fit.
All of which should ofcourse be optional!
|
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Many options gives you a choice. You are free to take advantage of them, and if you don't like them just program as you normally would. I don't se how this can be a bad thing.
|
| Previous - 1 | ... | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | ... | 27 - Next |
