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.