Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

org Label in freespace yields too small rats tags #273

Open
Alcaro opened this issue Oct 27, 2022 · 2 comments
Open

org Label in freespace yields too small rats tags #273

Alcaro opened this issue Oct 27, 2022 · 2 comments
Labels

Comments

@Alcaro
Copy link
Contributor

Alcaro commented Oct 27, 2022

<Sir Walrus> !rb as -s
freecode cleaned
db 1,2,3
asdf:
org asdf
db 4,5,6,7,8,9,10,11,12,13,14,15
<randombot999> $80FFD7:
0A
$908000:
53 54 41 52 02 00 FD FF 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

02 00 is the length, 3 bytes. The content is obviously much more than 3 bytes.

Easiest fix would be ban org Label to freespace and recommend pushpc.

@Alcaro
Copy link
Contributor Author

Alcaro commented Oct 28, 2022

Another one that shouldn't be allowed to point to freespace is autoclean Label. It's most likely a typo of autoclean JSL Label, and even if it isn't, it cannot possibly do anything useful.

@randomdude999
Copy link
Collaborator

another thing i need to ban is fill/skip align in freespaces, even though i actually suggested that as a workaround in #143 lol

1.9 behavior: on pass 0, the freespace starts at $xx008000 and all aligns will be done with respect to that. say you have db fill 15 : fill align 16 as the contents. end of pass 0 its length is 16 bytes. in pass 1, the freespace is given a snespos immediately. say this happens to be $108012, now the fill align will go all the way until $108030 which is 14 bytes over the freespace's end.

2.0 behavior: the freespace starts at $000000 in both passes 0/1, at the end of pass 1 it's allocated and will just grow in pass 2 instead

simple fix: add a align=X option to freespaces to lock their own alignment to X, and either demand that its value is higher than any skip/fill align if the freespace, or automatically increase its value to the largest such one. downside: will waste a few bytes inside the freespace, when the freespace could start a few bytes later and leave some more space in the rom.

proper fix: ????????
it feels like any fix that tries to not waste that space involves either some annoying linear algebra or is equivalent to SAT

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants