Loci - my Oric storage emulation project

[Dbug]

... paradoxically the fixed ULA vmode snooping may be too good ... during VBLANK

bit offtopic: Indeed, the snooping is too good!
If we make the mode byte to be accessible through the LOCI-API we can do VSYNC hack for free

You start with that, and you end up being able to do DMA transfers in the background like a Blitter, blocking the CPU and using the 6502 access slots to copy bytes at one byte per cycle

[Chema]

... paradoxically the fixed ULA vmode snooping may be too good ... during VBLANK

bit offtopic: Indeed, the snooping is too good!
If we make the mode byte to be accessible through the LOCI-API we can do VSYNC hack for free

You start with that, and you end up being able to do DMA transfers in the background like a Blitter, blocking the CPU and using the 6502 access slots to copy bytes at one byte per cycle

I’m not a big fan of anything not included in the original hardware. If a VSYNC detection could work the same way as the VSYNC hack does, that’s fine, but new features create a 'super-Oric'... which, honestly, I’m not a fan of.

I’d much prefer custom ROMs and maybe even emulation of Oric cartridges. I know they never existed back then, but they're possible with current hardware—it's just that, to my knowledge, no program made use of them.

What other devices were available back then that might be interesting to emulate, apart from a modem?

[ftmb]

the speech synthesis

[Sodiumlightbaby]

the speech synthesis

The SPO256 based one? I guess the Oric device had a separate speaker? What did people use it for?

I think one potential device could be printer (VIA output only).

I'm interested in creating a ULA implementation at some point because they are a finite resource. No rush though.

[Sodiumlightbaby]

maybe even emulation of Oric cartridges. I know they never existed back then, but they're possible with current hardware—it's just that, to my knowledge, no program made use of them.

I'm not sure I undetstand what you are thinking of. Just direct basic-replacing ROM cartridges with mappers/bank-switchers etc?

[ibisum]

> custom ROMs

Has anyone tried dflat on LOCI yet?

[Chema]

maybe even emulation of Oric cartridges. I know they never existed back then, but they're possible with current hardware—it's just that, to my knowledge, no program made use of them.

I'm not sure I undetstand what you are thinking of. Just direct basic-replacing ROM cartridges with mappers/bank-switchers etc?

I have some prototypes from Fabrice Frances which you plug on the expansion port. One acted as an erebus, so you list files with cload, etc. But the other is plug, reset, play game. I am not sure how they worked or if they are capable of.bank switching.... but, anyway, those "cartridges" never actually existed.

[Dbug]

If there were expansions to LOCI, actual useful ones (ie: not theorical could be cool), I think for me that would be:

• Possibility to easily replace the ROM by any other, like the Diagnostic Rom, DFlat
• A possibility to easily freeze a game and save the state to the USB storage, with possibility to restore it, would be awesome to try to finish games like Damsel that are very difficult, or games that are very long and don't have an actual save feature
• Communication (like to make a networked Oric game, or load data from the internet)
• Anything that can make development easier (like quick deployment from a PC to the Oric without having to plug-unplug anything)

On top of that I guess it would be cool to have something like what the Orix/Twilighte system does with providing some kind of large storage system with the pseudo Unix system, but I'm not the target user there

[Chema]

If there were expansions to LOCI, actual useful ones (ie: not theorical could be cool), I think for me that would be:

100% agree.

[Sodiumlightbaby]

• Possibility to easily replace the ROM by any other, like the Diagnostic Rom, DFlat

Diagnostic ROM is already shipping in the latest FW. Long hold (2-3s) the action button to boot it instead of LOCI ROM. Diagnostic ROM is special since you may have broken HW that prevents LOCI ROM usage.
Arbitrary ROM selection is coming. Since this seems to be hot at the moment, I can address it before TAP saving.

• A possibility to easily freeze a game and save the state to the USB storage, with possibility to restore it, would be awesome to try to finish games
  like Damsel that are very difficult, or games that are very long and don't have an actual save feature

A little more work, but yes this seems very useful.

• Communication (like to make a networked Oric game, or load data from the internet)

Already in if a little untested. Requires a USB modem device - RP PicoW. If not, Oricom is coming too

• Anything that can make development easier (like quick deployment from a PC to the Oric without having to plug-unplug anything)

