forums.jaspp.org.uk

Horizontal, if you look in vectors.vidc_abort at _VIDC_horizontal, R3 is the register used to adjust the values to match the VIDC20 documentation, some or all of them will need adjusting.
All except HCSR have bit 0 cleared and HCR has bits 0 and 1 cleared, so all R3 values will need adjusting by -2 or -4 if it's HCR that's wrong. A quick way to check if it's all that need adjusting would be to find the SUBLO R0, R0, R3 near the end and add SUBLO R0, R0, #2 after (implemented in the adffs-2 module). I suspect it's not all values though, so may need some testing to find which.

STM code looks okay, I didn't spot anything glaringly obvious at any rate. Upload your test code so I can test under emulation. I did test STM way back, so something could be broken further up the chain.

I did however notice a bug in the CR code, which was corrupting one of the STM code's registers. I've uploaded the fixed ADFFS module and source to the dev site.

EDIT: I've now tested the STM code and confirmed it's working, so the issue must be further down the VIDC code.

EDIT2: The pixel rate issue...what I've been unable to establish in Acorn docs is which clocks are set to which value. At the top of adffs.vectors.vidc_abort there are two #set values which may need changing:

reference_clock is the clock speed of the reference clock
RCLK determines which reference clock to use. 0 - VCLK, 1 - HCLK, 2 - RCLK

According to the doc "ARM DDI 0030E", RCLK is "recommended" to be 24MHz - which being the only figure I could find, is what the code is using. It could well be that RCLK isn't even used on the RiscPC and we have to use VCLK. We need the RiscPC TRM's to know for sure.

EDIT3: I've just found the RiscPC TRM, which I've put on the dev site. 1-14 says the reference clock is 64MHz, which is contradicted on 1-17 where its shown as 24MHz. Acorn_RPCTRM_MainPCBCircuiDiagram5of7.pdf (in RiscPCTRM_Drawings.zip) however clearly states RCLK (pin 124) is 24Mhz, so it must be a coding issue where I'm working out the pixel rate. If you let me know the VIDC1 clock and CR value I'll debug the code and check what pixel rate we end up with.

Just noticed I wasn't actually storing the clock when AutoVIDC_SetClock was called. Updated source / adffs and adffs-2 modules on the dev site.

JonAbbott wrote:Just noticed I wasn't actually storing the clock when AutoVIDC_SetClock was called. Updated source / adffs and adffs-2 modules on the dev site.

I've downloaded both - what's the difference between the two?

