Using overlay memory: how, tips and possibility for direct save/load

Since we do not have native C compilers on the Oric, this forum will be mostly be used by people using CC65 or the OSDK. But any general C related post will be welcome !
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by Dbug »

Indeed FloppyBuilder does not generate a Sedoric floppy, but if you can map the tracks and sectors where the data is, the Blake's 7 disk access code would work the same way.

There is save code:

Code: Select all

; CHEMA: Support saving
; Assumes that _LoaderApiEntryIndex contains a valid value (temp)
; As well as _LoaderApiAddress
; It fills the rest
_LoadApiSaveFileFromDirectory
    jsr SetLoaderParams
    jmp _LoaderApiSaveData

(...)

; Chema: WriteSupport
_LoaderApiSaveData			.byt OPCODE_JMP,<WriteData,>WriteData	   ; $FFEC-$FFEE
    
(...)

;-------------------------------------
; Write data. Uncompressed and
; directly to disk (no buffering)
; so deals with 256-byte chunks only
;-------------------------------------	
; CHEMA: I am re-using the var ptr_destination, though it
; is now the ptr to the buffer to write.
WriteData    
    
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

Correct, was checking the wrong file (looked ad sector_2-microdisc.asm, see I should look at loader.asm). Thanks!
This looks very usable, but not time to try now. Also code I would never ever be able to create myself with all the needed waits apparently and different bugfixes for FDC bugs.

(By the way: did I already say I really hate OSDN compared to Github? ;-) Sorry, you probably have your reasons, but the OSDN webinterface feels very spartan in especially the search code department, also because it can not preview the .asm files allthough they are plain text just because the extension is .asm instead of .s)
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by Dbug »

All the web UIs for source control suck, just in different ways.
The simplest is to fetch the SVN repository.

You can request to join the OSDN SVN repository, and I can add you to the list of users.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

Dbug wrote: Sun Jun 26, 2022 8:47 pm All the web UIs for source control suck, just in different ways.
The simplest is to fetch the SVN repository..
I do much code studying on my iPad, especially as I can do that in bed or on the coach in te living room 😉 which works rather well with GitHub. Much less so with OSDN.
Anywat, thx!
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by iss »

Well, let's finish this project ;).

I've just updated oricOpenLibrary with new library: lib-basic :idea: .
It's just one function like:

Code: Select all

void basic(char* command);
This function can execute BASIC tokens like:

Code: Select all

basic("CLS:PRINT\"Hello...\"");
and SEDORIC commands like:

Code: Select all

basic("!DIR");
basic("!SAVE\"SOMEFILE.BAS\"");
Only advice here is: always prefix SEDORIC commands with '!'.

You can find demo source code and compiled DSK (attached here too).

I think this will suite your needs.
Of course using sector r/w is more powerful but really requires lot work...

BTW, I think lib-basic should work with any Oric DOS :mrgreen:
Screenshot_20220626_233010.jpg
Attachments
libbasic_test.dsk.zip
(23.57 KiB) Downloaded 85 times
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

iss wrote: Sun Jun 26, 2022 9:32 pm This function can execute BASIC tokens like:
Very interesting Iss.

One problem: my whole purpose was to get rid of the RAM needed for the Sedoric commands. So invoking the Sedoric BASIC commands defeats that purpose. My code was already working with Sedoric using your libSedoric, just want that juicy 16 KB of RAM for my own purposes.

Your code is very useful for other ideas I have though, so might still be using it, just not for this.
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by iss »

Can you share roughly current memory map?
Maybe there should be easy and elegant solutions without the 16k overlay.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

iss wrote: Sun Jun 26, 2022 11:02 pm Can you share roughly current memory map?
Maybe there should be easy and elegant solutions without the 16k overlay.
https://github.com/xahmol/OricScreenEdi ... rymap.xlsx

Code: Select all

	StartHex	EndHex	SizeHex	StartDec	EndDec	SizeDec
ProgramMain	500	9000	8B00	1280	36864	35584
Screenmap	9000	AA00	1A00	36864	43520	6656
Window	AA00	B100	0700	43520	45312	1792
CharSwap	B100	B400	0300	45312	46080	768
CharStd	B500	B800	0300	46336	47104	768
CharAlt	B900	BB80	0280	47360	48000	640
Screen	BB80	BFE0	0460	48000	49120	1120
Free	BFE0	C000	0020	49120	49152	32
(Tabs misalign in the copy paste I see)

