Double Buffer for Dragon Target

[clovepower]

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.

Code: Select all

DEFINE DOUBLE BUFFER ON

SCREEN #2
CLS

DOUBLE BUFFER ON

10 PRINT "CIAO"
WAIT 1000 MILLISECONDS
SCREEN SWAP 

PRINT "MONDO"
WAIT 1000 MILLISECONDS
SCREEN SWAP 

GOTO 10

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?

[spotlessmind1975]

Hi clovepower!

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.

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.

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):

Code: Select all

Textual modes (starting address: &H0400):
SCREEN #0 : 512 bytes
SCREEN #1 : 512 bytes
SCREEN #2 : 512 bytes
SCREEN #3 : 512 bytes

Code: Select all

Graphics modes (starting address: &H0C00):
SCREEN #7 : 1024 bytes
SCREEN #8 : 1024 bytes
SCREEN #9 : 2048 bytes
SCREEN #10 : 1536 bytes
SCREEN #11 : 3072 bytes
SCREEN #12 : 3072 bytes
SCREEN #13 : 6144 bytes
SCREEN #14 : 6144 bytes

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:

Code: Select all

SCREEN #0-#3 : 9216 / 512 = 18 pages
SCREEN #7-#9 : 7168 / 1024 bytes = 6 pages
SCREEN #10 : 7168 / 1536 bytes = 4 pages
SCREEN #11-#12 : 7168 / 3072 bytes = 2 pages
SCREEN #13-#14 : 7168 / 6144 bytes = 1 page

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.

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

[clovepower]

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.

[spotlessmind1975]

Hi clovepower!

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:

Code: Select all

DEFINE PROGRAM START &H2400

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.

[spotlessmind1975]

Hi clovepower!

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?

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.