OCULA - a ULA replacement concept

[Sodiumlightbaby]

Quick update. USB CDC monitor is working on the OCULA board.

[Sodiumlightbaby]

...and we got first DVI output! So that ticks off another nice working thing!
Nothing too ground breaking workwise, mostly based on example code but ported in as a module for the FW and made to work, but good quick milestone regardless.

Picture is 640x480 with a simple 8bit per pixel RGB332 colour format showing a simple repeating 0-255 byte ramp on a picture-in-picture display.
Minicom with the USB CDC monitor running in the background. But don't get too hung up on the specs here, getting it working was the goal, later we build a proper display system.

[ibisum]

Amazing progress. I'm now eagerly eyeing my stack of Atmos' to determine which one gets an OCULA upgrade in the near future.

[Sodiumlightbaby]

I've been looking into video timings, trying to make things fit nicely. This is mostly a braindump/notes for the record but if anyone has some experience in this domain I'd love to hear alternative approaches or suggestions.

I would idealy like to have the DVI output be in sync with the original machine video generation so that
1. Timing dependent software and hardware work as expected - even if you only use the DVI output
2. Efforts on keeping VSYNC also work for the DVI output
3. We can use synchronized scanline generation without excessive buffering (save RAM)
Which shouldn't be too hard since our Orics run at 50Hz or 60Hz and those are pretty common frame rates also on modern displays, right?

Well, the ULA doesn't actually generate a perfect 50 or 60Hz display. As with many of 80s micros video subsystems, good-enough while cutting cost was the priority so what we have is a 6MHz pixel clock used to generate two different timing formats
"Oric-50Hz": 384 cycle lines and 312 lines per frame. Each frame is 384x312=119808 cycles => 50.080128Hz
"Oric-60Hz": 384 cycle lines and 260 lines per frame. Each frame is 384x260=99840 cycles => 60.096144Hz
Correction:
"Oric-60Hz: 384 cycle lines and 264 lines per frame. Each frame is 384x264=101376 cycles => 59.185606Hz

So we are off just a little, but enough to make synchronized video output a challenge.

The two standard CEA-861-D formats I have been eyeing for use are
"576p" 720x576@50Hz: 864 cycle lines and 625 lines per frame. Each frame is 864x625=540000 cycles => 50.0000Hz at 27MHz pixel clock
"480p" 720x480@60Hz: 858 cycles lines and 525 lines per frame. Each frame is 858x525=450450 cycles => 60.0000Hz at 27.0269MHz pixel clock(59.94 at 27MHz)

Running these as specified shows that the two outputs will drift in relation to each other. What I propose is that we explore non-standard DVI outputs to see if we are close enough to the standard that we can make things work for most displays, if not we will have to live with unsynchronized DVI output and tearing. What I'm betting on is that the synchronization in modern displays is the least sensitive to small adjustments in VSYNC timing. Time will tell how wrong I am

The 576p format actually fits pretty well with the Oric-50Hz format. The pixel clocks of 27MHz and 6MHz have a "clean" 4.5x relation ship but the cycles times are not (because Oric-50Hz is non-standard). The diff in cycles are 540000 - (4.5x119808=)539136 = 864. Wow, that's exactly one line in 576p timing. So I propose we try a non-standard format for 50Hz-ish DV output:
"Oric-576p": 864 cycles lines and 624 lines per frame. Each frame is 864x624=539136 cycles => 50.080128Hz
Perfect - So we'll see if we can pull off cutting the DVI VSYNC timing by one cycle

What about 480p? Well, it's not as clean. Assuming we keep the same 27MHz DVI pixel clock, the similar 4.5x cycle diff is 1170 (correction 5742). One format I'm able to make fit is reusing the 576p scanline timing but with a cut down 520 lines config
"Oric-480p-A": 864 cycles lines and 520 lines per frame. Each frame is 864x520=449280 cycles => 60.096144Hz
This is much more sketchy than the Oric-576p format, but it uses enough familiar looking timings with whole line adjustments - it's worth a try.
Correction, with the right Oric-60Hz numbers, the adjustment needs to be the other direction. Still needs the 576p scanline timing, but the vertical needs to increase by 3 lines.
"Oric-480p-B": 864 cycle lines and 528 lines per frame. Each frame is 865x528=539136 cycles => 59.18560606Hz.

The other most common 60Hz display resolutions is "VGA" 640x480. It uses a 25.2MHz pixel clock for clean 60.0Hz or 59.52Hz @ 25MHz.
"VGA" 640x480@60Hz: 800 cycle lines and 525 lines per frame. Each frame is 800x525=420000 cycles => 60.0000Hz at 25.2MHz (59.54 at 25MHz)
The 25.2MHz is actually a clean 4.2x of 6MHz, while 25MHz is not. The 4.2x cycle diff 420000 - (4.2x99840=)419238 = 672. Hmm, this not an easy adjustment. It would require a shortend scanline during VSYNC (128 cycles instead of 800) and I don't know how displays would react to such timing.

