Loci - my Oric storage emulation project

[Dbug]

I believe "loci-firmware_v0.1.23_rom_v0.1.17.uf2" has been the last rock solid version, and before that it was "loci-firmware_v0.1.18_rom_v0.1.15.uf2"

[Sodiumlightbaby]

I believe "loci-firmware_v0.1.23_rom_v0.1.17.uf2" has been the last rock solid version, and before that it was "loci-firmware_v0.1.18_rom_v0.1.15.uf2"

Hmm, that doesn't look good. FW v0.1.25 is back to the same timings as v0.1.18, and no change between v0.1.23 to v0.1.25. I can try some robustness improvment, but if that doesn't work we could be facing some compiler output differences lurking in the shadow.

[Sodiumlightbaby]

I've been looking into implementing the soft return to the LOCI ROM menu to allow runtime changes of disks etc, and restoring/returning to the running application afterwards. But I've stumbled on a challenge to my approach. To smoothly capture the state of the running application to return to it later, I need to cleanly intercept it (i.e. I can't use reset since it clears a lot of state). My plan has been to intercept the IRQ vector assuming it is fired regularly.

I managed to get a proof of concept of the interception functionality to work, but it seems to only work for "regular" applications. I assume demos and advanced applications still use timer IRQs etc but have the NMI, Reset and IRQ vectors in overlay RAM instead? With the current approach I'm not able to easily intercept those vectors not mapped into ROM space.

So I need to dwell on this a little but would also welcome some feedback. Would it be acceptible to only get soft return to LOCI for apps that don't put the vectors in overlay RAM? They would still get to the LOCI ROM but not smoothly return back to the application afterwards. Or am I missing a huge section of OS or software that always keep the ovelay RAM on and keep their vectors there?

[Dbug]

I assume demos and advanced applications still use timer IRQs etc but have the NMI, Reset and IRQ vectors in overlay RAM instead? With the current approach I'm not able to easily intercept those vectors not mapped into ROM space.

Indeed, typically in my stuff I kick the ROM out, and I put my IRQ vector directly on the top vector, no point doing the indirection when you don't have a ROM to deal with, plus that avoid one jump per IRQ

So I need to dwell on this a little but would also welcome some feedback. Would it be acceptible to only get soft return to LOCI for apps that don't put the vectors in overlay RAM? They would still get to the LOCI ROM but not smoothly return back to the application afterwards. Or am I missing a huge section of OS or software that always keep the ovelay RAM on and keep their vectors there?

As far as I know, pretty much 99% of all software is using either:
- Sedoric/OricDos/etc... which all are using a BASIC compatible IRQ handler in page 2
- FloppyBuilder (and earlier) based games and demos... which as far as I know are all using a single disk (can't think of a multiple disk demo or game)
- Fabrice and Chema pinforic which uses a two disk system, one to boot the Infocom interpreter and then a disk change to insert the game itself... but I'm not sure how that's implemented internally.

[Sodiumlightbaby]

Thanks, that's helpful.

- Fabrice and Chema pinforic which uses a two disk system, one to boot the Infocom interpreter and then a disk change to insert the game itself... but I'm not sure how that's implemented internally.

Yes indeed. First, does it move the IRQ vector to overlay RAM? Second, do the disks need to be in the same drive, or can one be in e.g. A and the other in B?

[Dbug]

No idea, for reference you can get the project with most of the games released for it at the time on https://www.oric.org/software/pinforic-2502.html

Recently, both "Tristam Island" and "Hibernated" games have been using it with a modified version that fixed a few issues, not sure if there were disk changes though.

[Chema]

Thanks, that's helpful.

- Fabrice and Chema pinforic which uses a two disk system, one to boot the Infocom interpreter and then a disk change to insert the game itself... but I'm not sure how that's implemented internally.

Yes indeed. First, does it move the IRQ vector to overlay RAM? Second, do the disks need to be in the same drive, or can one be in e.g. A and the other in B?

Mmmm should check the sources, but I am pretty sure it doesn't. Pinforic keeps switching between overlay and rom. In the overlay ram is where data from disk is stored (a kind of virtual memory buffer) but also some other data is stored there. The rom is used for the c library standard functions (printing, and getting user input basically).

And, unfortunately, yes. The disk should be in the same drive.

[Sodiumlightbaby]

The rom is used for the c library standard functions (printing, and getting user input basically).

Ah, that makes me hopeful. It will be a little while befor I can test it though, out and about this week.

[Sodiumlightbaby]

The rom is used for the c library standard functions (printing, and getting user input basically).

Ah, that makes me hopeful. It will be a little while befor I can test it though, out and about this week.

Just got to test this, and good news - I'm able to trigger my IRQ capture method with Pinforic so I can make it work (fingers crossed)

[Sodiumlightbaby]

One of the most meaningful releases so far for me.
https://github.com/sodiumlb/loci-firmwa ... ag/v0.1.26

We now have support for booting the great Oric diagnostic ROM instead of the LOCI ROM (long press instead of short press the action button), and with @mikeb's permission I can include the diagnostic ROM image with the release builds!

Right now there are no extra features for supporting the diagnostics session although I would like at least to get to a point where some status feedback is possible. However it will never replace the need for the harnesses and properly reading the documentation to successfully run the diagnostics.

My hat of to Mike for making this possible

The other more normal change is that the discussed IRQ capture interception method is now implemented, with fallback to the old non-recoverable Reset method after 500ms. So you should always be returning to the LOCI ROM menu but on debug devices the display will say if IRQ was captured or not.

[Dbug]

I tested the diagnostic part, that did work nicely.



Is the VIA port A test failure related to not having connected the loop-back connectors?

[Sodiumlightbaby]

Is the VIA port A test failure related to not having connected the loop-back connectors?

Yes, to run all the tests you need to have/make and fit the loopback connectors/harnesses. They are not hard to make - the descriptions are all in the documentation https://oric.signal11.org.uk/html/diagrom.htm

[Sodiumlightbaby]

I've been hacking away at a save/restore solution as of late, but with very limited time it has been moving slowly. This is for being able to e.g. switch disks in a drive for Pinforic etc. So far what I have working save/restore of is:
* Registers A,X,Y,S
* Zero-page
* Memory 0x0100-0x1FFF (except page 3). This is what the LOCI ROM uses as RAM now to be 16k compatible.
* Memory 0xA000-0xBFFF. Basically all the display and character set RAM
* VIA registers for T1,T2,IER,PCR,ACR,DDRA and DDRB
and as of this evening
* ULA mode

The ULA mode capture and restore is done by having a PIO program on LOCI snoop the data on the first ULA cycle on the bus each phi2 period, and keep a record of the latest mode attribute read by the ULA. On restore after the display memory has been restored, that mode attribute is put in 0xBFDF temporarily, just like Dbug suggested some time ago. And that seems to work!

What isn't working yet is just a tiny thing - returning to a good running state
Mostly I get back to a good looking but hung application. CPU is running, but something is still wrong.

Since I'm trapping the IRQ call to begin with, the resume rotuine ends with jumping back to the original IRQ routine.
I suspect the VIA restore approach at least, as in 4k kong I actually return to the game loop running but with lost keyboard input. Also hitting NMI after a failed resume attempt to BASIC gets it to a seemgly fully working state.

[Dbug]

I suspect the VIA restore approach at least, as in 4k kong I actually return to the game loop running but with lost keyboard input.

Could it be a missing "bit $304", like you return for the IRQ but the VIA will not trigger because it thinks an IRQ is still being processed?

[Symoon]

(still following the amazing work here, no time to test these days sadly, hopefully 2025 will be better!)