Hey, you, Reptons!

[steve3000]

Noting belatedly that I've added a processing delay between pixel data being enqueued for output and it actually being transcribed; I've yet to hit upon either a meaningful mental model or documentation about what causes the differing per-bpp latencies

I believe the differing HDSR/HDER values are a side-effect of the eight word DMA buffer and how VIDC steps through it depending on the bpp. You can probably completely mess that up by altering the CR DMA request bits.

Although it's not specifically stated, the geometry register values appear to be zero based so are all M-1. I'd also guess VIDC either processes two pixels at a time or pipelines two, so horizontal values have to be divided by 2.

what would be expected to happen if there were a colour-depth change mid-line

I'm not sure that's possible, I believe bpp is fixed at Flyback along with the geometry.

Steve can probably correct me here, but I believe only the palette can change mid-line. It might also be possible to get multiple cursors on screen if the DMA FIFO is observed, although I've never tried.

Humm...(bit of digging through my historic RM test code) this test below might answer some of your questions, but definitely not all:

4bpp, changing to 8bpp mid-screen, and back

It's not perfect, but here we start in MODE 9 (4bpp) from top of screen to line 127, then switch bpp by changing the VIDC CR, from 4bpp to 8bpp. Note the left-shift in the screen at this point, because I haven't corrected the HDSR/HDER for 8bpp. At this point RasterMan also points the MEMC to a new block of 8bpp data, or it would look silly. Then at line 196, we switch VIDC back to 4bpp (and point back to 4bpp data) until the end of the screen.

Other things to note:

The strange spike effect half way down the screen is made by shifting HDSR/HDER right and then left. So H-position can be redefined each line...The test of geometry would be to create a double spike to the left and right by increasing/decreasing line width...I'll have to try this too...
Also, the 8bpp palette is wrong, I didn't redefine the palette after switching to 8bpp, I should fix this.
And the 8bpp data is upside down - that's just RM showing off...

Not answered questions:

Can you change bpp mid-scanline? Not sure, never tried, but we have the technology to try, something for a bank holiday weekend
Can you have multiple cursors by resetting HCSR mid-screen? I don't think this would work, unless it repeats the loaded cursor data for that line (because DMA occurs during H-flyback, so it can't get new data). Anyhow easy to test, so must try this out.
Can you change pixel rate, eg. from 8MHz (MODE9) to 16MHz (MODE12) and back during screen output (a trick often used on the Beeb)? I tried this once, by switching in VIDC CR, but it screwed up the sync, so my CRT lost display until MODE change. I realise now, that I didn't change the H-geometry in that test, so of course it wouldn't work. Will need to try this again.

[sirbod]

Interesting and more or less the complete reverse of what I was seeing.

I don't recall if I was testing on VIDC1 or VIDC20 at the time, but I was specifically testing when HBSR/HBER were taking effect. What that showed (incorrectly going by your demo) was that if they weren't locked in when IR went high, the next frame was wrong. I'm now wondering if the code in the games I was testing was simply setting the wrong values, so HBSE/HBER were out of sync with HDSR/HDER, but that also wouldn't make sense at is they clearly work on tin.

At flyback the game was setting HBSR/HDSR/HDER/HBER. If the values for HBSR/HBER took effect on the next frame, it was visually wrong. Locking them to the value they were at IR fixed it. In fact the borders when scrolling on several games were wrong if I didn't lock in HBSR/HBER at IR, the image positioning was correct though.

Off the top of my head, it was James Pond II, GBH and one of the releases of Enter The Realm where the borders were wrong. Some of the emulators also do odd things with these, although I don't recall which off-hand.

Clearly my testing was flawed!

[steve3000]

Your testing might not be wrong. Remember with RM you don't have the pleasure of RISC OS resetting some VIDC values at VSync, which can throw things off? Also I don't know if I've tested HBSR/HBER changes each line, rather just HDSR/HDER, I'll add these to the bank holiday test plan.

Also I remembered there's a really good example of changing HDSR/HDER line by line in the original RM demo - see from 35s onwards here: https://youtu.be/claMPIjQA_U?si=KAU2jgDTrDlbWj60

If useful for emulator testing, I can package the RM demo into a bootable ADF easy enough, if it's not already out there.

[ThomasHarte]

If useful for emulator testing, I can package the RM demo into a bootable ADF easy enough, if it's not already out there.

I haven't been able to locate it, so if that were possible then I'd certainly be grateful.

EDIT: also I've pushed out a new release of the emulator; same links as above. It improves the VIDC side of things, but 'improves' is definitely as far as I'm currently willing to sell it.

