Using overlay memory: how, tips and possibility for direct save/load
Re: Using overlay memory: how, tips and possibility for direct save/load
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...
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
- 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
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Could be a conflict between the zero page addresses used by CC65 and what the loader uses.xahmol wrote: ↑Mon Jun 27, 2022 3:36 pm 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.
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
- 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
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
- 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
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.
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
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.
- 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
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?Dbug wrote: ↑Tue Jun 28, 2022 9:00 am 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.
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
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
- 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
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.
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
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
- 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
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.
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
- 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
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:
so for printing a char it jumps to $d36c.
This routine jumps to the XAFCAR function:
which in its turn jumps to D20E:
And on D20E it jumps to the $CCD9 ROM address by using the function in the SEDORIC code to swap ROM back in:
And after switching to ROM, it than lands at this code at $CCD9:
(source https://iss.sandacite.com/tools/oric-atmos-rom.html)
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?
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"
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
Code: Select all
D634- 4C 0E D2 JMP D20E continue en D20E (affiche le caractère présent dans A)
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
(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.
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?
Re: Using overlay memory: how, tips and possibility for direct save/load
Yes, it's RAM so you can definitely patch the codeSo, 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?
Nah, keep the printer available, that could even be a feature for your tool, allowing to print out the resulting imageAlternatively, 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?
Re: Using overlay memory: how, tips and possibility for direct save/load
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.
Good news for Sedoric I/O - at $4FD is the result code from last operation: if it's 0 (zero) - no error.