But again, program works, so in that sense I do not need t(e extra memory.

Want it though because:
- just because I can (I hope)
- to add some functionality such as a 8 KiB memory slot for an undo function
- to avoid the messy return to BASiC file handling of the present Sedoric routines on user error such as incorrect filename
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

Just checking on that Blake7 code:
I want to use the assembler code together with CC65, so want to change from XA65 syntax to CA65.

Really struggling with the macros for Telestrat alignment though:

Code: Select all

#ifdef TELESTRAT_ALIGN
#define PROTECT(X)  	.dsb (((X)&3)-((*+3)&3))&3,$ea
#define PROTECT2(X,Y)	.dsb (((X)&3)-((*+(Y)+3)&3))&3,$ea
#else
as CA65 does not have the .dsb function.

From what I understand, the .repeat function in CA65 should do more or less the same, so tried to convert to:

Code: Select all

TELESTRAT_ALIGN						= $01
	.ifdef TELESTRAT_ALIGN
	.macro	protect		count1
			.repeat	(((count1)&3)-((*+3)&3))&3
			nop
			.endrepeat
	.endmacro
	.macro	PROTECT2	count1,	count2
			.repeat	(((count1)&3)-((*+(count2)+3)&3))&3
			nop
			.endrepeat
	.endmacro
	.else
	.macro	PROTECT		x
	.endmacro
	.macro	PROTECT2	x,	y
	.endmacro
	.endif
But that does not work and gives an 'Error: Constant expression expected' compiler error on calling the macro like this:

Code: Select all

	protect __fdc_sector_1
__fdc_sector_1:	
	sta FDC_sector_register
So apparently my CA65 macro does only take a constant as input, not a variable like the program counter at compilation?

So questions?
- Am I correct that these NOPs are only needed for Telestrat compatibility and that I can completely ignore them if dropping Telestrat support?
- What exactly should the macro do? There are comments around the macro explaining, but think I still miss the core of it. If I see 'PROTECT(FDC_sector_register)', Input variable apparently is the FDC register address ($312 in this case), the &3 causes the address to be multiples of 4, the * is the program counter of the compiled line, the +3 &3 on that is getting to the next multiple of four, result is the difference between the two as multiple of 4? Or do I miss something?
- If so, then anyone has a suggestion on doing this in CA65? Or should I just drop it by dropping Telestrat support?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by Dbug »

I don't know CA65 that much, other that I never liked it, so can't really help there.

My suggestion would be to drop the Telestrat compatibility at the start, just try to get things working on the rest of the machines, and possibly just keep some comments to indicate where some Telestrat "padding" is required.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

My idea as well. And of course, reason to use CA65 is not because I hate XA65, but mixing XA65 with CC65 C code will be a whole other level of challenge.
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by iss »

First, CA65 has .res which is the same as XA's .dsb ;).
But here the problem is not related to XA and CA65! You can't have such code and simply link it to C-code.
The 'secret' is that your object files are 'relocatable' and during the compile time it's unknown at which actual address the code will be placed - this is know after linking but the linking depends on that address, so ... chicken and egg problem :). This explains the error message 'Constant expression expected'.

Possible solutions are:
- use @Dbug's suggestion and ignore Telestrat for now ( +1 from me ;) );
- compile the disc i/o code as standalone 'driver' on fixed address i.e. specify at asm begin * = $1000 (for XA) or ORG $1000 (for ca65). Then start with a JMP table which 'exports' your driver's internal functions and call them from your C-code using pointer to function.
- play with the ld65's CFG files defining special segment with known alignment and place disc routines in this segment.
- reconsider again the power of the 'basic' function from my previous post :idea:
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by iss »

iss wrote: Mon Jun 27, 2022 12:19 pm - reconsider again the power of the 'basic' function from my previous post :idea:
btw, when you switch-on the 16k overlay you have to take care about:
- no ROM functions anymore - cc65 libs depend on ROM too;
- where the IRQ,NMI,RESET vectors are pointing?
- keyboard interaction
- ... etc.
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

Iss, thanks, did know of .res, did not know it took variables like .dsb does (was already using that for all other .dsb reservation, overlooked that it could take variables and went way to complicated with .repeat), but indeed not variables only constants, so you are fully right.

It is completely possible though to indeed just let it compile at a fixed address, so will contemplate that as a later option after I get it working without the Telestrat delays.
Use those segments in the .cfg file a lot in my Commodore compiles (especially the C128 buid as the code that uses bankswitching should be below the set shared memory boundary, otherwise it can not be running before or after the bank being switched). So that should not be any issue. Thanks for the tip!

On using that 16k: see beginning of this thread, I actually already had fully functional code that switches the RAM overlay on just for the short time needed to do read/write/copy memory from that area, and switch back to ROM afterwards.
So during program execution ROM is enabled for all CC65 libs to use, apart from calling specific memory manipulation functions (OPOKE, OPEEK, OMemCpy, OMemSet) that do not use CC65 lib functions nor ROM calls and in which IRQ is temporarily disabled.
So think that I allready solved that part. Only then to find out that SEDORIC was doing the exact same thing and was already using that RAM.....
User avatar
xahmol
Flight Lieutenant
Posts: 437
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

Re: Using overlay memory: how, tips and possibility for direct save/load

Post by xahmol »

Starting to give up on the sector read/write idea as it now compiles, but crashes at locations completely outside of my code, so I am expecting that I somehow completely screwed up system IRQ vectors or states and such. Probably either made a porting mistake, or am overlooking something that makes the environment different from what the code expects. But very hard to find bugs if you do not always understand what the code does, let alone what system values do. So conclude that I lack the knowledge to do this.

Also do not want to bother you further, thanks for all the help!

So probably go on releasing Oric Screen Editor as it is now, with the present libSedoric save and load routines.
Iss, any advantage of going the BASIC route for those instead of just using your libSedoric functions? Assume still not better error handling?
Post Reply