created geos-cbm

[Dirk-Schnorpfeil]

Hi all,

i added support for GEOS subsystem on commodore machines. Also added an example (SamVlir) in example directory, which is a port from assembler to C of the SamVlir demo application of GeoProgrammer.

[mlund]

I think you probably need to run clang-format -i on the .h and .c files. This will pick up the formatting style of the SDK, found in root level (.clang-format).

[mlund]

Should this target be placed under mos-hardware/commodore? This would enable access to common CBM jump tables for ROM functions.

[Dirk-Schnorpfeil]

Should this target be placed under mos-hardware/commodore? This would enable access to common CBM jump tables for ROM functions.

I feel it should not because using the jump tables would crash the program. A lot of zero-page locations which are used by ROM functions are now used by the compiler. All GEOS calls which might call ROM functions first swap the zero page locations which are used back in and after the call again out.

[Dirk-Schnorpfeil]

I think you probably need to run clang-format -i on the .h and .c files. This will pick up the formatting style of the SDK, found in root level (.clang-format).

I tried, but after that the code looked more ugly. The header files are formatted to look close to the symbol definitions in the geoProgrammer package...

[Dirk-Schnorpfeil]

Added a README.md to .../mos-platform/geos-cbm

[mlund]

I think you probably need to run clang-format -i on the .h and .c files. This will pick up the formatting style of the SDK, found in root level (.clang-format).

I tried, but after that the code looked more ugly. The header files are formatted to look close to the symbol definitions in the geoProgrammer package...

Sections can be omitted from formatting by clamping in between // clang-format off and // clang-format on comments. I'd say that this should be done only for exceptional cases where formatting for some reason obstructs readability.

[Dirk-Schnorpfeil]

Hi, one question: how does this go on from here? I assume you will merge the changes to your main branch. But what is the process when I add more functionality or fix bugs?

Would I get the right to make changes to the gros-cbm subdirs or would we go through the pull process every time?

Thanks a lot,

Dirk

[mlund]

Hi, one question: how does this go on from here? I assume you will merge the changes to your main branch. But what is the process when I add more functionality or fix bugs?

Would I get the right to make changes to the gros-cbm subdirs or would we go through the pull process every time?

Thanks a lot,

Dirk

@mysterymath is the one ultimately doing the merging. All following changes go through a similar process, but PR's are then usually small and incremental, and quicker than this first commit.

[mlund]

I feel it should not because using the jump tables would crash the program. A lot of zero-page locations which are used by ROM functions are now used by the compiler. All GEOS calls which might call ROM functions first swap the zero page locations which are used back in and after the call again out.

I'm not too familiar with geos, but know of C64, C128 and an Apple II version. There's also work in progress for MEGA65. How much of the current PR is specific to Commodore? Could some headers or code be shared?

[Dirk-Schnorpfeil]

I feel it should not because using the jump tables would crash the program. A lot of zero-page locations which are used by ROM functions are now used by the compiler. All GEOS calls which might call ROM functions first swap the zero page locations which are used back in and after the call again out.

I'm not too familiar with geos, but know of C64, C128 and an Apple II version. There's also work in progress for MEGA65. How much of the current PR is specific to Commodore? Could some headers or code be shared?

I am also not familiar with GEOS for apple, atari and mega65. At cc65 these are seperate targets on the same level.

[mysterymath]

Another high level procedural question to @Dirk-Schnorpfeil : Are you intending to stick around and be somewhat available to provide support and answer questions about this, e.g. on our Discord?

Most targets are simple enough that I can fill that role myself, but this one has a ton of very specific GEOS knowledge baked in, and I'm out of my depth. I can advise on all the llvm-mos-isms, but I wouldn't be able to answer any questions about the specifics of how it interacts with GEOS, or maybe even the overlay model.

It's not necessarily make or break either way, but I might not end up being able to keep this working long term as we pull in changes from upstream LLVM and things subtly change. If users discover breakages, I'd either need to point them your way or advertise that the platform is increasing degrees of broken. If it gets too broken, I'd eventually need to pull it out.

This is a pretty long term concern though; it doesn't affect all that much in the here and now. Just something to think about.

[Dirk-Schnorpfeil]

Another high level procedural question to @Dirk-Schnorpfeil : Are you intending to stick around and be somewhat available to provide support and answer questions about this, e.g. on our Discord?

Most targets are simple enough that I can fill that role myself, but this one has a ton of very specific GEOS knowledge baked in, and I'm out of my depth. I can advise on all the llvm-mos-isms, but I wouldn't be able to answer any questions about the specifics of how it interacts with GEOS, or maybe even the overlay model.

It's not necessarily make or break either way, but I might not end up being able to keep this working long term as we pull in changes from upstream LLVM and things subtly change. If users discover breakages, I'd either need to point them your way or advertise that the platform is increasing degrees of broken. If it gets too broken, I'd eventually need to pull it out.

This is a pretty long term concern though; it doesn't affect all that much in the here and now. Just something to think about.

Hi, yes i would be around and do maintenance for that geos-cbm target. In a range that can be done having a full time job and family of cause :-)

[mysterymath]

Another high level procedural question to @Dirk-Schnorpfeil : Are you intending to stick around and be somewhat available to provide support and answer questions about this, e.g. on our Discord? Most targets are simple enough that I can fill that role myself, but this one has a ton of very specific GEOS knowledge baked in, and I'm out of my depth. I can advise on all the llvm-mos-isms, but I wouldn't be able to answer any questions about the specifics of how it interacts with GEOS, or maybe even the overlay model. It's not necessarily make or break either way, but I might not end up being able to keep this working long term as we pull in changes from upstream LLVM and things subtly change. If users discover breakages, I'd either need to point them your way or advertise that the platform is increasing degrees of broken. If it gets too broken, I'd eventually need to pull it out. This is a pretty long term concern though; it doesn't affect all that much in the here and now. Just something to think about.

Hi, yes i would be around and do maintenance for that geos-cbm target. In a range that can be done having a full time job and family of cause :-)

That's good to hear, and I'm in a similar boat. This is a hobby thing all around; I'm mostly just trying to do what I can to preserve the knowledge of how things work. :)

[mysterymath]

Oh, and before I forget, @Dirk-Schnorpfeil, thanks for putting this together! Having llvm-mos able to target GEOS is EXTREMELY NEAT, particularly with all of the weird overlay trimmings!

I'll keep churning through these files over the upcoming couple days; looking forward to getting this polished up!

[mlund]

Please also update the root level README.md to include the geos target.