ArcDVI, Archimedes DVI/HDMI output

[geraldholdsworth]

It's looking fantastic. Well done. I'd love one when they're ready.

One thing though - how would this fit in an A3K that already has an internal hard drive interface fitted?

[Mattmos]

It's looking fantastic. Well done. I'd love one when they're ready.

One thing though - how would this fit in an A3K that already has an internal hard drive interface fitted?

Cheers! Well, I don’t know, likely it wouldn’t. First thing would be to work out the height budget and perhaps a slimline all in one derivation could fit. Alternatively, all of the required signals are available at MEMC and ARM so some kind of mega-mod could pick them up under the keyboard. I think the short answer is “not easily”

[IanJeffray]

This is all staggering. Amazing. Impressive. Wow. I'm having to read the thread multiple times just to try and get my head around it all.
I'd love one for an A5000 -- which I performed a simple RAM upgrade on and have been running it at 16.66MHz quite happily for some time now - I assume the improved bandwidth would improve the 'logical' refresh?

[geraldholdsworth]

First thing would be to work out the height budget and perhaps a slimline all in one derivation could fit. Alternatively, all of the required signals are available at MEMC and ARM so some kind of mega-mod could pick them up under the keyboard. I think the short answer is “not easily”

Sorry for putting that spanner in the works. I'll get some photos of my A3K later on - there may be a solution. OK, it may need to be modifying the case to fit a DVI or HDMI socket into it. The main board, I think, as long as it'll fit under the floppy should fit in alongside the HDD i/f.

[steve3000]

Brilliant work, thanks for the update - this continues to amaze!

I really hope you do manage to get this as far as a production run, I can't wait to try one And definitely like the 3-board modular approach for flexibility.

Now some questions:
- How well does this perform with on-the fly timed VIDC parameter changes? You've had Lemmings running, which redefines the palette on timed IRQ for the menu/map bar at the bottom of the screen - does the bottom of the Lemmings screen display correctly?
- If Lemmings is OK, a much tougher test would be to run the !RasterMan demo (v0.16b is the one to try) from here - http://www.pi-star.co.uk/rasterman/download.html ...Part 1 of the demo uses timed colour changes at the end of each raster line, Part 2 adds a second mid-line colour change, and Part 3 shifts the HDSR/HDER positions and cursor position on each raster line, and reprogrammes MEMC on each line...
- You mentioned in the first post about sound, any further thoughts on this? It would be great to see clean sound output to HDMI avoiding Acorn's low-pass filter.
- And this is probably to much feature creep...but perhaps could you use the same trick you've done with video, as a route to 16bit sound? ie. Programme RISC OS to pump out 4-channel, 8bit sound data (it can manage 4 x 8bit samples easily at 20.8kHz and possibly 41.6kHz), then sniff out two of the 8bit values to generate a single 16bit left channel, and the other two for right...
- Finally, have you thought about our poor old ARM250 friends? I'm sure there will be a few folk who will want so much to get this running on thier A3010/20/A4000, they'll be happy to wire up a bird's nest of knar patch wires to the required points on the ARM250 pcb, to tap those VIDC signals. In which case, you might want to consider including a row of unpopulated solder connection points on the A3000 pcb, so these signals could be plumbed in on such machines?

[geraldholdsworth]

Looking at my A3K, I think your backplate could fit in place of the HDD I/F backplate with enough room behind. Might have to do a bit of fiddling around to get it all fitting, but it's possible - I think.

[Mattmos]

Looking at my A3K, I think your backplate could fit in place of the HDD I/F backplate with enough room behind. Might have to do a bit of fiddling around to get it all fitting, but it's possible - I think.

Thanks for the pics, Gerald. I think I understand the question now. IIUC there’s nothing underneath the FDD in your machine, so plan A (ArcDVI fully fitting underneath the FDD) should suffice. The backplate, well, something external would probably be best for machines already having an internal podule. Like mine!

