I noticed there's a small difference in the LIST statement on the AppleSoft BASIC if compared to the one in msbasic: there's an extra (and ugly) space printed after every token. I wonder where this comes from -- was it an Apple customization?

The source code for LIST seems to be a bit different:
https://github.com/txgx42/applesoft-lite/blob/6a1e34ba6f06d67c13a902da87a550c1fc97acb5/applesoft-lite.s#L956

I guessed it had to be PR_WRITTEN because at least that seems relevant, but thats at some random address. I assume on the ones that get loaded to ram (kim1 is my example) the 'OS' loads to a well known address, it then has to know where to enter the code. Its not at the load address for sure.

Hey, sorry for this most likely dumb question, but..

Why are there 4 Zero-Page start addresses?
e.g. in the File "define_cbm2.s" for the Commodore Basic 2 are 4 ZP addresses configured.

I do know that the ZP is the memory where the address-space starts and was usually used for registers etc. since you could access those bytes really fast.
Therefore I am confused where the 4 ZP-Pointers are pointing to.

Im trying to create a custom "define_custom.s" file for my own project, but I'm unaware of these 4 Pages (since there only should be one???)
(I may figured out that this is cause of 4 different memory selects that the 6510 has, but how to remove the errors from 6502 cpus?)

Also, when using the define_cmb2.s (copied into define_custom.s) im getting on executing ./make.sh:
us

er@DESKTOP-RJE8QP3:/mnt/c/Users/User/Downloads/msbasic-master$ ./make.sh
custom
print.s(104): Error: Illegal addressing mode
cbmbasic1
cbmbasic2
kbdbasic
osi
kb9
applesoft
microtan
aim65
sym1

print.s in line 104 - Why is that? It should be the same config?

And yes i did add the case to the define.s file.

For example,
PRINT "Hello"
work fine, but
10 PRINT "Hello"
RUN
doesn't work.
The line appears to be tokenized and stored to RAMSTART2 correctly,
but LINGET never seems to work.
FNDLIN always seems to look for LINNUM 00 00, even when it's 0A 00.
However, even doing:
00 PRINT "Hello"
RUN
Doesn't work.
I haven't dug further.

See cc65/cc65#2208

The current source does some (rather complex and hard to follow) magic things to figure out the location of certain variables. This broke due to a recent fix in ca65 (arguable the behaviour was broken before AND after the fix - but its now broken in a different way, while another case was fixed).

However, to properly deal with this, the source should be changed to use less magic instead, perhaps use different linker configs for each target binary.

Obviously the problem should ideally be fixed in ca65 as well - but i don't see that happening anytime soon (it's really not trivial to do). I don't see that recent fix being reverted either for that matter, as it fixed a much more relevant problem.