Today 17:30
Forum: The Lounge
Starter: Dick Barton
Views: 66
Replies: 5
Today 16:24
Forum: Proton Plus Compiler v3
Starter: cgriffin
Views: 1204
Replies: 6
Today 16:07
Forum: Master Synchronous Serial Port (MSSP) module / 3-wire SPI / I2C™ / Master and Slave modes
Starter: towlerg
Views: 42
Replies: 2
Today 11:20
Forum: The Lounge
Starter: theguru
Views: 44
Replies: 4
Go to last post By: normnet
Today 00:34
Forum: Proton Plus Compiler v3
Starter: zerone
Views: 1107
Replies: 3
+ Reply to Thread
Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: CDATA Font Table Format - Confused1852 days old

  1. #1
    Registered User canipus's Avatar
    Join Date
    Nov 2006
    Posts
    262
    Thumbs Up
    Received: 0
    Given: 0

    0 Not allowed!

    Default CDATA Font Table Format - Confused



    Will someone kindly explain this CDATA font table thing.
    When I look at the font.inc file supplied with proton it has the neat table format with 6 bytes per row needed for the GLCD. But when I look at the data from GLCD Font Creator it looks nothing like the font.inc file. Do I need to take the Font Creator file and reformat it or what? I understand that one table is HEX and the other is decimal format but where are the six bytes in each of the GLCD Font Creator lines? All these lines are different lengths so I'm totally confused.

    GLCD Font Creator
    '---------------------------------------------------------------------------------------------------
    '
    'FONT data for 11 pixels TAHOMA11test
    '
    TAHOMA11TEST_32:- ' Code for char
    CDATA 2,0,0,0,0,0
    TAHOMA11TEST_33:- ' Code for char !
    CDATA 3,0,0,126,1,0,0,0
    TAHOMA11TEST_34:- ' Code for char "
    CDATA 4,7,0,0,0,7,0,0,0,0
    TAHOMA11TEST_35:- ' Code for char #
    CDATA 8,64,0,200,1,120,0,206,1,120,0,78,0,8,0,0,0,0
    TAHOMA11TEST_36:- ' Code for char $



    Proton font.inc file
    -----------------------------------------------------------------------------------------------------------------------

    ' Font CDATA table
    ' Copy and paste this table into your own program
    ' if an internal font is required.
    FONT:- CData $00,$00,$00,$00,$00,$00 'Graphic character 0
    CData $FF,$FF,$FF,$FF,$FF,$FF 'Graphic character 1
    CData $07,$07,$07,$00,$00,$00 'Graphic character 2
    CData $00,$00,$00,$07,$07,$07 'Graphic character 3
    CData $E0,$E0,$E0,$00,$00,$00 'Graphic character 4
    CData $00,$00,$00,$E0,$E0,$E0 'Graphic character 5
    CData $FF,$FF,$FF,$00,$00,$00 'Graphic character 6
    CData $00,$00,$00,$FF,$FF,$FF 'Graphic character 7
    The 3 E's of Proton Development System
    * Excellence - robust, industry strength, best in class performance.
    * Efficient - concise assembler compilation.
    * Empowering - gets the job done faster from concept to production.

  2. #2
    Registered User Tim's Avatar
    Join Date
    Jan 2003
    Posts
    7,343
    Thumbs Up
    Received: 26
    Given: 45

    0 Not allowed!

    Default

    The normal font in Proton is for use with the normal print command

    If you want more control over what you print eg to pixel precision or large fancy fonts you have to use PPRINT

    See the sample folder for an example
    Tim

  3. #3
    Registered User canipus's Avatar
    Join Date
    Nov 2006
    Posts
    262
    Thumbs Up
    Received: 0
    Given: 0

    0 Not allowed!

    Default

    [QUOTE=Tim;87104]The normal font in Proton is for use with the normal print command

    If you want more control over what you print eg to pixel precision or large fancy fonts you have to use PPRINT

    See the sample folder for an example[/QUOTE

    Now you've lost me Tim! What has that got to do with the original Q? I'm trying to determine why the two table formats are different and whether I need to reformat the GLCD Font Creator data into $HEX to make it have the same format as the font.inc file. And why are there more than 6 bytes per line. I thought the standard transmission format to the GLCD was in 6 byte groups. There are more than 6 bytes in each line of the Font Creator file.
    The 3 E's of Proton Development System
    * Excellence - robust, industry strength, best in class performance.
    * Efficient - concise assembler compilation.
    * Empowering - gets the job done faster from concept to production.

  4. #4
    Registered User Tim's Avatar
    Join Date
    Jan 2003
    Posts
    7,343
    Thumbs Up
    Received: 26
    Given: 45

    0 Not allowed!

    Default

    Can I ask you why you are using "Font Creator"

    The data produced its not and was not designed to be usable by any standard Proton commands.
    Tim

  5. #5
    Registered User canipus's Avatar
    Join Date
    Nov 2006
    Posts
    262
    Thumbs Up
    Received: 0
    Given: 0

    0 Not allowed!

    Default

    Quote Originally Posted by Tim View Post
    Can I ask you why you are using "Font Creator"

    The data produced its not and was not designed to be usable by any standard Proton commands.
    Well this is what the blurb for the product says:


    * Export fonts as source code for your favorite Basic, Pascal or C compiler.
    * Full integration to Swordfish™ basic compiler IDE (as plugin) from Mecanique.
    * Full integration to Proton™ basic compiler IDE (as plugin) from Crownhill Associates.
    * Full support for MikroElektronika mikroBasic™, mikroPascal™, mikroC™.


    It specifically mentions Swordfish, Proton and Mikro
    Further there have been several forum posts from folks who swear by the product so .... are we talking two different product here or something?
    The 3 E's of Proton Development System
    * Excellence - robust, industry strength, best in class performance.
    * Efficient - concise assembler compilation.
    * Empowering - gets the job done faster from concept to production.

  6. #6
    Registered User Tim's Avatar
    Join Date
    Jan 2003
    Posts
    7,343
    Thumbs Up
    Received: 26
    Given: 45

    0 Not allowed!

    Default

    "Font Creator" converts fonts to work with PPrint which is an add on

    Like I said look in the samples folder
    Tim

  7. #7
    Contributor DaveS's Avatar
    Join Date
    Aug 2004
    Posts
    845
    Thumbs Up
    Received: 8
    Given: 1

    0 Not allowed!

    Default

    Hi Everett

    As Tim said, he difference is that GLCD Font Creator produces font tables compatible for use with Tim's PPRINT or PPRINT32 for the Samsung GLCD, which can handle none standard font heights and variable char widths.

    Samples\Proteus\PPrint\PP_TEST.BAS

    Understanding the format.
    So the font in your first post is 11 pixels high, (2 bytes of data per pixel width, 11 bits used 5 bits disregarded) the first number in the char CData is the width of the char (in Pixels) it doesn’t matter if the data is in decimal, hexadecimal or even binary, also the CData table has a dummy byte to even up the table for 18F PICS.

    An old post for PPrint
    http://users.picbasic.org/Howto/PPRI...le_fonts_o.htm

    Dave

  8. #8
    Registered User canipus's Avatar
    Join Date
    Nov 2006
    Posts
    262
    Thumbs Up
    Received: 0
    Given: 0

    0 Not allowed!

    Default

    Ah OK! Now the penny's dropped. I was puzzling over the replies until the realisation sunk in that PPRINT is not a standard Proton function but an extended one. Tim actually said as much but somehow it didn't register what I was reading. I think I have it all clear now. Thanks too David for the very useful links and the format explanation. I've got it all straightened out now.

    So is there going to be a new version of GLCD Format Converter supporting other GLCD controllers or has this wonderful product ground to a halt? I purchased it when it first came out at the low starting price on the basis that I knew it would be useful one day. However I have yet to see any further development over the years. I know it got pirated so I hope that isn't the issue.
    The 3 E's of Proton Development System
    * Excellence - robust, industry strength, best in class performance.
    * Efficient - concise assembler compilation.
    * Empowering - gets the job done faster from concept to production.

  9. #9
    Contributor DaveS's Avatar
    Join Date
    Aug 2004
    Posts
    845
    Thumbs Up
    Received: 8
    Given: 1

    0 Not allowed!

    Default

    Quote Originally Posted by canipus View Post
    So is there going to be a new version of GLCD Format Converter supporting other GLCD controllers or has this wonderful product ground to a halt? I purchased it when it first came out at the low starting price on the basis that I knew it would be useful one day. However I have yet to see any further development over the years. I know it got pirated so I hope that isn't the issue.
    Good question, there was some discussion on the SF forum, did write a font converter program which does all formats and compression but dropped development for now as it wouldn’t pay if the GLCD Format Converter was to be updated.
    I also bought the plug-in it’s been a few years with no update, for us purchasers of the product.

    There are large fixed width fonts for the Toshiba here http://www.picbasic.org/forum/showth...ghlight=PPrint

    Dave

  10. #10
    Registered User canipus's Avatar
    Join Date
    Nov 2006
    Posts
    262
    Thumbs Up
    Received: 0
    Given: 0

    0 Not allowed!

    Default

    Quote Originally Posted by DaveS View Post

    There are large fixed width fonts for the Toshiba here http://www.picbasic.org/forum/showth...ghlight=PPrint

    Dave
    Thanks Dave. I'm sure these will come in useful for me at some point. I read a couple of times through that thread and you've done some great work there. If you ever decide to complete your compressed fonts plug-in idea, count me in as a purchaser.

    Coming back to the subject of internal fonts and using CDATA commands to write the fonts into flash rom, I take it this will happen every time the PIC boots up; just how great is the risk that the chip will conk out in your opinion? I'm thinking if a handheld instrument gets switched on ten times a day, that's 3,650 times a year part of the flash rom chip is going through an erase/write cycle, then after a couple of years you're near the 10k cycle limit for the latest chips. Maybe booting up an instrument ten times a day is a bit extreme in real life scenarios, but isn't this one of the main reasons for placing fonts in external EEPROMS i.e using external fonts
    The 3 E's of Proton Development System
    * Excellence - robust, industry strength, best in class performance.
    * Efficient - concise assembler compilation.
    * Empowering - gets the job done faster from concept to production.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

     

Similar Threads

  1. Print big font for toshiba GLCD 6x8 format
    By SELCUK in forum Proton Plus Compiler v3
    Replies: 89
    Last Post: 29th September 2014, 19:13
  2. what's faster, working with bits in byte table or word table?
    By barak in forum Proton Plus Compiler v3
    Replies: 7
    Last Post: 12th March 2011, 00:52
  3. Font Table for Char above 126?
    By Beginner in forum Proton Plus Compiler v3
    Replies: 9
    Last Post: 21st February 2008, 14:46
  4. Confused...
    By pic-ignorant in forum Proton Plus Compiler v3
    Replies: 2
    Last Post: 26th October 2007, 19:24

Members who have read this thread : 31

Actions :  (Set Date)

You do not have permission to view the list of names.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts