Adding Oric support to the Oscar64 C compiler...

[Dbug]

The simplest is to copy bits of the OSDK, this way you get the proper zero page variables and you get some basic code to read from keyboard and print to screen: It's not optimal, but it should be enough to get something that is known working just fine.

[ibisum]

Yes, that is probably pretty simple .. I’ll have a gander at it once I get myself set up with proper debugging in Oricutron and gdb on Oscar64 simultaneously…

[Dbug]

Basically you can just check the content of the lib folder, in it there is a library.ndx file which is just a list of all symbols and which file contains them.

So for example:

Code: Select all

(...)
-gpchar.s
	_getchar
	_putchar
	putchar
	putchar2
	_puts
	_gets
	gets
(...)

this mean that the code to read from keyboard and print to screen is in gpchar.s located in the same folder, which if you open contains that:

Code: Select all

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

and this:

Code: Select all

;
; putchar(c)
;
_putchar
	ldy #0
	lda (sp),y
putchar
    cmp #$0A
    bne putchar2
    pha
    ldx #$0D
    jsr $0238
    pla
putchar2
    tax
   jmp $0238

and still in the same folder you have header.s that contains the zero page variables:

Code: Select all

	.zero

	*= $50

;
; Most of the documentation/comments in this file are from 'Another Approach to Instruction Set Architecture—VAX'
;
zp_compiler_save_start
ap		.dsb 2		; Argument pointer - points to the base of the list of arguments or parameters in memory that are passed to the procedure
fp		.dsb 2		; Frame pointer - points to the base of the local variables of the procedure that are kept in memory (the stack frame)
sp		.dsb 2		; Stack pointer - points to the top of the stack

tmp0	.dsb 2
tmp1	.dsb 2
tmp2	.dsb 2
tmp3	.dsb 2
tmp4	.dsb 2
tmp5	.dsb 2
tmp6	.dsb 2
tmp7	.dsb 2

op1		.dsb 2
op2		.dsb 2

tmp		.dsb 2

reg0	.dsb 2
reg1	.dsb 2
reg2	.dsb 2
reg3	.dsb 2
reg4	.dsb 2
reg5	.dsb 2
reg6	.dsb 2
reg7	.dsb 2
zp_compiler_save_end

[Chema]

and still in the same folder you have header.s that contains the zero page variables:

Code: Select all

	.zero

	*= $50

;
; Most of the documentation/comments in this file are from 'Another Approach to Instruction Set Architecture—VAX'
;
zp_compiler_save_start
ap		.dsb 2		; Argument pointer - points to the base of the list of arguments or parameters in memory that are passed to the procedure
fp		.dsb 2		; Frame pointer - points to the base of the local variables of the procedure that are kept in memory (the stack frame)
sp		.dsb 2		; Stack pointer - points to the top of the stack

tmp0	.dsb 2
tmp1	.dsb 2
...
zp_compiler_save_end

That was exactly what I came to say. You can safely use from $50 upwards in zero page without issues. I am not sure why you need reading keys and printing for creating a very simple test: you can simply load, write something to screen with a direct pointer, and exit. Then start adding things. But I may be completely wrong here.

In the library, look for enter and leave, which are functions called each time a C function is entered and exited. IIRC there you can see how the stack frame is managed.

[ibisum]

The existing Oscar64 implementation simply calls into ROM routines for reading chars and printing texts. Adding more code to the project doesn’t make sense at this point, when really just using the existing ROM routines would work just as well. At a later point, if it is really deemed necessary to do so, we can pull in this code - but its not productive to do so at the moment, because actually the last stumbling block really is just the way that registers are set up and the expectations for how to handle Page Zero addresses is implied.

If you guys want to help, take a look here:

https://github.com/seclorum/oscar64.ori ... er.cpp#L58

That is where the setup for everything begins and it is where I’ve probably gone off the rails with assumptions that are not yet verified.

The console i/o stuff is here, but like I said, this isn’t the real problem at the moment:

https://github.com/seclorum/oscar64.ori ... conio.c#L5

.. the real issue is the assumptions about Page Zero and where Oscar64 can set up its internal registers in Page Zero…

EDIT: Here is the code to generate .TAP files, also, for those digging into this:

https://github.com/seclorum/oscar64.ori ... .cpp#L1461

In my last session some months ago I got all of this implemented and got as far as having a working build that would take the ATMOS path and actually produce .TAP files, but I haven’t returned to debug things fully yet, so if someone wants the glory of getting the last 5% of the work done, the low hanging fruit is right there for you ..

[Dbug]

I feel we are crossing each other.

.. the real issue is the assumptions about Page Zero and where Oscar64 can set up its internal registers in Page Zero…

We told you it was free from $50 and you wrote that:

Code: Select all

	if (mTargetMachine == TMACH_ATMOS)
	{
		BC_REG_WORK_Y = 0xc0;       // Y-index temp
		BC_REG_WORK = 0xc1;         // General scratch
		BC_REG_FPARAMS = 0xc2;      // Function params start
		BC_REG_FPARAMS_END = 0xce;  // Params end
		BC_REG_IP = 0xcf;           // Instruction pointer (no overlap)
		BC_REG_ACCU = 0xd0;         // Accumulator
		BC_REG_ADDR = 0xd2;         // Address register (2 bytes: 0xd2-0xd3)
		BC_REG_STACK = 0xd4;        // Stack pointer (2 bytes: 0xd4-0xd5)
		BC_REG_LOCALS = 0xd6;       // Local variables
		BC_REG_TMP = 0xd8;          // Temp storage
		BC_REG_TMP_SAVED = 0xda;    // Saved temp for interrupts
	}

We did not mean that all the area from $50 to $ff was free, just that it was safe to have your compiler variables starting in $50.

Now what is actually usable seem to be documented in the Oric Atmos manual page 271.

image_2026-01-02_094608985.png

From this table we can see that it looks like there's a hole from $31 to $9a, but if we look in the Oric Advanced User Guide page 260-262 we get a very different picture:

image_2026-01-02_095024591.png

Basically the OSDK uses $50 because that was what the original SDK made by Fabrice, Alexios and Vaggelis originally did, and they choose this area because the $35 to $67 area is only used by ROM 1.0, so it's safe to use on the Atmos.

Writing from $c0 to $da basically overwrite data related to BASIC garbage collection and floating point calculations, so not sure what the consequences of doing that would be for a C program not using these.

My main problem is that you wrote that:

In my last session some months ago I got all of this implemented and got as far as having a working build that would take the ATMOS path and actually produce .TAP files, but I haven’t returned to debug things fully yet

without actually saying what the problem was. You've mentioned a number of time in the previous messages that "things needed debugging" but that does not tell anything about what needs debugging

So what is that actual "5% low hanging fruit" that needs to be looked at?

[ibisum]

Dbug, I wrote that code months before you told me about $50. Like I said, this part was based on wrong assumptions on my part and, when I could get back to it, I would take a closer look at the situation - which you’ve now succinctly described, and know all about.

I don’t have a development environment at the moment.

I’ll get back to this at some point. Or, you can take a look at it - that’s what open source is all about.

Seems like you’ve got a better idea about the issue now. Why don’t you read the diffs in my oric-support branch and Oscar64’s main branch, catch up with the work done so far to add ATMOS support, and see if you can get it working. I think its pretty close, just needs a bit of attention, and with your extensive knowledge, probably could work within an hour or so…