| |
Slammer
Registered: Feb 2004 Posts: 449 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 647 posts hidden. Click here to view all posts.... |
| |
mutetus
Registered: Dec 2020 Posts: 13 |
I'm having a small problem (ka 5.25). So, this works:
.var filename = "textfile.txt"
.import binary filename
But .import text filename doesn't work and it doesn't even tell me what the problem is. Any way around this? |
| |
Maxlide
Registered: Apr 2003 Posts: 37 |
Huhm.
When using a string literal instead of a variable it works.
.import text "textfile.txt"
But why .import binary is working fine with a variable and .import text is not... Well, very odd! |
| |
TWW
Registered: Jul 2009 Posts: 557 |
KickAss has the possibility to create tables with Lo/Hi byte pointers as follows:
Table:
.lohifill 4, List().add($00a0, $01b0, $02c0, $03d0).get(mod(i,16))
Then the LoByte table and HiByte table can be accessed as follows:
ldx #whatever
lda Table.lo,x
sta $fb
lda Table.hi,x
sta $fc
The lengt of the table does not matter, as the .lo/.hi affixes will point to the correct memory location for the tables.
------------------
Now to the question;
Is there a way to know if an address or pointer such as this 'Table' pointer is passed to a pseudocommand (i.e. that it has 2 pointers attached to it or however the internals of this works), and is there a way to easily derive the .lo/.hi addresses within said pseudo?
Reason for the question is because I would like to do this instead of the above example of use:
ldx #whatever
mov16 Table,x : $fb
|
| |
Slammer
Registered: Feb 2004 Posts: 449 |
I know why you want it, since I have also been in a situation where it would be handy. But currently you cannot do that. If you wanna support it you could make a dedicated command like this (Not tested):
.pseudocommand movlh lo : hi : tar {
lda lo
sta tar
lda hi
sta _16bit_nextArgument(tar)
}
.function _16bit_nextArgument(arg) {
.if (arg.getType()==AT_IMMEDIATE)
.return CmdArgument(arg.getType(),>arg.getValue())
.return CmdArgument(arg.getType(),arg.getValue()+1)
}
usage:
movlh table.lo,x : table.hi,x : $fb
The types you can give currently are the normal mnemonic modes (abs, immediate, absx, etc). But there are other situations where extra types are useful. For instance being able to give regA, regX and regY as arguments to a pseudocommand is very usful for e.g. telling the command to leave the result in register A instead of a memory address. So i might extend the pseudocommand arguments in the future. (NB you can achieve regA, regX and regY by being a little creative, but a dedicated argumenttype is nicer) |
| |
TWW
Registered: Jul 2009 Posts: 557 |
Great thanks. Extended mnemonics and regs sounds like a great idea.
Sounds like there may be some update in the future, so I'd like to use the oportunity to report a couple of findings in case they are not known already;
When dealing with 32 bit numbers which is passed as immediate to a pseudocommand, values >= #$80000000 will have it's lobyte set to #$ff if you don't do the opc #arg.getValue()&$ff trick. 16 and 24 works fine though, it's once it turns negative and the bypass is easy once you've figgured it out. Not sure if this is anyting to 'fix' though as going Unsigned perhaps messes up (a lot of) other stuff.
Inside a pseudo, I had to use "arg.getType() == -5" instead of "arg.getType() == AT_IZEROPAGEX" (seems to not be defined). Perhaps the argument type constant was not typed correctly in the manual (page 32). Could be this was fixed already as it was an old observation.
Anyway, cheers! |
| |
Slammer
Registered: Feb 2004 Posts: 449 |
Quote: Great thanks. Extended mnemonics and regs sounds like a great idea.
Sounds like there may be some update in the future, so I'd like to use the oportunity to report a couple of findings in case they are not known already;
When dealing with 32 bit numbers which is passed as immediate to a pseudocommand, values >= #$80000000 will have it's lobyte set to #$ff if you don't do the opc #arg.getValue()&$ff trick. 16 and 24 works fine though, it's once it turns negative and the bypass is easy once you've figgured it out. Not sure if this is anyting to 'fix' though as going Unsigned perhaps messes up (a lot of) other stuff.
Inside a pseudo, I had to use "arg.getType() == -5" instead of "arg.getType() == AT_IZEROPAGEX" (seems to not be defined). Perhaps the argument type constant was not typed correctly in the manual (page 32). Could be this was fixed already as it was an old observation.
Anyway, cheers!
The 32-bit issue was an easy fix. (The number-values in Kick-Assemeber are doubles, which have enough precision - but in the process it went through an 32bit int (which is signed) and then we had the problem.). It will be fixed in the next release. Didn't expect the use of 32bit values :-)
AT_IZEROPAGEX is defined but it is 5 not -5. The the minus modes are the 'unresolved' modes and -5 is 'unresolved indirect x'. Since we could get a processor where you could do:
lda ($1234,x) but not lda ($12,x) which then had to be lda ($0012,x)
KickAss first resolved the address mode when it has the mnemonic and know the available opcodes. I have a todo on exposing the unresolved constants, but using -5 as you do, will work.
Regarding a release, I can't promise anything soon, but if you are in pressing need then pm me and I will see if I can build a jar for you. |
| |
cobbpg
Registered: Jan 2022 Posts: 53 |
Speaking of numbers, I ran into the issue of double precision because I was trying to use 64-bit values. It was not even a very esoteric use case: I was deduplicating characters based on their contents, so I needed to use their bit patterns as keys to a hashmap. Had to convert them into hex strings to get around the issue. It would have been nicer to be able to just use 64-bit integers directly. Of course this is partly a me problem, as I generally prefer using Kick Assembler to write quick preprocessing scripts instead of Python, but it's just nice to be able to use one language within a project for as many things as possible.
In a bit similar vein, another thing that came up recently was the desire to implement segment modifiers as functions inside the scripting language instead of having to make a Java plugin. This would make it easy to spit out assembled structures in particular custom formats without having to implement and/or invoke external tools (e.g. cartconv).
Also, it would be nice to be able to convert numbers into characters, not just the other way around, so one could extract strings from files. As far as I can tell, the only way to approximate this functionality is to define a string listing the ASCII characters in order and use charAt(), like I did in the Kye music pattern parser logic.
And a little thing that sometimes bugs me is that when using the –vicesymbols option the resulting file is completely unordered. From time to time I wish the lines were ordered by address, and all addresses were padded to 4 hex digits, because then it would allow me to quickly check the generated memory layout just by eyeballing this file. |
| |
Slammer
Registered: Feb 2004 Posts: 449 |
If there is a need for it, the ViceSymbolfile could be sorted, but originally it is not intended for readning. You can get an overview af the memory by defining you segments in cronological order and naming you memoryblocks. Then you can get output like this:
Memory Map
----------
ZP-segment:
*$0010-$0037 zpBorderColorPtrs
*$0038-$0039 borderColorProtoThread indexs
*$003a-$003c Generate sprites
*$003d-$003d Pause
*$003e-$0045 Scroll controller
*$0046-$004e General Purpose
Debug-segment:
$0801-$080c Basic
$080e-$080d Basic End
$0810-$0893 Part Starter
Music-segment:
$1000-$245f Dirty_Vaiana.sid
Align100-segment:
$2500-$29ff Charset
MainProgram-segment:
$2a00-$2ac6 BorderColorProtoThread
$2ac7-$2afd UnpackSprite
$2afe-$2b08 Pause
$2b09-$2eb5 FillBuffer Job
$2eb6-$3262 Irq
....
When you are setting the segment you have the option of adding a mememoryblock name and then the above comes natural.
.segment Align100 "Charset"
charset: .fill ...
If you want more info on the output you can use the bytedump - file and see the content of the segments:
******************************** Segment: Debug ********************************
[Part Starter]
0810: a9 00 - start: lda #0
0812: 8d 20 d0 - sta $d020
0815: 8d 21 d0 - sta $d021
0818: a9 00 - lda #0
081a: 20 00 10 - jsr $1000
081d: 78 - sei
So is an ordered vice-symbolfile still usefull?? I'm asking because I know there is many ways of working with Kick Assembler and you seems like an advanced user that probaly know most of the above? |
| |
Slammer
Registered: Feb 2004 Posts: 449 |
Numbers->Chars - I will take a look at this.
64-bit integers not gonna happend anytime soon. I guess it would require more strict typing so the user have to be aware if he is working with an long or a double and I see a new problem comming up when you want bigger chars :-) But you found the right solution. Another way of getting big keys is putting several numbervalues in a container, could be a Vector.
Segment modifyers in KickAss script is also a wish of mine. Just havn't had time. |
| |
WVL
Registered: Mar 2002 Posts: 924 |
Can you put a list in a Hashtable? then you could put a char in an 8 value long list and do it that way.
So something like :
.var emptyChar = List.add(0,0,0,0,0,0,0,0)
.var charHashTable = Hashtable()
.eval charHashTable.put(0, emptyChar)
I also have a png -> charset decoder somewhere, but it didn't occur to me I could use a hasthable to check for duplicates. |
Previous - 1 | ... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 - Next |