[VDP] V9938... Blinking "Text" in Screen 7...

Paladin (677)

04-09-2019, 17:00

Hey there, just trying to figure out a way to do the blink ANSI attribute on MSX2ANSI library...

jANSI has it, but it is "limited"... It just wipe out the possibility of light white (a kind of grey, white without bold), being that it is always bright white, and exchange this for opening the space on the palette for a "blink color", so text with blink attribute will have the current foreground color copied to blink color and a backup, and jANSI is hooked to vdp interrupts and after few interrupts it exchange blink color by the background color, and vice versa (in the palette).

This is limited, as it will allow blinking only correctly for the last attribute set (i.e.: red, blink, RED BLINKING TEXT, blue, blink, BLUE BLINKING TEXT, all text that should blink will blink as blue and with the other color being the backgroun of blue....) and also do not allow light white, that is a grey a little bit different than light black...

I kind of do not like this approach for msx2ansi, mostly because some ansi art can use the difference between regular white, bright white and bright black, and also, implementing a hook on a library would complicate things quite a bit and might cause undesirable results for whoever uses the library.

So I was thinking of using the alternate display of pages, setting the odd page in R#2 and updating page 0 and 1 at the same time, with the difference that page 0 would not have blinking text "printed", so using R9 bit 2 and programming an interval in R#13 and VDP would switch every second or so between pages, making the blinking text blink... This looks great and amazing right? All colors would blink properly on their own background, would not loose regular white...

Except that this would prevent scrolling nicely using register 23... To use it (like msx2ansi actually uses), you need to use all 256 lines in the page, and that means 256 * 512 / 2 (as screen 7 uses 1 byte for 2 pixels), so, if you do this in the two pages (as VDP will just change the page, offset rendering would be the same), where do you store your sprite pattern and palette? All 128KB of VRAM are being used and at some time, you will end-up messing with the table as you start writing on lines >212.... So the sprite cursor goes to hell and some more sprites could start to show as the patterns and palletes get messed up...

So, I did not even checked what would be the performance difference by updating two pages at the same time (as there will be a performance hit, for sure, every operation needs to be done on the two pages, except blinking characters, which are not usual), just lost the motivation doing this blinking attribute on MSX2ANSI...

As usually having other people oppinions can bring fresh (and better) ideas, anyone has a different idea on how to implement this without hampering the performance or losing a color and hooking to VDP interrupts? At this point I'm just thinking that this blink attribute is not worth all this trouble for a multi-purpose library...

By NYYRIKKI

Enlighted (6033)

04-09-2019, 17:44

Yes, there would be most definitely a performance hit about 50%, but the scroll issue should not be that bad...

Palette in VRAM is just for BASIC... As long as you don't use BASIC color setting functions, this will not cause a problem. You can keep the palette in normal RAM instead.

Sprites are a bigger problem as you would be using whole 128kB of memory... My suggestion would be to ditch the sprites completely. You quite rarely need to draw/erase the cursor (only draw when input buffer is empty) and by disabling sprites you get huge boost to VRAM writes / copies that I think will easily more than compensate the extra time that cursor draw needs.

If you really really really want to keep the sprites then I would say that moving sprites with COPY to different address inside border and updating new info about the location for VDP is still much faster than moving of 106kB of screen data to make a scroll, but as I said... I would not really recommend going that way.

By Grauw

Ascended (10711)

04-09-2019, 18:10

You could dynamically change the sprite table base addresses and rewrite their contents every time you scroll so that it always stays within the border region.

Or you could display the cursor with HMMV (or LMMV with a xor logical operator?) instead of a sprite, and only show it when text is not being printed e.g. through a short time-out. Seems simpler.

By NYYRIKKI

Enlighted (6033)

04-09-2019, 17:58

... and one more thing... I would definitely recommend using 1-page mode by default and only when 1st blinking character appears I would make a copy of the page and switch to 2-page drawing mode... Then switch back to 1-page mode if "CLS" is sent. This way you would get best of both worlds... Fast operation normally, but correct display of blinking characters in case such are used.

