Play with Fonts - Question

[thorsinclair]

Hi all,

I wrote in Super Basic a short software because I want to change the data of the single characters diplayed on the screen in realtime. So what I did is:

Copying the character set from the ROM into the RAM
Setting the pointer to use the character set which is now in the RAM
Printing characters on the screen
Using POKE to change the value of the character definitions in the RAM

What I get is that the characters printed on the screen are not updated in realtime but must be printed again on the screen after having changed the values in tha RAM.

Is this behaviour OK or did I do sth wrong?

Many many years back I did sth like this on my C64 (blame me for being an ex Commodore user) and achieved nice graphical effects on the screen.

Some ideas?

Best,
T

[RWAP]

The QL screen is stored in an area of memory as a bitmap (the original display measures 128 bytes x 256 lines = 32768 bytes).

When the ROM routines print a character to the screen, they copy the character from the ROM, resize it as necessary (to reflect CSIZE), add the colour information and then set the relevant pixels on the screen display memory area to reflect each character. The information is added with NOT, OR or XOR dependent on the setting of the OVER command.

As a result, if you want to change the displayed character on screen in realtime, as you amend the character set, you need to use the command:

AT x,y:PRINT chr$(a)

You need to remember the exact position of each character, and retain the correct CSIZE, INK, PAPER, and OVER settings.

[thorsinclair]

Thank you for the info

I tried that but it isn't working as I would, but may i did not explain very well what I want to achieve.

Let's assume that the whole screen is filled up with a blank character (space, chr$(32)) and the definition of the pixels is stored in the RAM area. Now you poke a new pixel definition into the RAM area where the chr$(32) definition lies. Why aren't the chracters on the screen not updating automatically? To see the modified character I need to print it again. Any idea on this?

Best,
T

[dex]

This is misunderstanding.
QL does not use a text display mode.
QL has "only" graphics mode (bitmap framebuffer).

I.e., content of VideoRAM is not mirror of the font definition content.
Character graphic template is only copied to VideoRAM in the process of printing a character, and remain unmodified even if the font template is being modified. In fact, the VideoRAM content is not a character, as defined by ASCII code, but just its graphical representation (as a drawing on paper, whatever, if it is an A letter, an B letter, or a car or sun drawed on the paper).

The only way to modify the character dislplayed on the screen is to re-draw it.

[RWAP]

Hee hee - I thought that was what I had explained.....

Basically you have to think of the QL screen as if it were a printed sheet of paper - if you update a character, you need to remove the old character from the paper (erase it) and reprint it.

OVER 1 : PRINT CHR$(a)

will happily overwrite the previous letter without you having to worry about erasing it.

[dilwyn]

Hee hee - I thought that was what I had explained.....

Basically you have to think of the QL screen as if it were a printed sheet of paper - if you update a character, you need to remove the old character from the paper (erase it) and reprint it.

OVER 1 : PRINT CHR$(a)

will happily overwrite the previous letter without you having to worry about erasing it.

Alternatively, think of the QL screen as pure graphics. To display text you have to convert the dot pattern to graphics (which is essentially what PRINT does). So there is no text as such stored in the screen, just a pattern of dots that happens to resemble text.

Dilwyn

[thorsinclair]

Thank you for the comments! So I can't do it the same way I did it on the C64 many years back. Anyway, the chip that controls the display graphics is the ZX 8301, right? Anybody may can tell me where I can find more info about this chip? Thank you.

[tofro]

There's not much to know about this chip - It just does what it's intended for

There's one single register ($18063) that is accessible from user code doing the following:
Bit 0: Don't touch, leave at 0
Bit 1: Blanks display, if set to 1
Bit 2: Don't touch, leave at 0
Bit 3: 0: Mode 4, 1: Mode 8 (Easier done through TRAP #3)
Bit 4, 5, 6: Don't touch, leave at 0
Bit 7: Fetch screen memory from $28000 instead of $20000. Allows to display a second screen.
Unfortunately, standard QDOS does not support this, so you're on your own ($28000 is where standard QDOS puts the system variables and it has no support to move these out of the way). Minerva supports this, however. If you use a Minerva ROM you have actually two independent screen memory areas and you can do nice tricks switching back and forth between the to pages.

In general, it's a bad idea to use direct access to the hardware, as it makes your software non-portable between the various QL-like incarnations.

Tobias

[thorsinclair]

Hi Tobias,

Thanks for this. Is there any reference for this kind of info you can point me too? I've got interested in this after reading about Omega's dithvide project. There are demos (graphics, animations, ...) for more or less all kinds of computers but nothing I'm aware of for the QL. Would be nice to create sth ...

[tofro]

Hi,
apart from what I have written, there's not much more information available (most probably, because there isn't more - the QL hardware is so downwardly simple that there isn't much more in terms of hardware registers to learn about.
The information above comes from the QL Technical guide, abailable through Dylwin's website.

Omega's code seems to use the second screen and switch back and forth between the two screens and screen modes.

Cheers,
Tobias