| |
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....
|
| |
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: 2839 |
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: 555 |
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: 2839 |
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: 555 |
Sorry, I’m mixing my STA and LDA timings :-) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
rearranging code in cycle exact code doesnt only require tracking cycle count... you also have to track where in the line you are and consider the dma setup cycles. sounds like fun =) |
| |
Raistlin
Registered: Mar 2007
Posts: 555 |
Just to throw another spanner into this already quite complex system...
Something else that I do on C++ side is that I have some "loose" setup things that need to be done .. so, for example, it's common to want to move the Sprite Y values down every 21 lines. Except of course it doesn't need to be on exact lines - it can be almost anywhere within the existing line of sprites - so you have ~20 raster lines where it could happen for every 21.
I effectively make that a low-importance task - but higher importance than the "slow" task (which is usually something like the blitting of the DYPP or circle scroll).
And... it's good to know what raster-line you're on at each point - when scrolling D800 data, or when updating bitmap data etc, it's good to know whether you're behind or ahead of the raster.
Coding all of this, and keeping within memory budgets, is quite a task ;-) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting RaistlinCoding all of this, and keeping within memory budgets, is quite a task ;-) Top Coders
1 Raistlin (9.8)
2 Graham (9.8)
3 Crossbow (9.8) That top spot don't come from nothin'. =) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
