well i'm blind, i found the file in the obvious named "src" folder. thank you!


Just Raw Binary, the header is completely custom and programs are loaded via Serial
to be more specific my custom header is 32 bytes large, first 4 bytes are a hardwired magic number (0x65C81600 in this case), next is a 32-bit address that defines where in memory the program should be loaded into, next is the total amount of bytes to load (32-bit value), and the last one is a 32-bit address that specifies where execution should jump to after loading is done, in order to start the program.


well that won't be possible, programs will only ever get loaded into "HiRAM" ie bank 2 and above.
there is no reason to have it load code into bank 0 since the boot ROM will automatically do a long jump to the header specified address after the whole program has been loaded into memory.
the startup code should never have to deal with any of the vectors at all, since they are hardwired in the boot ROM.

so i'll modify the startup code to just remove the whole reset section, and put the address of __program_start into the header, hopefully that works.
though the assembler syntax will take some getting used to. plus it's like 5 in the morning here and i haven't slept yet, so i'll do all of that after a quick nap.

thanks for helping me getting this running

That should work fine, just remove the reset vector section. You may need to move the __program_root_section label next to __program_start label. It is used to mark the first section to be included by the linker.

I came across a problem where i was unable to use the assembler, no matter what input parameters or what was in the assembly file it would just silently crash with no error given or anything.
the only reason i knew it crashed was because my batch file checks for %errorlevel% being non 0 after calling AS65816.

