Equivalent of the NEW basic command ?

[Hialmar]

I was tired yesterday evening.

Those values are normal in fact. The upper limit on strings is always the HIMEM.
So I don't know what to do really.

Maybe the only solution will be to convert everything to C but it will take me ages

[Chema]

I am not sure about the details of your problem (sorry I am currently very busy and could not read this thread in detail). However the string upper limit can be changed by using the HIMEM basic command.

IIRC strings go down in memory and arrays grow up. Everyting is alright until both pointers collide Bottom of strings pointer is stored in $a2 $a3 and top of arrays in $a0 $a1 (or was it its size?)

A couple of things though. First make sure you are not facing an error of the C compiler (I got some unexpected results with local variables when using printf related functions and in some other cases). Normally that would give an error in the C code, not in BASIC, but who knows...

The OOM message is usually produced when you ask for array (or string) space allocation and there is not any left. The ROM attempts Garbage Collection and, if still no room, you get the error. This is in routine $c444 in the ATMOS rom (http://www.defence-force.org/ftp/oric/d ... sembly.pdf). You may want to have a look and put some breakpoints there to check what is going on.

Check also that your BASIC variables have not been altered and you are not requesting an array or creating an string with an invalid (too large) size.

Just some ideas...

Oh, and if you have enough memory, translating your BASIC code to C should not be really difficult.. and it will be much faster

Once you have done this, you will start mixing C and ASM and finaly convert everything to ASM to get even more speed in less space. That is how things went for me

[Hialmar]

Thanks Chema.

The problem is that the OOM error only happens after 14 or 15 switches between the C and Basic code. So it's an interaction problem.

The Basic code of one of the 3 programs I still have in Basic takes most of the RAM so in order to switch to C I'll have to split this program in several parts and switch from one to another part.

Before doing this I'll try what Geoff Phillips says and try to backup page 1 and 2 as well as page 0.
Now where will I put all this...

Anyway, I'll get you posted.

[Chema]

Oh, sorry then. I thought it was a kind of bug and that there should be enough room for everything. If you have run out of space, then that is a completely different story...

There are some holes in the Oric ram which can be used to store temporary data, but nothing near 512 bytes! I guess you are using HIRES mode (else you'd have much more room) maybe even using the bottom 3 lines of text, so from $500 to $9800 (from $9800 upwards to $9fff you have the character sets)?

If you are not using a disk, you can "steal" page 4 (though that is just 256 bytes). If you are not using the alternate charset, you have some room there too (+800 bytes!). Even you can the space for those characters which are unused.

And you have 32 bytes left from $bfe0 to $bfff.

If you are using a disk system you can make use of the Overlay ram... Even if you need the OS, there are surely parts you can overwrite.

[Godzil]

Thanks Chema.

The problem is that the OOM error only happens after 14 or 15 switches between the C and Basic code. So it's an interaction problem.

The Basic code of one of the 3 programs I still have in Basic takes most of the RAM so in order to switch to C I'll have to split this program in several parts and switch from one to another part.

Before doing this I'll try what Geoff Phillips says and try to backup page 1 and 2 as well as page 0.
Now where will I put all this...

Anyway, I'll get you posted.

Backupup page 2 is, I think a bad idea as it is the 6502 stack, and when restoring, if the S register is not set back correctly it will fail abominably..
I was wondering, how complex is your C code? The main problem with C is that the 6502 is not really adapted for C programming, because it only have a short number of registers, and the hardware stack is so small that the possible stackframe is just ridiculous (that's why most of the C compiler use a soft stack)

You should avoid passing parameters to your function and use as much as possible global variable, you should also try to get the smallest possible call depth in your code. (yes I know this is not compliant with modern coding standard )
I suppose that we should add a "non soft stack" version of the C compiler in the OSDK (by using a switch) it would not allow to compile everything, and will fail for a lot of C project, but in your case, if the call depth, and argument are kept as low as possible, it may help you to not have to save page 0 and 1, or at least save only page 0.

Current executable build by the C compiler of the OSDK are not the best way to interract with the BASIC environment.


One other solution would be to use your own basic interpreter, that would solve a lots of problem, a bit more complex for sure, but you will have more control

[Dbug]

Backupup page 2 is, I think a bad idea as it is the 6502 stack, and when restoring, if the S register is not set back correctly it will fail abominably..l

Page 2 is system data. The 6502 stack is on page one.

[Godzil]

Backupup page 2 is, I think a bad idea as it is the 6502 stack, and when restoring, if the S register is not set back correctly it will fail abominably..l

Page 2 is system data. The 6502 stack is on page one.

Yep sorry you're right, I mixed things up (shame on me , I have a working 6502 emulator, i should not make such a mistake... )

[Hialmar]

Thank you everyone for your feedback.

I'm using Sedoric so page 4 is out of limits for me. I'll try using the whole alternate character set (which I don't use anyway).

To be clear the problem is not only on the C side (which works without OOM errors) nor on the Basic side (which also works without OOM errors). It is I think an interaction problem between both sides.
I have a C program that calls Sedoric to load the Basic program and vice-versa. C and Basic are not mixed in RAM. It's either one or the other and they mainly exchange data through the disk and sometimes data hidden in HIRES space (swaps being done only in TEXT mode).

Writing another Basic Interpreter could be a solution but I suppose that it will take more time than converting everything to C

About page 1 and the stack, I'm clearly not thrilled to touch this. So maybe I should first try with only page 2.
I'll give that a try.

[Dbug]

If I was in your position I would use a loader that stays resident in memory during all the lifetime of the application and containing the code to call sedoric and do the zero page copies, and have it run either the BASIC or the C code, but definitely not have the C loads the BASIC or the BASIC loads the C, it's a recipe to recursion gone wild.

[Hialmar]

That sounds good but I don't understand how to do this on the Basic side.

Currently I use some ASM code that writes the name of the program to call and then let's Sedoric interpreter run this.
It should be the same as when you actually type the name of a program at the prompt.

[Dbug]

I guess the question is to know if you call the BASIC interpreter, can you come back from the caller if you run the END instruction?
It's also probably possible to use ! (look page 253 of the French Atmos manual) to automatically push the parameters, or a combination of POKE/CALL.

[Hialmar]

No you never come back to the calling program. Basically loading a new program overwrites everything (or almost everything as there is the problem with the page 0 and maybe something else.

Loading a Basic program from another Basic program does that at least.

The only different thing is when you load a memory zone from the drive. It's only written somewhere and the program (Basic or C) continues. You can use this to load ASM but I don't really think you can do this to load Basic.

[Dbug]

I assume the resident program is written in C or assembler, not BASIC.
There must be a way to short-circuit the BASIC, like for example by using the good old protection that overrides the "Ready" display by changing the value in 1A/1B/1C.
Possibly the same thing can be done by short-circuiting the code that prints error messages.

As soon as the C/Assembler code gets the hand again, it can just load some other BASIC program and run it.

Would that not work?

[Hialmar]

Ah it could work if I move the Basic code at an address farther than #501 and keep the ASM loader in page 5.

Geoff Phillips shows this in his book and Fabrice did it with his USB/TTL connection to the Oric.

I'll look into this.

Thanks a lot.

[Hialmar]

Ok I have finally found out that my problem was that I was filling the stack because I call an ASM routine from C and can't do a rts because I then directly jsr to the Sedoric interpreter.

So well, I now overwrite the stack pointer to $1fe just before doing that.
Okay it's not very good but it seems to work so far.

Here is my code for switching from one program to another (using Sedoric):

Code: Select all

_SwitchToCommand
.(
	ldy #$0         ; grab string pointer
	lda (sp),y
	sta tmp
	iny
	lda (sp),y
	sta tmp+1
	dey

sedoricloop2            ; copy the string to #35..#84
	lda (tmp),y
	sta $35,y
	iny
	ora #$0
	bne sedoricloop2
	lda #$0				; terminate with a 0
	sta $35,y
	
	ldx #$fe			; re-init stack
	txs
	
	ldx #$34
	ldy #$00
	
	jsr $c4bd ; call the interpreter
	rts  ; will never be called
.)

Please tell me if you think it's really a bad idea.

Also shouldn't I jmp instead of jsr for calling the interpreter ?