[CSDb] - User Forums - Kick Assembler

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Kick Assembler

2006-06-07 21:34

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....

2006-09-12 09:11

Copyfault

Registered: Dec 2001
Posts: 467

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

2006-09-12 09:15

chatGPZ

Registered: Dec 2001
Posts: 11154

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 ...)

2006-09-12 10:14

Monte Carlos

Registered: Jun 2004
Posts: 351

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

2006-09-12 10:17

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.

2006-09-12 13:38

Copyfault

Registered: Dec 2001
Posts: 467

@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* ???

2006-09-12 13:46

chatGPZ

Registered: Dec 2001
Posts: 11154

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)

2006-09-12 14:27

Oswald

Registered: Apr 2002
Posts: 5032

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 ....

2006-09-12 16:47

chatGPZ

Registered: Dec 2001
Posts: 11154

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 =)

2006-09-12 19:04

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.

2006-09-12 19:15

Burglar

Registered: Dec 2004
Posts: 1051

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

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

jmin
Didi/Laxity
MagerValp/G★P
Nordischsound/Hokuto..
zscs
Hobbit/Laser Inc.
MWR/Visdom
void256
Guests online: 73

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.7)
6 Uncensored  (9.6)
7 Comaland 100%  (9.6)
8 No Bounds  (9.6)
9 Wonderland XIV  (9.6)
10 Aliens in Wonderland  (9.6)

Top onefile Demos

1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Dawnfall V1.1  (9.5)
8 Daah, Those Acid Pil..  (9.5)
9 Birth of a Flower  (9.5)
10 Quadrants  (9.5)

Top Groups

1 Nostalgia  (9.4)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Offence  (9.3)

Top Organizers

1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 Tim  (9.7)

Page generated in: 0.057 sec.