I wrecked my brain on this trying to understand what is happening, until i treid it with the unmodified cstartup.s, which did work. but then i changed the file extension and it stopped working.
and i can't say that i'm a big fan of the assembler forcing a specific file extension to be used (also the fact that it doesn't even give the user an error message to work with).
For a compiler it makes sense, .c is always a C source file, .h always a header. But those are standardized... Assembly on the other hand comes in many different flavors, that's why i seperate them all with the file extensions. a65 for 65c02, a816 for 65816, a86k for 68k, arv for RISC-V, etc.
both cc65 and WDC's CC don't care what the files are, if you tell them to assemble some file they'll do it without question.

so please, just have the assembler ignore file extensions for convenience. leave that up to the user to handle.

on a different note how do you import a section into an assembly file?
i got this like in the header used to calculate how large the program is:

but the assembler says that it cannot find the section named "far". the command i'm using is:

I know the Clang system (I use its preprocessor for the assembler) has some ideas of file extensions and that they change the meaning of the input. Also, as you say, assembler extensions are all over the place. I will see if I can make it less picky about the extension used for assembly language, as the assembler binary knows what to expect...

To "import" a section, you need to mention it, like ".section sectionName", that makes it known. You do not need to put anything into (below) it.

ah! so like the ".section stack" and such at the start of the cstartup file?

but now I'm getting this error:

this should just calculate the size of the file and subtract 17 from it.
the scm file has this line:

i assume segments are placed in the order of how you put them in this list, so "far" will be the last segment in the output file and "farcode" will be the first.
so to get the size of the output file i just toke the end address of the "far" segment and subtract the start of the "farcode" segment from it, but aparently that won't work?
what alternative way is there?

if it helps here is the full header:

immediately after the header is the __program_start label with the rest of the code.

also once i actually have an object file, do i have to replace the original cstartup.o in the standard library? i assume i can i just remove it from the library and include the object file in the linker manually for convenience.

Octal and decimal are "good" as well....

Yes, that just makes it know to the assembler, it does not put anything into the stack or define its size in any way.



The error you get is because the expression is too complex for the ELF format and the available relocations to describe it. The crucial thing here is that the relocation/expression refers to two different sections.

What you are trying to accomplish is better solved by having the linker generate an output file in the desired format. Does the format you use have a name, is it officially known? Then I can add it.

If not, there is PGX and PGZ formats used by Foenix that looks very similar. Would it be possible for you to use either of them? PGZ is currently supported by the linker while PGX is not. The difference is essentially that PGX has a single chunk of code while PGZ supports multiple chunks (if you have that) and PGZ works with both 65816 and 68000 while PGX is only for 65816.

In either case, I prefer that this is solved by an output format, as that is what it is about.



When you replace the C startup module you can just add it to the command line. You do not need to remove it from the library and I do not know how to do that in an easy way. The linker is able to live with multiple C startup modules in libraries and there is a mechanism to pick a specified one. This is done using the run-time attribute which is called cstartup, in the original one it has the value "normal". You can put any suitable string there to name you variant and then tell the linker to use it on the command line with --rtattr cstartup=whatever.

wait so it's a limitation of the object file format? then what is cc65 using that it works there? or is it because cc65's section symbols are just regular old symbols that get defined at the linking stage, instead of special ".sectionxyz" directives?


it is not an official header, i designed by and for myself to be the "simpliest universal executable header possible" since it's not specific to any one system or architecture.
looking at the ones you mentioned, PGX wouldn't be a good choice as it doesn't specify the size of the program, making it impossible to load from Serial as the CPU wouldn't know when to stop reading/waiting for more data.
PGZ seems good though, i'd like it more if the signature was larger so it can be used for CPU/System Identification. but whatever, it'll do.


any specific reason for that? wouldn't that just mean more work for you instead of just having the users do it themselves in assembly (when possible of course)?


oh i see, so the librarian utility is just a bit bare bones at the moment, i assume someday in the future it will get some more features like adding/removing/extracting individual object files, listing all the symbols in the library, etc.
anyways doing that worked fine and i was actually able to generate an output file for once! milestone reached!

but the victory was short lived because the generated .pgz file is only 7 bytes large despite the linker's generated .lst file saying that the executable section is 494 bytes in size... so where is all of that code? (btw why is the startup code 490 bytes? that seems a little much)
the .pgz file consists of the "Z" signature byte (5A), a 24-bit address that points to some random location in the "cstack" section (E9 41 02 -> 0x0241E9), and lastly a 24-bit word that is just all 0's.
the c program i'm compiling is just just a main function with a "return 0" at the end.
here the command i used for the linker:


and the generated lst file:


interestingly, when i change "--output-format pgz" to "--output-format raw" to see if it's just a problem with the format, the linker straight up crashes with this error:


so am i doing something wrong here and the linker won't tell me, or is it just having a bad day?

Unresolved expressions are turned into relocations. What relocations are available depends on the target. In general, relocations are really simple and meant to resolve a single location with an offset. The result can be stored into the code stream in different ways, typically needed by the target at hand are provided.

The section start, end and size are just a name mangled symbol in Calypsi that is deciphered by the linker. This is of course non-standard, but it was the only way I could see that could do it. I limit my extension to a single section, no arbitrary expressions are allowed in ELF, which is why it failed. It could potentially be done in a different (non-standard) way, but that is how I implemented it.


PGZ is defined for 65816 and 68000, well, any byte oriented target that usues either 24 and 32 bit address ranges.



Well, you can see from all the hoops you are trying to do that it takes time. It is that "when possible" and trying to figure out how to do it. The header and metadata also exists in memory when done this way, when it really just is supposed to be in the file.

The PGZ format is about 20 lines of code for me, it is a simple format. Adding another (simple) format is not all that expensive, but there is of course long term maintenance of it. I think the best is to use an existing format, if there are limitations with them, then I think the second best is to add a new format to take care of that use-case. It may also be possible to write a simple converter tool.



The file format used is one of the two that is common on Unix, you should be able to use other (existing) tools to manipulate the library archives.


The internal error is caused by a bug. The Raw format only supports one "progbits" memory and there is a guard that checks if there are multiple. In this case it is none and that error guard did not trigger, but the code later did as it expected one. I need to add another error guard for this case.

The list file looks a bit fishy in that it seems like it has managed to mix zfar and farcode in the same memory, which is not allowed. zfar is bss (no bits) and farcode has bits.

What version are you using of Calypsi 65816? Is your project available on some hosting service so that I can take a look at it?

I would like to see the .scm file.

Rather than discussing here, maybe you could file an issue at https://github.com/hth313/Calypsi-tool-chains

I'll open an issue on that Internal bug in a minute, but i just want to quickly jump on this bit here.
i thought we already solved that a page ago or something with the "--hosted" commandline parameter?

EDIT: well just removing all the sections seems to work for that just fine.

Hi,

I'd like to try this compiler on a home brewed 65C02 from the late 1980s. The memory mapping is straight forward:
RAM - $0000-$7FFF (User program space: $0300-$7FFF)
I/O - $8000-$BFFF
EEPROM - $C000-$DFFF
EPROM (BIOS/Monitor) - $E000-$FFFF

I don't see a generic section in the manual for homebrew/custom boards and trying to figure out exactly what I need to do to get this to work. I would like to run programs in ram(ie. starting at $0300). To download the program to the board, I'd compile for raw output.

My guess for the .scm file would be something like:

I really have no idea what my startup.s should look like. The simplest one I found was at:
https://github.com/hth313/Calypsi-6502-Commodore/commit/1f7a1b62008a6321bce1a75131d37864f074d24c
for the C64. I've commented out what I think I don't need? Maybe I need to add some other code?

startup.s

I don't know how to handle the exit. If I decide to exit my C program, I'd want to jump to the monitor prompt, which is at $E003. Would I use the stub? ie:

...then put in some .s file (or part of startup.s?):

The next item is interrupts. When my board boots, IRQ location $FFFE in EPROM points to $00FD and puts an RTI instruction there. So, when writing in assembler, I'd put a JMP at $00FD, and the IRQ method address in $00FE/$00FF. So, if writing a C program with interrupts, would I initialize with a JMP at $00FD(in startup.s?), then in my C program:

...and lastly I'd need to figure out the command line options for the compiler and linker. Whew!

Any help appreciated, thanks!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

the tool chain github is where the dev is mostly spending their time to answer questions and resolve issues, so i'd recommend you ask over there: https://github.com/hth313/Calypsi-tool-chains

but i can answer some stuff.

when you download the utility it should come with an "example" folder that has a minimal linker setup, and in the "src\lib\lowlevel" folder there is the default cstartup.s that you can either modify directly or copy and then modify for whatever system you have.
though i agree that it should be made much easier to set up a custom environment. so a template example with better commented startup code would be very useful. (you can also ask for that on the github)


in C, exiting from the main function is handled like with any other function, meaning it just returns control to whatever code called it. in the startup code you can see the "JSR main" that calls the main function, and once it finishes/returns it continues with the instructions following it. in the case of your startup code it will execute a "JMP" to the label named "exit"
so it you want it to jump to your monitor you could just define "exit" to equal $E003, or replace the "JMP exit" with "JMP $E003".


I wouldn't recommend jumping execution to Zeropage. use an indirect jump instead, which gets it's target address (the address that it jumps to) from memory where the operand address (the one you write in the assembler) points to.
so for example "JMP ($00FE)" reads 2 bytes from address $00FE and $00FF and let's say that the value at the first address was $99 and at the second address $44, meaning that execution will jump to address $4499 and continue there.
this leaves your Zeropage nice and tidy without having to store any code there.

as for Interrupt code in C... it's somewhat complicated. your startup code has to get the address of the function (assembly or C) you want to call and write it to where your IRQ ROM code jumps to. the problem with doing it in C is that any temporary varibles the C environment uses (which are pretty much just in the Zeropage) have to be copied to somewhere else before you can actually call your C interrupt function, which adds a lot of latency to the IRQ function.
maybe also ask the dev about a simple example for interrupt handling since i've honestly never bothered with it myself and all my Interrupt code has been in pure assembly to avoid having to save any C memory values.

on a final note, i recommend including this header file i call "MemAccess.h" that i made that adds some macros for accessing memory and setting/clearing/checking individual bits of varibles/memory locations. which makes accessing memory a lot more readable IMO.


I also recommend learning the "stdint" sytax for variables. so "uint16_t" instead of "unsigned int", "int8_t" instead of "char", etc. on a CPU like a 65C02 keeping track of your vairable's widths can save you a fair amount of execution time and memory.

Either way, I hope this was atleast somewhat helpful.

Proxy, thank you very much for your reply! I didn't know there were minimal examples in the install. I'll d/l and install the utility and see how far I get. Sorry, I didn't explain the IRQ setting well. I meant to say how I'd initialize the IRQ vector. It would be called from an ASM program as you said, JMP ($00FE). Thank you for the MemAccess idea and example. Yes, it makes code much more readable. Also, thanks for the "int8_t", etc. idea as well. I use this syntax in microcontroller code and makes sense to continue with it here to keep things clear.

Thanks again for all the information!

Following up to my previous post, I have a home brewed 65C02 from the late 1980s. Memory mapping:
RAM - $0000-$7FFF (User program space: $0300-$7FFF)
I/O - $8000-$BFFF
EEPROM - $C000-$DFFF
EPROM (BIOS/Monitor) - $E000-$FFFF

The purpose is to run small experimental programs in RAM. Another objective is to have the code execute at the first loaded address, ie. if I load(raw format) between $1000-10FF, I want to do a run at $1000. If not configured right, the start of execution could be anywhere between the start/end addresses. I don't know if I did this the best way, but I have it working the way I want(so far, blinking a LED from a VIA(6522)) doing the following:

linker.scm

cstartup.s

Next is interrupts. I don't know, but it seems setting up the IRQ will not work the way I want it to using the attribute commands or modifying the interrupt.h(which appears to have been made for the C64?) In summary, I want my IRQ routine to be in RAM, in the same program space. How this board works is the BIOS IRQ points to page 0(EPROM - $FFFE=$FD, $FFFF=$00). In page 0, you would then do a JMP to your IRQ in program space.
ie:
Program lives at $1000-$10FF and lets say the IRQ routine compiles to be at $1034
When an IRQ comes in:
- $FFFE/$FFFF --> jumps to $00FD
- then the 3 p.0 locations would have to be: $00FD=$4C(JMP), $00FE=$34, $00FF=$10 --> JMP $1034
The way I got this to work is:

main.h

main.c

I noticed the "__asm" command doesn't do anything. There's no compile/link error, but it also doesn't produce any code when looking at the .lst file. I've put a "RTI" in my MBII_EndINT(); but that doesn't satisfy the final JSR and my guess is it will eventually crash(?)