Question 1: Possible to use it by switching on only when needed and then switching off again?
The arcticle describes how to switch off overlay ROM and that looks very clear and easy. However, the downside of not being able to use ROM kernal routines anymore would be an issue for me, as I program in C using CC65 and the CC65 libs most definitely are using those ROM routines.
However, with programming on the Commodore 128 (and to lesser extent the Commodore Plus/4) I have reference on how to do a similar thing there, and that is basically switching the correct bank over overlay area in, do stuff that you want there, and switch back to the original memory layout.
So would a similar think be possible on the Oric as well by doing it like this?
- stop IRQ
- enable overlay RAM
- do the PEEKing, POKEing and memory copying
- disable overlay RAM
- enable IRQ
- return
Or do I miss some other caveat here now?
If possible, it would be fairly easy to create POKE_OVERLAY, PEEK_OVERLAY and MEMCPY_OVERLAY routines in assembly to use with C wrapper functions, which would directly enable to use overlay RAM for data storage, swap storage and even overlay code storage in CC65.
Question 2: Is there any possibility for direct SEDORIC LOADs to and SAVEs from overlay RAM memory?
Ideally, I would like to directly load and save data to and from the overlay memory RAM area. But as the SEDORIC calls to make for those SAVEs and LOADs are residing in that same overlay memory area, my assessment so far is that that alas is not possible, at least not without yourselves completely rewriting own routines to replace the SEDORIC ROM ones, a task I lack the knowledge to do, if even possible.
Am I correct in this? Or are there possibilities to do this?
(on the Commodore machines, this is fairly easy to do as by default ROM kernal calls exits supporting disk load/save, that also fully support overlay and banked memory areas. To begin with, the most important kernal calls on Commodore machines are reachable via jump pointers in the always visible $FFxx memory area).
Background
After doing some Commodore projects I am now preparing to return for some Oric coding. Have my build chain up and running again (on different machine, and now Linux based using WSL2/Ubuntu under Windows 11).
I am investigating the viability of porting my most recent Commodore project, a screen editor. See the original C128 80 column version and the port I just finished for the Commodore Plus/4.
Main premise of this utility is the ability to use rather large screen maps that are a multiple of the visible screen. The C128 version can use up to 30 KiB as screenmap, the Plus/4 version 15 KiB. For the Oric I need half the memory as on the Commodores as characters and attributes are not two seperate memory areas (obviously, the lack of seperate attribute space will complicate the rest of the program and limit some possibilities, but that is how it is on the Oric). But still, it would be nice to have at least 7-8 KiB memory available for screen map data, next to having room for swap memory for my windowing system, swap memory for some screen operation stuff and memory to swap out a redefined character set to be able to return to the default charset and back to the redefined one.
For all this, of course the ablity to use that 16 KiB overlay memory RAM area would be ideal. But especially for that 7-8 KiB screenmap space, only if direct load and save to that area is possible to avoid need to reserve that 7-8 KiB in normal RAM at least as loading temporary buffer area.
Appreciate your ideas and tips!
Re: Using overlay memory: how, tips and possibility for direct save/load
Question 1: Possible to use it by switching on only when needed and then switching off again?
So would a similar think be possible on the Oric as well by doing it like this?
(...)
Or do I miss some other caveat here now?
If possible, it would be fairly easy to create POKE_OVERLAY, PEEK_OVERLAY and MEMCPY_OVERLAY routines in assembly to use with C wrapper functions, which would directly enable to use overlay RAM for data storage, swap storage and even overlay code storage in CC65.
Indeed, switching between ROM and RAM is just one byte to change in page 3, and yes the issues is code that uses the ROM, including IRQs.
Assuming your code does not rely on anything from the C000-FFFF ROM, there are two ways to deal with the IRQ issue:
Manually disable or enable IRQs using combinations of SEI/CLI/PLP/PHP around the code you want to run
Have the IRQ vector in the overlay ram point to some dummy IRQ handler that just does RTI
xahmol wrote: ↑Tue May 31, 2022 8:36 amQuestion 2: Is there any possibility for direct SEDORIC LOADs to and SAVEs from overlay RAM memory?
Ideally, I would like to directly load and save data to and from the overlay memory RAM area. But as the SEDORIC calls to make for those SAVEs and LOADs are residing in that same overlay memory area, my assessment so far is that that alas is not possible, at least not without yourselves completely rewriting own routines to replace the SEDORIC ROM ones, a task I lack the knowledge to do, if even possible.
Am I correct in this? Or are there possibilities to do this?
That's a complicated question, in theory Sedoric is BANK based, so it's possible to restrict Sedoric to only some parts of the overlay, but I've never done it myself.
This whole thing is why I made the Floppy Builder in first place, to allow us to have a minimalistic loader to get almost full access to the overlay ram, but it's not ideal for tools because the format is not standard which means you would need some additional tool to extract the data to use it somewhere else.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue May 31, 2022 9:13 am
by xahmol
Thanks Dbug, confirms what I thought to understand. So will start experimenting with that.
On the Sedoric banking topic: good to know it probably is possible then, but as said would not know where to begin myself (nor do I have any hope of being able any time soon). So unless maybe Iss reworks his SEDORIC routines in his OpenOricLibrary that I use now for SEDORIC stuff to enable banking, I will for now alas consider direct save/load a no go.
Will then have to do some puzzling if I can squeeze a program I started to design using 128 KiB that I squeezed in 64 KiB on the Plus/4 to the 48 KiB of the Atmos, with possibly some use of the overlay RAM area for swapping data and code.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue May 31, 2022 9:28 am
by Dbug
Technically, an alternative could be to have a Sedoric compatible floppy, with pre-saved "slots" for whatever your tool does (not sure if it's fixed size or not), which if they are stored continuously on the floppy could be then simply accessed by some read/write sectors without requiring Sedoric at all (as long as you know the position of the first sector.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue May 31, 2022 11:00 am
by xahmol
Makes sense, and I think would be viable. Would then need to look into what your floppy builder tool is doing. But my first guestimate is that that is a more complex undertaking for me then I am presently prepared to do. But will keep it in mind as potential future improvement, especially as the other approach will really give me lack of memory issues.
Thanks for thinking along!
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue May 31, 2022 11:16 am
by Dbug
I was more thinking of testing with Tap2DSK, like adding a bunch of empty tap files of the right size to reserve spots on the disk.
Should probably check how Tap2DSK allocates the sectors, but they are probably consecutive on disk.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue May 31, 2022 1:03 pm
by Chema
Well, Dbug already answered and provided most (all?) of the relevant information.
I have used overlay ram several times and you can check the source code. As you are restricted to C, you have the problem with library functions that use the ROM routines.
That is what we faced in pinforic and our solution was to patch the libraries and add code to switch the overlay off and on when necessary: switch_to_ram and switch_to_rom defined in header.s inside the lib16 folder. In the end, I think Fabrice came up with only two patched functions (getchar & putchar, redefined in header.s), and patched only a few library files that used the originals. I am not sure if he did anything else, but that was the general idea.
About using sedoric, that would be indeed trickier. Sedoric basically loads in overlay ram, so I doubt you can do much without becoming mad. What can be done for sure, is loading chunks of data using sector-based reads. I've done that in Space:1999 and 1337. Just create a file with your data and store it the first one when creating the disk. If I recall correctly, its data will start at sector 100 (after Sedoric stuff). I usually assemble everything that is to go there separately, creating a tap file which is added to the final disk by setting OSDKDISK= <tap_with_data> <taps with program>
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue May 31, 2022 2:48 pm
by xahmol
Thanks Chema.
Think I will have more work than you in C as I use CC65 and not the standard OSDK C compiler you probably do. I presently use the CC65 conio.h lib quite extensively and that one almost for certain is making lots of kernal calls.
Of course that is certainly solvable by reverting to more OSDK C like routines for screen handling, but that also sacrifices code portability so comes with a price.
But I think for what I have in mind I probably can manage with just needing to read overlay RAM with a PEEK like function, write to it with a POKE like function and copy memory to and from it with a memcpy like function. I actually already did write similar functions to use banking on the C128, which CC65 also does not support out of the box. Difference only being that on the C128, its MMU (memory management unit) takes care of things like IRQ going to the right place, so no need to disable interrupts there.
So think I will start with a PoC with at least these functions in assembly and avoiding any ROM call or C lib call in those functions. Should be doable, unless I miss something in how the Atmos behaves.
If I have that, at least I can use the memory space for:
- using the CC65 overlay system from memory instead of loading from disk by swapping the CC65 designated code overlay area in and out of that upper 16 KB area. Actually also now do that in my C128 version.
In that way, you have no need to run the code from the C000-FFFF area, you designate some area under the textscreen area as code overlay area and copy the code in from the upper 16KB on demand. CC65 supports the proper linking and addressing for that (sorry for the Wayback Machine link, but although the original is offline, this was still the best tutorial on CC65 overlays I could find),
Price is of course that there is always a part f code that is residing twice in active memory, namely both the CC65 overlay area and the upper 16 KB area, but that is certainly already way better than not using that 16 KiB at all.
- Swap memory for screen manipulation functions, unless it proves to be too slow. Probably fast enough though as I am not building an action game here
- Swap memory for custom character sets
- Maybe (but that is stretching) also the undo/redo implementation I made on the C128 using the 64 KB VDC video RAM memory if available (most machines have 16 KB, so made that part optional)
Sedoric direct sector access routines I still envision as a maybe for later. Think my skills are not mature yet to venture into that.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Thu Jun 02, 2022 1:57 pm
by xahmol
By the way, Chema, your code for doing this confirms what I thought that would work my self, so thanks, very usable:
; ======================================================================
; Overlay memory area routines code
; ======================================================================
switch_to_rom:
; Enable bits 1 and 7 of $0314 to enable overlay ROM
; Bit 1: Enables the internal BASIC ROM when set to one
; Bit 7: Enables the disk controller boot EPROM
lda #$7F ; Load $7F for #011111111 mask to enable bit 1 and disable bit 7
sta $0314
rts
; Restore state after re-enablling overlay ROM
cli ; Re-enable IRQ
rts
switch_to_ram:
; Set safe state to disable overlay ROM
sei ; Stop IRQ
; Disable bits 1 and 7 of $0314 to disable overlay ROM
; Bit 1: Disables the internal BASIC ROM when set to zero
; Bit 7: Disables the disk controller boot EPROM
lda #$FD ; Load $FD for #%11111101 mask to disable bit 1 and enable bit 7
sta $0314
rts
; Overlay memory areas core routines
; ------------------------------------------------------------------------------------------
_POKEO_core:
; Function to poke to a memory position with upper 16KiB overlay RAM area enabled
; Input: ORIC_addrh and ORIC_addrl: high and low byte of address to poke
; ORIC_value: value to poke
; ------------------------------------------------------------------------------------------
jsr switch_to_ram ; Enable overlay RAM
; Set address pointer in zero-page
lda _ORIC_addrl ; Obtain low byte in A
sta ZP1 ; Store low byte in pointer
lda _ORIC_addrh ; Obtain high byte in A
sta ZP2 ; Store high byte in pointer
; Store value in specified address
ldy #$00 ; Clear Y index
lda _ORIC_value ; Load value in A
sta (ZP1),y ; Store at destination
jsr switch_to_rom ; Disable overlay RAM
rts
; ------------------------------------------------------------------------------------------
_PEEKO_core:
; Function to peek a memory position with upper 16KiB overlay RAM area enabled
; Input: ORIC_addrh and ORIC_addrl: high and low byte of address to peek
; ORIC_tmp3: MMU config for peek
; Output: ORIC_value: value peeked at address
; ------------------------------------------------------------------------------------------
jsr switch_to_ram ; Enable overlay RAM
; Set address pointer in zero-page
lda _ORIC_addrl ; Obtain low byte in A
sta ZP1 ; Store low byte in pointer
lda _ORIC_addrh ; Obtain high byte in A
sta ZP2 ; Store high byte in pointer
; Store value in specified address
ldy #$00 ; Clear Y index
lda (ZP1),y ; Load value from source address
sta _ORIC_value ; Store value in variable to return
jsr switch_to_rom ; Disable overlay RAM
rts
Wrote a small test program that pokes values 0-9 in the area from $C000 and $F000 and reads back from both ROM as RAM:
Only I also want to understand WHY it works (and please forgive my still novice grasp of assembly and the Oric inner workings).
I first tried the Pinforic code Chema pointed me too. Did not work, when trying to read from RAM I get the values from ROM. I also note that that code uses for the Microdisc code this for switch_to_ram:
Which puzzles me, as $84 sets 1000 0100 as bitmask, which is way different than the bitmask 11111101 that DBug is explaining in his OSDK article. On the other hand, the bits that apparently matter, 1 and 7, are the same (0 and 1 respectively), so for that reason it is strange that the Pinforic one does not seem to work.
Also I see a value been stored in the Pinforic code in $32f (lda #0 sta $032F), what does that do? What is $032F?
The mask from the Dbug artictle does work, but if possible I also want to understand that Pinforic code.
I also found that actually adding php/pha/pla/plp around my code breaks the code, it breaks on execution. Without it it seems to work just fine. Why is this, so I understand why the first breaks and the second seems to work? Also to ensure I do not miss something biting me as bug later?
Is there somewhere a full documentation on the meaning of all bits in $0314, and preferably all extra registers added by the Microdisc controller? Do not see them in the Sedoric manual for example. Neither in Oric Advanced User Guide
And finally, is there a way in the Oricutron monitor to dump the RAM in the overlay memory area instead of the ROM? Do not see any option in the manual to choose which memory area is dumped.
Re: Using overlay memory: how, tips and possibility for direct save/load
Thanks for that already!
(but from now knowing what the other bits of $314 do, still not understand why the Pinforic code did not work for me. Maybe did something else wrong as well)
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 03, 2022 10:09 am
by xahmol
xahmol wrote: ↑Fri Jun 03, 2022 9:24 am
I also found that actually adding php/pha/pla/plp around my code breaks the code, it breaks on execution. Without it it seems to work just fine. Why is this, so I understand why the first breaks and the second seems to work? Also to ensure I do not miss something biting me as bug later?
Never mind this question: just realised myself what I did wrong there (doing php/pha in the enable_ram routine without doing a pla/plp before returning (did the pla/plp after the enable_rom routine) obviously makes that the program counter does not know where to return. Duh.....). So only question is: is that php/pha/pla/plp really needed as my code so far seems to work without it.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 03, 2022 10:19 am
by xahmol
Think I have found the reason why the Pinforic code was not working as well, forgot the part of the code that was initialising the machine_type variable:
So think that by not initialising this, the code jumped to the Jasmin code, instead of the Microdisc code.
Will now contemplate if I want to support Jasmin or only Microdisc, as the way it is done here might be complicated in what I am doing. As far as I understand from this, on program start it stores whatever is in the accumulator at program start, which apparently is an indication of machine type? But as I am using C in CC65, it is actually complicated to run this little piece of code at program start as first the CC65 initialisation code kicks in. Possible I guess, but have to dive in CC65 initialization code then. So think I will refrain from supporting Jasmin for now. Or is there an alternative to do this?
Checked, and indeed my code is also working with the $84 and $86 bitmasks of the Pinforic code.
Think I will modify my code to just toggle the 1 and 7 bits and remain the rest of $314 intact, as if I see the meaning of those other bits, I suspect that changing them might interfere with disk operations of my program. So will either use logical AND/ORs to toggle bits, or safeguard and restore the original value of $314 on entering/leaving RAM overlay enabled.
; ======================================================================
; Overlay memory area routines code
; ======================================================================
switch_to_rom:
; Set safe state
php ; Push program counter
pha ; Push accumulator
; Restore old $0314 value
lda ORIC_FDCtmp ; Get old value of $314
sta FDC_BUFFER ; Restore value
; Restore state after re-enablling overlay ROM
pla ; Pull accumulator
plp ; Pull program counter
cli ; Re-enable IRQ
rts
switch_to_ram:
; Set safe state to disable overlay ROM
sei ; Stop IRQ
php ; Push program counter
pha ; Push accumulator
; Safeguard old value of $314
lda FDC_BUFFER ; Load present value of $314
sta ORIC_FDCtmp ; Safeguard at tempory location
; Disable bits 1 and 7 of $0314 to disable overlay ROM
; Bit 1: Disables the internal BASIC ROM when set to zero
; Bit 7: Disables the disk controller boot EPROM
lda #$FD ; Load $FD for #%11111101 mask to disable bit 1 and enable bit 7
sta FDC_BUFFER ; Store in FDC register at $0314
; Pull PC and A
pla ; Pull accumulator
plp ; Pull program counter
rts
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 03, 2022 6:59 pm
by Chema
Sorry for not being able to answer before...
You only have to save the registers you wish, of course. I use to save those I modify (a and p in this case). I have yet another version which I am using in 1337 and also disables interrupts, just in case. Here is the code:
diskcntrl .byt $86
_switch_ovl
php
pha
sei
lda diskcntrl
eor #2
sta diskcntrl
sta $0314
lda #0
sta $032F
pla
plp
rts
This one is just one routine to switch overlay in and out (by modifying the value of diskcntrl. You don't need to enable interrupts back with cli, as plp gets the original value of the interrupt flag (whatever it was).
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 03, 2022 7:30 pm
by Dbug
Regarding php/plp, it's mostly a convenience used to avoid restoring the wrong context: That will restore the IRQ mode which was present before the function was called, so it it was already disabled, it will leave it disabled, contrary to SEI/CLI which will always restore IRQ even if they were disabled originally
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 03, 2022 11:24 pm
by xahmol
Thanks, very clear!
One question remaining: is it possible to show/dump overlay RAM area memory contents in the Oricutron monitor for debugging?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sat Jun 04, 2022 8:41 am
by iss
xahmol wrote: ↑Fri Jun 03, 2022 11:24 pm
One question remaining: is it possible to show/dump overlay RAM area memory contents in the Oricutron monitor for debugging?
Yes, using Oricutron debugger you can access RAM/ROM simply use mm command:
mm $314 $7f (activate internal BASIC ROM), m $c000 (display memory content):
mm $314 $00 (activate Overlay RAM), m $c000 (display memory content):
Here is some info for more proper value to poke at $314 (if you don't have them already):
/***************************************************************************************************************************************
* ; $0314 / $03f8
* ;
* ; |xxxxxxxx| Write
* ; ||||||||
* ; ||||||||_____bit 0: enable FDC INTRQ to appear on read location $0314 and to drive cpu IRQ
* ; |||||||_____ bit 1: ROMDIS (active low). When 0, internal Basic rom is disabled.
* ; ||||||______ bit 2: along with bit 3, selects the data separator clock divisor (1: double density, 0: single density)
* ; |||||_______ bit 3: double density enable (0: enable double density, 1: disble DD, i.e. single density)
* ; ||||________ bit 4: side select
* ; |||_________ bit 5: drive select (0 to 3)
* ; ||__________ bit 6: drive select (0 to 3)
* ; |___________ bit 7: Eprom select (active low)
* ;
* ; |x.......| Read
* ; |____________ bit 7: INTRQ state (only if bit 0 above has been set to 1) in negative logic so it`s 0 if FDC requests an Interrupt.
* ;
* ;
* ; $0318 / ($03fc - not valid for Jasmin)
* ;
* ; bit 7: DRQ state (active low)
***************************************************************************************************************************************/
EDIT: Note you need to start Oricutron with "attached" Microdisc FDC (./oricutron -km) or using DSK image (which by default will activate FDC usage).
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sat Jun 04, 2022 3:29 pm
by xahmol
Super thanks you all!
Will probably not come back (I hope, because that means that I do not encounter issues I can not directly solve) until I have a finished program.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 05, 2022 11:16 am
by polluks
xahmol wrote: ↑Sat Jun 04, 2022 3:29 pm
Super thanks you all!
Will probably not come back (I hope, because that means that I do not encounter issues I can not directly solve) until I have a finished program.
Feel free to do a PR at cc65 of your work
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 05, 2022 5:45 pm
by xahmol
polluks wrote: ↑Sun Jun 05, 2022 11:16 am
Feel free to do a PR at cc65 of your work
A PR for what? I am not adapting anything on my CC65 install, keep that standard. Just use own assembly routines next to it to do stuff CC65 dies not do out of the box.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 8:07 am
by xahmol
Hmm. Just realised I actually did miss something very fundamental.
Was assuming that SEDORIC was banked in to be in the same memory space as the overlay RAM area, but now realize that SEDORIC is actually USING the overlay RAM memory area.
Which for most here obviously is a 'duh', reading back I actually see that both Dbug in his article and even more clear Chema in his quote below were literally sauying so.
Chema wrote: ↑Tue May 31, 2022 1:03 pm
Sedoric basically loads in overlay ram
But this did not fully sink into me till just now. Too spoiled on the Commodore 128 original with all its banking functions switching ROMs and RAM areas in and out, combined with the Commodore drives being full 6502 CPU computers in itself with own ROM and RAM and the DOS fully on the drive.
OK.
So that means that not only you can not use save and loads using SEDORIC to and from the overlay memory area, but you can not use SEDORIC calls at akk after using the overlay RAM area yourselves, period. As you have just overwritten those SEDORIC routines.
Bummer.
This means that overlay RAM is still very usable this way for any program that basically loads all at start and not thereafter, but for my present project that is rather an issue as a screen editor without the possibility to load and save and to copy your saved stuff to other disks to be used is rather pointless. So I do need to be able to do disk operations during every moment of program execution.
Good news is that actually it seems that I might not need to use the overlay RAM to fit the program in, for some reason the C sources compile to much smaller binaries using the Atmos target compared to the Commodore Plus/4 and certainly the Commodore 128 targets. Partly explainable, as I could ditch all code lines that to manipulation and copying of the color attribute memory area as the Oric does not have one. But also apparently, the CC65 Atmos libs are rather efficient in code size compared to the Commodore ones.
But I might indeed than be diving in doing disk operations without using SEDORIC. I glanced trough the Pinforic code, and that seems to be understandable and doable for me. But that will probably be a release 2.0 endeavor.
One thing is that I than have to solve is that stuff saved from my screen editor (screens and charsets) are not only usable using the screen editor itself, but should also be possible to copied as file to other disks. And not sure if it is in any way possible to use sector based diirect loads and writes while still being able to create a file that is also readable as file seperately using SEDORIC. And that for a number of user definable different files, preferably not just one stub file. And also preferably without needing to basically rewrite a whole DOS again
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 8:20 am
by xahmol
By the way: apart from the SEDORIC manuals in the Oric Library, is there anywhere a technical reference manual of SEDORIC explaining memory use and memory map of SEDORIC?
I see something of what I mean in https://library.defence-force.org/books ... /index.htm
I can manage with it being in French (my basic grasp of French and Google translate will be probably just enough to understand it), but as far as I can see it does detail all addresses of SEDORIC variables and SEDORIC system calls, but it does not detail which part of the 16k RAM overlay is actually used by SEDORIC.
Is SEDORIC using the whole 16k? Or might there still be an area in that 16k that is not used by SEDORIC so usable for programs while keeping SEDORIC active?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 8:56 am
by Symoon
xahmol wrote: ↑Fri Jun 10, 2022 8:20 am
By the way: apart from the SEDORIC manuals in the Oric Library, is there anywhere a technical reference manual of SEDORIC explaining memory use and memory map of SEDORIC?
The most advanced book on Sedoric is "Sedoric à Nu", by André Chéramy, describing Sedoric 3.0
It's a 700-pages long book in French, but I guess some automated translation could be used.
I'm not sure is holds a memory map summary though.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 9:22 am
by Dbug
xahmol wrote: ↑Fri Jun 10, 2022 8:07 am
Hmm. Just realised I actually did miss something very fundamental.
Was assuming that SEDORIC was banked in to be in the same memory space as the overlay RAM area, but now realize that SEDORIC is actually USING the overlay RAM memory area.
(...)
That's why I mentioned that Sedoric is BANK based, it's not just 16KB of stuff loaded in one big block, it's made of multiple parts that are dynamically loaded/replaced depending of what is being called.
I don't know enough about Sedoric to know if it's possible, but there's a possibility that some basic Sedoric read/write access is still possible while having some other banks overwritten and used by your program.
As Symoon mentioned, it's probably all documented by André in "Sedoric A nu".
From page 12 and later we can see that
- C000 contains some status data
- C100-C1FF contains the read/write sector buffer
- C200-C2FF contains the bitmap (allocated sectors)
- C300-C3FF is another read/write buffer for the directory
- C400-C7FF is a Bank used to initialize Sedoric that gets overwritten after
Then page 30 it talks about "Swappable banks" in the same C400-C7FF area where the various commands like INIST, BACKUP, etc... are loaded.
Page 161 it presents the "permanent kernel" which goes from C800 to FFFF
So yeah, looks like it's quite full, and the swappable banks area is not that big :-/
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 10:08 am
by xahmol
Thanks!
Will investigate from there. But probably not a quick fix then to be applied on short term.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 10:13 am
by xahmol
And funny. I completely overlooked SEDORIC 3.0 à NU in the Oric Library. Did find it now, seems to provide what I was looking for.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 10:55 am
by Chema
If you want to actually load/save from SEDORIC files inside the disk, you would need SEDORIC in memory. Our routines are sector-based, so you basically state "read sector n here" or "write data from here to sector m". You'd have to add all the managing of the files and how the OS stores them in disk sectors.... could be complicated.
What are your memory needs? If you only need some temporary buffer, or some data you access with not high time-constraints, you could simply mimic the overlay system SEDORIC uses itself.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 11:11 am
by xahmol
Chema wrote: ↑Fri Jun 10, 2022 10:55 am
What are your memory needs?
Not sure yet. As indicated, compiling the part of my C code after porting from the Commodore original, the size of the binaries are way smaller than I expected, so to do the basic conversion actually I might not need anything in the overlay area, it probably will fit without it.
But I also want to know what is possible, as there are always of course nice to have functions to be build that need additional memory. One function for example that I do now not foresee it be ported is the redo/undo function, which if implemented requires a LOT of memory to be useful. Did allocate 48KiB for that function alone on the C128 original (also as I was using memory for it that only very few 128s actually have, so made it optional and also the reason why I did not want to use that memory for non-optional functions). Which would be rather overkill for the Atmos, but anything less the 8 KiB would make it not really useful.
And it is also good to know for future projects.
(Background to the Commodore 128 original: a standard C128 has 128 KiB of RAM with different portions of ROM banked in at demand. It also has an additional 16 KiB of video memory intended to be used with its VDC 80 column video chip. A specific later and rare model of the 128, the 128DCR which I happen to have, has 64 KiB VDC memory instead of 16 KiB. Intended to enable Hires graphic modes at higher resolution or more colors, but of course usable for other things if you work text mode only. So a Commodore 128 actually has either 144 KiB or 192 KiB of RAM.
Downside of using the VDC video RAM is that it is not directly addressable or bankable. You can only access it via VDC chip register writes, so it is slow and you can not run code from there directly).
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 11:25 am
by iss
Back to @Dbug's idea for SEDORIC + pre-allocated slots: I don't see any drawbacks, it's simply best solution for compatibility and functionality. The sector based routines will be fit in ~1k (or something like that), you can use the RAM-overlay for additional buffers freely because once booted you don't need SEDORIC anymore. Yep, it's bit more work but absolutely straight and doable quickly.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 11:31 am
by xahmol
iss wrote: ↑Fri Jun 10, 2022 11:25 am
Back to @Dbug's idea for SEDORIC + pre-allocated slots: I don't see any drawbacks, it's simply best solution for compatibility and functionality. The sector based routines will be fit in ~1k (or something like that), you can use the RAM-overlay for additional buffers freely because once booted you don't need SEDORIC anymore. Yep, it's bit more work but absolutely straight and doable quickly.
Tend to agree based on my grasp of it so far.
But just to check my understanding:
That would mean that I have to change from this how I now do it:
- being able to save to any filename and with a number of files only limited by disk space any time you want to;
To:
- asking the user to setup the project or load a project at program start, create the pre-allocate slot and afterwards disable all possibility to save to or load from anything but this allocated slot.
Am I right?
Is certainly feasible. But is a major change in the program setup.
Will actually have the added benefit of much less need for error handling on file operations as most operations will be to the predefined file and filename.
Drawback is that when I myself actually use the screen editor (created it for my own use in the first place), I tend to save many work in progress versions in different stages of completion, especially when I can not use a redo/undo function. That would be a problem then if you have to stuck to one predefined slot. Or I could create e.g. 10 slots at project creation.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Fri Jun 10, 2022 2:15 pm
by Dbug
- asking the user to setup the project or load a project at program start, create the pre-allocate slot and afterwards disable all possibility to save to or load from anything but this allocated slot.
Technically a slot is just a track/sector/side location and a length, you can definitely handle many at the same time without any problem.
The only important thing is that these are linear on disk.
If they are not linear on disk, then you need a list of sectors, and these would require decoding the Sedoric structure, or use Sedoric to build it.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sat Jun 11, 2022 8:08 pm
by xahmol
Definitely will investigate.
Noticed again that proper file handling with the Secoric routines I used is almost impossible as in many file errors Sedoric breaks to BASIC, which my C program can not handle. Is quite frustrating if you want to save your project and it breaks in saving due to some user error and you can not recover as it throws you to BASIC.
So using fixed slots already would be great to eliminate user error in file operations.
But will take time.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 12, 2022 10:40 pm
by xahmol
Finished a first complete and working alpha version of my project now: Oric Screen Editor.
To do is documentation/manual and some further bug hunting. Will investigate revamping disk routines for a future version. So beware: this version does not handle file errors well (breaks to BASIC), so safe often if you use this version.
Will release via an own topic if documentation is finished. For now, find out which keys to use by pressing FUNCT+8 to reach the help function (ALT+8 in Oricutron with default key mapping).
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 7:00 am
by Dbug
Nice to have the character redefinition as a part of the main editor, so you can see real time what you are editing
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 7:39 am
by xahmol
Dbug wrote: ↑Mon Jun 13, 2022 7:00 am
Nice to have the character redefinition as a part of the main editor, so you can see real time what you are editing
Well, that, and the possibility to use larger than one screen maps, was the whole reason for me to create the original on the C128 as nothing already existing could do that And needed it for a project.
Original by the way has been much influenced by the CD2 tool of Twilighte that does have the chareditor but not the larger than one screen map.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 7:41 am
by Dbug
You should try to extract some of the Loriciels intro screens and load them in your tool, could be cool to analyze how they are made
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 7:52 am
by xahmol
Dbug wrote: ↑Mon Jun 13, 2022 7:41 am
You should try to extract some of the Loriciels intro screens and load them in your tool, could be cool to analyze how they are made
Have to shamefully admit I never really tried any of the Loriciel titles as they are in French... but good suggestion.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 8:01 am
by Dbug
The main problem is to find versions that still have the intro.
Basically on the real tape, you get a small "error correction" patch, then the intro is loaded (text mode with redefined characters) which acts as advertisement for other games, and then the game.
Most TAP versions only have the game, everything else was stripped out.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 9:01 am
by xahmol
Any suggestion where to find proper images to try? Preferably working in Oricutron to enable extracting stuff from memory?
Do not have any of those original tapes myself (and not very willing to buy them just for this purpose)
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 9:14 am
by Dbug
I checked a couple on Oric.org That one has the intro, but with corrupted graphics...
LORIPJ.BIN is project meta data
LORISC.BIN is the screen
LORICA.BIN is the alternate charset
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 12:16 pm
by Dbug
Cool
That actually make sense they used the ALT charset, because that's located just before the TEXT mode so it can be loaded in one single block with the font before the image
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 1:19 pm
by xahmol
By the way: to manage expectation about what my tool can do: had to do preprocessing for my tool to load this.
Actually used Oric Explorer on the .tap to view the different files and see where the screen and charset were located. Oric Explorer has a very convenient text and charset viewer included.
With a hex editor on my Windows PC extracted those portions as a binary file to transfer to an Oric DSK.
Dbug wrote: ↑Mon Jun 13, 2022 12:16 pm it can be loaded in one single block with the font before the image
That is indeed exactly what it does
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 8:05 pm
by ibisum
I cannot explain how beautiful and fulfilling this is. Honestly, this is a tool that I've wished for on Oric for decades.
Wow.
Would be really cool to use it to write code too, though. Got space left for scrolling and word operations?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 8:29 pm
by Symoon
Dbug wrote: ↑Mon Jun 13, 2022 9:14 am
I checked a couple on Oric.org That one has the intro, but with corrupted graphics...
Just for the record regarding J'Apprends La CAO: this is the original program corruption, not Oric.org's
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 13, 2022 8:53 pm
by xahmol
ibisum wrote: ↑Mon Jun 13, 2022 8:05 pm
Would be really cool to use it to write code too, though. Got space left for scrolling and word operations?
No space left alas unless I work the alternative disk operations out and regain the overlay RAM by ditching SEDORIC. Had already to decease my windows buffer somewhat to make room.
Source code however is public at https://github.com/xahmol/OricScreenEditor , just made it public to be able to link the screenshots to the .md file also locally. Documentation needs to be transferred from Commodore to Oric still though, presently only did the screenshots and a search replace from TED (the Commodore Plus/4 video chip) to Oric.
Scrolling routines are already in https://github.com/xahmol/OricScreenEdi ... assembly.s
Probably they can be way more optimised though, writing for speed and size is not really my forte yet with my still novice assembly skills.
Feel free to send me PR for suggestions and to build upon this code.
Meanwhile the code has still more gremlins than I would like to, especially by lack of any error handling in file operations. So consider this an alpha version that is functional and usable (use it myself to make the help and title screen), but will also sometimes frustrate by loosing some of your unsaved work. Did kink already a lot of it out, but not sure I got it all yet, nor if I will be able to fully solve on short notice.
Suggestions always welcome of course.
Re: Using overlay memory: how, tips and possibility for direct save/load
php ; Push program counter
plp ; Pull program counter
php and plp are not related to the program counter, they push and pop the status flag (zero, carry, binary mode, ...) including the IRQ flag, so if you do
then you will be back to whatever the I flag value was from before php
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 14, 2022 8:53 am
by xahmol
Thank. Did found that out before in this topic, but forgot to delete this code as I now not use it yet as I still need SEDORiC.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 14, 2022 11:19 am
by iss
Congrats! Cool program and can be useful!
My 2 cents:
- turn off keyboard clicks (or set short key to switch it off/on);
- make selection tool to work not only from top-left to right-down;
- nice to have IJK-joystick
btw, github contains BAT files for OSDK but they are not for OSE.
Do you use cc65 optimization flags (i.e. -Oirs)?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 14, 2022 1:23 pm
by xahmol
iss wrote: ↑Tue Jun 14, 2022 11:19 am
Congrats! Cool program and can be useful!
My 2 cents:
- turn off keyboard clicks (or set short key to switch it off/on);
- make selection tool to work not only from top-left to right-down;
- nice to have IJK-joystick
btw, github contains BAT files for OSDK but they are not for OSE.
Do you use cc65 optimization flags (i.e. -Oirs)?
Correct, I need to clean the git, the BAT files are still from when my building chain was Windows based instead of Linux. Forgot to delete them.
I do use optimalisatie flags, indeed -Oirs
Keyboard clicks: good one. If you followed this forum you might have read that I accidentilately blew my internal speaker of my Oric, so do not hear them unless I connect external speakers, and also on the PC I normally work with sound muted. So did not notice. Will do, that one is easy.
IJK joystick: thought of joystick support, but because a joystick can only move and confirm and can never take over the rest of the functions that rely heavily on keyboard, for me it did not add much as you than continuously have to use keyboard anyway to do anything else but cursor movement. That is why I choose not to do it, also because it makes keyboard routines much more complex if you have to poll both keyboard and joystick. For starters as you then actually have to write code instead of just using cgetc().
Would of course be different in a full GUI, but as long as this is text based, doing everything with pull down menus would quickly be cumbersome, certainly without a mouse.
Selection not only from the top-left down: tried to do that at first, but got stuck on the surprisingly bad added complexity of that. Code went haywire at the time by negative offsets to original co-ords. But now think to remember that most of my issues at that time were quite specific to how the VDC chip of the Commodore 128 does thinks.
So maybe will take a shot at retrying for a in that sense much simpeler platform which is the Oric. Also as I now maybe realise where I at that time went wrong: was working with negative offsets to the start point, where I now think moving the start point on moving left or up is probably much better.
So will note as a feature request to consider and investigate feasibility as I do agree it would be very handy to have.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 15, 2022 9:48 am
by xahmol
Update with new version incorporating suggestions from Iss:
iss wrote: ↑Tue Jun 14, 2022 11:19 am
- turn off keyboard clicks (or set short key to switch it off/on);
Done. Keyboard click sounds should now be gone (they are at least here in Oricutron)
iss wrote: ↑Tue Jun 14, 2022 11:19 am
- make selection tool to work not only from top-left to right-down;
Done.
Proved to be very easy to do once I realised how to do it: Moving starting point of selection instead of doing complicated with end values smaller than the startvalue. Especially the latter made code very complex and almost impossible on C128 as the VDC chip auto increases addresses to the right on every write so writing right to left is very cumbersome. But if you move start point instead that immediately solves all issues as in the rest of the code you still write from left to right and from top to down.
Thanks for the suggestion, as I now will also port back this improvement to my Commodore targets.
iss wrote: ↑Tue Jun 14, 2022 11:19 am
- nice to have IJK-joystick
Not done (yet at least). Can of course be done, but polling joystick and keyboard at the same time adds complexity and looses responsiveness that for me does not weigh against the limited use a joystick would be here as you still need keyboard to do anything but move.
Will consider if also other people request it. So far nobody asked for it for the reasons I describe on the Commodore targets earlier.
iss wrote: ↑Tue Jun 14, 2022 11:19 am
btw, github contains BAT files for OSDK but they are not for OSE.
Deleted the .bat files from the git, also cleaned the assembly source of parts I do not use anymore (or at least not yet). Old versions are still in the git for potential future use.
No time now for a separate release post in an own topic, will probably be tomorrow.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 15, 2022 4:23 pm
by iss
Great improvement! Congrats.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 15, 2022 5:39 pm
by Dbug
I wonder if it would make sense to provide a few "built-in" sets of fonts that the user could select, like some variants of the PETSCII, or fonts inspired from various other systems
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 15, 2022 6:26 pm
by xahmol
Dbug wrote: ↑Wed Jun 15, 2022 5:39 pm
I wonder if it would make sense to provide a few "built-in" sets of fonts that the user could select, like some variants of the PETSCII, or fonts inspired from various other systems
Would certainly make sense if somebody artistically better than me can do good 8 to 6 bit width conversions…. Especially doing PETSCII right with two pixels less will be a challenge to make it still look right.
The number of characters available will not be a problem as the C64 can show only one charset at once and has no hardware reverse. So while you can define 256 characters, most C64 charsets use 128 chars plus the same 128 reversed.
As the Oric can use 96 plus 80 = 176, plus hardware reverse, that actually gives more room. (In black and white at least, hardware reverse in colour might actually be an issue on petscii as of course the colour changes completely differently in reverse on the Oric than on the Commodore).
Of course, the Oric way of serial attributes would then again be a nightmare doing PETSCII art.
By the way, I am very happy to see that at least one PETSCII artist actually is using the C128 version of my tool and creating this using only PETSCII, no redefined chars: https://csdb.dk/release/?id=218476 https://csdb.dk/release/?id=215305
(He gave also a LOT of valuable feedback on the tool, inspiring me to add for example palette mode and the visual charmap option)
The C128 by the way can in 80 column mode show two charsets of 256 visible chars at the same time on a 80x25 screen and does have hardware reverse ( plus underline and blink ) and seperate attribute memory like all Commodores after the VIC-20.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 10:30 am
by rax
Congratulations!
It looks quite good and functional.
Dbug's idea for PETSCII is interesting too.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 2:49 pm
by xahmol
Actually now have a more or less conversion of a PETSCII font for the Oric. Will upload soon.
Tried first resizing
Meanwhile also studying the Pinforic code for sector based and write and hope te experiment with that soon and decide if it is implementable in a first release or that I formally release for that in version 2.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 4:35 pm
by iss
Maybe you will find useful 'Oric Fonter' with some sample fonts.
It's just viewer but helps me lot when browsing font for projects...
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 5:07 pm
by xahmol
Found that one. But it seems to do only the standard charset, not the alternate one or combined? Or do I miss something?
Anyway: showing fonts is a capability that my own tool now also have, so use that. The palette view shows both standard and alternate charset.
And for showing (and editing) C64 charsets a plethora of great tools exist. Used http://petscii.krissz.hu/ now, also because I used the visual grouping used there.
Tried to put the PETSCII chars primarily in the alternate charset, as if possible I would like to keep lowercase next to uppercase chars (the full PETSCII charset only has uppercase), while doing some chars in reverse also as hardware reverse on the Oric also changes the colors if not in black and white or needs a paper and ink change.
Did conversion by hand as resizing in Photoshop automatically from 8 to 6 pixels gave very ugly results. Can doubtlessly be improved though.
Placed the PETSCII characters not by the original C64 key or code it was on, but placed it grouped for better visual character selection.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 5:14 pm
by xahmol
By the way: maybe n00b question, but why did the Oric designers ever thing chars of 6 by 8 instead of 8 by 8 by all competition was a good idea?
If the reason was the max number of horizontal pixels, why then not just choose a 32 char wide screen like also some other computers did?
Especially combined with the relatively tall 27 lines height. The combination give that weird non-square pixel aspect ratio of a real hardware Oric. Which unfortunately Oricutron does not emulate in windowed mode.
A 32 by 24 screen would have made screen addressing also so much easier using full 256 bytes pages.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 5:30 pm
by Chema
It was, I think, mostly for the serial attributes approach. Some bits in each byte are needed to indicate if it is graphical data or a serial attribute. This saves memory, but is very limiting and a nightmare to deal with.
On the other hand, the designers forgot to add a 320x200 monochrome mode. One simply removing serial attributes and taking the 8 bits as graphical data.
By the way, oricutron can emulate the aspect ratio in windowed mode if you change the video render mode and select stretch, as well as it can add scan lines.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 5:39 pm
by xahmol
Chema wrote: ↑Tue Jun 21, 2022 5:30 pm
By the way, oricutron can emulate the aspect ratio in windowed mode if you change the video render mode and select stretch, as well as it can add scan lines.
Ok, tried that, so good to know it should work. It crashes for me using the latest Linux build of Oricutron though under WSL2 with Ubuntu on Windows 11. But that could of course be a bug in the still very new graphical UI support for WSL2 in Win11.
Crashes directly on trying to change video render mode. Will try that in the Windows version then. Use the Linux version now mainly as I invoke it directly from my Makefile (make run). But cool thing of the new WSL2 is that I now actually can run the Windows and Linux version of Oricutron now in two windows next to each other on the same machine effortlessly (apart from the crashing that is )
And indeed, the serial attributes are a nightmare doing PETSCII art.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 21, 2022 9:02 pm
by xahmol
Testing the PETSCII Oric font, also showing Oricutron for Linux and Windows running next to each other.
Stretch indeed works in the Windows version.
Font in the palette viewer:
Re: Using overlay memory: how, tips and possibility for direct save/load
If I read this code, then I do not understand how it can work as it indeeds seems to have an endless loop to microdisc_read_data. Unless the interrupt is doing something I do not understand and do not get to work either.
Also do not understand what this is doing in the code:
So, start to conclude I probably know too little to use this code.
Any other examples of doing sector based reads and writes for Microdisk Oric disks? Basically the only thing I need is to be able to read and write to a specified sector on a disk preformatted with the proper files. So no need for any file handling, just the need to write to the sectors that already existing file is using, with the track and sector number provided by the programmer.
Otherwise I probably will stop exploring this for now and release OSE as it is.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 3:30 pm
by Dbug
I've not used this particular routine myself, but from what I understand this specific set of routines do REQUIRE the specific IRQ handler that comes with it.
Basically if you look at "fdc_irq" you see that it does three PLA instructions and quits with a RTS instead of a RTI, so what it basically does is to short-circuit the return location to not be where it came from (which is the microdisc_read_data) but the actual caller:
jsr readwrite_data
lda __status <- returns here
beq success
The horrible ".dsb 4-(*&3),$ea" are there to add NOPS (the EA opcode) before the access to the FDC register, because the Telestrat disk controller is buggy and does not behave properly when these registered are accessed on a memory address not multiple of four.
So basically all this .dsb does, is tro write a variable number of $EA bytes depending on how many are required.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 3:48 pm
by xahmol
Ok, thought it was indeed already the IRQ handler that should be ending the loop. Problem is, with using this same code at my end it does not, so I obviously made a mistake somewhere, and lack knowledge to solve it.
Will have another fresh look another time, but meanwhile if somebody has other code that does what I search for, love to hear it.
Will only support Microdisc for now, so all Jasmin and Telestrat code can come later if I first get Microdisc working.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 3:55 pm
by Dbug
Are you sure that the IRQs are enabled during the reading/writing loop?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 4:08 pm
by xahmol
Dbug wrote: ↑Sun Jun 26, 2022 3:55 pm
Are you sure that the IRQs are enabled during the reading/writing loop?
That is indeed something that I wanted to double check with a fresh look. Suspect that I mangled the code somewhere in trying to make it work in my code, so to ditch all machine independent stuff (as setting up the machine type variable as the Pinforic code does poses an issue) and convert away with using a C lib to just independently called assembly with a C wrapper function.
Must have done something wrong there, or, now that I write it, CC65 IRQ handling might also be interfering. Probably needs more diving in to then.
There is no way to do it without setting a separate IRQ handler?
(But away from my Oric for now. Have to prepare diner and family stuff)
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 4:54 pm
by xahmol
I begin to have a suspicion that the problem might be as basic as indeed removing the machine independent stuff wrong and thus wrongly sett8ng the fdc_offset variable. Will try again when I have time.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 6:12 pm
by iss
@xahmol: Try with Chema's Blake's7 sources and FloppyBuilder. These routines are working well for Microdisc and this is the best variant so far .
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 6:19 pm
by Dbug
iss wrote: ↑Sun Jun 26, 2022 6:12 pm
@xahmol: Try with Chema's Blake's7 sources and FloppyBuilder. These routines are working well for Microdisc and this is the best variant so far .
It's true that the Pinforic code is quite old, and using IRQ for disk handling makes things quite more complicated, the non IRQ version is much easier to understand
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 6:21 pm
by xahmol
iss wrote: ↑Sun Jun 26, 2022 6:12 pm
@xahmol: Try with Chema's Blake's7 sources and FloppyBuilder. These routines are working well for Microdisc and this is the best variant so far .
Thanks, will have a look. On first glance of course looks much simpler.
But just to check: FloppyBuilder created disks are not showing standard SEDORIC files that can be copied to other disks or extracted with for example OricExplorer, right? Ask because of course the whole purpose of a screen editor is that you can actually copy your finished work from the work disk to somewhere else.
Then again: I assume that the read and write sector assembly routines would work also on a Sedoric disk if provided the correct track to get or write the data from or to?
By the way: I see that this Blake7 source only has code for reading a sector, not writing one. Am I correct to assume the code for writing would be the same, just with the write command given to the FDC instead of read?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 7:32 pm
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.
; 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
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 8:38 pm
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)
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 8:47 pm
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 8:55 pm
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!
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 9:32 pm
by iss
Well, let's finish this project .
I've just updated oricOpenLibrary with new library: lib-basic .
It's just one function like:
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
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 9:54 pm
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Jun 26, 2022 11:02 pm
by iss
Can you share roughly current memory map?
Maybe there should be easy and elegant solutions without the 16k overlay.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 12:04 am
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.
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
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 11:10 am
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:
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?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 11:14 am
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 11:17 am
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 12:19 pm
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
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 12:30 pm
by iss
iss wrote: ↑Mon Jun 27, 2022 12:19 pm
- reconsider again the power of the 'basic' function from my previous post
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 1:31 pm
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.....
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 3:36 pm
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?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 3:59 pm
by 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...
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 4:19 pm
by xahmol
iss wrote: ↑Mon Jun 27, 2022 3:59 pm
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 5:33 pm
by Dbug
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.
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 6:36 pm
by xahmol
Dbug wrote: ↑Mon Jun 27, 2022 5:33 pm
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Jun 27, 2022 9:08 pm
by 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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 28, 2022 9:00 am
by 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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 28, 2022 9:14 am
by iss
Dbug wrote: ↑Tue Jun 28, 2022 9:00 am
... 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
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 28, 2022 10:07 am
by xahmol
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.
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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 28, 2022 10:45 am
by 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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 28, 2022 4:47 pm
by 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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 28, 2022 5:10 pm
by iss
xahmol wrote: ↑Tue Jun 28, 2022 4:47 pmBy 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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Tue Jun 28, 2022 5:12 pm
by 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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 29, 2022 10:38 am
by 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.
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
$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?
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 29, 2022 11:43 am
by Dbug
xahmol wrote: ↑Wed Jun 29, 2022 10:38 am
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
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 29, 2022 11:53 am
by 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.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 29, 2022 12:08 pm
by xahmol
iss wrote: ↑Wed Jun 29, 2022 11:53 am.
Good news for Sedoric I/O - at $4FD is the result code from last operation: if it's 0 (zero) - no error.
Saw that, but that does not help much if SEDORIC first throws you to BASiC on e.g. a file not found. C code can not recover from that (or do I miss something?)
Ideal would be to hijack ERRGOTO in a way.
Also, the SEARCH command is interesting before you save a file to see if an existing one exists , so you can ask the user if overwrite is OK.
In BASIC, this returns a 0 or 1 value on the variable EF. Was wondering: will setting that variable be destructive for C code as of course that EF var8able is stored somewhere? But also: would it be possible to read that variable from C code?
Because that would enable a File exists dialogue (that I do have in my Commodore targets).
Looking at the SEDORIC code for SEARCH, I could of course just patch that command again to store it at a memory location instead of EF:
E608 A9 01 LDA #01 A = #01 (pour "trouvé")
E60A 4C D5 D7 JMP D7D5 et dans les deux cas, continue en D7D5 où la variable EF (Existing File) reçoit A (0 si "non trouvé",1 si "trouvé"). Pour le traitement logique du résultat de la recherche, il faudra donc demander IF -EF THEN... et non IF EF THEN...
and patch the jump to D7D5 with a jump to an own handler.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 29, 2022 2:28 pm
by xahmol
Progress: managed to reroute the SEDORIC output to screen by indeed patching.
Started with a small Proof of Concept to reroute output to the $9000 memory area, and that works! Needed that to exactly see the output steam format.
DOSROM = $04F2 ; Call to function to disable/enable SEDORIC RAM
_DOSERROR = $04FD ; Disk error address
SED_PRINTCHAR = $D20F ; SEDORIC print character patch address
SED_XROM = $D5D8 ; SEDORIC default jump address before patch
; Disk directory parser routines
; ------------------------------------------------------------------------------------------
_ORIC_DIRParse_start:
; Function to enable directory parser and reroute screen output while DIR is executed
; Input:
; ------------------------------------------------------------------------------------------
; Enable overlay RAM
jsr DOSROM ; Call function to toggle overlay RAM
; Patch SEDORIC print character function
lda #<ORIC_DIRParse_process ; Get low byte of parsing function
sta SED_PRINTCHAR ; Store at patch address
lda #>ORIC_DIRParse_process ; Get low byte of parsing function
sta SED_PRINTCHAR+1 ; Store at patch address
lda #$60 ; Load $60 for oppcode RTS
sta SED_PRINTCHAR+2 ; Store RTS at patch location
; Disable overlay RAM
jsr DOSROM ; Call function to toggle overlay RAM
lda #$00
sta dirparse_automodify+1
lda #$90
sta dirparse_automodify+2
rts
; ------------------------------------------------------------------------------------------
_ORIC_DIRParse_end:
; Function to disable directory parser and reroute screen output while DIR is executed
; Input:
; ------------------------------------------------------------------------------------------
; Enable overlay RAM
jsr DOSROM ; Call function to toggle overlay RAM
; Patch SEDORIC print character function
lda #<SED_XROM ; Get low byte of parsing function
sta SED_PRINTCHAR ; Store at patch address
lda #>SED_XROM ; Get low byte of parsing function
sta SED_PRINTCHAR+1 ; Store at patch address
lda #$12 ; Load original value
sta SED_PRINTCHAR+2 ; Store RTS at patch location
; Disable overlay RAM
jsr DOSROM ; Call function to toggle overlay RAM
rts
; ------------------------------------------------------------------------------------------
ORIC_DIRParse_process:
; Function to intercept the system char to screen routine
; Input: Parses inout character stream via the X register
; ------------------------------------------------------------------------------------------
dirparse_automodify:
sta $9000
inc dirparse_automodify+1
bne dirparseend
inc dirparse_automodify+2
dirparseend:
; Jump to XROM routine to return to SEDORIC gracefully
jsr SED_XROM ; Jump to XROM routine
.byte $10,$cd,$10,$cd ; Data for XROM
rts
So, from here, a DIR parser should not be difficult anymore if I take only disks with this specific DIR layout as requirement.
(PS: Quickly noted that in the parser function, the use of zero page variables is to avoided, as the program went completely crazy ;- Apparently SEDORIC uses the same ZP addresses, but safeguards those on entering SEDORIC functions to restore afterwards)
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 29, 2022 2:38 pm
by Dbug
xahmol wrote: ↑Wed Jun 29, 2022 12:08 pm
Saw that, but that does not help much if SEDORIC first throws you to BASiC on e.g. a file not found. C code can not recover from that (or do I miss something?)
Ideal would be to hijack ERRGOTO in a way.
Have you found out how it gets back to BASIC?
Technically you can redirect the "Ready" prompt to call some code, it's often used as a protection in BASIC programs to call the reset routine when going back to the prompt:
DOKE(#1B,DEEK(#FFFC))
Technically you could replace this vector by a way to recover from errors, but I don't know what the status of the stack, etc... would be.
I guess technically the Sedoric/Basic wrapper could do something like having a small function designed to restore the stack pointer value and jmp to the end of the Sedoric function caller, and before calling Sedoric modify #1B-1C to point to this function and set the right stack value to restore to.
If the code does not crash, nothing happen, if it does crash, it would auto-jump to the crash handler, restore the stack, and jump back to continue running the code.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Jun 29, 2022 2:50 pm
by xahmol
Dbug wrote: ↑Wed Jun 29, 2022 2:38 pm
Have you found out how it gets back to BASIC?
Affiche le message "DISP_TYPE_MISMATCH"
Puis réinitialise la pile, affiche "_ERROR" et retourne au "Ready"
D16F- A9 A3 LDA #A3 pour le message "DISP_TYPE_MISMATCH_ERROR" (bogue: LDX)
D171- 20 D8 D5 JSR D5D8 XROM exécute à partir de la RAM une routine ROM
D174- 85 C4 7E C4 adresse ROM 1.0 adresse ROM 1.1 (affiche le message)
So, apparently it jumps to C47E, which is indeed the standard Oric Atmos ROM routine to print error messages (apart from skipping the first LDX) and return to BASIC (and indeed seems to clear stack and everything):
PRINTERROR
$C47C A2 4D LDX #$4D PRINT ERROR MESSAGES
$C47E 20 2F C8 JSR $C82F Reset output to screen.
$C481 46 2E LSR $2E Reset CTRL O.
$C483 20 F0 CB JSR $CBF0 Move to start of next line.
$C486 20 D7 CC JSR $CCD7 Print "?" on screen.
$C489 BD A8 C2 LDA $C2A8,X Print error message on screen
$C48C 48 PHA until last char which has bit
$C48D 29 7F AND #$7F 7 set. X holds initial offset
$C48F 20 D9 CC JSR $CCD9 into error table at start of
$C492 E8 INX routine.
$C493 68 PLA
$C494 10 F3 BPL $C489
$C496 20 26 C7 JSR $C726 Reset 6502 stack etc.
$C499 A9 A6 LDA #$A6 Print "ERROR" after the
$C49B A0 C3 LDY #$C3 message.
$C49D 20 B0 CC JSR $CCB0
$C4A0 A4 A9 LDY $A9 If high byte of line number
$C4A2 C8 INY is #FF then the computer is in
$C4A3 F0 03 BEQ $C4A8 immediate mode (not program).
$C4A5 20 BA E0 JSR $E0BA Print "IN (line number>"
BACKTOBASIC
$C4A8 4E 52 02 LSR $0252 RESTART BASIC
$C4AB 46 2E LSR $2E Clear pending ELSE, CTRL O
$C4AD 4E F2 02 LSR $02F2 and LIST/EDIT flags.
$C4B0 A9 B2 LDA #$B2
$C4B2 A0 C3 LDY #$C3
$C4B4 20 1A 00 JSR $001A Print "Ready"
See only in the SEDORIC code that it does not use just one single routine or ROM entry point, references to "retourne au Ready" are all over the place, using also different ROM entry points.
For example, here entry point in ROM at C4A0, so few lines further, probably becasue SEDORIC already printed its own error message (p 187):
Retourne au Ready après affichage d'un message d'erreur
D154- 20 D8 D5 JSR D5D8 XROM exécute à partir de la RAM une routine ROM
D157- AD C4 A0 C4 adresse ROM 1.0 adresse ROM 1.1
D15B- 60 RTS
So have to try, that one on p 187 seems to be the most promising entry point for patching, but there it is already to late to have SEDORIC print its own error message. Think then I have to find wherever it actually prints those error messages and patch already there.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Sun Aug 14, 2022 4:37 pm
by xahmol
Took a while for an update due to COVID (caught an infection last month and limited retro time as I practiced self isolation in home to avoid the rest om my family catching it) and holiday in France (luckily recovered with proper quarantine length in time). So only this week back to my retros since a month.
Also have been struggling to get that dirparser working. But alas gave up for now. Feel I was almost there as I saw things happening, but for some reason I caught most chars right but some not and for me in an unpredictable way. So that broke all my parser attempts.
I am sure it can be done because I feel I was so close, but also do not understand at all what went wrong, so decided to leave it for now.
Copying directly to memory was working fine, so think my routines became either too complex, took too long or I made some error somewhere. Of course copying the dir to memory would also work if only I had enough memory left for it to copy to. But have not that much memory to spare.
As I do want to release some version soon, I proceeded with a dir based file picker purely from the BASIC screen output. Which works great, so long you do not place too many files on the disk that would make the dir scroll the screen.
Attached new build, will release soon after seeing feedback and suggestions in this thread first (if any). This disk image also contains my attempt at a PETSCII charset, the screen, standard and alternate charsets are on the disk (the PETSCII**.bin files) with a project file (PETSCIIPJ.bin to load all at once).
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Aug 15, 2022 6:19 am
by coco.oric
Hello,
@xahmol :
If you've a lot of files, may be it's an opportunity to install OSE with a sedoric 4 OS which allows directories, and for example let user using one for charsets, one for screens ...
Re: Using overlay memory: how, tips and possibility for direct save/l
Posted: Mon Aug 15, 2022 6:42 am
by xahmol
Well, as long as the Tap2DSK tool is creating SEDORIC3 disks, using SEDORIC4 is not very practical as I then have no way of creating them autimatically in a build chain…. Or do you have a suggestion how to create SEDORIC4 discs automatically from the command prompt?
Next to that, the way now implemented of choosing files from having the BASIC dir command printing the dir on screen will certainly not work with subdirs, so that would actually get me farther from a solution than closer. Maybe that could be solved by forcing only a fixed dir structure indeed, so only supporting screens in a dir called screens and such, but that will come at the cost of being way more cumbersome on getting files to not standard OSE system disks.
Also, my issue is not that I have too many files already, more that I now have to warn users not to place too many .BIN files on disk as that will break the file picker.
(But curious for suggestions to create SEDORIC4 discs anyway)
Re: Using overlay memory: how, tips and possibility for direct save/lo
Posted: Mon Aug 15, 2022 7:04 am
by xahmol
Hmm, thinking of it, traversing subdirs down and up should be doable in the file picker: just do a new BASIC dir command if a dir is recognised on selection.
Would only still break if the subdir has too many files, with the downside of then needing to suppprt different versions of DIR output for different SEDORIC versions If I do not stick to just Tap2dsk created disks. Would make things much more complicated and still not completely take away the issue.
(But more important question is still how to include SEDORIC4 in an automated build chain, as copying the files to a SEDORIC4 disk manually on every build is extremely unpractical)
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Aug 15, 2022 7:30 am
by Dbug
xahmol wrote: ↑Sun Aug 14, 2022 4:37 pm
Feel I was almost there as I saw things happening, but for some reason I caught most chars right but some not and for me in an unpredictable way. So that broke all my parser attempts.
I am sure it can be done because I feel I was so close, but also do not understand at all what went wrong, so decided to leave it for now.
Copying directly to memory was working fine, so think my routines became either too complex, took too long or I made some error somewhere.
Do you have the code of the parser somewhere so we can take a look at it?
Re: Using overlay memory: how, tips and possibility for direct save/load
And then specifically these parts:
_ORIC_DIRParse_start_core:
DIRParse_nextX:
DIRParse_Stormem:
_ORIC_DIRParse_end:
ORIC_DIRParse_process:
It is not complete yet as I thought already I still miss a phase (skip from the right column to the left), but I think the first thing to understand is why solely capturting the dir to memory (did so for testing purposes in a memory area I actually can not miss, but wanted to see if the raw input was received correctly). This is the DIRParse_Stormem function that is called first in ORIC_DIRParse_process.
In memory I see this dump:
Schermafbeelding 2022-08-15 085609.png (10.09 KiB) Viewed 2685 times
Compared to this actual dir just in BASIC on screen:
Schermafbeelding 2022-08-15 091030.png (11.56 KiB) Viewed 2685 times
First thing I encounter is that the coloured part of the disk name gives output with escape codes ($1B) instead of just attribute values that can be plot directly. So have to figure that one out, as I assume that the number of escape codes will differ from dir to dir, so might be different on reading other disks. Parked that one for later if I can get the rest working.
But more worrying is that somehow the output of the filenames seems to be inconsistently weird sometimes in the extensions.
See:
- on the first file OSEHS1.BIN the extension suddenly misses a dot, but more worryingly, there is a weird sequence of 0D 08 2E 06 20 40 4F behind the BIN that I really can not place and do not see further on. $0D is an ENTER, weird, as it should keep printing on the same line, see output in plain BASIC. $08 is a backspace, why? And why does it do that here, but with further files sometimes (not always) that $0D but not the rest?
- On the second file OSEHS2.BIN there is suddenly a dot within the .BIN extension instead of before (so B.IN instead of .BIN)
The code to print things to screen is also far from functional still. It also is not complete and WIP yet as I know I still miss a phase (skipping chars going from right column to left column again). But solving the bugs that must be there is rather pointless if I can not understand what is happening with those irregularities in the raw stream in the first place, as my parser logic only works if distances between two file names are always exactly the same or at least follow a standard predictable pattern.
That is why I for now gave up on this rote, and reverted to the simple way of not interfering with the DIR output, Which works great with the caveat of breaking on too many files.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Aug 15, 2022 9:44 am
by Dbug
Will require some reading, but I can already say that there's a much easier way to handle your state machine, which would also end up being much faster code.
lda DIRParse_Phase ; Check phase
; Check for phase 0: skip first header and disk name
cmp #$00 ; Compare for phase 0
bne DP_phase1 ; Go to next check
jmp DP_skipheader ; Branch to skip header if phase 0
DP_phase1:
; Check for phase 2: print filename left column
cmp #$01 ; Compare for phase 2
bne DP_phase2 ; Go to next check
jmp DP_printleftcolumn ; Branch to read disk name if phase 2
(...)
DP_phase4:
; Check for phase 5: print filename right column
cmp #$04 ; Compare for phase 5
bne DP_phase9 ; Go to next check
jmp DP_printleftcolumn ; Branch to read disk name if phase 5
You can instead use either a pointer in zero page or a self-modified jmp that points to the code to run in the next phase, and all you need to do is to have the previous phase change the pointer to point to the next code to run, so "header" changes it to "print left column" which itself changes it to print right column, etc...
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Aug 15, 2022 11:02 am
by xahmol
Makes sense DBug. Using zero page I want to avoid because I already had conflicts with the SEDORIC code when I tried that (and safeguarding ZP values every time will certainly make the code slower), but self modifying is certainly possible. Good suggestion.
However, if I do not first solve why the data stream coming in is irregular.. Maybe will revert back to just one phase with just a memdump first to see if too complex / slow code effects this data stream. If yes, your suggestion could indeed help. If not, there is some other issue to solve first.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Aug 15, 2022 11:18 am
by Dbug
To test the speed theory, one thing you could do is to keep the byte fetcher hook, but just have it call the original function directly (check that it still works fine), then add a delay loop, and increase the value until it stops working.
If it gets slow without even stopping to work, it means it's probably not a performance related issue.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Mon Aug 15, 2022 11:49 am
by xahmol
Dbug wrote: ↑Mon Aug 15, 2022 11:18 am
To test the speed theory, one thing you could do is to keep the byte fetcher hook, but just have it call the original function directly (check that it still works fine), then add a delay loop, and increase the value until it stops working.
If it gets slow without even stopping to work, it means it's probably not a performance related issue.
Good suggestion. Will do.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Aug 17, 2022 11:08 am
by xahmol
Update: found the cause of the inconsistent byte grabbing. It was not the speed of the code that was the issue, it was that apparently that SEDORIC routine really does not like if you change the X register
Did as suggested: first just a byte grabber, nothing else. Works fine, consistent stream caught.
Then added delay as suggested by having an ldx dex bne loop. Was giving all kind of funny results even with a delay of ldx #$01 (so really no delay with the dex right after).
Added now safeguards to (to be sure) safeguard processor state, A, X and Y registers. And now it seems to work even with a delay ldx $ff.
So will now proceed with the actual parser. Which by the way I already found could never work also because I forgot to actually increase the X coordinate after plotting (duh.....) so every character would be plotted at exactly the same spot. Keep you posted. Will incorporate DBugs suggestion on auto modifying jump addresses.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Aug 17, 2022 12:05 pm
by Dbug
xahmol wrote: ↑Wed Aug 17, 2022 11:08 am
Update: found the cause of the inconsistent byte grabbing. It was not the speed of the code that was the issue, it was that apparently that SEDORIC routine really does not like if you change the X register
*kaboom*
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Aug 17, 2022 5:03 pm
by xahmol
Great progress: disk parser almost works!
It now works great on the OSE system disk:
Routine now puts its output where the program wants it, can fit a lot more files by having three columns instead of two (gaining the space by skipping the extensions and file block lengths) and even if there are to many files, it just ignores the files that do not fit on the screen instead of screwing everything up by scrolling.
Not entirely there yet though as I found out that it does not correctly parse two other disks I tried purely by parsing the diskname not entirely correct. Which is almost certainly caused by me not implementing the logic to deal with the fact that colours are allowed in the disk name and that SEDORIC outputs escape codes for that. I see that my logic dealing with escape codes goes wrong in the charcounter. So should be easy to solve, but takes more time to analyse than I have today, so leave that for another day.
Also noticed that I work very close to completely full memory (had to do already some hack to deal with being just 54 bytes short), so have to extensively test if all the rest is still working and not having quirks by memory errors.
But excited I already got so far! The rest should be easy.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Aug 17, 2022 8:49 pm
by xahmol
Yay! Seem to have solved also that final issue. Found that also the escape chars count in the character count (which of course does make sense, else a diskname with colours would take more room than one without). Also forgot to actually adjust string length in C for it, so it had no trailing zero to find, which of course creates some printing mess.
I have tested it now with many of my TAP2DSK images. which all parse correctly.
SEDORIC4 images as exected create an utter mess. but preventing let alone solving that mess is more than I can hope to do in the memory still left. So will leave it with a warning, do not try to use SEDORIC4 discs.
DiskBuilder images also create utter mess, so do not try that
Tried one non TAP2DSK SEDORIC3 image. Aigle d'Or, that one parsed correctly mostly but end of dir could not be detected. Now scan for an asterix in the **xx sectors free, but Aigle d'Or image had 1115 sectors free and starts not with an asterix. That is an issue, as I do not know yet how to distinguish that that 1115 is not a filename but end of dir without making the logic WAY more complex.
So certainly for now I will definately stick with documenting the limitation that only TAP2DSK created images are supported, anything else almost certainly will not work and breaks the program. Good enough for my own uses for sure.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Wed Aug 17, 2022 8:59 pm
by xahmol
Video demo:
Recorded from a real Oric Atmos and Cumana Reborn, so yes, it works on real hardware as well At me at least.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Thu Aug 18, 2022 7:01 am
by Dbug
Glad you managed to solve it
If there's one thing maybe, I find it disturbing that the selected menu item loses the highlight color when you show the menu list, would be nicer I think if the "File" background stayed white when the Save screen/Load screen/Save Project... options are displayed (@ 0:33)
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Thu Aug 18, 2022 7:05 am
by xahmol
Dbug wrote: ↑Thu Aug 18, 2022 7:01 am
the selected menu item loses the highlight color when you show the menu list
Good one. Will look at it and see if that is an easy fix (which I think and hope) or not.
Re: Using overlay memory: how, tips and possibility for direct save/load
Posted: Thu Aug 18, 2022 8:13 am
by xahmol
Dbug wrote: ↑Thu Aug 18, 2022 7:01 am
the selected menu item loses the highlight color when you show the menu list
Solved.
Will post the new image on release, but Github already updated.
EDIT: Hmm, to quickly, this gives another issue of the menu option staying highlighted if you move left/right from the pulldown to another menu option. So needs another fix
EDIT2: Also solved. Although code gets slightly longer with every fix
And needed it for a project.
.
