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

[iss]

Indeed, still no error handling. I assume it can be done quickly but needs to check Sedoric docs for details.
One real advantage is that you can display the file names using basic("!DIR") and with simple code make a file selector. Just an idea...

[xahmol]

One real advantage is that you can display the file names using basic("!DIR") and with simple code make a file selector. Just an idea...

That was exactly which I also myself was thinking of.
Two things I want to experiment with:
- how the DIR outputs, as I assume it will completely disregard my carefully build screen layout?
- i really had not much space left in memory for code, that was the reason for investigating using the RAM overlay. So a file selector would be terrific, also for preventing user error, will be hard to squeeze that in that final bytes left though. Will look.

[Dbug]

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.

Could be a conflict between the zero page addresses used by CC65 and what the loader uses.
Normally the loader zero page values location may be changed, it does not uses many, but if they happen to be what the compiler uses, things will crash.

[xahmol]

Could be a conflict between the zero page addresses used by CC65 and what the loader uses.
Normally the loader zero page values location may be changed, it does not uses many, but if they happen to be what the compiler uses, things will crash.

Did already try to take that into account by letting CC65 itself assign ZP addresses (the .zero area in the Blake7 code), so that should not be it unless I missed some.

[xahmol]

Well, Iss, your lib-basic works just fine. Loading and saving goes indeed smooth, and code is 100 bytes smaller than your libSedoric.
Only downside so far I could find is that loading files does not accept wildcards anymore while your libSedoric did. But if I manage to build a filepicker that is not an issue anyway.

Also managed to format screen in such a way that also printing a DIR works fine:

Only a little worried what happens if too many files are on the disk, as scrolling will make the screen of course FUBAR. Any suggestion how to prevent that? Starter for me will probably be filtering the DIR on .BIN files only.

Apart from that scrolling issue, making a file picker should be easy from here as filename positions from left top are fixed (if no scrolling occurs at least), the last ones in each column can be detected by the empty startchar and the filenames can be read from reading the screen chars.

[Dbug]

I wonder if it would be possible to hook on the XVDU vector (in $238 normally points to F77C on the Atmos) which is the routine that prints a character to screen to receive the data returned by the Sedoric functions to basically collect the directory and display it whatever way you want.

[iss]

... to hook on the XVDU vector (in $238 normally points to F77C on the Atmos) ...

Indeed! This would be the easiest solution and IMHO it will work

[xahmol]

I wonder if it would be possible to hook on the XVDU vector (in $238 normally points to F77C on the Atmos) which is the routine that prints a character to screen to receive the data returned by the Sedoric functions to basically collect the directory and display it whatever way you want.

To check if I correctly understand it: you mean basically changing that vector in $238 to your own routine, which should than be a parser of the screen output received? And directly afterwards, of course change it back?
Should be doable of course. To be investigated. Probably not even too difficult, my only worry is the space needed to actually store that directory in memory which I might not have. So probably then still have to grab filenames from the screen, but just have my own 'dirprinter' routine just grab a max numbers of lines at a time with a variable offset for the startline.

Meanwhile, the filepicker as it is starts to get together nicely and should work as long as you do not put more than 15 lines of .BIN files or so (so 30 files) on the disk. Which is already a lot better IMHO than a file dialogue that lets you type the name free format without able to show disk contents and that will crash you to BASIC on any typo.

[Dbug]

You can still store the data on the screen, but since you have control about the data coming in, you can filter stuff out, like remove the extensions, or the size, which means you can fit way more files on the screen at the same time, and you can also choose where things are displayed, so for example you can put the disk name and free space in other locations.

[xahmol]

By the way: in how far does the dir output differ between Sedoric versions and in how far is it needed to support anything else but Sedoric 3?
Never see other Sedoric versions actually being used so far….

Do not want to overcomplicate things. And supporting subdirs of Sedoric 4 is not something I am happy to have on the to do list.

I do consider supporting multiple drives now that I can use the commands from Sedoric basic commands to do so, as at least in Oricutron I see value in having a system and a work disk without needing to swap all the time.

[iss]

By the way: in how far does the dir output differ between Sedoric versions and in how far is it needed to support anything else but Sedoric 3?

Oric.org has all major versions. I never thought about 'DIR' output differences but yes, it's plausible. Else your generated DSK from tap2dsk is (iirc) ver.3.006 and you can stick with it as 'requirement' for working disk. If someone need to copy files and use other versions it will be for backup only .
I'll will see what can be done for some basic error handling.
About the memory limit it's possible to 'split' your program in 2 parts the actual drawing and file chooser while the data remains in memory as shared.

[xahmol]

By the way: took me till last week to realise that the SED in SEDORiC is just the French abbreviation for DOS…..
Shame. Thought SEDORIC was a much more exciting name than just ORIC DOS

And yes, will stick with disks created by Tap2dsk as requirement for now at least. Will also hopefully prevent me from needing multi dir page support, if with a parser I can got more files on one go the limits of a single sided Tap2dsk created disk probably won’t fit more than a page of files anyway.

