| |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2850 |
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. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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.
It's not only that. It's more about the assembler needs to know the bank ID for all labels it has so that bank switch macros knows what bank to switch in when JSRing (via ram trampolines) across different banks.
ca65 solves this by allowing an arbitrary bank-id to be assigned to a memory-directive. Segments emitting code into that memory will have all their labels assigned with that bank ID and other code can resolve it with the .bank(label) operator. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Would a .sectionof(label) directive allow for that? Sections are named, of course. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Would a .sectionof(label) directive allow for that? Sections are named, of course.
Yes, maybe. Bottom line I have a jsrf (jsr far) macro that works and looks exactly like jsr but the assembler emits all the code needed to perform a proper bankswitch and back again upon rts. This gives me the freedom to shuffle around the segments completely across various banks without having to think about it. That makes it very easy for me to fill the banks and pack the code tightly and never worry about breaking code when shuffling around the segments onto other banks. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
Could this be supported by simply allowing > 16bit addresses in symbols ? Meaning normally the top 8bits of a 24bit address would be the bank.
So then something like
!macro jsrf(a)
lda #a>>16 ; load bank
; Do magic
jsr a ; (top bits ignored as normal)
}
!section "bank5", $05a000
my_code:
nop
rts
!section "bank6", $06a000
nop
jsrf my_code
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Could this be supported by simply allowing > 16bit addresses in symbols ? Meaning normally the top 8bits of a 24bit address would be the bank.
So then something like
!macro jsrf(a)
lda #a>>16 ; load bank
; Do magic
jsr a ; (top bits ignored as normal)
}
!section "bank5", $05a000
my_code:
nop
rts
!section "bank6", $06a000
nop
jsrf my_code
That a step closer indeed. Also, sections needs to be filled and padded out so that the final binary have all the segments after each other. So you typically need a size and a fillval parameter for each section also. You also need to specify run-adress, in this case $8000 for both segments.
Also declaring a section with the same name further down but without adress should ideally continue to fill the section with "stuff". I use this f.e. to put bits and pieces of the clear frame buffer unrolled code where there is room. All of a sudden a bank is filled and a small portion of this clear code has to be moved to another section, so I just change the bank-id (or in your case section name) to something else and see if it fits there.
But all of this are just curiosities. I will NOT port EotB to this assembler, but just wanted to share the more advanced use cases with banking and segments. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
Quoting JackAsserT
But all of this are just curiosities. I will NOT port EotB to this assembler, but just wanted to share the more advanced use cases with banking and segments.
EoTB must be one of the largest C64 projects ever, so yeah that would be pretty stupid ;) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Well, good support for cartridge banking is a nice thing to have, regardless of whether the project is super big or not. DreamAss has some features along those lines as well, and I used that at some point for a little cartridge project I was fiddling with. At the moment I am working on a new music editor, and it may eventually turn out that I need to do it as a cartridge image instead, to be able to fit all the stuff that I want to have in it. If that would happen, a great assembler with intuitive support for cartridge banking would surely be my first choice. |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting FranticAt the moment I am working on a new music editor, and it may eventually turn out that I need to do it as a cartridge image instead, to be able to fit all the stuff that I want to have in it. Would REU be an option? And if not, Retro Replay's banked 32KB of RAM? :) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
The way I see it a cartridge image would be a more straightforward solution to the problem at hand, and loading time would be close to zero, even though both of the options you mention would of course provide some more space in different ways. Anyway, a discussion of that would probably be off topic in this thread, and the preferred option is still to squeeze it all into normal C64 RAM if possible. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
