| |
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....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: The point is that the current program counter is just one of many attributes of a program section/segment. Once you commit to using them, you have better and more elegant control. Then you also prefer to manipulate section attributes rather than rely on the old blunt tool that is "* =".
And besides, can you easily continue right where some other part of code ended, just by using "* ="? That is, without having gaps in your code or awkwardly saving current output PC in some variable to reuse it for some other "* =" further down or similar.
@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 |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
The question is still do we need "nested" sections.
So how would this work with a separate segment for ram_fn ?
!section "bank5", $058000
jsr copy_fn
jsr $c000
rts
copy_fn:
stx ram_fn_end-ram
$ lda ram_fn,x
sta $c000,x
dey
bne -
rts
!pc $c000
ram_fn:
nop
rts
I guess you need something like
!section "ram_fn", start=sections.bank5.end, pc=$c000
ram_fn:
nop
rts
Except hardcoding start is inflexible, ideally you want to
tell the assembler to place section anywhere withing a certain area... hence the division between memory and section in LD65...
Ok so I'll introduce memory areas, and then you can specify section start to either a specific address, or a memory area.
So we should not need something weird like wrapping the ram_fn in a nested section hopefully. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
I recently needed* nested sections.
This was for a portion of code that is copied from somewhere to RAM under $d000 after run, modified in that IORAM section, then later on transferred to the drive and executed there somewhere below $0800.
The nesting came in handy for sharing that IORAM section between drive code and other stuff not executed on the drive.
* Could have done without, mind, but a lot less elegantly and with some more potential sources of bugs. |
| |
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: 1820 |
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: 1987 |
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: 2825 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