A lot is already there inherited from RP6502 for controlling and uploading to LOCI over serial (USB CDC). What is missing is an easy way to doing the connection. My current plan is to have the PicoWifiModemUSB expose a non-modem CDC endpoint that allows development and control over your local Wifi network.

Talking about network stuff. Would it be possible to develop an Oric friendly frontend to oric.org? I think that could be a killer-app for Orics online.

[ibisum]

Would it be possible to develop an Oric friendly frontend to oric.org? I think that could be a killer-app for Orics online.

Hell yeah! Amazing idea.

I don't have my Atmos handy at the moment but as soon as I get some Oric hacking time, I wanna see if dflat works without fuss:

https://github.com/6502Nerd/dflat

(In case you hadn't seen it yet @sodiumlightbaby..) The thing about dflat is that its a workable ROM buildable from source .. besides being bloody awesome, of course.

[Sodiumlightbaby]

(In case you hadn't seen it yet @sodiumlightbaby..) The thing about dflat is that its a workable ROM buildable from source .. besides being bloody awesome, of course.

I have looked at it a few times, dflat is great indeed - fantastic work @6502Nerd! It would be my first choice for a native shell type OS for LOCI with some custom io drivers etc. Some day But just being able to use it as-is is within reach of course.

On the development side I've gone down an interesting set of forking rabbit holes starting around the VMode snooping. But I've broken something (introduced an FDC instability) in the process so I'll have to spend the limited time playtime towards the weekend dissecting exactly what caused it).

[Sodiumlightbaby]

As mentioned before it has been quite a lot of deep diving into different rabbit holes this week, but I think the knowledge building has been useful to increase the stabitliy.

However one area where I might have hit a challenging obstacle, is with the ULA snooping. I had some real issues getting a stable read of the ULA phase 1 RAM access. If I skewed the sampling to phase 2 it was rock solid so the reading function was pretty good. Well, it turns out there is a logical reason for why I'm having this problem.

Here is the logic diagram of the ULA CAS suppression logic from Mike Brown's excellent ULA documentation work https://oric.signal11.org.uk/html/ula-dieshot.htm

CAS suppression is used to cancel RAM output when it would conflict with other units on the bus like the VIA, the ROM and expansion devices during the CPU part of the clock cycle. All good. The design decision (possibly for timing reasons) that is hurting us now is that the signal for CPU or ULA use of the bus is merged in before the logic to decode addresses for ROM and the MAP signal.

The result of that choice is that the address and MAP checks apply for both CPU and ULA clock phases, and once the ULA crosses into VBLANK space it is generating phantom VRAM addresses that steps in the ROM address space. And because MAP isn't asserted in ULA phase 1 and the addresses are in ROM space, CAS is suppressed and the bus is left floating in ULA phase 1. The ULA doesn't care as it is not using that data anyway, but for us it becomes very hard to do snooping as the bus reads garbage.

It's not the end of the attempt, but it means the current approach is not likely to work and something very different is required. Time to put on the thinking hat

[Dbug]

and once the ULA crosses into VBLANK space it is generating phantom VRAM addresses that steps in the ROM address space. And because MAP isn't asserted in ULA phase 1 and the addresses are in ROM space, CAS is suppressed and the bus is left floating in ULA phase 1. The ULA doesn't care as it is not using that data anyway, but for us it becomes very hard to do snooping as the bus reads garbage.

Is it only during VBLANK or does that also apply to the HBLANK every 40 bytes decoded for the display?

[Sodiumlightbaby]

Is it only during VBLANK or does that also apply to the HBLANK every 40 bytes decoded for the display?

Is is only during VBLANK but it is not directly connected to VBLANK. It is just because the ULA doesn't care about what it fetches during VBLANK we get this mix of random data. HBLANK just happens to never step into the ROM area - it will however read 24 bytes of the next line and ignore it.

The garbage period is during the part of VBLANK after the ULA crosses the 0xC000 barrier. Text mode is forced on from line 200, even during VBLANK, so for each scanline the ULA will look for (but not use) character data. The data starting at 0xBFE0 (first byte ouside VRAM) is therefor read 8 times, including the HBLANK overshoot so 64 RAM reads per line. That means, if I'm getting this right, that for the 8 first scanlines during VBLANK (200-207), 32 bytes are read OK from 0xBFE0-BFFF, and then 32 bytes of garbage is read from 0xC000-C01F. After that it is all garbage until VSYNC is done and it starts from scanline 0 again.