| |
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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: can stand not to poke you guys, although using scripting and macros makes things incredibly easy, if you code a demo you will have to code a speedcode generator at the end of the day, otherwise you will face the problem of loading the huge speedcode...
I also didn't get this point... Wondering if there is a function
script_language -> 6510 speedcode_generator ???
As this seems not to be the case ;p, KickAss advantages mainly show when making some proof_of_concept - routines... or am I completely wrong here???
CF |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
huge speedcode packs quite good though (ofcourse not exactly as good as with a speedcode generator)... i've almost never bothered to write a generator for that very reason (although for the stuff i'm working on atm i'm doing it a lot ...) |
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
The speedcodegeneration routine problem ist not so easy to solve. All speedcode generators have in common, that they copy a sequence of code somewhere into memory, then modify the sourcesequenz, copy the modified seq to a following location and so on...
It depends on what you want to do with the speedcode, when, where and how the modifications are done. This makes it difficult to write a generator for a whole class of speedcodes.
I tried it sometime ago, to write a copier for the speedcodesequences which calls a routine at an adress you passed before as parameter.
The called routine then modifies the code and returns into the copy routine.
I made this with cc65 and the result was heavily bloated code.
Then i made an attempt in assembler, but this lead to a similar complicated routine.
Perhaps i did'nt come up with the right idea then.
Monte
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I agree with Oswald and copyfault. Scripting should be used for proof of concepts, and when you have seen that it works, you can bootstrap your routine by replacing the scripts with code generating assembly code.
Of course, for small pieces of code it doesn't matter, but generally I think it's faster to load a small code generator and have it generate the code than loading and depacking the generated speedcode. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
@Monte Carlos: while trying to do a userfriendly version of the ILM-editor, I also did some FLI-speedcode_generator in 6510 asm... I found it by far more comfortable to run the generator_routine in a main loop which calls a "paste_code" subroutine when necessary; is there a reason to do it the other way around? Maybe I didn't really get your point...
@Groepaz&Cruzer: [exaggerationmode=true] what about not packing all the speedcode and streaming new code_fragments from disk *rotfl* ??? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:@Groepaz&Cruzer: [exaggerationmode=true] what about not packing all the speedcode and streaming new code_fragments from disk *rotfl* ???
not so terribly rotfl at all :) in mathematica there is a part that does exactly that (inside torus followed by tunnel, one speedcode overloads the next, which results in the crossfade effect you can see) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
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 .... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
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 ?=)
oh? no i've never checked it...thats how i remember how quiss explained it to me, but ofcourse...that was like 10 years ago =) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Hi Oswald, Nice with a bit of poking, It gives me the opportunity to state some points :-)
First of all it seams to me that you equals Kick Assembler with loop unrolling and nothing else, and ignoring all the other advantages the script language offers.
When you have converted a logo to koala format with p1 and want to reallocate the data, or use only part of the picture, I guess you do the task by hand and do it every time you change the logo. With Kick Assembler you just write a couple of lines to that does this for you.
When you want to convert a charset from a gif picture to a c64 charset, I guess you have to run a 3rd party converter or write one yourself in another programming language which you have to run every time you select another charset. Why not just write the converter directly in your assembler. Its a lot easier and it runs automatically each time you assemble.
Small jobs like generating a sinus table, some random numbers, a bounce table, etc. you would normally do in other languages. But with Kick Assembler you can do it directly in the assembler.
Secondly, it sounds like you are neglecting macros. Well I dont know about you, but I like to write :BasicUpstart($3000), and then get a basic program that starts my program at $3000, but you can ofcause also generate it the old fashioned way. And I guess my move macro does just as good a job as your hand coded one since its decides on making speed code or normal code depending on how many bytes you want to copy:
.macro Move(source, target, size) {
.if (size<=$1000) :FastMove(source,target,size)
.if (size>$1000) :GeneralMove(source,target,size)
}
(Hey style, the above works since the size is given directly, but I guess you got that by now)
And finally, about making speed code. Its correct that if you want a part to load quickly you should probably unroll you your loops by hand. However, rapidly developing the part and then hand-packing the loop afterwards saves a lot of time since you are sure you pack the correct loop the first time
And by the way, there is a couple of directive to support unrolling of loops on my todo-list, but thats another story.
|
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
slammer, for what it's worth (not a lot), if I'd ever get back to coding on 64, this is the assembler I'd be using. |
| Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 27 - Next |
