The Sinclair QL Forum

Or you could try a different approach altogether: Use BLOCK or WM_BLOCK to draw your seven-segment characters. It has been done before, by W Lenerz. In fact I devised an asynchronous timer toolkit incorporating Wolfgang's code. The timer is perhaps not much use to you as it is designed for use in S*Basic programs that need to sport a timer that just keeps going whatever else the program is busy doing. It can of course be read and controlled by your program. It uses the RTC rather than the 50Hz interrupt, ie the resolution is a second.

I dont know if its available online anymore, but if youre interested you can always get it from me. The toolkit comes with the source code in assembler.

Per

Is something like this what you had in mind?
Per

pjw wrote:Is something like this what you had in mind?

The attachment Timer.jpg is no longer available

Per

That is certainly very useful pjw, I could use that myself.

My way is a little more elaborate and more about overcoming the tenth line and depends on specialised character fonts, however somebody might find this process useful.

Using the following code and loading the character font into memory 'a' the following can be achieved.

1000 :
1010 DEFine PROCedure c
1020 CLOSE
1030 OPEN #10,scr:INK#10,2: PAPER#10,7: CSIZE#10,1,0
1040 WINDOW#10,512,210,0,0: BORDER#10,2,7:CLS#10:PRINT #10
1050 CHAR_USE#10, a, a
1060 CHAR_INC #10,8,9
1070 PAPER#10,0
1080 FOR f=160 TO 220
1090 INK#10,2:PRINT#10,CHR$(f);" ";:INK#10,4:PRINT#10,f;" ",
1100 END FOR f
1110 :
1120 AT#10, 17,20:PRINT#10," ";
1130 FOR f=192 TO 200:PRINT#10, CHR$(f);:END FOR f
1140 PRINT#10," "
1150 AT#10, 16,20
1160 PRINT#10, " ";CHR$(201);" ";CHR$(202);" "
1165 AT#10, 16,26
1166 PRINT#10, CHR$(203)
1170 :
1180 END DEFine
1190 :

You will need to scroll own each image to see the result of adding specific characters together

With line at 1060 CHAR_INC #10, 10,11 you get this
With line at 1060 CHAR_INC #10, 9,10 you get this
With line at 1060 CHAR_INC #10, 8, 9 you get this[/color]

Hi,
I sent some font enlarging routines to Quanta. Dot_lookup gets the font définitions from memory and enlarges them to any SCALE. They should be in the Library. Maybe they could be of some use in this case. They were inspired by the QL World Fun with Fonts routines, which enable you to design fonts, but not enlarge them, except by the usual CSIZE commands.
Steve.

Dot_lookup, was this the Magazine or the Library Steve?

Hi,
Dot_lookup was on a floppy sent to Quanta, not published. Dilwyn may have it on his site.
Steve.

Hi again everyone and thank-you for such a wealth of good ideas!

As it stands, my testing so far has only been on QPC and it is here that the CHAR_INC 8,9 method correctly aligns the 8x9 standard font patterns on screen, but unless OVER -1 (xor) is also set, still appears to overwrite/blank the last pixel-row of the _previous_ character-line on screen.

None of your examples shown above seen to exhibit this behaviour, so my QPC setup must by screwy...

I haven't tried on my BBQL yet whilst I'm developing the program on my QPC...

Perhaps it will go away once I run it on the final target BBQL!

Thanks again everyone and Happy New Year!

M.

martyn_hill wrote:Hi again everyone and thank-you for such a wealth of good ideas!

As it stands, my testing so far has only been on QPC and it is here that the CHAR_INC 8,9 method correctly aligns the 8x9 standard font patterns on screen, but unless OVER -1 (xor) is also set, still appears to overwrite/blank the last pixel-row of the _previous_ character-line on screen.

None of your examples shown above seen to exhibit this behaviour, so my QPC setup must by screwy...

I haven't tried on my BBQL yet whilst I'm developing the program on my QPC...

Perhaps it will go away once I run it on the final target BBQL!

Thanks again everyone and Happy New Year!

M.

Hi Martyn, it is unlikely that anything is screwy with your system, if you look at my code for CHAR_INC 8,9 you probably overlooked that the characters are printed in reverse so to speak (bottom first), this is to overcome the additional line showing without using OVER-1.

Aha! Yes - I hadn't spotted how you did that - thank you!

So, this is expected behaviour - in summary, the std print routines will _always_ attempt to print an extra (10th or 0th, depending how you count it) blank pixel-line _above_ the row currently being printed regardless of the CHAR_INC settings in play (9 pixel-lines in this case).

So without OVER -1, such 'adjacent' printing needs to be issued bottom-up. Got it!

I can work with that - knowing now that I'm not just going mad!

And I promise to share the fruits of my labours here in due course (Alessandro - my 7 year old - asks me every night "When will my lapcounter be ready, daddy?" Even my boss isn't so demanding!