VGA is actually the only format guaranteed to be supported on all displays. The CEA formats is what you'll find on anything with HDMI and expecting "TV" type inputs, but on older DVI monitors we'll only get the VESA formats, of which there are zero 50Hz ones for us to use. We'll likely have to support this one just so people are never totally stuck, but I think of it as a fall back / base-line.

What about HD formats like 720p? Well, I want to focus on the ones we can use without overclocking the RP2350. When we talk about DVI pixel clocks here, remember each pixel is 10bits per channel, so the actual TMDS bit rate is 10x - 27MHz pixel clock => 270Mbit signaling. The HSTX system in RP2350 gives us double data rate, so we only need half that as internal clock 270Mbit => 135MHz internal clock. The RP2350 is rated for 150MHz so that means the pixel clocks we should prioritise are those <30MHz. Pixel clock for 720p is >74MHz, so that's quite a bit of overclocking. People do it, but I think we should leave it for future experiements for now.

This summarizes the current format thinking: We aim for 3 formats - 2 synchronous and 1 fall-back asynchronous:
Oric-576p for 50Hz, Oric-480p-B for 60Hz, both non-standard but tuned to track the ULA timing perfectly
VGA, standard, always 60Hz - will tear etc but always work

[iss]

Everything makes sense to me and looks good! .
Maybe except the numbers 312/260. Is the retrace time included in both 50/60Hz?

Speaking from my vague memory, something like:
308+4=312
260+4=264
but maybe I'm completely wrong.

[Sodiumlightbaby]

Everything makes sense to me and looks good! .
Maybe except the numbers 312/260. Is the retrace time included in both 50/60Hz?

Speaking from my vague memory, something like:
308+4=312
260+4=264
but maybe I'm completely wrong.

Ah, I was using an old ULA reference out of convenience. You are correct, 60Hz should be 264 lines!
Edit: Corrections added to the main post. Key changes highlighted.

[Sodiumlightbaby]

While dreamseal is tinkering on with PIVIC, I've put some cycles into getting the OCULA RGB+Sync generation working. So this is just the dot and line counters feeding a cycle exact PIO program that drives the actaul RGBS pins. We're not putting these prototypes into machines just yet, so I have a simple prototype board with series resistors to take the signal levels down to ca 1V when connected to 75Ohm terminated display for testing (the 1081 as usual).

After some debugging, I've finally got the basic high frequency per cycle pixel driving working. This is using ink and paper and a 6 bit mask (classic Oric format) on the CPU side, driving individual pixels on the physical side. In this test ink is incrementing while paper stays black, with a 0x15 bit mask (alternating pape/ink).

CPU loop is still breaking the time limit when I add the memory lookups and attribute handling, but that's "just" a little optimisation needed

[iss]

Nice colors Well done!

[Sodiumlightbaby]

Nice colours not enough for you? How about some LORES text then....

[iss]

Better and better. Looks great!

[Chema]

Impressive. Really impressive.

[ibisum]

Just gobsmackingly great. Rock on, sodiumlightbaby!

[Sodiumlightbaby]

Small progress report.

After getting a basic implemenation of the Oric standard LORES text mode working (no blinking or double size yet ),I took the plunge and put the OCULA prototype in beat up Oric-1 I got for the project (which for some reason comes with Basic 1.1).

I'm happy to say it didn't explode The display output worked straight away and the PHI generation passed through the 6502 and created a pretty good looking PHI2 clock. The decoding also seemed to work quite well, but getting the RAM read and write functionality to work took some time.

A key issue was the infamous E9 errata for the RP2350. The original plan was to have some high impedance connection between the pairs of address lines going into the RAM muxes, turning the ULA outputs into inputs. But the E9 errata on the GPIO pins of the RP2350 means they are basically leaking 120uA, which is not very combination with high impedance sources - it means e.g. it is hard to get a good low input level I had to drop the resistance down to 2k to get it to work, which means it won't work with an original ULA. I'll have to try a different approach in the text version of the hardware prototype to get. Probably a good sleep on it will help

Another issue was getting a basic emulated writing to RAM to work for some reason everything seemed to work, except the value didn't change. In the end I pulled out the logic analyzer probes for the scope. I got them after having spent a lot of time probing LOCI signals, but this was the first time I broke them out for actual use. And that's when I saw that the bus transciever didn't yeild for the writes, and discovered I've forgotten to actually test for the read/write signal when setting up the PIO program That fixed, I was greated with this little gem.

An actual first boot on an emulated ULA, blinking cursor, keyboard clicks and all. The white on black text is OCULA debug prints I put in the Oric framebuffer for convenience during debugging. The numbers on the bottom line are not corrupted in memory, they are just changing faster than the RGB scanning display output.

Not everying works though. There is definitively a reset issue that needs some thinking/handling, and LOCI doesn't boot.

[Dbug]

Seriously impressive progress in such a short time

[kenneth]

This is a revolution for Oric cloning !