CScreenDevice and BcmFrameBuffer resizing.

[ArnoldUK]

I'm creating my 'CScreenDevice' through the kernel as normal with the width and height passed in as the parameters for example I use size from config.txt then m_Screen(m_Options.GetWidth(), m_Options.GetHeight()).

Now the problem I have is after I have initialized the screen how would I then go about reszing the BcmFrameBuffer that the CScreenDevice automatically creates and initializes ?
How does one go about assigning a new BcmFrameBuffer to the CScreenDevice ?

I can create a seperate BcmFrameBuffer with a new width and height but that causes the inital CScreenDevice to show a black screen and the docs state that only 1 BcmFrameBuffer is supported with RPI1.

Would be useful to have a function called CScreenDevice.ResizeFrameBuffer(uint32_t newWidth, uint32_t newHeight).
Or maybe CScreenDevice.SetFrameBuffer(BcmFrameBuffer newFrameBuffer).

Thanks.

[rsta2]

You can define a pointer to a CScreenDevice object in CKernel and create it using new. It should be possible to delete this object later and recreate it with other width and height parameters. This will automatically recreate the CBcmFrameBuffer object in CScreenDevice with the new screen size and is the only supported way of resizing the screen. The current screen contents will get lost in this process and has to be redrawn, this is true.

[ArnoldUK]

I should of thought of that, not very elegant in my view, but simple and works. I was worried about creating memory leaks and the full circle stack collapsing. Thanks.

[rsta2]

Honestly resizing was not a requirement, when CScreenDevice was implemented. I added a method CScreenDevice::Resize() now on the develop branch.

[rsta2]

No problem. Just let me know, when the RPi version is available to test.

[ArnoldUK]

I would just like to thank you again for the resizing function which is working perfectly well now with my current re-release of the faux86 PC XT Emulator for all Raspberry Pi models. If you wish to give it a try, I have released v1.0 on my github page.
Faux86-remake Pre-Release Build V1.0 ARM-RPi

I think it would also be useful to add the resize function to the C2DGraphicsDevice also.
All the best to you.

[rsta2]

I tested your Faux86-remake on a Raspberry Pi 4B and it works quite well. Congrats!

A few notes:

• I had to add the following lines to the config.txt file:

[pi4]
kernel=kernel7l.img

Otherwise the firmware loads the kernel kernel8-32.img, if it exists on the SD card, also on the RPi 4.

• I had to comment out the lines, which explicitly set the HDMI mode:

#hdmi_group=0
#hdmi_mode=4
#hdmi_drive=2

Otherwise I got no display image. I don't know, if this is caused by my monitor, where some EDID entries are damaged.

• keymap=DE in cmdline.txt does not work and keyb gr, entered at the DOS prompt, says, that some file is missing.

Except from this, everything worked well. Seems to be a great project to me.

I will see, what I can do for C2DGraphics::Resize().

Cheers!

[ArnoldUK]

Great feedback and input, I will add your modifications to the relevent files. I did not have a Pi4 to test and wasn't sure which kernel to use for that model. The HDMI mode was tuned for my monitor so I will comment out that section. Booting the default A:\ drive in DOS does not have the codepage for keyb command.
If you set the path to PATH C:\DOS;C:\WINDOWS then keyb gr should work as I tested it today.

Obviously there are some issues than need fixing, like keyboard repeat and misaligned text cursor.
I'm still working on improving performance with multithreading support or maybe using the Circle scheduler tasks. At the moment the performance bottleneck is the blitting routine which converts the 32Bit RGB colour pixels to 16Bit. Also will be adding a menu overlay system to change settings on the fly without having to manually remove the sd-card.

Anyway, I'm really happy to hear my 1st feedback comment was positive. Cheers.

[rsta2]

Yes, keyb gr works, when running from C:\DOS. Thanks.

[rsta2]

C2DGraphics::Resize() has been added on the develop branch.

[ArnoldUK]

Thanks for that. I will be transferring all my rendering to the C2DGraphics class and using CBcmFrameBuffer to see if I gain any performance boost with the video buffer blitting. I'm using an 800 x 800 x 32Bit frame buffer and each screen update is taking around 15ms with CScreenDevice on a RPi 2.

[ArnoldUK]

I was thinking maybe it would also be a good idea to implement a mouse update function to see the screen size changes.
At the moment the only way to setup the mouse set screen size is throught the call to
CMouseDevice::Setup(unsigned nScreenWidth, unsigned nScreenHeight)
However when the screen is resized the mouse behaves out of sync with the new size.
I've tried calling the CMouseDevice::Setup function again after screen resize but this crashes the pi, maybe because it is designed to be called only once ??

[rsta2]

Yes, CMouseDevice::Setup can be called only once at the moment. I will have a look on it, if this can be changed.

[ArnoldUK]

Thanks! I looked at the function code myself but most of it I do not understand fully so I try not tinker with it too much, I leave that to the much more skilled :)

[rsta2]

There is a new method CMouseDevice::Release() available on the develop branch. You have to call it before resizing the screen. After resizing the screen you can call CMouseDevice::Setup() again.

[ArnoldUK]

Works great! I will close this topic now before it ends up as a dumping ground for all my feature requests.
Many thanks.