| |
Sasq
Registered: Apr 2004
Posts: 155 |
Badass - New 6502 Assembler
The last couple of months I've created a new 6502 Assembler called bass (or Badass).
The basic idea is for it to be as advanced as Kickassembler, but with a less complex, more unified syntax.
And it also has unit tests in an internal emulator.
You can find it at https://github.com/sasq64/bass
I've started a tutorial here: http://apone.org/bass/part1.html
Here is an example C64 source http://apone.org/bass/example.asm.html |
|
... 106 posts hidden. Click here to view all posts....
|
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
a case from 64Tass which has an internal linker, which lets you do crazy stuff.
So you have an IRQ handler, but you have 2, 1 PAL and 1 NTSC and you want to copy it to RAM but you want a hole big enough for it to be copied.
Then you want the some parts of the IRQ handler to be in the same address so other code can reference them.
so you have
* = Location in ROM File
IRQ_NTSC_START
.dsection sIRQ_NTSC
IRQ_PAL_START
.dsection sIRQ_PAL
.logical IRQ_DEST ; make the code assemble as if its in RAM
.section IRQ_NTSC
.section IRQ_NTSC_ENTER
.block IRQ_NTSC
IRQ_ENTER
...code..
.ends
.align size(IRQ_NTSC_ENTER) >? size(IRQ_PAL_ENTER) ; make sure first is in the same sport
IRQ_FIRST
...code...
IRQ_SECOND
...code...
IRQ_THRID
...code...
.bend ; NTSC IRQ
.ends; NTSC IRQ Handler
.here
.logical IRQ_DEST
.section sIRQ_PAL
.section IRQ_PAL_ENTER
.block IRQ_PAL
IRQ_ENTER
...code..
.ends
.align size(IRQ_NTSC_ENTER) >? size(IRQ_PAL_ENTER) ; make sure first is in the same sport
IRQ_FIRST
...code...
IRQ_SECOND
...code...
IRQ_THRID
...code...
.bend
.ends; PAL IRQ Handler
.here
then in the main code you have
IRQ_DEST
.fill size(sIRQ_NTSC) ?> size(sIRQ_PAL)
IRQ_FIRST = IRQ_PAL.IRQ_FIRST
cerror IRQ_NTSC.IRQ_FIRST != IRQ_PAL.IRQ_FIRST, "align filed"
(all of the top of my head so the .section, .block and .logical order might be wrong |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
Just like Jackasser and Frantic already mentioned some cartridge related stuff, this is how I tried to do it in Dreamass - unfortunately after the macro call the PC is off by one ("segmentof" still needs to be fixed on Dreamass) :(
However most inportant for us when asking DocBacardi for features was allowing setting up cart banking like:
#segdef "bank0",$8000-$A000, fillup, force, $bb, abs
#segdef "bank1",$8000-$A000, fillup, force, $bb, abs
#outfile @, "bank0", "bank1"
#include "macros.src"
#include "bank0.src"
#include "bank1.src"
That way problems on missing labels when referencing them in another bank are circumvented as Dreamass has access to all labels and something like ".Bankjsr (somerout)" can be handled by a macro with
#if segmentof {subroutine} != BANKNAME
with BANKNAME being (re)-defined in bank0, bank1, etc. to allow comparison in the macro.
Of course the project wont exceed 64kb here so we didnt see a reason for 24bit addresses.
There is little more to it. Looking at the bass tutorials and stuff something similar should be possible for smaller cart projects, hm?
Some current bass features look nice while of course quite a few things are not my cup of tea :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: @Oswald: Trust me and Krill on this. Only having *= for Eye of the Beholder would have been a disaster. PC and relative PC are just some of many attributes for a segment.
@Sasq: I suggest you take a look at LD65 and how they separate memory and segments as two different entities. It's quite elegant and you should be able to copy those concepts and instead of a separate link file you can have it directly in the source. https://www.cc65.org/doc/ld65-5.html
I trust both of you, I just think assembler functionality like this is often used unecessarily. Segments are not needed to change location of stuff in memory as it was explained here.
Oziphantom's example could be a simple .if PAL then PALIRQ .else NTSCIRQ fex. and the routine needed to be referenced by other code could just use a label.
I would like an assembler that makes code easyer to read and write.
fex in the BadAss example:
!rept 256 { !byte (sin(i*Math.Pi*2/256)+1) * 100 + 24 }
we use sines so often, why cant it be just like FullSine(Length,Max,Min)
(ok can be done through imported functions, that looks really nice in BadAss, but after 30 years of using ".", I cant stomach "!" :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: I trust both of you, I just think assembler functionality like this is often used unecessarily. Segments are not needed to change location of stuff in memory as it was explained here.
Oziphantom's example could be a simple .if PAL then PALIRQ .else NTSCIRQ fex. and the routine needed to be referenced by other code could just use a label.
I would like an assembler that makes code easyer to read and write.
fex in the BadAss example:
!rept 256 { !byte (sin(i*Math.Pi*2/256)+1) * 100 + 24 }
we use sines so often, why cant it be just like FullSine(Length,Max,Min)
(ok can be done through imported functions, that looks really nice in BadAss, but after 30 years of using ".", I cant stomach "!" :)
I kinda agree with you. :) Maybe both could be supported. *= for the quick hacks and segments for full blown cart dev. Also agree on . vs ! :D |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Agree with . rather than !, rest not sure. :) |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
I really wanted dots for local labels, as it naturally appends to the last non local label;
copy:
nop
.loop
dex
beq .loop
Here “.loop” just becomes “copy.loop” |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@sasq: I'm with you there. Also, I've been using ACME for a whole bunch of years, so the ! notation comes quite naturally by now. :)
Speaking of dots at the start of local labels: It is nice if the assembler can spit out all the labels to a file which is compatible with the VICE command line parameter "-moncommands", e.g. something that looks like:
al C:1004 .PL_SP1_chn01
al C:1022 .PL_SP2_chn01
al C:103f .PL_SETPARAMFLAG_chn01
al C:1043 .PL_PARAM_chn01
al C:1048 .PL_SETNOTEFLAG_chn01
al C:104c .PL_NOTE_chn01
al C:1057 .PL_SP1_chn02
al C:1075 .PL_SP2_chn02
al C:1092 .PL_SETPARAMFLAG_chn02
al C:1096 .PL_PARAM_chn02
al C:109b .PL_SETNOTEFLAG_chn02
al C:109f .PL_NOTE_chn02
al C:10aa .PL_SP1_chn03
al C:10c8 .PL_SP2_chn03
al C:10e5 .PL_SETPARAMFLAG_chn03
al C:10e9 .PL_PARAM_chn03
al C:10ee .PL_SETNOTEFLAG_chn03
Note that all labels have a dot at their beginning here, even if those are not local labels in the original ACME source code. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Quoting OswaldOziphantom's example could be a simple .if PAL then PALIRQ .else NTSCIRQ fex. and the routine needed to be referenced by other code could just use a label.
Please tell me how you can use an if/else to handle the case of having PAL And NTSC stored in ROM in a cart that copies the right version into RAM as the game boots depending upon which hardware it is plugged in to. And how you would have just a label to handle reference by other code. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Ozi, my bad I made wrong assumptions what you are doing there. anyway 6 "." directives seems a lot for some irq assembly...
Sasq, why "." cant e used for directives and label hierarhy too? an algorithm can differentiate if its a . infront of a keyword or after a label? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
one reason: to do that, you must know all and every keyword that you will ever use in advance, our your sources will randomly break in the future. it also makes the parser much easier and less messy to do. and its more consistent too. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
