I've double checked HSWR (&1474), VSWR (&1478), ereg (&13D0), fsynreg (&13D4) and conreg (&13D8, &1584) against the soft copies in ZP that RO uses, when using the LCDgm mode file ... they're identical, so we can rule them out.
That leaves the geometry parameters, DCTL and anything else RO may do. I've followed through the RO mode change code at least half a dozen times now, and I'm certain we're not missing anything. Vinit, Vstart, Vend etc won't be affected by us, neither will the palette. I've tried turning video DMA off before changing and back on after, to mirror RO...no change. I've added the fsynreg reset code...no change.
I'm at a loss to explain the problem we're seeing. Short of something daft, like the order we're programming the registers, I've really no idea why it works with the mode file and not by directly writing values.
EDIT: Why does increasing VCR fix the problem? For stock MODE 13, we only need to increase VCR by 2 - that implies the monitor can't lock on the vsync or that the parameters we're using are borderline.
RiscPC support
Re: RiscPC support
Yes, have to say I'm struggling too. I'm convinced it is memory / DMA related. I was trying to find out whether VRAM places additional restrictions on screen size, but can find nothing to support that...
On the basis that RISC OS gets it right with the mode definition file, my next thought was to use RedSquirrel or RPCEmu to list the register settings for VIDC20 and IOMD following a mode change using the LCDgm mode file. No idea if thats easy to do, but it would help us. Although only if they actually emulate VRAM, and not a Large DRAM block?
On the basis that RISC OS gets it right with the mode definition file, my next thought was to use RedSquirrel or RPCEmu to list the register settings for VIDC20 and IOMD following a mode change using the LCDgm mode file. No idea if thats easy to do, but it would help us. Although only if they actually emulate VRAM, and not a Large DRAM block?
Re: RiscPC support
We know its memory related as it changes with RAM size and type. This hints at DCTL and/or MEMC not being quite right.
I spent a few hours last night trying different settings for DCTL, looking at the relevant RO code and reading the VIDC20 TRM. What Jumps out (not related), is that RO doesn't configure VIDC20 correctly for VRAM, certainly not how it's stated in the TRM. The TRM is quite specific that when VRAM is used, VIDC20 BUS should be split in 63:31 mode (section 3.5). RO uses either 32bit in 31:0 mode or 64bit in 63:0 mode, both in Synchronous mode, but turning the VRAM DMA clock off. In both these modes, the system bus is used to transfer data, which seems a major flaw in the RiscPC design to me!
Anyhow, what we can gain from this is that timing during video flyback is probably critical when in Syncronous mode if Hdis is disabled - Hdis gets disabled if the display width isn't a multiple of 32, or 64 in the case of 2mb VRAM.
The issue we're seeing is symptomatic of the FIFO either being ahead or behind...increasing VCR increases the flyback time and hints at the FIFO being behind. Assuming that is the case, why is it happening? And how do we fix it?
I spent a few hours last night trying different settings for DCTL, looking at the relevant RO code and reading the VIDC20 TRM. What Jumps out (not related), is that RO doesn't configure VIDC20 correctly for VRAM, certainly not how it's stated in the TRM. The TRM is quite specific that when VRAM is used, VIDC20 BUS should be split in 63:31 mode (section 3.5). RO uses either 32bit in 31:0 mode or 64bit in 63:0 mode, both in Synchronous mode, but turning the VRAM DMA clock off. In both these modes, the system bus is used to transfer data, which seems a major flaw in the RiscPC design to me!
Anyhow, what we can gain from this is that timing during video flyback is probably critical when in Syncronous mode if Hdis is disabled - Hdis gets disabled if the display width isn't a multiple of 32, or 64 in the case of 2mb VRAM.
The issue we're seeing is symptomatic of the FIFO either being ahead or behind...increasing VCR increases the flyback time and hints at the FIFO being behind. Assuming that is the case, why is it happening? And how do we fix it?
Re: RiscPC support
You might well be right on the time critical part.
I recall seeing some comments in the RO source, somewhere near the Fsyn code during mode change - along the lines of 'may need some delay here' or something? I'll look it up when I'm home tonight...
The 63:31 mode just tells VIDC20 to expect data on the upper half of the 64bit bus, but this mode isn't used by RO. I understood that the 64bit bus was latched so that there is no involvement with the system bus during DMA?
I recall seeing some comments in the RO source, somewhere near the Fsyn code during mode change - along the lines of 'may need some delay here' or something? I'll look it up when I'm home tonight...
The 63:31 mode just tells VIDC20 to expect data on the upper half of the 64bit bus, but this mode isn't used by RO. I understood that the 64bit bus was latched so that there is no involvement with the system bus during DMA?
Re: RiscPC support
We're not programming IOMD register &90 'FSIZE' (flyback line size) see RPC TRM page 1-8. This could well be the problem...
Edit: It almost certainly is, see page 1-14 of RPC TRM.
Edit: It almost certainly is, see page 1-14 of RPC TRM.
That would also explain the VCR bodgeAt the start of each frame, IOMD does a full transfer to VRAM to initialise the video pointer in the SAM...IOMD counts the flyback lines, and when the last line but one is reached, it does the transfer. The 8 bit FSIZE register in IOMD is programmed with the number of flyback lines minus 1.
Re: RiscPC support
It works!
Run 'pokeLCDgm' in the Development/LCDGameModes ftp folder.
Run 'pokeLCDgm' in the Development/LCDGameModes ftp folder.
Re: RiscPC support
Brilliant, well spotted. I'm in Rome at the minute but will fix when I get back next week.steve3000 wrote:It works!
Run 'pokeLCDgm' in the Development/LCDGameModes ftp folder.
Re: RiscPC support
Enjoy Rome, it's an amazing place!JonAbbott wrote:Brilliant, well spotted. I'm in Rome at the minute but will fix when I get back next week.
Re: RiscPC support
ADFFS updated with FSIZE code and the VIDC1 to 20 translation now works correctly - allowing LCDGameModes (dev. version 0.22c) and JamesPond to produce this:
This is running on RISC OS 3.70, with 64Mb RAM and 2Mb VRAM. Success!
I've uploaded ADFFS 2.16v module to the Development/ADFFS ftp folder and the development version LCDGameModes 0.22c is the module in the Development/LCDGameModes folder.
Jon - I've also uploaded my source to the ADFFS folder as a ZIP, I've added a file "216v_Info" which details where I've made the changes to get this working.
If anyone else watching wants to try this on the RiscPC, here's the best way I've found: First load ADFFS 2.16v module, then load LCDGameModes 0.22c module. Now run !ADFFS (a recent version) to load the filer, don't worry - this won't load the older module though. Open the JFD of your choice. Then exit the desktop (press Ctrl-Shift-f12 twice). Enable video memory remapping with the command *ADFREMAPVIDEOMEMORY 13 160 and then type *LCDGameModes On ... Now, if you type *Echo <22><13> - the screen should reappear in LCDGameModes format. Type *Drive 0 then *Run your game...eg. *!JamesPond - and enjoy...!
- JamesPond on RiscPC 2Mb VRAM, ADFFS 2.16v
- tn_jpriscpc.jpg (23.2 KiB) Viewed 14237 times
I've uploaded ADFFS 2.16v module to the Development/ADFFS ftp folder and the development version LCDGameModes 0.22c is the module in the Development/LCDGameModes folder.
Jon - I've also uploaded my source to the ADFFS folder as a ZIP, I've added a file "216v_Info" which details where I've made the changes to get this working.
If anyone else watching wants to try this on the RiscPC, here's the best way I've found: First load ADFFS 2.16v module, then load LCDGameModes 0.22c module. Now run !ADFFS (a recent version) to load the filer, don't worry - this won't load the older module though. Open the JFD of your choice. Then exit the desktop (press Ctrl-Shift-f12 twice). Enable video memory remapping with the command *ADFREMAPVIDEOMEMORY 13 160 and then type *LCDGameModes On ... Now, if you type *Echo <22><13> - the screen should reappear in LCDGameModes format. Type *Drive 0 then *Run your game...eg. *!JamesPond - and enjoy...!
Re: RiscPC support
Finally had time to update everything...ADFFS 2.17 full ZIP uploaded. Several other files have changed to allow auto-loading of the correct version of LCDgm, depending on OS / VIDC20 presence, so I've not uploaded the individual ADFFS module.
lcdgm022c source has also been uploaded. It now calls XADFFS_Info (8) to check if VIDC1 translation is enabled before trying to do anything, this allows it to be enabled in the ADFFS !Boot and only take effect if a JFD enables VIDC1 translation (or it's enabled manually via *ADFRemapVideoMemory). I've also changed the compiled filename to LCDgmVIDC2 so both VIDC1 and VIDC20 versions can co-exist in the !ADFFS folder.
ADFFS now requests VIDC20's address from the OS for future compatibility, it also requests the IOMD address on RO5+.
FSIZE is re-calculated if any of the parameters change (VDSR, VDER or VCR).
It needs testing on all VIDC1 / VIDC20 platforms (except A7000 as the code isn't there yet). Provided you're using the JFD's with boot scripts (and/or have copied the obey.zip into the folder and have SparkFS running), simply loading !ADFFS and selecting "Boot floppy" should start the game, no manual intervention should be required.
Steve, if you'd like to update your LCDgm22 source code and check you're happy with it, I think we can start proper testing and look at releasing ADFFS finally.
EDIT: Looks like only Pesky Muskrats is working correctly. I took a guess at the FSIZE calculation as I couldn't find any detail on it, it's at the end of the vertical code and uses (VCR - (VDER - VDSR)) + 1
lcdgm022c source has also been uploaded. It now calls XADFFS_Info (8) to check if VIDC1 translation is enabled before trying to do anything, this allows it to be enabled in the ADFFS !Boot and only take effect if a JFD enables VIDC1 translation (or it's enabled manually via *ADFRemapVideoMemory). I've also changed the compiled filename to LCDgmVIDC2 so both VIDC1 and VIDC20 versions can co-exist in the !ADFFS folder.
ADFFS now requests VIDC20's address from the OS for future compatibility, it also requests the IOMD address on RO5+.
FSIZE is re-calculated if any of the parameters change (VDSR, VDER or VCR).
It needs testing on all VIDC1 / VIDC20 platforms (except A7000 as the code isn't there yet). Provided you're using the JFD's with boot scripts (and/or have copied the obey.zip into the folder and have SparkFS running), simply loading !ADFFS and selecting "Boot floppy" should start the game, no manual intervention should be required.
Steve, if you'd like to update your LCDgm22 source code and check you're happy with it, I think we can start proper testing and look at releasing ADFFS finally.
EDIT: Looks like only Pesky Muskrats is working correctly. I took a guess at the FSIZE calculation as I couldn't find any detail on it, it's at the end of the vertical code and uses (VCR - (VDER - VDSR)) + 1