| |
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....
|
| |
Sasq
Registered: Apr 2004
Posts: 155 |
@Frantic: I am hoping to avoid multiple levels with both segments and section because it complicates things...
For that particular case you can either mark the section as not ReadOnly and live without the extra checking. But better probably to add support for changing also the ReadOnly state on the fly, like the PC.
I'm wondering if there are other cases that are harder to handle with only one level of sections. Can you think of a situation where you really need the parent/child relationship ? |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: @Golara: There are Windows releases on the git-page, built using MSVC.
Binaries for Linux is usually not a good idea.
And for most people it is just "clone" and "make" and you are done.
I must have missed it then. Normaly there's a "releases" tab at the top, next to issues, pull requests etc. But it's not there now...
As for linux binaries. I know what you mean, but these problems arise when you use dynamic linking and your program wants glib 2.14.2 but you have 2.14.1 so it's not compatible :P This is a static build (that's why it's 22mb) and it should work on anything.
The only thing I can see potentially breaking is trying to run this binary on an older kernel than mine... I don't know if that's a problem but if doesn't work my vote is on that. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
@Golara: I think both those links are for the windows build... |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@sasq: changing the ReadOnly state on the fly sounds like a convenient solution, that doesn't overcomplicate things.
As for other uses of a parent-child type of structure, it is probably not necessary. Benefits of having it, that I can think of, may include:
* Local labels within a "section". If I remember correctly, DASM is pretty strong in this domain. (But you already had something like that in the assembler I think? Some sort of "blocks"? I confess I haven't looked into the details of your assembler yet — so all of what I say is just a bunch of general thoughts based on the discussion in this thread.)
* The grouping of statements that you mentioned, so the assembler knows where to "bank break" (e.g. not in the middle of a section), if you were thinking of some sort of automatic handling of rom banks. In this regard, a "section" could perhaps be defined as "floating", to allow the assembler to place it in any (according to some definition) available space in the ROM banks, rather than necessarily put it where it occurs in the source.
Anyway.. The support for banks/cartridges shouldn't be taken too far. If it comes at the cost of making all kinds of things more complicated in the assembler, it is probably not worth it. Personally I am happy as long as an assembler at least has some basic support for banking/cartridges that makes projects like that a bit easier. |
| |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
