Fonts.

StephenMoore · 2013-04-24 17:32

Has anyone archived fonts constructed for the various propeller VGA drivers available?

Specifically, are there alternative versions of 8x8 fonts available?

Is there convenient code available for building a custom font?

Also, if a specific driver has a font definition in a DAT section of the program, what is required to point to the Propeller ROM font for display (to free up program space)?

Regards,

sm

Rayman · 2013-04-24 18:03

I've posted "RaysFontEditor" here somewhere... It can edit and save the 8x12 font from VgaHiresText as well as other...

What driver are you using with 8x8 font?

StephenMoore · 2013-04-24 18:10

Hi Rayman:

I am using a driver that Kuroneko recently posted (single cog 320x356) that he packaged with an 8x8 font listed herein.

The driver works fine but the font is a little "blocky" and I was wondering if I could get any others.

Regareds,

sm

StephenMoore · 2013-04-24 23:14

Rayman:

I got the font editor from your website. It is a cool program. I will play with it and see what I can come up with.

Thanks.

sm

Duane Degn · 2013-04-25 01:36

I've typed the font called "Free Design" out as eight sets of bits (in binary).

Here's "ABC".

reeDesign065           byte %00110000                        byte %00110000
                        byte %00111000
                        byte %01011000
                        byte %01011000
                        byte %11111100
                        byte %10001100
                        byte %10001100
              
freeDesign066           byte %11111000
                        byte %11001100
                        byte %11001100
                        byte %11111000
                        byte %11001100
                        byte %11001100
                        byte %11001100
                        byte %11111000
              
freeDesign067           byte %01111000
                        byte %11001000
                        byte %11000000
                        byte %11000000
                        byte %11000000
                        byte %11000000
                        byte %11001000
                        byte %01110000

I'm using it in LED arrays. I don't know what you'd need to do to convert it to use with a VGA driver but maybe having it typed out like this would save your some time (if you like the font).

I personally think this font is easier to read on a scrolling LED array than many of the other 8x8 fonts I've seen.

You can see an example of it by skipping to 2:56 of this video. Or se it spelling out "Merry Christmas" here.

Let me know if you're interested and I'll post the font here.

StephenMoore · 2013-04-25 16:05

Yes I do like that Duane. The Kuroneko driver interleaves the complete character set one row at a time so I will have to do a little bit of juggling. How did you create your pixel maps?

Regards,

sm

kuroneko · 2013-04-25 16:48

StephenMoore wrote: »

... interleaves the complete character set one row at a time so I will have to do a little bit of juggling.

As this is a pixmap driver any two colour 8x8 font format will do. All you have to do is adjust the print method. The interleave is essential for pure tile based drivers where the font handling is done in place (critical timing). IOW, all fonts I have are interleaved (1 or 4 lines) so i didn't bother changing this one.

Duane Degn · 2013-04-25 16:50

StephenMoore wrote: »

How did you create your pixel maps?

I did it the hard way. I made an all zero character and copied it a bunch of times.

byte %00000000                        byte %00000000
                        byte %00000000
                        byte %00000000
                        byte %00000000
                        byte %00000000
                        byte %00000000
                        byte %00000000

I then filled in the ones to create the font.

I found the font on the internet somewhere.

When I'm able, I use a ten pixel wide "W". I don't really like my version of the eight pixel "W".

Here's the wide versions in case anyone is interested.

DAT wideFontsfreeDesignWide087 word %1100110001000000
                  word %1100110001000000
                  word %0110011010000000
                  word %0110011010000000
                  word %0110111010000000
                  word %0011001100000000
                  word %0011001100000000
                  word %0011001100000000
             
freeDesignWide119 word %0000000000000000
                  word %0000000000000000
                  word %1100110011000000
                  word %1100110011000000
                  word %0110011010000000
                  word %0110111010000000
                  word %0011001100000000
                  word %0011001100000000

StephenMoore · 2013-04-25 17:53

@kuroneko

So this might work with Duanes format...

PRI out(c) : b


  b := curx + cury * 320
  c &= 255
  
  colour.byte[curx + cury * 40] :=  curcol
  
  repeat 8
    screen.byte[b] := byte[base][c]
    b += 40
    c++ 'c += 256
    
  if ++curx == 40
   curx := 0
   cury++

I took the liberty of adding a character placeholder in the print function.

Regards,

sm

kuroneko · 2013-04-25 18:13

Make that:

PRI out(c) : b


  b := curx + cury * 320
  [COLOR="#FF0000"]c := c.byte{0} << 3[/COLOR]
  
  colour.byte[curx + cury * 40] :=  curcol
  
  repeat 8
    screen.byte[b] := byte[base][c] [COLOR="#FF0000"]>< 8[/COLOR]
    b += 40
    c++
    
  if ++curx == 40
   curx := 0
   cury++

StephenMoore · 2013-04-25 19:13

OK.

I get the byte reverse. I do not get the shift left 3.

When I load the font I get a few legible characters with a whole lot of garbage anyway.

Duane, is there a one to one ASCII correspondence here?

sm

kuroneko · 2013-04-25 19:20

StephenMoore wrote: »

I get the byte reverse. I do not get the shift left 3.

Assuming the font is build with 8 consecutive bytes for each character then character 1 starts at byte index 8, 2 at 16 etc (i.e. *8 or <<3). Alternatively just attach your project and I have a look.

StephenMoore · 2013-04-25 19:40

Makes sense. Thus the interleaved at 256 for the original. Either way the book keeper must get paid.

My problem was Duane's font omitted characters $01 thru $20.

It prints but to be honest your original font looks a scosh better. :blank:

