ugBASIC forum

Hi

I am trying to use double buffered screen with the Dragon target, but is seems unsupported. My code is below, please let me know if I am doing something wrong.
I tried to implement it myself with peek and pokes. Accordingly to the Dragon 32 Programmers' Reference Guide (page 40):

The area is from 1024 (&H400 ) upwards. The minimum size for this area in BASIC is 2048 (2 K) bytes (enough for the tex1 screen and one graphic page)

but if I try to put a second screen starting at 1024+512, this overwrites the ugBASIC program (I think, as everything goes insane).

Is there a way to either implement the double buffer on this platform or at least to specify the size for the screen memory / start address of ugBASIC program?

Hi clovepower!

clovepower wrote: ↑Sun Jul 07, 2024 7:43 am I am trying to use double buffered screen with the Dragon target, but is seems unsupported.

I confirm that it is currently not supported under Dragon 32/64. DOUBLE BUFFER is supported only for the following targets: c128 c64 (limited to text mode only), to8 pc128op coco3 (limited to graphics mode). There is no support for the Dragon 32/64 nor the TRS-80 Color Computer 1/2 (both equipped with the Motorola 6847).

However, I added a ticket to introduce the support for this video chipset:
Double buffer under 6847 #799

While waiting for implementation, you can use the WAIT VBL line workaround, which allows you to wait for the video raster to cross the vertical line before continuing with execution. This should give time to the Mororola 6809 processor and Motorola 6847 video processor to draw changes to the screen, without flickering. A technique of this kind has been implemented on source on Falling Balls.

clovepower wrote: ↑Sun Jul 07, 2024 7:43 am My code is below, please let me know if I am doing something wrong

The code is correct, but I don't know if it would give the desired result: this is because there is no synchronism with the vertical blank. That is, the WAIT VBL statement is missing. Without this instruction, the SCREEN SWAP instruction could occur anywhere on the screen -- making flickering visible.

clovepower wrote: ↑Sun Jul 07, 2024 7:43 am I tried to implement it myself with peek and pokes. but if I try to put a second screen starting at 1024+512, this overwrites the ugBASIC program (I think, as everything goes insane).

In this case it could be not possible due to the nature of the memory layout that ugBASIC organizes and expects. In reality I believe there are also other technical reasons, we should see exactly which approach you have chosen. In ugBASIC, the compiled ugBASIC code starts from the address &H2800 while the memory space of the Motorola 6847 chipset under Dragon 32/64 is structured as follows (the starting addresses are fixed, see here): It follows that today, i.e. without moving the starting point of the compiled program, there are approximately 9216 bytes in text mode and 7168 bytes in graphic mode. Which means that there are, in theory, available: So, again without touching the starting point of the program, we note that double buffering would only be accessible for SCREEN #0-#12. Higher resolution modes may have DOUBLE BUFFERING, but only if you move the ugBASIC start point.

And here we come to another point, linked to the specifics of the Dragon 32/64 target: the RAM memory is limited in the range &H2800-&H7FFF] equals to &H57FF = 22,527 bytes. Therefore, if we increase the availability of video memory bringing it to have 2 pages of 6144 bytes = 12288 bytes which should start from &H0400, the program will only be able to start from the address &H3400. In short, there will only be 19455 bytes available.

clovepower wrote: ↑Sun Jul 07, 2024 7:43 am Is there a way to either implement the double buffer on this platform or at least to specify the size for the screen memory / start address of ugBASIC program?

When the first ticket will be implemented, the DOUBLE BUFFER ON / SCREEN SWAP instructions will also be available for the Dragon 32/64, so you can directly write a source similar to the one you were writing.

To specify the screen size and starting address you can use the direct access approach, with the caveat that this modification does not imply that the ugBASIC instructions adapt automatically. To do this you should change the starting address of the text and/or graphics screen, and this should be possible by changing the TEXTADDRESS / BITMAPADDRESS variables. Except that these variables are not directly accessible to the ugBASIC programmer since ugBASIC has the TEXTMAP AT / BITMAP AT instructions, which also take care of resetting the chipset accordingly.

Unfortunately, I just verified that it doesn't work on Motorola 6847 due to the paradigm shift done in one of the first versions. I'm not entirely convinced that it's worth fixing these two instructions but I opened a specific ticket:
Fix TEXTMAP AT / BITMAP AT under 6847 #800

Finally, regarding the starting address of the ugBASIC program, there is in fact no such thing.
But it is uiseful for sure, so I added a specific ticket:
Add start address program (CODE START AT) #801

First of all, thanks for the long and fast reply. And thanks for adding those new feature requests.

Also, thanks for pointing me to the WAIT VBL line command, I will use it in my code.

Last but not least, based on the memory map you describe I must be able to implement screen swap myself, the bad behavior is clearly an error in my code then. Let me have a look at it and I will come back after that. I just wanted to make sure I was not reinventing the wheel or trying to do something which is impossible due to compile setup.

Hi clovepower!

clovepower wrote: ↑Sun Jul 07, 2024 7:43 am Is there a way to either implement the double buffer on this platform or at least to specify the size for the screen memory / start address of ugBASIC program?

I'm happy to let you know that the pragma for defining the starting address of an ugBASIC program has been implemented in tonight's beta release!

This is the syntax: This DEFINE will change the starting address of the program to 3400(hexadecimal) or 13312 (decimal).

On this page there are all pragmas defined, and for the starting address for programs, all the limits for each target. Finally, to use the beta version you can click on Build > Options > Use BETA compiler on IDE, and then click on Configuration > Compilers to download the beta version of the interested compiler.

All these features will be made available in the next final release.

Hi clovepower!

clovepower wrote: ↑Sun Jul 07, 2024 7:43 am Is there a way to either implement the double buffer on this platform or at least to specify the size for the screen memory / start address of ugBASIC program?

spotlessmind1975 wrote: ↑Sun Jul 07, 2024 10:20 pm To specify the screen size and starting address you can use the direct access approach, with the caveat that this modification does not imply that the ugBASIC instructions adapt automatically. To do this you should change the starting address of the text and/or graphics screen, and this should be possible by changing the TEXTADDRESS / BITMAPADDRESS variables. Except that these variables are not directly accessible to the ugBASIC programmer since ugBASIC has the TEXTMAP AT / BITMAP AT instructions, which also take care of resetting the chipset accordingly.

I am happy to let you know that the bug has been fixed on the repository, and therefore it is now possible on targets that predominantly use the Motorola 6847 (Dragon 32/64 and TRS-80 Color Computer) to use the TEXTMAP AT and BITMAP AT commands to set the textual/graphic page to show and work on. Obviously, the limit underlying the chipset always applies, so it must be a multiple of 512 bytes.

The fix will be made available at the next COLDFIX.