vbcc for 6502 and 6809

[Dbug]

Originally Posted by vbc

I added some changes to the vbcc backend to improve use of the x register and the comparison. (...) Down to 12 bytes.

Very nice!

What does VBCC require to work properly (zero page locations, stack, etc...) and how is that configured so it does not conflict with the system?

Is it possible to call VBCC compiled code from an IRQ handler?

[Thomas Richter]

Originally Posted by vbc

Down to 12 bytes.

Impressive. The 6502 is a very unfriendly target for a C compiler.

[phx]

Originally Posted by Dbug

Does VASM supports hexadecimal values expressed in 0x notation in addition to the usual $ for hex, and % for binary?

Depends on the syntax-module in use. oldstyle: yes.

Is it like devpac, with labels starting by . being local, anything else being global?

Yes. Depends on the syntax-module again, but for "mot" and "oldstyle" local symbols may be preceded by '.' or terminated by a '$'.

See the final section of https://wiki.defence-force.org/doku....#file_encoding

Thanks. Already implemented in vasm. Here is the output of your small example program, which starts at $0000 as no ORG or *= was provided:

frank@nerthus cat mytest.s
        lda     #23
        rts
frank@nerthus ../../vasm6502_oldstyle -quiet -Fbin -oric-mc -o mytest mytest.s
frank@nerthus hexdump -C mytest
00000000  16 16 16 16 00 00 80 c7  00 02 00 00 00 6d 79 74  |.............myt|
00000010  65 73 74 00 a9 17 60                              |est...`|

Is this a valid Oric machine code file? Reserved bytes are zero?

Does it output to some listing file?

Yes. -L option.

Generally we do this type of thing when we want to generate code that will be recopied, like typically force the * to something in zero page to make sure the code is generated with the proper 8 bit addresses, but with a valid label before and after that is not in zero page, so we can copy the block of data.

Ah, yes. I understand. That's also allowed in vasm, when you do it in a section. This code would be placed within the section, but relocated by the assembler for the given address.

At least this is how it works in mot-syntax. In oldstyle we have the "rorg <addr>" and "rend" directives, which define such a relocated-org block. The advantage is that it works not only in a section but also within absolute code, started by ORG or *=.

Can't I define the address of data, bss, etc... inside the assembler itself?

See above. In mot-syntax you can (I might add that for oldstyle). Otherwise you would just write multiple ORG-directives, or:

        *=$500
(..code..)
        *=$2000
(..data..)

When I code on the Atari ST, I largely prefer to .include my .s files than have to deal with a linker.

I'm 150% certain that the popularity of devpac back in the days, was that it could support object files, but that by default it could just output a .PRG file directly for a .S file.

Correct. vasm does the same. It's perfectly legal to include everything into one giant source, but I thought you wanted to be able to link with C objects or even linker libraries?

The Oric header is trivial, so yeah should not take long

Indeed. The o65 format is more complex, of course.

BTW, I think we are getting so deep into details that it makes our discussion no longer interesting for a forum. You are always welcome to contact us by email (look into the documentation of vasm and vbcc) for further questions or feedback.

[kamelito]

Nice to see this moving forward for the Oric, thanks you all for your work!

[Dbug]

Originally Posted by phx

00000000 16 16 16 16 00 00 80 c7 00 02 00 00 00 6d 79 74 |.............myt|
00000010 65 73 74 00 a9 17 60 |est...`|
[/code]Is this a valid Oric machine code file? Reserved bytes are zero?

Almost.

