| |
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....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: See S:T Lars Meeting III - Invite source
This one tracks register usage and cycles in the speed code in one code base and nops in another timed codebase and merges them while maintaining critical timing. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: yes - and to be useful for the generic case it really needs support by the assembler. and its a quite tricky problem to solve too, similar to jackassers recent pack-code-into-banks challenge :)
Which worked extremely well. I now have a prelinker scripts that digests all .o and .lib files and actually generates the link file for ld65. A prelinker. Freed up alot of space. |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Quoting JackAsserThis one tracks register usage and cycles in the speed code in one code base and nops in another timed codebase and merges them while maintaining critical timing. Yes, and that kind of stuff would have to be formalised for a generic tool. =) |
| |
Rex
Registered: Sep 2011
Posts: 14 |
For borderline pacman I coded a cycle-based code merger in C for merging cycle-exact raster code (opening the side-borders, displaying 9 sprites per rasterline etc.) with BOB-rendering code (rendering pacman and ghosts plus updating changed tiles).
In my case the raster-code has defined "cycle holes" with number of cycles that has to be spent and the BOB-code is split into tiny "atomic" blocks marked with the number of cycles the block uses. The code merger is short and runs on the c64 itself - it fills up the "cycle holes" with BOB-codes and NOP/BIT$EA to ensure the exact number of cycles is produced.
https://gitlab.com/camelot/kickc/-/blob/master/src/test/kc/comp..
This was the specific type of merging I needed for that effect. Other effects will need other types of code merging. Merging code and data will require another completely different merging strategy.
I am not sure that a general solution for the "merging problem" does exist. It would be interesting to see some ideas on what a general solution could look like. |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Quoting RexIt would be interesting to see some ideas on what a general solution could look like. I propose... a combined superset of various use-cases and their individual strategies. =)
But i guess the "FPP data"/"NMI handlers" problem would be the easiest to solve first. As in, have some fixed gaps in the code to assemble around. |
| |
Raistlin
Registered: Mar 2007
Posts: 563 |
Nice work, Rex - I use something similar in my all-border DYPPs and other such effects ... though I generate everything on PC by having CPP spit out ASM files.
There are some interesting optimizations to be had with this sort of stuff .. for example, where you have a 13 cycle gap and the code you want to insert is just STAs (4 cycles each). Use 12 cycles and you're left with a 1-cycle "problem... so you use 8 cycles instead, "wasting" 4-5. In my code, where possible, I made it such that I could easily waste an additional cycle - so using STA ----, Y for example, ensuring that the indexed write will always cross a page boundary (and therefore eat an extra cycle). Not always possible of course... but well worth it when it is. |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Quoting RaistlinSTA ----, Y for example, ensuring that the indexed write will always cross a page boundary (and therefore eat an extra cycle). So... formalise as "sta label,_y"? (without index or with y.) :)
(And i believe STA mem16,Y has a cycle count independent of page crossings: always 5.) |
| |
Raistlin
Registered: Mar 2007
Posts: 563 |
Sorry, I’m mixing my STA and LDA timings :-) |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Ok, well, thinking a bit further about it, this is one of the few things where a Turing-complete scripting language native to the assembler would come in handy. (Not much of a fan of that otherwise, one hammer vs. world made of nails and so.)
Something where stateful user code can do accounting and control emission of opcodes, etc. |
| |
Rex
Registered: Sep 2011
Posts: 14 |
That is a neat optimization Raistlin!
Another option would be marking some of the logic code blocks as independent to allow the merger to re-organize them to fill the available cycles with as much active code as possible.
One general need is probably the cycle-exact code merging. A solution for that should be able to fill cycle gaps in cycle-exact raster code. This requires the ability to keep track of cycle counts. A general solution should probably also support keeping track of (and handling) register usage. Smart optimizations like what you are proposing would also be nice.
Merging code and data in memory under constraints is probably a different use-case with different requirements. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 - Next |