Thank you both for your help. I am not sure how far I will get with 8x8 grids for appearance.

Is there any way to get 8x16 implemented (with the same color depth) without clogging the whole thing up?

kuroneko · 2013-04-25 19:48

StephenMoore wrote: »

Is there any way to get 8x16 implemented (with the same color depth) without clogging the whole thing up?

Assuming you mean 40x16 as the final resolution (y/2) then you can do that already, you just waste colour bytes in that you now can specify separate colour for top and bottom half. OTOH, if you still want 40x32 but effectively double y resolution (in terms of scanlines) I'll have to check the timing first ...

Another option would be the 50xH full colour driver which works with any 8xN font (but doesn't include pixel plotting).

StephenMoore · 2013-04-25 19:57

I like the 32 row display.

kuroneko · 2013-04-25 20:05

StephenMoore wrote: »

I like the 32 row display.

Fair enough. But to accomodate 8x16 (in the space of 8x8) I have to double the pixel memory (20K). That sounds like an awful lot (out of 32K) ...

StephenMoore · 2013-04-25 21:04

That was what I was fearing to hear. For a multi-prop scenario maybe we could live with it.

But I like the color by character feature of your driver and 8x8 is legible... so it is going to get used in one of our projects (a 3 axis stage to sense magnetic field).

Thank you very much. I recognize your talent as one of the great ones!

As far as 8x16 with existing driver I assume this would work:

PRI out(c) : b


  b := curx + cury * 320
'  c &= 255
  c := (c.byte{0}-32) << 3
  
  colour.byte[curx + cury * 40] :=  curcol
  colour.byte[curx + cury * 80] :=  curcol
  
  repeat 16
'    screen.byte[b] := byte[base][c]
    screen.byte[b] := byte[base][c] >< 8
    b += 40
'    c += 256
    c++

Regards,

sm

kuroneko · 2013-04-25 21:25

StephenMoore wrote: »

That was what I was fearing to hear. For a multi-prop scenario maybe we could live with it.

So you really need to be able to do pixel graphics and normal text? Dropping the former would reduce memory consumption (just checking).

8x16 modification:

PRI out(c) : b


  b := curx + cury * [COLOR="#FF0000"]constant(40 * 16)[/COLOR]
  c := (c.byte{0}-32) [COLOR="#FF0000"]<< 4[/COLOR]
  
  colour.byte[curx + cury * [COLOR="#FF0000"]80[/COLOR]]      :=  curcol
  colour.byte[curx + cury * 80 [COLOR="#FF0000"]+ 40[/COLOR]] :=  curcol
  
  repeat 16
    screen.byte[b] := byte[base][c] >< 8
    b += 40
    c++

StephenMoore · 2013-04-25 21:47

I will try an 8x16 font with this code.

However, I am still trying to understand the driver... the color map is by character but the screen map is by pixel.

So you really need to be able to do pixel graphics and normal text?

Are you suggesting that we can get color by pixel?

kuroneko · 2013-04-25 22:08

StephenMoore wrote: »

However, I am still trying to understand the driver... the color map is by character but the screen map is by pixel.

As I said earlier this is a custom job to emulate the screen of a (former East German) home computer. This includes pixel addressability and colour selection at character granularity (320x256, 40x32).

That said, I don't know your requirements. Maybe full colour text is enough (that's why I keep checking, we have any number of those) which would eliminate the current 10K pixel buffer (to be replaced by a 40x32 byte character buffer). Colour per pixel is possible but not at this resolution with just the Prop (e.g. C3 with Synapse OTOH manages 400x300 in full colour).

Duane Degn · 2013-04-26 06:42

StephenMoore wrote: »

My problem was Duane's font omitted characters $01 thru $20.

Yes, the font only had the printable ASCII characters.

highplainsbubba · 2013-06-11 19:43

I am trying to learn the video aspects of the prop and I was going through the VGA64_TMPEngine file by Kwabena W. Agyeman. I am a little confused. I thought this might be the right thread to find some help. On line 245 he codes "'' // StartColumn - The column to start scrolling on. Each column is 16 pixels wide so there are 40 columns numbered 0 - 39." This seems correct since the Parallax font is one tile wide(16 pixels) by 2 tiles tall(32 pixels). He goes on to code '' // EndRow - The row to end scrolling on. Each row is 16 pixels tall so there are 30 rows numbered 0 - 29. ". What I don't understand is how a character 2 tiles tall(32 pixels) fits into a 16 pixel tall row without overlapping the row above and below. My knowledge is limited in this area so what am I missing?

StephenMoore · 2013-06-11 21:45

I am not familiar with that particular driver but in general, if you are going to use a fixed screen buffer size, you will cut the number of rows in half by doubling the veritacl pixel count per character (so you will get 40 cols x 15 rows with your 16x32 pixel character)

You will have to modify the code for writing the character map too as Kuroneko pointed out earlier in this thread.

There are numerous other video drivers that accommodate different character resolutions... I am sure you will see in the file exchange OBEX.

Sorry I am not of more help right now...

sm

kuroneko · 2013-06-11 21:57

highplainsbubba wrote: »

'' // EndRow - The row to end scrolling on. Each row is 16 pixels tall so there are 30 rows numbered 0 - 29. ". What I don't understand is how a character 2 tiles tall(32 pixels) fits into a 16 pixel tall row without overlapping the row above and below.

It doesn't. A character simply occupies two rows in this driver.

highplainsbubba · 2013-06-13 14:03

I just found the Application Notes for video for the Propeller. That should help.
AN004 Getting Started with VGA pdf (16 pages)
AN005: GUI & Graphics Series - Simple VGA Menus

Fonts.

Comments