Also the source zip archive in the dev directory seems to be corrupt (it won't open for me with SparkFS or ArcFS...) any chance you can load up another copy?

Source uploaded

adffs-2 is identical except it subtracts 2 from the horizontal commands, to see if it fixes the horizontal shift you noticed.

If you've not done so already, could you please upload the latest LCDGameModes source, so I can test next week and hopefully fix the pixel rate issue before you return.

The test code for the raster palette would be useful as well, to investigate the STM issue.

Testing in MODE 13 and writing &E000000C which should set 8 bit/pixel 8 Khz pixel rate, it's coming back with:

VMOD = 7
RMOD = 3
CK = 7

Which is correct according to the docs:

Pixel rate = (VMOD / RMOD * RCLK) / CK
Pixel rate = (7 / 3 * 24000) / 7
Pixel rate = 56000 / 7
Pixel rate = 8000

The values written to VIDC20 are:

D0000602
E000047A

Ok, I'll need to look into those values further, but out of time now.

I did go back and try something else - I issued *ADFRemapVideoMemory 27 320, to select Mode27, so I could try on the LCD screen. I then poked in the full Mode27 mode definition - line by line, pressing a key between each parameter, finishing with CR. The horizontal shift happened at HDSR (more on that below), but all was going well and everything was still visible until CR. After CR was poked, the screen went off and I get 19.1 Hz reported.

So today has been busy, but between planning for holiday (next weekend), mowing the lawn and catching up on critical work emails... I managed to find some time to look properly at VIDC1 to VIDC20 translation.

I checked again the ADFFS-2 module, and the horizontal shift was still happening... I had a guess that this might be to do with HDSR/HDER as these are bpp specific on VIDC1 and a pain to get right at the best of times. So before looking at ADFFS source (as it was a bad zip this morning), I decided to write my own VIDC1 to 20 translator.

I started in BASIC, and moved to Arm. Didn't take too long - but then I got carried away and started optimising like crazy... Result is I now have a highly optimised Arm code VIDC1 to 20 translator. So I then set up an automated test routine - feeding in my set of RISC OS 3.1 built-in mode definitions (from the RO source) and comparing these to the RISC OS 3.5 set of definitions which I also have

The result, after a few rounds of tweaking here and there, is I am now pretty much 100% sure that my translation algorithm is correct for all video/palette registers. But I didn't do a full CR translation, other than pull out bpp and the clock divisor bits (definitely no point in me duplicating your optimised clock code) and I didn't do sound registers.

My code 'VIDC1to2,ffb' is now in the LCDGameModes.VIDCtranslator directory on the ftp site - run it to see.

As a final test, tonight I pulled out your translator code and popped it into a quick Basic program, to compare the two translators. See file 'VIDCompare,ffb'. It shows up a few differences between our code output. First, your palette translation doesn't expand the high bits to the low bits (ie. you translate &F to &F0, whereas I chose to go &F to &FF...so my output is slightly brighter, but tbh unlikely anyone will ever notice). Your translation of the following VIDC1 registers is slightly out: &8C, &90 (causing the H shift!), &9C, &B0, &B8 and &BC. Most are just out by 1 - so it's minor, just a single line/pixel shift in places.

Please run the code and have a play. I'm going to be away from RISC OS machines for ~2 weeks now, away from home this week with work, and next week on holiday. Still on email though.

So I'll leave it to you on what to do with the translator - to tweak your code, or patch mine into ADFFS (which I'm happy for you to do - and it's quite obvious how it works, so should be easy to do - it's not entirely the same as yours, but you'll get the idea).

Steve

You didn't upload the source for LCDGameModes or let me know the VIDC1 clock / CR values

I've fixed HDSR / HDER though, thanks for the comparison code. All the other values seemed to match except HIR, which you have as N instead of N/2.

JonAbbott wrote:You didn't upload the source for LCDGameModes or let me know the VIDC1 clock / CR values

No problem - I popped a copy of some useful bits and pieces (including the modified LCDgm source) on my laptop this morning. I'll email to you as can't access FTP on the laptop.

JonAbbott wrote:I've fixed HDSR / HDER though, thanks for the comparison code. All the other values seemed to match except HIR, which you have as N instead of N/2.

Be careful - HIR should not be N/2. From the VIDC20 tech docs - "if L is written into HCR then HIR should be L/2". The 'L' referred to is the total of all horizontal pixel time (ie. N = 800), subtract 8, which is programmed into HCR_vidc20, in units of 1-pixel, so in Mode 27 this is 792. HIR_vidc20 is therefore (792/2)=396.

This is (effectively) the same as what's done on VIDC1, but in units of 2-pixels, so HCR_vidc1 is the total (N-2)/2, so in Mode 27 HCR_vidc1 is 399. HIR_vidc1 is (399+1)/2 = 200.

So to translate, HIR_vidc20 = (HIR_vidc1 * 2) - 4 [ie. you just need to subtract 3 from the VIDC1 decoded value 399, and not divide by 2]

...however, RISC OS itself does not subtract the 4 in its VIDC20 mode definitions (according to it's source), so my translation followed RISC OS and leaves this as (HIR_vidc1*2)... But RISC OS might well be wrong here...

I think we shuold go with the docs, so (HIR_vidc1 * 2) - 4

Did you correct the palette entries? Just need a ORR Rx,Rx,LSR#4 to double up the colours to the correct brightness.

And did you look at &B0 VDSR, &B8 VCSR and &BC VCER?