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

[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

[xahmol]

Thanks, very clear!

One question remaining: is it possible to show/dump overlay RAM area memory contents in the Oricutron monitor for debugging?

[iss]

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):

Code: Select all

/***************************************************************************************************************************************
 * ; $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).

[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.

[polluks]

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

[xahmol]

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.

[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.

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

[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?

[Symoon]

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.

[Dbug]

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 :-/

[xahmol]

Thanks!
Will investigate from there. But probably not a quick fix then to be applied on short term.

[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.

[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.

[xahmol]

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).

[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.