Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Badass - New 6502 Assembler
2020-06-28 17:47
Sasq

Registered: Apr 2004
Posts: 157
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....
 
2020-06-28 22:02
Sasq

Registered: Apr 2004
Posts: 157
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
2020-06-28 22:12
JackAsser

Registered: Jun 2002
Posts: 2038
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.
2020-06-28 22:29
Sasq

Registered: Apr 2004
Posts: 157
Quoting JackAsser
T
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 ;)
2020-06-29 00:22
Frantic

Registered: Mar 2003
Posts: 1661
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.
2020-06-29 00:56
Krill

Registered: Apr 2002
Posts: 3098
Quoting Frantic
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.
Would REU be an option? And if not, Retro Replay's banked 32KB of RAM? :)
2020-06-29 01:03
Frantic

Registered: Mar 2003
Posts: 1661
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.
2020-06-29 10:18
Sasq

Registered: Apr 2004
Posts: 157
@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"
2020-06-29 10:34
Frantic

Registered: Mar 2003
Posts: 1661
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.
2020-06-29 13:32
Golara
Account closed

Registered: Jan 2018
Posts: 212
big + for c++ I'll definitely check it out
2020-06-29 13:33
JackAsser

Registered: Jun 2002
Posts: 2038
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)
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
iAN CooG/HVSC
CA$H/TRiAD
Airwolf/F4CG
Paul Bearer
Guests online: 247
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Codeboys & Endians  (9.7)
4 Mojo  (9.6)
5 Coma Light 13  (9.6)
6 Edge of Disgrace  (9.6)
7 Signal Carnival  (9.6)
8 Wonderland XIV  (9.5)
9 Uncensored  (9.5)
10 Comaland 100%  (9.5)
Top onefile Demos
1 Nine  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.5)
6 Scan and Spin  (9.5)
7 Onscreen 5k  (9.5)
8 Grey  (9.5)
9 Dawnfall V1.1  (9.5)
10 Rainbow Connection  (9.5)
Top Groups
1 Artline Designs  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Performers  (9.3)
5 Censor Design  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 OTD  (9.8)
3 Antitrack  (9.8)
4 Fungus  (9.8)
5 S!R  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.059 sec.