| |
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 |
@JackAsser: What about this:
stuct Section
string name
uint32 start
uint32 size
uint32 current_pc
uint32 offset
uint8 data[]
uint32 flags
uint8 fillchar
ASSEMBLING
* When a section is created, start & current_pc are the same.
* current_pc can be explicitly set, but normally increases as data[] grows.
* Size can be set if known, otherwise it will be the size of the data array.
* Sections can be switched at any time. Generated code and data is appended to the data array of the current section.
* Addresses can be > 16bit. Recommended to use >,< unary operators to get low and high byte.
* Assembler will generate an error if you try to access memory not within the 16bit range (ie where bits 16 and above differ).
OUTPUT
* If offset is not set, offset = start
* If size is not set, size = data.size
* Otherwise grow data to size and insert fillchar
* Write all sections in order to output file at offset
FLAGS
* NoOutput - Section only used for labels and offsets, will not be written to the output file.
* SeparateFile - write section to its own file, based on 'name'.
* ReadOnly - Intended to go into ROM. Assembler could warn if self modifying code is used.
AUTOMATIC BANK HANDLING
* A single section for multiple banks
* Keep track of where bank ends and wrap to next
* Needs grouping of statements so assembler know where it can "bank break" |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Sounds good I think. Regarding "* ReadOnly - Intended to go into ROM. Assembler could warn if self modifying code is used" it would of course also be important to allow self-modifying code to be assembled to ROM segments, since one would typically copy at least some code from ROM to RAM at runtime, and that code may involve self-modification etc. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
big + for c++ I'll definitely check it out |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Yes frasse, that is a common use case. I have pure rom segments, i have ram segments (stored on rom) and i have bss-segments (pure ram, nothing stored) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting FranticSounds good I think. Regarding "* ReadOnly - Intended to go into ROM. Assembler could warn if self modifying code is used" it would of course also be important to allow self-modifying code to be assembled to ROM segments, since one would typically copy at least some code from ROM to RAM at runtime, and that code may involve self-modification etc. Wouldn't that be a RAM segment that is loaded/assembled to ROM? I.e., a segment with different load and run addresses. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Yes, that's what I tried to say. What Jackasser said, basically. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
Well if it's intended for RAM, don't tag it as "Read Only" :)
The terms here can be a bit confusing though.
So if I understand correctly:
load_address is where the section is expected to end up in memory. It is used for checking overlap, and is normally specified directly by the developer. It defines the initial PC (run_address)
run_address is normally the same as load_address, but if the developer changes the PC inside a section, they will not align any more. run_address is something the developer needs to keep track of "manually".
file_offset normally needs to be specified for cart images, where the output is not a simple linear mapping to RAM. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Yes, the terms are a bit slippery. So, no matter if I use the terms correctly or not, what I meant was this:
If we distinguish between a segment (a larger unit) and a section (several sections of code can be contained in a segment), a segment which is generally intended for ROM and should be read only, may still contain one section of code which contains something that should be executed in C64 RAM or drive RAM and may contain self-modifying code.
!segment ROM_BANK1, $8000-$A000, READ_ONLY { ;a "segment"
[some read only stuff that can't use self-modifying code etc]
!section NAME_OF_SECTION, relativepc=$0800 { ;a "section" inside the segment
[some stuff that is intended to be copied "manually" from the ROM to $0800 in RAM. This should be able to override the READ ONLY restriction that otherwise applies to the segment that contains this section.]
}
[some more read only stuff that can't use self-modifying code etc]
}
Maybe there is some entirely different and better way to solve this. I just wanted to explain in more detail what I meant. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I know this is tool from coder for a coder, but still you could have released built binaries for people that can't into modern software compilationing
I made it :P Statically linked, so it should work on everything
windows 64bit (compiled with mingw on linux): https://mega.nz/file/2gYXFaBA#MftkFZhFnAdm4fKJ7WCZ4sq3ULVemKlXr..
linux 64bit https://mega.nz/file/2gYXFaBA#MftkFZhFnAdm4fKJ7WCZ4sq3ULVemKlXr.. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
@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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
