RiscPC support

[steve3000]

The clock is fixed on VIDC20 and the pixel rate is based on a divisor and modulus of it. The clock rate isn't really relevant to LCDgm on VIDC20, you just need to let ADFFS know what pixel rate you want and it will work out the divisor, modulus and FIFO settings based on the reference clock.

I understand that.

So does ADFFS work out this all out from the VIDC1 CR during translation?

LCDgm is written for a VIDC 1, where you specify input clock (24MHz, 25MHz or 36MHz) and a divisor (1/3, 1/2, 2/3 or 1/1) which is provided in the VIDC 1 CR. LCDgm uses 24MHz clock and selects the divisor based on the Mode.

Will this work on ADFFS, or will I need to rewrite LCDgm to calculate the pixel rate/etc?

[JonAbbott]

Yes, ADFFS works it all out based on VIDC1 CR and the clock being a stock 24Mhz.

No need to change your code, I just need to multiply the VIDC20 pixel rate by AutoVIDC_SetClock/24MHz when CR is set.

[JonAbbott]

No need to change your code, I just need to multiply the VIDC20 pixel rate by AutoVIDC_SetClock/24MHz when CR is set.

This is now done, ADFFS 2.16b module on the dev site.

AutoVIDC_SetClock must be called after a MODE change and prior to writing CR, as it only tracks the VIDC1 clock rate. On the next CR write, ADFFS will use the VIDC1 clock passed to AutoVIDC_SetClock and the CR pixel rate divisor to calculate the required VIDC20 pixel rate.

If AutoVIDC_SetClock hasn't been called since the last MODE change, it presumes a VIDC1 clock of 24MHz.

[steve3000]

This is now done, ADFFS 2.16b module on the dev site.

AutoVIDC_SetClock must be called after a MODE change and prior to writing CR, as it only tracks the VIDC1 clock rate. On the next CR write, ADFFS will use the VIDC1 clock passed to AutoVIDC_SetClock and the CR pixel rate divisor to calculate the required VIDC20 pixel rate.

If AutoVIDC_SetClock hasn't been called since the last MODE change, it presumes a VIDC1 clock of 24MHz.

Wow, that was quick

Currently LCDgm does this the other way round - it sends all the VIDC parameters including CR first, then works out whether an input clock change is required using AutoVIDC and if necessary fires off the SetClock command. So I'll need to have a play with LCDgm to reverse the order tomorrow.

But triggering the VIDC20 clock speed recalc based on VIDC1 CR is definitely good - there are certainly a few demos which build their modes completely so set their pixel rate via CR, although I'm not sure any games do this (maybe some ancient Arthur ones...?).
Steve

[JonAbbott]

I'm not aware of any games that set CR, all the ones we've marked as needing LCDgm set geometry only.

I did look at getting AutoVIDC_SetClock to set the clock, however it would need to know the required pixel rate as well...meaning adding the type 4 SVGA RO3.1 MODE table in - something we didn't want to do.

So long as you can swap the order without any issues, happy days.

[steve3000]

I'll have a quick go at the weekend and see where I get to. It's not difficult to swap the order, but will need testing to ensure no side effects happen on RO3.1 systems as a result.

With ADFFS loaded, if i shell out of the desktop, do I just issue "adfremapvideomemory 13 160" to switch on translation, then drop into Basic to run some vidc1 tests?

[JonAbbott]

With ADFFS loaded, if i shell out of the desktop, do I just issue "adfremapvideomemory 13 160" to switch on translation, then drop into Basic to run some vidc1 tests?

Yes

EDIT: I should add, I've done no testing of these changes. I'll put the source on the dev site tomorrow morning, just in case there are issues.

[JonAbbott]

I've put the source on the dev site, changes are:

adffs.vectors.vidc_abort: Re-coded _VIDC_control to divide the VIDC1 clock to get the adjusted pixel rate.

adffs.service: Added two lines to _skip_bitdepth to default the VIDC1 clock rate to 24MHz after a MODE change. I'm not sure if RO resets the clock on a MODE change or not, but it seemed like the most logical place to reset considering LCDgm will change the clock. Obviously the order the modules are called is an issue here, we may need to comment the two lines out or move them to _premodechange:

Code: Select all

MOV     R0, #VIDC1_reference_clock
STR     R0, VIDC1_clock

adffs.vectors.swi: Added four lines to _P2 to trap the AutoVIDC SWI block on RO3.5+

Added adffs.vectors.swi_AutoVIDC to handle the AutoVIDC SWI block.

[steve3000]

Jon, I've been properly playing with the VIDC translation this evening. First impressions - it's very good

I had prepared a set of 'simple' VIDC tests a while ago (not testing CR though, more on that in a sec), the tests poked individual registers here and there to see the response. Overall the translation passed very well - no internal errors, and most registers did approximately what they should.

The palette registers appear perfect, but something is not 100% correct with the display registers - for example, if I select Mode 13 on the RPC (on a TV monitor) and then I poke the Mode 13 definition into the VIDC1 registers (excluding CR), the whole screen shifts to the right slightly ~1 pixel. Not the end of the world by any means, but I'll need to take a look at your translation code tomorrow

Finally, the CR. This really isn't working right. If I poke Mode 13 values into VIDC 1 registers and I include CR in my list, then the screen goes crazy... I monitored the refresh rate from BASIC, using WAIT commands, with the following result: RPC Mode 13 = 50.1 Hz, but after poking the Mode 13 definition with CR, I get 16.1 Hz ! I'm sure it just needs a little tweak... so I'll look at this too...

As the palette registers are translating well - I decided, just for fun, to run a few of my old Arc 'Raster' routines, which hammer VIDC1 and IOC, redefining the palette on every raster. These have *never* worked on the RiscPC. IOMD overlaps the IOC addresses for Timer1 - which I'm using, so no problem there, but obviously VIDC20 isn't naturally mapped to VIDC1, so that'll be the big test of the ADFFS translator.

Result - 100% perfect Raster bars, under VIDC1 translation! This is particularly impressive as the palette is redefined on every raster, and there is absolutely no flicker or 'overflow' onto the next line.

I then tried running my !RasterMan demo. This uses a highly optimised palette redefinition system, changing 6 colours on every raster line... but sadly this didn't work under translation. No crash though - just no colours. As RasterMan uses STMIA R0!,{R1-R6} to set the 6 palette registers on each line (whereas the previous raster code used STR) - I expect there's a problem with STM in the translator? Is this supported?

Steve

[JonAbbott]

something is not 100% correct with the display registers - for example, if I select Mode 13 on the RPC (on a TV monitor) and then I poke the Mode 13 definition into the VIDC1 registers (excluding CR), the whole screen shifts to the right slightly ~1 pixel.

No problem, we just need to increase the horizontal values I suspect.

Finally, the CR. This really isn't working right. If I poke Mode 13 values into VIDC 1 registers and I include CR in my list, then the screen goes crazy... I monitored the refresh rate from BASIC, using WAIT commands, with the following result: RPC Mode 13 = 50.1 Hz, but after poking the Mode 13 definition with CR, I get 16.1 Hz !

Not surprising, I've long suspected this code wasn't right. What values were you writing for VIDC1 clock / CR?

I then tried running my !RasterMan demo. This uses a highly optimised palette redefinition system, changing 6 colours on every raster line... but sadly this didn't work under translation. No crash though - just no colours. As RasterMan uses STMIA R0!,{R1-R6} to set the 6 palette registers on each line (whereas the previous raster code used STR) - I expect there's a problem with STM in the translator? Is this supported?

Yes, STM is supported. I'm double checking the code.