Using Overlays with OSDK

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

User avatar
coco.oric
Squad Leader
Posts: 720
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Using Overlays with OSDK

Post by coco.oric »

Hi,

For an idea (quite big) i have, i need probably to use overlays and using different parts of the program at the same place.
It seems that CC65 has it : http://www.paytonbyrd.com/BlogEngine.We ... rlays.aspx

Is it possible to have overlays with OSDK ?
Thanks, Didier
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Using Overlays with OSDK

Post by Godzil »

As the overlay is just plain memory (ie you can only choose between ROM and DRAM on a vanilla Oric) there is nothing much to do, just tell the linker that 0xC000 to 0x10000 is available.

Or do you plan to use external SRAM pages?
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Using Overlays with OSDK

Post by Chema »

I think Dbug solved this with his FloppyBuilder tool, but I've never used it, so let's see if he can shed some light on this.

But I did something similar in 1337 with the missions. The mission code size was fixed, but there is no need to keep that restriction. The main idea is putting a jump table at the beginning of your code with the interface to the overlay. Imagine you load your overlay code in high memory from 0xc000. You can start your code with:

Code: Select all

*=$c000
InterfaceFn1 jmp InterfaceFn1_imp
InterfaceFn2 jmp InterfaceFn2_imp
InterfaceFn3 jmp InterfaceFn3_imp
...


InterfaceFn1_Imp
.(
     ;your code here
.)
In your main code you simply do something like

Code: Select all

#define InterfaceFn1 0xc00
#define InterfaceFn2 0xc00+3
...

jsr InterfaceFn1; will jsr to the current implementation in overlay
Obviously you have to complile every overlay separatedly from the main code and put each overlay in a different starting sector in your disk, so you can select which part to load. That is the difficult part, but I have somewhat automated that, so I can give you a hand if you wish...

But, again, FloppyBuilder does all this automatically, I think.
User avatar
coco.oric
Squad Leader
Posts: 720
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Re: Using Overlays with OSDK

Post by coco.oric »

Humm, i think there's confusion between overlay ram and overlaying pieces of code.

'CC65, the cross-compiler system for 6502/65816 computers, is very powerful. One of the most powerful features is the ld65 linker which allows you to create executables that are extremely flexible. One use case allowed by the linker is the ability to create overlays, or code fragments that reside at the same memory location and are loaded into RAM dynamically as needed. This is an extremely useful feature for writing large applications that will not fit into the typically tight memory configurations of 6502-based computers.'

CC65 allow coders in switching pieces of code at the same memory location.
I'm not sure that using overlay and technics from floppybuilder are so powerful.

Didier
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Using Overlays with OSDK

Post by Chema »

Yes, I think I understood. What I am trying to explain is a method for implementing this by hand, switching pieces of code in and out of the memory, in this case provided that they keep a consistent interface and (just as an example) they were loaded in overlay ram.

But I think you need something more powerful, such as those pieces of code having completely different routines, so you need in compile time the addresses of those routines... Mmmm..

Not sure what would happen if you start each section that is to go in an overlay with an *=addr statement, and keep them in the same project (so the linker knows the labels), but certainly you'll still need to compile each piece separatedly again and organize it all in the disk. That last part is where FloppyBuilder could help.
User avatar
iss
Wing Commander
Posts: 1637
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Using Overlays with OSDK

Post by iss »

There is another problem with CC65 - it doesn't support any Oric OS (fopen/fread/fclose are unimplemented),
so loading overlays from disk must be written from zero. I like CC65 but in this case I doubt it's worth to be used.
Chema's idea is nice, clear and already tested :).
Else, program overlays can use any memory, using high RAM as overlay buffer is just 'private case'.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Using Overlays with OSDK

Post by Dbug »

I'm currently stuck in the middle of nowhere with a broken car, but I will think about it while waiting for the mechanics to fix the engine.

Basically something like Sedoric bank switching modules would work for you?
User avatar
coco.oric
Squad Leader
Posts: 720
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Re: Using Overlays with OSDK

Post by coco.oric »

Hello, thanks for your remarks.
Yep, CC65 isn't totally adapted for oric and it's an hard point for this implementation.

Here is the memory structure that the software could have :
+---------------------------------+
: Pages 0....4 : Oric
+---------------------------------+
: Main C program with his
: global variables and subroutines
: Loading the OVERLAYS / SEGMENTS
: that it's needed
+---------------------------------++---------------------------------++---------------------------------+
: Segment C or 6502(1) ......... :: Segment C or 6502 (2) ......... :: Segment C ou 6502 (3)
: loaded by main prog. ......... !: loaded by main prog. ........ !: loaded by main prog.
: and using global var & ....... !: and using global var & .......!: and using global var &
: main subroutines ........ !: main subroutines ........ !: main subroutines
: and its internal var. ......... !: and its internal var. ........ !: and its internal var.
+---------------------------------++---------------------------------++---------------------------------+
: Various areas of memory
: used or non for datas (ie graphs)
: loaded on the dsk
+---------------------------------+
: hires, charset ...
+---------------------------------+
: rom / overlay disk :
+---------------------------------+
I agree : Floppybuilder, Chema's disk routines will be used to finish the project.
I'll try your ideas Chema, to see if i'm able to make these segment switches between several segments with OSDK.
And i'll continue to implement, there's a lot of things to do.
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Using Overlays with OSDK

Post by Dbug »

I'm wondering about something... (Warning, thinking out loud)

Let's say you use Chema's idea of using jump tables, there are actually two ways of doing that:
#1 Have each module have just jump tables for the current module
#2 Also have a global jump table for all the functions that exist across all the modules

If each module only has jump tables to the current module functions only, it's much more compact in memory, but on the other hand it means that all the calling code has to know which module is currently active and has to load the correct module before calling the function.

If the jump table is global, it's probably possible to do something fancy that can perform automatic loading of modules before calling the function if it is not yet available.

Another alternative is to use the BRK instruction to perform the function calls.

You could define with a macro your own JSR function, which would take two parameters: Module number and Function number

Then the BRK handler would check if the current module is already loaded, if not loads it, then call the right function through the jump table.

So let see some pseudo code:

Code: Select all

// The new 'JSR' function
#define CALL(moduleid,functionid)  brk:.byte moduleid,functionid

// List of modules
#define MODULE_A 0
#define MODULE_B 1
#define MODULE_C 2

// Module A functions
#define FUNC_FOO 0
#define FUNC_BAR 1
#define FUNC_ZOB 2

// Module B functions
#define FUNC_TAGADA 0
#define FUNC_BAZINGA 1
#define FUNC_YIHA 2

// Module C functions
#define FUNC_DOSTUFF 0
#define FUNC_MORESTUFF 1
#define FUNC_STUFFED 2
#define FUNC_FLATTENED 3
#define FUNC_DEFLATTENED 4


  // Random calls
  lda #65
  CALL(MODULE_A,FUNC_FOO)
  ...
  CALL(MODULE_B,FUNC_DOSTUFF)
Then conceptually this will generate a BRK call followed by the two parameters, the first one is used to load the module and the second one for the jump.
Post Reply