That’s another reason I thought the FFC (Flat Flex Cable) was cool: it can snake out through the gap around the external podule socket, to an HDMI socket mounted on the outside “somehow”/TBD.

[Mattmos]

This is all staggering. Amazing. Impressive. Wow. I'm having to read the thread multiple times just to try and get my head around it all.
I'd love one for an A5000 -- which I performed a simple RAM upgrade on and have been running it at 16.66MHz quite happily for some time now - I assume the improved bandwidth would improve the 'logical' refresh?

Aw, thank you. glad you like it. I will make sure it works in an A5000. Very cool that you've got the fast RAM for sure. (Tangent: we need to figure out how to make FastRAM PAL kits for pre-A540 machines too. )

It raises an interesting question. A faster MEMC will (I think) give VIDAK/SNDAK DMA strobes that are a little shorter. There's a decent margin given the speed I'm sampling them/the data at, but for speeding up the memory system there will eventually be a point where it's hard to capture data correctly. I don't have my notes to hand, the limit can be calculated -- I don't think this is anything to worry about in practice. If you're up for it, it'd be great to test out on your super-fast A5000 sometime.

But you didn't ask that: IIUC the consumed video bandwidth will remain the same (your VIDC will stay at 24MHz/36MHz/whatever A5K enhancers do), and it's the same number of pixels per second as before. Obvs as the available bandwidth is higher, the percentage used by video is lower. You could probably then afford to make custom modes for higher refresh rates (but I don't personally think that's useful on LCDs). I hope I've understood the question correctly.

[AndyMc1280]

Aw, thank you. glad you like it. I will make sure it works in an A5000. Very cool that you've got the fast RAM for sure. (Tangent: we need to figure out how to make FastRAM PAL kits for pre-A540 machines too. )

It raises an interesting question. A faster MEMC will (I think) give VIDAK/SNDAK DMA strobes that are a little shorter. There's a decent margin given the speed I'm sampling them/the data at, but for speeding up the memory system there will eventually be a point where it's hard to capture data correctly. I don't have my notes to hand, the limit can be calculated -- I don't think this is anything to worry about in practice. If you're up for it, it'd be great to test out on your super-fast A5000 sometime.

*mumbles*
20mhz Ram,
ARM 3&FPA10 @30 mhz Adelaide A3010 here - almost an A5000 in a wedge box.

Would be "Interesting" to test, although I'm within driving distance of @Ian Jeffray Rather than mess about on my own....

[Mattmos]

Brilliant work, thanks for the update - this continues to amaze!

I really hope you do manage to get this as far as a production run, I can't wait to try one And definitely like the 3-board modular approach for flexibility.

Cool, thanks! I'm glad the 3-board approach sniffs OK.

Now some questions:
- How well does this perform with on-the fly timed VIDC parameter changes? You've had Lemmings running, which redefines the palette on timed IRQ for the menu/map bar at the bottom of the screen - does the bottom of the Lemmings screen display correctly?

I knew some day you'd ask about palette-switching; I'm prepared.

Yes, Lemmings looks normal AFAICT. But, I think it leaves a line or two so that the timer doesn't have to be dead-on (not unusual AFAIK).

- If Lemmings is OK, a much tougher test would be to run the !RasterMan demo (v0.16b is the one to try) from here - http://www.pi-star.co.uk/rasterman/download.html ...Part 1 of the demo uses timed colour changes at the end of each raster line, Part 2 adds a second mid-line colour change, and Part 3 shifts the HDSR/HDER positions and cursor position on each raster line, and reprogrammes MEMC on each line...

