| |
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....
|
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: @Golara: I think both those links are for the windows build...
yes, my bad. Here it is https://mega.nz/file/exYzBCLZ#1KnI4ZkpL-Wk-qtwLkVv1oJtmsw4a_5o0.. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting SasqMy "vague" plan about sections and linking is not to have linking, but rather something more "javascript" like where you can have sources that "export" symbols and then you can import those sources.
And instead of a link script you can choose to have a top level source file that lays out everything. Sounds like this could be achieved with separate section-declare/collect and section directives, as 64tass does.
These allow the position in the source code to be independent of the position in the output binary.
Rest (splitting up source files) can be done via regular include semantics.
*= allows that aswell, I dont really see advantage of sectons for this :P |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: *= allows that aswell, I dont really see advantage of sectons for this :P
Nah. You have position in rom, positioning in ram and positioning in the actual binary (i.e. Bank) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Nah. You have position in rom, positioning in ram and positioning in the actual binary (i.e. Bank)
I mean this part "section-declare/collect and section directives, as 64tass does. These allow the position in the source code to be independent of the position in the output binary." |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Just like chisel and hammer also work to write your next novel, yes. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Just like chisel and hammer also work to write your next novel, yes.
same effor frankly to change section or *= addresses. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
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. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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: 2839 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