On splitting the program: yes, obviously that is possible, but it will things way more complex with much more additional disk io that can go wrong.
Actually extensively use overlay memory swapping on the C128 version as alas CC65 does not support the extended memory of the C128 beyond a very Spartan approach (no code, no variables), so CC65 by default actually has less memory available on the C128 target than on the Oric Atmos target, as the Commodore ROMs that are mapped in by default are bigger than the Atmos one (next to attribute memory and some other things).
Exactly the reason why I was surprised to not need memory overlays on porting to the Oric till now.

[xahmol]

Alas, changing the $238 vector does not seem to work on SEDORIC output.

Using 'Sedoric 3.0 à NU' I tried to look why, and I think I now why: for screen output SEDORIC directly points to the $CCD9 ROM routine, which has the JSR $F77C hard coded. So SEDORIC does not seem to use the $238 vector.

See 'EXÉCUTION DE LA COMMANDE SEDORIC DIR' starting on page 278.
https://library.defence-force.org/books ... 0_a_nu.pdf

On page 279 I see the first encounter of a character printed to the screen:

Code: Select all

E355- 20 6C D3 JSR D36C affiche (X+1) ème message de zone CEE7 terminé par "caractère + 128"

so for printing a char it jumps to $d36c.

This routine jumps to the XAFCAR function:

Code: Select all

D391- 20 2A D6 JSR D62A XAFCAR affiche le caractère ASCII contenu dans A

which in its turn jumps to D20E:

Code: Select all

D634- 4C 0E D2 JMP D20E continue en D20E (affiche le caractère présent dans A)

And on D20E it jumps to the $CCD9 ROM address by using the function in the SEDORIC code to swap ROM back in:

Code: Select all

Affiche le caractère présent dans A
D20E- 20 D8 D5 JSR D5D8 XROM exécute à partir de la RAM une routine ROM
D211- 12 CC D9 CC adresse ROM 1.0 adresse ROM 1.1
D215- 60 RTS

And after switching to ROM, it than lands at this code at $CCD9:
(source https://iss.sandacite.com/tools/oric-atmos-rom.html)

Code: Select all

$CCD9	24 2E                    	BIT   $2E                               	If CTRL O flag is set then set
$CCDB	30 33                    	BMI   $CD10                             	flags and exit.
$CCDD	48                       	PHA                                     	Save char to be printed.
$CCDE	C9 20                    	CMP   #$20                              	If control character do not
$CCE0	90 0B                    	BCC   $CCED                             	check cursor position.
$CCE2	A5 30                    	LDA   $30                               	Compare cursor position with
$CCE4	C5 31                    	CMP   $31                               	line width.
$CCE6	D0 03                    	BNE   $CCEB
$CCE8	20 F0 CB                 	JSR   $CBF0                             	If past end, print Newline.
$CCEB	E6 30                    	INC   $30                               	Advance cursor column.
$CCED	68                       	PLA
$CCEE	2C F1 02                 	BIT   $02F1
$CCF1	10 08                    	BPL   $CCFB                             	Printer is off.
$CCF3	48                       	PHA
$CCF4	20 3E 02                 	JSR   $023E                             	Send byte to printer.
$CCF7	68                       	PLA
$CCF8	29 FF                    	AND   #$FF                              	Set flags and exit.
$CCFA	60                       	RTS
$CCFB	86 27                    	STX   $27                               	Save X register.
$CCFD	AA                       	TAX
$CCFE	20 7C F7                 	JSR   $F77C                             	Print character to screen.

which indeed uses the JSR to $F77C.

So, what I will try next (do not have time now for at least till 13h) is if I can switch to RAM overlay to POKE into the SEDORIC code (as it is in RAM, that should be possible, right?), and try to change that JSR D5D8 on $D20E to my own capture routine, as of course my own code is not in ROM so would not need the $D5D8 jump.
Would/should that work?

Alternatively, I see that $CCD9 ROM routine checks if the printer is enabled via the $2F1 flag, and if yes, uses the vector at $023E for output to printer, so maybe could also enable the printer and change the $023E vector?

[Dbug]

Alas, changing the $238 vector does not seem to work on SEDORIC output.

So, what I will try next (do not have time now for at least till 13h) is if I can switch to RAM overlay to POKE into the SEDORIC code (as it is in RAM, that should be possible, right?), and try to change that JSR D5D8 on $D20E to my own capture routine, as of course my own code is not in ROM so would not need the $D5D8 jump.
Would/should that work?

Yes, it's RAM so you can definitely patch the code

Alternatively, I see that $CCD9 ROM routine checks if the printer is enabled via the $2F1 flag, and if yes, uses the vector at $023E for output to printer, so maybe could also enable the printer and change the $023E vector?

Nah, keep the printer available, that could even be a feature for your tool, allowing to print out the resulting image

[iss]

Yep, $238-trick doesn't work but you already commented it in-depth.
Good news for Sedoric I/O - at $4FD is the result code from last operation: if it's 0 (zero) - no error.