Much tougher indeed! So, I know this won't work. ArcDVI runs exactly one line behind VIDC's scan, i.e. while VIDC is scanning out/fetching line 2, ArcDVI is scanning out line 1, possibly doing so twice at twice the speed. The delay is necessary to capture the line fully before scanning it out twice, IYSWIM. BUT, the palette registers are (arguably incorrectly) sampled at the time of every pixel being output. So palette updates appear a line late, and if doubled likely 1.5 lines late (e.g. I've been testing with the "Arabella II" demo which tears in the middle).

In short, fine-grained palette-switching doesn't really work -- except for simple "This score/status bar is different" cases like Lemmings. I haven't found anything (aside from your Part 3!) that does dynamic *mode* changes (a la Elite on the beeb), but these will not work. ArcDVI doesn't consume the VIDC display values directly; when the VIDC timing regs change it's flagged to the MCU, which reads them, constructs an output mode and sets up the FPGA regs. It'll be hard to make fine-grained timing changes work.

Some approaches we could take for the palettes:

1. Do nothing: ArcDVI works for almost all games, might look dodgy on some, and sadly RasterMan doesn't work. But we can easily scratch the many-colours itch the right way: true 256-colour (out of 16.7M) modes, and 16BPP high-colour modes.
2. Take a snapshot of the palette's state at the start of each VIDC output line, and use /that/ in output a line later. I can try this; the FPGA has space to add 192 more FFs. This will make per-line switching accurate (your Part 1 should look good).
3. Implement a perfect VIDC model, including FIFOs and aligning palette writes with pixels consumed. I think this is possible, though probably quite some work to get it exactly right.

I think my first priority would be finishing off the high-colour/extended-palette modes, and eventually option 2. If the majority of games look right, IMHO it's the right sweet spot for now.

- You mentioned in the first post about sound, any further thoughts on this? It would be great to see clean sound output to HDMI avoiding Acorn's low-pass filter.

Still on the wishlist! I'll next try to capture the sound DMA and get this going. I've wired up I2S lines to the HDMI serialiser so in theory we should be able to output digital audio via HDMI too. There's a risk that the TDA19988 may be painful to get working with HDMI audio. The Arc audio would need to undergo dynamic sample rate conversion from $whatever to 44.1KHz/16bit, and the RP2040 is best placed to do this maths. Twistedly, that means FPGA captures Arc audio data which is read out by the RP2040, SRC'd/filtered, and pushed back to the FPGA for precise emission in sync with the video. (I put on a half-duplex parallel bus MCU<->FPGA for this.)

Failing that, there are footprints for a disgusting PWM audio output (plus passive RC low-pass filter) on the rear panel board, to a 3.5mm jack -- I hope we don't have to go there as I expect this to be a bit crappy.

Anyway ... didn't want to get any hopes up before getting it working, but that's my thinking.

- And this is probably to much feature creep...but perhaps could you use the same trick you've done with video, as a route to 16bit sound? ie. Programme RISC OS to pump out 4-channel, 8bit sound data (it can manage 4 x 8bit samples easily at 20.8kHz and possibly 41.6kHz), then sniff out two of the 8bit values to generate a single 16bit left channel, and the other two for right...

Nice idea, and pairing the channels up is a great approach! So code would service the buffer refill requests and do the data "unzipping" into each channel request? It's nice that this would work within the RISC OS sound framework too, and wouldn't change how the DMA looks. I think this is worth a try for sure.

- Finally, have you thought about our poor old ARM250 friends? I'm sure there will be a few folk who will want so much to get this running on thier A3010/20/A4000, they'll be happy to wire up a bird's nest of knar patch wires to the required points on the ARM250 pcb, to tap those VIDC signals. In which case, you might want to consider including a row of unpopulated solder connection points on the A3000 pcb, so these signals could be plumbed in on such machines?

Pretty tough due to the system on chip integration. The signals tapped from the VIDC clip-over (eg. the VIDW register write strobe, and the DMA strobes/handshakes between MEMC/VIDC) aren't externally exposed on ARM250. The data bus does go external, but the handy "here's some pixel data right ...now!" signals don't. ARM250 support would be a very separate project unfortunately.

<inventing hat on>One could snoop D[31:0], the RAS/CAS and RAM addresses, and capture transfers from screen memory addresses. But I can't see a way to see VIDC register writes. Maybe some software support (e.g. RISC OS hacks) could mirror VIDC writes to an I/O address, then ArcDVI could know what mode timing/bpp are used?

[Mattmos]

*mumbles*
20mhz Ram,
ARM 3&FPA10 @30 mhz Adelaide A3010 here - almost an A5000 in a wedge box.

Would be "Interesting" to test, although I'm within driving distance of @Ian Jeffray Rather than mess about on my own....

Maaaate, that's too much excitement in one machine I'm sure Ian's super-soldering can gently probe VIDC's desirable strobes and buses, and bring them to some PCB or other for ArcDVI. Adelaide machines are super-nice.

They're IOC aren't they? How does the fast RAM work, does that speed up IOC/IO accesses too (as would happen if A3000's MEMC (and therefore system clock) were overclocked) or does it have some kind of FastRAM logic like the A540/A5000?

[IanJeffray]

does it have some kind of FastRAM logic like the A540/A5000?

It has an IOEB hidden on the underside of the mezzanine.

[Mattmos]

does it have some kind of FastRAM logic like the A540/A5000?

It has an IOEB hidden on the underside of the mezzanine.

Wow! I’m still finding so many threads on here I haven’t seen before (largely due to your cross-link tips). Thanks

[Mattmos]

Updatey updatey:

I think the "soft" side of this project (the firmware/FPGA design) is now finished for v1 features. It's AFAICT debugged, so good time to push the sources. It was looking super-messy having it all part of one jumbo repo so it's split up a bit now. The old 'ArcDVI' single-repo is unchanged, but I will remove it in due course. ArcDVI lives here:

• FPGA contents: https://github.com/evansm7/ArcDVI-hw
• Microcontroller (RP2040!) firmware: https://github.com/evansm7/ArcDVI-fw
• RISC OS stuff: https://github.com/evansm7/ArcDVI-sw
• PCB designs: https://github.com/evansm7/ArcDVI-PCB (NOTE: stale)

I haven't yet published the PCB designs, sorry. I plan to (though would suggest not to build the current version, there's a new revision to design). In case I get hit by a bus before I do that, the plotted schematics of the main board are:

arcdvi-schem1.pdf

(499.05 KiB) Downloaded 19 times

Feature-wise:

• I got mode 24 working (I can't count)
• All standard RISC OS 3.1 modes 0-36 work perfectly
• Modes 37-40 (896x352) do not display on my monitor. As-is, they've too few lines, but line-doubled to 896x704 they're too square. Solution is to add "visible" black bars either side, but that's work. How much do we care about these modes (so I can prioritise accordingly)?
• Cursor/pointer works
• Hi-res mode works
• Dynamic switching of pixel clocks works (e.g. *Configure any monitor type, including hi-res mono, and go)
• Added 256 colour Extended Palettes (what I'm calling a freely-writable 256-entry 24-bit palette, distinct from the traditional 256-colour modes whose colours are generated using the normal VIDC palette).
• Added 32K colour support (was 64K but see below, 32K seems more "supported" in RISC OS)
• Firmware & FPGA bitstream easily field-updatable over USB
• Basically, all the games/demos I've tried worked. Only caveats are dynamic palette-switching (a la RasterMan) as per previous post.

Ahh the fun colour modes! Sorry, more haphazard screenshots ahoy. In the ArcDVI-sw repo is a module providing some new modes.

For the 256 colour Extended Palette modes, got them going outside the desktop relatively easily, with lovely gradients:

The top is drawn by writing directly to screen memory. The circles at the bottom are drawn via BASIC, though I failed to coax GCOL (col% >> 2) TINT (col% AND &c0) to choose colours 0-255 as you can see. Can't figure out what I'm doing wrong.
(See later for desktop...)

The precedent set by ColourCard is really for 32K RGB 555 (rather than 64K RGB 565). Here's a BASIC test of 32K colours:

I created a mode 107 to mimic the ColourCard's mode 107 (same res/depth). ColourCard's !Clearly application then works OOTB with mode 107 ( ) so you can display deep sprites/Clear files outside the desktop at 576x424 in 32K colours.

ColourCard's demo sprite:

Tram:

Flowers:

(As usual, photos of a glossy-screened field monitor with moiré patterns...) This 480K mode really chugs on my ARM2 A3000!

I happened to notice that CC supported 32K in the desktop by reimplementing ColourTrans and adding a SpriteExtend module. Both are in the CC Gold podule ROM; note they use an unconventional/reserved chunk type so that RISC OS doesn't load these, but they're chain-loaded (selectively?) by the DesktopLoader module. Anyway ... clever them! Loading them here, and selecting mode 107, the desktop works in 32K colours (!!!!):

Very very slowly, poor A3000. But I'm surprised, I didn't think this would work! !Draw is well-behaved w.r.t. choosing colours via ColourTrans; other apps not so. !Paint is explicitly disabled by the CC Gold modules.

I found the 256 colour modes loads more painful to get working in the desktop, mainly because I claimed PaletteV wrong and wrote broken code that made every colour look like black to ColourTrans. Having .. not done that, the desktop works in the extended modes. But I don't really know how to progress here with 256-entry palettes (palette files that large aren't supported on 3.1). The RM has a "grey" command which reprograms the palette to greyscale via ColourTrans, so some apps then pick up the palette and render correctly -- this is !Translatr displaying an 8BPP greyscale image:

Weirdly, !Draw doesn't display correctly at all in the grey state. I don't really know how the greyscale modes were supposed to work on other hardware (I saw a ColourCard for the first time in my life this month at CCH); a bit stumped about the palettes. I suppose I could try to hack !FlipTop to run and see if it'll set a grey palette (or try to RE it to see what it does).

One more screenshot. The 20cm flat flex cable (FFC) isn't great for signal integrity. Certain colour transitions cause corruption:

And, I just noticed mode 23 doesn't display at all with the 20cm FFC. The 10cm FFC displays both perfectly. This might only be my test monitor being very fussy (I'll try both on the LG, Dell and Sony displays I have access to), but investigations to do. (I don't think a 3 board approach will physically reach in an A-series with the short cable.)

Now just another PCB rev to make ... and decisions about PLCC plugs etc.

[IanJeffray]

Wowowow. That MODE 107 desktop looks unbelievable, even despite having a ColourCard here!
I'm boggled to see you're doing all this on an ARM2 machine, thus also 8MHz bus -- and as such, I think it'd be interesting to see clock-reduced versions of standard modes, to free-up the bandwidth; MODE 27/28, and 31/32, for example, running at a still-useable 30Hz but generating a true 60Hz output would be just magic. Is it viable to trick the system to do this by masking every second vsync (and the following hsyncs) from VIDC on the "plug in" (not "plug over") interposer? I guess it's probably simpler just to generate new low-refresh MODE modules.

[sirbod]

I guess it's probably simpler just to generate new low-refresh MODE modules.

You could also shut the video DMA off and only turn it on when something changes in screen, with the DVI board caching the last video and pointer DMA. Then pass the pointer coordinates directly to the DVI via TickerV and have the DVI board handle the pointer itself when the DMA is off so it's updated at the DVI refresh rate.

This would get all the bus bandwidth back between frame updates and actually speed up the CPU

On the RO side you'd probably want a key to turn "low bandwidth" mode on or off unless you hook into the SWI vector and Wimp to pick up on anything that might affect the screen. Essentially enabling video DMA for one frame after the screen has changed.

For games that frame-switch, the write to the VIDC DMA would trigger a single frame of DMA, which you'd shut off when it hits flyback if the DMA registers been haven't changed by the game again.

Given the video is a bus hog on the A-series, you could potentially see quite a speed up of memory intensive tasks by doing this.

Yes, Lemmings looks normal AFAICT. But, I think it leaves a line or two so that the timer doesn't have to be dead-on (not unusual AFAIK).

Lemmings has about 8 lines to hide the palette swap.

Try SWIV as it has a rolling palette swap point that moves down the screen as it scrolls. If it's missed you'll notice the palette "snap" when the swap point wraps back to the top line.

[Mattmos]

Hi Ian,

Wowowow. That MODE 107 desktop looks unbelievable, even despite having a ColourCard here!

It looks like full-screen Arculator, except it’s slower and has a real floppy drive :S

I'm boggled to see you're doing all this on an ARM2 machine, thus also 8MHz bus -- and as such, I think it'd be interesting to see clock-reduced versions of standard modes, to free-up the bandwidth; MODE 27/28, and 31/32, for example, running at a still-useable 30Hz but generating a true 60Hz output would be just magic. Is it viable to trick the system to do this by masking every second vsync (and the following hsyncs) from VIDC on the "plug in" (not "plug over") interposer? I guess it's probably simpler just to generate new low-refresh MODE modules.

Ah I’m cheating already: in the corner of the screenshot you can see mode 107’s at 39Hz refresh. As I don’t have a VIDC enhancer, VIDC runs at 24MHz max – while it still uses lots of DMA bandwidth, mode 31 also runs slow (37Hz ish iirc) and the monitor just copes. I don’t have a science answer but remember modern monitors/TVs will display a 24Hz cinema input so already do the buffering/frame rate conversion you describe. I’ve found 24-80Hz seems to display fine. I don’t know how low this can go though; I might try an XGA or something at 20Hz…

I want to avoid full CC-like framestore at all costs: more chips to find, more expensive FPGA, more BOM cost, more complex/bigger board.

Nice idea tho; depending on the lower practical limit for monitors displaying low refresh rates, we could redefine modes like 31 to actually run slower, eg VIDC CR pixel clock selecting 16 instead of 24MHz; a proportional reduction in refresh rate and DMA B/W.

[IanJeffray]

I want to avoid full CC-like framestore at all costs

Ahh yes sorry. 3am brain not thinking correctly - forgot this was all achieved with just a line buffer!

[sirbod]

Ahh yes sorry. 3am brain not thinking correctly - forgot this was all achieved with just a line buffer!

As did I

[SKS1]

You could also shut the video DMA off and only turn it on when something changes in screen ...

Given the video is a bus hog on the A-series, you could potentially see quite a speed up of memory intensive tasks by doing this.

Your memory-intensive task would need to ensure adequate coverage of addresses as you'd no longer be refreshing all of the DRAM.

[IanJeffray]

You could also shut the video DMA off and only turn it on when something changes in screen ...

Given the video is a bus hog on the A-series, you could potentially see quite a speed up of memory intensive tasks by doing this.

Your memory-intensive task would need to ensure adequate coverage of addresses as you'd no longer be refreshing all of the DRAM.

I may be showing my lack of understanding of the architecture here, but AFAIK, VIDC DMA requests are unrelated to DRAM refresh.

[Mattmos]

… Then pass the pointer coordinates directly to the DVI via TickerV and have the DVI board handle the pointer itself when the DMA is off so it's updated at the DVI refresh rate.
(Snip)

there’s a position open for ArcDVI Grim RISC OS Hacks Software Lead!

Lemmings has about 8 lines to hide the palette swap.

Try SWIV as it has a rolling palette swap point that moves down the screen as it scrolls. If it's missed you'll notice the palette "snap" when the swap point wraps back to the top line.

Cool, thanks for the suggestion! This would be ideal to test future palette-snapshotting. (I’ll prototype audio first and see if the FPGA has any LUTs left; it’s getting near full and a second palette will eat FFs. :/ )

[Mattmos]

I may be showing my lack of understanding of the architecture here, but AFAIK, VIDC DMA requests are unrelated to DRAM refresh.

You remember correctly, fortunately MEMC deals with all that “over there”.

SKS1, remember things like !ArmSI will turn off Video DMA for that extra burst of perf, and you can stay like that for long periods just fine.

[sirbod]

there’s a position open for ArcDVI Grim RISC OS Hacks Software Lead!

I've actually coded some of what I described in ADFFS' VIDC20 emulator for GPU's, I just need to finish it off so it does stop blitting when there's no changes - the code is currently disabled. The knowledge won't be much use without a full video buffer on the DVI board though.

remember things like !ArmSI will turn off Video DMA for that extra burst of perf, and you can stay like that for long periods just fine.

I coded !Si (!ARMSi was someone else modifying my original) like that to get the true CPU speed specifically because of the VIDC bus hogging.

[SKS1]

I may be showing my lack of understanding of the architecture here, but AFAIK, VIDC DMA requests are unrelated to DRAM refresh.

You remember correctly, fortunately MEMC deals with all that “over there”.

SKS1, remember things like !ArmSI will turn off Video DMA for that extra burst of perf, and you can stay like that for long periods just fine.

Yes, but no, but ... in high-res modes that have short Vsync+porches all the DRAM refresh can be performed as a side-effect of VIDC requesting video data. Once Vsync+porches get long enough (low-res modes), MEMC has to be set up to perform the DRAM refresh during flyback, with video DMA taking over as normal otherwise. If video DMA is turned off, MEMC has to be set up to perform continual refresh. It's the same control register anyhow, there's a soft copy at a well-known location. Some will know all that and take it as a statement of the bleeding obvious, many more will not.

[Mattmos]

I may be showing my lack of understanding of the architecture here, but AFAIK, VIDC DMA requests are unrelated to DRAM refresh.

You remember correctly, fortunately MEMC deals with all that “over there”.

SKS1, remember things like !ArmSI will turn off Video DMA for that extra burst of perf, and you can stay like that for long periods just fine.

Yes, but no, but ... in high-res modes that have short Vsync+porches all the DRAM refresh can be performed as a side-effect of VIDC requesting video data. Once Vsync+porches get long enough (low-res modes), MEMC has to be set up to perform the DRAM refresh during flyback, with video DMA taking over as normal otherwise. If video DMA is turned off, MEMC has to be set up to perform continual refresh. It's the same control register anyhow, there's a soft copy at a well-known location. Some will know all that and take it as a statement of the bleeding obvious, many more will not.

Sorry, you’re right of course, I should have checked the MEMC data book before posting (from phone on a train)!

(If others are interested: p24 of it describes interaction between video DMA and refresh, then p73 which shows the mapping of DMA addresses to RAS refresh addresses; long and short of it is 1024 video DMA accesses (16KB) will touch all rows in 4MB DRAM.)

I dimly remembered the option to refresh during flyback, for “slow” display modes which don’t touch memory fast enough to maintain DRAM refresh timing. I’ll check the V flyback time of the ArcDVI low-refresh modes – do you know how a mode indicates to RISC OS that it needs extra refresh during flyback? Or is it up to an extension module to change MEMC config (via SWI) from the mode change service call?

[SKS1]

You remember correctly, fortunately MEMC deals with all that “over there”.

SKS1, remember things like !ArmSI will turn off Video DMA for that extra burst of perf, and you can stay like that for long periods just fine.

Yes, but no, but ... in high-res modes that have short Vsync+porches all the DRAM refresh can be performed as a side-effect of VIDC requesting video data. Once Vsync+porches get long enough (low-res modes), MEMC has to be set up to perform the DRAM refresh during flyback, with video DMA taking over as normal otherwise. If video DMA is turned off, MEMC has to be set up to perform continual refresh. It's the same control register anyhow, there's a soft copy at a well-known location. Some will know all that and take it as a statement of the bleeding obvious, many more will not.

Sorry, you’re right of course, I should have checked the MEMC data book before posting (from phone on a train)!

(If others are interested: p24 of it describes interaction between video DMA and refresh, then p73 which shows the mapping of DMA addresses to RAS refresh addresses; long and short of it is 1024 video DMA accesses (16KB) will touch all rows in 4MB DRAM.)

I dimly remembered the option to refresh during flyback, for “slow” display modes which don’t touch memory fast enough to maintain DRAM refresh timing. I’ll check the V flyback time of the ArcDVI low-refresh modes – do you know how a mode indicates to RISC OS that it needs extra refresh during flyback? Or is it up to an extension module to change MEMC config (via SWI) from the mode change service call?

Honestly can't remember, it has been QuiteAWhile(TM). Not having that bit of the RISC OS 2 kernel source, I would suspect that the VDU component of the kernel works it out from the mode parameters supplied. It does look as if for some reason I did publicly expose the MEMC control register soft copy sometime between Arthur 1.2 and RISC OS 2.0 build; perhaps SWI OS_UpdateMEMC wasn't fast enough when setting up a new mode after bashing the VIDC registers? Oh, if we only had the source to consult! It's all on an A440 lodged in Acorn's Drawing Office (now known as landfill, I'm sure).

[IanJeffray]

I may be showing my lack of understanding of the architecture here, but AFAIK, VIDC DMA requests are unrelated to DRAM refresh.

Yes, but no, but ... in high-res modes that have short Vsync+porches all the DRAM refresh can be performed as a side-effect of VIDC requesting video data.

Holy cactus. Ok. Every day is a school day - and today's a good 'un. I had no idea of your experience/involvement here. Wow!

[SKS1]

I may be showing my lack of understanding of the architecture here, but AFAIK, VIDC DMA requests are unrelated to DRAM refresh.

You remember correctly, fortunately MEMC deals with all that “over there”.

SKS1, remember things like !ArmSI will turn off Video DMA for that extra burst of perf, and you can stay like that for long periods just fine.

Yes, but no, but ... in high-res modes that have short Vsync+porches all the DRAM refresh can be performed as a side-effect of VIDC requesting video data. Once Vsync+porches get long enough (low-res modes), MEMC has to be set up to perform the DRAM refresh during flyback, with video DMA taking over as normal otherwise. If video DMA is turned off, MEMC has to be set up to perform continual refresh. It's the same control register anyhow, there's a soft copy at a well-known location. Some will know all that and take it as a statement of the bleeding obvious, many more will not.

Just fired up an A440/RISC OS 2 on Arculator - looks like that always has 'Refresh during flyback' mode selected.

P.~?&115 gives &D (or SYS "OS_UpdateMEMC",0,0 TO r0%: P.~(r0%>>8)&3: REM for those who prefer to do it properly), so that's sound DMA, video DMA, 'Refresh during flyback' [01]

Safest thing, I guess. Who knew that we'd left some performance fettered so?

[Mattmos]

Hello,

Still ongoing! Nichts moribund! Well, 2023 has as promised loosened up a bit of component availability, in particular cheap FPGAs. Parts aren’t all available from one source, but they’re in stock. So, I picked ArcDVI up again and today should receive PCBs for a prototype V2.

Three boards was fiddly and didn’t help in solving the goal of working for Axxx and A3000, so flip-flopped and went for two: one “VIDC end” to capture signals, and a back panel for the real work.

For Axxx, an interposer that plugs into the socket and has VIDC plug on top:

Or, for A3000, an upturned socket to vampire onto the soldered VIDC:

The weird shape makes it easier to trim off the tab and MIGHT then be usable in A5000.

They connect via FFC (more elegant) to the main board which will occupy a podule slot:

For A3000, this “should” (assuming my paper models are OK) stack onto the VIDC board and fit under the floppy drive. It needs a flat HDMI extension cable to then get to a socket outside the case (various on eBay), TBD how that might mount. (Someone creative with a laser cutter might fashion a plate?)

I chose an ADV7513 to generate the DVI signal; it’s more expensive but not discontinued and is documented.

At this stage really the physical/mechanical is the remaining open, ensure things fit in all (discrete VIDC) machines, maybe move mounting holes, etc.

Hopefully by July/Aug we should have news (just about to go away for work, feh).

Anyway, quick update! Ah, I’ll make a note to get these on GitHub.