By Grauw

Ascended (10711)

04-09-2019, 18:15

Would be pretty cool if you would get this to work btw.

Nyyrikki's suggestion of showing the cursor only when the buffer is empty may be easier than a timeout. And using fast 1 page mode as long as no blinking characters are present also seems like a good optimisation.

For the page flipping you can simply use the V9938's hardware blink function, only need to change 1 register bit to activate it.

By ducasp

Paladin (677)

05-09-2019, 00:46

Lots of great suggestions here, thanks!

P.s.: it seems that page flipping is not uniform across emulators / OCM....

I could get it (page flipping, not everything) working fine on Open MSX by just setting R#9 bit third bit to 0, R#2 to 0x7F and R#13 to 0x55 (835ms page 1 / 835ms page 0). So it would show half the time page 1 (just the background color) and half the time page 0 (whatever has been printed on screen)....

But the same approach do not work on OCM or BlueMSX.... OCM just show page 1 and do not flip to page 0

Blue MSX just show striped bars, weird, weird (VDP Registers are with the same value as on Open MSX).... Is this not properly implemented on OCM and BlueMSX or am I missing doing something?

By ducasp

Paladin (677)

05-09-2019, 02:06

Yeah, by looking into KDL firmware source code, the vdp module responsible for graphic modes 4,5,6 and 7 doesn't even have connections to register 13, so it will just use the page in R2 and won't ever alternate pages....

A quick glance at what seems to be the latest BlueMsx source code also shows that Blink register is used only for text modes, not sure yet why instead of getting the solid color that is filled on page 2 I'm getting a stripped pattern, but probably it is miscalculating the vram address based on R2.

So it seems that both OCM and BlueMSX would need fixes to have this working (and altough I love OpenMSX, it doesn't have OBSONET emulation so it is not really useful for internet software debugging like BlueMSX)

By jltursan

Prophet (2619)

05-09-2019, 08:41

Why not avoid at all the alternate paging tricks and use a simple linked list of blinking texts that you'll iterate every n time alternatively printing or erasing the text in screen?
I'm supposing here that the screen won't be totally filled with blinking texts of course!, if so, the performance would suffer.

By NYYRIKKI

Enlighted (6033)

05-09-2019, 10:13

ducasp wrote:

Yes... In openMSX this also used to be broken, but they fixed it once I mentioned about it. In OCM I would guess similar thing might happen, if you talk with Kdl, but BlueMSX is completely dead... Actually in BlueMSX this is a bit broken even in text mode. I guess for debug purposes you can use EO bit in R#9 instead as IIRC that works correctly. (Uncheck "Blend consecutive frames") Naturally it does not look right, but should be enough for debugging purposes.

By Grauw

Ascended (10711)

05-09-2019, 10:54

In modes G6 and G7 the r#2 bits are shifted right by one, so you need to set it to 3FH, maybe that’s the problem.

Also, file bug reports to KdL for the OCM firmware, in my experience he will fix it .

By gdx

Enlighted (6113)

05-09-2019, 11:03

An example in Basic:

10 SCREEN 7:COLOR ,,4
20 ON INTERVAL=40 GOSUB 100
30 OPEN"grp:"AS#1: X=12: Y=100
40 A$="Example of ": C=12: GOSUB 110
50 A$="text blinking": C=9: BX=X: BY=Y: GOSUB 110: BL=L: C2=C: BC=6: BA$=A$
60 A$=" in SCREEN7":C=14: GOSUB 110
70 INTERVAL ON
80 IF STRIG(0)=0 THEN 80
90 END
100 SWAP BC,C2: COLOR C2: PRESET(BX,BY): PRINT#1,BA$: RETURN
110 COLOR C: PRESET(X,Y): PRINT#1,A$: L=8*LEN(A$): X=X+L: RETURN