EDIT2: having finally spent a little time on it, passively observing SWIs Wimp_CreateWindow, Wimp_PlotIcon and Wimp_CreateMenu seems to provide most of what I need to automate software launch, so that you can just double click your ADF-or-whatever and then be taken directly into the game or application on the ADF-or-whatever. So I guess I'll work on that and aim for a less-opaque topic here if I get that working to my satisfaction.

---

And to document how it does video, at least for now:

• horizontal and vertical state machines are disjoint other than the former hitting its restart point ticking the latter;
• each compares its current position to all defined timing locations just before the position either resets or ticks upwards;
• output is otherwise prioritised: sync is highest priority, blank second, display third, border colour just fills in the gaps;
• video fetch occurs any time both state machines are in display, and goes into a short circular buffer;
• how far back that circular buffer is indexed depends on current bit depth, and palette is applied then.

Tracking for sync is a single 'has ended' bit; for blank and display it's two bits a piece for 'has started' and 'has ended' with the state being active only if the former is set and the latter is clear.

Known deficiencies:

• as per the emulated machine being an archetypal Archimedes, not a real one, and bus accesses being free, there's no DMA delays;
• the counter-versus-programmed-times tests occur only once, discretely, rather than in an ongoing capacity;
• I'm still unclear on how timer phase ties into all of this — mine are subject to an external divider down to 2Mhz and then the programmed dividers, so won't necessarily start counting immediately when you tell them to, but merely in the next 2Mhz window (which might be correct, and I'm not ruling out other timer flaws);
• you'd have to use a timer to watch the length of flyback to determine even/odd fields in interlaced mode as I haven't spotted that being exposed anywhere explicitly but I acknowledge that probably means I've just missed something.

Unknown deficiencies: countless, in all probability.

Much better implementations could have exactly the same fidelity, etc, but it'd be nice to have something less flawed to compare them to before I get too far into that.

[steve3000]

If useful for emulator testing, I can package the RM demo into a bootable ADF easy enough, if it's not already out there.

I haven't been able to locate it, so if that were possible then I'd certainly be grateful.

Ok I'll pull something together, but might be next weekend.

you'd have to use a timer to watch the length of flyback to determine even/odd fields in interlaced mode as I haven't spotted that being exposed anywhere explicitly but I acknowledge that probably means I've just missed something.

I don't think the odd/even field is tracked or exposed anywhere by RISC OS or in the VIDC registers. But if it is, I'd love to know

The simplest solution I found was to assume VIDC always starts interlace on the same field each time, when switching from non-interlaced to interlaced output. So you just keep track of the fields from the point of enabling interlace. I have this method working reliably on my interlace-sync screenmode app.

[steve3000]

Not answered questions:

Can you change bpp mid-scanline? Not sure, never tried, but we have the technology to try, something for a bank holiday weekend
Can you have multiple cursors by resetting HCSR mid-screen? I don't think this would work, unless it repeats the loaded cursor data for that line (because DMA occurs during H-flyback, so it can't get new data). Anyhow easy to test, so must try this out.
Can you change pixel rate, eg. from 8MHz (MODE9) to 16MHz (MODE12) and back during screen output (a trick often used on the Beeb)? I tried this once, by switching in VIDC CR, but it screwed up the sync, so my CRT lost display until MODE change. I realise now, that I didn't change the H-geometry in that test, so of course it wouldn't work. Will need to try this again.

And I've answered these now See: viewtopic.php?t=29118

[ThomasHarte]

Not answered questions:

Can you change bpp mid-scanline? Not sure, never tried, but we have the technology to try, something for a bank holiday weekend
Can you have multiple cursors by resetting HCSR mid-screen? I don't think this would work, unless it repeats the loaded cursor data for that line (because DMA occurs during H-flyback, so it can't get new data). Anyhow easy to test, so must try this out.
Can you change pixel rate, eg. from 8MHz (MODE9) to 16MHz (MODE12) and back during screen output (a trick often used on the Beeb)? I tried this once, by switching in VIDC CR, but it screwed up the sync, so my CRT lost display until MODE change. I realise now, that I didn't change the H-geometry in that test, so of course it wouldn't work. Will need to try this again.

And I've answered these now See: viewtopic.php?t=29118

Cool!

Though, pedantically *and with extreme vanity*:

note the mid-scanline changes are not currently supported by emulators, so for these you'll need real hardware)

This emulator fully supports mid-scanline changes. Though only in the sense that it’ll apply them at the correct moment and then try to respond appropriately. Not in the sense that anything has been tested. So there’s probably a technical argument to be had here over the meaning of supporting such changes.

I’ll bet that all the geometry changes work because they’re pretty straightforward but colour-depth changes and clock changes probably aren’t right yet.

Testing will reveal a lot of deficiencies, I’m sure. But they’re latent bugs rather than being a natural consequence of a simplified output model.