From looking at my VLSI manual on the original chipset, it states:
Vinit is set on a 16 byte boundary
HDSR is always even
HDER is always even
Horizontal display width (HDER-HDSR) must be a multiple of 128 bits.
So...for a 4bpp MODE:
Vinit is a multiple of 8 pixels
Display width is a multiple of 32 pixels
For a 8bpp MODE:
Vinit is a multiple of 4 pixels
Display width is a multiple of 16 pixels
Only problem is, this doesn't seem to be true. James Pond for example uses an 8 bpp MODE, 318 pixels wide and a 4 bpp MODE, 300 pixels wide - neither of which are multiples of 128 bits.
What are the restrictions on the Display width on VIDC1?
VIDC1 parameter restrictions
Re: VIDC1 parameter restrictions
Have to be careful here.
JP may use a 300 width 4bpp *apparent* visible screen...however it generates this by using a 320 pixel wide frame area (HDER-HDSR), and reducing the visible size by moving the screen borders inwards. This is the way to implement hardware horizontal scrolling on VIDC1:
For example...Start with an unscrolled 4bpp screen displaying bytes 000-143 (288 pixels only, by moving HBER back to cover over 32pixels of the right-edge of the screen) of a 160 byte line. You then have a second, third and forth frame buffer, drawn at an offset of 2, 4, 6 pixels respectively. Switching between these offset frames gives 2-pixel accurate horizontal scrolling, when you reach 8 pixels, go back to the first frame, shift HDSR and HDER left 8 pixels and the borders right by 8 pixels. Overall the screen position is the same but the scroll has happened. The visible area is now bytes 004-147.
Repeat the above until you are displaying bytes 012-155. The next jump would be to bytes 016-160... However offset 16 is on a 128 bit boundary, so now you can move the MEMC Vstart pointer to byte 016, reset HDSR and HDER and borders to their start positions, and loop again from the start of the above...
They did like to make you really think out of the box, back in the days of VIDC1...
JP may use a 300 width 4bpp *apparent* visible screen...however it generates this by using a 320 pixel wide frame area (HDER-HDSR), and reducing the visible size by moving the screen borders inwards. This is the way to implement hardware horizontal scrolling on VIDC1:
For example...Start with an unscrolled 4bpp screen displaying bytes 000-143 (288 pixels only, by moving HBER back to cover over 32pixels of the right-edge of the screen) of a 160 byte line. You then have a second, third and forth frame buffer, drawn at an offset of 2, 4, 6 pixels respectively. Switching between these offset frames gives 2-pixel accurate horizontal scrolling, when you reach 8 pixels, go back to the first frame, shift HDSR and HDER left 8 pixels and the borders right by 8 pixels. Overall the screen position is the same but the scroll has happened. The visible area is now bytes 004-147.
Repeat the above until you are displaying bytes 012-155. The next jump would be to bytes 016-160... However offset 16 is on a 128 bit boundary, so now you can move the MEMC Vstart pointer to byte 016, reset HDSR and HDER and borders to their start positions, and loop again from the start of the above...
They did like to make you really think out of the box, back in the days of VIDC1...
Re: VIDC1 parameter restrictions
For a really good spot that this is how JP works - load it up, start a game, watch as the screen scrolls left/right during the mission briefing... Look at the bottom left corner of the display. You see on the bottom left corner, a single row of corrupted pixels appear and disappear as the screen scrolls - this is easy to miss, but it is a bug, because someone forgot to re-plot the bottom left tile as screen scrolled left, using the above technique
Re: VIDC1 parameter restrictions
I have understood the restrictions correctly then, I just need to handle DA2 in blocks of 16 bytes and use HBER-HDSR for the visible display width where HBER<HDER. Where (Display Width * bpp) MOD 256 > 0, I jump 16 bytes at the end of each scanline in the GPU frame buffer to wrap to the next scanline.
The end result being that the visible display width is a multiple of 2 pixels and the physical display width is a multiple of 128 bits in DA2 and 256 bits in the GPU frame buffer.
That's rather convenient for optimizing the code.
The end result being that the visible display width is a multiple of 2 pixels and the physical display width is a multiple of 128 bits in DA2 and 256 bits in the GPU frame buffer.
That's rather convenient for optimizing the code.
Re: VIDC1 parameter restrictions
On second thoughts, I think I have that wrong. I'll need to account for HBSR>HDSR as HBSR and HBER will need to change together to keep the display width the same.
That vastly complicates the code as it will need to shift the words right 2, 4 or 6 pixels in a 4 bpp MODE.
I might pause development of the DA2 frame buffer and start on the ARM JIT, I really need some games running that I can use to check the VIDC side.
That vastly complicates the code as it will need to shift the words right 2, 4 or 6 pixels in a 4 bpp MODE.
I might pause development of the DA2 frame buffer and start on the ARM JIT, I really need some games running that I can use to check the VIDC side.
Re: VIDC1 parameter restrictions
Yes, it was a real pain BITD writing code to successfully implement hardware scrolling in this way...!JonAbbott wrote:On second thoughts, I think I have that wrong. I'll need to account for HBSR>HDSR as HBSR and HBER will need to change together to keep the display width the same.
That vastly complicates the code as it will need to shift the words right 2, 4 or 6 pixels in a 4 bpp MODE.
Ah well - I'd be happy to have a go at working up some conversion code, and see how it performs?
I've already written an efficient routine to perform 4bpp to 32bpp on a fixed 640x256 screen (Mode12), and allow palette redefinitions on each scanline, so I can convert some demo code which uses time raster bars over onto the Pi. I've put this up on the ftp site, under development/32bit/4bpp modes/ - you'll need to run it on a Pi though.
This code really shows the superiority of the RPi memory speed and CPU - during benchmarking, my StrongArm RPC managed to convert ~30 screens per second on RISCOS 4 and only ~19 screens per second on RISCOS 5.19, but the RPi can do close to 600 per second!
Steve
Re: VIDC1 parameter restrictions
Thanks, I'll take a look at the code, sounds like you've spent a bit of time on it. I've yet to look at implementing the IOC clocks so I can implement mid-frame palette changes. I'm busy rejigging the ADFFS source code at the minute, which will end up with three versions of the module, IOC, IOMD and StrongARM+. Hoping to have it up on dev site next week.steve3000 wrote:JonAbbott wrote:This code really shows the superiority of the RPi memory speed and CPU - during benchmarking, my StrongArm RPC managed to convert ~30 screens per second on RISCOS 4 and only ~19 screens per second on RISCOS 5.19, but the RPi can do close to 600 per second!
I too was amazed at the Pi speed as well, Zarch was running at several hundred FPS.