Microchip claim that an interrupt during a table read will cause the PC
to end up pointing to the wrong location. This appears to be nonsense,
but is still stated in data sheets as gospel; does anyone know
decisively if this CAN happen?.

> ----------
> From:         Mike Keitz[SMTP:mkeitz@JUNO.COM]
> Reply To:     pic microcontroller discussion list
> Sent:         Thursday, December 04, 1997 7:18 AM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      Re: Scorebaord [ot]
>
> On Wed, 3 Dec 1997 09:46:42 -0600 Scott.Horton1@BRIDGE.BELLSOUTH.COM
> writes:
> >Paul,
> >
> >I'm working on one of those electro-mechanical 5x7 displays.  I
> >understa=
> >nd the
> >electronics part, but I'm having trouble making the connection on how
> >to=
> > store
> >and retrieve fonts a "row" at a time in software.  Can you offer any
> >advice/pointers on how this is/can be done?
>
> With a table, of course.  The method of storing data tables in PIC
> code
> ROM is obscure, but well-documneted (I sus[pect any of the PIC FAQ's
> would cover it well).  Assuming you understand that, then it's just a
> matter of organizing the data.
>
> The most straightforward organization would be 7 tables of 128 entries
> (or however many characters the font contains) of 5 bits each.  The
> row
> being scanned decides which table to use.  Then look up the data for
> the
> character to be displayed and output it  to the columns of the
> display.
> For example, here's the letter "A":
>
> 00100 - Table 0 index 65
> 01010 - Table 1 index 65
> 10001 - Table 2 index 65
> 10001 --etc.
> 11111
> 10001
> 10001
>
> Rather than using seperate tables, they can be combined into one big
> table, compute the index as row*128 + char.  This requires a slightly
> more advanced lookup technique in order to address the proper entry.
>
> Storing only 5 useful bits in the 8 bit field that could be used for
> each
> table entry isn't real efficient.  It would be better to use a table
> of
> 5*128 entries by 7 bits and scan the display columnwise.  This also
> gives
> a faster refresh rate.  Even if the display must be scanned row-wise,
> the
> table could be organized columnwise and a more complicated lookup done
> to
> get 5 entries, selecting the proper bits for the row being scannned.
> Full optimization could pack the data in 8 bits wide (using 4 3/8
> bytes
> per character), but this would make editing the table difficult since
> the
> relation between the position of a bit in the table and a dot on the
> display would vary.
>
> >
> >How would you for instance store the letters H and I (I assume these
> >are=
> > simple
> >letters for example) and then retrive then a row at a time for
> >shifting =
> >out to
> >a two digit (14 column wide) display?
> >
> To display the top row using a rowwise table look up (0,'H') = 10001
> and
> (0,'I') = 01110.  Place these 2 5-bit results side by side and output
> them to the columns (a 2-digit, 5x7 display is 10 columns wide).  Now
> select the next row, lookup (1,'H') = 10001 and (1,'I') = 00100, and
> output them.  Continue until all 7 rows are done.
>
> As part of a project in progress I've entered a rowwise table of 128x8
> by
> 5-bit entries (in MPASM 'retlw') but not checked it thoroughly.  I'll
> send it privately upon private request.  Requests posted to the list
> will
> be summarily deleted.
>