16 16 16 16 should be 16 16 16 24.
You can actually have many more 16 (it's the synchronisation sequence) but it needs to end by a 24.

The 80 C7 is correct, but it's nice to be able to specify that you don't want the file to auto start (when debugging, etc...) in which case 80 00 is what you want.

The 00 02 / 00 00 is correct if you want to load at address zero, but page 2 is used by the system, page 3 is where I/O are, page 4 is used by the DOS, so we consider that the safest "default" address to load anything would be $500 so in this case that would be 05 00

In summary, instead of
16 16 16 16 00 00 80 c7 00 02 00 00 00 6d 79 74 65 73 74 00 a9 17 60

what you should have is:
16 16 16 24 00 00 80 c7 05 02 05 00 00 6d 79 74 65 73 74 00 a9 17 60

Originally Posted by phx

BTW, I think we are getting so deep into details that it makes our discussion no longer interesting for a forum. You are always welcome to contact us by email (look into the documentation of vasm and vbcc) for further questions or feedback.

Yeah, I'll have to discuss with the Oric guys about how to proceed, and check with the maintainer of LCC65 if that's ok. Because he basically spent a lot of time fixing some stuff recently, that feels kind of crappy to drop the whole thing like that :-/

[vbc]

Originally Posted by Dbug

What does VBCC require to work properly (zero page locations, stack, etc...) and how is that configured so it does not conflict with the system?

In zero page, vbcc uses 2 bytes as a user stack pointer (sp) and up to 32 bytes as pseudo registers (r0..r31). If data types >=32 bits (long/float) are used, up to 16 additional bytes may be needed (btmp0..btmp3).

If the SANE IEEE libraries are used, they need additional space in zero page. The wozfp library does not need additional zero page space.

The 6502 stack is used for return addresses and register saves. A software stack is used if local variables are needed that are not assigned to pseudo registers. Also, depending on the compile options, register saves can be done to the software stack. The stack sizes mainly depend on the code that is compiled.

The zero page registers are addressed via name and they have to be provided by the runtime system. On a normal port they come with the startup code or the library and are placed by the linker script. The stack pointers have to be set up to point to suitable space before calling vbcc code.

Is it possible to call VBCC compiled code from an IRQ handler?

Yes, vbcc6502 offers the __interrupt attribute. This will instruct the compiler to restore all registers and return with rti.

[Dbug]

Originally Posted by vbc

In zero page, vbcc uses 2 bytes as a user stack pointer (sp) and up to 32 bytes as pseudo registers (r0..r31).(...)

Ok, so slightly less than the current OSDK compiler, but basically works the same

Yes, vbcc6502 offers the __interrupt attribute. This will instruct the compiler to restore all registers and return with rti.

By registers, do you mean AXY, or does that also includes the pseudo registers in zeropage?

Is there a way to just have the pseudo register saving without the RTI?

Basically I'm talking of implementing callbacks in C, but that integrate in some existing IRQ handler managed by the Oric system (which already did all the saving of XYA, status flags and RTI), but that should make sure to not trash the pseudo registers in zero page.

[vbc]

Originally Posted by Dbug

By registers, do you mean AXY, or does that also includes the pseudo registers in zeropage?

It will save AXY and all the pseudo registers used in the function. If it contains a non-inlined function call, all caller-save pseudo registers will be saved.

If the software stack is needed, it will also switch to a separate interrupt stack. This is necessary, because changes to the software stack are not atomic (16bit pointer).

Is there a way to just have the pseudo register saving without the RTI?

Not in the current version, but adding this as an option can be easily added.

Basically I'm talking of implementing callbacks in C, but that integrate in some existing IRQ handler managed by the Oric system (which already did all the saving of XYA, status flags and RTI), but that should make sure to not trash the pseudo registers in zero page.

I see. Makes sense.

[phx]

Originally Posted by Dbug

You can actually have many more 16 (it's the synchronisation sequence) but it needs to end by a 24.

Yes, I missed that. Thanks.

The 80 C7 is correct, but it's nice to be able to specify that you don't want the file to auto start (when debugging, etc...) in which case 80 00 is what you want.

Ok. So I added an additional option.

-Fbin -oric-mcx

now writes an Oric header with auto-exec flag (80 c7), while

-Fbin -oric-mc

writes one without (80 00).

The 00 02 / 00 00 is correct if you want to load at address zero, but page 2 is used by the system, page 3 is where I/O are, page 4 is used by the DOS, so we consider that the safest "default" address to load anything would be $500 so in this case that would be 05 00

Right, but when you have a source without setting a start address, or just with a .text section, you would expect the output to be assembled for $0000, won't you?

If you really need that, I could make it default to $500 only when an Oric header is generated and the start address is zero.

Yeah, I'll have to discuss with the Oric guys about how to proceed, and check with the maintainer of LCC65 if that's ok. Because he basically spent a lot of time fixing some stuff recently, that feels kind of crappy to drop the whole thing like that :-/

Absolutely.

I would try to keep both compiler options working in parallel as long as possible, until you and other OSDK users are sure about it. It's a long way to go and probably quite some work for you. What I can definitely promise is that I'm working on implementing the o65 object file format, for XA-compatibility, and we can also build a standard clib for Oric, as soon as we find out how character input/output works with its OS.

[Dbug]

Originally Posted by phx

Right, but when you have a source without setting a start address, or just with a .text section, you would expect the output to be assembled for $0000, won't you?

If you really need that, I could make it default to $500 only when an Oric header is generated and the start address is zero.

I'd say that in the absolute, you are right, but in practice there's pretty much 0% chance you can load an Oric program using this format (tape header) at address zero, since that will overwrite system variables required by the program to run at all.

In the spirit of "just call the assembler and get something that runs", it makes sense to have $500 used if no value is specified, because that would work on Oric 1, Atmos, Telestrat and Pravetz, with or without a floppy drive attached.

Originally Posted by phx

I would try to keep both compiler options working in parallel as long as possible, until you and other OSDK users are sure about it. It's a long way to go and probably quite some work for you. What I can definitely promise is that I'm working on implementing the o65 object file format, for XA-compatibility, and we can also build a standard clib for Oric, as soon as we find out how character input/output works with its OS.

You can read the keyboard with the handle in $23B and output characters with the one in $238 (at least on ROM 1.1 and later, but that's another painful topic ).

Here is the implementation of the "getchar" from the OSDK:

_getchar
	jsr $023B
	bpl _getchar	; loop until char available
	tax
	jsr $0238	; echo char
	lda #0
	rts