| |
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 |
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.
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Maybe it's not obvious for everyone that you can program basically the normal way if you like, hence the critisism?
e.g this is still a valid program in kick assembler, no need for any frills if you don't need it.
.pc = $1000
sei
loop:
inc $d020
jmp loop
I think kick assembler is a very fresh and flexible way of doing coding.
Just pick and choose the features you like! :)
Slammer, you did a very good job on this! |
| |
Iapetus/Algarbi/Wood
Registered: Dec 2004
Posts: 71 |
Keep up the good job Slammer! |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Thanks guys.
I have just uploaded the new version so now you can user virtual memory blocks. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Thanks guys.
I have just uploaded the new version so now you can user virtual memory blocks.
Super, works like a charm! :)
I have another question:
Is it possible to reference the pc/define labels that is not equal to the current pc (like in Tasm/dasm or others)
e.g:
lda #$00
hi_addr = * + 2
sta $1000
or
sintab:
.fill 256, blahblah...
costab = sintab + 64
I tried with .var or .const, but that won't allow forward references which is a bit awkward.
Maybe I missed something in the docs?
EDIT: well, I missed the pc stuff in the docs, it's actually precisely '*'. :) |
| |
Mace
Registered: May 2002
Posts: 1799 |
Just got a weird idea the other day, that might not be usefull in a lot of occasions, but it would be nice if it existed... something to code on a rainy Sunday, so to speak ;)
In a program I'm working on, I want to use as little a memory footprint as possible. So I put code in the bitmap, where there are no visible graphics and make sure the colour codes are black.
However, weaving the monolithic code through the available space is a rather awkward job.
Wouldn't it be nice to have some way to 'reserve' certain spaces of the memory and drop data/code in the gaps between it, automatically splitting it and perhaps add JMPs to link the parts?
Just a thought... and I found it very much in the idea of Kick Assembler :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Just got a weird idea the other day, that might not be usefull in a lot of occasions, but it would be nice if it existed... something to code on a rainy Sunday, so to speak ;)
In a program I'm working on, I want to use as little a memory footprint as possible. So I put code in the bitmap, where there are no visible graphics and make sure the colour codes are black.
However, weaving the monolithic code through the available space is a rather awkward job.
Wouldn't it be nice to have some way to 'reserve' certain spaces of the memory and drop data/code in the gaps between it, automatically splitting it and perhaps add JMPs to link the parts?
Just a thought... and I found it very much in the idea of Kick Assembler :)
I want this feature as well in ca65. Although the cases where it's useful are rather limited. But for example interleave speed code that changes the graphics in an FPP-based effect would be a school book case. =) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
In ca65 it would be useful in the following case too:
You want a segment with code from 0800 or so to somewhere like $8000, however, you also want a segment "inserted" from $1000 to $xxxx containing a tune. It would be nice if the linker would be able to figure out by itself where to split the contents of the codesegment WITHOUT explicitly having to supply the absolute size of the tune and divide the code segment in two and move code from codesegment_part1 to codesegment_part2 in case the first one overflows or so. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
I finally got at litte time to check up on the latest ideas.
- Symbol exports for vice : Can't take long to implement so I guess it will be in the next release. Scoped variables might collide, but I guess we can find a solution.
- Segments / namespaces : The more I think about it, the more I think it's a great idea. Its quite simple, but It will solve alot of problems. Do you prefer brackets {}?. There are both pros and cons and I havn't really made up my mind on heavily indented assembler code. however I don't fancy notations like .namespace_start, .namespace_end.
- Export of symbols (for multi part demos): That is allready on my todolist. Are there any preferences? Should we export all symbols or only ones given by export commands? (If it's combined with a namespace the symbols won't collide)
- Splitted codememoryblocks with jmp instructions to tie them together: This is an interesting idea. Not quite trivial. I guess it requires branch commands (bne, beq, bcc .. ) that can jump to a random address, since your normal branch commands easily could get out of range. It can be done, but I think it will take some time.
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote:- Segments / namespaces : The more I think about it, the more I think it's a great idea. Its quite simple, but It will solve alot of problems. Do you prefer brackets {}?. There are both pros and cons and I havn't really made up my mind on heavily indented assembler code. however I don't fancy notations like .namespace_start, .namespace_end.
The indentation is a concern I haven't resolved either, but I think I still prefer brackets.
Quote:- Export of symbols (for multi part demos): That is allready on my todolist. Are there any preferences? Should we export all symbols or only ones given by export commands? (If it's combined with a namespace the symbols won't collide)
Doesn't matter to much because unless it produces something that can be directly used when assembling another file it still has to be parsed and processed.
All symbols to a file will help me achieve that, others may have higher demands. :)
The process could be streamlined with .print to a custom file + macros though.
A structured export would help if you decide to implement some object-format (as in .o) later.
I'd like all of the above, but if I had to pick one it would be just a symbol table dump.
A couple of others:
- how about defining labels from an expression like in my post above? (i.e allowing forward references to a calculated address)
- toDecString() (so you can print integers)
- some way to resolve a passed parameters "name" when inside a macro/function. I guess it will be kind of a hack as I assume you do call by value. It would be quite useful though. |
| Previous - 1 | ... | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 - Next |
