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

Since we do not have native C compilers on the Oric, this forum will be mostly be used by people using CC65 or the OSDK. But any general C related post will be welcome !
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

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.
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

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.
User avatar
Chema
Game master
Posts: 2898
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

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

Post 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.
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

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.
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

Testing the PETSCII Oric font, also showing Oricutron for Linux and Windows running next to each other.
Stretch indeed works in the Windows version.
Schermafbeelding 2022-06-21 215922.png
Font in the palette viewer:
Schermafbeelding 2022-06-21 220116.png
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

Downloads:
Screen:
PETSCIISC.tap
(1.07 KiB) Downloaded 6 times
Standard charset:
PETSCIICS.tap
(788 Bytes) Downloaded 6 times
Alternate charset:
PETSCIICA.tap
(660 Bytes) Downloaded 5 times
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

Well, trying the sector based routines from this Pinforic code:
https://osdn.net/projects/oricsdk/scm/s ... b16/disk.s

But I am afraid that utilising that surpasses my grap of both assembly as the floppy disk controller operations, as I can not get it to work.

Trying to use it just gives me an endless loop on trying to read a sector, with as far as my knowledge of assembly is also logical from the code:

Code: Select all

microdisc_read_data
    lda $0318
    bmi microdisc_read_data
    lda $0313
    sta ($f3),y
    iny
    bne microdisc_read_data
    inc $f4
    jmp microdisc_read_data
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:

Code: Select all

    .dsb 4-(*&3),$ea
    nop
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.
User avatar
Dbug
Site Admin
Posts: 4040
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

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

Post by Dbug »

I'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:

Code: Select all

	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.
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

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.
User avatar
Dbug
Site Admin
Posts: 4040
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

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

Post by Dbug »

Are you sure that the IRQs are enabled during the reading/writing loop?
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

Dbug wrote: Sun Jun 26, 2022 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)
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

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.
User avatar
iss
Wing Commander
Posts: 1448
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss »

@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 ;).
User avatar
Dbug
Site Admin
Posts: 4040
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

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

Post by Dbug »

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 :)
User avatar
xahmol
Flight Lieutenant
Posts: 356
Joined: Sun Jun 28, 2020 7:32 pm
Location: Utrecht, The Netherlands
Contact:

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

Post by xahmol »

iss wrote: Sun Jun 26, 2022 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?
Post Reply